I have followed the steps of unit 3 to merge the odometry of the wheels and the IMU with AMCL. However, three problems occur:
- When AMCL rectifies the robot position, filtered odometry does not move with the robot. With “2D Pose Estimate” does not work either.
- Initially, the filtered odometry has an offset with respect to base_link
I do not know if errors are normal or am I doing something wrong. I am using the configuration proposed by the course and I simulated the robot locally and the results are the same. The steps to replicate my problem are:
- Download the package: package
- Place the robot at the point of spawn (reload simulation)
- roslaunch my_sumit_xl_tools global_localization.launch
- rosrun rviz rviz (select my_summit_rviz.rviz in the rviz folder)
- roslaunch summit_xl_gazebo keyboard_teleop.launch
- Move the robot
Note: to better appreciate problem 1 it is advisable to change the origin of the map to origin [-8.500000, -9.000000, 0.000000]
Thanks a lot fellows!
I’ve just tested this and verified that there’s something strange with the filtered odometry. Let me check this issue more in depth on Monday and I will provide a more detailed answer to you.
I’ve finally got the chance to have a good look to the issue, and here is what I found out:
First, there’s an error in the configuration file of the ekf node in the notebook. The topic where to get the odometry is not /odom, but /summit_xl/odom. The simulation has been recently updated and this topic has changed. So first thing, make sure that your configuration file has this correct.
Second, about the /odometry/filtered data, which is the result from combining the /summit_xl/odom with the IMU data, it doesn’t have any initial position information. If you check the matrix in the configuration file, you’ll see that the pose data (which is the first row) is set to false both for the odometry and the IMU. The IMU doesn’t provide any pose data at all, and for the odometry, we are just taking into consideration the velocities, which are the only values we can fuse with the IMU data. This makes sense and it is supposed to be like this.
However, this means that the /odometry/filtered data will always start at the [0,0] position. For this Chapter, though, the robot doesn’t start at the [0,0] position, which is causing all these offset errors. Then… how can you tell the /odometry/filtered topic where to actually start? Well, for this the robot_localization package provides a ROS Service named /set_pose. When launching the node, you can call this service in order to provide the actual initial pose of the robot. If you do this, everything should work properly. Below you can see an image where I was testing this:
I hope this post clarifies your doubts and solves your issues. Also, I will update the notebooks with all this information, so that future students don’t suffer these issues. If you have any other doubts, or you still get errors, don’t hesitate to let us know.