[ros-users] how to use pr2_controller_manager with a different robot

Wim Meeussen meeussen at willowgarage.com
Wed Sep 1 01:17:41 UTC 2010


> When I launch and try to check the status of the controllers using
> pr2_controller_manager list, it hangs and if I kill it the traceback says it
> was waiting for 'pr2_controller_manager/list_controllers.' When I run the
> pr2 in gazebo, that service is advertised by gazebo itself... so obviously I
> have a problem.

The pr2 controller manager is a library, not an executable. So when
you run in simulation, Gazebo creates the controller manager, and when
you run on the pr2, pr2_ethercat creates the controller manager.  When
you launch "controller_manager.launch", this will only load the
configuration for the controller manager on the parameter server, and
run some supporting nodes (diagnostics, state publisher, etc), but
this will not run the controller manager. Take a look at the
pr2_etherCAT package for an example on how to start the controller
manager.


> What is the correct procedure for interfacing my own hardware with ros? I
> know at some point I need to hook all this up to actual joint data coming in
> off my hardware. Can someone point me to an example of how that is
> published? Also, do the CartesianPoseController and JTTeleopController work
> with a generic urdf, or are they pr2-specific?

There are multiple ways to do this:
 * You can create a ROS node for each piece of hardware, and allow
other nodes in your system to interact with the hardware over
topics/services/actions. This is a very easy approach. The
disadvantage is that you won't be able to create a closed loop in hard
realtime, and you won't be able to reuse the controllers we built for
the PR2. But I would think that most people have used this approach
when porting their robot to ROS.

 * You can implement the hardware interface (pr2_hardware_interface)
for your hardware, and use the controller manager. The pr2 hardware
interface is however PR2 specific, so this approach will only work for
robots that are in some ways similar to the PR2. The hardware
interface for example only supports effort controlled joints.  All the
controllers we built, are using the "JointState" object of the
hardware interface. So, take a look at the class, and see if you could
implement this for your robot.

The controllers that are not PR2 specific live in stacks that don't
have the pr2-prefix. The robot_mechanism_controllers package for
example contains a set of non-pr2-specific controllers.


Hope this helps,

Wim




-- 
--
Wim Meeussen
Willow Garage Inc.
<http://www.willowgarage.com)



More information about the ros-users mailing list