Hi I am having trouble ( a lot of trouble ) trying to get meaningful and timely acceleration data. In essence, I have a wheel speed sensor that picks up around 40 to 100 pulses per wheel revolution (adjustable). This is captured by a 16bit Micro/DSP. All I want to assert, with reasonable accuracy is the wheel acceleration. My acceleration data at the moment is all over place. How can I filter the data in real time so that I can assert wheel acceleration? eg. DO I need to implement a Kalman filter or is there a faster way of doing this? In other words, as a test, I have fitted this setup to a car and steady acceleration does not show steady acceleration data - it's all over the place. I can see the acceleration component, but is is saturated with acceleration spikes.
Acceleration
Started by ●October 30, 2007
Reply by ●October 30, 20072007-10-30
"Gareth" <gareth@nonick.net> writes:> Hi > > I am having trouble ( a lot of trouble ) trying to get meaningful and > timely acceleration data. > > In essence, I have a wheel speed sensor that picks up around 40 to 100 > pulses per wheel revolution (adjustable). This is captured by a 16bit > Micro/DSP. > > All I want to assert, with reasonable accuracy is the wheel acceleration. > My acceleration data at the moment is all over place. > > How can I filter the data in real time so that I can assert wheel > acceleration? eg. DO I need to implement a Kalman filter or is there a > faster way of doing this? > > In other words, as a test, I have fitted this setup to a car and steady > acceleration does not show steady acceleration data - it's all over the > place. I can see the acceleration component, but is is saturated with > acceleration spikes.It's tough to help you determine what's wrong with your algorithm when you haven't described it to us. How are you measuring time? Are you using a timer on micro? Are the pulses coming in as interrupts? What's your interrupt latency time? Do you keep interrupts enabled all the time? Etc., etc. -- % Randy Yates % "And all that I can do %% Fuquay-Varina, NC % is say I'm sorry, %%% 919-577-9882 % that's the way it goes..." %%%% <yates@ieee.org> % Getting To The Point', *Balance of Power*, ELO http://www.digitalsignallabs.com
Reply by ●October 30, 20072007-10-30
On Oct 30, 4:12 am, "Gareth" <gar...@nonick.net> wrote:> Hi > > I am having trouble ( a lot of trouble ) trying to get meaningful and > timely acceleration data. > > In essence, I have a wheel speed sensor that picks up around 40 to 100 > pulses per wheel revolution (adjustable). This is captured by a 16bit > Micro/DSP. > > All I want to assert, with reasonable accuracy is the wheel acceleration. > My acceleration data at the moment is all over place. > > How can I filter the data in real time so that I can assert wheel > acceleration? eg. DO I need to implement a Kalman filter or is there a > faster way of doing this? > > In other words, as a test, I have fitted this setup to a car and steady > acceleration does not show steady acceleration data - it's all over the > place. I can see the acceleration component, but is is saturated with > acceleration spikes.You need a higher resolution encoder. Get the highest number of counts per revolution that will not exceed the counter limits. I recommend you look into a steady state Kalman filter or observer. Peter Nachtwey
Reply by ●October 30, 20072007-10-30
>"Gareth" <gareth@nonick.net> writes: > >> Hi >> >> I am having trouble ( a lot of trouble ) trying to get meaningful and >> timely acceleration data. >> >> In essence, I have a wheel speed sensor that picks up around 40 to 100 >> pulses per wheel revolution (adjustable). This is captured by a 16bit >> Micro/DSP. >> >> All I want to assert, with reasonable accuracy is the wheelacceleration.>> My acceleration data at the moment is all over place. >> >> How can I filter the data in real time so that I can assert wheel >> acceleration? eg. DO I need to implement a Kalman filter or is there a >> faster way of doing this? >> >> In other words, as a test, I have fitted this setup to a car andsteady>> acceleration does not show steady acceleration data - it's all overthe>> place. I can see the acceleration component, but is is saturated with >> acceleration spikes. > >It's tough to help you determine what's wrong with your algorithm when >you haven't described it to us. > >How are you measuring time? Are you using a timer on micro? Are the >pulses coming in as interrupts? What's your interrupt latency time? >Do you keep interrupts enabled all the time? Etc., etc. >-- >% Randy Yates % "And all that I can do >%% Fuquay-Varina, NC % is say I'm sorry, >%%% 919-577-9882 % that's the way it goes..." >%%%% <yates@ieee.org> % Getting To The Point', *Balance ofPower*, ELO>http://www.digitalsignallabs.comI am using a dsPIC. This has capture channels that capture a 16bit timer value every pulse. I then put a number of sequencial capture values in an array to do post processing. Right now I am using an array length of 40. I average the first five and last five values as the start and end velocity, and then divide that by the time it has taken between (by adding the values). This, I believe, give me acceleration, but it is very 'noisy'.
Reply by ●October 30, 20072007-10-30
>Hi > >I am having trouble ( a lot of trouble ) trying to get meaningful and >timely acceleration data. > >In essence, I have a wheel speed sensor that picks up around 40 to 100 >pulses per wheel revolution (adjustable). This is captured by a 16bit >Micro/DSP. > >All I want to assert, with reasonable accuracy is the wheelacceleration.>My acceleration data at the moment is all over place. > >How can I filter the data in real time so that I can assert wheel >acceleration? eg. DO I need to implement a Kalman filter or is there a >faster way of doing this? > >In other words, as a test, I have fitted this setup to a car and steady >acceleration does not show steady acceleration data - it's all over the >place. I can see the acceleration component, but is is saturated with >acceleration spikes. >Sorry, I did'nt fully answer your question: Yes, I am using 'always on' interrupts. They capture a timer value on edge detection. I manually reset the timer in the ISR. The interrrupt's latency on this device is apparently 7 cycles.
Reply by ●October 30, 20072007-10-30
"Gareth" <gareth@nonick.net> wrote in news:I4CdncABe7eeqLranZ2dnUVZ_oWdnZ2d@giganews.com:> > Sorry, I did'nt fully answer your question: > Yes, I am using 'always on' interrupts. They capture a timer value on > edge detection. I manually reset the timer in the ISR. The > interrrupt's latency on this device is apparently 7 cycles. > >I'd spend some time verifying the quality of your ISR servicing with a function generator, though with your low pulse count, unless you screwed the pooch, the ISR should be able to keep up. For stuff like this, I really prefer using a controller that directly handles quadrature inputs, maintaining your count in hardware, not software. It just simplifies the debugging process alot. There are also chips that will maintain the count of an encoder-- HCTL-something or other, if I almost remember correctly. -- Scott Reverse name to reply
Reply by ●October 30, 20072007-10-30
>On Oct 30, 4:12 am, "Gareth" <gar...@nonick.net> wrote: >> Hi >> >> I am having trouble ( a lot of trouble ) trying to get meaningful and >> timely acceleration data. >> >> In essence, I have a wheel speed sensor that picks up around 40 to 100 >> pulses per wheel revolution (adjustable). This is captured by a 16bit >> Micro/DSP. >> >> All I want to assert, with reasonable accuracy is the wheelacceleration.>> My acceleration data at the moment is all over place. >> >> How can I filter the data in real time so that I can assert wheel >> acceleration? eg. DO I need to implement a Kalman filter or is there a >> faster way of doing this? >> >> In other words, as a test, I have fitted this setup to a car andsteady>> acceleration does not show steady acceleration data - it's all overthe>> place. I can see the acceleration component, but is is saturated with >> acceleration spikes. > >You need a higher resolution encoder. Get the highest number of >counts per revolution that will not exceed the counter limits. >I recommend you look into a steady state Kalman filter or observer. > >Peter NachtweyHi Peter Thanks for the reply. I am currently using a resolution of 200nS but can go to 25nS. I will try that next. (it's not so simple as the timer overflows at low to moderate speeds). How do I implement a steady state Kalman filter / where can I find out more information on this? Gareth
Reply by ●October 30, 20072007-10-30
Gareth wrote:> Hi > > I am having trouble ( a lot of trouble ) trying to get meaningful and > timely acceleration data. > In essence, I have a wheel speed sensor that picks up around 40 to 100 > pulses per wheel revolution (adjustable). This is captured by a 16bit > Micro/DSP. > > All I want to assert, with reasonable accuracy is the wheel acceleration. > My acceleration data at the moment is all over place. > > How can I filter the data in real time so that I can assert wheel > acceleration? eg. DO I need to implement a Kalman filter or is there a > faster way of doing this?You have got a trivial bug somewhere. Fix your code. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●October 30, 20072007-10-30
> > >Gareth wrote: > >> Hi >> >> I am having trouble ( a lot of trouble ) trying to get meaningful and >> timely acceleration data. >> In essence, I have a wheel speed sensor that picks up around 40 to 100 >> pulses per wheel revolution (adjustable). This is captured by a 16bit >> Micro/DSP. >> >> All I want to assert, with reasonable accuracy is the wheelacceleration.>> My acceleration data at the moment is all over place. >> >> How can I filter the data in real time so that I can assert wheel >> acceleration? eg. DO I need to implement a Kalman filter or is there a >> faster way of doing this? > >You have got a trivial bug somewhere. Fix your code. > > >Vladimir Vassilevsky >DSP and Mixed Signal Design Consultant >http://www.abvolt.comHi Vladimir Thanks for the pointer! Seriouly though, I have been at this for weeks. I have tried different target systems, different code, Quad Encoders, Interrupts, DMA, Capture ports etc I have even tried buffering all of the data, dumping it to a pc and then writing VB code to perform the math - The result is always similar. I think it has somthing to do with the fact that the timer capture value changes slighly from pulse to pulse even with a function generator giving a steady square wave. This must be due to the fact that it is catching the timer increment halfway. I guess that I need some kind of filter to quash these differences?
Reply by ●October 30, 20072007-10-30
On Oct 30, 7:12 am, "Gareth" <gar...@nonick.net> wrote:> Hi > > I am having trouble ( a lot of trouble ) trying to get meaningful and > timely acceleration data. > > In essence, I have a wheel speed sensor that picks up around 40 to 100 > pulses per wheel revolution (adjustable). This is captured by a 16bit > Micro/DSP. > > All I want to assert, with reasonable accuracy is the wheel acceleration. > My acceleration data at the moment is all over place. > > How can I filter the data in real time so that I can assert wheel > acceleration? eg. DO I need to implement a Kalman filter or is there a > faster way of doing this? > > In other words, as a test, I have fitted this setup to a car and steady > acceleration does not show steady acceleration data - it's all over the > place. I can see the acceleration component, but is is saturated with > acceleration spikes.Try an alpha-beta filter first. If that isn't good enough, try an alpha-beta-gamma filter.
