From: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> To: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> Cc: "linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Gregor Boirie <gregor.boirie-ITF29qwbsa/QT0dZR+AlfA@public.gmane.org>, Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Samu Onkalo <samu.onkalo-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> Subject: Re: [PATCH] iio: document bindings for mounting matrixes Date: Mon, 29 Aug 2016 18:31:44 +0100 [thread overview] Message-ID: <8137ebdc-fcf5-8b5b-bed6-1b72eaf5ecca@kernel.org> (raw) In-Reply-To: <CACRpkdbA=qZO9M=nc2mUK7Sg5ZdOzcH=x0kUQ004_+uVTQ8tCA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> On 25/08/16 22:56, Linus Walleij wrote: > On Sun, Aug 21, 2016 at 5:56 PM, Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote: > >> Sorry I took so long to get to this... >> (out of curiosity are you running a fifo queue of patches? Every time >> I review and merge one, another one turns up in my inbox :) > > Haha no, IIO is just sucking me in, it's such a nice subsystem. > >>> +The axes may also be flipped: for a screen you probably want (x) coordinates to >>> +go from negative on the left to positive on the right and (z) depth to be >>> +negative under the screen and positive in front of it, toward the face of the >>> +user. >> >> I'm not sure we don't want to define that it can't be flipped and enforce the >> correct coordinate system on the underlying drivers (fingers crossed they are >> currently all left or all right handed? - oops should have been keeping an eye on >> this). > > I'll reword. What I wante to get across was the concept of flipped axes. > > We need to keep an eye on drivers coming from the middle > east as their writing systems go from right to left, but I suspect they are > all aware of this issue. > >> For now we are being a bit simplistic as for accelerometers at least, it can be >> of interest to know the translation as well as the rotation. You can use a couple >> of them to do fairly precise rotation estimate if they are located in different >> places on a device. > > Hm the mounting matrix doesn't account for that at all. Oh well sigh, that > would be another property in sysfs the day we need to handle it. > >>> +Examples for some three-dimensional sensor types: >>> + >>> +- Accelerometers have their frame of reference >> >> Not quite right. Their frame of reference is in the frame of the device - it has >> nothing to do with the world frame which you are describing here (except when >> the device is deliberate oriented to match. > > So the core of the crux, the help I'm trying to provide, is for people > that develop sensor drivers to be able to verify that they have the right > mounting matrix. > > They need to see that the figures coming out of the buffers match to > something they can verify and thus understand that they got it right. > > Maybe this is too ambitious :( That's fine, but the trick is to explicitly say that under these circumstances the rotation matrix between the device and the world is the identity matrix (and highlight that that means it has no effect). Under these specific circumstances, the mounting matrix may be easily verified. > >> So we have 3 frames - that of the sensor, that of the device and that of the world. > > OK reworded and tried to reflect this. > > is toward the center of gravity, >>> + usually to the core of the planet, and users would likely expect a value of >>> + 9.81N upwards along the (z) axis when the device is held with its screen >>> + perpendicular to the planets surface and 0 on the other axes. >> >> I'd have thought screen parallel - i.e. z is out of the screen? >> Might be the same thing I suppose, but I'd define it simply as into the screen >> then y towards top of screen and x from left to right of the screen. > > Trying to fix up the confusion by rewording. > >>> +- Magnetometers (compasses) have their frame of reference relative to the >>> + geomagnetic field. In a mounting matrix for a magnetometer sensor the main >>> + hardware orientation is defined with respect to the local earth geomagnetic >>> + reference frame where (y) is in the ground plane and positive towards >>> + magnetic North, (x) is in the ground plane, perpendicular to the North axis >>> + and positive towards the East and (z) is perpendicular to the ground plane >>> + and positive upwards. >> >> Same issue, world to frame transform is not included... > > OK rewording, this is all about the system-to-world really. > >>> +- Gyroscopes detects the movement relative the device itself, and has no other >>> + frame of reference than the mounting chassis itself. >> >> This is true for all of them as far as we are concerned here... >>> The angular momentum is >> Hang on, where did momentum come into it from? Mems gyros are detecting rate >> of change of rotation about an axis (lets ignore the significant cross talk and >> effects of linear acceleration and pretend it's all easy here ;) >> >> Rest of this description is fine. > > Angular velocity. Sorry, just screwed it up. > >>> +Flipped X axis (negative values means positive): >>> + >>> +mount-matrix = "-1", "0", "0", >>> + "0", "1", "0", >>> + "0", "0", "1"; >> >> Hmm. This is an odd one as it basically means the device had a right hand >> coordinate system in the first place... If that happens I think we should >> by default report the negative of the scale for that axis. >> >> We've never strictly defined a coordinate system but I think left handed >> is a good start! >>> + >>> +X and Y flipped (X values are for Y and Y values are for X): >>> + >>> +mount-matrix = "0", "1", "0", >>> + "1", "0", "0", >>> + "0", "0", "1"; >> Same with this one, we are flipping coordinate systems. > > Hm you have a point. > > Those are inspired by the touchscreen input properties > Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt > as those have: > > - touchscreen-inverted-x : X axis is inverted (boolean) > - touchscreen-inverted-y : Y axis is inverted (boolean) > - touchscreen-swapped-x-y : X and Y axis are swapped (boolean) > Swapping is done after inverting the axis > > By supporting the mount matrix we open the door for augmenting > driver bugs with this. Sigh. > >> I'd expect only >> rotation matrices to be valid mount matrices. > > OK what about sensor mounted upside-down relative device: > > mount-matrix = "1", "0", "0", > "0", "1", "0", > "0", "0", "-1"; > > Sensor mounted standing on the side so X becomes Z > and Z becomes X: > > mount-matrix = "0", "0", "1", > "0", "1", "0", > "1", "0", "0"; > > Are these proper rotation matrices? Determinant = 1? Err (been a while) but using trusted wolfram alpa. Nope to the first one That's a rotoinversion. No to the second as well.. You can't end up just swapping axis. Imagine taking your thumb and first two fingers to form a 3D axis then see if you can spin it using your circus skills to match the new orientation. > >>> +Complex angular mounting with X and Z in a certain tilted orienation and >> orientation >>> +Y flipped: >>> + >>> +mount-matrix = "-0.984807753012208", /* x0 */ >>> + "0", /* y0 */ >>> + "-0.173648177666930", /* z0 */ >>> + "0", /* x1 */ >>> + "-1", /* y1 */ >>> + "0", /* z1 */ >>> + "-0.173648177666930", /* x2 */ >>> + "0", /* y2 */ >>> + "0.984807753012208"; /* z2 */ >>> This one is a rotation ;) >> >> Anyhow, now my head hurts. > > That is a real-world example from the AK8975 on some Nokia... > > Yours, > Linus Walleij > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron <jic23@kernel.org> To: Linus Walleij <linus.walleij@linaro.org> Cc: "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>, Gregor Boirie <gregor.boirie@parrot.com>, Sebastian Reichel <sre@kernel.org>, Samu Onkalo <samu.onkalo@intel.com>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org> Subject: Re: [PATCH] iio: document bindings for mounting matrixes Date: Mon, 29 Aug 2016 18:31:44 +0100 [thread overview] Message-ID: <8137ebdc-fcf5-8b5b-bed6-1b72eaf5ecca@kernel.org> (raw) In-Reply-To: <CACRpkdbA=qZO9M=nc2mUK7Sg5ZdOzcH=x0kUQ004_+uVTQ8tCA@mail.gmail.com> On 25/08/16 22:56, Linus Walleij wrote: > On Sun, Aug 21, 2016 at 5:56 PM, Jonathan Cameron <jic23@kernel.org> wrote: > >> Sorry I took so long to get to this... >> (out of curiosity are you running a fifo queue of patches? Every time >> I review and merge one, another one turns up in my inbox :) > > Haha no, IIO is just sucking me in, it's such a nice subsystem. > >>> +The axes may also be flipped: for a screen you probably want (x) coordinates to >>> +go from negative on the left to positive on the right and (z) depth to be >>> +negative under the screen and positive in front of it, toward the face of the >>> +user. >> >> I'm not sure we don't want to define that it can't be flipped and enforce the >> correct coordinate system on the underlying drivers (fingers crossed they are >> currently all left or all right handed? - oops should have been keeping an eye on >> this). > > I'll reword. What I wante to get across was the concept of flipped axes. > > We need to keep an eye on drivers coming from the middle > east as their writing systems go from right to left, but I suspect they are > all aware of this issue. > >> For now we are being a bit simplistic as for accelerometers at least, it can be >> of interest to know the translation as well as the rotation. You can use a couple >> of them to do fairly precise rotation estimate if they are located in different >> places on a device. > > Hm the mounting matrix doesn't account for that at all. Oh well sigh, that > would be another property in sysfs the day we need to handle it. > >>> +Examples for some three-dimensional sensor types: >>> + >>> +- Accelerometers have their frame of reference >> >> Not quite right. Their frame of reference is in the frame of the device - it has >> nothing to do with the world frame which you are describing here (except when >> the device is deliberate oriented to match. > > So the core of the crux, the help I'm trying to provide, is for people > that develop sensor drivers to be able to verify that they have the right > mounting matrix. > > They need to see that the figures coming out of the buffers match to > something they can verify and thus understand that they got it right. > > Maybe this is too ambitious :( That's fine, but the trick is to explicitly say that under these circumstances the rotation matrix between the device and the world is the identity matrix (and highlight that that means it has no effect). Under these specific circumstances, the mounting matrix may be easily verified. > >> So we have 3 frames - that of the sensor, that of the device and that of the world. > > OK reworded and tried to reflect this. > > is toward the center of gravity, >>> + usually to the core of the planet, and users would likely expect a value of >>> + 9.81N upwards along the (z) axis when the device is held with its screen >>> + perpendicular to the planets surface and 0 on the other axes. >> >> I'd have thought screen parallel - i.e. z is out of the screen? >> Might be the same thing I suppose, but I'd define it simply as into the screen >> then y towards top of screen and x from left to right of the screen. > > Trying to fix up the confusion by rewording. > >>> +- Magnetometers (compasses) have their frame of reference relative to the >>> + geomagnetic field. In a mounting matrix for a magnetometer sensor the main >>> + hardware orientation is defined with respect to the local earth geomagnetic >>> + reference frame where (y) is in the ground plane and positive towards >>> + magnetic North, (x) is in the ground plane, perpendicular to the North axis >>> + and positive towards the East and (z) is perpendicular to the ground plane >>> + and positive upwards. >> >> Same issue, world to frame transform is not included... > > OK rewording, this is all about the system-to-world really. > >>> +- Gyroscopes detects the movement relative the device itself, and has no other >>> + frame of reference than the mounting chassis itself. >> >> This is true for all of them as far as we are concerned here... >>> The angular momentum is >> Hang on, where did momentum come into it from? Mems gyros are detecting rate >> of change of rotation about an axis (lets ignore the significant cross talk and >> effects of linear acceleration and pretend it's all easy here ;) >> >> Rest of this description is fine. > > Angular velocity. Sorry, just screwed it up. > >>> +Flipped X axis (negative values means positive): >>> + >>> +mount-matrix = "-1", "0", "0", >>> + "0", "1", "0", >>> + "0", "0", "1"; >> >> Hmm. This is an odd one as it basically means the device had a right hand >> coordinate system in the first place... If that happens I think we should >> by default report the negative of the scale for that axis. >> >> We've never strictly defined a coordinate system but I think left handed >> is a good start! >>> + >>> +X and Y flipped (X values are for Y and Y values are for X): >>> + >>> +mount-matrix = "0", "1", "0", >>> + "1", "0", "0", >>> + "0", "0", "1"; >> Same with this one, we are flipping coordinate systems. > > Hm you have a point. > > Those are inspired by the touchscreen input properties > Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt > as those have: > > - touchscreen-inverted-x : X axis is inverted (boolean) > - touchscreen-inverted-y : Y axis is inverted (boolean) > - touchscreen-swapped-x-y : X and Y axis are swapped (boolean) > Swapping is done after inverting the axis > > By supporting the mount matrix we open the door for augmenting > driver bugs with this. Sigh. > >> I'd expect only >> rotation matrices to be valid mount matrices. > > OK what about sensor mounted upside-down relative device: > > mount-matrix = "1", "0", "0", > "0", "1", "0", > "0", "0", "-1"; > > Sensor mounted standing on the side so X becomes Z > and Z becomes X: > > mount-matrix = "0", "0", "1", > "0", "1", "0", > "1", "0", "0"; > > Are these proper rotation matrices? Determinant = 1? Err (been a while) but using trusted wolfram alpa. Nope to the first one That's a rotoinversion. No to the second as well.. You can't end up just swapping axis. Imagine taking your thumb and first two fingers to form a 3D axis then see if you can spin it using your circus skills to match the new orientation. > >>> +Complex angular mounting with X and Z in a certain tilted orienation and >> orientation >>> +Y flipped: >>> + >>> +mount-matrix = "-0.984807753012208", /* x0 */ >>> + "0", /* y0 */ >>> + "-0.173648177666930", /* z0 */ >>> + "0", /* x1 */ >>> + "-1", /* y1 */ >>> + "0", /* z1 */ >>> + "-0.173648177666930", /* x2 */ >>> + "0", /* y2 */ >>> + "0.984807753012208"; /* z2 */ >>> This one is a rotation ;) >> >> Anyhow, now my head hurts. > > That is a real-world example from the AK8975 on some Nokia... > > Yours, > Linus Walleij >
next prev parent reply other threads:[~2016-08-29 17:31 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-07-24 10:17 [PATCH] iio: document bindings for mounting matrixes Linus Walleij 2016-07-24 10:17 ` Linus Walleij [not found] ` <1469355434-17043-1-git-send-email-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2016-07-24 19:03 ` Jonathan Cameron 2016-07-24 19:03 ` Jonathan Cameron [not found] ` <06168d06-b609-a0ec-945e-aa36a4dbe795-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 2016-07-25 8:42 ` Linus Walleij 2016-07-25 8:42 ` Linus Walleij 2016-07-25 12:48 ` Gregor Boirie 2016-07-25 12:48 ` Gregor Boirie [not found] ` <57960AAF.1060103-ITF29qwbsa/QT0dZR+AlfA@public.gmane.org> 2016-07-25 13:57 ` Linus Walleij 2016-07-25 13:57 ` Linus Walleij 2016-07-26 19:07 ` Rob Herring 2016-07-26 19:07 ` Rob Herring 2016-07-26 21:01 ` Jonathan Cameron 2016-07-26 21:01 ` Jonathan Cameron 2016-08-11 11:33 ` Linus Walleij 2016-08-11 11:33 ` Linus Walleij [not found] ` <CACRpkdY0gCLKD3rmiYuFgWSYOe6dtUaBeRi1ns-UFF=AspntFg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-08-15 14:58 ` Jonathan Cameron 2016-08-15 14:58 ` Jonathan Cameron [not found] ` <c8e83cf2-f9dc-0bc9-fcde-326b05ee290b-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 2016-08-15 18:47 ` Linus Walleij 2016-08-15 18:47 ` Linus Walleij 2016-08-24 13:18 ` Gregor Boirie 2016-08-24 13:18 ` Gregor Boirie [not found] ` <57BD9EB6.1090504-ITF29qwbsa/QT0dZR+AlfA@public.gmane.org> 2016-08-24 21:29 ` Jonathan Cameron 2016-08-24 21:29 ` Jonathan Cameron [not found] ` <067a4882-c6f2-5994-e3ce-100e317ed121-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 2016-08-25 12:28 ` Gregor Boirie 2016-08-25 12:28 ` Gregor Boirie 2016-08-25 22:04 ` Linus Walleij 2016-08-25 22:04 ` Linus Walleij [not found] ` <CACRpkda-Mz0wOAXx4uoZ43OCVw0U_E0+iCrboUO_7keYV2scBw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-08-29 17:24 ` Jonathan Cameron 2016-08-29 17:24 ` Jonathan Cameron 2016-08-21 15:56 ` Jonathan Cameron 2016-08-21 15:56 ` Jonathan Cameron [not found] ` <ab89a386-dfca-bbc3-3dec-613d32d374a5-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 2016-08-25 21:56 ` Linus Walleij 2016-08-25 21:56 ` Linus Walleij [not found] ` <CACRpkdbA=qZO9M=nc2mUK7Sg5ZdOzcH=x0kUQ004_+uVTQ8tCA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-08-29 17:31 ` Jonathan Cameron [this message] 2016-08-29 17:31 ` Jonathan Cameron
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=8137ebdc-fcf5-8b5b-bed6-1b72eaf5ecca@kernel.org \ --to=jic23-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \ --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=gregor.boirie-ITF29qwbsa/QT0dZR+AlfA@public.gmane.org \ --cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \ --cc=linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=samu.onkalo-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \ --cc=sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.