Gimbal Lock and Euler angles

[JoeJ]

Yes, on opposite thrusters forces cancel out each other and only torque remains, we all agree on that.

Maybe there is confusion because control problem and rendering problem are mixed in the same thread, i don't see any relation between them.

Is it possible for you to write the force and torque callback you were mentioning? I am still working on the proper rotation order for my space simulator, and I just want to make sure I am not observing any undesirable effects from applying torques on principal local axis.

This indicates you want a better control now just to help solving the render problem?
That's just anather layer of indirection again - you MUST solve the problem at it's root. Now. Control comes after that.
Controlling a body with forces (or torques) will make it rotate around drifting axis,
controlling with velocity is better but the same problem.
Setting it's orientation matrix directly is what you want - you have full control over any axis of rotation.
To do this, you would calculate its orienation with euler to matrix code like i gave, use the same eulers for the renderer and try all options until they match. I than can create the reverse transform for you.

If you wan't to remove another layer of indirection, you could work without any physics body at all and use the just the orientation matrix alone.
At this point we would be exactly at the code i gave before

You say you 'struggle' with it, but that's too less information to help further.

[misho]

Well, I agree with you, except, it seems Julio doesn't He mentioned in his latest reply that by using torques on axis the way I do right now, I will be getting some unexpected and undesired residual rotations. And if I am getting that, all my efforts in trying to establish the proper steps in rotation conversion will be "tainted", because I'll be trying to fix something that might not be working for a reason that's different than the one I'm thinking.

All I'm asking him is to help me put in place an "offset force" procedure that's not introducing any undesired residual rotations. Does that make sense?

[Julio Jerez]

remind me this Saturday I will write you a force and torque call back that you only need to pass and array of forces and the points of action.

you need to also decide how are you going to damp the velocity. like I say before. control a space ship in real space is a real tough problem if you want realism, reason being that in space they is no drag, so the thruster has to be constantly making adjustment correction in order to fake a conservative torque.

satellite get a way because stately can use real inertial damper using Giros. I have idea how the space station does it. but is is a incredible complex calculation.
are you going for the realistic simulation of are you willing to cheat by adding angular velocity base drag.

[misho]

Sounds good, Julio... I will remind you on Saturday!

As for damping velocity, are you talking about rotational velocity (omega)? Because right now, as I apply torque, my spacecraft keeps rotating with very small omegas, it never stops. The omegas are not being damped... and that's how I want it. I do this by using NewtonBodySetAngularDamping to set it to 0.

Is that a problem? That's what I'd expect from objects in space, they keep spinning since there is no friction.

Misho

[JoeJ]

All I'm asking him is to help me put in place an "offset force" procedure that's not introducing any undesired residual rotations. Does that make sense?

If my impression is right, you want something that let's you spin a body around it's x axis for some degrees, than stop spinning, than spin around y axis for example.
And you want this to ease debugging the render problem.

