baxter实际使用时出现的无法规划问题的解决（很傻的一个问题...）

好久好久都没有写博客了，总感觉博客的编辑不好使，喜欢写到文档里面，不过还是写到博客里面会有个监督的感觉...

好吧，把最近做的一些东西写出来吧～保持写博客的习惯吧。目前在用的是baxter机器人，虽然他公司已经倒闭了，但是在做研究的时候，还是挺好用的。

前一段日子，有个问题很怪异，关于real baxter&moveit的问题，问题是，在仿真环境gazebo&moveit的时候，拖拽和规划一切都顺利，定制生成的ikfast解算插件也能够正好正常工作，但是使用真实baxter验证的时候，拖拽总是出现问题提示

 

这个提示意思是关节产生了自碰撞，查找问题，说是修改moveit配置文件夹中的opml_planning.yaml文件，修改其中longest_valid_segment_fraction参数，默认0.05，但是改小了就提示解算不出来解，即使加大计算时间，也不行，改大了有解但是提示自碰撞，根本找不到一个合适的数值满足条件。很纳闷为什么仿真时候自碰撞不会提示问题，但是真实机械臂就会提示碰撞。

经过一天半，已经解决，我的流程是，考虑gazebo仿真和实际机械臂连接moveit的结构入手，参考之前的图

可以看出其实gazebo和realworld与moveit链接的时候都是通过两个相同的接口结构，可以分为机械臂端和moveit端，

1. 考虑仿真和实际，在参数服务器中的URDF文件不同

    因为不论是仿真还是实际，moveit都需要机器人的URDF文件，以此为依据，结合机械臂端反馈回来的位置数据，来计算是否有碰撞，考虑是不是URDF文件的不同导致的碰撞检测不同？但是使用命令

rosparam get -p /robot_description | tail -n +2 > baxter_urdf.xml

从参数服务器中抽取URDF，不论是否是在仿真还是真实环境下，URDF文件都相同。

       2.考虑moveit端

    因为在两种环境中启动的moveit的launch指令相同，经过查看moveit的系列launch文件，准根溯源，没有发现有根据环境进行切换的语句。排除这个问题。

开头的地方出现的问题，实际上终端窗口给出过警告，但是只是警告，不是错误，所以没有在意

类似于上图中的情况提示起始位置超出了界限，无论怎么求解都无解，调大参数longest_valid_segment_fraction: 0.02，提示有解，但是经查看提示baxter上臂和头部会发生碰撞，查看moveit源文件中抛出警告的那个源文件kinematic_constraint.cpp，

http://docs.ros.org/jade/api/moveit_core/html/kinematic__constraint_8cpp_source.html 发现启动的时候，会检查各个关节的起始位置是不是超出了规划要求的关节界限，上面提示，超出了界限。

所以原因在于，在gazebo中仿真的时候起始状态如下图所示，关节处于限制之内，因此会有正常解。

而在实际机械臂运行时，执行使能机械臂命令rosrun baxter_tools enable_robot.py -e

之后，机械臂会呈现如下状态

 

这种状态中关节s0，s1处于极限位置之外，需要执行：

rosrun baxter_tools tuck_arms.py -u到工作状态，之后再启动moveit，这样才能保证找得到解。

 

是不是很蠢的问题...  以后要注意呀