CurieIMU Doesn't Provide API For Sync To Gyroscope Rate

[PaulStoffregen]

CurieIMU allows the gyroscope measurement rate to be controlled with these functions:

https://www.arduino.cc/en/Reference/CurieIMUsetGyroRate
https://www.arduino.cc/en/Reference/CurieIMUgetGyroRate

However, there does not appear to be any API for an Arduino sketch to actually read the data at the proper rate. Functions like readGyro() return the stored data from hardware registers. If called rapidly, readGyro() will return the same data many times.

Normally Arduino libraries provide an available() function, to indicate whether (or how much) new data is available, which hasn't already been read.

Acquiring gyroscope data at the correct rate is particularly important. Gyroscopes measure angular velocity. Converting this to angular position with a Kalman or other filter algorithm involves integrating the angular velocity with respect to time.

If an Arduino sketch re-reads the same data, because it can't reliably know when the sensor has produced a new measurement, and it passes that data to a Kalman or similar integrating filter, the short-term rotational motion will be overestimated. The result is sketches using CurieIMU must resort to very poor design practice. For example, the Orientation Visualizer uses this kludge factor:

int factor = 800; // variable by which to divide gyroscope values, used to control sensitivity
// note that an increased baud rate requires an increase in value of factor

Obviously this is terrible design. The computed angular position depends heavily on the Curie's CPU speed, by how quickly it can run the loop() function. If you run the visualizer and vigorously shake the Arduino 101 board for several seconds and then let it rest, you'll see the visualizer almost always stops in a very wrong orientation, and then very slowly corrects itself over about a minute as the filter uses the accelerometer data to gradually correct for the massive errors caused by incorrect rate & improperly scaled gyroscope data.

[Dan-Lightsource]

The suggestion to provide an available() function makes sense.

Another option which may help, along with this, would be to extend the API to make better use of the FIFO on the IMU to provide synchronised accel/gyro samples which are timestamped by the IMU.

[eriknyquist]

the BMI160 has a SENSORTIME register, a 24-bit counter that increments with all "sensor events" (updates to data registers). I propose using this to implement a simple IMU.available() function with no buffering, i.e. if IMU.available() returns 3 then you can only actually get the current sample. The next step will be to use the IMU's internal 1024 byte FIFO as @Dan-Emutex suggests, to make IMU.available() behave like the other available() functions and return the buffered data.

[eriknyquist]

On further investigation, it looks like you can't really get useful information from the SENSORTIME register unless you're also using the BMI's internal FIFO to buffer samples. So I think that any worthwhile implementation of an available() function for the IMU class will need to make use of this FIFO; the simpler design I described above will be mostly useless. I'll need to keep reading the datasheet to figure out how exactly this thing works.

[mjs513]

@eriknyquist In going over the schematic for the Arduino 101 I didn't see the BMI160 sensor connections. Reason I ask is that if a magnetometer is attached to the secondary interface of the sensor (either SPI or I2C you could read the mag data into the FIFO as well. Not sure if this is possible. As Paul can tell you mag data is used in the 9dof version of the AHRS algorithms and is intended to correct some of the gyro drifting over time.

[SidLeung]

For the Arduino 101 board, it does not have the provision to attach a magnetometer. However, the new product, tinyTILE, that was announced at the IDF event has that capability.