Issue : dropped 100.00% of messages so far
Resolve : tf transform wrong , for me , change /scan to /robot1/scan to resolve
https://answers.ros.org/question/246928/messagefilter-dropped-100-of-messages/
Issue : Timed out waiting for transform from base_footprint to map to become available before running costmap, tf error: . canTransform returned after 0.101175 timeout was 0.1.
- Resolved: 关键词 :base_footprint , 在local和global costmap 配置文件中都有配置, 一般情况改为base_link即可 (robot_base_frame: base_link)
- 还要注意检查 base_link / robot1/base_link 到odom的tf有没有建立起来. odom -> base_link 一般都是硬件驱动(arduino)程序提供的tf转换
- https://answers.ros.org/question/174114/turtlebot-amcl-waiting-on-transform-from-robot1base_footprint-to-map-to-become-available-tf-error/
navigation 调试 -1- 解决导航过程中边前进边转圈问题
https://blog.csdn.net/sunyoop/article/details/78903903?utm_source=blogkpcl6
浅谈路径规划算法
https://blog.csdn.net/chauncygu/article/details/78031602
ROS Navigation Stack之dwa_local_planner源码分析
https://blog.csdn.net/TurboIan/article/details/78165648
"其整一个逻辑顺序就是computeVelocityCommands->findBestTrajectory –> createTrajectories –> generateTrajectory"
ROS导航小车无故倒退问题分析
https://blog.csdn.net/lqygame/article/details/73716065
“作者:wayen820
原文:https://blog.csdn.net/qq_29573053/article/details/70318241
1、如果使用的是base local planner,里面有两个参数pdist_scale 和gdist_scale ,要理解这两个参数,设想一下两个极端情况,pdist_scale很大,gdist_scale很小,这时候小车会不动,因为所有规划出的局部路径都将导致离开全局路径,小车还不如停在原地不动,得分高;如果pdist_scale很小,gdist_scale很大,这时候小车将朝着局部目标点(如果全局目标点在局部规划范围外,局部目标点就是全局路径在局部规划范围外的第一个点)或者全局目标点跑,完全不照全局路径走;这时候有个不好的影响是,狭窄通道或者避障转不过弯,因为局部路径规划给出的路径全部都是朝着目标走,而朝着目标走的局部路径都被障碍物挡住了,因此全部被否决,小车原地转圈。因此实际中还是应当将pdist_scale取得大一点,gdist_scale取得小一点。
2、amcl粒子云在小车持续转弯后迅速发散问题,或者迟迟不收敛。这时候你需要调试你的里程计,确保有一定的准度。如果你觉得里程计还是挺准的,记得要将amcl参数配置的关于里程计的参数odom_alpha1-5 这几个参数调节小一点,因为它是设定里程计方差的,如果你设置过大,那就意味着要amcl不相信你的里程计,全部靠amcl来估计,因此粒子云会表现得不太稳定
3、如果你发现在rviz中小车完全没有按照局部规划路径跑,那就是你的里程计给出的twist信息错误了。好好调试一下。”
ROS导航包之costmap_2d
https://blog.csdn.net/mllearnertj/article/details/74838981 (调参注意事项)
https://blog.csdn.net/u013158492/article/category/2308493
Recovery ISSUES:
I'm working with P3-DX and ROS navigation stack. I have encoutered these two circumstances in which the nav stack aborts.
-
The robot is too close to the obstacles, it can't even rotate. These two error messages came out and the robot stopped.
[ERROR] [1472631068.711487006]: Rotate recovery can't rotate in place because there is a potential collision. Cost: -1.00
[ERROR] [1472631068.811355441]: Aborting because a valid plan could not be found. Even after executing all recovery behaviors
-
There are many obstacles arround the robot, but it can rotate. Then it rotated several times but still could't find a way out. Finally, it aborted. And this error message came out.
[ERROR] [1472633546.394854371]: Aborting because a valid plan could not be found. Even after executing all recovery behaviors
thanks. however, exactly this is a problem: planning is successful -> local planner fails to execute -> again planning is successful -> again local planner fails to execute. and it loops indefinitely. thoughts on that, how to avoid that loop?
thanks for the ideas. but I guess it is not the case: my update_frequency is 5.0, yet the same behavior happens. I currently don't have a real robot to work on, only a simulation, but what makes you think that on the real robot there would be a difference?