ZacharyTaylor
commented
6 years ago While these systems are sensitive to time-stamping I think once you are down to the kHz range you really hit diminishing returns in your accuracy gains. @bloesch could probably advise you better however in section 5.3 of the rovio ijrr journal it is stated that in rovio the IMU prediction step is simply based on the average value of the IMU readings between two images and so weather an IMU is sampled at 100 Hz or 1000 Hz is probably not going to make any real difference.
The only place it would probably be important is for sudden shocks, however I have only really used these approaches on aerial systems where this isn't an issue. When we do do IMU integration on these platforms and make direct use of the resulting prediction for control (such as in piping MSF into our MPC) we typically heavily filter the IMU. This induces some small delay, however this is not a huge issue as the system itself takes some time to react to disturbances. The filtering is also needed as the motors usually induce at least 2 ms^2 of noise which if unfiltered plays havoc with our velocity estimates.
As for what timestamp to give, giving the stamp of the last measurement makes the most sense to me as in any other case you would be incorporating future information. This could give unexpected results if for example your IMU read a large shock near the end of the sampling period.
bloesch
Overview and Motivation
Consumer inertial sensors today are capable of sampling at high rates (4-8 kHz). However, it is not possible to use all of the raw data without suitably lowering the rate first. It is indeed preferable to run sensors at kHz sample rate and then integrate the raw measurements (e.g using a trapezoidal integrator) down to whatever rate is necessary for inertial filter prediction. Running at the highest possible internal sample rate of the sensor also necessarily implies disabling all on-chip DLPFs. This allows us to :
For this example case, let's talk about using the IMU data from a Pixhawk autopilot (running PX4) using a cheap ICM-20689 accel/gyro chip. Currently, the sensor signal processing chain for PX4 looks something like this :
Timestamping
My question is - what is expected in terms of time-stamping, especially given that the data is integrated down to 250Hz. Should the timestamp be at the start of the integration frame, the middle, or the end?
Currently it is at the end, but this is most likely not optimal given how the integrated measurement is divided by the delta time to get a "mean" sample to send to Rovio. On the other hand, the end timestamp makes sense for the delta angles/velocities, since it intuitively means the delta angle/velocity as of that time.
The VI-Sensor seems to timestamp the beginning of the IMU sample, but I'm only basing this on the diagram in the original paper. If someone could confirm this, it would be great.
Integrated values (Delta angle, delta velocity)
A step further would be to actually discuss feeding Rovio directly with the pre-integrated delta angle and delta velocity measurements in order to not "lose" information in dividing by the delta time (see step 4 of signal processing chain above). This is sensible since the Rovio filter must integrate IMU samples between image frames internally in order to produce the attitude estimate.
I haven't dug very deep, but it seems like the change wouldn't be massive, once we figure out the correct timestamp for the integrated sample. https://bitbucket.org/bloesch/lightweight_filtering/src/0c8517a5eb19a00a4f8d36dac4ffdc45dac6a363/include/lightweight_filtering/Prediction.hpp#lines-138:157
@bloesch @helenol @ZacharyTaylor Your guidance on these matters would be appreciated!
@bresch @RomanBapst FYI.