ROS 2 robot_state_publisher improvements

[rhaschke]

I very much agree with @peci: The robot_state_publisher is just yet another client consuming a robot model. Providing the robot model shouldn’t be bound to this node. All that matters is that clients can access a robot model that is coherent across all clients. I think this is the crucial point, not yet discussed at all: What are / will be the mechanisms to ensure that all clients operate on the very same model?
In this regard, the mechanism proposed by @gavanderhoorn is dangerous: If all clients need to “integrate” incremental changes on their own, it’s likely that they end-up in an inconsistent state.
However, as @peci1 pointed out: Having a central node that integrates such changes and publishes them, will be perfectly fine.
I’m not very deep into ROS2 yet, but from the discussion here I’ve learned that ROS2 publishes its robot_description via a latched topic. How do you ensure security/consistency there? Isn’t it possible that any node publishes on the topic? So you can screw up your robot description accidentally or adversarially? In my point of view, there should be a unique, trusted node that publishes the robot description in a consistent fashion.

[gavanderhoorn]

@rhaschke

In this regard, the mechanism proposed by @gavanderhoorn is dangerous: If all clients need to “integrate” incremental changes on their own, it’s likely that they end-up in an inconsistent state.

Algorithms that ensure consistent state across multiple distributed entities have existed for quite some years now (decades even). This is not a new problem and it’s not dangerous.

It would be good to take a look at the field of distributed and parallel computing.

Systems like etcd fi offer exactly this.

---

But it’s all off-topic. Sorry @clalancette

[gbiggs]

@clalancette

I guess it is a matter of perspective. We allow changing the node name for some good reasons, but I still think of it more like an “identifier”, rather than a totally fungible resource. So renaming yourself to “become” another node seems like a lie to me. I view topics, on the other hand, as fungible. But you are right, your method would work.

I think differentiating between the type of a node and the name of a node is important. Possibly parameters are ambiguous on this, which is something that should be made clear one way or the other in the future, but for topics, services and actions it is perfectly reasonable for one node to masquerade as a commonly-used node’s type.

@smac

If some of these transforms are changing, they’re probably not being given out by the URDF but by TF updates.

The purpose of changing the URDF is not to change transforms so much as to change the structure of the robot itself, which includes changing some transforms, adding others and removing still others.

[clalancette]

@rhaschke

I’m not very deep into ROS2 yet, but from the discussion here I’ve learned that ROS2 publishes its robot_description via a latched topic. How do you ensure security/consistency there? Isn’t it possible that any node publishes on the topic? So you can screw up your robot description accidentally or adversarially? In my point of view, there should be a unique, trusted node that publishes the robot description in a consistent fashion.

The answer to the security question is pretty much the same answer as for all of ROS; use appropriate security mechanisms (VPNs, SROS, etc). From that perspective, the robot_description topic is no different than dozens of other topics that can cause robots to do bad things.

I would say the “resilient-to-bugs” answer is similar. While we could move the publication to a trusted node, it’s just moving the problem around. In this respect, robot_state_publisher just could be the trusted node.

@gavanderhoorn

But it’s all off-topic. Sorry @clalancette

For what it is worth, I think all of these perspectives are quite interesting. And this is a good thread of ideas for people who want to really tackle the problem in the future. I just wanted to make it clear from the outset that I have do not have the time currently to do anything more radical than what I’ve already done.

@gbiggs

The purpose of changing the URDF is not to change transforms so much as to change the structure of the robot itself, which includes changing some transforms, adding others and removing still others.

Right, the whole purpose of robot_state_publisher is to do these TF updates as the robot moves around. The “new” thing here is the ability to update the URDF so that you can add/remove pieces from the robot.

[peci1]

@clalancette

Right, the whole purpose of robot_state_publisher is to do these TF updates as the robot moves around. The “new” thing here is the ability to update the URDF so that you can add/remove pieces from the robot.

Which brings another long unresolved problem. There’s no “proper” way to remove a static TF. What I do in our system is that I re-parent deleted static TFs under a “trash” TF parent that’s disconnected from all proper TFs. But that’s a workaround, not a solution.

[gavanderhoorn]

A few of us were discussing a “next gen urdf” over in ROS-Industrial. As it seems this is (turned into) a(n) almost parallel discussion, I thought of linking the two:

Consideration of STEP or Collada for Describing the ROS Environment

Received some great notes from the recent developers’ meeting hosted by @Levi-Armstrong and I figured I would post them hear to drive a continued discussion. From Levi… The primary discussion was on what the format will be for describing ROS environment. The current supported candidates are SDF and URDF, but should we move toward an industry standard like STEP or collada. The recommendation was to get a ROS2 working group put together to select the next format going forward. It was also discus…

[clalancette]

@gavanderhoorn Thanks for the link. The thing is, the decision about what file formats to support is actually somewhat orthogonal to robot_state_publisher. It’s not entirely clear from the documentation, but URDF is actually two separate things:

1. A file format where you can specify robot geometries
2. An API allowing downstream consumers to load robot-geometry-specifying file formats. For instance, robot_state_publisher supports loading in COLLADA files via this API.

So no matter what we agree on in the other thread, robot_state_publisher should be able to take advantage of it via the URDF API (once appropriate support is developed).

[gavanderhoorn]

@clalancette

The thing is, the decision about what file formats to support is actually somewhat orthogonal to robot_state_publisher.

Thanks Chris, but I am actually aware of that

I just thought, seeing the amount of posts in this thread about URDF, robot_state_publisher, “next gen” URDF and some people mentioning support for runtime updates to robot models I’d link the discussion we have in ROS-Industrial as selecting a format with support for all that is important there.

With most discussions about “future technology” happening in Next Generation ROS, it’s sometimes hard to keep track of discussions that happen in other categories. That’s why I posted the link.

I promise not to go off-topic here any more