[Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage

[Mike]

At 03:03 AM 4/6/07, you wrote:
>I also have considerable experience in stochasic estimation and robust control, both in my graduate work and direct implementation in particle beam accelerator trajectory control with 10,000 control elements and measurement points, with results published in numerous physics journals. The thing about electron-beam accelerators is that you have only one chance to get it right, otherwise you will destroy a multi-billon dollar facility. But again, size does not matter....

Excellent, since we both have direct experience of systems and techniques
far more complex than that required by a 60 tooth crank wheel trigger then it
must be clear that references to Kalman like filtering are needlessly complex...

>>In other words, the 6 deg toothed gear pulse
>>is adequate to gauge engine state or rather impending engine 'change' of state. The rush and it appears an overly complex
>>rush to the notion of a Kalman filter as the base reference is tangential to a really simple algorithm to interpolate the best
>>guess for the start of dwell for an ignition event, ie I stand by my earlier comment, its needlessly complex and I will add
>>that a simple binary interpolation will do and easy to add a accel add/sub factor. Its not as esoteric as a "predictor" implies,
>>its a simple term in a bit of late high school algebra, lets not make it sound like its a basis for a fields medal...
>>
>
>Going back to the original answer to request for information on Kalman filtering, the response was to look at a tracking filter. 

Although the initial poster thought that a Kalman filter 'might' be suitable, the more appropriate response might
be to steer him or rather rotate the paradigm away from Kalman ;)  and just start with linear interpolation and when that
works and he is comfortable with it that he then add a term to fit change of velocity over time to obtain a y=mx+b form
which he can apply to the next interval to calculate the ignition point. ie No need for any filter.

>http://www.acfr.usyd.edu.au/teaching/4th-year/mech4721-Signals/material/lecture%20notes/16%20Range%20Tracking.pdf
>
>At the top of page 413 (actually page 5 in the pdf), the statement "The alpha-beta tracker is a fixed gain formulation of the Kalman filter and is still widely used because it is easy to implement [and] performs well in general"
>
>I will forgo the medal, I will take the cash instead....

Link is of some interest. But its still way over the top of whats needed and isnt necessary to entertain any
Kalman keywords at all for the purpose of name dropping ;-)

Like Customs Brokers, they make things so overly complex and charge $200 (mostly) for finding an HTS...

>Another paper: http://www.ee.ucl.ac.uk/lcs/papers2002/LCS078.pdf (see the end of the first page..)
>
>Another one: http://code.eng.buffalo.edu/tracking/papers/tenne_optimalFilter2000.pdf

Yes mostly really nice links of an academic ilk, way over that needed for the 60 tooth crank 'problem'... I would have thought...
Though interesting reading, tah :)

>Actually, this is correct. As stated before, higher tooth densities are desired. When interpolation is involved, its just guesswork between the tooth positions. And if there are rotational rates of change then there will be error. If I guess with a tracking filter, linear/quadratic interpolation, etc. its just a guess.

The thing is the type of instantaneous change of rotational acceleration wont be high enough to be a factor
at all unless there is detonation I would expect, or is there any data log from an MS to suggest it will that such
a 3rd order might be relevant, 2nd order would be ok though, and grabbing the previous 3 samples of counts
between the teeth will either be a (rough) straight line or a parabola etc with some minimal potential other curves
in between but the need for a filter seems to add if anything a complexity of terminology to a detail which
will absorb a huge amount of time with doubtful practical import.

>I will say that if I was also to implement a crankwheel I would use as high a tooth count as possible. In fact, I find it interesting to see ignition controller specs that advertise "0.1 degree timing accuracy". And at crank tooth update points this may be close (probably not so for other reasons). But you will never see this stated as "0.1 degree timing accuracy over all engine operating ranges".

mmmm,  me think sales speak has probably got into those specs or the dot on the line isnt a decimal.... ;)

Or the interpolator is a salesman since its easier to sell then design a good interpolator or is a simplistic division of
background cycle rate with roational speed to acquire knowledge of engine state at 0.1 deg intervals etc !

>What I need to do is dig up the mathematical error analysis we performed on crank position estimation a while back (posted on the MS forums), alomg with real measurement results, compared to linear last interval and rate-of-change of last interval (which was originally performed in the code). Also the fact that the tracking filter takes under 4 usec to totally complete on aq 24 MHz HCS12 (contrast this to the fact that at 10,000 RPM a one-degree crank angle takes 16.6 usec). Again, for high tooth count wheels the code defaults to last interval and does not use this calculation. 

mmm, I am guessing that a linear interpolation and table lookup for accel/decel add/sub would be far quicker and use less
register space & memory etc ?

>And, everyone running MS-IIs right has the capability of performing their own experiment right now. One runtime variable available is the "TimingErr" variable. This is the subtraction of the predicted next-tooth time from the actual next-tooth arrival time, converted to crankshaft degrees. The coefficients alpha,beta,gamma can be adjusted in real time. The gamma value is the one that introduces feed-forward for rotational acceleration prediction. All they have to do is turn on a datalog, run the engine, then plot the results in MLV. Do not be surprised when you see +/- 10 degrees of error in timing for low tooth count wheels at low RPM....

mmmm, yes understood and has anyone done any blind trials re drivability, ie classic experimental trial. 

Eg. Driver ONE is faced with 4 buttons on console, button 1 selects just linear, button 2 selects accel/decel,
button 3 turns on a light and selects linear button 4 turns on a different light and selects accel/decel.
then a course is traversed, cruise, hill, start, stop, gentle drive, hard acceleration etc etc

Then buttons are randomised (but recorded separately) and Driver TWO does same course

Maybe if time do again for Driver THREE and FOUR.

Map qualitative perceptions and any quantitative results like fuel consumption, number of engine cycles etc and prepare a
stat table of all drivers, their buttons, the actual resulting software setting of linear interpolation vs accel/decel. amendment etc

Thus gaining a perspective on the practical value of such a correction and its effect on fuel, drivability, engine wear etc


>The one thing I have dropped a few times here but no one has questioned is why is there more error at low RPMs?

Saw a few other comments, all make sense re static compression, good thing Adam didnt slap his forehead that time ;)

*grin*

Have a nice easter everyone,





Regards from


Mike
Perth, Western Australia
VK/VL Commodore Fuse Rail panel that wont warp, twist or melt, guaranteed  !
Twin tyres for most sedans, trikes and motorcycle sidecars
http://niche.iinet.net.au