[Summary of move_base function package running problems]

move_baseWhen recording and running the function package here , some problems are encountered and recorded.

Use the following launchfiles to invoke move_basethe function pack.

<?xml version="1.0"?>

<launch>
    <arg name="use_rviz" default="false" />
    <!-- for amcl -->
    <arg name="init_x" default="0.0" />
    <arg name="init_y" default="0.0" />
    <arg name="init_a" default="0.0" />
    <arg name="base" default="$(optenv TIANRACER_BASE compact)" />
    <!-- for Map server -->
    <arg name="map" default="$(find f1tenth_simulator)/maps/torino.yaml"/>


    <!-- Map server -->
    <node pkg="map_server" name="map_server" type="map_server" args="$(arg map)"/>

    <!-- Localization -->
    <!-- AMCL -->
    <include file="$(find f1tenth_navigation)/launch/amcl.launch.xml">
        <arg name="init_x" value="$(arg init_x)"/>
        <arg name="init_y" value="$(arg init_y)"/>
        <arg name="init_a" value="$(arg init_a)"/>
    </include>

    <!--  Navigation -->
    <node pkg="move_base" type="move_base" respawn="false" name="move_base" output="screen">
        <rosparam file="$(find f1tenth_navigation)/param/move_base_params.yaml" command="load"/>
        <rosparam file="$(find f1tenth_navigation)/param/teb_carlike/costmap_common_params.yaml" command="load" ns="global_costmap" />
        <rosparam file="$(find f1tenth_navigation)/param/teb_carlike/costmap_common_params.yaml" command="load" ns="local_costmap" />
        <rosparam file="$(find f1tenth_navigation)/param/teb_carlike/local_costmap_params.yaml" command="load" />
        <rosparam file="$(find f1tenth_navigation)/param/teb_carlike/global_costmap_params.yaml" command="load" />

        <rosparam file="$(find f1tenth_navigation)/param/teb_carlike/compact_teb_local_planner_params.yaml" command="load" />
        <rosparam file="$(find f1tenth_navigation)/param/teb_carlike/global_planner_params.yaml" command="load" />

        <param name="base_local_planner" value="teb_local_planner/TebLocalPlannerROS" />
        <param if="$(eval base=='compact')" name="footprint" value="[[0.34,0.1],[0.34,-0.1],[-0.05,-0.1],[-0.05,0.1]]" />
        <param if="$(eval base=='standard')" name="footprint" value="[[0.42,0.14],[0.42,-0.14],[-0.12,-0.14],[-0.12,0.14]]" />
        <param if="$(eval base=='fullsize')" name="footprint" value="[[0.8,0.27],[0.8,-0.27],[-0.2,-0.27],[-0.2,0.27]]" />
        <param name="clearing_rotation_allowed" value="false" /> Our carlike robot is not able to rotate in place
    </node>

    <!-- cmd_vel to ackermann_cmd -->
    <node pkg="f1tenth_navigation" type="cmd_vel_to_ackermann_drive.py" name="vel_to_ackermann" >
        <param name="twist_cmd_topic" value="/cmd_vel" />
        <param name="ackermann_cmd_topic" value="/drive" />
        <param if="$(eval base=='compact')" name="wheelbase" value="0.255" />
        <param if="$(eval base=='standard')" name="wheelbase" value="0.33" />
        <param if="$(eval base=='fullsize')" name="wheelbase" value="0.6" />
    </node>

    <!--  Visualisation -->
    <node name="rviz" pkg="rviz" type="rviz" args="-d $(find f1tenth_navigation)/teb_navigation.rviz" if="$(arg use_rviz)" />

</launch>

---

Question 1

问题：
Couldn’t transform from base_laser_link to base_footprint, even though the message notifier is in use

Solution:

Keep the base_frame_id in amcl_params.yaml consistent with the car body base_link

---

Question 2

