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

Motion queue + Re: [tekkotsu_dev] Problem: RLE -> bounding boxes

Expand Messages
  • Thijmen Bink
    I will put some more time into this issue then and see if I can make it work with examening those runs. Thanks for your advice :) But my group has run into
    Message 1 of 4 , May 2, 2006
      I will put some more time into this issue then and see if I can make it
      work with examening those runs. Thanks for your advice :)

      But my group has run into something else aswell. When we create behaviors
      with motions, our AIBO can become a shocking.. AIBO.. For example:
      We ask him to walk towards the ball and make a shooting motion when he's
      close enough. He will walk towards it then.. and when he's close enough,
      he will shoot.. and again, and again etc.. These motions aren't handled
      one at a time but seem to be cancelled when the new motion comes in. Thus
      the first shooting motion takes 20 miliseconds, the new motion comes in
      and does those 20 milisecs again.. and so on. Untill he won't shoot
      anymore (losing the ball) he won't stop stacking these events/motions.

      We seem to be needing some sort of lock, which we've tried at several
      places but it didn't work. Can you point out what we're doing wrong, or
      what we should be doing?

      Thijmen Bink
    • Ignacio Herrero Reder
      Hello. I ve done a similar behavior with AIBO and found similar problems. To solve it, I used a variable to know if movement had ended, forbidding new actions
      Message 2 of 4 , May 2, 2006
        Hello. I've done a similar behavior with AIBO and found similar
        problems. To solve it, I used a variable to know if movement had ended,
        forbidding new actions until the last had finished. The variable is
        activated (true) when you command the action, and is disactivated
        (false),' listening' to the MotionManager event associated to the
        action. Meanwhile, no new actions are allowed, no matter your
        processing stuff order to shoot again (simply put a 'if-then' statement
        asking the variable state). In my case, in which decisions are taken
        depending on the Bounding Box parameters of the ball, this strategy has
        worked perfectly. Regards

        Ignacio Herrero Reder / Tl. +34-95.213.71.60
        Dpto. Tecnologia Electronica / Fax: +34-95.213.14.47
        E.T.S. Ing. Telecomunicacion /
        Universidad de Malaga / nhr@...
        Campus Universitario de Teatinos /
        29071 Malaga, Spain / http://www.dte.uma.es



        Thijmen Bink wrote:

        > I will put some more time into this issue then and see if I can make it
        > work with examening those runs. Thanks for your advice :)
        >
        > But my group has run into something else aswell. When we create behaviors
        > with motions, our AIBO can become a shocking.. AIBO.. For example:
        > We ask him to walk towards the ball and make a shooting motion when he's
        > close enough. He will walk towards it then.. and when he's close enough,
        > he will shoot.. and again, and again etc.. These motions aren't handled
        > one at a time but seem to be cancelled when the new motion comes in. Thus
        > the first shooting motion takes 20 miliseconds, the new motion comes in
        > and does those 20 milisecs again.. and so on. Untill he won't shoot
        > anymore (losing the ball) he won't stop stacking these events/motions.
        >
        > We seem to be needing some sort of lock, which we've tried at several
        > places but it didn't work. Can you point out what we're doing wrong, or
        > what we should be doing?
        >
        > Thijmen Bink
        >
        >
        > SPONSORED LINKS
        > Industri al robotics
        > <http://groups.yahoo.com/gads?t=ms&k=Industrial+robotics&w1=Industrial+robotics&w2=Mechanical+engineering+software&w3=Robotics&w4=Fanuc+robotics&w5=Applied+robotics&w6=Robotics+technology&c=6&s=143&.sig=Yh0FQn7W8o2uyO4sGLFhoQ>
        > Mechanical engineering software
        > <http://groups.yahoo.com/gads?t=ms&k=Mechanical+engineering+software&w1=Industrial+robotics&w2=Mechanical+engineering+software&w3=Robotics&w4=Fanuc+robotics&w5=Applied+robotics&w6=Robotics+technology&c=6&s=143&.sig=uJwX6-gc4ZIQuPixa0jj%0Aqg>
        > Robotics
        > <http://groups.yahoo.com/gads?t=ms&k=Robotics&w1=Industrial+robotics&w2=Mechanical+engineering+software&w3=Robotics&w4=Fanuc+robotics&w5=Applied+robotics&w6=Robotics+technology&c=6&s=143&.sig=3i2KdwPZ_WkJ3uybrFnwVA>
        >
        > Fanuc robotic s
        > <http://groups.yahoo.com/gads?t=ms&k=Fanuc+robotics&w1=Industrial+robotics&w2=Mechanical+engineering+software&w3=Robotics&w4=Fanuc+robotics&w5=Applied+robotics&w6=Robotics+technology&c=6&s=143&.sig=Fp6pi7eBzrbbqJZ-Ge9XVA>
        > Applied rob otics
        > <http://groups.yahoo.com/gads?t=ms&k=Applied+robotics&w1=Industrial+robotics&w2=Mechanical+engineering+software&w3=Robotics&w4=Fanuc+robotics&w5=Applied+robotics&w6=Robotics+technology&c=6&s=143&.sig=d710bXzi4htJBIlIeI9cPw>
        > Robotics technology
        > <http://groups.yahoo.com/gads?t=ms&k=Robotics+technology&w1=Industrial+robotics&w2=Mechanical+engineering+software&w3=Robotics&w4=Fanuc+robotics&w5=Applied+robotics&w6=Robotics+technology&c=6&s=143&.sig=_Lp606M7K9Tj1CxNbkQKjw>
        >
        >
        >
        > ------------------------------------------------------------------------
        > YAHOO! GROUPS LINKS
        >
        > * Visit your group "tekkotsu_dev
        > <http://groups.yahoo.com/group/tekkotsu_dev>" on the web.
        >
        > * To unsubscribe from this group, send an email to:
        > tekkotsu_dev-unsubscribe@yahoogroups.com
        > <mailto:tekkotsu_dev-unsubscribe@yahoogroups.com?subject=Unsubscribe>
        >
        > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
        > Service <http://docs.yahoo.com/info/terms/>.
        >
        >
        > ------------------------------------------------------------------------
        >
        > .
      • Ethan Tira-Thompson
        I agree with the previous response -- it sounds like you are triggering the motion multiple times... remember that motions do not block until completion.
        Message 3 of 4 , May 2, 2006
          I agree with the previous response -- it sounds like you are triggering the motion multiple times... remember that motions do not "block" until completion.  When you request a motion it will begin executing in parallel to your code. (this is why you need an MMAccessor to lock the motion while you're making changes...)

          So whatever event triggers "close enough" to play the kick, you don't want to have trigger the kick again in 30-32ms when the next vision/sensor update notices it's still "close enough".  It may be enough to just erouter->removeListener(...) the triggering event after you start the motion, and then addListener(...) again the next time you are trying to approach.

          By the way, if you added your motion sequence as "prunable", then you can listen for a (motmanEGID,YOUR_MC_ID,deactivateETID) event to signal when it has been pruned.  Alternatively, with the current code out of CVS, you can listen for (motmanEGID,YOUR_MC_ID,statusETID) to signal when it has completed, regardless of whether it is prunable or persistent.

          -ethan


          On May 2, 2006, at 6:52 AM, Thijmen Bink wrote:

          I will put some more time into this issue then and see if I can make it
          work with examening those runs. Thanks for your advice :)

          But my group has run into something else aswell. When we create behaviors
          with motions, our AIBO can become a shocking.. AIBO.. For example:
          We ask him to walk towards the ball and make a shooting motion when he's
          close enough. He will walk towards it then.. and when he's close enough,
          he will shoot.. and again, and again etc.. These motions aren't handled
          one at a time but seem to be cancelled when the new motion comes in. Thus
          the first shooting motion takes 20 miliseconds, the new motion comes in
          and does those 20 milisecs again.. and so on. Untill he won't shoot
          anymore (losing the ball) he won't stop stacking these events/motions.

          We seem to be needing some sort of lock, which we've tried at several
          places but it didn't work. Can you point out what we're doing wrong, or
          what we should be doing?

          Thijmen Bink


          SPONSORED LINKS
          Industrial robotics Mechanical engineering software Robotics
          Fanuc robotics Applied robotics Robotics technology


          YAHOO! GROUPS LINKS





        • Thijmen Bink
          whoohoo, the 2 answers combined have proven a good solution. Ive used a boolean to do the locking, and as Ethan suggested, added a listener to motman for
          Message 4 of 4 , May 3, 2006
            whoohoo, the 2 answers combined have proven a good solution. Ive used a
            boolean to do the locking, and as Ethan suggested, added a listener to
            motman for deactivates to unlock. No more spastic doggies here :)

            Thanks a lot!
            Thijmen Bink

            > I agree with the previous response -- it sounds like you are
            > triggering the motion multiple times... remember that motions do not
            > "block" until completion. When you request a motion it will begin
            > executing in parallel to your code. (this is why you need an
            > MMAccessor to lock the motion while you're making changes...)
            >
            > So whatever event triggers "close enough" to play the kick, you don't
            > want to have trigger the kick again in 30-32ms when the next vision/
            > sensor update notices it's still "close enough". It may be enough to
            > just erouter->removeListener(...) the triggering event after you
            > start the motion, and then addListener(...) again the next time you
            > are trying to approach.
            >
            > By the way, if you added your motion sequence as "prunable", then you
            > can listen for a (motmanEGID,YOUR_MC_ID,deactivateETID) event to
            > signal when it has been pruned. Alternatively, with the current code
            > out of CVS, you can listen for (motmanEGID,YOUR_MC_ID,statusETID) to
            > signal when it has completed, regardless of whether it is prunable or
            > persistent.
            >
            > -ethan
            >
            >
            > On May 2, 2006, at 6:52 AM, Thijmen Bink wrote:
            >
            >> I will put some more time into this issue then and see if I can
            >> make it
            >> work with examening those runs. Thanks for your advice :)
            >>
            >> But my group has run into something else aswell. When we create
            >> behaviors
            >> with motions, our AIBO can become a shocking.. AIBO.. For example:
            >> We ask him to walk towards the ball and make a shooting motion when
            >> he's
            >> close enough. He will walk towards it then.. and when he's close
            >> enough,
            >> he will shoot.. and again, and again etc.. These motions aren't
            >> handled
            >> one at a time but seem to be cancelled when the new motion comes
            >> in. Thus
            >> the first shooting motion takes 20 miliseconds, the new motion
            >> comes in
            >> and does those 20 milisecs again.. and so on. Untill he won't shoot
            >> anymore (losing the ball) he won't stop stacking these events/motions.
            >>
            >> We seem to be needing some sort of lock, which we've tried at several
            >> places but it didn't work. Can you point out what we're doing
            >> wrong, or
            >> what we should be doing?
            >>
            >> Thijmen Bink
            >>
            >>
            >> SPONSORED LINKS
            >> Industrial robotics Mechanical engineering software Robotics
            >> Fanuc robotics Applied robotics Robotics technology
            >>
            >> YAHOO! GROUPS LINKS
            >>
            >> Visit your group "tekkotsu_dev" on the web.
            >>
            >> To unsubscribe from this group, send an email to:
            >> tekkotsu_dev-unsubscribe@yahoogroups.com
            >>
            >> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
            >>
            >>
            >
            >


            -- You have been messaged by The Binkster --
          Your message has been successfully submitted and would be delivered to recipients shortly.