About Physics modeling.

[Julio Jerez]

This new thread is in response to these two treads.
http://www.newtondynamics.com/forum/viewtopic.php?f=9&t=9775&hilit=balance
http://www.newtondynamics.com/forum/viewtopic.php?f=9&t=9800&p=67638&hilit=balance#p67638

One of the things that have been pointed out to me (Daved Gravel, also other people) is that the engine is hard to use.
Most people when the come to the engine that learning curve is too high.
some people eventually overcome that phase, but only if when had the necessary programing skills to persevere.
The demos are too complex, most are work in progress and unreliable.

Even I have a hard time reading them when I come back to a demo after few weeks or month of doing something else.

What I get form that is that most user expect some realizable core stuff that that can use. and that is agnostic of programing style, graphics APY, throes party library, etc.

also the engine we need to provide reliable modeling solutions, that are not part of a demo.
there are not solutions stuff like a Rag Doll, and Box Car, and helicopter, and airplane, and so on.

base on that assumption and observation, a while back I start adding separate libraries that are solution to thing that can be used to model physics. on that regard I added.
- A deep learning library, for making complex functions.
- the load/save library.

next I am planning to add the dModel and the Authoring
all these libraries are optional.

The point of a library like dModel will be to move the functionality in the demos, to teh library, and have the officially supported.

The one difference is that, for most models I will put her the designing considerations.

My intension is that all will have a root on physically based, them there will be the Constrain considerations for eth implementation.

I will start with the most basic model, but my goal is to get to the balance walking models.
so this will be more like a blog of what we are doing.

people are welcome to make suggestion, agreement or disagreements.

[JoeJ]

Even I have a hard time reading them when I come back to a demo after few weeks or month of doing something else.

I have this problem with my own code too.
But interestingly it does not become better as my code becomes better. It becomes worse.
The better the code is, the harder it is to use, i feel.

However, i can share the experience i've had with the car for some feedback.
The high level code was two classes made for the sandbox demo, which i have copied.
It was not really clear to me what's the reason to have two classes. Probably a base and an example for a certain type of vehicle.
Some dependencies on the demo were a problem, e.g. the 3D models or the configs with parameters. So i could not replicate the same car you have in the demo, and it also caused me some work e.g. to set up tires without having the models.
In the end it worked, but not as well. My car was hard to steer and started sliding too easily. For a quick fix, i made the turning radius depending on speed, which helped a bit.
It would be nice if you would set up things like mass properties, tire dimension and locations procedurally with code, without depending on the 3D model. Then it would be easier to replicate your behavior as in the sandbox, and after that start to tweak the working parameters as desired.
I've also spend some work to make it fun to drive, mainly automatic reverse gear when holding the break button. And ofc. the things related to application frameworks, e.g. detecting button presses.
After the update with the shared pointers my copy was broken, and likely you did improvements on the car as well.
So at some point i'll do an new copy, expecting i've to do all this work again.
That's not coming unexpected, because i know things like vehicle, IK or fluid are WIP.
But a newcomer not knowing this might be annoyed. So maybe you want to mark WIP stuff as such, so everybody knows breaking changes are very likely.

Ideally you would create some class to abstract application and model stuff, so we would need to change only this, and the other vehicle classes could become part of the engine already. But i do not expect such polish from a one man project. The work spent on porting wasn't much, nor was it difficult.

Regarding tools to edit models, e.g. something to choose car type and edit proportions, or a character editor (not sure what you have in mind),
personally i would likely not adopt them, and i also expect to make my own file formats for serialization etc.
That's because i already have such tools, or make them on demand.
But that's just me. Others may be happy about some framework to make tools and extend on it.
And you need to make them for your own development anyway.

[Julio Jerez]

yes, all very good points and well taken.
I start form the simple to the more complex.
I those of going with Box car first, but I realize that in fact is not the simple model.

one of the simplest model, believe it or not, is the passive ragdoll.
the reason is that it does not has any input controls.

so whet the Ragdoll we can address the problem with asset dependencies.

you are right I got carried away adding dependency on the model, there is nothing wrong with that, Game does all the time, But a Tool like a physics engine should no do it, and if it did, it should be very clear to end user how to replace for its own uses.

the ModelPassiveRagDoll will be the first model and as you said, that mopdel is configyre from and fbx in with there are lot of nodes with information's.

so that will be the very first challenge.

