# Using DFT to determine control system bandwidth from user input

I am currently working on a race car project where steering and braking is to be done by a fully electronic x-by-wire system. To roughly determine the minimum bandwidth of the controllers, I took user + car data from an existing race car. I though I would do an FFT of the input signals to see what the 'user' bandwidth is, and let the controller sample time be at least 10 times this value.

As an example, this is what I did with the steering input:

1. I took the sampled time-series of the steering wheel angle, s(t), for 2 laps, and removed the mean value from the series.
2. I determined |s(t)|^2 to obtain a power-like quantity from the user input
3. An FFT was performed on the signal from step 2, and the bandwidth of this signal was determined. At first I was going to determine the half power bandwidth, but I quickly noticed the spectral components above 2 Hz were negligible so I took this as the 'user signal bandwidth'
4. From step 3, the min sample frequency for the steering input is 20 Hz as rule of thumb.

My questions are:

• was I correct in thinking that an FFT of the input signal represents how much input 'energy' is present at each frequency in the FFT?
• does step 2 makes sense or should I skip it?
• Am I correct in thinking the system will steer nicely if I sample the input signal at at least the frequency from step 4?
• My grad prof asked me 'so an FFT of the steering input, what am I seeing here? What does this graph actually mean? Is the driver actually turning the wheel at 1/3 Hz, what have you plotted?' and I had no idea how to clearly answer this question. Any thoughts?

I am new to this forum so hope my questions are clear enough for you guys.

Thanks in advance for helping me out!

Your basic approach seems correct! However, step 2 is not a good idea since taking the square of the signal is a non-linear operation. Taking the square of the FFT to determine the signal power is correct though.

For your profs. question it depends on what you have measured and at which sample rate. I assume it is the steering wheel angle and therefore it should be possible to answer it, but there will be some pitfalls as most likely the steering movement is not in a sinusoidal form. However, the basic frequencies in the movement will be related to this.

Given that you redo the estimation without the squaring of the signal, the ten times safety margin should be more than enough.

To further convince you and your prof. I would suggest bandlimiting the measured data to your estimate by using a very sharp FIR filter and compare visually as well as downsampling the data and compare.

• Thank you for your answer! As to what I have measured, it is the actual steering wheel angle with a sample time of 50 ms, so sample f = 20 Hz. Judging from your answer and my knowledge: if I apply an FFT on this signal, do I see the representation of steering input from the driver by a finite set of sinuses, so I can conclude even though the input is not sinusiodal what my system sample time should be? Commented Feb 24, 2014 at 12:40
• Well, if it is already sampled in 20 Hz and your conclusion is that the bandwidth is 10 Hz I guess it may not be much of a conclusion. Or was the purpose to see if 20 Hz is enough? To answer your question, yes, the DFT determines how similar the signal content is sinusoids with different frequencies. Assuming that small amplitudes will not contribute significantly to the information of the signal, one can determine a suitable bandwith in this way. For the racing aspects in the second reply I have no clue so better trust that answer as well. Commented Feb 25, 2014 at 8:20
• The information that was available to me just so happened to be sampled at 20 Hz. The FFT looks kind of like a normal distribution with a peak at 1/3 Hz and almost 0 at 1 Hz. Around 2 Hz even the noise is hardly visible. Commented Feb 25, 2014 at 15:25

First, I agree that step 2 should be omitted before the FFT.

Second, I'd suggest a much larger data collection set before making any conclusions on the frequencies that might be involved in the user input. As a racer, I can tell you that many drivers have different styles, some being very smooth with inputs which would be expected to have less bandwidth, and others that are constantly making quick corrections. Car setup will affect this as well. Input bandwidths may increase substantially in response to an incident like a mechanical failure (e.g., blown tire) or other unusual situation.

There are also tricks like letting go of the steering wheel to allow it to recenter quickly after a substantial correction that will result in a high rate of change of the steering angle. If you want to be able to capture things like that, be sure to include such events in your test and analysis data. The implication here is that the steering angle can change faster than a normal human input either in response to letting go or hitting a curb/berm/hole on an apex or something like that.

• Isn't the conclusion from (at least parts of) your discussion that the wheel to steering wheel information transfer may have a larger bandwidth than the steering wheel to wheel information transfer? Commented Feb 25, 2014 at 8:25
• Actually when I looked back at the code I wrote I had omitted step 2 and plotted |X(f)|^2, yay me. I have several datasets, including an endurance race and a race with a warm-up lap immediately followed by hotlap. Also I didn't just look at the steering input, but also brake-pressure etc. to capture any 'wild' input. The controllers to actuate setpoints from the user + corrections from electronic stability control are supposed to run at 1 KHz, so no worries there. I mostly just took the FFT to see what typical user input is and what order of frequencies I'm looking at! Commented Feb 25, 2014 at 15:32