Staubli-DH: Offset parser to URDF

[nilsmelchert]

Hi, buying a Staubli robot, you can additionally order a robot calibration, which consists of DH-Offsets. These identified offsets can then be found on the CS8 controller in the arm.cfx file and has the following format:

  <DhArray name="dhOffset" >
    <DH index="0" theta="OFFSET_IN_DEG" d="OFFSET_IN_MM" a="OFFSET_IN_MM" b="OFFSET_IN_MM" alpha="OFFSET_IN_DEG" beta="OFFSET_IN_DEG" />
    <DH index="1" theta="OFFSET_IN_DEG" d="OFFSET_IN_MM" a="OFFSET_IN_MM" b="OFFSET_IN_MM" alpha="OFFSET_IN_DEG" beta="OFFSET_IN_DEG" />
    <DH index="2" theta="OFFSET_IN_DEG" d="OFFSET_IN_MM" a="OFFSET_IN_MM" b="OFFSET_IN_MM" alpha="OFFSET_IN_DEG" beta="OFFSET_IN_DEG" />
    <DH index="3" theta="OFFSET_IN_DEG" d="OFFSET_IN_MM" a="OFFSET_IN_MM" b="OFFSET_IN_MM" alpha="OFFSET_IN_DEG" beta="OFFSET_IN_DEG" />
    <DH index="4" theta="OFFSET_IN_DEG" d="OFFSET_IN_MM" a="OFFSET_IN_MM" b="OFFSET_IN_MM" alpha="OFFSET_IN_DEG" beta="OFFSET_IN_DEG" />
    <DH index="5" theta="OFFSET_IN_DEG" d="OFFSET_IN_MM" a="OFFSET_IN_MM" b="OFFSET_IN_MM" alpha="OFFSET_IN_DEG" beta="OFFSET_IN_DEG" />
  </DhArray>

Where OFFSET_IN_DEG and OFFSET_IN_MM are the corresponding offsets of "their" DH-Representation. By "their", I mean, that the conventional DH notation consists only of 4 instead of 6 parameters.

I just wrote a small parser in Python, which is able to consider those offsets and parse them to the URDF format.

Now regarding my two questions:

• Is anyone is interested in that kind of parser to be contributed to this repo?
• Is there a way to load the arm.cfx file from a running controller (Maybe some sort of socket connection)?

[gavanderhoorn]

I would certainly be interested in adding support for this in some way to the staubli packages here.

It would be interesting to see whether and if so, how this connects to https://github.com/ros-industrial/universal_robot/pull/414.

• Is there a way to load the arm.cfx file from a running controller (Maybe some sort of socket connection)?

that I wouldn't know right now.

FTP might be an option, but it would have to configured on the controller.

Might perhaps also be accessible through the XML-RPC server (the parameters I mean, not the file necessarily)?

[nilsmelchert]

It would be interesting to see whether and if so, how this connects to ros-industrial/universal_robot#414.

Our DH-Parameters actually consist of 6 parameters not of the conventional 4. Or what do you mean by "connects to"?

FTP might be an option, but it would have to configured on the

That is actually not a bad idea at all, since the log in data is always the same for each controller and the robot ip has to be entered anyways when using the val3 driver.

Might perhaps also be accessible through the XML-RPC server

That would probably be the cleanest way I think. Is there actually a way to set up an XML-RPC server on the controller?

In order to use the corrected parameters in ros, I see two possible ways:

1. Change the URDF and then save if afterwards with those corrected parameters
2. Update the parameters directly in the robot_description on the parameters server during runtime

What do you think?

[gavanderhoorn]

It would be interesting to see whether and if so, how this connects to ros-industrial/universal_robot#414.

Our DH-Parameters actually consist of 6 parameters not of the conventional 4. Or what do you mean by "connects to"?

I was more referring to the approach that is being used in ros-industrial/universal_robot#414.

FTP might be an option, but it would have to configured on the

That is actually not a bad idea at all, since the log in data is always the same for each controller and the robot ip has to be entered anyways when using the val3 driver.

Afaik FTP security can be configured, so it wouldn't necessarily be identical for all controllers, but that's an implementation detail.

Might perhaps also be accessible through the XML-RPC server

That would probably be the cleanest way I think. Is there actually a way to set up an XML-RPC server on the controller?

IIRC all CS8 controllers have a built-in XML-RPC server.

In order to use the corrected parameters in ros, I see two possible ways:

1. Change the URDF and then save if afterwards with those corrected parameters

2. Update the parameters directly in the `robot_description` on the parameters server during runtime

updating robot_description is not viable imo: it leads to race conditions too easily.

Updating the urdf could be done, but I'd recommend taking a look at ros-industrial/universal_robot#414 where a separate .yaml is used to store the offsets and then some math is used in the .xacro to incorporate the calibration.

Generating new .xacros for each robot is also an option, but would make increase maintenance burden whenever the 'original' gets updated (users would have to patch in the changes or regenerate).

