I'm using navigation stack on PX4 drones, after learning tutorials I managed to set up the stack on my real drone system, with Pixhawk controller, Hokuyo UTM-30LX and jetson TX1,and everything seems work well in RVIZ, rqt_gragh and rqt_tf_tree.

I think a successful simulation is necessary before a real flight, but I met some problems.

First, amcl continuously send warnings about: No laser scan received.... and move_base send warnings like: timed out waiting for transform from base_link to map become avaliable before running costmap... I think a real laser lidar is not needed in simulation, and the urg_node(hokuyo node) should not be started, and who should send /scan topic to amcl?

What's more, I want to know if amcl is necessary in navigation stack, I know that amcl helps localize the robot in the map, and it should send tf between /odm and /map,but in my real system gmapping did this work, so can I remove amcl in the system?

Second, I tried set parameter use_sim_time to true in launch file, and no warnings exist after that. However other nodes, for example uav_base_controller node just don't send moving commands to UAV and even simulation in gazebo stopped. What's the problem? Should use_sim_time set to true in simulation?

edit retag close merge delete

Sort by » oldest newest most voted

Should use_sim_time set to true in simulation?

Yes, use_sim_time should be true when running Gazebo, and the Gazebo node will publish the /clock topic needed by other nodes.

I know that amcl helps localize the robot in the map, and it should send tf between /odm and /map,but in my real system gmapping did this work, so can I remove amcl in the system?

SLAM algorithms like gmapping dynamically build a map of the environment while also estimating the robot's pose on the map, and then convey that pose in the form of a TF transform from map to odom. On the other hand, AMCL compares incoming LIDAR scans to a static map and provides the same map to odom transform.

Therefore, if you're loading a pre-built map, then AMCL can be used for just localization. When in an unknown environment, then SLAM algorithms can perform localization as well as build the map.

I think a real laser lidar is not needed in simulation, and the urg_node(hokuyo node) should not be started, and who should send /scan topic to amcl?

Correct, the /scan topic should come from the simulation itself, which requires a Gazebo plugin to simulate one. Here is a good example of how to add a Hokuyo sensor to a robot model in Gazebo:

Hokuyo / Gazebo Example

.... and move_base send warnings like: timed out waiting for transform from base_link to map become avaliable before running costmap

AMCL or a SLAM node will publish the transform from map to odom, but something has to publish the transform from odom to base_link to complete the TF tree required by move_base.

The odom to base_link transform is typically published by integrating wheel speeds and / or IMU measurements to generate an approximate, drift-prone position and orientation. This process is known as dead reckoning. The localization then essentially corrects the drift by updating map to odom such that the combined map to base_link transform is accurate.

Another way to set the system up is to skip dead reckoning and configure AMCL or gmapping to publish directly from map to base_link. This tends to be less robust than the method in the previous paragraph because the localization has to solve the position and heading of the robot using just the laser scans, whereas using dead reckoning requires the localization algorithm to only make relatively small corrections.

I hope this helps!

more