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<geometry_msgs::Twist>(node_, "state/error", 1));
state_pose_publisher_.reset(new realtime_tools::RealtimePublisher<geometry_msgs::PoseStamped>(node_, "state/pose", 1));
state_pose_desi_publisher_.reset(new realtime_tools::RealtimePublisher<geometry_msgs::PoseStamped>(node_, "state/pose_desi", 1));
joint_state_publisher_.reset(new realtime_tools::RealtimePublisher<sensor_msgs::JointState>(node_, "joint_states", 1));
effort_publisher_.reset(new realtime_tools::RealtimePublisher<std_msgs::Float32MultiArray>(node_, "state/effort", 1));
Adam Leeper
Stanford University
aleeper@stanford.edu
719.358.3804
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 <aleeper@stanford.edu> 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 <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
>
>
> _______________________________________________
> 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