Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Staubli-DH: Offset parser to URDF #35

Closed
nilsmelchert opened this issue Jul 30, 2019 · 21 comments
Closed

Staubli-DH: Offset parser to URDF #35

nilsmelchert opened this issue Jul 30, 2019 · 21 comments

Comments

@nilsmelchert
Copy link
Contributor

nilsmelchert commented Jul 30, 2019

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
Copy link
Member

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 ros-industrial/universal_robot#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
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

gavanderhoorn commented Aug 5, 2019

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
Copy link
Contributor Author

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
Copy link
Member

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

@nilsmelchert
Copy link
Contributor Author

@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
Copy link
Member

Still interested in your progress @nilsmelchert: any updates?

@gavanderhoorn
Copy link
Member

🛎️

@gonzalocasas
Copy link
Contributor

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

@nilsmelchert
Copy link
Contributor Author

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
Copy link
Member

Is there anything you could use help with?

@nilsmelchert
Copy link
Contributor Author

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
Copy link
Member

Is there a way to compile Latex in github issues?

Not really convenient, but a few options:

perhaps nicer (but require some setup):

@nilsmelchert
Copy link
Contributor Author

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

@gavanderhoorn
Copy link
Member

Still interested in this :)

@gavanderhoorn
Copy link
Member

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
Copy link

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 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants