Strange movement with hector_navigation

asked 2019-06-15 09:39:58 -0500

ford_prefect gravatar image

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.

edit retag flag offensive close merge delete

Comments

"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 gravatar imagebilly ( 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?

ford_prefect gravatar imageford_prefect ( 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.

billy gravatar imagebilly ( 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?

ford_prefect gravatar imageford_prefect ( 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.

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