I'd be more the glad to help alpha test and work through this stuff prior to release. Feel free to send along the current documentation. I believe my intern created a reasonable URDF before he left for a week of personal time. I'll try to track that down. I'll also start writing my own joint_trajectory_action if needed. One thing I was confused about was joint_tractory_action. That package exists is the pr2_controllers stack. Can't I simply use than and then have it subscribe to my controller for status and publish controller commands? Why do I need to write my own if one exists? Or did you mean that I'll need to write my own node to handle the joint_tracjectory messages from the joint_trajectory_action node? On Mon, Jun 13, 2011 at 1:59 PM, Gil Jones wrote: > Hi Patrick, > > We are currently actively (as in right this second) developing a tool > chain that assists users in configuring and building applications for > arm navigation on novel platforms.  We're aiming to have all of this > working reliably and in a documented fashion in time for the release > of e-turtle later this summer.  In the meantime, if you are interested > in being an alpha tester of this functionality I can send you a > rosinstall file and tell you a bit about how the tool chain works - > this should definitely be the fastest way to go from a urdf to solving > kinematics and generating collision-free trajectories for your arm > using our software.  This is with the usual caveats that things aren't > quite ready for prime-time. > > To use this new functionality you'll need a urdf and your own > joint_trajectory_action, but all the intermediate configuration and > launch file generation should be done for you.  This also doesn't help > configure any of our manipulation stacks - those will not be released > at 1.0 in e-turtle. > > All the documentation, etc will be cleaned up in conjunction with the > e-turtle release, and now that we're taking the plunge towards a 1.0 > release of major parts of the system things should be substantially > more stable as of e-turtle. > > -Gil > > -- > E. Gil Jones (gjones@willowgarage.com) > Research Engineer > Willow Garage, Inc. > 68 Willow Road > Menlo Park, CA 94025 > 650.475.9772 > > > On Mon, Jun 13, 2011 at 11:36 AM, Patrick Beeson wrote: >> I'm attempting to try and utilize novel, custom-made 7-DOF modular arm >> hardware with ROS, and I'd like any help people are willing to provide >> in starting from scratch with getting a new arm working in ROS.  I >> have lots of familiarity with ROS, writing ROS drivers for perception >> and navigation hardware, but, I'm not a manipulation or kinematics >> expert, and I'm having difficulties understanding exactly what I do >> and do not need to implement on my end to use the move_arm high level >> package. >> >> Having previously used the navigation stack, and other such stacks,  I >> assumed that I would need some sort of driver that would subscribe to >> some topic that would send joint positions or velocities based on >> higher level kinematics planning given URDF models of the joints. >> Instead, what I found was this tutorial: >> http://www.ros.org/wiki/arm_navigation/Tutorials/Running%20arm%20navigation%20on%20non-PR2%20arm, >> which seems to imply the need for writing my own kinematics plugin in >> addition to my own joint trajectory execution node.  I can certainly >> do this given some time; however, previous emails implied a >> generic_kinematics package in unstable that would be useful, but after >> searching through the Subversion repository, a generic_kinematics >> package does not exist anywhere. >> >> So, I'm going to start my creating a joint_trajectory_execution node >> that has a a joint_trajectory_action interface and does soft-realtime >> control of my joints behind the scenes.  What I need help determining >> is if/where any generic kinematics packages exist or if I need to >> write my own for my arm.  If I need to write my own, more details on >> how to get this working with the other relevant modules would be >> useful.  If a generic package exists, where is it?  How do I feed it >> the model of my arm?  Also (tutorial step 5) there are lots of other >> bits and pieces lying around that need to get tied together that >> aren't well documented.  All in all, what I need is a better tutorial >> that gives a much more simplified explanation as to what pieces are >> needed, how they fit together (from move_arm down to hardware >> interface), what parameters are definitely needed and which can be >> ignored, etc. >> >> Any help on this would be appreciated.  I'm sure I could figure all of >> this out given enough time, but these days, time is not a great luxury >> that I have, and part of the reason I use ROS is that it has been easy >> to create, use, swap nodes, messages, topics with relative ease.  the >> ARM documentation however is quite lacking and the large number of >> motion planning, kinematics, controller, and action modules are not >> well documented as to what is deprecated, how things fit together, >> etc. >> >> Thanks in advance, >> >> Patrick >> _______________________________________________ >> 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 >