Ask Your Question

Build a controller for an arm (no PR2)

asked 2011-02-24 05:30:03 -0500

charias98 gravatar image

updated 2011-02-24 07:54:58 -0500

Eric Perko gravatar image

Hi, i want to use ROS to work with a SSC32 card, but i can't find information about how to build a controller for it. I had readed about pr2_controller_interface, pr2_mechanims_model, ( ), hardware_interface, joints, urdf, etc... but i don't understood what interface do i must implement and how use it.

Where can i find instruccions about it, or somebody can give some advice?

Thanks in advance

edit retag flag offensive close merge delete

7 Answers

Sort by ยป oldest newest most voted

answered 2011-02-24 08:16:53 -0500

updated 2011-02-24 08:17:27 -0500


We did it for our own interactive arm with three actuators that communicate through a CAN bus. Here's a quick rundown of what we built and what you might need:

  • A valid URDF definition of your joints and actuators,
  • A bridge class that will own instances of:
    • A pr2::HardwareInterface
    • A pr2::ControllerManager
    • One pr2_hardware_interface::Actuator for each of your motors
  • A node for hardware communication that will own the bridge class.

At initialization, your bridge class will create the actuators that should appear in your URDF and add them to the hardware interface. You will then create the controller manager and link it to the hardware interface. After loading your URDF XML into the controller manager (initXML(...)) you will be ready to periodically update your controller manager, which should call any other controllers you want to run, e.g. a JointSplineTrajectoryController.

I'm not familiar with SSC32 cards, but with our setup we communicate the state through each actuator instance that was added to the hardware interface. The controller manager update cycle will get these values automatically and propagate them to controllers. We run separate threads to get values to and from our bus, and call the controller manager update() method in its own thread.

Hope this helps,

edit flag offensive delete link more


Thanks a lot for your answer. It helps a lot, but I still have some questions: the instances of ControllerManager and ACtuator that i must to put in my bridge class there are objects of the original classes or must i extend them? Which class send the digital signals to card? Thanks again
charias98 gravatar image charias98  ( 2011-02-25 01:39:45 -0500 )edit
We don't extend these classes, we used them as-is. As for communicating with the card, we have a second class that has a an instance of the bridge. It periodically updates the actuator values and read back the command_effort to send it to the actuators.
francoisferland gravatar image francoisferland  ( 2011-02-27 01:26:40 -0500 )edit

answered 2011-02-25 17:43:39 -0500

KoenBuys gravatar image

Please note that our lab (Steven Bellens) wrote a driver for this card:

You can find our code on our GIT server (it moved from SVN, but is also kept on our SVN):

edit flag offensive delete link more

answered 2011-02-27 01:48:12 -0500

updated 2011-02-27 01:48:43 -0500

After calling the update on the controller manager, we read back the commanded_effort variable and send it to our actuator drives. Look into the ethercat_hardware package or even pr2_gazebo_plugins and the gazebo_ros_controller_manager to see how they do it on the PR2. The later is a bit easier to follow, everything is done in the gazebo_ros_controller_manager.cpp file, from URDF parsing to sending commanded efforts.

Here we actually cheat a little bit on our setup. Since we already have microcontrollers with PID loops that accepts positions as commands for each of our actuators, we set the joint spline trajectory controller p and d parameters as {1,0} so the commanded_effort variable only contain the full joint position error.

edit flag offensive delete link more

answered 2011-02-27 02:14:02 -0500

Klaus gravatar image

Cool, thanks! I was looking into the ethercat nodes before, but didn't really find the point where the data is actually transmitted to the mcu boards. Anyway, will check the Gazebo nodes. Interesting point what you said about sending the full joint position error. I thought in case of PR2 motor control would be outsourced to mcu level as well. But come to think of it, it is more flexible to keep the actual control centralized within the control computer to be more flexible when it comes to trying new controlers etc.

edit flag offensive delete link more


Ah ok, now I see the point: I need to create a kind of container thread that runs the controller manager and manages the communication with my hardware. Then I need to copy the transmitted actuator commands (from the controller) into commands for my hardware manually within the container thread. Took me a while to realize that. Might be nice to have some kind of overview diagram for that in the documentation.
Klaus gravatar image Klaus  ( 2011-02-27 03:24:38 -0500 )edit
Yep, that's exactly what we do. If I understand it correctly, on the PR2 they run all their controllers on a realtime kernel. They also use special publishers and subscribers for internal communication to limit message copying and stay realtime. It's somewhat similar to the nodelets API.
francoisferland gravatar image francoisferland  ( 2011-02-27 03:43:41 -0500 )edit

answered 2011-06-21 13:43:18 -0500

clark gravatar image

The reply from francoisferland is really instructive. Now the thing remains unclear to me is, for an actual non-pr2 robot arm, how to "create the actuators ......and add them to the hardware interface"; wondering whether there is an existing implementation for reference? Those ros implementations for existing arms, such as the katana, smart_arm, and gambit arm, all define their own controller manager rather than directly using the pr2 mechanism; the interactive arm with three actuators mentioned by francoisferland, its source is unfortunately not available either.

edit flag offensive delete link more

answered 2012-03-16 09:18:34 -0500

Red24Dog gravatar image

Klaus, as a new Turtlebot builder, as of this week, I have the same intention to drive a Lynxmotion SSC32, in my case from the Turtlebot netbook usb-serial port, from ROS/PS3, I have that controls a built 5 DOF servo based arm. I'd be curious as to ur experience & sucess using the Bellens driver referenced above, of how did u proceed?

edit flag offensive delete link more

answered 2011-02-26 19:42:40 -0500

Klaus gravatar image

updated 2011-02-26 19:54:12 -0500

Hi Francois,

How is the _effort variable within ActuatorCommand transmitted to the hardware? If I look at the code of the existing controllers, I only see this variable being written, but can't find the point where the information is actually used. Is this located somewhere inside the controller manager?

Cheers, Klaus

edit flag offensive delete link more


Hi Klaus, did you got an answer to your question? I'm looking for the same thing
charias98 gravatar image charias98  ( 2011-03-26 11:10:42 -0500 )edit
Hi Klaus. The hardware drivers transmit the ActuatorCommand to the hardware. For the PR2, check out the ethercat_hardware and pr2_etherCAT packages.
sglaser gravatar image sglaser  ( 2011-06-13 07:54:31 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2011-02-24 05:30:03 -0500

Seen: 1,681 times

Last updated: Mar 16 '12