# [FoRK] kalman filters

Stephen Williams sdw at lig.net
Tue May 12 16:39:26 PDT 2009

```I want to solve a similar problem soon.

Damien Morton wrote:
> Struggling with a problem.
>
> I have an 3-axis accelerometer device held in a person's hand.
>
> I am trying to write code which will roughly measure the trajectory of
> the device as it is swung through a fishing rod casting motion.
> Apparently the distance of a cast is >80% dependant on the peak
> angular rate. The algorithm should then estimate that peak rate, while
> having a limited ability to be fooled as to the casting
> motion/trajectory.
>
> First thought on estimation is to look at the "outward" acceleration
> of the device as it is swung through an arc. Trouble is, this can be
> fooled by holding the device upside down and letting gravity to the
> work.
>
> Second thought is to integrate the forward acceleration to get an
> approximate velocity along the casting arc, and then based on an
> estimated radius of that arc, compute the centrifugal force and
> compare that with the "outward" measured acceleration. My worry here
> is that the direction of gravity (in the frame of the device) is
> changing over the length of the arc.
>
> Third thought is to integrate the "forward" acceleration to give a
> forward velocity estimate, and integrate again to give a distance
> travelled estimate. Use the distance estimate to place us on the arc
> and compute the gravity vector, and use the velocity estimate to
> compute an estimate of centrifugal force (based on an estimate of the
> arc's radius), which is correlated with the "outward" force. This
> approach seems to me to have too much estimating going on to produce
> reasonable results.
>
The acceleration is given in 3D.  You get a series of vectors that allow
you to fit an arc.  Too bad the Wiimote, and I think the iPhone don't
seem to have gyros in addition to the MEMS accelerometers.  The iPhone
should also have a compass.

Just looking at the Wiimote as an example:
http://blogs.msdn.com/coding4fun/archive/2007/03/14/1879033.aspx
http://www.wiibrew.org/wiki/Wiimote#Accelerometer
>   Accelerometer
> ADXL330 in a Wii remote
> Coordinate system used by Wii Remote
>
> The Wii Remote includes a three-axis linear accelerometer located on
> the top suface of the circuit board, slightly left of the large A
> button. The integrated circuit is the ADXL330 (data sheet),
> manufactured by Analog Devices. This device is physically rated to
> measure accelerations over a range of at least +/- 3g with 10%
> sensitivity.
>
> Since the accelerometer actually measures the force exerted by a set
> of small proof masses inside of it with respect to its enclosure, the
> accelerometer measures linear acceleration in a free fall frame of
> reference. If the Wii Remote is in free fall, it will report zero
> acceleration. At rest, it will report an upward acceleration (+Z, when
> horizontal) equal to the acceleration due to gravity, g (approximately
> 9.8 m/s²) but in the opposite direction. This fact can be used to
> derive tilt from the acceleration outputs when the Wii Remote is
> reasonably still.

> XX, YY, and ZZ are unsigned bytes representing the acceleration in
> each of the three axis, where zero acceleration is approximately 0x80.
> The coordinate system is shown in the diagram above (note that this is
> different from the coordinate system used by GlovePIE). Additionally,
> the BB BB  Buttons bytes also include the LSBs of the acceleration
> values in the unused bits
So, a series of acceleration points at certain time steps allows
integration to a set of fixed points in space.
This talks about it but doesn't solve it completely:

According to this a Kalman filter won't help when you only have a single
sensor:

Good demo of a Kalman filter for gyro+accel:
http://tom.pycke.be/mav/92/kalman-demo-application

Partially helpful.  Note that you cannot fly properly without either a
gyro or ground vision.
http://tom.pycke.be/mav/69/accelerometer-to-attitude

Nice:
http://en.wikipedia.org/wiki/Kalman_filter
http://blog.medallia.com/2007/08/iphone_accelerometer_source_co.html
http://blog.medallia.com/2007/08/fun_with_the_iphone_accelerome.html

sdw
> Fourth thought is to create a simulated robot arm, and use inverse
> kinematics to torque the joints to match the observed acceleration. I
> can simplify the problem to 2D, which will help. Getting really
> complicated here.
>
> I'm wondering if there might be a simpler way. In the end, all I want
> to do is take the accelerometer data and produce a value for casting
> velocity (I am assuming that the launch angle is perfect).
>
> Any suggestions welcome!
> _______________________________________________
> FoRK mailing list
> http://xent.com/mailman/listinfo/fork
>

```