A, TF
See Ku ranking https://www.guyuehome.com/355
Focus: Radio TF, subscription, Cmakelist add compiler options at compile time
1 broadcaster.sendTransform( 2 tf::StampedTransform( 3 tf::Transform(tf::Quaternion(0, 0, 0, 1), tf::Vector3(0.1, 0.0, 0.2)), 4 ros::Time::now(),"base_link", "base_laser" 5 ) 6 )
1 listener.transformPoint("base_link", laser_point, base_point);
1 add_executable(tf_broadcaster src/tf_broadcaster.cpp) 2 add_executable(tf_listener src/tf_listener.cpp) 3 target_link_libraries(tf_broadcaster ${catkin_LIBRARIES}) 4 target_link_libraries(tf_listener ${catkin_LIBRARIES})
Second, prepare navigation
See wiki official website http://wiki.ros.org/navigation/Tutorials/Navigation%20Tuning%20Guide (good reference for engineering practice)
1, robots
(1) a distance sensor
(2) odometer
The first test checks the odometer of a reasonable degree of rotation. I opened rviz, the frame is set to "odom", laser scanning display provided by the robot, the theme of the decay time is set very high (approximately 20 seconds), and then rotates in place. Then I look at the scans in the subsequent rotation match each other closely extent. Ideally, the scan will overlap each other, but it is expected there will be some rotation drift, so I just make sure that the scan does not deviate more than twelve degrees.
The next test is the odometer integrity check translation. I will use only a few meters from the wall of a robot to set rviz. Then I'll robots directly at the wall and see the wall thickness of the laser scanning summarized in the report rviz. Ideally, the wall should look like a scan, but I just want to make sure it does not exceed the thickness of a few centimeters. If you are heading meter wall, but the scan range extends to more than half a meter, the odometer problem may exist.
(3) positioning
AMCL, initialization to pose as accurate.
2、costmap
Source is set to ensure that each observation sensor in accordance with the actual rate of release Expected_update_rate parameters. Here are usually given a certain tolerance, the inspection time is set to double what I expected, but when the sensor falls below the expected rate, will receive a warning from the navigation.
Appropriately set to the system transform_tolerance parameters. Check using tf from "base_link" frame to "map" to wait for the expected conversion of the time frame is. Usually tf_monitor delay view system, and the parameter set conservatively. In addition, if tf_monitor delayed report is large enough, four poke to see the cause of the delay, help to identify the problem how to publish conversion on a given robot.
On the robot's slow handling capacity, consider reducing map_update_rate parameters. However, when performing this operation, considering the fact that this will result in cost entry velocity sensor data of FIG delayed, thus slowing down the speed of the robot to respond to the obstacle.
publish_frequency parameter is rviz visualized costmap be useful. However, particularly for large global map, this parameter may cause things to run slowly. In the production system, reducing the cost of the rate of release of the FIG, and when required a very large visual FIG, you make sure the rate is set very low.
Whether voxel_grid or costmap model for determining the cost to a large extent depend FIG robot has a sensor suite. Because really need to consider the unknown space, it is necessary based on the 3D adjustment costs FIG cost of FIG. If a robot I use only plane laser, then I will always Costmap model for the map.
Sometimes, the only run in the framework of navigation odometer useful. To do this, the easiest is to copy local_costmap_params.yaml file global_costmap_params.yaml file and change the width and height of the map . If you want to adjust independently of the localization performance navigation, it is normal to make things run a very simple way.
Also, try to tend to select the map you are using a robot according to the size and resolution of processing power. In the robot (such as a powerful processing capabilities and the need for tight spaces PR2 on), use fine-grained map ... Set the resolution to 0.025 meters. For like the Roomba such a thing, I could reach 0.1 meter resolution, in order to reduce the amount of calculation.
Rviz is a good way to verify if costmap working properly. From costmap View obstacle data, and make sure when driving the robot, with its maps and laser scanning are aligned under joystick control. This is the sensor data is entered in a reasonable manner costmap sanity check. If you use a robot to track unknown space, then mostly use voxel_grid robots costmap model, view the unknown space visualization to understand the unknown space cleared in a reasonable manner. Do a good check is to see if you can correctly from costmap remove obstacles in is simply to walk in front of the robot and see if it can successfully see and clear the dynamic obstacle. About costmap posted to rviz detailed information about the topics, check out rviz course of navigation .
In the navigation stack runs only costmap checking the system load is a good idea. This means that the recall move_base nodes, but not to send targets and to check the load. If at this time the computer paralyzed, I think if you need a chance to run any program, you require some CPU savings parameter adjustment.
3, local planning
On the robot has reasonable acceleration limit is generally used dwa_local_planner ; for those with lower acceleration limit and hope in every deployment are taken to limit the acceleration of the deployment of benefit robot will be used base_local_planne r . Adjust dwa_local_planner ratio adjustment base_local_planner more pleasant, because its parameters are dynamically configured.
Third, the navigation configuration
See Ku ranking https://www.guyuehome.com/281 .
Focus: robot startup configuration file, configure the cost of maps, configure the path planner, launch
Four, RVIZ
See wiki official website http://wiki.ros.org/navigation/Tutorials/Using%20rviz%20with%20the%20Navigation%20Stack
Key: RVIZ the topic, msg type
Fifth, odometer
See Ku ranking https://www.guyuehome.com/332
Sixth, the sensor
See Ku ranking https://www.guyuehome.com/326
Source is set to ensure that each observation sensor in accordance with the actual rate of release Expected_update_rate parameters. I usually give here a certain tolerance, the inspection time is set to double what I expected, but when the sensor falls below the expected rate, very pleased to receive alerts from navigation.
为系统适当地设置transform_tolerance参数。很高兴检查使用tf从“ base_link”帧到“ map”帧的转换的预期等待时间是多少。我通常使用tf_monitor查看系统的延迟，并保守地设置该参数。另外，如果tf_monitor报告的延迟足够大，我可能会四处戳一下以查看造成延迟的原因。有时这使我发现有关给定机器人如何发布转换的问题。
在缺乏处理能力的机器人上，我将考虑降低map_update_rate参数。但是，在执行此操作时，我考虑到这样一个事实，即这将导致传感器数据进入成本图的速度出现延迟，从而减慢了机器人对障碍物做出反应的速度。
该publish_frequency参数是在rviz可视化costmap有用。但是，尤其是对于大型全局地图，该参数可能导致事物运行缓慢。在生产系统中，我考虑降低发布成本图的速率，并且当我需要可视化非常大的图时，请确保将速率设置得非常低。
是否将voxel_grid或costmap模型用于成本图的决定很大程度上取决于机器人具有的传感器套件。由于确实需要考虑未知空间，因此需要为基于3D的成本图调整成本图。如果我使用的机器人只有平面激光器，那么我总是将Costmap模型用于地图。
有时，仅在里程表框架中运行导航很有用。要做到这一点，我发现最容易做的事情就是我的复制local_costmap_params.yaml文件在我global_costmap_params.yaml文件并更改了宽度和高度的地图是东西更像是10米。如果要独立于本地化性能来调整导航，这是使事情正常运行的非常简单的方法。
我倾向于根据机器人的大小和处理能力来选择正在使用的地图的分辨率。在具有强大处理能力且需要适合狭窄空间的机器人（如PR2）上，我将使用细粒度的地图...将分辨率设置为0.025米。对于像Roomba这样的东西，我可能会达到0.1米的分辨率，以减少计算量。
Rviz是一种很好的方法来验证成本图是否正常工作。我通常会从成本图中查看障碍物数据，并确保在操纵杆控制下驾驶机器人时，它与地图和激光扫描都对齐。这是对传感器数据是否以合理方式进入成本图的合理性检查。如果我决定使用机器人跟踪未知空间，那么大多数都是使用voxel_grid的机器人在成本图的模型中，我确保查看未知空间的可视化效果，以了解以合理的方式清除了未知空间。我要做的一个很好的检查，就是看是否能正确地从成本图中清除障碍物，就是简单地走在机器人前面，看看它是否能成功看到我并清除我。有关costmap发布到rviz的主题的详细信息，请查看rviz教程的导航。
在导航堆栈仅运行costmap时检查系统负载是一个好主意。这意味着调出move_base节点，但不向其发送目标并查看负载。如果此时计算机陷入瘫痪，我想如果需要任何机会运行计划程序，则需要进行一些CPU节省参数调整。