[PD] MARG (Was: Sensors2OSC mapping challenge)

Tue Aug 22 23:20:34 CEST 2017

Hi,

there seems to be a misunderstanding from my side when reading the bug
report: Currently Sensors2OSC is reading all sensors and outputs the
values. Each sensor reports its type, and there is an orientation sensor
available, but that sensor is deprecated. So using newer models,
getOrientation() should be used.

As I currently have no time for further developing the app, it is noted,
but it won't happen until later this year, probably not before November,
as other changes are already waiting to be finished, notably a change in
the OSC format, and the ability for the app to run as a service in the
background.

Thomas

On 22.08.2017 22:58, katja wrote:
> It seems that SensorManager.getRotationMatrix() gets the raw sensor
> values and SensorManager.getOrientation() calculates the device
> orientation from there:
> 
> https://developer.android.com/reference/android/hardware/SensorManager.html
> 
> But that is the API, I don't know how it's done. The result won't be
> optimal for all purposes when the functions use accelerometer and
> magnetometer values only (no gyro).
> 
> Katja
> 
> On Tue, Aug 22, 2017 at 7:58 PM, Max <abonnements at revolwear.com> wrote:
>> I see! In my case the data comes from the smartphone (via Sensors2OSC). So
>> either it somehow runs on the smartphone or it runs in Pd (as abstraction or
>> external). Network traffic may be an issue.
>>
>> Somehow I had expected that Google, Apple or even the sensor chip
>> manufacturers have something like this and provide it via API, but that
>> doesn't seem the case. Or maybe
>> SensorManager.getRotationMatrix [1]
>> is something like a MARG?
>>
>> [1]
>> https://stackoverflow.com/questions/15315129/convert-magnetic-field-x-y-z-values-from-device-into-global-reference-frame#15317814
>>
>>
>>
>> On 2017년 08월 21일 19:17, katja wrote:
>>>
>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
> 

-- 
"Anything can be a tool - poverty, war. War is useful because it
is effective in so many areas." (Bijaz to Hayt in: Frank Herbert -
Dune Messiah)
http://www.residuum.org/