Longboard sensor module log

Group Members

-Sam Ragsdale
-Danny Andreev

Week 1

This week we began physical planning and code/data planning. Additionally we created our BOM and Gant chart.

Physical planning: First where the parts will go in the box, what size the box should be, and where the box should be mounted on the board.

Code/Data Planning: We started planning how much data we were going to capture, where to store it, and how to interpret it. We also started looking into communication protocols.

Week 2

We continued on our project planning. The majority of this was finalizing the parts we were going to use and made sure all of the parts were compatible with eachother. Another constraint for the parts was size. We tried to find both the smallest and most accurate (while still cheap) version of parts. That way we could ensure good data while also ensuring a small form factor on the board. The final (and possibly most important) constraint for the sensors was that they had to be compatible with the raspi. While writing our own library for the sensors is possible, it would take away from time we could spend making the final result of the project much better overall.

Week 3

We've started developing the CAD model of all of the components to make a box that holds the sensors and the Raspi. This started with modeling all of the individual components that will go in the box and so that the CAD model can accurately be built around them. The model also has to be built taking into account the restrictions of 3D printers.

We've ordered all the components and have started working on learning the libraries necessary to communicate between the Raspi and the external sensors. 

Additionally we've prepared our presentation for the class: https://uploadfiles.io/ibkna

Week 4

Files are now backed up on Danny Andreev's git repo under a larger electric longboard project. All electrical components were CADed.
https://github.com/lolomolo/LongboardMarkII/tree/master/Ev%20Sensor%20Module

The components are fully and accurately modeled in our CAD file for the box.

The code planning is almost complete and ready to be started for next week. We've decided we will take 3 samples/second from every sensor and store that in a local SQL DB. We are aware that some of the sensors will provide the equivalent of "null" data for some of those samples so this will allow us to "smooth" or average the data to ~1 data point/second for the user to view. Finally we will use a python library to chart the data locally on the raspi and view through HDMI. This will allow us to quickly iterate through different sample rates and smoothing algorithms and ultimately decide what data the user will have access to.

Week 5

A very basic case for the box is complete. Needs some cosmetic touch-ups and a few more port holes before printing.

The code stubs and database have been made. The code still needs communication protocols implemented to the sensors and then we can begin reading data and testing.

Week 6

Box model is complete, the bottom potion of it has been printed. The electronics are all soldered together, tested and working. The Raspi is set up, and a local SQL server is running on it. Database input and output via Python has been built and tested.

Week 7

Now we just need to read in sensor data and store it to server. I2C output (accelerometer) to the Rapsi is up an running. Once UART (GPS) is in we can start adding data points to the DB. The code is currently on the Raspi which doesn't interact well with WUSTL wifi, but will be on github (and linked here) ASAP.

Additionally NumPy is now on the RasPi but we have to switch the RasPi OS to one with a GUI to get the graph output we desire.

Week 8

Sam (4.5 hours): The Raspi can read data over I2C and UART from the sensors. Helper classes have been made for GPS and acceleration polling. This vastly simplifies interaction with the sensors. The data needs to be distilled and relevant information displayed on a UI.

Danny (5 hours): The model for the enclose has been updated slightly. It needs to be reprinted. Two prints were attempted but failed do to build plate adhesion.

Week 9

Sam (8 hours): The issues with the SPI interface were resolved. Gps, Acceleratometer, barometer data was successfully gathers.

Danny (8 hours): A basic program was finished which pulls images of google maps through the google maps API and overlays the GPS Locations onto the picture. This will be further revised and the GUI updated.

Week 10

Danny (8.5 hours): Data is processed and using the google maps api we can compile a an image which shows the path, velocity and position during the travel of the device.

Sam (6 hours): The "recoding" code is now all in a loop that runs based on button press. This required a large restructuring/refactoring of existing code. Additionally there is a module to export the DB to a CSV file to send to the google maps api script.

Week 11

Danny (3 hours): The box has been reprinted and fit to size. The wires have been redone to cut down on space requirements and to provide more consistent electrical contact.

Sam (6 hours): The SQL DB is now deleted every time the script is run. This makes for better data output for future processing, as well as deletes all of the unnecessary data. The Raspi now allows for Internet Connection Sharing (ICS) which is important so that a user can connect to the Rapsi like an access point while the Raspi is also able to communicate with the Google Maps API (over the internet).

Week 12

Sam (6.5 hours): Spent a long time trying to get ICS working over wifi, but this was a fruitless effort. Getting ICS to work over wifi would allow the user to connect to the Rapsberry Pi by connecting to the Raspberry Pi's wifi as an access point. This would then allow the user to receive the data while the Raspi is also able to communicate with the Google Maps API. This did work in testing on my home router, but does not work on WUSTL wifi. WUSTL wifi has (reasonably) banned ICS as it is a security problem for the user. Unfortunately that means that during testing we will have to connect to the Raspi over ethernet. Lastly, the HTML templating via python is built and working. This uses an HTML template and python's built in string templating function to replace values from an HTML template file and places the output in the Apache server directory, such that every time dboutput.py (our main script) is run it updates the index.html on the Apache server.

Danny (6 hours): Finished up mathematica script to take recording CSV, filter, and parse into a google maps api string to receive a static image. It has been tested and is working consistently. We still have to make sure we can connect it to the python database end on the raspberry pi. Thankfully, Debian (the OS for Rapsi) comes with mathematica installed.

Week 13

Combined (18 hours each): Our final week was very hectic so it became all hands on deck. We learned that mathematica notebooks will not run on the Raspberry pi. This resulted in us having to fully rewrite that portion of code in python. That worked out fine and resulted in better interfacing between the portions of code anyways.

Additionally the discovery last week that we would have to use ethernet instead of wifi for the demo meant that we had to use a RPi3 for the demo rather than a Pi Zero. This had a lot of implications. Firstly, we either had to reprint the box or get rid of some of the internal components. We chose to get rid of the barometer (because we can just use GPS altitude), wire the massive GPS antenna wires to the outside of the case (as it would likely be mounted separately from the module anyways) and remove two battery cells. In the end, with a lot of finagling, we got it all into the box.