karl3＠writeme.com wrote:
> karl3＠writeme.com wrote:
> > karl3＠writeme.com wrote:
> > let's think about my old walking algorithm ^_^
> > the (emotional/executive) problem with the walking algorithm is a few fold
> > 1 producing or facilitating a set of geometric (or physics or dynamics)
> > primitives sufficient to enable step planning
> > 2 writing and wiring a small-depth plan solver to resolve which foot to
> > move first in edge situations
> > 3 combining everything with a physical or simulated armature, and then
> > debugging it
> > now part 2 has prerequisites that are also significant:
> > 2a defining the state of a step of sufficient use to fully plan a good step
> > 2b defining and sufficiently coding the uses of the various constraints of
> > the system: joint extremes, center of mass positioning
> > 2b also has subparts
> > 2b-1: [i don't quite remember but one runs into it when trying to do the
> > whole thing together]
> > 2b-2: annotating an armature with sufficient structured information (limb
> > graph in 3-space with mass) to derive the various constraints
> > something that's missing in here may be the utilization of paths of motion
> > through areas where constraints are continuously satisfied in the same
> > manner. doing this is kinda what makes the system analytically solvable on
> > an arduino by a disabled guy -- the constraints only matter at the points
> > in these paths where they change, i.e. when the structure would fall or
> > reach a joint extreme
> > :D
> > _now_ a lot of this is already done for the specific thing i was doing it
> > for, in the fuzzytew/toywalker github repo, but work towards the specific
> > goal is roughly lost. {so ... ummmmmmmmmmmmmmmmmmmmmmmm <this algorithm is
> > not in the repo.
> > the big blocks for this algorithm involved combining the planner w--
> > so the algorithm could be reoriented/refactored in various manners, and
> > doing so could be useful to generalize components since the original wasn't
> > made;
> but the original plan was for it to be conditioned on a path of motion of the
> center of mass, and an environment in which it must step through.
>
> then in the planner, it considers each foot to lift first -- opening n
> branches of a decision tree. in each branch, one foot is carrying no weight,
> so the center of mass must be moved to prevent fall. the center of mass is
> moved as far as it can go along planned path (note if you have a "head" full
> of sensors it might make more sense to plan the motion of the head rather
> than the center of mass, of course many people train RL models and use model
> inference hardware), and the lifted foot is moved to the best spot to support
> the center of mass for the next length of path (i was going to use a
> heuristic that assumed roughly straight paths to start with, basically you
> can predict the location of the armature along the path in the future and
> place the foot so that it has the largest range of motion, kinda; this could
> also be done with a feedback loop if a better solution is needed in a pinch).
>
> rather than busy waiting, it ideally uses its runtime to consider further
> steps in the future, but since it became so hard to implement the decision
> tree exploration strategy doesn't matter at this point
>
> then it picks the foot to pick that provides for the path to succeed, using a
> heuristic (like longest length covered) to break ties :)
>
> i was going to start with only static concerns rather than dynamic concerns,
> so the center of mass would be kept above the convex polygon enclosed by the
> unlifted feet.
>
> and there's the spot of confusion >(
so i found myself at the toywalker repo sad to discover other attempts to work
on haven't reached/stayed github. likely relates having issues very quickly
when engaging code ... next bit was going/trying to add was geometric
primitives for convex polygon to calculate center of mass constraint
