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

Re: UPennWalkMC affects motions?

Expand Messages
  • Steven Kryskalla
    ... Yes we ve encountered that too, this seems to be different because the motions worked fine with the regular WalkMC, but stutter using the UPenn walk... ...
    Message 1 of 5 , Jun 4, 2006
    • 0 Attachment
      "Thijmen Bink" <tjbink@...> wrote:
      >
      > Well in my experiences there are 2 main problems that can cause
      > stuttering or weird motions. Either it was because motionsequences were
      > being send to the engine, overriding the current motionsequence, or
      > mutliple things are sending motions/postures to joints.

      Yes we've encountered that too, this seems to be different because the
      motions worked fine with the regular WalkMC, but stutter using the
      UPenn walk...

      > For example you have your headcontroller on, while a behavior is
      > trying to control the head too (same happens when 2 such behaviors
      > are on).

      I am not sure if how we were using headcontroller was blocking the
      other motions. For now we are only using motions / postures to set
      the joints.

      > If that's not it I would be interested in the other details since my
      > team is looking at using that too now.

      We will continue to work on it, but we are working on other tasks
      right now :( Hopefully someone will have some advice for us. It
      would be nice if we could get the UPenn walk to work, but if it is too
      much trouble we will stay with the default walk.

      Steve
    • Ethan Tira-Thompson
      Hi, sorry for the delay -- I was off on a trip. I agree with Thijmen... the basic problem is conflict between motions, but I think you re seeing two separate
      Message 2 of 5 , Jun 4, 2006
      • 0 Attachment
        Hi, sorry for the delay -- I was off on a trip.

        I agree with Thijmen... the basic problem is conflict between motions, but I think you're seeing two separate issues -- the UPenn walk only uses the leg joints, so any problems with the head are separate.  In particular, leaving the Head Remote Control window open does unfortunately conflict with other behaviors trying to use the head... we fairly recently stumbled over this ourselves.  If this is the problem, the fix is fairly simple: in Behaviors/Mon/HeadPointControllerBehavior.cc, change:
          head_id = motman->addPersistentMotion(SharedObject<HeadPointerMC>());
        to:
          SharedObject<HeadPointerMC> headmc;
          headmc->setHolding(false);
          head_id = motman->addPersistentMotion(headmc);

        (need to get that setHolding(false) call in there)

        Of course, alternatively, you could just not leave the remote control running ;) (but the tricky part is, you need to turn off the server running on the Aibo, not just the GUI window that connects to it... you'll notice the server you launch to bring up the window stays running after window closes simply because we don't have any mechanism in place to send a message back when the window closes.)

        As for the walking, the problem probably stems from a small difference between the default walk engine and our port of the UPenn one: when the walk is set to (0,0,0), the default engine does nothing -- a quick return, and no control of any joints.  This allows other behaviors to use the joints.  The UPenn walk doesn't have a special case for (0,0,0) -- it's still controlling the joints, actively holding them (marching in place?).

        So, to solve aspect, either modify the UPenn walk code to quickly skip out of updateOutputs/WalkLegs if its target velocity is 0, (probably a good idea, send in the modification if you do) or modify your controlling code to remove and later re-add the walk when not in use, or similarly drop its priority to MotionManager::kIgnoredPriority.

        -ethan

      • Steven Kryskalla
        Hi Ethan, ... Deleting the call to StandLegs when velocity was (0,0,0) fixed the problem for us (although we may have changed some of our other code around
        Message 3 of 5 , Jun 9, 2006
        • 0 Attachment
          Hi Ethan,

          Ethan Tira-Thompson <ejt@...> wrote:
          > So, to solve aspect, either modify the UPenn walk code to quickly
          > skip out of updateOutputs/WalkLegs if its target velocity is 0,
          > (probably a good idea, send in the modification if you do) or modify
          > your controlling code to remove and later re-add the walk when not in
          > use, or similarly drop its priority to MotionManager::kIgnoredPriority.
          >

          Deleting the call to StandLegs when velocity was (0,0,0) fixed the
          problem for us (although we may have changed some of our other code
          around too). It doesn't make for much of a patch, but I added it to
          the bug tracker (#229).

          Thanks,
          Steve
        Your message has been successfully submitted and would be delivered to recipients shortly.