robotology/event-driven

Update import/export of IMU events in Python scripts

aikolina opened this issue · 6 comments

aikolina commented

Description

An IMU event is encoded in 32 bits as follows:

RRRR RRRR TCRR SSSS VVVV VVVV VVVV VVVV

where

  • R is a reserved bit,
  • T indicates the type of event (in this case T = 1),
  • S indicates the sensor type (i.e. accelerometer, gyroscope, magnetometer or thermometer), and
  • V is the value assumed by the sensor.

At the current status, IMU events are imported from a *YARP .log file into a Python dictionary with the following keys:

ts acc angV temp mag tsOffset

where acc=[accX accY accZ], ang=[angX angY angZ]and mag=[magX magY magZ].
Therefore, a single timestamp ts is associated with all sensors types measurements.

However, by doing so, we lose the timestamp information associated with a single sensor measurement. This is also going to affect the export process which will contain incorrect timestamp information.

So, I suggest to keep the original encoding format and import the IMU events into a dictionary with the following keys:

ts sensor value tsOffset

Files to be updated:

simbamford commented

Hi Aiko,

Sorry I dropped the ball on this. Also happy new year.

It's not clear to me from a brief look at the datasheet (http://www.invensense.com/wp-content/uploads/2017/07/DS-000179-ICM-20648-v1.2-TYP.pdf) what the relationship is between the timestamp of the readout and the time to which the reading refers. Certainly my code contains an assumption that all the serial readouts are referred to a single time, which doesn't appear to be justified.

One way to resolve this is to have a "sample" datatype, which is simply what you get from importing the samples in order and prior to the function which converts sets of samples into IMU readings. One could even allow both the "sample" datatype and the "imu" datatype to coexist.

But perhaps the first thing is to get more clarity on what the timing of the sensor signal is. It seems that preserving the readout timestamp gets you closer to the real time of the sample - is it possible to do better than that? I see for example these DELAY_TIMEH DELAY_TIMEL values - perhaps Maurizio could help to shed more light on it?

aikolina commented

Happy new year to you too, Sim! 🎉 😸

What I need for my current task is the "sample" datatype, so that I can process the IMU data offline as a YARP module would do when reading the IMU data online.

In my opinion, having only the "sample" datatype would be sufficient since it directly reflects the raw data. Do you think it would be better to keep both datatypes?

I didn't go into the details of the IMU datasheet, so I don't know if it's worth investigating the values DELAY_TIMEH and DELAY_TIMEL for getting better timestamps. But if that's the case, I think there might be the need to check how the timestamp is handled at a lower level. So I guess we should check zynqgrabber.

simbamford commented

Okay - I've just commited to the python-dev branch - now if you add the flag convertSamplesToImu=False, like this:
imported = importIitYarp(filePathOrName=filePathOrName, convertSamplesToImu=False)
Then it will leave a "sample" datatype in the channel dictionary rather than converting this to IMU. I've left conversion to IMU as the default behaviour because this puts the output in the same format as the import from ROS. I'll leave this issue open because I would still like to understand what is the reality of the timings from the IMU.

  • 👍1
arrenglover commented

@simbamford I think this issue can be closed now right?

simbamford commented