# How amcl works?

Hi! I use this file:

<launch>
<!-- Run the map server -->
<node name="map_server" pkg="map_server" type="map_server"
args="$(find robot_setup_tf)/mymaps/map.yaml" output="screen"/> <include file="$(find frontier_exploration)/launch/amcl_diff.launch">
</include>

<node pkg="move_base" type="move_base" respawn="false" name="move_base" output="screen">
<rosparam file="$(find frontier_exploration)/launch/costmap_common_params.yaml" command="load" ns="global_costmap" /> <rosparam file="$(find frontier_exploration)/launch/costmap_common_params.yaml" command="load" ns="local_costmap" />
<rosparam file="$(find frontier_exploration)/launch/local_costmap_params.yaml" command="load" /> <rosparam file="$(find frontier_exploration)/launch/global_costmap_params.yaml" command="load" />
</node>

<node pkg="rviz" type="rviz" name="rviz" args="-d rviz_cfg.rviz"/>

</launch>


but what amcl would do? Because I see the map and what laser scan see but nothing happens. I think it should overlap the scan points on the map, is it correct? Thanks you!

edit retag close merge delete

Sort by » oldest newest most voted

AMCL tries to match the laser scans to the map thus detecting if there is any drift occurring in the pose estimate based on the odometry (dead reckoning). This drift is then compensated by publishing a transform between the map frame and the odom frame such that at the end the transform map->base_frame corresponds to the real pose of the robot in the world. It is explained here with a nice diagram:

here you can find the definitions and uses of each frame for ROS REP105 naming conventions:

Coordinate Frames

map

The coordinate frame called map is a world fixed frame, with its Z-axis pointing upwards. The pose of a mobile platform, relative to the map frame, should not significantly drift over time. The map frame is not continuous, meaning the pose of a mobile platform in the map frame can change in discrete jumps at any time.

In a typical setup, a localization component constantly re-computes the robot pose in the map frame based on sensor observations, therefore eliminating drift, but causing discrete jumps when new sensor information arrives.

The map frame is useful as a long-term global reference, but discrete jumps make it a poor reference frame for local sensing and acting.

odom

The coordinate frame called odom is a world-fixed frame. The pose of a mobile platform in the odom frame can drift over time, without any bounds. This drift makes the odom frame useless as a long-term global reference. However, the pose of a robot in the odom frame is guaranteed to be continuous, meaning that the pose of a mobile platform in the odom frame always evolves in a smooth way, without discrete jumps.

In a typical setup the odom frame is computed based on an odometry source, such as wheel odometry, visual odometry or an inertia measurement unit.

The odom frame is useful as an accurate, short-term local reference, but drift makes it a poor frame for long-term reference.

The coordinate frame called base_link is rigidly attached to the mobile robot base. The base_link can be attached to the base in any arbitrary position or orientation; for every hardware platform there will be a different place on the base that provides an obvious point of reference. Note that REP 103 [1] specifies a preferred orientation for frames.

Relationship between Frames

We have chosen a tree representation to attach all coordinate frames in a robot system to each other. Therefore each coordinate frame has one parent coordinate frame, and any number of child coordinate frames. The frames described in this REP are attached as follows:

The map frame is the parent of odom, and odom is the parent of base_link. Although intuition would say that both map and odom should be attached to base_link, this is not allowed because each frame can only have one parent.

more

@Mehdi. Hello, sir. Does the real pose of the robot in the world mentioned in your answer means that the real pose of the robot measured by a sensor such as lidar?

( 2019-03-28 02:20:17 -0600 )edit