the Goal is how to make the ModelPassiveRagDoll by any one is such way that the could just do it in there own app the same way a Body, or a joint is made.

also, the client app should be able to load a saved model, save form eth demos without any problems, currently that not possible.

after that, I will move to the vehicles, which also has different challenges.

[Dave Gravel]

Hi Joej,
Regarding the vehicle, there are several things to take into account. Firstly, the tires have their own friction model, such as ndTireFrictionModel::m_brushModel. For some friction models, the implementation may not be complete if I remember correctly. Additionally, the tires use a different material, which needs to be configured for each wheel. If you are using a mesh for the chassis, it's important that it is oriented in the correct axis. I don't recall the exact axis, but in Blender 3D, I always have to ensure that my vehicle chassis is placed in the correct direction. This may depend on how I load my meshes, but it can greatly affect the behavior of the vehicle.

Another important thing to consider is the slip differential. It is crucial that the wheel creation is done in the same order as in the demo, which is rr_tire, rl_tire, fr_tire, fl_tire. If the order is different, it can lead to problems in the functioning of the differential. The same applies to AddAxel. If the wheel order is different, the vehicle will still work, but it may exhibit strange reactions, poor friction, or poor mass balance.
Another thing that can make a big difference is if you use different values for m_motorMass, m_motorRadius, m_differentialMass, and m_differentialRadius. This completely changes the behavior of the vehicle.

[Julio Jerez]

ok moving on with the first model, a Rag Doll.
if you sync and build, you will see that the demo is set to ndRagdollTest.cpp.

the now will use the new ndModelPassiveRagdoll from the model library.

basically this is a sub class of a ndModelBase.

a model base is just a collection of body and joints with not specific relation to each other,
it is more like an interface for the application and other libraries.
the File format library use this for saving and loading the model parts.
There will be other functionality on the ndModelBase, stuff like Model Notification and inputs, but for now we do no need it.

them, ndModelPassiveRagdoll stablish the parent child relation between bodies
since the rag doll is passive that very much all there is to it.

right now I onle added the root node, so that people can see what is going on.

when this model is saved it looks like this.

Code: Select all

