.dll Question thruster control

[weiqi]

I have added six thrusters to six direction of a satellite, and all the force direction are in the body reference frame(left/right/forward/backward/up/down). Certainly I put the force action point at the center of the satellite.
However, when I make the forward thruster to push the satellite forward, it just circumrotate around! I want to know, if I want to push a satellite forward, what is the correct way I should go?
Thanks for your help!

 

[tblaxland]

Do you mean you have a forward thruster defined with an attack point of (0,0,0) and a direction of (0,0,1)? If so, I don't see any immediate problem. Maybe the issue is how you've defined your thruster groups?

 

[weiqi]

Hi,tblaxland:
Yes, I've defined the thruster as what you have said. I'm not sure whether there is any relationship between the thruster defination state and the staellite's inertia axes, because the satellite's attitude control system is related to the inertia axes.However, I don't know what the results which is created by the "shipedit.exe"(contained in the SDK/utils directory) means, because the "Inertia" keeps changing with the time. Is there any good way to solve this?

 

[tblaxland]

shipedit resolves the inertia by examining the mesh and improves its estimates with each iteration. If the values are changing by a lot, it means that you do not have a well behaved closed mesh. That in itself is not a problem, just that you need to resort to more archaic methods to calculate the inertia: .Often the values returned by shipedit are inaccurate because it assumes a homogeneous mass distribution throughout the volume, so you may get better results by manual calculation.

This is just speculation but if you have used very low values for the moments of inertia, rounding errors causing the thrust to be slightly of axis may cause your ship to spin.

 

[weiqi]

Thanks a lot! I have learned the mechanism of shipedit through what you have said.

 

[ex-orbinaut]

Thruster control is one of the most entertaining and versatile aspects of OAPI over SC3, I find. I admit that I am still pretty new to OAPI, but have got my head around this with no real problem. You don't need to 0,0,0 your engines, really. You can put the source of thrust where your nozzles really are on the ship, and if they are not CG centered, you can change the Y / Z angle of the thrust to compensate any unwanted moment pitch tendency. The important thing is that the vector be an angularly correct for both axes (it's a 3D matrix, in essence). For example, 10º angle would be

For Z axis Cos(10º) and for Y axis Sin(10º). Your thrust vector then looks like;

(0, 0.17365, 0.98481)

..and you have the satisfaction of knowing your model is as realistic as possible. You can even "animate" the thrust vector, and link it to keys, so that you can implement a "thrust trim" system, in case you are carrying assymetric payloads. The required off center thrust moment can be calculated with relative ease, it is simply the engineering Torque formula.

It is also helpful for implementing mixed thrust types in your main engine group.

Look at the engines section of the API Programmers Guide that came with Orbiter for more info.