Revision history [back]

This is tricky because if you're fusing N>1 Odometry messages, each Odometry needs a unique frame for header.frame_id.

Since frames can only have one parent, these frames typically end up children of base_link, while the fused odom frame broadcast by robot_localization ends up the parent of base_link.

Another approach may be to have your sensors publish TwistWithCovarianceStamped, which will be transformed to the local frame of the vehicle and does not require a distinct coordinate frame.

See http://docs.ros.org/kinetic/api/robot_localization/html/preparing_sensor_data.html

This is tricky because if you're fusing N>1 Odometry messages, each Odometry needs a unique frame for header.frame_id.

Since frames can only have one parent, these frames typically end up children of base_link, and must be broadcast by your components, while the fused odom frame broadcast by robot_localization ends up the parent of base_link.

Another approach may be to have your sensors publish TwistWithCovarianceStamped, which will be transformed to the local frame of the vehicle and does not require a distinct coordinate frame.

See http://docs.ros.org/kinetic/api/robot_localization/html/preparing_sensor_data.html

This is tricky because if you're fusing N>1 Odometry messages, each Odometry needs a unique frame for header.frame_id.

Since frames can only have one parent, these frames (such as the proposed odom_laser) typically end up children of base_link, and must be broadcast by your components, while the fused odom frame broadcast by robot_localization ends up the parent of base_link.

Another approach may be to have your sensors publish TwistWithCovarianceStamped, which will be transformed to the local frame of the vehicle and does not require a distinct coordinate frame.

See http://docs.ros.org/kinetic/api/robot_localization/html/preparing_sensor_data.html