We have a robot using MoveIt & OMPL for its movements. In our robot, we have some parts that are not actuated but depend on the state of other joints.
Example: we have a cable that is pushed&pulled depending on the extension of our arm. We managed to integrate it in the URDF using multiple mimic joints, but this solution is limited to a linear relation between one joint and the mimic joint.
We would like to be able to specify a complex kinematic relation between joints, for example using a passive joint and an IK plugin. This IK would be used to update the robot model when checking collisions, for example.
I believe this is not too far from the already existing transmission API of the URDF format.
Is there anyone out there with the same issue? What do you think of this use case?
I know your pain! Mimic joints leave much to be desired in how narrowly useful they are.
In my experience, you should consider URDF to be a “fixed specification” – in other words, you should look for alternative ways to add new information because you will have a hard time changing the spec.
For example, URDF joint limits only provide position, velocity, and effort limits, and there have been a whole bunch of discussions in the MoveIt space on adding acceleration limits to the allowable set of tags. This has gone nowhere due to the “slippery slope” argument: that is, if we add acceleration limits, then someone is going to want jerk limits next, etc. There is validity to this, as you will certainly encounter scope creep from implementing every such request.
This is why many tools provide their own supplemental information (e.g., MoveIt with SRDF and joint limits YAML files), have their own parsers that can parse additional tags in URDF files (e.g., <ros2_control> or <drake> tags), or even make their own alternative formats (e.g., the MJCF format from MuJoCo).
I agree with @scastro. It is better to include this additional information in the imported model or by writing a custom parser. Pinocchio also provides some level of support for this.
Just FYI, I think part of the problem related to modifying the URDF spec is that currently there is no version control (i.e. git) or versioning (i.e. git tags) of the spec itself, so it is not possible to discuss changes in the spec itself.
The URDF format, in its current state, is insufficient for accurately describing our robots. The necessary workarounds, as demonstrated here, are indicative of a broader problem. Certain robot architectures, including delta robots, are not supported by URDF. We require a more robust and comprehensive robot description format to meet our current and future needs.
With limited effort, how would you overshoot an acceleration limit? Isn’t the acceleration limit just a consequence of the effort limit and other properties?
But back to the main question: on hand, I’d be happy if URDF format could evolve, but on the other hand, it’s nice it has been stable for so long - writing a parser is quite easy.
An implementation note: the urdfdom library is (for a reason unknown to me) distributed as a standard Ubuntu package from Ubuntu repos (not from OSRF repos). That means that pushing even the slightest change of this library to already released Ubuntu repos is almost a heroic task. I remember a fix for float parsing took almost 3 years back in the time of ROS Indigo. And new features will not get into released distros at all. That means that if you’d get an URDF update merged now, the first distro to offer it for ROS would be 26.04.
Several years back, I was behind adding acceleration limits to the Drake URDF parser for exactly these reasons. It helped, of course, that we already had an accepted pattern for <drake:tag name>-style non-standard tag support.
With limited effort, how would you overshoot an acceleration limit? Isn’t the acceleration limit just a consequence of the effort limit and other properties?
Practically speaking, on a huge number of robots all of the entries in limits are bounds applied/expected by the controller(s), rather than any direct property of the physical hardware. For a large industrial robot, the limits are usually defined around operating at maximum extension and maximum payload - so you could easily exceed maximum allowable acceleration by applying near-maximum effort with a lower payload and/or lower extension.
With limited effort, how would you overshoot an acceleration limit? Isn’t the acceleration limit just a consequence of the effort limit and other properties?
When you are controlling in position control mode, you can limit/optimize the desired position to respect these limits and send the references accordingly, because any reference without respecting these limits will cause the system to be unable to track the reference. I would say this is needed and jerk limits can be used to smooth further. Same goes for the velocity control mode too, with the acceleration limits, you can control the rate at which you can change the velocity
An implementation note: the urdfdom library is (for a reason unknown to me) distributed as a standard Ubuntu package from Ubuntu repos (not from OSRF repos).
This is really a distinction without a difference. For example, the limits on a robot arm are virtually always the limits that its onboard controller enforces, exceedingly rarely are they the physical hardstops. Effort limits are entirely non-physical in virtually all cases; extremely few robot arms are going to allow you to continuously run actuators at the actual maximum possible power level. Velocity limits are generally equally non-physical; they are practically well below the maximum angular velocity that the weakest component of the drivetrain could survive.
Trying to draw a hard line between “hardware” limits and “controller” limits is nearly impossible, and the current line essentially privileges the onboard controller (its limits are “hardware”) at the expense of anything implemented elsewhere (their limits are “control”), and it only makes it harder to implement effective controllers in standard ROS.
I strongly believe they are a part of robot hardware information. Most of the motor control boards like ELMO, ingenia requires this information and most of the actuators need this information and this makes it a part of the hardware. Having velocity limit alone makes the hardware look like it can achieve that velocity with infinity acceleration, but this is not the case most of the time. You have another entity “acceleration” and “deceleration” that it depends on. Regarding your point on reflecting them on controller end, What most of the controllers mostly use are the conservative limits rather than the real hard limits the hardware can achieve.
I agree with you @calderpg-tri, if we are developing new robots with ROS-provided control architectures like ros2_control instead of commercial robots which come with their own control architecture. This information is crucial to implement effective controller or hardware drivers in standard ROS
If I recall correctly, urdfdom was moved to be an upstream Debian/Ubuntu package to permit to reuse it in Gazebo packages (in particular in sdformat) that at that time were packages as upstream Debian/Ubuntu packages. However, as of Ubuntu 24.04 that is not anymore the case, but nevertheless urdfdom is also packaged in upstream Ubuntu repos, and it seems that somehow the Ubuntu version is still used even in ROS packages via the liburdfdom-dev rosdep key, see for example:
I looked in why we can’t simply remove the liburdfdom-dev rosdep key, but at the first glance it seems that rosdep keys are shared between ROS 1 and 2 and differerent ROS distros, so it is tricky to deprecate/remove existing rosdep keys.