sciss Posted April 25, 2018 at 01:06 PM Share Posted April 25, 2018 at 01:06 PM 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! Quote Link to comment Share on other sites More sharing options...
borg Posted April 25, 2018 at 02:47 PM Share Posted April 25, 2018 at 02:47 PM 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. Quote Link to comment Share on other sites More sharing options...
sciss Posted April 25, 2018 at 04:07 PM Author Share Posted April 25, 2018 at 04:07 PM 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? Quote Link to comment Share on other sites More sharing options...
sciss Posted April 25, 2018 at 10:44 PM Author Share Posted April 25, 2018 at 10:44 PM 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. Quote Link to comment Share on other sites More sharing options...
borg Posted April 26, 2018 at 09:34 AM Share Posted April 26, 2018 at 09:34 AM 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 Quote Link to comment Share on other sites More sharing options...
sciss Posted April 27, 2018 at 01:11 PM Author Share Posted April 27, 2018 at 01:11 PM 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.. Quote Link to comment Share on other sites More sharing options...
borg Posted April 27, 2018 at 01:56 PM Share Posted April 27, 2018 at 01:56 PM 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! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.