[ros-users] Creating a hardware device

Adrian adrian.kaehler at gmail.com
Mon Aug 2 18:05:32 UTC 2010


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 <ugo at shadowrobot.com> 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 <mquigley at cs.stanford.edu>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 <adrian.kaehler at gmail.com> 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 at code.ros.org
>> > https://code.ros.org/mailman/listinfo/ros-users
>> >
>> >
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>
>
> _______________________________________________
> ros-users mailing listros-users at code.ros.orghttps://code.ros.org/mailman/listinfo/ros-users
>
>
> --
> Ugo Cupcic         |  Shadow Robot Company | ugo at 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 at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100802/f2e3af76/attachment-0003.html>


More information about the ros-users mailing list