We can successfully transmit position data from the cameras to any connecting Raspberry Pis. Currently, in absence of a working Pi Car prototype, most of our implementations output received data to a file along with arrival timestamps. This allowed us to analyze the delay between frames at different points of the pipeline.
We analyzed time intervals , we saw a mean of 8.3 milliseconds between frames, they can strangely vary up to the low hundreds; when this happens, the following frames always arrive extremely quickly (<5-6ms, to as low as 0.05ms), as if to ‘make up’ for the prior delay.
Using the component object class definition programs we created, we were able to successfully sample data from the hardware components to the Raspberry Pi using the data aggregation scheduler program. We then looked into testing for latency issues while sampling for data inputs.
We created benchmark testing sampling methods in the main scheduler (main-sensors.py) for each component using an instantiated object of the encoder and IMU types. These methods were created using a time.time() call before and after the “object.sample()” method was called. Therefore, the data in our graphs shows the duration of each sample call for the specific component type. Though these benchmark testing sampling methods were called using the LoopingCalls Twisted method set at the target frequency of every 20 ms (50 Hz), all of the objects were sampled easily within this range — averaging 0.2 ms, 0.3 ms, and 3 ms for the left encoder, right encoder, and IMU respectively.
Data Aggregation Scheduler
Within the Twisted scheduler, we measured the total duration between each sampling call, similar to the time interval measurements from before. The following two charts show the interval lengths per frame instance for the IMU and Motive:
As discussed with the electrical team, we set the LoopingCalls to run at 50Hz. In the graphs above, we see that the vast majority of sampling frames occur on time, with several outliers randomly spread out among the data set.
Finally, since the team ran into time constraints with creating a compatible controller program for the scheduler to pass data inputs into, we instead made them available to users through a basic web server. When the programs are running, the scheduler opens a websocket on one of the RPi’s ports and renders an HTML text containing our data payload:
As shown above, any person can view real-time vehicle metrics by opening the RPi’s IP address in a browser tab. Since the human eye can only process changes to a certain extent, we set the page refresh rate to 0.1 seconds per load.