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]]
#transform_tolerance: 0.5

global_frame: /map
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.

edit retag close merge delete

"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?

( 2019-06-16 13:52:54 -0500 )edit

@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?

( 2019-06-17 05:11:23 -0500 )edit

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.

( 2019-06-22 18:38:16 -0500 )edit

@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?

( 2019-06-24 05:49:38 -0500 )edit

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.

( 2019-06-24 17:45:15 -0500 )edit