Skip to content

Hardware Status comments#66

Merged
bmagyar merged 1 commit intoros-controls:masterfrom
MarqRazz:hardware_status_comments
Jul 23, 2025
Merged

Hardware Status comments#66
bmagyar merged 1 commit intoros-controls:masterfrom
MarqRazz:hardware_status_comments

Conversation

@MarqRazz
Copy link
Contributor

@MarqRazz MarqRazz commented Jul 1, 2025

Here are some general thoughts I had on the hardware_status. Sorry they are not very organized, so feel free to add questions where it's not clear.

# ——— Health & Error ——————————————————————————————————————————————
uint8 health_status # see HealthStatus enum
uint8 error_domain # see ErrorDomain enum
uint8[] error_domain # Array of device errors, because hardware can throw more than one, see ErrorDomain enum
Copy link
Member

Choose a reason for hiding this comment

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

@MarqRazz I'm still getting together my ideas in a different one. How about something like this?
saikishor@db470af

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I really like the idea of using diagnostic_msgs/KeyValue but unless there are some standardized keys then we won't have an agnostic framework like we do with JointState. We also have the issue that everyone would be required to convert the value from string to ___ type.

GPIO in ros2_control is also not standardized and completely free form other than the value is always a double (see my comments on UR's setup). Users are allowed to name the state and command interfaces anything they want which means any code downstream is specific to the hardware_interface they implemented it against and would require changes if they switched or wanted to support multiple robot brands (even though both brands offer digital IO through their hardware_interface). Now I don't think we can come up with some format that can meet all use cases for every user but do believe we could add some base standards here that could make users code more modular and hardware agnostic.

Copy link
Contributor

@soham2560 soham2560 left a comment

Choose a reason for hiding this comment

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

partial review

uint8 MODE_AUTONOMOUS =2
uint8 MODE_SAFE =3
uint8 MODE_AUTO =2 # automatic mode when the driver is remote controlling the hardware
uint8 MODE_SAFE =3 # what is the expected use case for this mode?
Copy link
Contributor

Choose a reason for hiding this comment

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

the idea was that when a safety sensor is touched on the robot, and it has to halt operation, this is what would be reported, in hindsight could've been named better

uint8 POWER_ON =3
uint8 POWER_SLEEP =4
uint8 POWER_ERROR =5
# Battery power states see [BatteryState.msg](https://docs.ros2.org/foxy/api/sensor_msgs/msg/BatteryState.html)
Copy link
Contributor

Choose a reason for hiding this comment

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

opinion on directly having that message here? goes back to the discussion in the meet, should we directly plop in messages from elsewhere or create our version of them. just a thought

For example, the `ErrorDomain` enum could be redefined as a bitmask:
```
# Example ErrorDomain as a bitfield
# Example ErrorDomain as a bitfield (why only an 8 bit number?)
Copy link
Contributor

@soham2560 soham2560 Jul 10, 2025

Choose a reason for hiding this comment

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

no other reason than that everything else was also uint8, maybe here specifically we could go higher?

Copy link
Member

@bmagyar bmagyar left a comment

Choose a reason for hiding this comment

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

Thank you! Let's merge this as-is and do updates in a new PR

@bmagyar bmagyar merged commit 170a0f1 into ros-controls:master Jul 23, 2025
2 checks passed
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.

4 participants