Revision history [back]

This is really interesting. However, it seems you are not the first person to ask regarding the +9.81 for an ENU facing IMU. Have a look here and here for the detailed answer. It seems that IMUs do not report the actual gravitational acceleration but rather:

the accelerometers measure the difference between the actual acceleration of the sensor with respect to any inertial frame and the gravitational acceleration: a_accelerometer = a_sensorFrame − g

So this will explain why this is still a right handed coordinate system with ENU convention.

Regarding your second question, yes, Robot_Localization will handle the different time delays of its input sources. All the message types have a "header" field which is populated with time stamp information. More crucially, be very careful to ensure that the covariances reported by both your camera estimate and the IMU is sensible. It would be even better if the manufacterer can provide the covariance matrix. An incorrect or inaccurate covariance matrix is another huge source of problem for those who work with robot_localization.

Another crucial thing is to ensure that the data sources are reliable in the sense that they will periodically update (within some reasonable time frame). If, for example, robot_localization does not receive data for say 10-20seconds, the odometry estimate can also explode and may not recover even if data comes back on after that. There are also a lot of other little caveats that you may miss that can cause the odometry estimate to explode, and the robot_localization guide has provided some examples.

Hope this helps.