Reference frames in robot_localization

asked 2020-04-13 06:06:28 -0600

Aquas
32 ●6 ●7 ●11

updated 2020-04-13 06:09:12 -0600

Hello! I've got a couple of questions:

I've been reading robot_localization documentation (http://docs.ros.org/melodic/api/robot...) and I've seen that they only use North-East-Up references:

As of this writing, robot_localization assumes an ENU frame for all IMU data, and does not work with NED frame data. This may change in the future, but for now, users should ensure that data is transformed to the ENU frame before using it with any node in robot_localization.

Nontheless, in that same page, if you look at IMU information, they say:

The state estimation nodes in robot_localization assume that an IMU that is placed in its neutral right-side-up position on a flat surface will: Measure +9.81 meters per second squared for the Z axis.

In that case, if gravity is possitive, the Z vector is pointing down. Isn't this the opposite of what was stated above? Should my IMU gravity component be positive(NED) or negative(ENU)?

.2 I am measuring the variation of the angles and the movement from images taken from the bottom camera of a UAV and fusing them with the IMU. IMU updates values each 2.5ms and the information from the image is extracted each ~100ms, so the pose information from the camera is given with respect to the previous frame (~100ms ago). Does the robot_localization takes into account that pose values are with respect to the previous meassure given by that sensor, or should I change something?

Thank you in advance.

answered 2020-04-13 07:28:51 -0600

hashirzahir
228 ●1 ●14 ●7

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.

edit flag offensive delete link

Comments

Thank you very much!!! I guess that if it's me the one that creates the pose estimation from the camera, I should estimate its covariance matrix too, am I not?

Aquas ( 2020-04-14 04:49:27 -0600 )edit

Yes, if it is an estimate provided by your algorithm, you need a method to estimate the covariance matrix for every pose estimate given by your algorithm (i.e. ideally it is a dynamic covariance estimate, perhaps based on the quality of data you get).

hashirzahir ( 2020-04-14 08:26:09 -0600 )edit

add a comment

Reference frames in robot_localization

1 Answer

Comments

Question Tools

Stats

Related questions

Reference frames in robot_localization edit

1 Answer

Comments

Question Tools

Stats

Related questions

Reference frames in robot_localization