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