Added 4th section regarding robot control. by michalpelka · Pull Request #10 · RobotecAI/wip-openusd-interoperability-rep

michalpelka · 2026-03-30T13:31:16Z

Added robot control proposal.

rep.md

Signed-off-by: Michał Pełka <michal.pelka@robotec.ai>

Added `ROS2JointStateBroadcasterAPI`. Created differentiation between `ROS2IntegratedControlAPI` and `Ros2IntegratedControlAPI`. Signed-off-by: Michał Pełka <michal.pelka@robotec.ai>

Signed-off-by: Michał Pełka <michal.pelka@robotec.ai>

michalpelka · 2026-04-03T15:31:10Z

Applied ROS 2 is ROS for schema as well in this PR. Tested with usdcat and usdGenSchema.py.

rep.md

Co-authored-by: Michał Pełka <michal.pelka@robotec.ai>

adamdbrw

Strong contribution, thank you @michalpelka. I have some comments per sections, and please also consider to make it more concise (I am slowly applying this over entire REP).

adamdbrw · 2026-04-07T11:37:56Z

rep.md

+- `rel ros:rigid_body_twist:body`: Reference to a prim with 
+  `UsdPhysicsRigidBodyAPI` for applying velocities.
+
+- `double ros:rigid_body_twist:cmd_vel_timeout`: Timeout in seconds after 


This seems to be a runtime deployment parameter, not a piece of an asset. The argument for is plug-and-play assets, batteries included approach. At most, I would keep all such parameters separate and as "hints" to streamline plug-and-play operation of robot.

This approach could work if tooling supports parameters override through ros2 param set / params.yaml

adamdbrw · 2026-04-07T11:48:38Z

rep.md

+and the controller should publish odometry data to a topic with type `nav_msgs/Odometry`.
+Implementation should follow logic similar to the `diff_drive_controller` in `ros2_controllers` package.
+
+- `rel ros:diff_drive:subscriber`: Reference to prim with `ROSTopicAPI` for subscribing to velocity commands.


Suggested change

- `rel ros:diff_drive:subscriber`: Reference to prim with `ROSTopicAPI` for subscribing to velocity commands.

- `rel ros:diff_drive:subscriber`: relationship targeting a prim with the RosTopicAPI with `role="subscription"` that provides the velocity commands for this controller.

adamdbrw · 2026-04-07T11:49:40Z

rep.md

+- `rel[] ros:diff_drive:right_wheels`: References to prims with `UsdPhysicsDriveAPI` representing right wheel joints.
+- `double ros:diff_drive:wheel_separation`: Distance between left and right wheels in meters.
+- `double ros:diff_drive:wheel_radius`: Radius of the wheels in meters.
+- `double ros:diff_drive:cmd_vel_timeout`: Timeout in seconds after which the command is considered stale. Default: `0.5`.


See the other comment on cmd_vel_timeout

adamdbrw · 2026-04-07T11:52:28Z

rep.md

+- `rel ros:joint_trajectory:server`: Reference to a prim with `ROSActionAPI` 
+  for receiving trajectory action goals.
+- `rel[] ros:joint_trajectory:command_joints`: References to prims with `UsdPhysicsJointAPI`.
+- `double ros:joint_trajectory:action_monitor_rate`: Frequency in Hz for 


Similarly, this is a dynamic parameter, and so is the timeout (below).

adamdbrw · 2026-04-07T11:54:07Z

rep.md

