CIO in ND

[blackbird_dream]

A very efficient way of computing optimal control for robots or humanoids is CIO (contact invariant optimization). It requires at each time step the knowledge of the Eq of motion in generalized coordinates :
M(q)q'' + C(q,q')= F_contact + F_motor
M inertia matrix, C Coriolis, centrifugal and graviational terms
also the jacobian mapping generalized coords to end effector locations
Is such an approach feasible in ND?
Thks

[JoeJ]

A very nice paper which i did not knew about. I see they generate very smooth and plausible procedural animation.
If i get it right, the proposed algorithm solves for trajectories to get form one pose to another, so it's more about planning motion in advance than actual simulation.
The simulation would then try to follow the predicted trajectories.

Is such an approach feasible in ND?

From my experience i'm sure it is.
In the paper they used a very simple model of physics, e.g. approximating the body with a single point mass on the pelvis, iirc.
This will be a problem. The assumptions made will not hold for the accurate simulation, and the body will loose balance and fall down in some (but more likely many) cases.
You could address this either by making the physics model in the motion planning more detailed, or by compensating the errors in a smarter simulation (which may require to restart the planning if the physics diverge too much from the plan).
I guess you have to do both.

Julios work on the self balancing ragdoll feature would be such smart controller i guess. So if you can implement the paper, it would be interesting to see what you get from using it.
It's also a example for my main concern about the idea, because by having control only about end effectors of the skeleton, it might be difficult to make the simulation follow the planning results closely.

Another option (which i was using til yet) is to make the physics skeleton match the planning animation using joint motors. This works very well in terms of accuracy and robustness.
But then you are on your own with error compensation to maintain balance.
It's quite a hard control problem. The planning already tries to care about it, but i'm sure some detailed adjustments are always necessary.
Ofc. the easy option would be to do those adjustments with external force, which for games is a valid option.

[blackbird_dream]

It's not planning i'ts just finding the optimal solution to minimize cost functions related to balance control.
The simplifications made i.e point mass bodies are not severe approximations, it's not a problem to add inertia.
The difficulty there is to hold the Newton's law in a non conventional way, I mean consider the contact forces as input and not output variables. It requires having access to all members of the equation as mentioned in my msg, that was the meaning of my question.
see

Robust balance optimization control of humanoid robots with multiple non coplanar grasps and frictional contacts

for details, on which CIO was based.

[JoeJ]

I mean consider the contact forces as input and not output variables. It requires having access to all members of the equation as mentioned in my msg, that was the meaning of my question.

Contact forces can be obtained form the Newton simulation.
Not sure about motor forces. Iirc, when i worked on this i only got an approximation of that, something like an initial guess. Recently there was related discussion on adding this as a new feature, and maybe it's already possible.

It's not planning i'ts just finding the optimal solution to minimize cost functions related to balance control.

As far is i understood it, it calculates trajectories to get to a target, and it also calculates intermediate steps like putting hands at some place on the ground for support to get up. It does this without any given examples like poses or captured motion. That's what i meant with 'planning'. Input is just pose of a character flat on the floor, and a target upright position. All internal motion is calcualted by the algorithm.
To use it for controlling a simulation, the algorithm plans ahead for some time to get to the target, and then you can 'play back' the trajectories on the simulated robot.
The simulation however will diverge from the plan, no matter how accurately the planning model tries to match the simulated model.
To compensate for this, i expect you'll have to run the planning algorithm again every frame using the current state of the simulation.
I don't expect getting this state or converting it into generalized coordinates would be a problem.
Basically i do the same when converting the complex ragdoll into a simplified inverted pendulum, although my case is surely simpler as i need no contact or joint forces to consider, just momentum and mass properties.

The problems i do expect are: Eventually the planning of complex motion each frame is too slow to keep up with realtime. And eventually simulation diverges too strongly from the plan, so the algorithm is not smart enough to adapt to simulated reality. But i would be very optimistic.

[Julio Jerez]

I made a long post, and when submitted, I wasn't logged in them after logging, the posted got cleaned up.
I will try to put my thought over the weekend, but I think there is a confusion here.
I will state the summary of my thoughts now, them go over the point I believe are kind of a condition of mixing things.

Equation
M(q)q'' + C(q,q')= F_contact + F_motor

is a reduced coordinate system model for rigid bodies. probably derived from a special case of
Lagrangian, Legendre, Hamilton or D' Lamber.

So I enter the equation in google and Got this paper.
https://scaron.info/robotics/equations-of-motion.html

It seems it is a D' Lamber method, although not stated clear.
I am or I was very familiar with D'Alembert methods, I used them way back in the late 80's in college for solving vibrations of static structures. steel cages, towers, that sort of things.

Going on the assumption that it is a generalized coordinates system method, the things to know is that there are some pros and const with generalized vs reduced coordinates systems.

but I will say that, the const of generalized coordinate systems far outweigh the benefits.
The reason is that the problem with generalized coordinate system are unsolvable.
the people who use them, always, end up with ad hoc iterative solutions.

one such problem is lost of Holonomicity, that is, the model assumes that the number of coordinates are independent, that is the number of equations representing a coordinate, are linearly independent, therefore the acceleration will be equal to the number of coordinates (DOF).
however, that is not the case, not even with the most trivial systems, like a ball socket.
we all know that a ball socket will has orientations where one of the one of the three dof will be lost.
so you end up with two coordinates since one will be a linear function of the other.
but, they are many more cases for example, kinematic loop.

now these problems are not unique to generalized coordinate methods, when but the solution using generalized methods does not have known direct linear system, even when you solve the Convex problem I will just be an approximation. reason been that the system is not linear.

that's not the case when using reduces methods, reduced system always decompose the problem into a set of free bodies, each with 6 dof.

them the method for constraint forces always yield a linear system that provide the unknown forces. But in this case now when using convex quadratic solver, there are linear algebra method to exclude variables that make the matrix I'll conditioned.
And since the system is linear, it does not matter what did is excluded, the other will make up.


Reduce method do have the severe problem of drifting,
however, the problem of drifting although is not solvable, can be made arbitrarily small at the expense of computer power, that is not the case with generalize methods.
there are other hard problems still, but that one is a big show stopper.

here is the Newton 4 answer to the problem.
Generalized coordinate system are attractive to students and researcher because they promise that by running the system you can always get the kinematic state of each DOF.
that is, knowing position of the state vector. you can run the system and get the velocity and acceleration.
Then you make decisions as to what forces, motors to apply to the free dofs.

In newton 4 I introduce the dModel and IkSolver objects.

this dModel is an object that let the application group a series of bodies, joints, and other things together an they get thier own simulation updates.

the order if

-collision update
-dModel update
-Constraimt solver update
-dModel post update
-Integration

with this, an application can configured an articulated robot,
and add an ikSolver.

in the update the application can Get the exact same answer that it would get if this was formulatef as a reduced system. In fact it can get far more than that, because it handle loops, and lost of DOF graciously.

but the app can also try iterative solutions for highly non linear system. and example is an articulated vehicle tire model, using a brush friction model.

anyway I will probably say more later.
but the answer is that since both generalize and reduced coordinate system are equivalent,
yes, in newton 4 we added the dModel as an answer to generalized systems.

[Dave Gravel]

Regarding the blackbird_dream question and Newton 4, currently blackbird_dream is restricted to using Newton 3.14. Newton 4 is not yet ready to be used with Pascal. While waiting for a Pascal solution for Newton 4, can blackbird_dream replace ndModel and use the listener in the same way ?
And I don't remember if Newton 3.14 has an equivalent tool to the ikSolver.

[Julio Jerez]

Yes I am aware of that pascal port yes. I haven't try yet.
I am not sure if the auto conversion is reliable, when I read what people who has use though about I God a mix bag of opinions. The manual conversion is a big job.

Anyway, on the model object. it is not that object. It is what can be done with it.

For the generalized cordinates equation poste by blackbear, it is conceivable to even implement that equation all together.
Another option would be the adding a Featherstone algorithm.
The newton solution is the IkSolver which does not exist in newton 3.

The option of converting the ik silver back to 3.14 is not really so trivial, because for newton 4 the convex quadratic solver has been improved to handle zero joint rows, as well as singular rows.

I am not particular fund of Featherstone, because it is in fact quite limited.

During this week I will make a series of post of simple example, an solve it by the tree different methods.
-Classic free body diagram.
-generaliex coordinate, maybe dlamber
-reduced method, the engine

Hopefully this will show why the Reduce method, for ridid bodies are actually better that the other method, simply because generalized methods are special cases that meak asumptions, and this asumptions can be easily broken during a simulation.

The I will show how the I k solver is equivalent to a generalized methods, for people who work on solution to problems where they need a generalized cordinates solver.

[Dave Gravel]

Yes, it's a big job to completely redo the DLL interface by hand. And if it's an automatic solution, it would be good if it could be updated when changes are made to the library.

Newton 4 in C++ is really good because you can create your own classes based on those that already exist and modify certain features of the class. In Pascal, you have to use what already exists and what is shared by the DLL interface.

I had already started to make a DLL interface, but to be honest, I got a little discouraged because over time, I started to prefer Visual Studio C++. The beginning of my interface was functional but very limited, because I only had the world creation and a few basic features, but it worked well.

So for Pascal, I see two solutions. Either the DLL interface shares all the internal tools of Newton. And in this way, the user can create their own custom classes from the interface in Pascal. But in this case, the DLL interface would be really huge and complicated to maintain unless you have a very good automation tool for the interface.

Or the other solution is to only make an interface for the existing tool classes without any more. With the latter solution, the user is limited to only using the active classes of the Newton engine. This is similar to a wrapper like the one for Unity, where the user can only use what is shared by the interface, but cannot modify the classes from that interface. Or the user need to apply the changes in the c++ code.

The latter solution reminds me a little of the old version of Newton, where we had to use the vehicle already made in the DLL but we couldn't modify its code. I no longer use Pascal for my 3D demos, but if you need help trying and preparing an interface, I am available to help and try. In my backups, I have some quick 3D code solutions to try and test the Pascal DLL interface.

Anyway, on the model object. it is not that object. It is what can be done with it.

Yes, I see.

The newton solution is the IkSolver which does not exist in newton 3.

Ok.

[JernejL]

Even if an automated (swig?) C dll export interface is made, it can be converted to multiple languages that can interface with raw C api easily, i have a pascal converter and can modify it to work on newton 4 header when it's made, it could also generate headers for other languages such as python.

[blackbird_dream]

Difficult now cos there are 2 topics in one discussion.
About CIO, the trajectory is not planned beforehand for gait. The steps (and the related virtual reaction forces) are set as variables. They are optimized so that at the end it gives the full traj. You can see in the videos that depending on optimization choices, it leads to diverse trajs.
In the 2nd paper, yes some hand grip positions are set but this paper ref was just given to illustrate how unilateral contact forces may be processed as optimization variables and not just output results of the physics engine.

PS : Thks Dave. Yes I am still interested in the v4 for delphi. Thks also Jernejl for your offer of support.

[Dave Gravel]

I'm sorry for polluting the discussion with another topic. The idea was not to introduce a new topic. I just wanted to respond to Julio's solution regarding "here is the Newton 4 answer to the problem." and "In newton 4 I introduce the dModel and IkSolver objects." I wanted to know if it would be possible to reproduce this solution in Newton 3.14 because it might take some time before you can use Newton 4. I apologize again for mixing up the discussion.

[blackbird_dream]

no troubles