A

• Read and organized Tim/Jack's predictive sim code.
• Completed an opensim planar walking model that matches Gait2D.
• Discussed dynamics software with Sherm.
• Mentored GSoC students and prepared for final two weeks. Contributed to a System class to help Tarun move forward.
• Met twice with Jack Wang and once with Ajay about utilizing Jack's work along with my data. Less clear now if there is anything worth doing there.
• Read Tim, Jack et al's preprint.
• Hashed out an opensim computational plan for direct collocation system id on a planar walking model with gait gain scheduled full state feedback torque control. Got Ajay's advice on this.
• Learned the basics of using the eigen C++ lib.
• Built a simbody conda package.

O

• Run extensive tests on the inverted pendulum system id system and summarize the method's abilities to identify the controller for a variety of # of degrees of freedom, initial guesses, measurement noise, discretization intervals and simulation durations. The idea is to make sure that the scale of the gait control id problem can be solved.
• Complete the controller implementation in opensim.
• Start on the direct collocation code: data loading, objective func, etc.
• Learn some about O(n) multibody dynamics with Sherm.

I

• Still haven't successfully compiled Opensim with working Python bindings. The SWIG stuff eats up about all the memory on my machine so it is painful to compile it. Started work on binary installers for simbody and opensim for the conda package manager with Chris to address this (for others at least).
• Floundered around in idea space and didn't make much progress on implementing an opensim system id approach.
• Slow movement in C++ development.

Ajay's Comments

jen taro taga in the 80s had a CPG for a walking model, global lean angle, phase of legs with respect to global angle, simulation, big paper in 1995

idea: think about having an indirect method working and then having varying in complexity plant so you can keep adding complexity to the plant and keep identifying the different controllers where you can find different controllers given different complexity plants. With the most complex plant you might identify the neuro stuff that there is no model for.

Once you have an indirect identification method working that has a plant and controller model in place for the "simplest" plant model (i.e. joint torque controlled low DoF, simplest contact) you will be able to identify this lumped "controller" which has everything in the dynamics that isn't modeled by your plant (and measurement noise). At first this lumped controller includes muscle dynamics, neuro stuff, passive joint dynamics, etc. Then you can imagine adding things to the plant model, like muscles, and running the id again, then you get a "controller" that lumps fewer things. Maybe you can tease apart unkown and known dynamics, where the "controller" holds all the unknowns.

Ajay also had the idea that we can simulate Jack's walking model and then change specific things in it, like time delays, and then see if the identification results show these changes. i.e. can you detect the explicit model changes in the identified high space controller.

O(n) Lecture by Sherm

Autolev: for forward dynamicists so they can see the code

SD Fast

Symbolics: big problems will not fit in cache

Kane style: generated code is n cubed, order n though witll not have the cache problem as soon.

Just as easy to do the symbolic version as a numeric version.

Symbolic: a code generator of some sense

Somewhere around 10 bodies the O(n) is faster. SD/Fast had a switch for O(n) or O(n^3). 20 bodies were definitely faster with O(n).

1991 Abhi Jains' paper proves all O(n) methods are the same.

Featherstone: discusses it better. Jain: Better presentation in papers.

Featherstone: Chatper 1 is plucker vectors: but it isn't that important. Jain spends only a paragraph on Featherstones chapter 1.

THe Jain papers have better notation than Jains book.

Sherm learned from Charles Schwiter's paper. (molecule stuff)

Jain: counts the bodies from the out in which seems odd and becomes annoying to keep track of things.

Simbody's numbering is ground out numbering but Jain's alg.

Mobilezers: start by thinking of bodies fixed then mobilizing DoFs, instead of bodeis with full motion and removing dof with constraints. internal coordinate joint that doesn't involve a constraint.

Constraints are restrictions on mobilities.

• Good abstractions make good code. Code can't be any better than your abstractions.
• Make your data structures so that you can write the alg in the code just like Jains printed alg.
• Spatial notation: spatial combines rot and trans

APL language required a special keyboard.

Spatial M;
Spatial V;

SpatialVec P = M * V; // spatial momentum

Real ke = ~V * M V / 2; // kinetic

Jain: greatest contribution, computes everything in the ground frame (as soon as

you possibly can). You never want to rotate an articulated body inertia!

SD/FAST started by defining the base frame to the CoM which was bad. So start

with a frame that is just attached at an arbitrary point on the body.

Sherm recommends using a notation that maps to the mathematics really well so you can spot errors when comparing to the main Jain algorithm.

Seth et al Nonlinear dynamics 62, 2010 shows mobilities.

It is advantageous to create a ground body as a default parent body. We may need that in pydy.

Articulated body algs in simbody:

realizeArticulatdBodyInertiasInward.cpp everything is in ground frame Phi: shift op that shifts forces for example to different points

• artic body inertia is a 6x6 same flavor of spatial inertia: linear realtion with three forces and three torques and the spatial accel
• PPlus is P shifted across the joint
• Projecton of art inertia on the null space of the joint. Sucks out the effect of the joint. AlG 6.1 in jain's book.

Articulated inertia is known for terminal bodies: it is spatial inertia of that body.