+Implementation needs to check the name for [custom joint names](rep.md#29-custom-names-to-ros-joints) in `ros:joint:name` 
+property of the joint prims and use it for mapping trajectory points to joints in the simulator.
+
+- `rel ros:joint_state_broadcaster:publisher`: Reference to a prim with `ROSTopicAPI` for publishing joint state data.


Suggested change

- `rel ros:joint_state_broadcaster:publisher`: Reference to a prim with `ROSTopicAPI` for publishing joint state data.

- `rel ros:joint_state_broadcaster:publisher`: relationship targeting a prim with the RosTopicAPI with `role="publisher"` for joint state data.

adamdbrw · 2026-04-07T11:54:20Z

rep.md

+
+- `rel ros:joint_state_broadcaster:publisher`: Reference to a prim with `ROSTopicAPI` for publishing joint state data.
+- `rel[] ros:joint_state_broadcaster:joints`: References to prims with `UsdPhysicsJointAPI` representing the joints whose states are to be broadcast.
+- `double ros:joint_state_broadcaster:publish_rate`: Frequency in Hz at which joint states are published.


dynamic parameter.

adamdbrw · 2026-04-07T12:02:35Z

rep.md

 OpenUSD cameras natively face the -Z axis, whereas ROS optical frames (REP 103) must face +Z. To bridge this without opaque simulator-side rotations, authors must decouple the physical sensor from its optical interface. Authors must create a child UsdGeomXform (e.g., `camera_optical_frame`) rotated 180 degrees around its local X-axis. All RosTopicAPI and RosFrameAPI schemas must be applied exclusively to this optical frame, ensuring deterministic data orientation in RViz.

---
+### 2.9 Custom names to ROS joints.


We need to align with IsaacJointAPI isaac:nameOverride so that there is no duplication for Isaac Sim assets. Since this PR is more general (e.g. does not name a particular simulator), I would opt for this approach. @ayushgnv could you comment? Perhaps there is an extra rationale for this attribute in-schema?

adamdbrw · 2026-04-07T12:04:19Z

rep.md

+
+In application level simulation, the simulator simulates the robot as a whole, including its physical properties, kinematics, and dynamics.
+This approach is meant to be used for application testing (e.g. whole robotics stacks, mapping, localization frameworks).
+In this approach the controller is integrated in the simulator codebase and managed by parameters of the prim and ROS communication.


I would love a connection to assets here - how these approaches reflect on OpenUSD assets (this can be deduced but lets make it clear).

adamdbrw · 2026-04-07T12:16:36Z

rep.md

 *   **API Translation:** Ros*API schemas must map exclusively to modern extension blocks (e.g., SDF `<plugin>`, MJCF `<extension>`). Obsolete approaches such as injecting legacy `<gazebo>` tags into URDF are not allowed.
 *   **Discard, not inject:** OpenUSD-native metadata (layer stacks, unselected variants) must be cleanly discarded. Injecting custom, non-standard XML elements to store unmappable OpenUSD states is not recommended. If pipeline necessitates it for practicality, such metadata must be confined to valid, format-native extension points.

+## 4. Robot Control


I see this as a good approach:

Most representative cases are covered by convenience application-level schemas.

Developers should fall back to generic hardware-level interfaces for other cases (which there are multiple of).
However, this is not clear from the reading - could you please rephrase this intro chapter and add extra clarifications in the sub-chapters as well? Someone could be confused and ask "where's the Ackermann, what about my custom ML policies"? Also, please refer to ML policies directly as this is a key aspect.

Regarding the dynamic parameters - it would be great to address that these are only hints, and should be subject to tuning / overrides.

michalpelka requested a review from adamdbrw March 30, 2026 13:52

michalpelka mentioned this pull request Mar 30, 2026

Work in progress: Items to address #6

Open

7 tasks

michalpelka commented Mar 31, 2026

View reviewed changes

rep.md Outdated Show resolved Hide resolved

michalpelka force-pushed the mp/control branch from 8f05ce5 to ee824aa Compare April 3, 2026 14:30

michalpelka added 2 commits April 3, 2026 16:36

Added 4th section regarding robot control.

032622a

Signed-off-by: Michał Pełka <michal.pelka@robotec.ai>

Added ros2:joint:name custom attribute instead of ROS2JointAPI schema.

84b460b

Added `ROS2JointStateBroadcasterAPI`. Created differentiation between `ROS2IntegratedControlAPI` and `Ros2IntegratedControlAPI`. Signed-off-by: Michał Pełka <michal.pelka@robotec.ai>

michalpelka force-pushed the mp/control branch from ee824aa to 23fc3bd Compare April 3, 2026 14:41

Applied ROS 2 is ROS to rep.md

1521383

Signed-off-by: Michał Pełka <michal.pelka@robotec.ai>

michalpelka force-pushed the mp/control branch from 23fc3bd to 1521383 Compare April 3, 2026 14:45

michalpelka added 2 commits April 3, 2026 17:28

Applied ROS 2 is ROS to rep.md

1fb2c0e

Signed-off-by: Michał Pełka <michal.pelka@robotec.ai>

ROS 2 is ROS in schema.usda

167df1c

Signed-off-by: Michał Pełka <michal.pelka@robotec.ai>

michalpelka requested a review from zakmat April 7, 2026 08:36

michalpelka commented Apr 7, 2026

View reviewed changes

rep.md Outdated Show resolved Hide resolved

Update rep.md

36767ba

Co-authored-by: Michał Pełka <michal.pelka@robotec.ai>

adamdbrw reviewed Apr 7, 2026

View reviewed changes

	- `rel ros:diff_drive:subscriber`: Reference to prim with `ROSTopicAPI` for subscribing to velocity commands.
	- `rel ros:diff_drive:subscriber`: relationship targeting a prim with the RosTopicAPI with `role="subscription"` that provides the velocity commands for this controller.

	- `rel ros:joint_state_broadcaster:publisher`: Reference to a prim with `ROSTopicAPI` for publishing joint state data.
	- `rel ros:joint_state_broadcaster:publisher`: relationship targeting a prim with the RosTopicAPI with `role="publisher"` for joint state data.

Conversation

michalpelka commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

michalpelka commented Apr 3, 2026

Uh oh!

Uh oh!

adamdbrw left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

michalpelka commented Mar 30, 2026 •

edited

Loading