Revision history - ROS Answers: Open Source Q&A Forum

I still don't see a picture, but there are three coordinate frames, all of which are specified by REP-105. See the description of the frame parameters here.

EDIT: Just so I understand, are you trying to use AMCL and a GPS?

I still don't see a picture, but there are three coordinate frames, all of which are specified by REP-105. See the description of the frame parameters here.

EDIT: Just so I understand, are you trying to use AMCL and a GPS?

EDIT 2: Not sure how you're planning to combine AMCL and the GPS-enabled instance of ekf_localization_node, but here is how the data is meant to flow, at least as far as robot_localization is concerned:

image description

Your launch files for your two instances of ekf_localization_node should be very similar, except in the second one, you'll have your world_frame set to map instead of odom, and you'll have a new input source (the GPS odometry coming from navsat_transform_node).

I still don't see a picture, but there are three coordinate frames, all of which are specified by REP-105. See the description of the frame parameters here.

EDIT: Just so I understand, are you trying to use AMCL and a GPS?

EDIT 2: Not sure how you're planning to combine AMCL and the GPS-enabled instance of ekf_localization_node, but here is how the data is meant to flow, at least as far as robot_localization is concerned:

image description

Your launch files for your two instances of ekf_localization_node should be very similar, except in the second one, you'll have your world_frame set to map instead of odom, and you'll have a new input source (the GPS odometry coming from navsat_transform_node).

EDIT in response to comment below: No, that's not what I meant, sorry. First, I'm guessing that amcl should receive the output of your odom instance of ekf_localization_node, not the map instance. Second, if you look at my drawing, you'll see a difference in the way the sensor data is being used. In your drawing, you are only feeding the raw odometry and IMU to one instance of ekf_localization_node. In my drawing, both instances work with the raw data. Don't feed the output of ekf_localization_node's odom instance into the map instance.

I still don't see a picture, but there are three coordinate frames, all of which are specified by REP-105. See the description of the frame parameters here.

EDIT: Just so I understand, are you trying to use AMCL and a GPS?

EDIT 2: Not sure how you're planning to combine AMCL and the GPS-enabled instance of ekf_localization_node, but here is how the data is meant to flow, at least as far as robot_localization is concerned:

image description

Your launch files for your two instances of ekf_localization_node should be very similar, except in the second one, you'll have your world_frame set to map instead of odom, and you'll have a new input source (the GPS odometry coming from navsat_transform_node).

EDIT in response to comment below: No, that's not what I meant, sorry. First, I'm guessing that amcl should receive the output of your odom instance of ekf_localization_node, not the map instance. Second, if you look at my drawing, you'll see a difference in the way the sensor data is being used. In your drawing, you are only feeding the raw odometry and IMU to one instance of ekf_localization_node. In my drawing, both instances work with the raw data. Don't feed the output of ekf_localization_node's odom instance into the map instance.

EDIT in response to comment: Yeah, I'm aware that reparenting would be an issue. I'm advocating that he drop the GPS instance of ekf_localization_node. amcl's handling of transforms (compute map->base_link, listen for odom->base_link, use that to compute and publish map->odom) is identical to that of robot_localization's state estimation nodes when world_frame == map_frame.

In any case, the setup should work as-is (provided the sensor data is fed into the map1 instance of ekf_localization_node), yes. However, I don't know if there are any implications within amcl if the map1->base_link transform has any discontinuities. Perhaps there are none.

Revision history [back]