kalman filter

zrbz · Joined: 16 Jul 2007 Posts: 2

can anyone help me implement a kalman filter using pic16f877?

i am using 1000 tics per revolution shaft encoder to get the position of my motor.

RLScott · Joined: 10 Jul 2007 Posts: 465

Does your shaft encoder have an index pulse too?

What sort of noise do you expect to have to deal with? I have never heard of a Kalman filter being used "estimate" the position of a shaft when a reliable encode is connected to it.

Robert Scott
Real-Time Specialties

Guest · Posted: Mon Jun 09, 2008 8:34 am

no it does not have an index pulse. i use it for a bipedal robot, so im expecting unnecessary increments in the encoder when the robot moves.

Ttelmah · Guest

The encoder, should return where the shaft is.
The 'point' about a Kalman filter, is where there is significant variation in the reading being taken, and the reading relates to a well understood motion, you can make a 'better guess' at where the real position is. So, if using a ultrasonic range finder for example, or a similar IR detector, which can have momentary variations as ambient conditions change, and also return a fairly 'noisy' signal, the Kalman filter is a good way of working out the real position. However with a shaft encoder, the reading should be accurate, and such a filter would be pointless...
You don't say what sort of rotational rate is involved, but if it is more than a slow rate, I doubt if a PIC, could perform a reasonable Kalman filter anyway, from a 1000ppr encoder. If the speed was at all significant, I'd consider using a hardware counter for the position (to avoid pulses being missed), and let the PIC get on with other jobs.

Best Wishes

RLScott · Joined: 10 Jul 2007 Posts: 465

Another reason why a Kalman filter is pointless in a shaft encoder is that the readings are not independent. Once an error in the count creeps in, that error stays in forever (or until some independent information comes in that can correct the error.) A Kalman filter would help in the case where each reading may have some error, but the error affects only that reading and not any future readings.

Why do you think that there will be unnecessary counts when the robot moves? Are you at least using a quadrature encoder (with A and B phases)? Such an encoder, when connected to a proper quadrature up/down counter, will not get any unnecessary counts, and it will properly account for stopping and reversing direction.

Robert Scott
Real-Time Specialties

radiohound · Joined: 17 Jan 2009 Posts: 1