I can follow that thought but it makes little sense to do it with torques and only complicates a problem that is unrelated to physics. (I don't wanna sound rude, just trying to prevent seeking the reasons for the render problem at the wrong place.)

[misho]

No, that's not it at all. All I want is a way to exert a force on a rigid body at any point - not just body's centre of gravity. And I want/need this because it is a proper way to model Reaction Control System (RCS) on spacecraft. RCS thrusters are placed on various positions on spacecraft, so that when they fire in various combinations, they change spacecraft attitude. If you take a look at the picture of an Apollo command module, you will see small 4-way thrusters placed around its body circumference. When they fire in different combinations, they can change attitude in all 3 axis.

This (and all other forces in action) needs to be done on a newton body. The "sim" (render visual) object's attitude will then be aligned to newton body.

No worries about sounding rude, I value constructive criticism above all else. I just hope I am explaining myself correctly. There are several problems I'm dealing with here:

1. Trying to get Newton body to behave properly. I thought I had it by applying torques on its principal axis, but Julio is saying that's not a proper way to go about it.
2. Then, keeping in mind that Newton is right handed and my sim is left handed coordinate system, getting the sim visual object to properly align to what the Newton body is doing, attitude wise. That's what the debug objects are for, since they show me what a newton body is doing. Thanks for that tip, that is very helpful!
3. Finally - getting the right ECEF to NED conversion going.

I implemented #2 using torques on local body principal axis (I could observe that it is aligning correctly by observing debug spheres. Currently, I was (with your help) on step #2. If you remember, I was performing tests above north pole because that's where the Newton and Sim coordinate frames align. I know that because sim visual (spacecraft) and newton body (in their default state with RPY all at 0) are aligned. Now, Julio advised me that step #1 (applying torques on body's local axis) is not the correct way to do this - that's why I need to go back to step 1 and fix things with a method that he offered to implement. I hope that makes sense. Otherwise, please let me know if my logic is flawed. Also, I can draw more diagrams. I love drawing diagrams

Misho

[misho]

Consequently, as a way of applying pure forces to a Newton body, I was toying with the idea of attaching smaller Newton "child" bodies on a "parent" body with rigid hinge (CustomHinge with all limits set to 0) and then applying pure forces to "child" bodies. That would achieve the same effect of rotating the main body without actually explicitly applying torque on it, but letting internal solver rotate the main body.

This would actually be the closest to modelling actual spacecraft, since they do have small thruster clusters attached to their fuselage. I just thought that seems to be an overkill, there must be a more elegant solution.

[JoeJ]

Consequently, as a way of applying pure forces to a Newton body, I was toying with the idea of attaching smaller Newton "child" bodies on a "parent" body with rigid hinge (CustomHinge with all limits set to 0) and then applying pure forces to "child" bodies. That would achieve the same effect of rotating the main body without actually explicitly applying torque on it, but letting internal solver rotate the main body.

Using a second body would cause the same torque on the main body, using the simple force / torque pair method is accurate, faster and more robust than a rigid joint (which is difficult to solve).

Resulting torques are correct and there is no need trying to avoid them.
The only 'special' case here is, if you only want the body to rotate, you can just use torques to simplify this assuming real life thruster forces would cancel each other out.

To model a number of thrusters at known positions, summing up their forces and torques is correct and as easy as it seems. The hard thing is only to calculate the forces the thrusters should use to control the space ship.

[Sweenie]

The hard thing is only to calculate the forces the thrusters should use to control the space ship.

You are talking about a PID controller right?

[JoeJ]

Don't know, depends on the problem, but i would start by getting analytical equations of motion under earth gravity for a object with initial velocity to predict it's trajectory. I assume that's not so easy.

[misho]

Don't know, depends on the problem, but i would start by getting analytical equations of motion under earth gravity for a object with initial velocity to predict it's trajectory. I assume that's not so easy.

It actually IS fairly easy. I'm not sure if I follow, but that's what the physics engine is for - to make a solution for you. Once you set up the "scene", the bodies will behave close to the way they behave in the real world (depends on the sophistication of the physics engine). In my case, I have a body that orbits Earth. I tested trajectory and it is behaving as it should. To set up my "scene", I have:

1. Created a gravity field that points to the centre of coordinate system (Earth centre) no matter where the object is.
   
2. Given the object an initial velocity which is a velocity needed for stable circular orbit at a given altitude.

No need to program any equations of motion... the physics engine is doing it for you. With this setup, I can slow down the body, which then falls down (re-enters atmosphere), or speed up the body, which then goes into elliptical orbit, or, given enough speed, can completely escape earth gravity ("escape velocity"). Actually, The physics engine is so precise (after Julio implemented double precision) that, if I have 2 separate objects in orbit right next to each other, the minute difference in their positions create slightly different orbits, which can be observed by very small relative speed between the two objects.

[misho]

Using a second body would cause the same torque on the main body, using the simple force / torque pair method is accurate, faster and more robust than a rigid joint (which is difficult to solve).

Yes, BUT, the torque would be applied implicitly (within the solver) and not explicitly, which is what Julio is telling me - not to apply torque explicitly on the body - only forces.

The hard thing is only to calculate the forces the thrusters should use to control the space ship.

Probably not as hard as one may think. Spacecraft specs are widely available on line. In order to precisely simulate the behaviour of a specific spacecraft, one can design a rigid body with the same mass as in the specs, and apply same forces as given in the specs. For example, an Apollo Command Service Module (CSM) has full tech specifications available on wiki:

(From Wiki)
Mass: 12,250 lb (5,560 kg)
RCS: twelve 93 lbf (410 N) thrusters, firing in pairs

So, creating the body with a mass of 5560 kg, and using RCS thrusters that apply a force of 410N should give Newton enough info to accurately simulate the real-life Apollo CSM. What I'm trying to say is, NASA engineers already calculated these values Of course, if you are modelling a "science fiction" spacecraft, then yes, a bit of trial and error will be needed.

Misho

[JoeJ]

No need to program any equations of motion... the physics engine is doing it for you.

The physics engine does this accurate enough only for a very small timestep, what i mean is that planning efficient motion is hard. E. g. for a journey to mars you would need to account for (at least) two planets moving on nonlinear trajectory, they both affect the spaceship with gravity and it's very hard to calculate the best start time and trajectory for the spaceship to use as less fuel as possible.
That's what i mean with control problem (don't know what Julio has in mind).
Giving a gamer a joystick and let him control the thrusters directly is no problem at all. It depends on what you want to simulate, real life space travel or action fun.

