[Vm-dev] MadgwickAHRS plugin and support code (was: Building a linux/Pi library to call via FFI)

David T. Lewis lewis at mail.msen.com
Sun Sep 13 04:31:58 UTC 2015


On Sat, Sep 12, 2015 at 08:49:50PM -0700, tim Rowledge wrote:
> 
> On 12-09-2015, at 6:47 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> > I don't know what got into me, but I brewed up a nice pot of coffee this
> > morning and ended up with http://squeaksource.com/MadgwickAHRS/
> > 
> > This is a plugin, accessor class, and unit tests that claim to demonstrate
> > that the plugin works.
> > 
> > I used FloatArray for parameter passing, on the theory that users of the
> > plugin may be doing float (not double) arithmetic, so it may be more
> > efficient to pass values in that manner.
> 
> Cool! I did actually write one as well, but I used an array of BoxedFloat64 (or whatever it is) for input and create a 4 element array for the quaternion result. I considered a FloatArray as well but
> a) I?ve never used one before, so I?m scared of them

Well it's basically the only convenient way to deal with float (as opposed
to double) floating point values. In Squeak, a Float is a C double, and
AFIK the only thing that directly represents single precision floats is
FloatArray. You would be justified in being scared of them, especially
if any of this sounds like it makes sense. But it does work and it might
be more efficient than arrays of Float (C doubles). Or maybe not, I don't
have any way to measure it. But I tried to set things up so that the
FloatArray things can be reused to avoid allocations and type conversions,
so maybe it will help.

> b) Won?t they be arrays of 64bit float values on a 64-bit image?

On the 64 bit V3 image, no. For 64 bit Spur, I am not sure. But by definition
I would expect FloatArray to contain single precision float values in any
image format, so there is a good chance that it will work on 64 bit Spur
also. I did test on 64 bit V3, and that passes the unit tests.

> c) I?m pretty sure I will have to create a bunch of floats when reading the IMU chip anyway, so since I have them, might at well stick?em in an array. 
> 

I was mainly thinking of matching the parameters to MadgwickAHRSupdate(),
which are single precision float. I don't know anything about IMU chips,
so I don't have a clue if that is a good fit. And I had to look up "IMU"
on Google, so that should give you an idea of my level of expertise.

> I did consider making the array 13 long so the result could be just appended. Might be worth trying?
>

That would work also. I don't think there would be a performance difference
either way, so whichever is easier to understand and document is probably good.
 
> The good news is that on a Pi 2 the call as-is costs ~8micro-sec, which considering it apparently uses ~50 +, 60 -, 150 *, 14 / and 5 sqrt floating point calls is quite impressive.
> 
> And yes, I suppose we?ll need to keep this as an external plugin to dodge the gnu-stasi. Sigh.
> 

Building external is easy, not an issue. But I think we need to keep the GPL
source code out of the platforms/Cross tree to prevent license confusion, so
that means linking to an installed library rather than linking the GPL code
directly into the plugin. That should not be a problem but I have not actually
done it yet.

Dave



More information about the Vm-dev mailing list