ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
2

How to aggregate command hardware interfaces in ros_control?

asked 2015-03-02 16:09:22 -0500

Daniel L gravatar image

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.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
1

answered 2015-03-03 03:27:27 -0500

Adolfo Rodriguez T gravatar image

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.

edit flag offensive delete link more

Comments

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.

Daniel L gravatar image Daniel L  ( 2015-03-05 13:03:08 -0500 )edit

Would there be other parts of the code where the hardware_interface type string is used?

Daniel L gravatar image Daniel L  ( 2015-03-05 13:04:23 -0500 )edit
1

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?

Andreas Hermann gravatar image Andreas Hermann  ( 2016-02-22 02:46:53 -0500 )edit

Question Tools

3 followers

Stats

Asked: 2015-03-02 16:09:22 -0500

Seen: 1,186 times

Last updated: Mar 03 '15