好久好久都没有写博客了,总感觉博客的编辑不好使,喜欢写到文档里面,不过还是写到博客里面会有个监督的感觉...
好吧,把最近做的一些东西写出来吧~保持写博客的习惯吧。目前在用的是baxter机器人,虽然他公司已经倒闭了,但是在做研究的时候,还是挺好用的。
前一段日子,有个问题很怪异,关于real baxter&moveit的问题,问题是,在仿真环境gazebo&moveit的时候,拖拽和规划一切都顺利,定制生成的ikfast解算插件也能够正好正常工作,但是使用真实baxter验证的时候,拖拽总是出现问题提示
这个提示意思是关节产生了自碰撞,翻墙查找问题,说是修改moveit配置文件夹中的opml_planning.yaml文件,修改其中longest_valid_segment_fraction参数,默认0.05,但是改小了就提示解算不出来解,即使加大计算时间,也不行,改大了有解但是提示自碰撞,根本找不到一个合适的数值满足条件。很纳闷为什么仿真时候自碰撞不会提示问题,但是真实机械臂就会提示碰撞。
经过一天半,已经解决,我的流程是,考虑gazebo仿真和实际机械臂连接moveit的结构入手,参考之前的图
可以看出其实gazebo和realworld与moveit链接的时候都是通过两个相同的接口结构,可以分为机械臂端和moveit端,
- 考虑仿真和实际,在参数服务器中的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,这样才能保证找得到解。
是不是很蠢的问题... 以后要注意呀