Aggressive tracking in a newtonian simulation

[Darren Grant]

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

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.
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.
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.
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.
(If there are flight sim devs out there in the crowd, what can I
say, I would really appreciate your advice!)
:)

Cheers,
Darren

[David Olofson]

Post by Darren Grant
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

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.

Post by Darren Grant

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.

Post by Darren Grant

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! ;-)

Post by Darren Grant

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.

[Darren Grant]

On Tuesday 30 November 2010, at 10.48.55, Darren Grant
...

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.

The max speeds are aspects that the designers would like to dictate
directly. Realism is not a primary goal, so the simulation can have
relaxed demands. It also takes place in the vacuum of space, so
strictly speaking friction and drag aren't expected.

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! ;-)

Oh yes. :)

The smallest ships tend to have unlimited torque but the larger are
limited for their mass. Although I am naively minimizing -pi..pi on
each rotational axis, I haven't seen a case where a ship gets caught
in an endless spin cycle. Now that you mention it I'm going to try
instigating the scenario.

An odd issue comes from treating significant local errors by
component. If there are large errors on multiple axes in a low torque
to mass configuration, control feedback will sometimes plan a
trajectory that causes the craft to spiral in to the solution. I'm
not sure whether this is an implementation bug, or evidence of the
dismissed angular coupling.

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.

It is definitely a control engineering problem then, but the game
doesn't require the feel of actual control systems. The motivation is
to allow ships to interact believably with external forces and
impulses since this is a key part of the tactics that can be employed.

The next big question is going to be which steering behaviors to
incorporate as parameters in the control system, and which to
generate from piecewise paths. Picking up the engineering ball, I
think a trajectory sampling API will help answer some questions. :)



Cheers,
Darren

[Will Vale]

Hi Darren,

On Tue, 30 Nov 2010 22:48:55 +1300, Darren Grant

I am a programmer tasked with developing a newtonian simulation of
high performance spacecraft.

For I-War 2, we had what sounds like a similar setup of rigid bodies and
requirements. We used a very simple follower for each (local space)
angular velocity component, basically the same as the linear velocity
component. I just looked up the code and it was something like:

for each component i:
dv[i] = target[i] * max_speed[i] - current[i]
torque[i] = clamp_to_max_torque( dv[i] * moment[i] / dt )

(moment is the diagonal of the MoI matrix - all our stuff was in this form)

Pretty horrible stuff - especially dividing by dt - but it worked OK in
practice. We didn't allow ridiculous speeds or torques. Our integrator was
straight Euler, and while I thought it had some bespoke stuff in to stop
it hunting or blowing up, I looked and couldn't find it. I'm sure I
remember playing with this at some point, but maybe we ended up
constraining the inputs such that it would remain stable.

For the NPC ships, our AI coder (Brett Laming) drove the same simulation
by setting max angular/linear speeds. He went into more kinematic depth to
figure out what inputs to use so that a ship would arrive at a particular
place at a particular time (acceleration, coasting, braking). I suspect
these days both of us might consider a less pure approach whereby the AI
can get at the simulation at a lower level than the pilot interface so we
wouldn't have to second-guess it so much.

Heh. While looking for this, I found the marvellously-named
iiSim::DetachAndFlingChild. As a parent, I have to say I disapprove!

HTH,

Will

[Darren Grant]

Post by Will Vale
Hi Darren,
On Tue, 30 Nov 2010 22:48:55 +1300, Darren Grant

I am a programmer tasked with developing a newtonian simulation of
high performance spacecraft.

For I-War 2, we had what sounds like a similar setup of rigid bodies and
requirements. We used a very simple follower for each (local space)
angular velocity component, basically the same as the linear velocity
dv[i] = target[i] * max_speed[i] - current[i]
torque[i] = clamp_to_max_torque( dv[i] * moment[i] / dt )
(moment is the diagonal of the MoI matrix - all our stuff was in this form)
Pretty horrible stuff - especially dividing by dt - but it worked OK in
practice. We didn't allow ridiculous speeds or torques. Our integrator was
straight Euler, and while I thought it had some bespoke stuff in to stop
it hunting or blowing up, I looked and couldn't find it. I'm sure I
remember playing with this at some point, but maybe we ended up
constraining the inputs such that it would remain stable.

This sounds a lot like what I rolled for Sots Prime. This time around
we're working with Bullet on advice from a coworker. It is much more
robust. For example, one tricky bit of business was conveying near
inertia-less motion in a dynamic simulation. Kinematic sounds like
the right answer, but then you're stuck implementing all of the
remaining dynamic responses by hand. With Bullet I can evidently use
extreme forces to fake the effect without the huge instabilities that
were a problem before.

Post by Will Vale
For the NPC ships, our AI coder (Brett Laming) drove the same simulation
by setting max angular/linear speeds. He went into more kinematic depth to
figure out what inputs to use so that a ship would arrive at a particular
place at a particular time (acceleration, coasting, braking). I suspect
these days both of us might consider a less pure approach whereby the AI
can get at the simulation at a lower level than the pilot interface so we
wouldn't have to second-guess it so much.

It's deceptive. Simple steering behaviors are nice neat packages, but
it is a whole other story combining these into a smart and
interesting control system. I still really want to stitch paths
together from simple goals using an expert planner, but producing
achievable paths is always going to be a problem. Abundance of force
helps, and I hope that a kinematic API will be useful for testing
concrete options.

I wonder how ATC engineers stay sane. ;)

Post by Will Vale
Heh. While looking for this, I found the marvellously-named
iiSim::DetachAndFlingChild. As a parent, I have to say I disapprove!

That is pretty horrifying. Remember, premature optimization is evil.
Spending a lot of CPU cycles on enumerating children is a good thing. :)


Cheers,
Darren

[Jon Watte]

First: You want to use R-K-4 for your integrators, if at all possible. That
will make "springy" behavior from the errors of a first-order (forward or
backward) integrator go away.

Second: From doing this before, I think you should treat this system as a
PID controller, although you probably can keep the I term zero. Use P for
the "gas" thrust/torque, and D for the "brake" thrust/torque. Given that the
available thrust/torque for navigation thrusters are generally tiny compared
to the mass of the spacecraft, you have to use pretty large look-ahead for
the D part.

If you tune the system carefully, you can even get it to the point where the
relation between error, velocity/spin, and forces becomes a critically
dampened system, which means it will be "optimal" in some sense in obtaining
the desired kinetic pose. (Google "critically dampened mechanics" or
something like that for the math)

Sincerely,

jw


--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world. Nevertheless,
whether we get there willingly or not, we shall soon have lower consumption
rates, because our present rates are unsustainable.



On Tue, Nov 30, 2010 at 1:48 AM, Darren Grant <

Post by Darren Grant
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
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.
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.
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.
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.
(If there are flight sim devs out there in the crowd, what can I say, I
would really appreciate your advice!) [image: :)]
Cheers,
Darren
_______________________________________________
Sweng-Gamedev mailing list
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com