This page provide some recommendations and insights from several semesters of advising senior design teams. While the material presented in the course is correct, there are some additional details or practices that enhance the planning and execution of the proposed project. Most of them involve the planning stage, which ultimately impacts execution.

While Gantt charts are nice, they can be far too detailed while at the same time missing important aspects of the best way to execute the construction process. Additionally, Pert charts are easy to make without thinking too deeply about what is an effective execution strategy for the team. Both of these charts are easy to draft up in a very generic form that hide all of the important parts of the design process/timeline. That makes the documents pretty useless as guides to follow. The typical charts remind me of the PhD Comics strip on drafting a thesis outline. The outline is so generic as to be uninformative. A good outline gives a strong sense for what will be done. The design chart documents need to do the same.

The best way to proceed is to actually have multiple documents that go from the high level and descend to the low level. The high level would be the manager equivalent and promote rapid identification of the overall design and its components. The low level is the engineer equivalent and gets closer to the day-to-day or week-to-week details. I advocate creating a few additional planning documents that operate at the higher level and precede the Gantt and Pert charts. These documents are visual and textual summaries of the proposed design solution. There are two basic additional charts that I always recommend since they really expose what the design process will require.

The first is a block diagram of the device to design. Since we are in ECE, this often involves hardware, electrical circuit, device, and digital computation components. A minimal hardware block diagram should be constructed that describes all of the important components and their connectivity. If there is non-trivial software associated to the digital compute devices, then the main software elements should be included in the diagram if reasonable to do so, otherwise additional diagrams should be made per compute component that visualize the software blocks and their connectivity/dependencies.

The second is what I call the device task breakdown. Take the hardware and software diagrams, then label each major component as a task.

Efforts: At least one person, preferably two, should be lead on each task

Often I advise teams whose projects involve non-trivial physical design components. Naturally, mechanical and physical design is not a forte of ECE students. Thus initial designs tend to be simplistic, describe individual pieces without contemplating their union, or miss important fabrication considerations. To overcome this I recommend following the same iterative and exploratory design procedure that students in industrial design classes do. It's really a shame that these techniques are not taught to ECE students as they apply to even circuit design. Conversely good practice associated to general design is most likely also good practice for ECE-specific design.

Some of the links below are google searches, which means that they will contain good hits and irrelevant hits. Scroll through them and your find good examples. Usually it should be clear what are the good hits from the context of the link text.

Industrial design folk do lots of pre-design exploration, have many design iterations where multiple design instances and modifications get considered. For those few that seem promising, they go so far as to create cool miniature mock-ups. Sometimes the mockups use modern fabrication methods (3D printing, laser cutting) or old fashioned methods (paper). Fast, small instances of the envisioned design rapidly identify what really is promising and what would be problematic. In the senior design class there is not enough time to actually do this, but the degree to which one can make the effort, even in thought, is quite worthwhile.

The most important philosophy, one that even applies to research, is to always make an effort to identify at least 5 solutions. We can call this process prototyping, for lack of a better word. Pre-design exploration often involves identifying a theme or underlying design direction then examining variations of the theme/direction. Note that in the link many instantiations are considered. Do this for each important component of the product. The current senior design course sequence does not really provide for this, nor have a strong coercion component to induce this. As a team, you should put the extra effort now to do so. It will give great return on efforts during ECE4012.

For both the inital thinking about the product, as well as the final demonstration, I recommend doing something called storyboarding, which is the process of describing and visualizing interface scenarios between the user and the product. I am not sure if the hits will be the best, but here is a google search for the topic (try clicking on the “engineering” option since we are engineers, then maybe the “software” option with “engineering” unclicked afterwards).

As engineers, we should be somewhat familiar with this. In Physics classes we learn about gedankenexperiments, otherwise translated as thought-experiments. Here physical scenarios are specified and imagined. Applying the laws of physics to these scenarios leads to hypothesized outcomes in order to reason through a particular concept. The design process should involve something similar. Storyboarding is a way to force the designer to think about the user interaction and the designed item more thoroughly, from the beginning to the end of the interaction. If multiple pathways are possible, then they should be outlined.

Make sure you are aware how much mechanical or physical design is involved.

Computer vision can get nasty fast. It is easy to define a design project that sounds easy, but is in fact deviously hard. Humans are really good at visual processing. Computer vision is still in the dark ages, no matter what hot new method is out there. The first step should always be to vet the idea by talking to experts. Sometimes they know tricks that can make the difference between doable and impossible.

Robotics is really a multi-disciplinary field. Opting to design a functional robot is a non-trivial task, usually well beyond the time frame allotted by ECE4012. It is best to create a realistic end-point for the robotic device, as well as to define what the real contribution should be. Is it the robot or what the robot does? Is it a new accessory for a robot? Define what matters and simplify the rest.

Some design teams don't really need to build a robot, but can simply use an existing robot (such as the Turtlebots from ECE4560, or a robot from a research lab). Some choose a commercially available product hoping that it can serve as the robotic platform. This can often be a mistake since commercial products don't always have the sensory devices, or don't provide access to sensory signals, that are crucial to robotic autonomy. The effect of this deficiency will be to make the entire project more difficult as the team works to overcome these limitations. It is important to be aware of what affordances are available versus what are needed. This way the proposed design is compatible with the underlying device. It can be OK to us a commercial device that has limited capabilities if the design takes them into consideration, and defines an execution plan that is informed by them.

Main