Split joint trajectory controller

edit

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??

1. 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.
2. 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.
3. 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--

1. 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.
2. 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.