Loading ...
Sorry, an error occurred while loading the content.
 

RE: [SeattleRobotics] Re: Accurate odometry, adding jaws

Expand Messages
  • Alan
    Hi Peter, The base task (base behavior) is probably navigate, summing in any broad avoidance vectors. The emergency level behaviors like imminent contact,
    Message 1 of 5 , Dec 29, 2011
    Hi Peter,

    The "base" task (base behavior) is probably navigate, summing in any broad
    avoidance vectors. The "emergency" level behaviors like imminent contact,
    or the table edge (my Table Top 'bot) are cause for a takeover by the
    appropriate behavior.

    In my case, I have behaviors for retreating from the table edge, navigating
    towards an object once seen, searching for the goal (shoe box at end of
    table) after an object has been acquired, releasing and backing away from
    the goal once it's achieved. My base task is to wander the table top,
    trying not to fall off. I also have a behavior for closing the jaws on an
    object once it's been detected at the base of the jaws. The jaws re-open
    and clear the task (allowing it to start over) if the object is lost.

    Very simple priority (behavior) shifts from detecting object, to driving
    towards the object, grasping the object, then detecting the goal, driving
    towards the goal, and eventually after the object is in the goal releasing
    it, and backing off from goal.

    I agree that Subsumption is a relatively easy way to implement something
    like a Table Top or RoboMagellan 'bot.

    I guess you could say the base task "blends" both vectors to the goal and
    broad avoidance. Good navigation would typically do that, I think.

    Yes, I remember having to work out how much of a gait cycle had to be
    completed before it could change from forward to reverse, or start a turn
    when I wrote my code for Loki. It can get complicated! And I discovered
    that I needed to make the gaits reversible, so as to simplify/minimize the
    code needed to execute the gaits. At the time I don't think I thought of
    them as behaviors, but I guess they could have ended up that way! My gait
    routines were quite low-level, with any behaviors being distinctly above
    them.

    On another topic, I remember your simulations of quads and hexapods, and was
    wondering if you'd ever done or seen a simulation of the four-bar linkage
    for a gripper (jaws)? I'm working on an improvement from a very simple jaw
    to the use of what I'm told is a four-bar linkage. It's driven from an R/C
    servo, and the gears face down towards the table. This linkage does work
    (I've built it), although I'm still working on the joints a little. There
    are micro switches to detect the object. A second jaw plate on top of the
    long curving jaws gives a little more depth to the jaw. The circle is a
    soda can, and the square is cheese!

    What I'd really like to know is how changing the length of the linkages and
    location of the two link bearings (flanking the center micro switch) affects
    the travel of the jaws. The jaws stay parallel for the most part. I'm
    pretty much fixed on the action of the two gears, and locations of the two
    table-looking IR sensors seen just below the gears. I played with
    min/max/norm positions of the jaws in my CAD drawing before I started to
    machine the parts.

    I'm not a mechanical engineer, but I suspect there are some general (IK?)
    guidelines for designing these linkages.

    A simulation would be of GREAT help! Do you know of any guidelines or
    simulations? Or are you interested in writing one?

    Thanks!

    Alan KM6VV


    > -----Original Message-----
    > On Behalf Of Peter Balch
    >
    > Yes. That's exactly what I'm trying to determine. On the one hand, dpa
    > makes
    > it clear that he's a big fan of subsumption. On the other hand, the videos
    > apparently show very smooth transitions between the "avoid" and "navigate"
    > behaviours. It's as though, as you suggest, the "avoid" and "navigate"
    > behaviours are somehow blended together. But that's absolutely not the way
    > that subsumption works. In subsumption, one behaviour completely
    > overrides
    > another - there's never any blending.
    >
    > Personally, I too am a fan of subsumption. Not neccessarily because I
    think
    > it's wonderful, but more because it's so easy. However it does have its
    > disadvantages. The lack of blending can give sudden changes in behaviour.
    I
    > was paticularly struck by this when writing controllers for a simple biped
    > and a quadruped. With a wheeled buggy, you can always instantly respond to
    > an input by switching to a new behaviour - i.e. classical subsumption. One
    > behaviour doesn't need to know anything about the internal state of
    > another.
    > But for my walking bots, I'd programmed a behaviour as a gait - i.e. a
    > sequence of leg movements ("walk forward", "reverse left", "turn on the
    > spot"). Which means that you're not allowed to swap behaviours instantly.
    > It's only safe to do so at particular phases in the gait - one gait must
    > change seamlessly into another. So the new behaviour has to know about
    > the
    > internal state of the current one. Also if you can't instantly respond to,
    > say, an obstacle, you're more likely to walk into it.
    >
    > If dpa has invented blending-subsumption, I'd like to know.
    >
    > Peter
    >
  • Wim Lewis
    ... I was looking for a very specific linkage a while ago and bookmarked a few pages that might be helpful for you as well: KMODDL:
    Message 2 of 5 , Dec 29, 2011
      On 12/29/11 10:40 AM, Alan wrote:
      > I'm not a mechanical engineer, but I suspect there are some general (IK?)
      > guidelines for designing these linkages.
      >
      > A simulation would be of GREAT help! Do you know of any guidelines or
      > simulations? Or are you interested in writing one?

      I was looking for a very specific linkage a while ago and bookmarked a
      few pages that might be helpful for you as well:

      KMODDL:
      http://kmoddl.library.cornell.edu/

      http://kmoddl.org/machinesandmechanisms/index.php/Tutorials_and_Descriptions

      P. Pamfilos' website, and EucliDraw:
      http://www.math.uoc.gr/~pamfilos/eGallery/Gallery.html
      http://www.euclidraw.com/

      EucliDraw claims to be handy for experimenting with linkages, though I
      haven't tried it.
    • Alan
      Thanks for the URLs, I remember the KMODDL tour! I didn t recognize the parallel motion (4-bar) used in the jaws (grippers). Well, a LOT that I didn t
      Message 3 of 5 , Dec 29, 2011
        Thanks for the URLs, I remember the KMODDL tour!

        I didn't recognize the parallel motion (4-bar) used in the jaws (grippers).
        Well, a LOT that I didn't recognize! I have designed and machined 4-bar
        linkages for a Walking Beam steam engine. And my jaws do work, I'd just
        like to be able to understand the design of such mechanisms better!

        Maybe EucliDraw will be of help! (I'm just using CAD).

        Thanks,

        Alan KM6VV

        > -----Original Message-----
        > On Behalf Of Wim Lewis
        >
        > I was looking for a very specific linkage a while ago and bookmarked a
        > few pages that might be helpful for you as well:
        >
        > KMODDL:
        > http://kmoddl.library.cornell.edu/
        >
        > http://kmoddl.org/machinesandmechanisms/index.php/Tutorials_and_Descr
        > iptions
        >
        > P. Pamfilos' website, and EucliDraw:
        > http://www.math.uoc.gr/~pamfilos/eGallery/Gallery.html
        > http://www.euclidraw.com/
        >
        > EucliDraw claims to be handy for experimenting with linkages, though I
        > haven't tried it.
      • Chuck Harrison
        Maybe you could have fun modeling it in Geogebra http://www.geogebra.org/en/upload/files/english/RGemberling/JumpingFrog.html Chuck
        Message 4 of 5 , Dec 29, 2011
          Maybe you could have fun modeling it in Geogebra
          http://www.geogebra.org/en/upload/files/english/RGemberling/JumpingFrog.html

          Chuck

          --- In SeattleRobotics@yahoogroups.com, "Alan" <KM6VV@...> wrote:
          >
          > Thanks for the URLs, I remember the KMODDL tour!
          >
          > I didn't recognize the parallel motion (4-bar) used in the jaws (grippers).
          > Well, a LOT that I didn't recognize! I have designed and machined 4-bar
          > linkages for a Walking Beam steam engine. And my jaws do work, I'd just
          > like to be able to understand the design of such mechanisms better!
          >
          > Maybe EucliDraw will be of help! (I'm just using CAD).
          >
          > Thanks,
          >
          > Alan KM6VV
          >
          > > -----Original Message-----
          > > On Behalf Of Wim Lewis
          > >
          > > I was looking for a very specific linkage a while ago and bookmarked a
          > > few pages that might be helpful for you as well:
          > >
          > > KMODDL:
          > > http://kmoddl.library.cornell.edu/
          > >
          > > http://kmoddl.org/machinesandmechanisms/index.php/Tutorials_and_Descr
          > > iptions
          > >
          > > P. Pamfilos' website, and EucliDraw:
          > > http://www.math.uoc.gr/~pamfilos/eGallery/Gallery.html
          > > http://www.euclidraw.com/
          > >
          > > EucliDraw claims to be handy for experimenting with linkages, though I
          > > haven't tried it.
          >
        • Alan
          That s cute! But not sure what to do with it! Alan KM6VV
          Message 5 of 5 , Dec 29, 2011
            That's cute! But not sure what to do with it!

            Alan KM6VV

            > -----Original Message-----
            > On Behalf Of Chuck Harrison
            >
            > Maybe you could have fun modeling it in Geogebra
            > http://www.geogebra.org/en/upload/files/english/RGemberling/JumpingFro
            > g.html
            >
            > Chuck
          Your message has been successfully submitted and would be delivered to recipients shortly.