On Tuesday 30 November 2010, at 10.48.55, Darren Grant <dgrant <at> kerberos-productions.com> wrote:
> So I originally posted the following to the bulletphysics.org general
> discussion forum. But perhaps this mailing list is a better venue
> since the subject is related to what I imagine is basic flight sim
> development and steering behavior:
> >I am a programmer tasked with developing a newtonian simulation of
> >high performance spacecraft. For the sake of discussion, each craft
> >is a rigid body with non uniform moments that must navigate its
> >environment by applying only (central) forces and torques. Mass and
> >acceleration can vary by a couple orders of magnitude. Linear and
> >angular tracking are treated independently. The high order
> >parameters are: max speed, max angular speed, max torque scalar (may
> >be component-wise) and max force magnitude.
What is the purpose of restricting the simulation in terms of speed, angular speed etc? It would seem more natural (to me, at least) to restrict only the forces and torques, and have friction and drag take care of the rest.
In a game with relaxed demands on realism, you can probably get away with plain coefficients for friction and drag, but a simulator should probably have more realistic models.
> >Here's what I have now:
> >The linear tracking code is very simple and attempts to minimize the
> >difference between actual velocity and desired velocity using
> >kinematic knowledge of motion to produce the desired velocity at
> >each tick (accelerate to apogee, decelerate to target). This is
> >comfortable territory.
This method should translate just fine to angular tracking; position becomes angle, inertia becomes rotational inertia etc. I think you can, in most respects, handle rotation as another set of dimensions - so you have x, y, z, alpha, beta, gamma (or whatever you prefer to call them), and the respective derivates, inertias, coefficients etc for each one of those.
> >Angular tracking is significantly more bloated and follows the same
> >principals by trying to minimize local angular error component-wise.
> >There is some hand-waving of the coupling of large angular terms
> >that makes this even remotely acceptable. So it works alright if
> >there is an abundance of turning power, but the big problem is that
> >it is just a messy solution that I'm afraid might blow up in my face
Well, if there is supposed to be unlimited torque avaliable, you can basically just move the body where you want it, and then calculate torques, forces etc after the fact.
If not, there is just no way you can avoid the "do I turn left or right?" problem. And, the correct answer to that isn't obvious either. If you have rotational speed and inertia, the "nearest" direction in terms of angles is not necessarily the quickest solution; it might be faster to just keep turning in the direction you're going - but if that decision also affects your path of travel and final position, you have to consider that as well.
Loads of fun!
> >Is there a better way to approach the angular tracking problem or is
> >this just how it is done? I intend to start layering flight AI on
> >top of this simulation.
As I said, I'm not quite sure what you want to achieve, but if you actually want to *control* the bodies (as opposed to just moving them around and calculating the forces, torques etc that would be required in the real world), you're looking at a control engineering problem. However, compared to a real world system, a simulation has the massive advantage of having all data instantly available. The math can be hairy, but from a theoretical POV, all data you need is right there.
So, unless you're actually trying to design a control system that could be applied to real hardware, or need the realism and/or "feel" of actual control systems at work, there are a lot of shortcuts you can take, such as calculating exact corrective forces based on physics, rather than approximating it with a PID or similar - if you even need to do the calculations in the first place.
//David Olofson - Consultant, Developer, Artist, Open Source Advocate
.--- Games, examples, libraries, scripting, sound, music, graphics ---.
| http://consulting.olofson.net http://olofsonarcade.com |