<?xml version="1.0" ?>
<ndFile>
    <ndWorld>
        <ndPhysicsWorld className="ndPhysicsWorld" nodeId="0">
            <ndWorld className="ndWorld" nodeId="1">
                <subSteps int32="2" />
                <iterations int32="4" />
            </ndWorld>
        </ndPhysicsWorld>
    </ndWorld>
    <ndShape>
        <ndShapeClass className="ndShapeConvexHull" nodeId="2">
            <ndShapeClass className="ndShapeConvex" nodeId="3">
                <ndShapeClass className="ndShape" nodeId="4" />
            </ndShapeClass>
            <points count="58" float3Array="-0.014207 0.021723 -0.142141 " />
        </ndShapeClass>
        <ndShapeClass className="ndShapeConvexHull" nodeId="5">
            <ndShapeClass className="ndShapeConvex" nodeId="6">
                <ndShapeClass className="ndShape" nodeId="7" />
            </ndShapeClass>
            <points count="58" float3Array="-0.014207 0.021723 -0.142141" />
        </ndShapeClass>
    </ndShape>
    <ndBodies>
        <ndBodyClass className="ndBodyDynamic" nodeId="8">
            <ndBodyClass className="ndBodyKinematic" nodeId="9">
                <ndBodyClass className="ndBody" nodeId="10">
                    <ndBindingNotifyClass className="ndBindingRagdollEntityNotify" nodeId="11">
                        <ndNotifyClass className="ndDemoEntityNotify" nodeId="12">
                            <ndNotifyClass className="ndBodyNotify" nodeId="13">
                                <gravity float3="0.0 -10.0 0.0" />
                            </ndNotifyClass>
                            <useCollisionForVisual int32="1" />
                        </ndNotifyClass>
                        <bindMatrix>
                            <posit float3="0.0 0.0 0.0" />
                            <angles float3="0.0 -0.0 0.0" />
                        </bindMatrix>
                        <capSpeed float="100.0" />
                    </ndBindingNotifyClass>
                    <matrix>
                        <posit float3="-0.008467 1.2046 -0.001177" />
                        <angles float3="0.0 -0.0 -90.000023" />
                    </matrix>
                    <omega float3="0.0 0.0 0.0" />
                    <velocity float3="0.0 0.0 0.0" />
                    <centerOfMass float3="-0.051485 0.004352 0.001253" />
                </ndBodyClass>
                <ndShapeInstanceClass className="ndShapeInstance" nodeId="14">
                    <shapeNodeIdRef int32="2" />
                    <scale float3="1.0 1.0 1.0" />
                    <skinMargin float="0.0" />
                    <localMatrix>
                        <posit float3="0.063804 0.006622 0.001177" />
                        <angles float3="0.0 -0.0 91.099983" />
                    </localMatrix>
                    <alignmentMatrix>
                        <posit float3="0.0 0.0 0.0" />
                        <angles float3="0.0 -0.0 0.0" />
                    </alignmentMatrix>
                    <material count="8" int64Array="0 0 0 0 0 0 0 0" />
                </ndShapeInstanceClass>
                <invMass float="1.0" />
                <inertia float3="0.008802 0.03931 0.034466" />
                <principalAxis float3="0.0 -0.0 0.0" />
                <useSkewInertia int32="0" />
                <maxLinearStep float="1.0" />
                <maxAngleStep float="90.0" />
            </ndBodyClass>
            <linearDampCoef float="0.0" />
            <angularDampCoef float3="0.0 0.0 0.0" />
        </ndBodyClass>
        <ndBodyClass className="ndBodyDynamic" nodeId="15">
            <ndBodyClass className="ndBodyKinematic" nodeId="16">
                <ndBodyClass className="ndBody" nodeId="17">
                    <ndBindingNotifyClass className="ndBindingRagdollEntityNotify" nodeId="18">
                        <ndNotifyClass className="ndDemoEntityNotify" nodeId="19">
                            <ndNotifyClass className="ndBodyNotify" nodeId="20">
                                <gravity float3="0.0 -10.0 0.0" />
                            </ndNotifyClass>
                            <useCollisionForVisual int32="1" />
                        </ndNotifyClass>
                        <bindMatrix>
                            <posit float3="0.0 -1.081331 0.0" />
                            <angles float3="0.0 -0.0 0.0" />
                        </bindMatrix>
                        <capSpeed float="100.0" />
                    </ndBindingNotifyClass>
                    <matrix>
                        <posit float3="0.0 1.081331 0.0" />
                        <angles float3="0.0 -0.0 -90.000015" />
                    </matrix>
                    <omega float3="0.0 0.0 0.0" />
                    <velocity float3="0.0 0.0 0.0" />
                    <centerOfMass float3="0.032229 0.014571 0.000079" />
                </ndBodyClass>
                <ndShapeInstanceClass className="ndShapeInstance" nodeId="21">
                    <shapeNodeIdRef int32="5" />
                    <scale float3="1.0 1.0 1.0" />
                    <skinMargin float="0.0" />
                    <localMatrix>
                        <posit float3="0.157806 0.027379 0.0" />
                        <angles float3="0.0 -0.0 95.799988" />
                    </localMatrix>
                    <alignmentMatrix>
                        <posit float3="0.0 0.0 0.0" />
                        <angles float3="0.0 -0.0 0.0" />
                    </alignmentMatrix>
                    <material count="8" int64Array="0 0 0 0 0 0 0 0" />
                </ndShapeInstanceClass>
                <invMass float="1.0" />
                <inertia float3="0.008996 0.043847 0.039075" />
                <principalAxis float3="0.0 -0.0 0.0" />
                <useSkewInertia int32="0" />
                <maxLinearStep float="1.0" />
                <maxAngleStep float="90.0" />
            </ndBodyClass>
            <linearDampCoef float="0.0" />
            <angularDampCoef float3="0.0 0.0 0.0" />
        </ndBodyClass>
    </ndBodies>
    <ndJoints>
        <ndJointSpherical className="ndJointSpherical" nodeId="22">
            <ndJointClass className="ndJointBilateralConstraint" nodeId="23">
                <body0 int32="10" />
                <body1 int32="17" />
                <localMatrix0>
                    <posit float3="0.0 0.0 0.0" />
                    <angles float3="0.0 -0.0 0.0" />
                </localMatrix0>
                <localMatrix1>
                    <posit float3="-0.12327 -0.008467 -0.001177" />
                    <angles float3="0.0 -0.0 -0.000007" />
                </localMatrix1>
                <solverMode int32="1" />
            </ndJointClass>
            <rotationTarget>
                <posit float3="0.0 0.0 0.0" />
                <angles float3="0.0 -0.0 0.0" />
            </rotationTarget>
            <springConstant float="0.0" />
            <damperConstant float="0.25" />
            <springRegularizer float="0.1" />
            <minTwistAngle float="-15.0" />
            <maxTwistAngle float="-15.0" />
            <maxConeAngle float="30.0" />
        </ndJointSpherical>
    </ndJoints>
    <ndModels>
        <ndModelPassiveRagdoll className="ndModelPassiveRagdoll" nodeId="24">
            <ndModelBase className="ndModelBase" nodeId="25">
                <ndModelClass className="ndModel" nodeId="26" />
                <bodies count="2">
                    <body int32="17" />
                    <body int32="10" />
                </bodies>
                <joints count="1">
                    <joint int32="23" />
                </joints>
            </ndModelBase>
            <limb>
                <childBody int32="17" />
                <parentBody int32="0" />
            </limb>
            <limb>
                <childBody int32="10" />
                <parentBody int32="17" />
            </limb>
        </ndModelPassiveRagdoll>
    </ndModels>
