DLu
commented
3 years ago Closing in favor of the discussion here: https://answers.ros.org/question/367962/move_base-local-planner-deviates-significantly-from-global-planner-path/
Closed derektan95 closed 3 years ago
DLu
commented
3 years ago Closing in favor of the discussion here: https://answers.ros.org/question/367962/move_base-local-planner-deviates-significantly-from-global-planner-path/
Hi ROS community,
I am in need for some help with a project involving the use of move_base package with Ubuntu 16.04, ROS Kinetic. I have looked through most of the other issues with move_base that others have faced, but I did not encounter any similar issues in the forum. Help is greatly appreciated!
I am currently running this on a robot dog which I recently owned (Unitree A1). This robot has an internal IMU which allows me to derive odometry base_link - odom tf as well as to publish ‘/odom’ message, using this ROS tutorial here (link). In fact, I used this, along with laserscan from a 2D Lidar, for HectorSLAM and AMCL package and it worked well. I am also able to teleops the robot dog using the Teleops Twist Keyboard package. Here is a rough image of the tf of the system (Note: This is not the latest diagram. I have attempted to keep all nodes publishing at 10Hz).
tf frames: https://drive.google.com/file/d/1mC1M4bUQD_Oex7u7pYbn0kgCXHMigf9E/view?usp=sharing
Successful AMCL video using teleops: https://youtu.be/BET4nThOA5E
I have spent a long time attempting to tune the move_base parameters for this package. While the global planner seems to do its job of planning a relatively straight path from start to goal pose, the local planner is causing the robot to move in very unpredictable manner, often deviating from the global path. Here are some videos of RVIZ describing the issue. I have mapped an office environment using a RPLidar, and have initialized the AMCL package with origin: x=0, y=0, theta=0 (At the origin where I started mapping, facing Eastwards). In all of these videos, the arrows corresponds well with the real (observed) location of the robot. The video is lagging because I am viewing rviz on my personal laptop, remotely from the ROS nodes running in the robots.
Failed Attempt 1: https://youtu.be/zjztpArHyRk As you could notice, the robot seem to do wierd rotations at the starting pose before hitting a dead-end that is deviating even further from the goal pose.
Failed Attempt 2: https://youtu.be/CUEi0Uyg1lg You would notice that the robot spins off the path and faces a wall again.
Successful Attempt 3: https://youtu.be/IDlVw3i-xfI Out of about many attempts today, only 1 of them seem to work relatively well. Even so, it seems to deviate from the goal pose once it is close to it.
I have looked through most of the other posts regarding issues with move_base. There was a post explaining how to resolve the issue of robots moving in random circles (link). However from the 2nd video (failed attempt), you could see that I displayed the axis for map coordinate system. I have looked through the coordinate system for odom, base_link and laser, and all of them are facing the same way (x facing Eastwards, y facing northwards, z facing out of the plane). So this ensures that my robot’s base_link tf is oriented in the right direction.
In addition, I made sure that the odom message derived from IMU correlates with the ‘/dog_cmd_vel’ sent by the move_base node well. I have also looked through other common troubleshooting guides (troubleshooting guide) but failed to derive anything meaningful to it. I have also attempted to use DWA Planner instead of the default trajectory planner but to no avail.
I wonder if anyone has any other insights to this issue? Would be great if we could consider potential issues which I may have overlooked. Help is greatly appreciated, thank you very much.
move_base.launch