Talk:Charts on SO(3)

Suggestions

 * Section header added. —Nils von Barth (nbarth) (talk) 21:13, 28 June 2010 (UTC)

Euler angles are z-y-z. Tait-Bryan (aka Cardan aka nautical) angles are x-y-z. These latter are often called "Euler angles", and somewhere mention of this confusion should be made, but it should not be presented as anything "correct" or "official".

Cayley rational parameters are in Weyl The Classical Groups. The reference should go in the C.r.p., not here.

The skew-symmetric matrices themselves form a chart near the identity. Their exponentials are the orthogonal matrices, so the previous version was just a complicated way of saying SO(3) parameterizes SO(3).

Another parametrization to list is to treat SO(3) as the manifold that it is -- real 3-dimensional projective space. This is elaborated on in https://arxiv.org/pdf/1005.4661.pdf. Normvcr (talk) 06:21, 18 December 2019 (UTC)

Conversion between quaternions and Euler angles
Should it be merged to here as a special case without a particular notability? Incnis Mrsi (talk) 16:18, 30 August 2011 (UTC)

It's all so wrong (EditMe)
It's all really so much simpler in Euler Axis (Not Euler Angles) is so much easier to convert to and from rotation matricii and Quaternions; and this is entirely ommited.

There should be a section on 'Successes in parameterization'

Axis-Angle $$(\theta,(x,y,z))$$ combined to $$(x\theta,y\theta,z\theta)$$ and used as Euler Axis with Rodrigues' Rotation Formula applied to axis-angle.

https://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation#The_composition_of_spatial_rotations

Although that section is on a page of quaternions, it doesn't have a lot to do with quaternions, since the input parameters are immediately A-axis-angle and B-axis-angle, where the axis is a normalized direction vector indicating the axis of rotation, and the angle is the length-scalar of as a separate term; this doesn't change that it's really a 3D value into a 4D value.

https://en.wikipedia.org/wiki/Rotation_formalisms_in_three_dimensions#Rodriguez_Rotation_(Rotation_Composition) This version is closer to accurate.

I've been playing with (x,y,z) rotations for a while now, this demo shows the flat double-cover representation of the rotation space, which does not overlap itself when represented this way. https://d3x0r.github.io/STFRPhysics/3d/indexSphereMap.html It's really a very direct representation of the projection of the rotations. Any point is just an axis and a length to determine the spin around that axis - like having a gyroscope centered at the origin, it's axle of rotation aimed along a line, and the angle, an amount of turn of the rotor, only instead of the rotor moving all the points around it are translated... leaving all the points on the line itself untransformed.

No stereographic projections... although, it's obvious that something mobial (or of a mobius) might be a good parameterization, as the points turn in space around a mobial path... but it's inobvious that it's probably a red herring since it's already in a natural form as X,Y,Z coordinates, which are coincidentally in the same X/Y/Z direction as linear transformations.

But, if I'm really the only person in the world to know this, I should really try showing everyone else they already had all the tools to put this together.

The singularity at (0,0,0), when projected to rotations sort of has to be handled; it's technically possible that every axis of rotation is valid, but the change around that axis is 0 degrees, so there is no change anyway, so the direction really is free to be whatever you need it to be. Composing directly as axis-angle never has this issue, since the (x,y,z) format is just the briefest notation, computationally, what is needed is the normal and angle, and rarely are the combined values used. An axis being defined as a unit vector can never be zero. The point at the origin results with no change, and is Identity, (not a singularity?).

Latitude and Latitude are enough to specify a normal to a sphere, which will be called 'up', but does not define the orientation around that 'up'... naive calculations will of course result with An orientation, and it is deterministic, but it's not a good 'base'. Once the 'up' is found, the first step is to normalize that, such that the 'forward'(z) and 'right'(x) basis vectors are aligned with the longitude and latitude lines respectively; this involves applying the Rodrigues Axis-angle rotation from the quaternion page. From this aligned basis, an additional spin can be applied as a parameter to define the frame, resulting in (lat,long,spin) coordinates for the frame; reversing from axis-angle to this as been challenging, involving arccos and arcsin which results in a limited range of outputs.

Parameterization of extended (latitude, longitude, spin) can be accurately translated to axis-angle for a range of -2pi to 2pi on each parameter. The latitude 0 results in a direction vector that is 'up' perpendicular to the first pole, and the longitude defines how that will spin around that point, and is effectively the same as 'spin' on each pole. Other than where the gimbles are in a common direction some times, the full topology of the curve can be walked using axis-angle... this isn't a single-covering parameterization, but is able to completely cover the space at least once.

For purposes of expressing a direction, the two (latitude, longitude) coordinates can compactly identify this... it simply translates to `(lat*cos(long),0,lat*sin(long))`, or `lat, ( cos(long), 0, sin(long) )` in axis-angle form.

D3x0r (talk) 05:11, 5 April 2021 (UTC)