Conversation
| # ——— 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 |
There was a problem hiding this comment.
@MarqRazz I'm still getting together my ideas in a different one. How about something like this?
saikishor@db470af
There was a problem hiding this comment.
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.
| 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? |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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?) |
There was a problem hiding this comment.
no other reason than that everything else was also uint8, maybe here specifically we could go higher?
bmagyar
left a comment
There was a problem hiding this comment.
Thank you! Let's merge this as-is and do updates in a new PR
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.