Final Demo and Documentation
The final demo will happen on the last day of class in the lecture hall. You will be required to bring your fully working and integrated works-like-looks-like prototype to class and show it off. It's a speedy day for Paul (have to get through ~70 projects), so you should practice a 30-second presentation to ensure that we can have a very quick demo.
A dire warning: there is a well-known supernatural phenomenon that occurs on all demo days. You will be visited by the Demo Day Demon. Your prototype, which was working up until 5 minutes ago, will suddenly stop working. Something will fry. Something will come loose that you can't find. Some program will crash that will never restart. The Windows Team decides that exactly right now is the only time to make you update for five hours. The only way to ward off the Demo Day Demon is to have the instructor look the other way and your prototype will suddenly work. As soon as the instructor looks back at your demo, it will be broken again.
Realizing the unfortunate reality of this formidable poltergeist, it would be wise for you to make your videos and document your project as soon as your demo works at home. Then, when you transport it to the lecture hall, if something happens, you have visual proof that your demo did work at some point.
Along with your demo, you should hand in your documentation. Everything should be up to date: the latest and most accurate pitch, the current BOM, any supporting sketches. But more importantly, your sketchbook should tell the story of how you developed your project and why it connects to COGS. We should be able to clearly see a progression from your first sketches, a few intermediary ideas, a few dead ends, and then your final project. Feel free to print pictures and be creative.
The point of having this documentation is (a) we can actually understand what you're trying to do; and (b) when something does inevitably go wrong, you have proof that you really did try hard. Otherwise, we can only go off of awkward smiles, excuses, and shrugs during the demos, and nobody likes that.
In terms of quality, this prototype should be "good." This is your chance to show off your skills. However, that will mean something different for each project. The point of having demos and sketchbook reviews is to help you work towards a high-quality project. We prioritize a good concept that has been fully thought-through and faithfully realized over something electronically complex. Some of our top projects from last term only had "something like" four servos and an ultrasonic sensor, but they were very well executed.
Marking
The documentation and prototype will be marked on quality of concept, quality of execution, and quality of presentation. Electromechanical complexity is a consideration, but absolutely not the main metric by which you'll be evaluated. The main question to ask yourself is "did I pursue a clear idea as far as I could?" There is a hall of fame in the lab, and you can see the diversity of the projects on display: from a highly developed and complex pill dispenser to a simple breathing ball that lit up, these students decided on a clear idea, tried their best to make it happen, and documented the process in their sketchbooks well.
Handin
You will physically hand in your sketchbook on the final demo day. You will keep your personal prototype (return anything that belongs to us in the lab). You will submit your video (and anything else you need links or interactivity for) to Canvas. Everything is due at the beginning of demo day.