robot_localization
I've seen the package has changed a lot since I used it the last time.
I have a doubt: Is it correct the structure shown in the picture (with two map frames)?
ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
I've seen the package has changed a lot since I used it the last time.
I have a doubt: Is it correct the structure shown in the picture (with two map frames)?
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:
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.
I Know it. Maybe you can see the picture with its link http://s18.postimg.org/ig947a8d4/robo...
Actually, AMCL computes the localization on base_link, and then publishes the transformation between that localization (in the frame global_frame_id
) and wathever frame is passed as odom_frame_id
. I guess that using /map1
as odom_frame_id
is correct, otherwise /odom
would have two parents.
Asked: 2015-01-14 13:15:49 -0500
Seen: 1,403 times
Last updated: Jan 27 '15
Did you post an image? I don't see one. Sorry, I don't currently have a laptop with me and am viewing this on a mobile phone.