</ndFile>


the idea is that, any app should be able to just load that model and them customize it.
right now loading is not implemented but I will try to work on it this weekend.

[blackbird_dream]

I am not expert in computing but in Mechanics (solid mechanics as well as rigid bodies mechanics and Structure Dynamics).
I found a good compromise using FPC (Lazarus) and GLScene.
With GLScene I don't have to handle OpenGL stuffs.
FPC is concise (no header files for instance) and HMI are drag and drop unlike in C++.
In my opinion, the result is a better way of understanding Newton Dynamics concepts because the code is easier to read.

ps1 : we're still working on the model of autonomous biped in forward dynamics. i'll let you know.
ps2 : consistently I'm still interested in V4 for fpc

[Julio Jerez]

yes, the graphics. can be a big obstacle for many people. This is why I am trying to make the dModel library agnostic of Graphics.
but even when no using graphics, when modeling complex contractions of bodies and joint,
it could get difficult to many users.

I am hoping that using the FileFormat with some rudimentary authoring, that it could alleviate the difficulties.

Usually, people find easing when the going one the parsing or a file than when trying to figure out the math or complexity of a demo.
some stuff on eth demos, are like back box magic. and that is a big problem.

the autoring tool, I will postpone until the file load and save and model libs are fully functional.

on this

ps1 : we're still working on the model of autonomous biped in forward dynamics. i'll let you know.

I have a different opinion, but I am not one that can speak with authority since I have failed so many times.

this is what I learn from reading, what I guess is over 30 papers, some good, so mediocre, and quite frankly the majority just nonsense.

I understand that when a Grad student write those papers, that they do no have to have everything right, but I also believe that it is quite dishonest that many those paper flood the internet as if they are all peer reviewed.
you find them even on peer review journals, and when you readd them you can see that most of the stuff is untested and sometime just wrong.
Very disappointing how the internet has deluded the distribution of information which seems to be based on fallacious majority of clicks, rather than rigorous peer review. now click counts equally or even stronger the citations.

anyway, what I am further alone on the libraries. I am going back to the Self-balance quadruped walk.

I will put all the development here. but I can give some summary.

I will not start with the biped. many time I did that, and to me, the problem with that is that it is a muti issue problem.

the criteria for a Biped walk, is that they are dynamically stable and statically unstable for the large majority of the walk cycle, while a quadruped base on the motion cycle, are always dynamically and statically stable.

so solving for a quadruped walk, reduces to solving the phase of the motion when the creature become statically unstable, and what accion can make it stable.

this is s subset of the more general motion.
Them, if I succeed on that, I move to a bipedal motion.

I will start with the basic's definitions, the basics criteria and from there see how I can justify my assumptions.

[blackbird_dream]

I am not open that can speak with authority since I have failed so many times.

I don't understand this.
I wrote

I'll let you know

about the progress we made if we make some.
I'm not working on the basis of grad student papers and I am not a grad student.

[Julio Jerez]

I mean
I am not one that can speak with authority, given that I failed so many time at trying to stabilize a biped.

So the next time, I will take few step back, and try to model the motion of legged creatures that are statically stable.

By this, I mean that when the model is not moving it will not fall.
The model will lost stability for a brief moment when start to move. This means, the movement algorithm can anticipate the motion before the point of instability is reached. It does that by shifting the center of mass, toward a point inside the support feature.

