Testing the current state of the messbox

After working on the server-PI and sensor-PIs separately and often virtualized we decided that it’s time to put the messbox together and see what happens.

iot_glue_setup

The PIs boot and connect automatically. The sensor-PIs directly start sensing and forward the data to the server-PI who reads the GPS data and writes the received sensor data to csv files as soon as all sensors are connected.

iot_glue_screenshot

Here you have a sample csv log file which contains a quake around the timestamp 707020657 (line 844): sample csl file

The format of the csv file is:

sampleID, timestamp, sensorName (GPS), time, lat, lon, speed, course.
sensorName (FL), gyroX,gyroY,gyroZ,acceX,acceY,acceZ,rotaX,rotaY,rotaZ,
sensorName (FR), gyroX,gyroY,gyroZ,acceX,acceY,acceZ,rotaX,rotaY,rotaZ,
sensorName (BL), gyroX,gyroY,gyroZ,acceX,acceY,acceZ,rotaX,rotaY,rotaZ,
sensorName (BR), gyroX,gyroY,gyroZ,acceX,acceY,acceZ,rotaX,rotaY,rotaZ,
measurementID

And here a chart of the test quake:

received_2015-06-07_19-56-44_chart

Advertisements

Testing MPU-6050 with Node.js and Websockets

After setting up and testing the hardware we need to get going on the software side of the measurement setup.

We decided that each of our four MPU-6050 sensors gets its own RPi (Model B) for sensing the accelerometer and gyroscope data. These samples get directly transferred to a Server-RPi (Model 2-B) where they receive a timestamp and are stored for later use. As a protocol we keep it simple and use websockets for the beginning. We are going to switch to a UDP protocol if the network delays get problematic.

Node.js library for the MPU-6050 sensor

Fortunately there are npm-packages for our sensor out there, let’s try to install them:

  • npm mpu6050 (didn’t compile)
  • npm i2c-mpu6050 (worked!)

Using the example code in the i2c-mpu6050 package provided sensor data with ~35 Hz. After hacking around a bit it went up to ~46Hz. As we don’t need the temperature provided in the package’s regular index.js we uncommented those code lines and got a sensing frequency of ~55Hz (RPI Model B) which should work for us (if the car drives max. 160km/h we still have a sample at least every 80cm). With a RPI 2 we would get ~76Hz.

First sample data

To get a first idea of the sensed data, the delays and if a quake of the underground can be seen in the data we did put 4 RPis with sensors on a common ground and shaked it (by knocking) 5 times while sensing with 55 Hz and sending the data to our server. Here are first results:

received_samples_booklet5_4PI-PI2B-55Hz_1PIsample

received_samples_booklet5_4pi-pi2b-55hz_allsamples1

With a sensing frequency of 55Hz a difference between the timestamps up to 18ms is regular.

Size of stored data

The data volume we produce and need to store for 4 sensors with 55Hz is ~100MB per hour, thus our class 6 SD card should be able to manage that.