Validate sampling rate of IMU sensor

[sbrodeur]

The sampling rate for the IMU unit is currently at 20 Hz, which may be a little low. It would be nice to see if it could be increased to 100 Hz without much performance impact on the Beaglebone Black. However, this should only be done if we estimate that we are currently losing too much information at 20 Hz, specially for angular velocity and linear acceleration:

Note: the gyroscope sensor operates natively at 800 Hz, and the accelerometer at 1600 HZ.

[sgcarrier]

Maximum rate for the imu capture seems to be around 22Hz. Will continue to investigate if this is a performance issue that we can fix.

[sgcarrier]

With new higher bitrate for i2c, and by using FIFO BYPASS mode for the devices, 130+Hz imu data can be obtained.

However, FIFO BYPASS causes issues with the magnetometer. Also, having a sampling frequency over 20Hz seems to have too much of an impact on performance, especially during recording.

[sbrodeur]

I just found linux drivers for the gyroscope (l3gd20), and accelerometer + magnetometer (lsm303):

l3gd20 http://www.st.com/content/st_com/en/products/embedded-software/mems-and-sensors-software/drivers-for-mems/stsw-mems018.html

lsm303 http://www.st.com/content/st_com/en/products/embedded-software/mems-and-sensors-software/drivers-for-mems/stsw-mems025.html

Those may allow for better sampling rate than the current implementation. Like for the barometer (bmp180), I was able to compile the drivers. They remain to be tested on the robot.

[sbrodeur]

See commit 7a921d2 for all the necessary Linux drivers to install: https://github.com/sbrodeur/ros-icreate-bbb/tree/master/src/imu/drivers

[sbrodeur]

It seems that the LSM303D and L3GD20 sensors report data as HAL events: https://github.com/01org/android-iio-sensors-hal https://www.inovex.de/blog/android-sensor-integration-part-3-hal/ https://www.kernel.org/doc/Documentation/input/input-programming.txt http://www.linuxjournal.com/article/6396 https://www.kernel.org/doc/Documentation/input/event-codes.txt

It seems that the data is published as EV_ABS events:

root@beaglebone:~# cat /sys/class/input/event1/device/name
l3gd20_gyr
root@beaglebone:~# cat /sys/class/input/event2/device/name
lsm303d_acc
root@beaglebone:~# cat /sys/class/input/event3/device/name
lsm303d_mag

See here for usage: https://wiki.analog.com/resources/tools-software/linux-drivers/input-misc/adxl345

evtest /dev/input/event2
Event: time 1476653982.173862, -------------- EV_SYN ------------
Event: time 1476653982.274380, type 3 (EV_ABS), code 0 (ABS_X), value 41220
Event: time 1476653982.274380, type 3 (EV_ABS), code 1 (ABS_Y), value 20820
Event: time 1476653982.274380, type 3 (EV_ABS), code 2 (ABS_Z), value 997260
Event: time 1476653982.274380, -------------- EV_SYN ------------
Event: time 1476653982.374665, type 3 (EV_ABS), code 0 (ABS_X), value 41640
Event: time 1476653982.374665, type 3 (EV_ABS), code 1 (ABS_Y), value 19860
Event: time 1476653982.374665, type 3 (EV_ABS), code 2 (ABS_Z), value 994860

[sgcarrier]

Right now, the captureBMP node for the barometer, is slower than its accel/gyro counter-part. I suspect this is due to the file reading which can be quite time consuming. I will continue to investigate to speed up the node. Once it reaches an acceptable speed, we could switch LMS303D and L3GD20 to this as well.

[sbrodeur]

I think it is also possible that the delay comes from the overloaded I2C bus. All devices (RTC, accelerometer, gyroscope, magnetometer) are currently sharing that single bus. Running the barometer node alone should show if this is the case or not.

[sgcarrier]

captureBMP was using too expensive read operators on the files. Now it's running well and can go 45Hz+ if we desire.

[sbrodeur]

See: http://elinux.org/Sparkfun:_BMP085_Barometric_Pressure_Sensor#Reading_the_Temperature_and_Pressure_Programmatically

[sbrodeur]

From the datasheet of BMP180 (page 13):

We should get higher rates, up to 128Hz.

[sbrodeur]

Barometer will be updated at 15Hz.