ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A answers.ros.org
Ask Your Question
2

Fusion of odometry from different sourses

asked 2016-12-05 22:14:37 -0600

shashank gravatar image

I have three different sensor generating odometry . The three sources are 1. laser 2. Wheel 3. camera i want to fuse these odometry using robot localization package .

Do the fame_id of the all the sources generating odometry be parent odom child base_link or it should be different for different source ( odom_laser-->base_link) ?

edit retag flag offensive close merge delete

Comments

Missing details to answer: The point of the whole tf tree is to link the different objects (e.g. sensors) together. One sensor could be e.g. rotated by 90° or placed 1m away. The tf then needs to reflect that.

Humpelstilzchen gravatar image Humpelstilzchen  ( 2016-12-06 03:09:40 -0600 )edit

1 Answer

Sort by » oldest newest most voted
2

answered 2016-12-06 17:30:15 -0600

paulbovbel gravatar image

updated 2016-12-06 18:14:23 -0600

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...

edit flag offensive delete link more

Comments

according to my understanding your are saying that my frame ids should be ( base_link-->laser_odom , base_link--> camera_odom, base_link-->wheel_odom) . The ekf_localization should publish me odom-->base_link. Am i correct ???

shashank gravatar image shashank  ( 2016-12-07 02:22:32 -0600 )edit

that's correct

paulbovbel gravatar image paulbovbel  ( 2016-12-07 07:33:53 -0600 )edit
1

Note that the odometry messages/inputs can have the same frame_id, but unless the measurements are in agreement with each other (e.g., odom0 and odom1 both provide measurements that don't diverge), it's going to produce ugly results. I try to stick to one pose and N velocity inputs.

Tom Moore gravatar image Tom Moore  ( 2016-12-19 03:49:21 -0600 )edit

So u are saying i should choose the pose input from the most reliable source of odometry(say laser odometry) and for rest odometry (camera,wheel) source i should only choose twist(velocity) messages and omit out pose. Am i correct??

shashank gravatar image shashank  ( 2016-12-19 23:13:27 -0600 )edit

Yes, correct.

Tom Moore gravatar image Tom Moore  ( 2017-01-04 02:33:59 -0600 )edit

I have the same confusion. As per the comments, did you set the frames laser_odom , camera_odom and wheel_odom as the children of base_link ? That cant work for me because these are the fixed frames..

Abdur gravatar image Abdur  ( 2022-03-31 06:22:36 -0600 )edit

If those frames are from sensors that are onboard the robot, then yes, they should be children of base_link. If they come from an external reference like a motion capture system, they would not be. You'd want a transform from your EKF world frame directly to that frame.

Note that the case of pose data that is being generated from a sensor onboard the robot where the sensor is not aligned with the vehicle origin is not well supported, but will be once this PR is merged. Then you can do something different: make the child_frame_id in the odom message your sensor frame (e.g., camera_odom) and set odomN_pose_use_child_frame to true, and then also set odomN_differential to true.

Tom Moore gravatar image Tom Moore  ( 2022-04-14 02:46:06 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2016-12-05 22:14:37 -0600

Seen: 1,655 times

Last updated: Dec 06 '16