Strange movement with hector_navigation
Hello there!
Me and my team are trying to get a mobile robot running for autonomous exploration. Since the only sensor we have available is a Lidar sensor (RPLIDAR A2), we went with Hector SLAM(http://wiki.ros.org/hector_slam), because it requires no additional sensors.
Mapping works great, all obstacles are being mapped accordingly, the robot pose is also okay. However, when we try to do navigation, we get some strange results. We are using the Hector Navigationpackage (http://wiki.ros.org/hector_navigation) - more specifically, the hector_exploration_node and the simple_exploration_controller. The path gets computed fine, and velocity commands get published (which we then process through our own Motor Controller node).
However, the robot keeps moving back and forth all the time - it eventually reaches the goal, but it is constantly moving back and forth. Our costmap (edited the one that comes with the package) is as follows:
global_costmap:
map_type: costmap
track_unknown_space: true
unknown_cost_value: 255
obstacle_range: 2.5
raytrace_range: 3.0
footprint: [[0.18, 0.15],
[-0.18, 0.15],
[-0.18, -0.15],
[0.18, -0.15]]
inflation_radius: 0.32
#transform_tolerance: 0.5
inscribed_radius: 0.15
circumscribed_radius: 0.24
global_frame: /map
robot_base_frame: /base_link
update_frequency: 0.5
publish_frequency: 0.1
static_map: true
rolling_window: false
#Investigate what this actually does
cost_scaling_factor: 10.0
We modified the parameters of the costmap that came with hector_navigation to fit our mobile base (modified: footprint, inscribed_radius, and curcumscribed_radius). We looked at the code in hector_navigation and really have no idea what the cause for this behavior is.
The rest of the hardware used is:
- Lynxmotion Aluminum A4WD1 Rover Kit
Sabertooth Dual 12A 6V-24V R/C Regenerative Motor Driver
Did anyone else have this problem? How do we get the robot to simply move along the path, instead of going back and forth before eventually reaching the goal? Could it be that it is due to limited hardware?
Additional information that could be useful:
- We are using ROS Kinetic on an NVidia Jetson TX2 board
- Turning works perfectly - as soon as a new path is computed, the robot turns into the desired direction. It is only linear movement that causes the back-and-forth motion.
We can provide any additional info if needed.
"It is only linear movement that causes the back-and-forth motion."
"Linear" "back-and-forth" means it moves forwards, then backs up, then forward again? Is it possible that the math in your control node has an error that sets speed higher than requested by Hector?
@billy
Yes, it moves forwards, then it backs up, then it moves forwards again, and so on. The math in the control node is correct as we checked it multiple times and tested it with manual driving. However, the motor driver we are using (Sabertooth Dual) is not very precise, so it could be that the end result that is sent to the motors is different - maybe this is something that is wrong with the hardware (i.e. the motor driver not being good enough) so it can't be fixed?
If you're still working on this issue, monitor the cmd_vel topic and find out if move_base is issuing commands and robot is following them, or if robot is doing it on it's own.
@billy We monitored the cmd_vel topic, the commands issued correspond to the movement of the robot. But we do think that the robot is not moving precise enough, e.g. the command being 0.35 m/s linear, and the robot moving 0.45 or 0.5 m/s. This is most probably a hardware issue with the motor driver, right?
Could be hw. Could be tuning. I have no way to know but if it is hw it would interesting that both channels have same issue. Maybe driver lacks power.
Hi, I have this issue as well. The robot doesn't follow the path!
Hi @ford_prefect , I am also having the same exact problem, may I check if you managed to solve this problem?
Hi @jjbecomespheh , We did manage to solve the problem. There were actually a few issues present. First, we had some reflective surfaces in the area, which caused the sensor to deliver imprecise readings. Secondly, the configuration for the parameters of navigation was too strict (even diverting a cm from the path would be seen as an error, and the robot would try to fix that by going backwards). Lastly, we got a bigger power supply (battery) for our motor controller, which in turn resulted in more precise messages to be sent to the DC motors. We are not aware which of these 3 issues has caused the initial behavior, but I hope this can help you out. As far as I am concerned, this question can be locked.