Shadow controllers not filling controller info correctly

[guihomework]

In the past the, the clean way to access the hand in devel space (not using hand_commander) was to query the list of controllers and match the name with the joint they control as done here https://github.com/shadow-robot/sr_core/blob/indigo-devel/sr_hand/src/hand_commander.cpp#L109

With roscontrol the controller_manager actually contains this information too like here :

name: rh_hand_trajectory_controller
    state: running
    type: position_controllers/JointTrajectoryController
    hardware_interface: hardware_interface::PositionJointInterface
    resources: ['rh_FFJ1', 'rh_FFJ2', 'rh_FFJ3', 'rh_FFJ4', 'rh_LFJ1', 'rh_LFJ2', 'rh_LFJ3', 'rh_LFJ4', 'rh_LFJ5', 'rh_MFJ1', 'rh_MFJ2', 'rh_MFJ3', 'rh_MFJ4', 'rh_RFJ1', 'rh_RFJ2', 'rh_RFJ3', 'rh_RFJ4', 'rh_THJ1', 'rh_THJ2', 'rh_THJ3', 'rh_THJ4', 'rh_THJ5', 'rh_WRJ1', 'rh_WRJ2']

but for standard controller (position controllers or mixed_position_velocity_controllers) this info is empty and would be really helpful.

  - 
    name: sh_rh_wrj2_position_controller
    state: running
    type: sr_mechanism_controllers/SrhJointPositionController
    hardware_interface: ros_ethercat_model::RobotState
    resources: []

The same way it is really weird that the advertized hardware_interface is not of type JointPositionInterface. I suspect this comes from the hack to chain controllers (traj to robotstate), but the info should be hacked also to display a type JointPositionInterface. This info is crucial for control management to see which type of control interface is available

[toliver]

You are right. Currently we are using ros_ethercat_model::RobotState as the hardware interface type as we didn't want to change the structure of our controllers too much when we migrated to ros_control.

We are currently doing some work to make our code more ros_control compliant, and that will eventually include the controllers.

I'll keep you updated on this.

[guihomework]

I just feel that what is displayed in the controller info could be hacked too to hide the hacked hardware interface until this is cleanly fixed by the compliance rework.

[toliver]

Please note that this only "kind of" a hack, but

ros_ethercat_model::RobotState is actually a hardware_interface::HardwareInterface and can be legitimately used as we are using it.

What it is not, is a hardware_interface::HardwareResourceManager. So it doesn't inherit from hardware_interface::ResourceManager and therefore the controller_manager can't show a resources list for it.

We could certainly make it look like a JointPositionInterface, and show the associated resources, but I'm not sure if that would be misleading. My preference is to keep it as it is until we change it to more standard controller type.

[guihomework]

I know you simulate a hardware interface in your controllers, to fake the internal command of the controller to look like an interface used by another controller, where this should normally only be accessible by topics.

I did not look in details but from what you say a controller should be a resource manager and not a hardware interface to provide correct info to the controller manager. Maybe this should be a direction to improve ros_control, admit that a hardware interface could also claim resources and hence fill up the missing data if the controller manager lists them.

I don't see how making a joint_controller advertize it is a jointposition controller is misleading, What is misleading is that the joint position controller are not showing as they are jointposition controller although they respond to /command topics too, even when connected to a joint_traj_controller, at least they try to but the command is erased by the joint_traj_controller if running.

Changing to a standard controller type looks like a long term goal that requires to wait for full support of chaining controllers in ros_control. Not likely to happen soon I think.