[ros-users] using ROS with a new 7-DOF arm hardware

[Patrick Beeson]

Thanks Stuart.  After looking over this yesterday, I had concluded that #2 on your list was my best option.  I had considered #3 but I couldn't figure out exactly where to draw the line at stopping using your code and inserting my own---I found it difficult to determine exactly how things fit together in between ethercat drivers and the publish manager.  I'll continue on writing a new Trajectory Joint Action node that sets efforts for Gazebo and publishes to my hardware.

Sent from my iPhone

On Jun 14, 2011, at 8:56 PM, Stuart Glaser <sglaser at willowgarage.com> wrote:

> Hi Patrick,
> 
> I'll try to answer some of your questions about writing a controller
> for your robot and simulating it in Gazebo.
> 
> You should create a controller that provides a
> pr2_controllers_msgs/JointTrajectory [1] action server, similar to the
> joint_trajectory_action.  This action is the interface that the motion
> planning stacks use to command the controller.
> 
> Don't use the joint_trajectory_action itself.  It only exists to
> support older (deprecated) controllers that didn't provide the action
> interface themselves.  Instead, you should use the
> JointTrajectoryActionController as the best example of what to write.
> 
> You also asked about how to simulate your robot using Gazebo.  AFAIK,
> you have three choices:
> 
> 1. Write a Gazebo plugin that mimics your robot's interface.  The
> Gazebo plugin communicates to Gazebo (I think by writing to Gazebo
> interface classes that it creates; see the Gazebo documentation), and
> it also provides the ROS topics, services, and actions that the rest
> of your software expects.  If your joint trajectory action is
> communicating with the hard realtime system over ROS, then you can
> just implement that interface and keep the rest of your code the same.
> 
> 2. Use the pr2_mechanism infrastructure in Gazebo, but not for your
> regular robot.  In this case, you would write PR2 controllers (or use
> the existing JointTrajectoryActionController) for when your robot runs
> in simulation, which have the same ROS interface as the controllers
> for your robot.
> 
> 3. Use the pr2_mechanism infrastructure in Gazebo and on your own
> robot.  Though pr2_mechanism was intended to run only on a PR2, other
> groups have had success with porting it to other robots [2].
> 
> Those are your three options.  None of them stands out as the best
> option, so you will probably be fine no matter which you choose.
> 
> [1] http://www.ros.org/doc/api/pr2_controllers_msgs/html/msg/JointTrajectoryGoal.html
> [2] http://answers.ros.org/question/158/build-a-controller-for-an-arm-no-pr2
> [3] http://www.ros.org/wiki/pr2_mechanism_model
> 
> Cheers,
> -Stu
> 
> 
> On Tue, Jun 14, 2011 at 9:47 AM, Patrick Beeson <beeson.p at gmail.com> wrote:
>> I now found out a bit more.  I now realize that by setting the
>> commanded_effort_ of a JointState is the way commands are sent (not via
>> messages or other).   I also see that  Gazebo is has a plugin to
>> replicate the controller_manager, that uses the URDF description to set
>> up a robot model and simulation joint motions.  So, at the VERY least,
>> if I want to use Gazebo, I'll need to make sure that I load a
>> pr2_mechansim_model of the Robot that is consistent with the model used
>> by Gazebo.
>> Does this sound correct?
>> 
>> 
>> to have it's own ros_controller_manager that does the same for Gazebo.
>> So, my intuition is that if I write
>> 
>> 
>> On 06/14/2011 10:53 AM, Patrick Beeson wrote:
>>> Great.  I look froward to trying this out once it's released.
>>> 
>>> One or two quick questions that are not at all clear.   Will (in the
>>> new tool chain) my custom JointTrajectoryAction controller also need
>>> to be a pr2_controller in order to use my URDF model with Gazebo?  I
>>> was going to make a joint_trajectory_action_node that communicated
>>> directly with my hard in soft real-time to start.   This wasn't going
>>> to be a pr2_controller at all.   But I will want to be able to use the
>>> urdf model to control the arm in Gazebo.   My understanding is that
>>> right now, somewhere, something allows controllers to run in
>>> simulation instead of on the ethercat hardware.  I can't seem to find
>>> a good example that shows where exactly the line in drawn between sim
>>> and real, but it looks like the default Gazebo pr2 sim AND the pr2 arm
>>> hardware  both use
>>> robot_mechanism_controllers/src/joint_trajectory_action_controller.cpp.
>>> Examining that controller, I find it VERY difficult to understand how
>>> the low-level joint commands are being set (they seem to be copied
>>> into a RealTimeBox that is never intialized, so I don't know where
>>> they go from there).    So is the sim joint communication happening
>>> below this?  Do I need to do something special to talk to simulated
>>> joints in Gazebo versus on my hardware?  Another way of asking, if I
>>> write a joint_trajectory_action_controller to talk to my specific
>>> hardware, will I need to write another to talk to Gazebo?   And Do
>>> these need to be pr2_controllers?
>>> 
>>> 
>> _______________________________________________
>> ros-users mailing list
>> ros-users at 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 at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users