Ugo, Thank you, that is very helpful. Thanks also Stuart for your pointer to the tutorial. -A On Mon, Aug 2, 2010 at 2:15 AM, Ugo Cupcic wrote: > Hi, > > At Shadow we had 2 different approaches: we built 2 different ROS > interfaces, one for the ethercat hand we plugged to the pr2 and another one > for our existing CAN hand. > > I'm more familiar with the CAN interface. In this interface, we built a ROS > interface on top of our existing driver. There's one publisher and one > subscriber for the hand. The ROS interface reads data and publishes them > periodically to the joint_states topic. It also publishes hardware > information on the diagnostics topic. I also defined a couple of specific > messages because it was easier in certain cases than to use the existing ROS > messages. The subscriber is used to send command to the hand. > > The ethercat interface is really different. It was build directly for ROS, > using the pr2_controllers, etc... There's one publisher and one subscriber > per joint. If I'm not mistaking, it only uses standard ROS/pr2 messages. > > In both cases, one of the important thing was to build the urdf model of > the robot. The model is used throughout the code and also for visualization > / simulation purposes. > > If you want to have a look at the ROS interface for our CAN hands, you can > go to: > https://launchpad.net/sr-ros-interface > > Hope this help, otherwise don't hesitate to recontact me if you wanted more > info. > > Cheers, > > Ugo > > > On 02/08/10 07:29, Adrian wrote: > > > Morgan, > > Thanks, that is quite helpful. The point of my question was that I want > to do this in a way which would make the arm as easy as possible for > existing ROS users like, for example, those familiar with the PR-2 software, > to just "drop in" my hand/arm. So I would not want to go create a buch of > new messages and services and such if I could help it, I would like to > figure out what level of abstraction is the correct place for my code to > meet up with existing code. Is the "joint space controler" the place to do > this? > If so, what exactly is the "joint space controler"? From what I read in > the wiki, it looks like controlers are not exactly nodes, but some kind of > module which is loaded into some general real-time layer which handles all > controlers on the robot. Is that correct? (I am learning about ROS as I > start this, so I appreciate your patience with what probably look like dumb > questions.) > Really, what I am getting at is, if someone walked up to someone and said > "hi, I made a cool hand, want to use it in your research?", what would be > the best case for them, as ROS users, and possibly PR-2 owners, in terms of > code I could have implemented to make the hand easy to use? > I gather that the Shadow Hand folks had this exact situation, what did > they do? > > -=A > > ps. Nice to hear from you Morgan! > > On Sun, Aug 1, 2010 at 11:10 PM, Morgan Quigley wrote: > >> Hi Adrian, >> >> I'm sure others will chime in here, but IMHO the greatest thing about >> ROS is that you can do whatever you want :) it's designed from the >> ground up to be flexible and extensible, and to not favor one approach >> over another equally-valid approach. >> >> That being said, when I've built my own sensors and arms, if the >> bandwidth isn't prohibitive, I first wrap up the hardware details in a >> ROS node that performs whatever bit-mashing is necessary to publish >> and subscribe to abstracted versions of what the hardware deals with, >> e.g., translating to/from some packet format that contains sensor >> readings and actuator commands that goes over usb/ethernet/etc. to an >> embedded microcontroller. This node doesn't do anything beyond munging >> the embedded protocol into ROS messages, and maybe do graceful >> startup/shutdown of the hardware. When using the real hardware, this >> program is started once during a session and left up for a few hours >> while hacking higher layers. >> >> Once the driver wrapper is done, you can write higher layers that >> either implement your own stuff or interface to other ROS software >> (e.g., rviz, robot state publisher, nav stack, etc. etc.). Since those >> higher layers aren't tied to hardware, you can use rosbag to >> record/play real data to the rest of the stack, and/or write a >> simulation layer to swap with the "real" driver wrapper. >> >> we just did a master-slave "puppeteer" demo of our arm that had a >> straightforward stack: >> >> * human motion capture >> * inverse kinematics via OROCOS/KDL >> * robot state publisher (forward kinematics) >> * joint-space controller >> * state estimation from encoders, accelerometers, etc. >> * device driver wrappers >> >> It's all available in an unvarnished state here: >> https://stanford-ros-pkg.googlecode.com/svn/trunk/openarms/ >> >> each layer is a separate node. All of them talk to rviz in one way or >> another to ease debugging. The robot state publisher (from the WG >> robot_model stack) converts joint angles and the robot's kinematic >> description (URDF) into tf frames. When doing any of this stuff, rviz >> is extremely helpful when converting a new robot's cad models into >> URDF and in general for making sense of all the coordinate systems. >> >> HTH, >> -mq >> >> >> On Sun, Aug 1, 2010 at 8:34 PM, Adrian wrote: >> > >> > I am interested to know how one goes about creating an interface for >> > a device, such as an arm or hand. In particular, the question is what >> is >> > the lowest level component in the ROS architecture which one would >> implement >> > first? Presumably, once that low level element was in place, one could >> then >> > go on to create services or actions that make use of that component. >> > Could someone point me to (or write?) a summary of what this stack >> looks >> > like for something like the PR2 or Shadow arms? >> > >> > >> > _______________________________________________ >> > 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 >> > > > _______________________________________________ > ros-users mailing listros-users@code.ros.orghttps://code.ros.org/mailman/listinfo/ros-users > > > -- > Ugo Cupcic | Shadow Robot Company | ugo@shadowrobot.com > Software Engineer | 251 Liverpool Road | > need a Hand? | London N1 1LX | +44 20 7700 2487http://www.shadowrobot.com/hand/ @shadowrobot > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > >