IMU v2 - nominal and actual sampling rate, time stamps

[sciss]

Hi there,

 

I'm new to this; just received an IMU v2, and all seems pretty cool, great documentation and software examples!

 

I'm using the Java bindings, and I notice two problems with the call-back approach (trying linear accel at the moment): Neither does the call-back receive any time stamp information, nor does the nominal rate given through `setLinearAccelerationPeriod` have any reasonable correlation with the actual rate. Also, there is no information available about the acceptable sampling rates. Comparable IMUs usually have a resolution of 200 to 500 Hz. I can't seem to get close to that.

 

For instance, if I set `imu.setLinearAccelerationPeriod(10)`, the observed sampling rate is around 57.2 Hz, where it should ideally be 100 Hz. This adds to the problem of the missing time stamps, because I notice that for small periods / high sampling rates, the same values might be polled numerous times, and I want to experiment with position tracking, so the duplicate values would increase the already existing noise.

 

So I would be grateful, if somebody could share some light on how to get tight and precise timing when polling for example the linear acceleration.

 

Thanks!

[borg]

Do you have the IMU Brick V2 directly connected to a PC via USB or is it in a stack? Do you have any additional Bricklets connected?

 

If the fusion algorithm is enabled you should be able to reach a 100Hz update rate. Here is screenshot from the BNO055 datasheet:

 

If you turn the fusion algorithm off (see set_sensor_fusion_mode) the frequency goes up, you can then configure it with the set_sensor_configuration function.

[sciss]

Do you have the IMU Brick V2 directly connected to a PC via USB or is it in a stack?

 

Directly connected.

 

Do you have any additional Bricklets

 

No.

 

Perhaps the problem is in brickd or the way the listener is implemented in Java?

[sciss]

Here are my measurements:

 

val m = Seq(
  1 -> 559.5,
  2 -> 286.2,
  3 -> 187.0,
  4 -> 141.7,
  5 -> 114.6,
  6 -> 95.8,
  7 -> 82.0
)

val e = m.map { case (p, hz) => hz / (1000.0/p) }
e.mean  // 0.5688
e.sorted.apply(e.size/2) // 0.5724

 

Left is periods specified in milliseconds, right is actually frequency measured. That is to say, the frequency seems to be by factor 0.5724 lower than it should be according to specification. Also this way it seems impossible to produce the correct rate to read exactly all 100 samples per second that the BNO055 should output.

 

[borg]

I tested it and to my surprise i could reproduce your problems!

 

While introducing proper I2C DMA handling we added a bug to the IMU Brick V2 that resulted in some crazy randomness in the period calculation for the callbacks (and also the I2C communication period with the BNO055 was a bit broken).

 

Can you try the attached firmware? You should now get the callbacks in exact 10ms intervals.

 

Thank you very much for your help with debugging this.

imu-v2-2.0.12-beta1.bin

[sciss]

Thank you for the update. The reported rate is now accurate (I tested with period 10 and it indeed gives 100 Hz).

 

This patch however has a new problem - you can't save the calibration, at least from brickv, it seems to crash the brick, the connection is lost when you press 'save calibration'; you can bring it up again by disconnecting and reconnecting USB, but then you have to calibrate again.

 

Best, ..h.h..

[borg]

This patch however has a new problem - you can't save the calibration, at least from brickv

 

Yes, i know. Have the calibration fixed in git already! I will make a new firmware release today.

 

Edit: New firmware (2.0.12) is released now!