问题：
Timed out waiting for transform from base_footprint to map to become available before running costmap, tf error: canTransform: source_frame base_footprint does not exist… canTransform returned after 0.100814 timeout was 0.1.

Reason: The coordinate system is not uniform

Solution:

1. Locate the parameter file: The parameter files for the called global and local maps are global_costmap_params.yamlsum local_costmap_params.yaml.
   
2. robot_base_frameModify the coordinate system in both files to base_link.
   
3. If amclthe function package is called, amclthe configuration file is base_frame_idalso changed base_link.
   

---

Question 3

question:

[ ERROR] [1669281693.716503087, 871.669000000]: Extrapolation Error: Lookup would require extrapolation -0.044000000s into the future. Requested time 871.665000000 but the latest data is at time 871.621000000, when looking up transform from frame [odom] to frame [map]

[ [ERROR] [1669281693.716542307, 871.669000000]: Global Frame: odom Plan Frame size 156: map

reason:

1. The time between the two controllers is not synchronized. But I did it on the simulation, there is no such situation.

2. Modify the costmap parameters.

Solution:

Modify map update frequency. Modify the parameters in the local_costmap_params.yanland file to .global_costmap_params.yamlupdate_frequency5.0

---

Question 4

问题：
[ERROR] [1678257648.538376817]: Extrapolation Error: Lookup would require extrapolation into the future. Requested time 1678257648.500453419 but the latest data is at time 1678257648.498552861, when looking up transform from frame [odom] to frame [map]

[ERROR] [1678257648.538445254]: Global Frame: odom Plan Frame size 517: map

[ WARN] [1678257648.538480014]: Could not transform the global plan to the frame of the controller

Solution:

After searching the information,
some people said that move_basethe function package is the wrong version, and reinstalling can solve it. But the version I installed is fine.
Some people say that there is an empty map in /map, comment out the release node that passes in the empty map. But I only have one map_serverand the map is not repeated.

Finally, someone said that the reason is that the odometer coordinate system of the local cost map is wrong . Change local_costmap_params.yamlthe second line to , and it can run successfully after I am done.global_frame: odomglobal_frame: map

---

Question 5

question:

The origin for the sensor at (0.28, 0.00, 0.00) is out of map bounds. So, the costmap cannot raytrace for it.

Reference:
https://answers.ros.org/question/9845/move_base-warning-sensor-out-of-bounds/

Solution:

Change the parameter global_costmap_params.yamlin to .rolling_windowtrue

Or add parameters global_costmap_params.yamlin static_map: true, it can also run normally.

This conflicts with question 6 , and it was later found to be a problem with the map format. When using an image to import a map, the image format is .pgm, not .png. After converting the png format to pgm, the same error will still be reported. The reason is that the pgm format has a standard form, and the converted format is not standard, so an error will be reported. Solution: The picture in pgm format can be planned by using the slam method and saved by using the command, or it can be drawn manually by using the drawing tool.

After the map format is correct global_costmap_params.yaml, rolling_windowchange the parameter in to false.

correct pgm format

wrong pgm format

---

Question 6

Problem:
After setting the waypoints, the path cannot be planned, and an error is reported:
Clearing both costmaps to unstuck robot (1.84m).
Aborting because a valid plan could not be found. Even after executing all recovery behaviors

If you do the following:

1. At the target point of the device that is closer to the current vehicle, there is no error and it arrives smoothly.
2. If the target point is set at a far location, an error (above) will be reported and it cannot be reached.

This article analyzes the reasons and solutions . The problem is that when the robot rotates, all the optional trajectories will become very short, which will cause the speed of the robot to become very small. If you increase the upper limit of the robot's speed, you can increase the movement speed of the robot when it has a rotation action to some extent . After I improved the parameters acc_lim_x, acc_lim_thetathe above problem still hasn't been solved.

Finally, I explored by global_costmap_params.yamlmyself rolling_windowand changed the parameter in to false, and no error was reported, and the path can also be planned when the target point is far away.

But here it contradicts question 5 .