Re: UPennWalkMC affects motions?
- "Thijmen Bink" <tjbink@...> wrote:
>Yes we've encountered that too, this seems to be different because the
> 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.
motions worked fine with the regular WalkMC, but stutter using the
> For example you have your headcontroller on, while a behavior isI am not sure if how we were using headcontroller was blocking the
> trying to control the head too (same happens when 2 such behaviors
> are on).
other motions. For now we are only using motions / postures to set
> If that's not it I would be interested in the other details since myWe will continue to work on it, but we are working on other tasks
> team is looking at using that too now.
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.
- 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
- Hi Ethan,
Ethan Tira-Thompson <ejt@...> wrote:
> So, to solve aspect, either modify the UPenn walk code to quicklyDeleting the call to StandLegs when velocity was (0,0,0) fixed the
> 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.
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).