Jump to content

IMU v2 - nominal and actual sampling rate, time stamps


sciss

Recommended Posts

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!

Link to comment
Share on other sites

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:

NAHhdbP.jpg

 

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.

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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..

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...