Add service to MotoROS to retrieve true link lengths and joint limits

[gavanderhoorn]

This is really just a suggestion, but would be very nice to have.

Perhaps we could add a service to MotoROS that would allow clients to retrieve information about the kinematics of the robot that the MotoROS server is running on. In particular, I'm thinking:

• link lengths (using the values stored in the controller's parameters instead of the 'default' values for the robot variant)
• joint limits: lower and upper position limits, maximum velocities, etc

The driver could then expose a ROS service that would translate the information returned by MotoROS into ROS datatypes (TBD). For accessing the specific parameters on the robot controller we could employ the same scheme as is currently used with the ParameterExtraction library.

[gavanderhoorn]

@ted-miller @EricMarcil: thoughts?

[gavanderhoorn]

Depending on how MotoROS makes this information available, we could even see whether it would be possible to generate a skeleton urdf/xacro macro using some tool basing it on the data coming from the controller.

This could make adding support for new robot variants somewhat easier.

[ted-miller]

I am definitely in favor of this. But, I won't be able to implement it quickly. Also, I expect that @EricMarcil is busy until at least mid-September. But, I think one of us could probably implement something around the end of Sept.

Depending on how MotoROS makes this information available, we could even see whether it would be possible to generate a skeleton urdf/xacro macro

Can you elaborate on how you like this data presented? I'm thinking it would just be a new command message on the state-server.

[gavanderhoorn]

@ted-miller wrote:

But, I won't be able to implement it quickly. Also, I expect that @EricMarcil is busy until at least mid-September. But, I think one of us could probably implement something around the end of Sept.

I would offer to do some of the development, but the bulk of it would probably be retrieving the parameters, and that is something I cannot do.

Perhaps I can see whether I can do something on the simple message and motoman_driver side.

Depending on how MotoROS makes this information available, we could even see whether it would be possible to generate a skeleton urdf/xacro macro

Can you elaborate on how you like this data presented? I'm thinking it would just be a new command message on the state-server.

Yes, it would be a request-reply sequence probably added to the state server (doesn't really matter though which server it ends up being).

I was more referring to whether it'd be in the form of DH parameters, no specific notation or modeling at all, or in the form of transforms -- as ROS uses.

The latter would obviously make things very easy for ROS consumers, but as there are users of MotoROS outside the ROS context, it might not be the most suitable option.

[gavanderhoorn]

#247 might be something to take into account here.

[gavanderhoorn]

Is this something we could start discussing again @ted-miller @EricMarcil ?

[EricMarcil]

I do think that doing anything complex is an over kill. To my knowledge, it is very rare that a robot is calibrated and the arm link lengths are modified in the process. Making reference to the spec sheet should be fine in most cases.

If we put it in the MotoROS driver, it should be super simple, just spitting out the none zero length in order and not try to explicitly build the model. It would require the modification the Parameter Extraction Library since Yaskawa will not publish restricted parameters informations.

Otherwise, I would recommend making a separate application that would make a standard URDF file from the all.prm file and make it available to end users. The problem with that is to make sure to address the various robot models and maintaining it over time. At this time, I do not believe that this issue can justify the required development and making a URDF for a new robot only takes a couple of hours and most of the effort is related to the 3D model work, not the actual URDF file.

[gavanderhoorn]

It doesn't need to be very complex. Just returning the nr of links, their order and link lengths should suffice. Perhaps in a "graph" based format (ie: joint->link->joint->link->..).

It would be a simple SimpleMessage service with an overlaying ROS API.

All proprietary access to parameters stays on the controller that way.

Stand-alone applications need additional maintenance, and that may be overhead we're not willing to pay at this time.

I do believe that for users to be able to verify that the URDF they're (trying) to use is correct wrt their robot would be a great service.

[ted-miller]

I can add this into the next update. There are a couple outstanding issues that I'm waiting on some feedback before I implement the next update. So, I'm hoping to have something implemented in 1-2 weeks.

Can you provide an example struct of how you thing the message(s) should be organized?

[gavanderhoorn]

#256 adds a service that returns D-H parameters.

[gavanderhoorn]

The ROS side would have to be added, but MotoROS has been extended with this service in #256, so closing.

[gavanderhoorn]

Tracking the ROS API side in #289.