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. I advocate creating a few additional planning documents that precede the Gannt 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.

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.

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).

As engineers, we should be somewhat familiar with this. In Physics classes we learn about gedankenexperiments, otherwise translated as though-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.

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.

Main