Confused about many different drivers

[simonschmeisser]

Hi Everybody,

I'm sitting in front of a YuMi for some time now and wondering what driver would be best for us and where to take it from. We intend to use it for bin-picking and execute pre calculated trajectories (ie. no live feedback/realtime required). It has to be fast!

I read somewhere that the ABB_driver based joint_trajectory downloader approach is supposed to have a long (several seconds) delay before starting trajectory execution. Is that true? Is it faster for short/sparse trajectories (number of points, not distance)?

I started using the drivers from https://github.com/OrebroUniversity/yumi/tree/master/yumi_hw master branch and it is moving using MoveIt!. However there is a very notable delay before it does (ca 1s) and sometimes it moves joint6 (the wrist) to 0 instead of the intended position. I'm not sure if this is a ros_control issue (I doubt it) or related to yumi_hw. Also sometimes it hangs at startup and the joint_state_controller does not come up.

I feel safer about using the trajectory downloader approach actually because we use that for other brands already but of course I worry about the long delays. What do you think? Can you point me to whatever branch and version you recommend?

Does egm also work for position control or just velocity control?

Thanks a lot Simon

[simonschmeisser]

Small update, I haven't seen any real erroneous movements any more using the position controlled driver from yumi_hw master. I also have the gripper running using the code from feature_egm branch (using fewer locks/mutexes seems to be the main difference). Delay before execution is somewhat acceptable now at 100% controller velocity override and aiming for slower speed in the trajectory parametrization (25%). However while some movements are nice and smooth, others are quite jerky, showing lots of stop and go motion. I have two days remaining next week to get a nice presentation for our potential customer, what do you think would be the best approach? For other robots we usually send trajectories with only two points (if collision free) but I read that for this driver I need more dense ones. I currently just interpolate 100 steps, no matter what distance. What step size do you recommend? How does it depend on velocity? Doesn't ros_control interpolate itself?

Should I try one of the egm branches or is that to complicated to setup?

@tstoyanov @rtkg @YoshuaNava sorry for spaming, but any opinion? Please :)

[tstoyanov]

Hi Simon,

terribly sorry for the long wait, but we are overloaded at the moment. I am afraid that you are already using the best currently available solution to your issue... There are indeed several options for the yumi drivers, which are:

• trajectory download and then execution in RAPID. This we have tested (briefly) with MoveIt, and seems to work ok. There might be an issue with joint 7 (elbow joint), which I would have to double-check, and this might explain the strange motions you see. This is in the main branch.
• direct joint control over ros_control and a native RAPID interface. This should work without any delay, but in order to use it with moveit you would need a tracking controller. This should be possible to do, but I have not tried it and I am not sure how well the tracking controller will work. There are also a lot of issues with re-starting the robot and mutex initialization in this option.
• the last option is ros_control over EGM, which should work best. You would again need a tracking controller, but at least this option should give you better tracking. You would however need an EGM license from ABB in order to use this on the robot.

sorry couldn't help more. T.

[simonschmeisser]

Hi tstoyanov,

when I wrote this I was using option 2 (direct joint control over ros_control and a native RAPID interface). This was indeed starting movements without major delays but movement often got jerky and generally looked imprecise. I think issues were mostly related to a mismatch between trajectory point spacing and execution rate of these. (And then there were also the mutex and other issues)

I then switched to using classical option 1, ie trajectory download based on abb_driver and this results in smooth and relatively speedy execution. However I still have (unpredictable) delays before execution of the trajectory starts. I assume this is due to internal collision checking in the yumi controller. Also trajectories are still slower than the designated max speed.

Do you know how to disable collision checking? Other settings that limit the velocity?

[tstoyanov]

Hi Simon, and sorry for the long delay. You probably have this figured out by now, but in case you did not, you can check issue #28 and the suggestions there. Regarding the collision checking, I think you can look at the MotionSup (motion supervision) level. If you set that to 0, you should be able to smash into things freely :)