For most quadruped, this is the case.

Most biped, like humans, are dynamically stabled and statically unstable, meaning if it stops the motion, it will fail.

In the pass 20 years, robots like Honda Assimo and also today's all of those toy robot's, are statically stable.

This is why they have huge feet, this allows for relatively large support plane.
The problem is that making a biped walk kipping it statically stable, is that the movement is very unnatural and high energy. Stride are short since it needs to keep the center of mass inside the foot plant. You can see all of the hip shifting, which make the cycle slow, clumsy, high enery and unnatural.

I think that Boston Dynamics figured out how to make a dynamically stable walks.
So their motion is more dynamics and gracious.

For that I believe they still use the concept of the zero moment point.

When I get there I will put all those concept, definition and critirias, in the form of equations, so that we know precisely what the goal is.

I do read the papers, I gives me background info, so that at least I know what not to try.

But, any way, my point is that if I accept that separation
Dynamic vs Static stable legged motion,
Them I am dealing with two problem which make for a more compound solution. Therefore, to me it makes sense if I try with a simpler one first.

Quadruped are models that by definition are statically stable.

Btw, a six-legged creature, is one that is statically stable at all time.
the motion reduces to just playing the animation sequence, assuming that at least three legs will be in contact with ground at all time and the com falls inside the support polygon.
Those are uninteresting physically but can be useful to test animation driving physics sim.

so as you can see the learning curve has many obstacles. and I have been arrogant thinking that I can simply skip them.

[Julio Jerez]

I have spent many years, trying to get this, reading the literature.
I have learned techniques like:
zero moment point, statically stable, dynamically stable, support polygon criteria. and the most I got is very, very little progress to show.

I do not think brains do that kind of complex math just to keep balance, there must be a simpler method. Even insects who have many legs can actually walk in two legs.

The most I have gotten is a humanoid balanced keeping the cg inside the support polygon.
But even that is a method that is highly unstable, since getting that information is very unreliable, even one flat plane.

From there, I try the AI methods, not in depth, but I do not really want to try an AI method, get a result and them not been able to understand why it works.

They say a definition of insanity is repeating the same thing, expecting different results.

there is not reason that trying again a zero-moment point method will work, but even if it did the method is so limited that it will be useless.
I respect the people who came with the criteria, I actually learned a lot from reading the papers.
but I believe at the end of the day, even the most successful experiments, like Asimo are is quite limiting.

so from now on I will develop my own method.

I will start by writing the math before writing any code.
This week, I will make a series of post developing the math rigorously, following the law of physics.

Them applying a criteria and assumptions.
testing with simple examples, that can be solved manually on paper before coding it.

we will start from the very basic concepts even if is a repetition of stuff with now already.

[Julio Jerez]

Here is the model, I am using, but the development of the equation should generalize to more general rigged models.

This model is simple enough and we know is easy to balance those devices.

Untitled1.png (97.7 KiB) Viewed 15357 times

this is the abstraction of the model represented as connected rigid bodes.

Untitled.png (5.28 KiB) Viewed 15357 times

[Julio Jerez]

ok, based of the graphs, the first rule we are going to stablish, is that the entire set of connected bodies will act as a single body with origin at the center of mass cg.

therefore: the single body will have:
Cg = center of mass of all connected bodies.
Mt = total mass = sum of all mass(i)
It total inertial = sum of all inertia I(i) + central theorem limit.

Vcg = cg velocity,
Wcg = cg omega.

Acg = cg acceleration,
Bcg = cg angular velocity.

the criterion for equilibrium is that the body array will be balanced if the horizontal component of the angular acceleration of the equivalent single body, with center of mass cg, mass Mt and inertia It, is below some small tolerance.

if my criteria is wrong, the model will not work.

so the algorithm for balancing the model is this.

Code: Select all

-calculate quantities. Cg, Mt, Vcg, It, Wcg, Acg, Bcg
-repeat until Bcg.x and Bcg.z are below some small value or the max iteration is reach.
     -Move some internal actuated joint, to generate a change Cg, Mt, Vcg, It, Wcg, Acg, Bcg
     -such that  Bcg.x and Bcg.z decreases toward a small value.


that's the pseudo code for the control loop.
so far we had done nothing, we just have an objective.
but as you can see no where we make reference to support polygon, center of pressures, contact points or any of that other stuff we find in the literature.

