That could easily be my mistake. First, there are a variety of conventions for handling euler angles, and I've yet to find a presentation which both gives numeric examples and a geometric explanation which I am happy with.
The reason conventions come into play are: [A] We have to choose between left handed and right handed rotations [B] We have to choose the which rotation comes first, and which comes last. But I have decided that I did not like the reference I used for the basis of my previous post. Here's my current "best implementation": rotmat=:verb define 3 3$(2 1 o./ (,-)y) 4 8 5 7}&,=i.3 : (,~x)|.rotmat y ) rotate=:verb define assert. y=0 0 0+,y +/ .*/|.0 1 2 rotmat"0 y ) Now, whether I can find the name associated with this particular convention, I'm not sure. Nor am I sure I want to stick with this particular convention (I am using euler angles, after all, because someone else was using them). But at least I can convince myself that my angles in some way represent rotations about each of the three axes. I guess I need to spend more time figuring out the coordinate system details corresponding to the code that I'm reading (which, oddly enough, my previous post tried to emulate - but that does not mean that that code was working properly). Thanks, -- Raul On Sun, Jul 10, 2016 at 2:55 PM, Brian Schott <[email protected]> wrote: > The following may be of some help, but I notice that my results are > slightly different from yours with regard to with yaw and roll type > rotations. Our "pitch" rotations seem to agree. The difference seems to be > mostly in the definition of my ry0. These are all taken from my turtle > graphics for j (tgfj) development. > > > load'trig' > > I3 =: =@i. 3 > i3 =: I3"_ > > rx0=: (cos,sin),:(-@sin,cos) > ry0 =: (cos,-@sin),:(sin,cos) > ry0 =: rz0 =: rx0 > > 'RlRow YwRow PtRow' =: i. 3 > AllRow =: i. 3 > PtPlane =: 1 2 > YwPlane =: 0 1 > RlPlane =: 2 0 > > bip=: <"1@(,"0/~) NB. Table of boxed index pairs > bipx =: (bip PtPlane)"_ > bipy =: (bip RlPlane)"_ > bipz =: (bip YwPlane)"_ > > rx=: ''&(rx0@]`bipx`i3})"0 > ry=: ''&(ry0@]`bipy`i3})"0 > rz=: ''&(rz0@]`bipz`i3})"0 > > ptRot =: rx > rlRot =: ry > ywRot =: rz@:- > > ywRot 0.05p1 > 0.987688 _0.156434 0 > 0.156434 0.987688 0 > 0 0 1 > ptRot 0.05p1 > 1 0 0 > 0 0.987688 0.156434 > 0 _0.156434 0.987688 > rlRot 0.05p1 > 0.987688 0 0.156434 > 0 1 0 > _0.156434 0 0.987688 > > > On Sun, Jul 10, 2016 at 1:43 PM, Raul Miller <[email protected]> wrote: > >> I need a routine which makes rotation matrices for a given angle. >> >> For example, let's say that my angle is 0.05p1, I would be wanting >> these two rotation matrices: >> >> 3 3$(2 1 o./ (,-)0.05p1) 0 4 1 3}&,=i.3 >> 0.987688 0.156434 0 >> _0.156434 0.987688 0 >> 0 0 1 >> >> and >> >> 3 3$(2 1 o./ (,-)0.05p1) 4 8 5 7}&,=i.3 >> 1 0 0 >> 0 0.987688 0.156434 >> 0 _0.156434 0.987688 >> >> Now, obviously, I could implement this directly: >> >> rotmat=:dyad define >> 3 3$(2 1 o./ (,-)y) (0 4 1 3+4*x)}&,=i.3 >> ) >> >> But it seems to me that there ought to be a better way of doing this. >> And by better I mean more concise and direct. >> >> But I'm not seeing that. >> >> The best alternative I have thought of so far is: >> >> elcric=:dyad define"0 >> if. 1<|y do. >> (_2+|y) o. x**y >> else. >> y >> end. >> ) >> >> rotmat=:dyad define >> (1 1-x) |. y elcric 1 0 0,0 4 3,:0 _3 4 >> ) >> >> And while maybe that satisfies some concept of "prettier" it is not >> more concise and it is not more direct. It is not even faster. >> >> That said, what I really want to build would be this: >> >> rotate=:monad define >> +/ .*/ 0 1 0 rotmat"0 y+0 0 0 >> ) >> >> (I threw in the unnecessary +0 0 0 to emphasize that I expect three >> angles.) >> >> In other words, I have three different euler angles and I want the >> rotation matrix they represent. So maybe there is even something >> already implemented for this purpose? (But when I search jsoftware.com >> for mentions of euler angles, I don't see anything promising.) >> >> Any ideas? >> >> Thanks, >> >> -- >> Raul >> >> P.S. I imagine I could live with getting the rotation quaternion they >> represent, instead of the rotation matrix. But I have not investigated >> the details of that approach here. >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm > > > > > -- > (B=) <-----my sig > Brian Schott > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
