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