Posted on July 23, 2017 by Gabe Parmer
In a nutshell, an SD project needs to have core computer science as its “meat”, something that’s innovative, something that will challenge you and take you out of your comfort zone. We know that some projects involve a lot of work, but a lot of programming is not a substitute for innovative core CS content. Your project should clearly include both technical challenges and an algorithmic component.
To illustrate, here are some projects that would NOT be acceptable, no matter how ambitious the programming effort:
Now, there are exceptions. For example:
However, to be granted an exception, you will have to make a strong case for an exception.
Here are some criteria to use in looking for projects:
A few more points about the project:
Each project should have well-defined sub-projects with clearly-delineated interfaces that separate the sub-projects. You’ll need a number of sub-projects equal to the number of group members, so each sub-project should be of roughly equivalent size. Each sub-project should have some component that independently satisfies the Project Criteria above.
Sub-projects focus less on the project’s “idea”, and more on the constituent technological challenges. An example of a set of sub-projects:
We’re happy to help you work on breaking a project into sub-projects, but you have to be proactive and contact us as early as possible as this process will take time that does not excuse you from the SD deadlines. Once the sub-projects are delineated, you must document what the interfaces between them are. This will be an iterative process going from an abstract description, all the way to function prototypes and data specifications.
Though there are many different types of sub-projects, we want to provide some guidance for the challenges and requirements for a few of the major sub-project classes. Your overall project will likely consist of multiple sub-projects that fall into multiple categories below. You might not be comfortable with many of the technologies and techniques discussed below. This will be a continuous trend in Senior Design, yet you must still figure out how to make it work! By now you should understand how to learn independently, and senior design is about continuously learning. This means you will have to spend large amounts of time learning about the underlying technologies, and formulating plans for using them.
ML techniques comes in many different varieties. Do you have a supervised learning, an unsupervised learning, a reinforcement learning problem, or otherwise? Are you focusing on classification, clustering, anomaly detection? Different ML libraries provide varying levels of support for each of these, so it is important to first have a good grasp on the goals of your system.
As mentioned above, the main complexity in ML projects is understanding how to perform feature extraction. Before understanding this, you should learn about the assumptions and considerations of some of the major ML libraries as they define their capabilities, but the focus should be on how to feed processed data into the library. You must also investigate what scale of data collection and labeling is required for training the library. An argument must be made that data is available in the volume required for this effective training.
Most of the time in formulating and planning your project should focus on how to take the raw data, and convert it into a form that is useful for the ML library. This might involve image processing, conversion of data into the frequency domain (FFTs), part-of-speech tagging, phoneme extraction, etc… Many of these can be partially provided by libraries, but you must clearly identify your own contribution, and the challenges therein.
You’ll also need to determine how effective your system is once it is up and running. Doing so on a small, hand-picked set of inputs is not acceptable, and neither is using the training data. Though at the early phases of your project these tests will be tentative, it is important to have a plan for this.
Summary. Factors to consider in the design of your system:
The main challenge to designing an algorithmic project is properly specifying the problem. To understand what your project entails, you should first characterize the inputs and outputs. Given this, provide a high-level sketch for the tasks involved in converting from inputs to outputs. You might need to understand some of the existing technologies that can help you with this goal. These include SMT solvers, ILP optimizers, graph processing libraries, temporal data-bases, etc… If the core of your algorithmic challenge is solved by an existing library, then your project must present complexity in the conversion of your data into the input, and/or from the output of the existing solver. See the Machine Learning subsection above for details about this.
Summary. Factors to consider in the design of your system:
These projects enhance or create a systems infrastructure, and make it more capable than it was before in some significant way. In these projects, it is important to understand the underlying infrastructure, and how you will alter it. Understanding how the various components interact, and where you’ll insert your code is essential. To really get a sense of this, it is likely you’ll have to dive into the code to really understand the APIs of the interactions.
Systems projects are about removing the “magic” from various layers in the system by diving in to understand how they work. To understand what modifications and additions are necessary, you’ll need to start an iterative process of gaining an ever-more increasing understanding of the relevant code. To force yourself to do this, you’ll want to state your goals in as much detail as you can using the terms of the abstractions and mechanisms of the system. For examples, how to threads, processes, VMs, hypercalls, system calls, network sockets, etc relate to your area of focus?
After understanding the landscape of your project, you have to understand the surrounding technologies; the libraries and services that can help you accomplish your goals. A number of practical factors further complicate system projects from there. Tasks as simple as compiling and building your software might be challenging. Making and testing changes might be more tedious than higher-level tasks. Thus, you should investigate how this aspect of the system will work; how will your changes compile with the rest of the system, and how long and complicated is that process?
Finally, you should focus on what the mechanisms, policies, and abstractions that you’re seeking to provide. You should be able to state these with respect to your goals, but also with respect to the abstractions of the existing system.
Summary. Factors to consider in the design of your system:
Embedded system projects involve constructing a physical object with some computational integration. This can be for many reasons including
It is difficult to make a commercial-grade embedded system in terms of footprint and battery life. Your focus should be on providing a prototype with sufficient capability to convince an unbiased observer that the vision of the project could be possible with more resources. Given this, you should focus on what is required to demonstrate the capabilities of the system.
The main factors in deciding what you want to do with the embedded system will focus around a number of factors How do you want the system to sense the environment (sensors)? That is, you’re using an embedded system often to provide some insight into the state of the physical world. How do you want the system to impact the environment (actuators, screens)? With the sensor information, some projects will attempt to then change the world in some way, for instance, via locomoting (quad-copter), changing the contents of a screen (augmented reality), or physically controlling some process (flipping a switch). Lastly, how do you want the system to communicate with the broader project (networking and I/O)? If the system is part of a larger project that includes desktop/server processing, then it must communicate in some way with the broader system.
Which embedded system hardware and software to use should follow from these questions with some considerations for operating system system, required system software, and the complexity of setting up and using the environment. Further, if processing is required on the sensor data, you must investigate the options, and the software for helping you with this. Such processing might include reducing noise in the sensors (e.g. Kalmann filters), providing some privacy transformations (determining if someone is being sensed and either anonymising the data, or not sending it), or providing security (e.g. encryption). Once you process the sensor data, will you need to construct a model of the environment (i.e. try and track humans, track signal strengths, etc…)?
Summary. Factors to consider in the design of your system:
We’re constant given access to new and interesting sensors. Examples include the Kinect, Wii nunchucks, the Leap, and even sensors to measure EKG brainwaves. Though much simpler, any project that uses a camera as an input device also falls into this category. Unlike embedded system projects, most of these sensors easily integrate into a normal computer (laptop/desktop). Thus, these sub-projects should focus more on how to interpret and use the sensor information for something novel.
Summary. Factors to consider in the design of your system:
Projects that can effectively make use of, or need cheap access to
…but do not need access to…
…can get utility from using either an Android phone or an iPhone. We have had quite a bit more success in the past using Android as the app and development environments are more accessible. Such projects will need to use the system emulators, and will require quite a bit of start-up effort. Getting an app up and running requires a significant amount of up-front work.
Android is a very large eco-system of libraries and system services that you can leverage in your projects. This is good as it can enable you to provide quite a bit of functionality, but bad in that it requires quite a bit of work to determine what you should use.
To make progress on this, you have to assess what is required by your project. Which hardware do you need access to, and what do you need from it? Which software you end up using will depend on the answers to these questions. Secondarily, what amount of processing do you want to perform, and can it be performed on the phone?
Summary. Factors to consider in the design of your system:
Acknowledgments. This document is an adaptation of a document originally written by Rahul Simha in 2010, later updated by Tim Wood.