Thanks Wim.

If robot_mechanism_controllers/CartesianPoseController is generic, is there
a sample config or launch file for setting the parameters? Sachin sent one
out earlier for JTTeleop, but I guess that is pr2-specific.

Thanks.


Adam Leeper
Stanford University
aleeper@stanford.edu
719.358.3804


On Tue, Aug 31, 2010 at 6:17 PM, Wim Meeussen <meeussen@willowgarage.com>wrote:

> > 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)
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>