0
$\begingroup$

Rosanswers logo

I would like to know what workarounds can be used to allow a controller to command more than one hardware interface in ros_control. The hardware interfaces could be homogeneous or heterogeneous (e.g. VelocityJointInterface + PositionJointInterface + MyCustomInterface). I am looking for a solution that does not involve creating a new hardware interface with gigantic handles. There is a workaround here for the case where only one hardware interface sends commands, but it might not work for our particular case.

One of our applications for this is a mobile manipulator where the arm has velocity and position hardware interfaces, and the base has a velocity hardware interface. We would like to control both the arm and the base within the same controller.

To get familiar with ros_control, we developed the control architecture for the arm first. The RobotHW specialization has a VelocityJointInterface and a PosVelJointInterface for visual servoing/joystick and trajectory tracking control modes, respectively. The design of the architecture is such that several components (e.g. arm + base) can be aggregated in a single RobotHW specialization. Now we are facing the difficulty of aggregating hardware interfaces at the controller level. So I would like to know what other people have done on similar scenarios.


Originally posted by Daniel L on ROS Answers with karma: 43 on 2015-03-02

Post score: 2

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

IIURC, you want to send commands to different interfaces from a single controller, but there is one interface associated to each resource (eg. joint). This is currently not well supported, and would require (C++ and ROS) API changes to be done correctly.

That being said, you could hack your way around by deriving your controller from controller_interface::ControllerBase (as opposed to controller_interface::Controller<T>). The upside is that you get access to a RobotHW*, (as opposed to a particular interface), hence to all the robot's resources. The downside is that the getHardwareInterfaceType method, which you must implement, assumes a single HW interface. Resource conflict handling might not work correctly in such a case, I haven't checked the implications in detail.


This is not what you are trying to do, but I add it here for completeness. If you want to attack the same resource from different HW interfaces, you can implement a custom checkForConflict(...) method for your hardware abstraction, and override the default exclusive resource usage policy.


Originally posted by Adolfo Rodriguez T with karma: 3907 on 2015-03-03

This answer was ACCEPTED on the original site

Post score: 1


Original comments

Comment by Daniel L on 2015-03-05:
Thanks for replying. I went through the code in ControllerManager::ControllerManager and checkForConflict(...), and it seems that this would work. The first only uses the hardware_interface type as a string for reporting purposes. The second uses ControllerInfo::resources.

Comment by Daniel L on 2015-03-05:
Would there be other parts of the code where the hardware_interface type string is used?

Comment by Andreas Hermann on 2016-02-22:
Just to see, if I get this right: I will NOT be able to have a hardware_interface for my device A and another hardware_interface for my device B and have them controlled in sync by one single trajectory controller? So I have to aggregate ALL different drivers (CANOpen, Serial, ...) in one interface?

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.