Re: Aggressive tracking in a newtonian simulation

On Tuesday 30 November 2010, at 10.48.55, Darren Grant <dgrant@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
> >later.

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   |
'---------------------------------------------------------------------'

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com