Getting_Processed_Device-Motion_Data

[delmenhorst]

Would it possible to get access to this class?

https://developer.apple.com/documentation/coremotion/getting_processed_device-motion_data

It would be very handy.

[danomatika]

This could be a "raw", "processed", or "prepared" sensor option to the #pdparty receiver ala sending #pdparty accelerate processed 1 or #pdparty accelerate raw 0 would use the system-prepared events. In the case of "raw" this would be the default as it is now and by disabling it, you would request the processed data instead.

[danomatika]

The only issue if you want to use both types of events, but I am hesitant to keep adding new global receiver names, ala something like #paccelrate, #orientation, etc when I can reuse the current ones.

[delmenhorst]

I understand. mhm, In this case I think a new receiver like #orientation or #motion could make sense, because the processed data (pitch/roll/yaw) is a fusion algorithm of #accelrate, #gyro, #magnet.

[brizolara]

Yes, fused orientation as @delmenhorst described is a game changer. IMHO, the simple inclusion of orientation data in PdParty gives immense agility to prototyping (or even fully developing) and making accessible lots of stuff in sonic interaction design / new interfaces for music expression... (which includes of course @danomatika himself :) ). I'm porting this instrumentalization of atmospheric sounds (the Elemental) to PdParty at this very moment... I'm excited to have orientation data in PdParty!

Back to coding... I would simply increase the list of global receivers in PdParty. As for using a "processed" option, I wouldn't because - as far as I understood -, except for rotationRate that improves gyroscope data, all other quantities available are not improved versions of raw sensor data but new quantities (the most prominent case being the orientation)...

Letting, data = self.motion.deviceMotion (as in Listing 1 here) CMAttitude attitude = data.attitude,

a proposition of super useful receivers to add would be:

• #orientationeuler: (attitude.roll, attitude.pitch, attitude.yaw). 3d orientation calculated via sensor fusion, expressed as Euler angles roll, pitch, yaw/azimuth.
• #orientationquat: (quaternion.x, quaternion.y, quaternion.z, quaternion.w). Same as above, but in form of a quaternion. WithCMQuaternion quaternion = attitude.quaternion;
• #orientationmatrix: (rotMatrix.m11, rotMatrix.m12, rotMatrix.m13, rotMatrix.m21, rotMatrix.m22, rotMatrix.m23, rotMatrix.m31, rotMatrix.m32, rotMatrix.m33). Same as above, in the form of a rotation matrix. WithCMRotationMatrix rotMatrix = attitude.rotationMatrix;
• #rotationrate: (data.rotationRate.x, data.rotationRate.y, data.rotationRate.z). This is improved gyroscope data. Docs: "... gyroscope data whose bias has been removed by Core Motion algorithms".
• #gravity: (data.gravity.x, data.gravity.y, data.gravity.z). This is the gravity vector in relation to the device, in units of g.
• #useracceleration: (data.userAcceleration.x, data.userAcceleration.y, data.userAcceleration.z). This is the subtraction of the total acceleration of the device [i.e., the raw acceleration that PdParty receives in #acceleration] by the gravity acceleration in relation to the device. So, it's the acceleration imparted by the user to the device. Docs: "The accelerometer measures the sum of two acceleration vectors: gravity and user acceleration. User acceleration is the acceleration that the user imparts to the device. Because Core Motion is able to track a device’s attitude using both the gyroscope and the accelerometer, it can differentiate between gravity and user acceleration." I can't test now, but all it tells that it's also in units of g.

There's also heading and magnetic field (with earth magnetic field subtracted... Interesting!), but I wouldn't say these are urgent...

[danomatika]

@brizolara Since I had not heard back to my review notes on #92, I decided to use it as a guide to implement a simpler version: b691713ab5747bf10618020954490afc6899a259.

There is a single #motion sender for the following events:

• attitude pitch roll yaw: attitude in radians
• rotation x y z: 3 axis rate of rotation in radians/s
• gravity x y z: gravity vector
• user x y z: user-initiated acceleration (without gravity)

The motion events are enabled in the same manner as the other sensors, ie. send motion 1 to #pdparty and there is a new Motion pdparty test which simply shows the incoming values.

I decided to leave off the attitude quaternion and matrix for now.

Can you test and update your sample project? If everything works, please open a new PR for just the sample project so I can include it in the beta4.

[danomatika]

@brizolara Also, consider adding an info.json file to your sample project. The contents are displayed in the scene info view.

[danomatika]

@brizolara I have added a slightly modified version of the elemental-rain example to the PdParty samples. The only changes were to the sensor input handling to reflect the new #motion event message format. As far as I can tell, it's working as in your example video, but you may want to check. I plan to submit 1.3.0 to Apple for release in the next day or two.