Decimating physics data At work we run a physics simulator (video game) that operates in an inner loop at 360 Hz.  Data from that inner loop is collected 60 times a second and sent out to hardware (a force feedback steering wheel) in order for playback to the user.

I have two questions on this system.  

First what is the best way to decimate the 360 Hz data down to 60 Hz.  Right now we do a straight average of 6 samples together, but I suspect that this is causing some aliasing of the data and we are very sensitive to high frequency noise.  We are also extremely sensitive to latency and even adding in 4 samples of latency (in the 60 Hz loop) would cause a noticeable delay between the onscreen display and the force feedback device that the users would pick up on.

Second, the hardware (steering wheels) is typically made to very poor tolerances and usually has a difficult time playing back data above about 20 Hz before the signal significantly degrades.  Would it be better to low pass filter the 360 Hz data down to 20 Hz, or to low pass the 60 Hz data to 20 Hz, and what would be the most efficient way to handle this.  

I currently have a single pole IIR filter that you can optionally define on the 60 Hz signal, this does smooth the data out, and adds in a considerable amount of latency as well.  Mixing less than 0.20 of the current sample causes an odd disconnected feeling in the wheel so that is my lower bound.  I would assume that going to a more complex filter would give me a much faster falloff and would both smooth out the high frequency chatter and noise in the wheel without increasing the latency beyond 4 samples (66 ms)

I'm half way through Steven W. Smiths book "The Scientists and Engineer's Guide to Digital Signal Processing" so I have a limited understanding of DSP's.  I do have 20+ years of programming experience in 2D image manipulation so I have been using dsp's all along without knowing what they were.  The point is go easy on my poor mind :)

I should also point out that the 60 Hz loop is running in 'real time' that is timed to the pc clock, and all communication with the wheel is also in real time, however the inner loop is processed 60 times a second and there is no way to get access to the inner loop data at a faster rate than 60 Hz.
This is a really very nice applied signal processing question. Unfortunately your lack of DSP and physics expertise, builds some barriers on the way of your understanding. Hopefully this answer helps to tunnel through.

Now, your first question is about downsampling a discrete time signal. In fact there are already plenty of such questions here under the title of interpolators, downsampling etc. These are already answered with great detail. You better make a search on the site for more detailed answers but here once more I'll give a brief reply. 

In downsampling a discrete-time signal (say from 360 hz to 60 hz in your case, by a facttor 6) the most critical thing to consider is the Spectral Utilisation of the original (360 Hz) signal. Based on Shannon-Nyquist sampling theorem criteria, this signal is assumed to contain meaningful (non-trivial) information in the band of frequencies 0 to 180 hz. However for many applications the frequency band of interest within the say 0-180 hz range will be a much smaller band, say for example from 0-20 hz. In such a case, the original signal is said to be "oversampled" (by a factor of 9 in this case). When a signal is oversampled by a factor of say M, then it is somewhat acceptable to discard every (M-1) samples and use the Mth one to represent the information content of the original signal without loss (except at the higher end of the band which gets to limit of aliasing). But this will/may produce some noise due to aliasing being on the very edge of it. 

There won't be any aliasing, as long as the out-of-interest frequency band in the original signal contains no energy. In order to guarantee this condition of zero energy in the out of interest band, it is required to filter out those out of interest bands by a suitable filter of sufficient quality, before decimating the signal. 

The quality of such a filter depends on, therefore, i-the spectral distribution of the original signal, ii-band of interest, iii-downsampling factor and other requirements such as real time processing or offline, accuracy, CPU power etc.

In your case, the answer lies in the following: the best downsampler should produce the most accurate representation of the band of interest signals and reject any irrelevant information for your steering hardware to process.

The short answer is this: as long as your system is configured to use 60 hz information (30 hz band) for the force-feedback processing, it seems that (and from my experience with mechanical acceleration signals, it is indeed so) this band of signals is adequate to represent average mechanical control. (as long as I can remember, most mechanical acceleration sensors do use at most a band of a few hundred hz). So just use a simple low-pass filter of cutoff frequency at pi/6 for better performance.

The second questions simply asks which is better to choose i-filtering 360hz into 20hz or ii-60 hz into 20 hz. The answer is the latter. It will be a much shorter filter to apply, and the transition band would also be easier.

When the latency of a few samples becomes so critical as in your example of real time forced-feedback control of a physical simulator, then high accuracy filters becomes impractical to use. May be you should completely discard using any filters at all, as you have pointed out the physical limitations of the wheel mechanics already prevents bulding of responses faster than 20 hz...