[PD] MARG (Was: Sensors2OSC mapping challenge)

katja katjavetter at gmail.com
Mon Aug 21 19:17:15 CEST 2017


Max, I don't know of a Pd project in this field, but there's a good
reason to do sensor mixing (beit IMU or AHRS) on the platform that
reads the sensors rather than in a Pd patch or external. The filter /
mixer works best when sensor data is read at a higher sample rate than
you may need the orientation data. For example, an Arduino Pro Micro
(16 MHz processor) can do IMU mixing at ~400 Hz which is just a decent
sample rate for the purpose of filtering sensor noise. For parameter
control I don't really need the data at that rate so I send midi
messages at a lower rate (could be OSC instead of midi). That
minimizes traffic over USB but also a saves lot of function calls in
Pd.

On the other hand it would be nice to do it in a Pd patch or external
for educational reasons or better reusability. By the way Sebastian
Madgwick's current work on AHRS is in this repository:

https://github.com/xioTechnologies/Fusion

Katja

On Sun, Aug 20, 2017 at 9:02 PM, Max <abonnements at revolwear.com> wrote:
> Attached is the C code from the paper linked below.
> Before I try, should I attempt to make this in Pd as an abstraction or just
> take this c code and see if I can turn it into an external?
>
> Or maybe someone has already done it?
>
>
> On 2017년 07월 27일 09:17, katja wrote:
>>
>> Hi Max,
>>
>> To emulate 3D orientation from gyro, accelerometer and compass data is
>> most efficiently done using a 'quaternion filter'. Sebastian Madgwick
>> has popularized the method, see
>> http://x-io.co.uk/open-source-imu-and-ahrs-algorithms/. I use
>> Madgwicks implementation of Mahoney's method, for Arduino based
>> 'electronic hands', and found that Mahoney's algorithm for IMU sensors
>> (gyro and accelerometer only) worked much better than Madgwick's own
>> algorithm. But I had to make a few modifications, based on Kris
>> Winer's work (https://github.com/kriswiner).
>>
>> Katja
>>
>> On Tue, Jul 25, 2017 at 11:13 PM, Max <abonnements at revolwear.com> wrote:
>>>
>>> Made a quick little video
>>> https://vimeo.com/226958567
>>> the described issue is still there.
>>>
>>> Background on the problem:
>>>
>>> https://stackoverflow.com/questions/27106607/get-rotation-and-display-in-degrees
>>>
>>> https://stackoverflow.com/questions/15315129/convert-magnetic-field-x-y-z-values-from-device-into-global-reference-frame#15317814
>>>
>>>
>>>
>>> On 2017년 07월 08일 23:16, Max wrote:
>>>>
>>>>
>>>> I've played around with the Android app Sensors2OSC [1] and was trying
>>>> to
>>>> just map the senors to a virtual model of a phone.
>>>> I was able to get the axis individually mostly behaving correctly, but
>>>> as
>>>> soon as the phone moves around in more than one way, it is doing weird
>>>> things. I started to wonder if it is only my phone though.
>>>>
>>>> At https://github.com/mxa/GemVR the patch ReceiveSensors2OSC.pd has
>>>> everything ready to map the senor data to the Gem model.
>>>>
>>>> I'd be curious to see if it is possible to let it behave correctly.
>>>>
>>>> [1] https://sensors2.org/osc/
>>>>
>>>> _______________________________________________
>>>> Pd-list at lists.iem.at mailing list
>>>> UNSUBSCRIBE and account-management ->
>>>> https://lists.puredata.info/listinfo/pd-list
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Pd-list at lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> https://lists.puredata.info/listinfo/pd-list
>>
>>
>



More information about the Pd-list mailing list