From: Gregor Boirie <gregor.boirie-ITF29qwbsa/QT0dZR+AlfA@public.gmane.org> To: "linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> Cc: 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: Thu, 25 Aug 2016 14:28:59 +0200 [thread overview] Message-ID: <57BEE48B.5020408@parrot.com> (raw) In-Reply-To: <067a4882-c6f2-5994-e3ce-100e317ed121-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> On 08/24/2016 11:29 PM, Jonathan Cameron wrote: [snip...] >>>> + >>>> +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). >> As to coordinate system definition, multiple conventions seem to exist across >> industries. For UAV, we use the one described here: >> https://en.wikipedia.org/wiki/Flight_dynamics_(fixed-wing_aircraft) >> >> So I feel like we should keep away from any temptation to define the coordinates >> system too strictly. >> I also think of systems composed of multiple hardware parts with sensors >> scattered all over them. What would be the right "device/main hardware" reference >> frame definition in these cases ? >> As this is product specific, I feel like "device/main hardware" reference frame >> definition should be left to the "board/main hardware/device..." implementor's >> choice. > Flexible is good, but I think we should define a base rule for the chips frame > of reference and fix up any that disagree (which is nasty ABI breakage :( We might as well expose another property to userspace to indicate coordinates system convention currently in use. This seems overly complex to me but might ease portability across platforms and products. I have no clear opinion on this. Anyway, DT / BSP maintainer would always have the ability to customize mounting matrix values on a per-product basis to fit their application expectations. E.g., from Parrot's UAVs perspective, flight control stack expects coordinates system to be defined according to aeronautic convention (hardcoded). Even if DT required a strict definition of coordinates system, this would implies no changes to rotation matrix values currently set into our DTs... > Trivial choice of either right handed or left handed frame might be all we > define in general. Useful to define consistent frames for device types that > are common perhaps as well. (such as the screen ones Linus has here). It seems most common definition is what is described here: https://www.w3.org/TR/2016/CR-orientation-event-20160818/ and here: https://developer.android.com/guide/topics/sensors/sensors_overview.html#sensors-coords given that Android devices represent a fair amount of phones and tablets in use. Searched for IoT related things but no clear conventions came out... And I can't think of PC world as a reference for this kind of stuff. Yours, Greg.
WARNING: multiple messages have this Message-ID (diff)
From: Gregor Boirie <gregor.boirie@parrot.com> To: "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>, Linus Walleij <linus.walleij@linaro.org> Cc: 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: Thu, 25 Aug 2016 14:28:59 +0200 [thread overview] Message-ID: <57BEE48B.5020408@parrot.com> (raw) In-Reply-To: <067a4882-c6f2-5994-e3ce-100e317ed121@kernel.org> On 08/24/2016 11:29 PM, Jonathan Cameron wrote: [snip...] >>>> + >>>> +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). >> As to coordinate system definition, multiple conventions seem to exist across >> industries. For UAV, we use the one described here: >> https://en.wikipedia.org/wiki/Flight_dynamics_(fixed-wing_aircraft) >> >> So I feel like we should keep away from any temptation to define the coordinates >> system too strictly. >> I also think of systems composed of multiple hardware parts with sensors >> scattered all over them. What would be the right "device/main hardware" reference >> frame definition in these cases ? >> As this is product specific, I feel like "device/main hardware" reference frame >> definition should be left to the "board/main hardware/device..." implementor's >> choice. > Flexible is good, but I think we should define a base rule for the chips frame > of reference and fix up any that disagree (which is nasty ABI breakage :( We might as well expose another property to userspace to indicate coordinates system convention currently in use. This seems overly complex to me but might ease portability across platforms and products. I have no clear opinion on this. Anyway, DT / BSP maintainer would always have the ability to customize mounting matrix values on a per-product basis to fit their application expectations. E.g., from Parrot's UAVs perspective, flight control stack expects coordinates system to be defined according to aeronautic convention (hardcoded). Even if DT required a strict definition of coordinates system, this would implies no changes to rotation matrix values currently set into our DTs... > Trivial choice of either right handed or left handed frame might be all we > define in general. Useful to define consistent frames for device types that > are common perhaps as well. (such as the screen ones Linus has here). It seems most common definition is what is described here: https://www.w3.org/TR/2016/CR-orientation-event-20160818/ and here: https://developer.android.com/guide/topics/sensors/sensors_overview.html#sensors-coords given that Android devices represent a fair amount of phones and tablets in use. Searched for IoT related things but no clear conventions came out... And I can't think of PC world as a reference for this kind of stuff. Yours, Greg.
next prev parent reply other threads:[~2016-08-25 12:28 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 [this message] 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 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=57BEE48B.5020408@parrot.com \ --to=gregor.boirie-itf29qwbsa/qt0dzr+alfa@public.gmane.org \ --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@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.