0
$\begingroup$

Rosanswers logo

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: 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. There is a lag seen because I am viewing RViz on a server that is remote from the robot.

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 

<!-- MOVE BASE node: Specify goal position on map for bot to navigate to. Includes path planning module. -->
<node name="move_base" pkg="move_base" type="move_base" respawn="false" output="screen">
    <remap from="scan" to="/scan_filtered"/>
    <remap from="cmd_vel" to="/dog_cmd_vel"/>
    <param name="base_global_planner" value="navfn/NavfnROS" />
    <param name="base_local_planner" value="base_local_planner/TrajectoryPlannerROS"/> -->

    <!-- Load Config files -->
    <rosparam file="$(find my_robot_nav)/config/costmap_common_params.yaml" command="load" ns="global_costmap" />
    <rosparam file="$(find my_robot_nav)/config/costmap_common_params.yaml" command="load" ns="local_costmap" />
    <rosparam file="$(find my_robot_nav)/config/local_costmap_params.yaml" command="load" />
    <rosparam file="$(find my_robot_nav)/config/global_costmap_params.yaml" command="load" />
    <rosparam file="$(find my_robot_nav)/config/base_local_planner_params.yaml" command="load" />
</node>
</launch>

base_local_planner_params.yaml

 controller_frequency: 10

 TrajectoryPlannerROS:

  # Robot Config Params
  acc_lim_x: 0.1
  acc_lim_y: 0.1
  acc_lim_theta: 0.05
  max_vel_x: 0.2 
  min_vel_x: 0.1 
  max_vel_theta: 0.1
  min_vel_theta: -0.1
  min_in_place_vel_theta: 0.0   # 0.2
  escape_vel: -0.1
  holonomic_robot: false
  # y_vels: [-0.2, -0.1, 0.1, 0.2]

 # Goal Tolerance Params
 yaw_goal_tolerance: 0.2
 xy_goal_tolerance: 0.1
 latch_xy_goal_tolerance: false

 # Forward Simulation Params
 sim_time: 1.0
 sim_granularity: 0.025
 angular_sim_granularity: 0.025
 vx_samples: 5.0
 vtheta_samples: 20.0

 # Trajectory Scoring Params
 pdist_scale: 0.3            # 0.6
 gdist_scale: 0.8 
 occdist_scale: 0.02

costmap_local_params.yaml

map_type: costmap

obstacle_range: 2.0 
raytrace_range: 3.0 
transform_tolerance: 0.5 
robot_radius: 0.25 
inflation_radius: 0.3 
cost_scaling_factor: 1.0
observation_sources: laser_scan_sensor
laser_scan_sensor: {sensor_frame: laser, data_type: LaserScan, topic: /scan_filtered, marking: true, clearing: true}

global_costmap_params:

global_costmap:
global_frame: map
robot_base_frame: base_link
update_frequency: 5.0
publish_frequency: 5.0
width: 20.0
height: 20.0
resolution: 0.05
static_map: true
rolling_window: false

local_costmap_params.yaml

local_costmap:
global_frame: odom   #odom
robot_base_frame: base_link
update_frequency: 5.0
publish_frequency: 5.0
width: 10.0
height: 10.0
resolution: 0.05
static_map: false
rolling_window: true

amcl.launch

<launch>
<!-- MAP SERVER node: locate map and send out map data for localization  -->
<arg name="map_file" default="$(find my_robot_nav)/maps/stels_office_lvl3.yaml"/>
<node name="map_server" pkg="map_server" type="map_server" args="$(arg map_file)" />

<!-- Adaptive Monte Carlos Localization (AMCL) node: Subscribe to topics for localization  -->
<node name="amcl" pkg="amcl" type="amcl" output="screen">
    <remap from="scan" to="/scan_filtered"/>
    <param name="base_frame_id" value="base_link"/>
    <param name="odom_frame_id" value="odom"/>
    <param name="global_frame_id" value="map"/>

    <!-- If you choose to define initial pose here -->
    <param name="initial_pose_x" value="0"/>      <!--Center of Map-->
    <param name="initial_pose_y" value="0"/>      <!--Center of Map-->
    <param name="initial_pose_a" value="0"/>      <!--Center of Map-->
    <param name="initial_cov_xx" value="0.05*0.05"/>      
    <param name="initial_cov_yy" value="0.05*0.05"/>      
    <param name="initial_cov_aa" value="(3.14/192)*(3.14/192)"/>     
     <!--<param name="initial_cov_xx" value="0.25*0.25"/>      -->
     <!--<param name="initial_cov_yy" value="0.25*0.25"/>      -->
     <!--<param name="initial_cov_aa" value="(3.14/24)*(3.14/24)"/>       -->

    <!-- Limits on particles used in AMCL -->
    <param name="min_particles" value="50"/>
    <param name="max_particles" value="1000"/>

    <!-- AMCL Update Rate (d = translational, a = rotational) -->
    <param name="update_min_d" value="0.001"/>
    <param name="update_min_a" value="0.001"/>
    <!-- <param name="update_min_d" value="0.01"/> -->
    <!-- <param name="update_min_a" value="0.01"/> -->

    <!-- Laser settings -->
    <param name="laser_min_range" value="-1.0"/>        <!-- Use LaserScan Msg's min range -->
    <param name="laser_max_range" value="-1.0"/>        <!-- Use LaserScan Msg's max range -->
    <param name="laser_min_beams" value="30"/>
    <param name="laser_z_hit" value="0.95"/>
    <param name="laser_z_rand" value="0.05"/>
    <param name="laser_model_type" value="likelihood_field"/>

    <!-- Odometry Settings - alpha = noise error (Assume ~0.5cm error) -->
    <param name="odom_model_type" value="diff-corrected"/>
    <param name="odom_alpha1" value="0.005"/>
    <param name="odom_alpha2" value="0.005"/>
    <param name="odom_alpha3" value="0.005"/>
    <param name="odom_alpha4" value="0.005"/>
    
