Odom frame initialized at 180 degrees to base_link

asked 2021-06-03 22:52:12 -0500

AnAssortmentOfAtoms gravatar image


New to ROS, I am trying to build a map using lidar while driving my omni-directional robot around. Having issue with the /odom frame initializing in a position that is rotated by 180 degrees around the the X-axis relative to /base_link and /map frames. Unfortunately being a new forum user I don’t have enough karma to post a screenshot of rviz to provide extra information.

When the robot drives in the X-axis a map is built as expected with subsequent laser scans being stiched together. However when driven in the Y-axis, because of the rotated /odom frame, the map “staggers”, superimposing elements of the building in the wrong position on the Y-axis, I believe this is because slam_toolbox expects the robot to be moving in the opposite direction than it really is and the toolbox is trying to match any features from the lidar it can. The /odom frame can also be seen in rviz drifting away from the origin in the Y axis instead of staying in the same place as it should be expected (ignoring the small amount of drift from accumulated error in odometry).

See my launch file, URDF, and odometry publisher file below. At present /odom is calculated based on the /cmd_vel message. I know this is a crude approximation compared to encoders or an IMU; I haven’t had the chance to implement them yet.

I would like to isolate the reason that /odom is initialized at 180 degrees to /base_link and /map. All other frames (laser, base_link, map, base_footprint) are consistent with REP103/105

I have poured over my code looking for a missing 180-rotation but my understanding is that slam_toolbox publishes the map->odom transformation and this appears to be confirmed when I run the command

ros2 run tf2_ros tf2_echo map odom

I get:

At time 1622759069.311130383
- Translation: [0.000, 0.000, 0.000]
- Rotation: in Quaternion [1.000, 0.000, 0.000, 0.000]

Which in Euler angles corresponds to a 180 degree rotation about the X axis. So this suggests to me that the 180-rotation is coming from slam_toolbox; is there some way to initialize the /odom frame to have the same orientation as the /map frame?

I did find one proposed solution that suggests running

ros2 topic pub /set_pose geometry_msgs/PoseWithCovarianceStamped '{header: {stamp: {sec: 0, nanosec: 0}, frame_id: "odom"}, pose: {pose: {position: {x: 0.0, y: 0.0, z: 0.0}, orientation: {x: 0.0, y: 0.0, z: 0.0, w: 0.0} }, covariance: [1,0,0,0,0,0,0,1,0,0,0,0,0,0,1,0,0,0,0,0,0,1,0,0,0,0,0,0,1,0,0,0,0,0,0,1]}}'

However this did not change the /odom frame at all (regardless of what pose/orientation I chose).

For context the robot is a 3 wheel omni-directional robot running on a Raspberry Pi 4, Ubuntu 20.04, ROS 2 Foxy. Using slam_toolbox, rplidar_ros, and teleop_twist_joy packages.

odometry_node.py ... (more)

edit retag flag offensive close merge delete


why did you change x to y (self.vx = msg.linear.y )?

Nachum gravatar image Nachum  ( 2021-12-12 02:57:21 -0500 )edit