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.

[mjs513]

Hi @SidLeung thanks for the heads up. Did a quick search and found some limited info. Looks nice. However, the only thing I saw was that there are test points that supposed expose all the connections - I think. I have attached a HMC5883L through the I2C connections and works without a problem. Only issue is the syncing that was why I was asking if it would be possible to use the fifo to link it to an external mag.

[SidLeung]

You are fast, Mike. As you may notice that there are many Curie signals being brought out for external access in tinyTILE. The back side of the board is the only suitable space to accommodate them all. You may also notice that these connection points are intentionally made larger than standard test points for the purpose of soldering.

[mjs513]

Hi Sid. Been working with IMUs and AHRS for quite awhile so this is of particular interest to me. Couldn't tell from the photos how big the connections were from the couple of photos I found on line. I did notice that the info available said it would be programmable from the Arduino IDE. So the question would then be would the corelib for the Arduino 101 be the same as for the tinyTile. I know I am jumping ahead of myself - either way would be interesting to get ahold of it when it comes out. Thanks for the info on the tinyTile.

[descampsa]

Implementing a available-like function for gyroscope/accelerometer data does not seem too complex, see descampsa@773a800 and descampsa/MadgwickAHRS@83bb806. I have not tested it much yet, but on the Orientation Visualizer example, it seems to work as expected.
A proper FIFO implementation would be better, of course.

[eriknyquist]

Thanks @descampsa, I'll try it out.

[eriknyquist]

Thanks descampsa, tested it out and seems to work great. Made the updates below

#317
arduino-libraries/MadgwickAHRS#16

[eriknyquist]

Latest update is a bit more flexible that my first attempt. This will be in the next release.
ee08a03