</node>

Originally posted by tootyboi95 on ROS Answers with karma: 21 on 2020-12-17

Post score: 2

Improve this question
$\endgroup$

2 Answers 2

Reset to default
0
$\begingroup$

Rosanswers logo

I'd like to comment on something that caught my attention.

vx_samples and vtheta_samples are real numbers, but they should be parameters that take integers. It may be that move_base is not interpreting the parameters properly.

I think acc_lim_theta, max_vel_theta, and min_vel_theta are too small. You may not be able to generate the angular velocity needed to turn.

Originally posted by miura with karma: 1908 on 2020-12-30

This answer was NOT ACCEPTED on the original site

Post score: 1

Original comments

Comment by tootyboi on 2021-01-01:
Hi Muira, thanks for your feedback! I eventually came to realize that the robot is acting strangely because of its natural drift as a result of its IMU. Correcting that helps alot.

I also had the chance to increase the theta limits and that helps alot. Thanks again!

Improve this answer
$\endgroup$
0
$\begingroup$

Rosanswers logo

Hello!

I am also working with Unitree A1's slamtec package, and have been struggling to get there navigation stack to work with 2D Goal! Every time I send command via 2D Goal on rviz, the robot seems to be confused (often times failing to get to the destination I have asked for), and the times it works, the robot takes a quite a while to get to the goal (it spins left and right, readjusts itself way too much).

I am assuming that you have been having similar issues, and I am starting to question if the generated cmd_vel is designed for wheeled robots like turtlebot. I wanted to write my own cmd_vel publisher for quadruped, but I am not sure how to integrate it with the output of global/local planner.

I would really appreciate if I can hear back from you and your progress, as I think knowing someone who is working on A1 would be nice in the progress moving forward. I am part of Georgia Tech, and I am in the process of making a slambox with ouster lidar, vectornav imu, and Intel NUC so that I can correct for odometry drift.

Sincerely,

Originally posted by buzzport93 with karma: 23 on 2021-04-05

This answer was NOT ACCEPTED on the original site

Post score: 1

Original comments

Comment by tootyboi95 on 2021-04-06:
Hi buzzport93,

No problem at all.

I would need more information. What aspect of the slamtec package you are using? I believe it comes with both the SLAM and the planner (or navigator) package.

If you are using the ROS Navigation Stack instead of Slamtec navigation stack, debug using these steps:

  1. Is the global planner giving a reasonable path to the goal? If so, move on.

  2. Is the local planner of the navigation stack not planning properly? Verify by sending a 2D Goal and visualizing the small line output by the local planner displayed on RViz. You can make the length more visible by increasing sim_time and min_vel. If the local planner seem to give local plans that are very inappropriate, you would need to refine the parameters.

  3. If (2) is ok, it might be indeed the cmd_vel sent by the planner to the robot. You might want to check (and correct) for robot's drift while it's trotting stationary. Overdrifting causes issues since the controller has to overcompensate.

Comment by buzzport93 on 2021-04-07:
Hi Tootyboi95. Good to hear from you!

I am not sure how your A1 was configured, but we got it with SLAMTEC S1 lidar option. Therefore, when we received the robot, catkin_ws/src was already equipped with SLAMTEC's sdk that uses ROS costmap_2d & navfn, which is what I am using.

So yesterday, I finally got the robot to walk to chosen locations after a critical fix. The fix was changing base_local_planner to dwa_local_planner (not the original 'inclusive' dwa = true). After adjusting some parameters (velocity & acc), I got to achieve this: https://www.youtube.com/watch?v=ibmLmJ9aCGc.

The most critical issue with that video above is that robot doesn't know when to stop properly for heading angle. I intended the robot to move to that chair, so that worked out nicely, but the robot seem to be confused for final heading angle. Is this just going to happen all the time due to the drift? or is this something that can be tuned with parameters? Also, have you used amcl with A1? Thanks!

Comment by buzzport93 on 2021-04-07:
If you have used amcl, I would like some help! I have already generated pgm & yaml file for my environment (the place you see in youtube video), and I would like to have robot navigate the area autonomously with the knowledge of map already in the 'brain'. I have looked for several tutorials, but they kind of seem confusing. What are the necessary changes you need to make for your launch files and yaml parameter files? Any reference / help would be greatly appreciated. Once again, thank you :)

Comment by tootyboi95 on 2021-04-10:
Hi,

I'm not too familiar with Slamtec's API, but I think it might use something similar to HectorSLAM for mapping, since it doesn't require any odometry input. This API would also only work with rplidars. Since I had issues with my rplidar, I swapped out of it and used my own Autonomy pipeline instead of the Slamtec one.

Comment by tootyboi95 on 2021-04-10:
As for the poor robot convergence issue, it seems like the robot is unable to converge accurately to the target pose, hence the continuous readjustment. You might want to consider increasing the goal XY and angle tolerance. I could set this using ROS navigation stack, but I'm not sure if you can do so using the SLAMTEC API.

Comment by tootyboi95 on 2021-04-11:
As for AMCL, perhaps you would consider something like this: https://github.com/tue-robotics/robot_launch_files/blob/master/launch/localization/amcl.launch

Note that you would need a map server to load the pgm and yaml map files and publish it out as topic for AMCL to subscribe to.

As for specific parameters, you should definitely check out the AMCL wiki page. You should make sure that the topics are defined correctly for proper topic subscribing and publishing: http://wiki.ros.org/amcl

Hope it helps!

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.