I would strongly suggest always keeping the robots as xacro macros instead of urdfs as otherwise composability is immediately lost.

Finally: in any case calibrated versions / data should be hosted by separate ROS packages. The original files should not be changed.

[nilsmelchert]

Might perhaps also be accessible through the XML-RPC server (the parameters I mean, not the file necessarily)?

Where can I find the documentation to communicate with the xml rpc server? I had a quick look at the val3 handbook and the SRS2019 handbook.

Updating the urdf could be done, but I'd recommend taking a look at ros-industrial/universal_robot#414 where a separate .yaml is used to store the offsets and then some math is used in the .xacro to incorporate the calibration.

I like the way you Pointed out of integrating the Offsete using yaml files. But writing a parser in order to convert the parameters to a valid ROS format is still needed right? Would Python be ok for this repository or would you prefer c++?

[gavanderhoorn]

Where can I find the documentation to communicate with the xml rpc server? I had a quick look at the val3 handbook and the SRS2019 handbook.

I'm not entirely sure, it's been a while since I've worked with Staublis. I'll have access to one in about 2 weeks, so I could take a look then.

I might be mistaken, but I'm pretty sure there is one on CS8 controllers.

I like the way you Pointed out of integrating the Offsete using yaml files. But writing a parser in order to convert the parameters to a valid ROS format is still needed right?

Well, "valid ROS format" would be .yaml in this case.

Would Python be ok for this repository or would you prefer c++?

I'd stick with Python. Emitting . yaml (and parsing .xml) is much, much easier there.

[nilsmelchert]

I'd stick with Python. Emitting . yaml (and parsing .xml) is much, much easier there.

Alright. Will do that.

Well, "valid ROS format" would be .yaml in this case.

By valid, i meant the representation of transformations in xacro-files.

[gavanderhoorn]

Well, "valid ROS format" would be .yaml in this case.

By valid, i meant the representation of transformations in xacro-files.

Ah, ok.

You're probably already aware, but all transforms are 6D transforms relative to the parent frame, using xyz (metres) and rpy (radians).

But xacro supports Python expressions these days, so it may be that it's more convenient to use a different representation in the .yaml and then use some math to get to an appropriate representation in the .xacro.

---

The referenced PR against ros-industrial/universal_robot stores similar data in the .yaml and then post-processes that in the .xacro.

[nilsmelchert]

The referenced PR against ros-industrial/universal_robot stores similar data in the .yaml and then post-processes that in the .xacro.

I had a look at that PR and everything you said sounds reasonable. The only thing I did not find was the "post-processing" script you just mentioned. Is it already available somewhere? I might be able to compare it to my scripts.

You're probably already aware, but all transforms are 6D transforms relative to the parent frame, using xyz (metres) and rpy (radians).

Yes, I am aware of that. Besides that, I figured that staubli is using the Cardan representation, in contrast to ros and specifically xacro, where the RPY convention is used.

[gavanderhoorn]

@nilsmelchert: I'm curious to know whether you've made any progress with this?

[nilsmelchert]

@gavanderhoorn : I had to take a break concerning this small project due to some side projects in my job. But the first results looked pretty good. I will continue working on this in about two weeks.

[gavanderhoorn]

Still interested in your progress @nilsmelchert: any updates?

[gavanderhoorn]

:bellhop_bell:

[gonzalocasas]

+1 to this idea, would love to take a look at your approach

[nilsmelchert]

Hi, sorry for responding this late. I am currently very busy with other things such as student lectures ;-)

I still have not forgotten this little project and get back at it as soon as I can. Probably in about 2 weeks.

[gavanderhoorn]

Is there anything you could use help with?

[nilsmelchert]

I might. But first I would have to describe the approach that I am following mathematically here. Is there a way to compile Latex in github issues?

[gavanderhoorn]

Is there a way to compile Latex in github issues?

Not really convenient, but a few options:

• https://gist.github.com/a-rodin/fef3f543412d6e1ec5b6cf55bf197d7b (for simple stuff)
• https://stackoverflow.com/questions/11256433 (using image generation/rendering service)

perhaps nicer (but require some setup):

• https://github.com/leegao/readme2tex (command line tool)
• https://github.com/agurodriguez/github-texify (github webapp version of this tool)

[nilsmelchert]

The latter looks interesting. I will create a repo and link it as soon as I am done.

[gavanderhoorn]

Still interested in this :)

[gavanderhoorn]

While I (and others) would still be interested in this, I guess @nilsmelchert is not working on this any more.

Closing for now.

We can re-open at a later time.

[LucasLabarussiat]

Hello,

I know this issue has been closed, but I was wondering if anyone has tackled this since then ? Even if the entire thing with macros and yaml files isn't available, I'd still be glad to have a look at the parser or even just the maths behind it ! @nilsmelchert any chance ?