the first part is how to calculate each one of the quantities: Mt, It, Vcg, Wch, Acg, Bcg
some are simpler than others, but I believe we have all the tools.

in the next post we will go over for the simpler to the more complex.

[Julio Jerez]

ok let us start solving this part

-calculate quantities. Cg, Mt, Vcg, It, Wcg, Acg, Bcg

here there are several values that we need to compute. we take one at a time from the easier to the more complex.
the easier are the linear values: Mt, Cg, Vcg

notice that there will be extra terms that will emerge from of the calculus of the derivation.

for the Total Mass, it is straightforward

Mt = m(0) + m(1) + m(2) + .... m(n) = sum (M(i))
a) Mt = sum (M(i))

for the Cg is also quite simple

Mt * Cg = p(0) * m(0) + p(1) * m(1) + p(2) * m(2) + .... p(n) * m(n) = sum (p(i) * M(i))

b) Cg = sum (p(i) * M(i)) / Mt

for the linear Vcg with use the definition of total linear momentum which is the time derivative of expression b

Mt * Cg' = p(0)' * m(0) + p(1)' * m(1) + p(2)' * m(2) + .... p(n)' * m(n) = sum (p(i)' * M(i))

Mt * Vcg = v(0) * m(0) + v(1) * m(1) + v(2) * m(2) + .... v(n) * m(n) = sum (v(i) * M(i))

c) Vcg = sum (v(i) * M(i)) / Mt

so for the linear case we have three expressions that we can evaluate at each step and come out of the current state of the model.

Code: Select all

a) Mt = sum (M(i))
b) Cg = sum (p(i) * M(i)) / Mt
c) Vcg = sum (v(i) * M(i)) / Mt


so, for the linear part, this is not complicated at all, all these quantities are computed from the model current state. but we still do not have anything yet, just some needed values.

[Julio Jerez]

ok, we now derive the equation for the angular acceleration of the center of mass.
first some observations.

the first thing we notice is that when deriving the linear velocity and acceleration of the entries array of object, we start with the position of the object which is represented by the center of mass of each individual body.
we assume that the motion for a rigid body is represented the linear motion of each position of each particle of the body, and from that axiom we decide that the Mass, and the moment of intuition are the scalar value of the linear velocity and angular velocity of the body center of mass.

I am not deriving those equations, because these can be found on Wikipedia or any other site.
but I am introducing them here because. those are the same principles we are going to use to represent the collection of bodies as a single virtual body.
the difference is that for a rigid body some terms on the angular momentum are zero, and that why we never see them represented, but for a collection of bodies they are not zero.

with the stated, let us write the expression for the angular momentum of a rigid body relative to some arbitrary point.

angular momentum will be expressed by the let L,

and is give by.

L = (r - cg) x (m * Vcg) + I * w

L = angular momentum,
r = arbitrary point
cg = center of mass
m = mass
Vcg = velocity of center of mass
I = moment of inertia
w = angular velocity.

we will now demonstrate without proof that when we are dealing with only one body, and r is taking as cg that L and it derivative is zero.

if we substitute r equal cg in the Abebe expression, we get:

L = (cg - cg) x (m * Vcg) + I * w

and since cg - cg = 0

we get for a single rigid body,

L = I * w

if we calculate the time derivative of L

we get

L' = (r - cg)' x (m * Vcg) + (r - cg) x (m * Vcg)' + (I * w)'
L' = (Vr - Vcg) x (m * Vcg) + (r - cg) x (m * Acg)' + I * w)'

again since this is a rigid body Vr = Vcg so we get

L' = (Vcg - Vcg) x (m * Vcg) + (cg - cg) x (m * Acg)' + I * w)'

first and secund term are zero, therefore for a rigid body.

L' = (I * w)' = external Torque.

again, this all rely on the proof that the motion of a rigid body, is represented by the linear and angular velocity of the center of mass.

let us now use the equation for a collection of rigid bodies.
the second assumption is that angular momentum is additive.
This is the angular momentum of the system is equal to the sum of the angular momentum of all bodies.

Lt = L(0) + L(1) + L(n) = sum (l(i))

The time derivative of Lt becomes:

Lt' = Torque on the cg = Icg * Bcg = sum [(r(i) - cg)' x (m(i) * V(i)) + (r(i) - cg) x (m(i) * V(i))' + (I(i) * w(i))']

