Thanks Stu. I should have replied to Wim's email that I got something working using a custom ROS node and a hacked version of Cartesian Pose Controller. I have a question though: Is there a significant speed difference between setting up several realtime state publishers as shown below (twist, 2x Pose stamped, JointState, Float array) compared to making a custom message type and sending it out on one publisher? The current publish rate is 10Hz but I am thinking of increasing that to 30Hz+. Also... are the real-time publishers below doing anything different than regular publishers, given that they aren't actually working in part of the pr2_controller manager? It seems I didn't have to call ros::spinOnce() anywhere to get those to work, but I ended up having to call ros::spinOnce() every 100ms anyway to get the incoming pose commands to update. Thanks, Adam state_error_publisher_.reset(new realtime_tools::RealtimePublisher(node_, "state/error", 1)); state_pose_publisher_.reset(new realtime_tools::RealtimePublisher(node_, "state/pose", 1)); state_pose_desi_publisher_.reset(new realtime_tools::RealtimePublisher(node_, "state/pose_desi", 1)); joint_state_publisher_.reset(new realtime_tools::RealtimePublisher(node_, "joint_states", 1)); effort_publisher_.reset(new realtime_tools::RealtimePublisher(node_, "state/effort", 1)); Adam Leeper Stanford University aleeper@stanford.edu 719.358.3804 On Tue, Sep 7, 2010 at 2:54 PM, Stuart Glaser wrote: > Hi Adam, > > Neither the JTTeleopController nor the CartesianPoseController are > necessarily PR2 specific, however, both run inside the PR2 controller > manager, which is PR2 specific. Controllers can only be run on a > robot that supports the PR2 controller manager. > > Wim's email from Aug 31 describes a few ways to run the pr2 controller > manager on your own robot. Following his instructions is your best > bet to getting any of the controllers running on your robot. > > -Stu > > 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 > > > > > > _______________________________________________ > > ros-users mailing list > > ros-users@code.ros.org > > https://code.ros.org/mailman/listinfo/ros-users > > > > > > > > -- > Stuart Glaser > sglaser -at- willowgarage -dot- com > www.willowgarage.com > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users >