Split joint trajectory controller
I have an arm that uses dynamixel servo motors. I use the dynamixel motor stack along with Moveit! to operate it. The dynamixel stack is structured very similarly to ros_control, however, it is not directly compatible with it. It comes with it's own joint_trajectory_action_controller that interfaces with Moveit!. It looks like the author rewrote the joint_trajectory_action_controller so that he could broadcast positions/velocities of mutliple joints on the bus simultaneously and improve performance.
I have another motor that I want to put into the same kinematic chain as the arm (prismatic slider for the arm). I wrote the interface to it, and it is a standard ros_control hardware_interface. So I am faced with the problem of how to handle the trajectory action interface from Moveit!
Should I??
- Include each dynamixel joint in my hardware_interface, sacrificing the performance improvements made by @arebgun. Then I would use the standard joint_trajectory_action_controller.
- Somehow nest action servers so that the top one takes the request from !Moveit and separates it into dynamixel and "other" and then passes it own.
- Or is there some simple answer I am missing?
I am mostly asking from a typical architecture of ros_control point of view, as I assume I am not the first person to have this problem.
--EDIT in response to @DaveColeman--
- I guess that was my real question, has anyone thought of a clever way to do this yet. In the dynamixel version of joint_trajectory_action_controller he uses the low level function set_multi_position_and_speed. I guess I could write a dynamixel "multi joint controller" that looks similar but takes a topic of vel/pos commands instead of implementing an action server. Then I could wrap that node with my hardware interface and run it from the ros_controls joint_trajectory_action_controller.
- Did you mean one controller_manager? I have noticed this feature, but I'm not sure I understand it well enough to leverage it for this particular situation. I definitely see the advantage of having multiple hw_interfaces as I would prefer one for arm one for base etc. However, my problem is how to wrap the dynamixel stack without losing pos/vel (@arebgun only exposes position in his nodes but one could write a node exposing both) or the ability to broadcast across the 422 bus to multiple motors/joints.
What @arebgun did is quite good, all the bus i/o interface is controlled by one class and all the controllers have shared pointers to it. The dynamixel controller_manager gets status/diagnostics on all the connected motors. It seems like it will be hard to not sacrifice some performance if this was re-written to work on a controller by controller basis in ros_control. But likely I don't understand the the ros_control architecture well enough to determine that, suffice to say I'm not sure how to do it.