The seeing like a bike team is now in the stage of wrapping up the sensor box and integrating parts as a system. Each level of the sensor system design – from hardware to software – is under the iterative refinement process to better collect data as well as to provide a seamless experience to end users.
Box Design
The sensor box needs to be tenable from external pressure and shocks. Also, it needs to provide an easy-to-use interfaces for users. In order for allowing shock/pressure/vibration tolerance, we aim to make boxes using a sturdy ABS. Before working on actual ABS boxes, we first started testing our designs using wooden plates since it was more efficient in terms of time and cost. 
After several iterations, we were able to come up with a best design that can house complex structures of sensors, a battery, and an Arduino board. After finalizing the structure of the box, we tried to laser-cut an ABS box. However, using a laser cutter to make required 
holes and ventilation slits was 
tricky due to the characteristic of ABS – it was burning easily when exposed to lasers. After several experiments, we were able to find a good way to cut ABS boxes. Using a fast speed laser with low power, the burning effect decreased. By cutting the ABS multiple times with this weak laser, it was possible to make relatively neat holes and slits.
The front case, i.e., the server 
case, is also being redesigned and constructed using a 3D printer. Since the GPS device has been moved to the front, we redesigned it, and now, it is being slowly constructed from the printer. We are still in the process of refining the locations of slits and holes, but we are almost there!
Data Quality and Computing Efficiency
Even though data collection functionalities and high-level board optimizations were completed last week, we have been continuously working on optimizing the code structure and data formats. This optimization process is not only for data quality in the acquisition stage, but also for the power efficiency (so to allow the longevity of the device). This process involves (1) running the code in the command-line mode; (2) minimizing the use of REST APIs; (3) using GPS timestamps for entire sensory data; and (4) setting a time interval correctly for each sensor. In addition, we also redesigned the LED operations to make the indicators simple.
The original Raspberry Pi server was running in the Windows mode due to the convenience for setting the auto-running mode. However, running the Windows mode on Raspberry Pi with a battery is inefficient from the longevity perspective. This led us to dig into the Linux settings, and we finally changed the mode to the command line. Also, we tried to minimize the use of REST APIs. While they provide powerful interfaces for other applications to communicate to the server, it also creates another layer of software, i.e., network layer, which each sensor needs to go through. This is not critical in the power consumption, but still we moved several sensor communications to simple socket applications so to minimize the script executions.
Timestamp was another challenge in the original system as the Raspberry Pi’s time was not universal one. Due to the inconsistency and inaccuracy of times among devices, synchronization techniques had to be used to maintain the timestamps consistent across different datasets. To make it simple and accurate, we came up with a solution: GPS’s timestamp that comes from the satellite is used for the entire dataset. Since GPS data is collected every 200ms, we update the global time every 200ms, and other sensors use this global time when logging their times.
Finally, we set the data collection interval for each sensor. For example, air quality does not change very quickly, it is okay to collect data every second. Meanwhile, the acceleration of the bike can change very quickly depending on the movement of the bike, so the accelerometer needs to collect data more frequently then air quality sensors. As part of this effort, ultra sonar sensors’ interval has been set to 200ms based on a simple physics model. We believe this series of setting and tuning parameters and refining software structures will allow better raw data quality and energy efficiency.
Next Steps
The next steps are to connect everything with a new box and case, to calibrate some sensors (for making sure the sensory data is correct), to deploy the system on a bike, and to start collecting pilot data. Once pilot data looks good, we will make same boxes more and deploy them to passionate riders’ bikes. We cannot wait heading out to ride a bike with our system.