Propose additional primitive types for interface-handles. #39
Conversation
|
I think |
|
The other way to handle this, I suppose, is just add ROS publishers/subscribers to the controllers. Since ROS2 messaging has real time capability now. It seems like this would duplicate a lot of the core messaging functionality of ROS2 itself. |
I've posited something similar in #17. At least at that point in time, the performance of the available executors was not deemed sufficient. I still hope we can go in that direction though. If you're interested in something like that, I'd suggest taking a look at OROCOS (with the new ROS 2 integration). |
I don't understand what do you mean? This is a concept for data storage inside the framework, i.e., exchanging data between hardware and controllers. Controller should than publish those for the rest of the ROS-World |
| @@ -0,0 +1,16 @@ | |||
| # Extension of types used for command and state interfaces | |||
|
|
|||
| For introduction the file about general [purpose inputs/outputs in ros2_control](non_joint_command_interfaces.md). | |||
There was a problem hiding this comment.
Link does not work for me?
bmagyar
changed the title
|
I touched up some typos but generally the proposal looks sensible. We should at least look at the consequences/possibilities of introducing variable types to the interfaces. A specific demo that uses this would be nice too. |
| @@ -0,0 +1,16 @@ | |||
| # Extension of types used for command and state interfaces | |||
|
|
|||
| For introduction the file about general [purpose inputs/outputs in ros2_control](non_joint_command_interfaces.md). | |||
There was a problem hiding this comment.
Link does not work for me?
| ## Possible solution | ||
| Extend [`ReadOnlyHandle`](https://github.com/ros-controls/ros2_control/blob/93b15787f1d2e16dd41d202cebff5fdbef56e19d/hardware_interface/include/hardware_interface/handle.hpp#L31) to accept other primitive types like `bool`, `int`, and unsigned types. | ||
| This could be simply done by templating the class, or to keep it restricted implementing constructors, getters and setters for those types. | ||
| The latter could become complex to keep track about specific types. |
There was a problem hiding this comment.
Since we are at it, I'd look for a solution that works for any type instead of adding support for a few hard coded ones.
There was a problem hiding this comment.
The link is to the file in PR #38
No description provided.