Positron wrote:
>Sorry I've been rather unclear up to this moment! Thanks for your
patience
>and willingness to help. I'm not an engineering student (just a curious
Curiosity is good, but you might also do some searching, too.
>math major!). When I said "it moves on its own" what I meant is a
scenario
>like this: Imagine a car with a driver in it that can drive however he or
>she wishes.
So you're trying to work without measuring what the driver is doing, but,
rather, the effects of what the driver is doing. Can you add a sensor to
measure the positions of the pedals (or something closely related)? That's
really the kind of thing that goes in the "B" and "u" terms. At the risk
of overgeneralizing, the more information you give the filter, the better,
and only giving it one piece of information is not a recipe for success, as
you've found. I'd still expect some drift even then, but it'll be less,
and you can cut it down if you can assume the car tends to stop on its own
(somewhat level ground).
If you're not able to connect to the car, you might at least postulate GPS,
computer vision, odometry, or some other source of data. Is this a purely
theoretical exercise, or are you actually going to try to implement it at
some point? If it's just a theoretical exercise, you may want to try
something a bit different (let me know, and I can give you some ideas to
play around with to build intuition).
Can you afford a book?
>The car has an accelerometer attached to it. The goal is to
>determine purely from the accelerometer readings how far the car has
>traveled.
The way you've posed the problem, it probably just won't work. The Kalman
Filter is not magical. You may be able to improve your results slightly,
but nothing better than applying a digital FIR or IIR filter to the data
and doing your double integration. The nice thing about the Kalman Filter
is its ability to combine information.
>
>So, the car moves simply using Newton's laws and kinematics. That's why I
>chose F =[1 dt dt^2/2 ; 0 1 dt; 0 0 1]. But, this ignores the actual
>acceleration that the driver seems to be able to choose.
Yes, and the acceleration is usually a function of the system state. In
this case, it is not. The fact that your filter has no idea what the
driver chose is technically a violation of an assumption in the derivation
of the filter, but that in and of itself isn't necessarily fatal in
practice. It usually means that you add a lot of process noise to try to
cover up what the driver is doing. I wouldn't necessarily expect the
covariance to be a useful measure of how the filter is doing in that case,
though you can certainly build intuition through simulation.
Again, I don't think the Kalman Filter is really gaining you anything the
way you're using it.
>That's why I
>figured we would take measurements of acceleration. However, when the
state
>evolves from x_k to x_(k+1) I need to factor in the new acceleration at
the
>time step k+1.
>
>"You still need to know how your plant moves. Inertia, forces, etc."
>
>I'm unfamiliar with the word plant. Does that just refer to the body in
>question with the accelerometer attached to it? Or does this just mean
the
>actual model itself?
In this case, at a minimum, it refers to the car. You can also make it
refer to the driver and the road, but that choice is not arbitrary, and
depends on what you're doing. "plant" is one of the first terms you hit in
controls theory, so I assumed that you'd have run into it in your reading
on wikipedia and elsewhere. You apply a control input (u) to a plant (the
system and/or a model of a system), and you measure outputs through sensors
(y). There are internal states that are not usually directly observable,
which we model as "x". The choice of "x" is usually not unique, but
physical states like position, etc. are acceptable in this case. Sometimes
the sensor data is fed through a transformation (usually with memory), back
into the control input; this is basic feedback control of the plant, such
as in a cruise control (which uses a measurement of speed, not
acceleration).
>
>With respect to forces, the car has a driver, so accelerations occur at
the
>whim of the driver. For my simple model, I'm assuming there are no other
>outside forces (although, later I will assume a bumpy road scenario so
>there will be some random Gaussian process noise).
A bumpy road presents sensor difficulties, but ultimately has a [nearly?]
zero-mean effect on the states. A grade in the road may violate
assumptions about the plant: does your car come to a stop if you coast
long enough?
>Does that make a bit more sense?
Yes, although I think you'll wind up frustrated if you follow this path
without changing the problem statement any. Either in simulation or in
practice, this is not really going to be pleasant without some changes.
If you integrate white noise, you get a random walk, and if you integrate
that, you get a random ramp. Have you seen graphs of realizations of those
processes, or of their statistics? Try doing your double cumsum() you
mentioned over 10000 of those randn() realizations, and plotting either all
the traces, or, if MATLAB is being retarded about memory, just median, Q1,
Q3 (quantile(), IIRC). The results are all over the place, no?
And that's assuming no bias on the accelerometers. By measuring a quantity
more closely related to what you want to estimate (such as position), even
if your measurements are rare, you can try to keep those drifts in check.
Michael