Waseh

This project helped me learn how to design and build embedded systems in order to fulfill various goals. It gave me the tools and skillset necessary to make decisions regarding the components as well as the design of the system. It further helped me improve my understanding of the PIC32 microcontroller, and the underlying system to IoT platforms. The greatest challenge was interfacing with new technology (ESP8266) that required a deeper understanding of both the microcontroller and the esp module. Even then, there were a lot of variables that were hard to understand, such as the state that an ESP might go into if power is removed in the middle of transmission. To try and adapt to these problems, I tried to run as many tests using a serial terminal instead of with the PIC. I also had a debugging setup for the ESP8266 so that i could easily switch between the PIC32 and the serial terminal, in order to communicate with the ESP. Furthermore, I aimed to improve my understanding of the library and the UART peripheral of the PIC32. From this ordeal, I learned the importance of constant testing and incremental implementations. By adding one layer at a time (setup, then transmission, then reception, etc) I was able to understand the system better as well as tackle bugs as they came instead of doing it all at once towards the end. The biggest takeaway from this would be to never rush design and implementation. Taking time to produce a robust design reduces the effort in debugging and then realizing that there is a design flaw. Also, I hope to use this experience and develop a better process for simultaneous testing and prototyping.

Ian

Aside from learning about various practical things (Hall Effect sensors, servo interfacing, networking, etc.), I also learned more process-oriented things.  With the complexity of our system, it became increasingly important to be able to test individual portions of the system by themselves.  To this end, I learned to develop some tools (such as the command line interface) solely for the purposes of aiding debugging.  These ended up being very useful.  The biggest problem encountered for me was the numerous hardware problems encountered on the PCB, in particular involving the power supply.  Some of the buttons were also nonfunctioning.  There were several take-aways from these problems.  First and foremost was that it pays off to spend somewhat more time developing and verifying something like a PCB before fabricating.  Fixing the layout problems took much more time than it would have taken to catch them in the first place.  Second, I learned to never assume that something works in debugging.  Because I assumed all of the buttons worked, it took me a long time of frustrating debugging to actually check and verify that they were broken.  Similarly, many hours were spent trying to find the software cause of the motors powering up by themselves when the problem ultimately was solved by switching power supplies.  When dealing with embedded systems where there can be both hardware and software failures, it is particularly important, I have learned, to not assume anything about the functionality of anything.  Though perhaps questioning the design of the MIPS core in the PIC goes somewhat far.