Hi all,
currently we are working on ROS2-based networked (distributed) robotic systems with focus on communication aspects. By doing so, it became clear to us that current URDF specifications lack a way to represent:
- Physical Interfaces: Components like power plugs, Ethernet ports, and other communication connectors are critical for modeling how robots interact with their environments and peripherals.
- Computing Components: Control boxes and onboard computers are integral to networked robotic operation but are not explicitly modeled in URDF.
We propose to add the following elements:
Add a hardware_interface element
Define physical interfaces (e.g., plugs, ports) as a new tag. These interfaces can be attached to links, representing their location on the robot.
Attributes:
name: Unique identifier for the interface.type: Type of interface (e.g., USB, RJ45, AC_power, etc.).position: Relative position of the interface on the link.specifications: Optional block for detailed specifications like voltage, current, bandwidth, or protocol.
Example:
<link name="base_link">
<hardware_interface name="power_plug">
<type>AC_power</type>
<position xyz="0.1 0.0 0.05" rpy="0 0 0"/>
<specifications>
<voltage>220</voltage>
<current>10</current>
</specifications>
</hardware_interface>
<hardware_interface name="ethernet_port">
<type>RJ45</type>
<position xyz="0.2 0.0 0.05" rpy="0 0 0"/>
<specifications>
<bandwidth>1Gbps</bandwidth>
<protocol>TCP/IP</protocol>
</specifications>
</hardware_interface>
</link>
2. Add a computing_component element
Model computing components such as control boxes, embedded computers, or microcontrollers. (Note, that Control boxes can be modeled as separate links or as part of the robot’s body.)
Attributes:
name: Unique identifier for the computing component.type: Type of computing hardware (e.g., Industrial_PC, Microcontroller).position: Position of the component on the link.specifications: Detailed specs such as CPU, RAM, storage, and supported interfaces.
Example:
<link name="control_box">
<computing_component name="main_computer">
<type>Industrial_PC</type>
<position xyz="0.0 0.0 0.0" rpy="0 0 0"/>
<specifications>
<cpu>Intel i7</cpu>
<ram>16GB</ram>
<storage>256GB SSD</storage>
<network_interfaces>
<interface name="eth0" type="RJ45" bandwidth="1Gbps"/>
<interface name="wifi" type="WiFi" bandwidth="300Mbps"/>
</network_interfaces>
</specifications>
</computing_component>
</link>
3. Add a connections element
Model how physical interfaces and computing components connect to each other.
-
Attributes:
source: The source interface (e.g.,link_name:interface_name).target: The target interface (e.g.,link_name:interface_name).type: Type of connection (e.g., AC_power, Ethernet).cable_length: Optional, for modeling physical constraints.
-
Example:
<connections>
<connection>
<source>control_box:power_plug</source>
<target>base_link:power_plug</target>
<type>AC_power</type>
<cable_length>2.0</cable_length>
</connection>
<connection>
<source>control_box:ethernet_port</source>
<target>sensor:ethernet_port</target>
<type>Cat5e</type>
<cable_length>5.0</cable_length>
</connection>
</connections>
We beleive that the above extensions have the following advantages:
- Provides a more accurate representation of the components of networked (distributed) robotic systems where communication is important and has to be modeled.
- Facilitates mapping between physical interfaces and ROS 2 nodes (as communication end points).
- Supports complex systems with multiple computing components as elements of robots, and networking setups.
As for backward compatibility, existing URDF parsers can safely ignore the new tags if not required.
I’d love to hear your thoughts on this proposal. Specifically, does this extension align with your use cases? Are there additional features or components that should be included?
Looking forward to your feedback and suggestions.
Attila