Skip to content

Conversation

@wgtayar
Copy link

@wgtayar wgtayar commented Sep 17, 2025

Summary

This PR extends odrive_status.msg and updates the odrive_can_node implementation to support multi-ODrive setups by disambiguating messages and adding temporal context.

Motivation

The existing implementation works for a single ODrive but makes it impossible to distinguish messages when multiple ODrives are connected. Additionally, messages lacked a timestamp, complicating debugging, logging, and synchronization with other ROS data streams.

These changes:

  • Enable reliable use of multiple ODrives in one ROS system.
  • Improve traceability and debugging with accurate timestamps.
  • Reduce overhead by defining node_id once.

This inspiration comes from working on a system with multiple ODrives, such as a quadruped robot.

Changes

  • Message definition

    • Added std_msgs/Header header (provides stamp).
    • Added uint32 node_id field to uniquely identify each ODrive device.
  • Publisher logic (odrive_can_node.cpp)

    • header.stamp is now assigned immediately before current and voltage measurements are taken, ensuring accurate timing of values.
    • node_id is defined once at initialization, rather than being re-set in every loop iteration.

Testing

  • Verified build with colcon build.
  • Ran ros2 topic echo /odrive_axis*/odrive_status with two ODrives connected:
    • Confirmed each message contains the correct node_id.
    • Confirmed header.stamp updates consistently at each publish cycle.

Notes

  • This is a message definition change. Downstream packages depending on odrive_status.msg must be rebuilt.
  • Maintainers: please confirm if uint32 is suitable for node_id or if a smaller type is preferred.

@CLAassistant
Copy link

CLAassistant commented Sep 17, 2025

CLA assistant check
All committers have signed the CLA.

@wgtayar wgtayar changed the title CMakeLists and package.xml for correct inclusion of std_msgs feat: multi-ODrive support with node_id + timestamp in odrive status message Sep 17, 2025
@wgtayar wgtayar marked this pull request as ready for review September 17, 2025 14:46
@@ -1,3 +1,5 @@
std_msgs/Header header
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we're not using any of the other fields in Header, is there any downside to just using time timestamp directly?

@@ -1,3 +1,5 @@
std_msgs/Header header
uint32 node_id
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your PR description states that this node_id should serve to distinguish two or more ODrive sources. But the typical way to do this that I know of is via the topic path on which they are published:

ros2 topic echo /odrive_axis0/odrive_status
ros2 topic echo /odrive_axis1/odrive_status
...

Is there a scenario where this does not work?

pkg: "odrive_can"
exec: "odrive_can_node"
name: "can_node7"
namespace: "odrive_axis0"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these names should be different for each instance

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants