What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?
- Getting the different systems using the Pi to run at the same time and still meet our latency requirements. We are still working on unit testing each part but we will be putting the code together (hopefully) ~next week. If the system becomes really slow with the RPi bluetooth sender/receiver running, we’ll have to find places to simplify our code and the data being sent to the server at a time. Currently the latencies for sending just the foot sensor readings to the server and the extension reading data from the server are pretty small, so we are not too worried. Power draw may also be a concern when we have more computation being done, since our Pi already gets wickedly hot before we even run anything. In terms of safety we can manage this risk by keeping the Pi very far from the user when we put the mat together. We thought about having some sort of casing to protect the user, but realize this would also worsen the heating problem.
- Managing the bluetooth connection between ESP32 and RPi. Setting this up is taking a little longer than expected (at least as of the time of writing this team report – the work continues today…) due to some unexpected incompatibilities with some of the packages we tried to use. However, we’ve already successfully tested two-way communication from the ESP32 and the nRF connect app (just downloaded on a phone), and we’ve set up a BLE scanner on the RPi with compatible libraries to test today. If we completely fail at setting this up, we could try connecting to the server via Wifi directly to send/receive data. However, this is probably way more work than using bluetooth (and would likely destroy our power requirements) so this is more of an absolute-worst case plan. We also expect the BT to be figured out soon, as there is a decent amount of documentation on this.
Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?
Instead of using a breadboard to do the wiring of the foot sensor mat, we’re using a protoboard with a 3/5V regulator + voltage divider circuits + pin headers soldered on. This was needed to make connections easier to reconfigure and keep our wiring more organized/scalable (even just connecting 2 foot pads using the breadboard was already pretty burdensome). No costs were incurred since we already had the protoboards from a previous project.
Provide an updated schedule if changes have occurred.
As of right now, no schedule changes are needed. Integration is underway to set up communication between all our components, though we are still also working on getting the data sent from each part to be what we want.