processing accelerometer files from Matrix model (axes orientation issue)

[vcs1984]

Hello ActiPASS community. I hope you're all doing well. We would like to ask a question to the ActiPASS developers and community regarding how to best process data from a new accelerometer model.

We have previously used ActiPASS successfully with Axivity accelerometer data. However, we are now working with files from a relatively new device — the Matrix003 accelerometer — and have encountered some challenges due to different axis placement and orientation compared to the Axivity device and the default axis expectations in the Generic CSV format. Please see the image below, which illustrates the difference in axis orientation between the Axivity and the Matrix accelerometers, in both upright and inverted positions (as used in our project).

To work around this, we attempted the following transformations in R, after converting the Matrix .bin files into .csv format with the appropriate headers.

⚠️ Case 1: Matrix accelerometer placed inverted on the thigh
(This was done to avoid skin irritation in the standard position in most of participants)

acc_x <- output$data$acc_y * (-1) # Expected X is vertical (positive downward); Matrix inverted: -Y
acc_y <- output$data$acc_x # Expected Y is horizontal (positive outward); Matrix inverted: X
acc_z <- output$data$acc_z * (-1) # Expected Z is oblique (positive toward the skin); Matrix inverted: -Z

⚠️ Case 2: Matrix accelerometer placed upright (non-inverted) on the thigh
acc_x <- output$data$acc_y * (-1) # Expected X is vertical (positive downward); Matrix upright: -Y
acc_y <- output$data$acc_x * (-1) # Expected Y is horizontal (positive outward); Matrix upright: -X
acc_z <- output$data$acc_z # Expected Z is oblique (positive toward the skin); Matrix upright: Z

We would greatly appreciate your confirmation: Is this approach correct and necessary? Or is it possible to process the original Matrix CSV files without modifying the axes, perhaps using the flipped and rotated options in ProPASS or ActiPASS?

We tested three participants in ActiPASS 2025.04. (ProPASS default mode) with: (1) The original Matrix .csv (no axis changed); (2) A version with the "inverted" axis transformation (case 1); and (3) A version with the "upright" axis transformation (case 2). Interestingly, in two participants, all three files produced identical results. For one participant, the original (unmodified) file produced different results, while both transformed files yielded identical outputs. This led us to suspect that the transformation may not be necessary — possibly because ProPASS default mode uses auto Flip/Rotation=force, which might detect and correct the orientation automatically. I am attaching the ActiPASS_BatchSettings.txt file and the BatchOut PNGs for the participant where the unmodified file (13010003_original.png) shows different results compared to the files with previously modified axes (13010003_modified_inverted.png and 13010003_modified_upright.png).

We would really appreciate your guidance on whether axis transformation is needed for Matrix003 files, or if the default processing in ActiPASS already handles orientation correction.

Thank you very much in advance for your help, and also for providing this amazing open-source tool.

Best regards,

Vero




ActiPASS_BatchSettings.txt

[pasan-h]

Hi Vero,
Interesting question. I will try to answer but I am also bit confused 😉.

1. It's always a good idea to transform axes of raw data according to match the default orientations for respective accelerometer brand. This helps ActiPASS with cases where auto-orientation detection is difficult. This is specially true if the axes are also interchanged (with respect to defaults) like seen in above two cases.
2. This means ActiPASS generic CSV format should be corresponding to Axivity orientations (first case in above pictures).
3. I think (may be I am wrong) that, the activity-visualizations above indicate that ActiPASS most probably didn't fix orientations in either of the three cases.
4. Now comes the confusing part: The cases two and three above (inverted and upright) seem to have an impossible axes configuration. Whatever the orientation Axes should conform to the right-hand-rule; aren't they? Also keep in mind that the gravity as measured by accelerometers when the corresponding axes is downward have a negative sign.
5. Once we figure out why the axes config look strange, then we can figure out the correct axes transformation needed, I think.

Best
Pasan

[vcs1984]

Hi Pasan,
Thank you so much for your quick reply. I'm not quite sure what you mean by the "right-hand rule"; now that you mention it, it's possible that the axis transformations I'm applying (both inverted and upright) are not correctly accounting for gravity.

Just in case it's helpful, I'm attaching the three CSV files (only a fragment due to size) from the participant whose visualizations I shared earlier: (1) the original CSV (raw Matrix data, without axis transformation); (2) the CSV with modified axes (inverted; using the formulas from the previous comment), and (3) the CSV with modified axes (upright; using the formulas from case 2 in the earlier comment).

I truly appreciate your support, as I'm also confused about how ActiPASS is handling the axis correction and how to properly prepare these files for accurate analysis 😢

Many thanks again.

Best regards,

Vero

Uploading MD ACEMI1-13010003_AxisModified_inverted_fragment.csv…
Uploading MD ACEMI1-13010003_AsixModifiedUpright_fragment.csv…
Uploading MD ACEMI1-13010003_Original_fragment.csv…

[vcs1984]

MD ACEMI1-13010003_Original_fragment.csv
MD ACEMI1-13010003_AsixModifiedUpright_fragment.csv
MD ACEMI1-13010003_AxisModified_inverted_fragment.csv

[pasan-h]

Hi Vero,
I will go through the attached files as time permits. But please give me some time.
What I meant by "right-hand-rule" is that accelerometer (or any triaxial sensor) should conform to the right hand rule. However the axes config above (for the two cases), does not follow that rule (i.e. if we assume X, Y axes are pointing correctly, then the Z axis points in the wrong direction). Maybe that is why the results look weird (anyway I haven't looked at CSV files yet).

[pasan-h]

If we assume Matrix raw data follows a right-hand cordinate system, then for the inverted case; the R code should look like below I think.

acc_x <- output$data$acc_y * (-1) # Expected X is vertical (positive downward); Matrix inverted: -Y
acc_y <- output$data$acc_x # Expected Y is horizontal (positive outward); Matrix inverted: X
acc_z <- output$data$acc_z # Z is already oblique (positive toward the skin); Matrix inverted: Z