Icg * Bcg = sum [(V(i) - Vcg) x (m(i) * V(i)) + (r(i) - cg) x (m(i) * A(i)) + (I(i) * B(i) + w(i) x (I(i) * w(i))]

now we can see that when it comes to an array of bodies. the term

(V(i) - Vcg) x (m(i) * V(i)) can be different than zero since (V(i) - Vcg) can be different that zero.
(r(i) - cg) x (m(i) * A(i)) can also be different that zero, since r(i) - cg is different that zero.

we also see that the are some emerging values coming out from the derivation.

if we re arrange the expression is such wat that the fix values are grouped together,
and that variable values are also grouped together, we get.

Icg * Bcg = sum [(V(i) - Vcg) x (m(i) * V(i)) + w(i) x (I(i) * w(i))] + sum [(r(i) - cg) x (m(i) * A(i)) + I(i) * B(i)]

if we call

T0 = sum [(V(i) - Vcg) x (m(i) * V(i)) + w(i) x (I(i) * w(i)]
T1 = sum [(r(i) - cg) x (m(i) * A(i)) + I(i) * B(i)]

we can see that T0 is part of the state, of the body, since is only depend of position, and velocities, so the can be precompute in the same loop that we compute the cg, Mt, Vcg.

for T1 = can see that the term
m(i) * A(i) = Fext(i) on each body
I(i) * B(i) = Text(i) on each body.

these values we can get form taking one step on the OK solver.

we still need to know who to compete Icg * Bcg

Bcg will be the virtual angular velocity of the Total body, and will be the same for the body who the Total inertia is calculated as

Icg = sum (I(i) + covarianMatrix(x(i) - cg) * m(i))

so we now arrive to the final equation.

Bcg = (Icg^-1) * (T0 + T1)

and now we apply the stability criteria, which is
the body is stable is

Bcg.x and Bcg.z ~= some small value.

so the final equation are.

Code: Select all

T0 = sum [(V(i) - Vcg) x (m(i) * V(i)) + w(i) x (I(i) * w(i)]
T1 = sum [(r(i) - cg) x Fext(i) + Text(i)]
Bcg = (Icg^-1) * (T0 + T1)


I will go over the equation again before start coding it. but I feel very good about this.

the physics interpretation of the equation is that the term T0
is an emerging torque, that enforces conservation of angular momentum for the collection of bodies.

so the method reduces to, we calculate the initial Bcg, and as long as the horizontal acceleration are no zero, we perform an action by manipulating any of the actuator's joints until acceleration decreases.

and here is whet the simple monocycle model become practical, it only have one actuator. so we can just move that actuator.

when it come to a more complex like a biped or a quadruped.
we can calculate the gradient of Bcg, to get a vector of displacements, that we can use to move the joints, but we will address that after we get the first monocycle test working.

anyway afte review, I am going toi start coding this over the weekend.

[Julio Jerez]

oh there is one simplification still, on the expression.

T0 = sum [(V(i) - Vcg) x (m(i) * V(i)) + w(i) x (I(i) * w(i)]

can be expanded as

T0 = sum [V(i) x (m(i) * V(i)) - Vcg x (m(i) * V(i)) + w(i) x (I(i) * w(i)]

but V(i) x V(i) is alway zero so we get

T0 = sum [w(i) x (I(i) * w(i)) - Vcg x (m(i) * V(i))]

and the final equation becomes

Code: Select all

T0 = sum [w(i) x (I(i) * w(i)) - Vcg x (m(i) * V(i))]
T1 = sum [(r(i) - cg) x Fext(i) + Text(i)]
Bcg = (Icg^-1) * (T0 + T1)

that seem to make lot of sense to me.
just like for a rigid bod with irregular inertia, the term w x (I x w) enforces conservation of angular momentum,

there seems to be an extra term Vcg x (m(i) * V(i)) for when the cg is offset form the center of mass
that also enforces angular momentum conservation.
and that fact that appear analogues to w x (I x w) simple because

Vcg x (m(i) * V(i)) is in fact the gyro torque of the point mass.
if the bodies was only a single object, the Vcg == V and the term will be zero.
for multiple connected bodies Vcg is now an average, so the tern is a compensation factor.
is a very good sign that this is the right track, I feel very hopeful about this.

so I think we are ready to try this out.