> 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.