Filtering/fusing multiple sensor data in max? (Kalman/Complimentary/Marg)

I found this these which shows how to handle some of the math:
https://cycling74.com/forums/how-to-calculate-sqrt-a2-b2-c2-with-only-one-expr-object

The main bit is this:
expr sqrt ( $f1*$f1 + $f2*$f2 + $f3*$f3 )

That doesn't address the C code stuff or calibration however.

I attempted something along these lines a while back (we probably even have the same sparkfun 6dof board). I was attempting to get most of the math running on the arduino itself, and only output the 3 axis rotational data via the serial object (along with an absolute 3-dimensional spatial number).

That C-code looks promising, it probably wouldn't be TOO hard to convert to Processing to use on an arduino.

If you're interested in collaborating on getting something like this to work, I'm all for it! I'm sure we have different needs for the end result but it's something that I think would come in handy for a lot of people.

That would be great. I (we, as Angela and myself are working on this together) have an Arduimu board which has the same exact sensors as the sparkfun 6dof board.

I've seen the code you're talking about (if it's the code posted on the arduino forum) and it is pretty straight forward looking. I wanted to avoid doing the processing on the arduino in order to bring latency down to a minimum (working on the assumption that a laptop can crunch the numbers tons faster than the arduino) and wanted to also avoid involving Processing. Basically to have the smallest amount of stuff "in between" as possible. So for me it would be ideal to turn that C code into straight Max so that it goes from sensor data right to processing in max or whatever.

Definitely up for collaborating on figuring this stuff out. With the amount of wiimote action happening I'm surprised more people aren't doing this kind of software filtering on the data.

I've been playing a bit with the Sparkfun 9DOF but I haven't been able to get a stable 3D position tracking without serious drifting. So any development to get a good Kalman filtering or such within Max would be nice !

The version of the video/code posted in the first post (that uses 9dof instead of 6dof) is really impressive. Solid tracking and very little latency (at least visible).

Check it:

http://www.youtube.com/watch?v=fOSTOnQzZC

I found a 6dof Kalman filter designed specifically for the sparkfun 6dof Razor board that I own - which seems to be working pretty well - sadly it doesn't cover yaw, as you need a magnetometer to do that.

I suppose I don't really see the necessity of running all the filtering from within Max, when you've got a more than powerful enough microprocessor on any arduino. That way your hardware is putting out useful information, and all you have to do with max is interpret it. In my experience, trying to do 'heavy' math like a 6 or 9 dimensional kalman filter is either too slow, too complex (which leads to 'slow' again), or downright impossible - and you'd need an external written in C. At which point, why not just run that code on your microprocessor?

I'm of the opinion that utilizing the microprocessor is for the best - the arduino can output at a bit rate/baud rate of 115200 bps. If we have 16 bytes worth of data coming out, that's about 900 samples per second. That's like running a metro set to 1.1 - which in my experience can cause some issues with Max (CPU spikes, crashing metros, etc). For contrast, MIDI runs at 31250 baud, which is almost a quarter of the speed of the Arduino's max output.

Basically, the benefit of a microprocessor is that you can devote the entirety of it's processing to doing something very specific - implementing a Kalman, DCM, or Complimentary filter in Max would likely be slower merely because the CPU is doing other things - and unless we can write a C external that devotes a thread to the filtering, I'd expect error handling would start to get maddening.

Hmm, you make some compelling points. At the moment I'm polling serial at 10ms with a qmetro, so it's not super fast.

Is this what you're using?
http://arduino.cc/forum/index.php/topic,58048.0.html

What looked good about the video in the first post is that the yaw was there (even with 6dof), it was just a bit prone to error.

For our particular usage, the artists hands would often return to her side, or rather, straight ahead, and she would never turn completely around, so I think that could be used to periodically 'reset' the gyro by sensing if its been relatively stationary for 3sec, then reset that as zero, or something like that.

Having the numbers crunched in max could make that kind of autocorrection more difficult, as the drift would be reset post-calculations. There are 9dof arduino filters I think too (or something like the C code above).

Hmm, so as long as the Arduino can read, process, and send over wireless faster than I can poll serial comfortably (10ms?) it's better. Wireless also adds a bit of delay/bottlenecking too I would think.

Are you sending both the raw and processed values across? Just wondering about the resetting error correction (though I guess that could happen in the Arduino as well, much more difficultly).

Wireless is something I still need to work out myself (Xbee is physically too large for what I need in the end), but I don't think it would add too much overhead. Possibly a delay, sure, but I don't think it would eat into the baud rate at all.

Resetting error correction wouldn't be too hard to code into an arduino - in the main loop, you just keep a running average (or two, or four) that resets every second or so. So, say you have averages A, B, C, and D - A resets at 0.25 seconds, B at .5, C at .75, and D at 1.0, as a cycle. Then you average those four numbers, which gets you an average of the past 1 second without any huge hiccups. If all of the averages are within a certain range of each other, reset to 0 (or whatever numbers make sense). Then run the main loop.

OK so I guess maybe that is a bit complicated. My personal ideal would be to not even have to reset arbitrarily, as it's more precise in the long run. That would need a 9dof, though, I'm rather certain. Sadly I can't afford to buy one of those for a few more months.