extended joint_mode_controller

[bmagyar]

to handle lists of handles, and take strings to define the modes. The accepted string parameters are the names of the corresponding hardware_interfaces for each.

[bmagyar]

Example yaml content to switch the legs of REEM-C to effort mode:

joint_mode_controller:
  type: joint_mode_controller/JointModeController
  mode_handles:
    leg_left_1_joint:  'hardware_interface/EffortJointInterface'
    leg_left_2_joint:  'hardware_interface/EffortJointInterface'
    leg_left_3_joint:  'hardware_interface/EffortJointInterface'
    leg_left_4_joint:  'hardware_interface/EffortJointInterface'
    leg_left_5_joint:  'hardware_interface/EffortJointInterface'
    leg_left_6_joint:  'hardware_interface/EffortJointInterface'
    leg_right_1_joint: 'hardware_interface/EffortJointInterface'
    leg_right_2_joint: 'hardware_interface/EffortJointInterface'
    leg_right_3_joint: 'hardware_interface/EffortJointInterface'
    leg_right_4_joint: 'hardware_interface/EffortJointInterface'
    leg_right_5_joint: 'hardware_interface/EffortJointInterface'
    leg_right_6_joint: 'hardware_interface/EffortJointInterface'

[bmagyar]

@adolfo-rt @lucamarchionni @hilario
This I believe could go upstream.

[awesomebytes]

The example yaml content should use the variable name thingy to not repeat
the same string all the time and so it gets a bit more readable.

It was something like:
leg_left_1_joint: &hipji 'hardware_interface/PositionJointInterface'
leg_left_2_joint: *hipji

(hippy!)

Example file:
https://github.com/pal-robotics/reem_robot/blob/hydro-devel/reem_controller_configuration/config/joint_trajectory_controllers.yaml

@adolfo-rt https://github.com/adolfo-rt @lucamarchionni
https://github.com/lucamarchionni @hilario https://github.com/hilario
This I believe could go upstream.

—
Reply to this email directly or view it on GitHub
#41 (comment)
.

[bmagyar]

That is true sir, thank you for your feedback.

[po1]

Did you try it on a robot?

[bmagyar]

Only on the simulated one. I'm only done with the simulation HAL, the other one is on the way.

[davetcoleman]

In Indigo we dropped support for rosbuild - should this PR target indigo and not include rosbuild stuff in cmakelists?

[bmagyar]

Note taken

[davetcoleman]

From email:

Secondly, I changed the controller to take a dictionary of joints and modes to do the switch. We have the use-case where we only want to change the arms, legs to effort but keep the other in position or change all at once.

I haven't given this much thought, or read into it, but this seems to be adding too much complexity. If you want to change different groups to different control modes, shouldn't they just be in different controllers? This would allow you to have different joint_mode_controllers right? My memory is hazy.

[davetcoleman]

Any progress on this?

[bmagyar]

Yes. As Adolfo mentioned in ros-simulation/gazebo_ros_pkgs#256, I am currently working on a hardware implementation of it, to validate that the proposed implementation is valid for both simulated and real hardware.

Apologies for the visibility blocker, but to ease development, the changes are currently being done internally. When all is ready and tested, it will appear on the PAL github, and I will make a PR to ros-controls with it.

[davetcoleman]

I just wanted to send my encouragment (and gradtitude) for this feature!

[adolfo-rt]

We've come to the conclusion that having controllers for handling joint mode switches is suboptimal. There are two reasons supporting this argument:

Usability

It would be much more convenient to simply start/stop the actual controllers we're interested in, without having to additionally instantiate extra controllers for changing the mode of a joint.

Consider the following example:

1. foo_joint is currently driven by pos_controller, a controller requiring a position interface.
2. We call controller_manager/switch_controller and request to stop pos_controller and start vel_controller, a controller that would also drive foo_joint, but through a velocity interface.
3. foo_joint is now driven by vel_controller, in velocity mode.

It's clear from 2. above that stopping pos_controller and starting vel_controller implies changing the control mode of foo_joint from position to velocity. There is already enough information to figure this out. What remains to be determined is if the actual robot is capable of doing the required mode switch. Such robot-specific code is well within the scope of RobotHW.

Having additional controllers that trigger the mode switch seems unnecessary. I have also received some negative feedback from testers of this proposal that mode-switching controllers are an odd fit, as they are not really controllers (they do nothing in the control loop update cycle). They only do work when started/stopped.

Technical aspects

Doing proper resource conflict handling with mode-switching controllers is kludgy at best in our prototypes. Reviewing the design, we found it impossible to prevent inconsistent controller configurations, in which one could end up with a running controller targeting a currently disabled interface. Without going into much detail, this is because when checking for conflicts, the only information available is a list of ControllerInfo instances, which don't allow to introspect the actual joint modes we want to switch to.

There is one place where all the information required to perform a correct mode switch exists, and that is the RobotHW.