ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

what are benefits of using ROS-I and motoman_driver?

asked 2019-04-17 08:08:47 -0600

nd gravatar image

Hello,

I want to develop vision based pick and place. let say I have camera on robot end effector, I am taking image of object and esimating it pose to give it to robotic arm using camera.

As, I have motoman robot I can use motoman_driver to communicate with real robot.

But this can also be done without using motoman_driver. for application like this if I use ROS-i, can it seen as here ´not required´? as this can be done also without using it.

how can I use motoman_driver to give only POSE of object to robot controller(as we can do in traditional vision system with INFORM programming job) without Moveit motion planning? as motoman robot has its own controller to do all the thing.

what exactly use of motoROS application?

may be I am confused here. Thanks.

edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted
1

answered 2019-04-17 09:18:32 -0600

gvdhoorn gravatar image

updated 2019-04-17 09:56:18 -0600

I want to develop vision based pick and place. let say I have camera on robot end effector, I am taking image of object and esimating it pose to give it to robotic arm using camera. [..] But this can also be done without using motoman_driver. for application like this if I use ROS-i, can it seen as here ´not required´? as this can be done also without using it.

using something like ROS (or more generically: a off-controller motion controller) can be beneficial if you wish to use something like sensor based motion planning.

Yes, you can send a Cartesian position to the controller and parameterise an INFORM job with it as you describe. And in that case the controller will execute the motion hard-coded in the job, but with some changes based on the position you received from the camera. You don't need MotoROS for such a setup.

If that is all you require, then using MotoROS is probably not going to be more efficient or interesting.

When it does get interesting is when (some examples):

  • you want your motion plans to take obstacles into account (the robot controller will not do that, in fact: it will try to move through obstacles)
  • when those obstacles are dynamic (ie: they move while the robot is moving)
  • when your sensor data is voluminous and heterogenous (there is a lot of sensor data and it's also not all from the same type of sensor)
  • when you have a complex motion planning problem that is also changing while the robot is executing it (fi: optimisation of process parameters in an on-line fashion)
  • when the robot is only part of a larger system (ie: a 34 dof system in which the 6 (or 7) of the robot are a subset) and planning of motions must take all dofs into account
  • when no part of your application can be preprogrammed in an INFORM job (essentially all joint poses are unknown at design time, fi because all future motions will depend on in-situ gathered data)

and there are many more situations in which external control of a robot can be beneficial.

As good as (industrial) robot controllers have become and are at controlling a robot (specifically: the robots of the OEM), robotic applications are typically much more than just a (single) robot. Such applications therefor typically also require more than just the controller of the OEM.

Robot controllers are getting more and more complex, but I haven't found one that can process point clouds or do dynamic motion planning.

A good example of a complex application that benefited from the external control that MotoROS made possible is the A5 system (from this video):

Screenshot of A5 demonstration video

That's a pretty complex application that is using on-the-fly motion planning (no CAD models, so no off-line CAD-to-path) with collision avoidance, in-process Q&A and integrating many different sensors and actuators from many different OEMs. The plane (ie: "workpiece") can be anywhere, the robot can be anywhere, surface conditions ... (more)

edit flag offensive delete link more

Comments

Note: you can actually send a trajectory that you have computed yourself (so without using MoveIt) to motoman_driver. Just use the /follow_joint_trajectory action server for that.

MoveIt is not needed at all.

This would even work with single-point trajectories (actually: two-point trajectories (start, destination)). It would be joint interpolation though. But it is supported.

gvdhoorn gravatar image gvdhoorn  ( 2019-04-17 09:20:08 -0600 )edit

Note also: I'm not saying a pick-and-place application cannot be complex. What I'm saying is that depending on where the complexity comes from, the resources that an OEM controller has may not be sufficient to control more than just the robot itself. YRC1000 controllers are pretty OK machines, but you cannot run arbitrary programs on them, and even if you could, they would be seriously limited in CPU processing power and memory available to them.

To escape those limitations, external control makes sense.

gvdhoorn gravatar image gvdhoorn  ( 2019-04-17 09:51:45 -0600 )edit

@gvdhoorn Thank you for the great answer. As I want to use motoman_driver only for communication between PC and controller. because I found that using Motocom32 I can give related object pick,place position but it is not "free". so using motoman_driver can I give pick, place position using vision directly? but I do not understand "send a trajectory that you have computed yourself "? is it not done by robot controller?

nd gravatar image nd  ( 2019-04-17 09:56:27 -0600 )edit

No, you cannot just send positions. It's always a trajectory.

MotoCOM allows you to set registers, that is not what MotoROS is for.

If you have the option, you may want to take a look at the highspeed ethernet server.


Edit: if you have MotoPlus and are comfortable programming in C, you can definitely add getting and setting registers to MotoROS. See this fork for some inspiration.

gvdhoorn gravatar image gvdhoorn  ( 2019-04-17 09:58:10 -0600 )edit

oh, I understand wrong. I thought i will use motoman_driver, then sending POSE information to controller, Ik service and /follow_joint_trajectory I can do pick and place. so, I think then it is good to have Motocom32 as my programming experience is intermediate.

nd gravatar image nd  ( 2019-04-17 10:09:39 -0600 )edit

@gvdhoorn how can I calculate trajectory for given POSE if I want to use motoman_driver? I think then I have to use Moveit?

nd gravatar image nd  ( 2019-04-17 10:15:56 -0600 )edit

oh, I understand wrong. I thought i will use motoman_driver, then sending POSE information to controller, Ik service and /follow_joint_trajectory I can do pick and place

Things are not as black-and-white as you make them to be.

No, you cannot use MotoROS to send single poses (to registers) and use INFORM. Yes you can actually create a pick-and-place application with MotoROS.

But it all depends on where your focus is, and how much time you are willing to invest (and of course whether that time investment makes sense depends on what else you'd like to do).

gvdhoorn gravatar image gvdhoorn  ( 2019-04-17 12:49:36 -0600 )edit

@gvdhoorn how can I calculate trajectory for given POSE if I want to use motoman_driver? I think then I have to use Moveit?

a trajectory is nothing more than a sequence of joint space poses and associated time_from_start values (and velocity, if you don't want to stop at each point).

"calculating" is a strong word: you can just "make up" joint poses and append them to a trajectory_msgs/JointTrajectory. Set the joint_names field correctly, make sure to specify proper time_from_start values, wrap it in a FollowJointTrajectoryGoal and submit it to the /follow_joint_trajectory action server.

gvdhoorn gravatar image gvdhoorn  ( 2019-04-17 12:59:00 -0600 )edit

Question Tools

1 follower

Stats

Asked: 2019-04-17 08:08:47 -0600

Seen: 399 times

Last updated: Apr 17 '19