Re: Aggressive tracking in a newtonian simulation

At 05:00 AM 11/30/2010, David Olofson wrote:

>On Tuesday 30 November 2010, at 10.48.55, Darren Grant 
><[email protected]> wrote:
>...
> > >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.


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


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

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