The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
However, the transform from map to odom drifts a lot
It should drift. How much is "a lot"? Your odom-frame state estimate will drift without bound. If that transform didn't drift, you'd have no need for a Tier 2 EKF. See REP-105.
I am trying to understand what is the map to odom transform doing, but I can't get the grasp of it
Your robot has two state estimates. One is in the odom frame, and one is in the map frame. The state estimates (at least the pose portions of them) are equivalent to the odom->base_link and map->base_link transforms. So after a few minutes, your pose in the odom frame might be at (10, 10) with a heading of pi / 4 radians. At the same time, your pose in the map frame might be (12, 11) with a heading of pi / 3 radians.
But ROS doesn't allow a frame to have two parents. You cannot have map->base_link and odom->base_link published in the same transform tree. To get around this, we compute the map->odom transform as
T_map_odom = T_map_base_link * T_odom_base_link ^ -1
This lets us have a single transform tree that has map->odom->base_link. This lets us still look up a transform from base_link to odom or from base_link to map.
Since your map and odom frame poses will not be the same, that transform will change over time.
I am currently starting the robot on the same marked spot on the ground and asking it to go to a fixed latitude and longitude, but the transforms to map coordinates changes every time
Does it change every time you give it a fixed lat/long within the same run? In other words, which if these are you doing?
navsat_transform_node, wait for transforms to get established. Give it a fixed lat/long, get map pose. Give it the same lat/long, get a different pose.navsat_transform_node, wait for transforms. Give it a fixed lat/long, get map pose. Stop software, start it again, wait for transforms. Give it the same lat/long, get a different pose.If it's (2), I would expect that, because GPS will drift, and your GPS coordinates when you start between any two runs will change. Your IMU can also drift, as magnetometers are notoriously terrible.
Is it OK to set the fixed frame to map for RViz visualization? Or should the fixed frame be odom?
That's up to you. Most people would visualize in the map frame if they have it, but it depends on what you want to see.
In what frame should I give move_base the points if I want to make a GPS waypoint follower?
In your case, you'd want to issue map-frame coordinates. The odom frame state estimate is subject to drift (again, see REP-105, as well as your config - you have only velocity data fused, which is correct, but integration of errors will lead to drift). So if you drive your robot to (10, 10) in the odom frame, and then drive it around a whole bunch, and then drive it back to (10, 10), the robot (in the real world) will not actually be in the same location, even though it thinks it is. However, that should generally not be true for the map frame. If you come back to the same position, the robot should actually be in the same position in the real world.
| | 2 | No.2 Revision |
However, the transform from map to odom drifts a lot
It should drift. How much is "a lot"? Your odom-frame state estimate will drift without bound. If that transform didn't drift, you'd have no need for a Tier 2 EKF. See REP-105.
I am trying to understand what is the map to odom transform doing, but I can't get the grasp of it
Your robot has two state estimates. One is in the odom frame, and one is in the map frame. The state estimates (at least the pose portions of them) are equivalent to the odom->base_link and map->base_link transforms. So after a few minutes, your pose in the odom frame might be at (10, 10) with a heading of pi / 4 radians. At the same time, your pose in the map frame might be (12, 11) with a heading of pi / 3 radians.
But ROS doesn't allow a frame to have two parents. You cannot have map->base_link and odom->base_link published in the same transform tree. To get around this, we compute the map->odom transform as
T_map_odom = T_map_base_link * T_odom_base_link ^ -1
This lets us have a single transform tree that has map->odom->base_link. This lets us still look up a transform from base_link to odom or from base_link to map.
Since your map and odom frame poses will not be the same, that transform will change over time.
I am currently starting the robot on the same marked spot on the ground and asking it to go to a fixed latitude and longitude, but the transforms to map coordinates changes every time
Does it change every time you give it a fixed lat/long within the same run? In other words, which if of these are you doing?
navsat_transform_node, wait for transforms to get established. Give it a fixed lat/long, get map pose. Give it the same lat/long, get a different pose.navsat_transform_node, wait for transforms. Give it a fixed lat/long, get map pose. Stop software, start it again, wait for transforms. Give it the same lat/long, get a different pose.If it's (2), I would expect that, because GPS will drift, and your GPS coordinates when you start between any two runs will change. Your IMU can also drift, as magnetometers are notoriously terrible.
Is it OK to set the fixed frame to map for RViz visualization? Or should the fixed frame be odom?
That's up to you. Most people would visualize in the map frame if they have it, but it depends on what you want to see.
In what frame should I give move_base the points if I want to make a GPS waypoint follower?
In your case, you'd want to issue map-frame coordinates. The odom frame state estimate is subject to drift (again, see REP-105, as well as your config - you have only velocity data fused, which is correct, but integration of errors will lead to drift). So if you drive your robot to (10, 10) in the odom frame, and then drive it around a whole bunch, and then drive it back to (10, 10), the robot (in the real world) will not actually be in the same location, even though it thinks it is. However, that should generally not be true for the map frame. If you come back to the same position, the robot should actually be in the same position in the real world.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.