Analysis of embObjIMU rate

[Nicogene]

Trying the changes added in #592 I noticed a worse behaviour of iKinGazeCtrl while using the imurfe data instead the "old" imuBosch_BNO055 attached via i2c.

I dumped the dt of data received and here is the result:

The upper plot represent the dt using the imuBosch_BNO055 attached to the pc104, the other one the imurfe using acquisitionRate = 10.

EDIT: these numbers have been taken from the iKinGazeCtrl, then the timestamp is the one set by the embObjIMU device, then not the one coming from the board.

cc @traversaro @pattacini

[Nicogene]

Today I performed a more accurate measure on iCubGenova02 of the performance of the imu-rfe dumping the timestamp coming from the board and here the result:

Plot

Histogram

[Nicogene]

For excluding any type of interference I performed the same test running only the device of the imu-rfe on iCubGenova02 and here the results:

Plot

Histogram

[marcoaccame]

OK @Nicogene, we shall investigate the problem together. I get in touch w/ you soon.

[Nicogene]

The results has been confirmed also on the minimal setup, ms board-rfe-laptop

We observed the same results also putting PC104RXrate to 1ms instead of 5ms, and TXrateOfRegularROPs to 1ms instead of 3ms

It seems that every ~250 samples(2.5 seconds) something happens

[Nicogene]

@triccyx and me extracted the statistics of the acquisition time of the CAN and here is the histogram(~ 2000 samples):

And here is the plot of the acquisition time:

[Nicogene]

Me @triccyx @marcoaccame and Giorgio Zini analyzed the behavior of the i2c bus of the rfe board, to which is attached the imu Bosch BNO055.

We measured with the oscilloscope the lines SCL(clock) the SDA(data), and the CAN channel that send the data to the mc4plus board as soon as the data is ready.

SCL periodicity

First of all we checked that the clock signal is raised up with a period of 10 ms as you can see from the following figure(yellow line).

CAN transmission

Then we checked that effectively the CAN(blue line) starts transmitting just after the end of the SCL signal(yellow line).

Zooming in it is possible to see that the delay between the end of the SCL and the start of CAN transmission is very little.

SCL variance

We verified that the clock signal is triggered every 10 ms, but we observed also the duration of this signal respect also to the SDA channel(blue line).
We observed that sometimes the data is ready and the acquisition from the imu lasts less, other times the clock is stretched for waiting the imu.

"Short" acquisition

"Long" acquisition

Conclusion

With the oscilloscope we observed the same time variability in the acquisition of the data through the i2c bus that we spotted with the various statistical analysis of the timestamp done at higher level.

I personally checked the functionality of software that uses the imu such as iKinGazeCtrl, wholeBodyDynamics and gravityCompensator and they work fine also with the imurfe.

We saw that the i2c speed of SCL on rfe board is the standard one (100 KHz), we don't know if the the i2c of the old imu attached of PC104 is set or not in fast mode(up to 400 KHz).
Increasing the speed could reduce the variability we observed, but probably it requires an analysis in the electronics (e.g. pull-up resistors etc).

Moreover we found out that probably the way the timestamp is take by the device of the old imu(see here) hides this variability of i2c bus.

If we are interested we can move that line and after the read function and measure again the timestamp of the old imu. Otherwise I think we can close this issue.

cc @pattacini @maggia80 @traversaro

[Nicogene]

We tested the performances of imurfe respect to the old imu bosch attached to the pc104 and we observed they behave in the same way.

This supports the hypothesis that the probably both have the same uncertainty in the i2c bus acquisition, but the old device driver "hides" this irregularity in the way it takes the timestamp.

Closing.