Adam, I only found an old and out-of-date configuration file. So this will not work, but might help you in coming up with a working configuration. To find out what exactly you need, take a look at the init method of the controller. Wim On Tue, Aug 31, 2010 at 6:29 PM, Adam Leeper wrote: > 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 > 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. >> > _______________________________________________ >> ros-users mailing list >> ros-users@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users > > -- -- Wim Meeussen Willow Garage Inc.