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 >(
