What Worked
The project could only come together once all programs worked on their own. To do so, we each had to master multiple sensors and understand how to wire, read, and communicate them.
After each of us mastered our respective sensors, we shared our findings and worked on the cumulative program which put all together at once. As we mastered each sensor separately, we created simulations specific to them. Through this, we all had great success in creating intricate processing games that used the full potential of the sensors.
A big part of this was, of course, the physical wiring of these sensors. With the work on code (the majority of the project), and mastering efficient wiring, we made individual programs that would later collaborate under one. In this way, our plan of separating them together worked great. Besides getting over the coding hump of using multiple languages at once (C in Arduino and Java in processing), and learning how to use mostly new sensors, there were a few major obstacles in this area.
The largest stress came after we put them together...
What Didn't
Although we had to make a couple of changes, like scrapping the heartbeat sensor; our project, for the most part, went as expected! Everyone was able to make their simulations work perfectly fine with the sensors. However, this was never going to be the hardest part of the project, only the most time-consuming. Instead, it was the multi-sensor aspect that caused the most trouble.
Because there are so many sensors, and each simulator uses the same or different sensors in different ways, it was important to properly organize these sensors so that all the games could work under one program! In addition, having them work in the most efficient way, and minimizing data waste, was integral.
To achieve this, originally, we tried sending values based on what each game needed at the time. This was to allow delays depending on how often each game needed and to minimize sending values that weren't being used. Doing so would have been the most storage efficient, and kept the serial communication clean. Unfortunately, switching between programs did not work so smoothly. While one change was okay, too many meant that the values got convoluted and inaccurate. Additionally, to do this method, we needed to send values to Arduino as well as to processing. This is because changes in processing dictated which program was playing, and so Arduino needed to know about these changes to know which sensor values to send. So, this two-way communication caused many issues. The stage change was delayed, and, as mentioned, values were convoluted.
Thus, with this failure, we had to change our method to a less efficient, but more proven plan. This was sending call sensor values at once, all the time. This meant no delay in sending values since values like joystick needed to be updated constantly. Since all were sent at once, and change in sending one value meant a change in all. Ultimately, this method works perfectly well, and come presentation day we were easily able to switch programs and read accurate sensing data. We ended up having to opt for the less efficient method, but it succeeded overall.
And of course, it did! This course has crafted us into sensational makers!