Yes, BUT, the torque would be applied implicitly (within the solver) and not explicitly, which is what Julio is telling me - not to apply torque explicitly on the body - only forces.

Sounds like a misunderstanding.
Julio does not like to apply torques because he might miss the real reason that caused that torque (which is a thruster in our case).
He also says troques do not exist in reality and they are just a mathematical model to describe something that is caused by mechanic external forces and hold together by atomic internal forces.
... that's just my personal non-expert interpretation - correct my if i get this wrong, but that's at the edge of philosophy and does not really matter here, because finally he would apply the resulting torque from an external force as suggested.

I don't get what you mean with implicitly / explicitly, but i guess we would end up talking about neglectable numerical errors.

That's my final word's on control problem - i'm just the 'fix the euler angles problem, otherwise anything else is pointless' guy

[misho]

...what i mean is that planning efficient motion is hard. E. g. for a journey to mars you would need to account for (at least) two planets moving on nonlinear trajectory...

Oh yes, you are absolutely correct there, sir! That's quite literally rocket science! Luckily, there IS theory out there that can be coded into algorithm, and I intend to start working on that as soon as I put the "basics" together!

I don't get what you mean with implicitly / explicitly, but i guess we would end up talking about neglectable numerical errors.

All I mean by "explicit" is that the torque would not be applied in an explicit (user-issued) command (i.e. NewtonBodyAddTorque) but somewhere within the solver (internal workings of the physics engine) This COULD be achieved with the parent/child setup - I could just push the child with a simple force vector, and let solver worry how it is going to rotate the parent. Who knows, maybe Julio will implement some kind of a similar, but "phantom" child body attached to parent and let me apply force to it. He wrote the engine... I trust he knows the inner workings of it

That's my final word's on control problem - i'm just the 'fix the euler angles problem, otherwise anything else is pointless' guy

By all means! I can't wait to test your latest code, but I'll first wait and see what Julio comes up with.

[JoeJ]

All I mean by "explicit" is that the torque would not be applied in an explicit (user-issued) command (i.e. NewtonBodyAddTorque) but somewhere within the solver (internal workings of the physics engine) This COULD be achieved with the parent/child setup

That's a wrong assumption. The gain you expect will be more than compensated by the joint itself, because a rigid joint is hard to solve and may even jitter. The result will be much worse than using force / torque callback.
Actually space flight is a very simple problem for a physics engine. There is no complex interaction of joints to solve, like e.g. a stack of boxes. In practice you use only the integration step - the solver has nothing to do.
And the integration is very accurate and handles the limitation coming from discrete timesteps with runge-kutta.
To get the gain you expect you could simply use smaller timesteps to see if there's a difference.

By all means! I can't wait to test your latest code, but I'll first wait and see what Julio comes up with.

That's not fair. Julio makes control algorithm, but you fail to fix euler problem and have to give up - all time spend on control algorithm is lost.
Whatever Julio will create - it will not help you to fix the euler problem.