Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Raxx]

ENSONIQ5, I know your pain. In case you may have missed it, there's a RPYtoQuaternion function in ASL that'll handle that all that nasty conversion and convert your roll/pitch/yaw for you.

Code: [Select]

point4 RPYtoQuaternion(float roll, float pitch, float yaw)
      // Compute the primary unit quaternion defined by
      // applying a roll , then a pitch, and finally a yaw
      // specified in degrees.


[ENSONIQ5]

Yeah, I know about that one, however the QuaterniontoRPY function is conspicuous by its absence.  Since I'm deriving motion from a rotating object (ie. getting the orientation value), I need to convert to RPY to run oscillations, either rotational (like a pendulum) or linear (like a sliding piston).  I'm planning to jump out to a simple project and analyse a few RPYtoQuaternion operations to see if I can work out what's actually going on before working out the reverse process, I'd love to get a handle on this since it is often used in 3D geometry to avoid 'gimbal lock' issues and I kinda feel like it's something I should know about.  One Wiki article I started to read on the subject of quaternions started to get into 'unreal numbers' (those impossibilities that equal a negative number when squared, ie x^2=-1) and I recall that it was these little $#@&s that back in high school marked the limit of my mathematical ability and interest and helped me to cross 'mathematician' off my careers options list!

[Raxx]

Ugh, sorry about the obvious reference. I've been staring at ASL for the last 12 hours

I've made my fair share of attempts to convert from Quaternions to Vectors/YPRs and back again. Only once did I get really close. It's unfortunate but it seems that for the most part it's impossible to get a 100% conversion. Or at least, that's how it's been for me.

For example, I did a quick run with this (it's a mess, sorry), and it doesn't work:

Code: [Select]

/*
From: http://www.euclideanspace.com/maths/geometry/rotations/conversions/quaternionToEuler/
http://www.euclideanspace.com/maths/geometry/rotations/conversions/eulerToQuaternion/index.htm

*/

#command("object");

file $output;
float $test, $roll, $pitch, $yaw;
quaternion $q, $qC;

$output.open("$console", "w");

/* Our beginning Roll, Pitch, and Yaw */
$yaw = 20;
$pitch = 45;
$roll = 50;

$output.print("\nStarting RPY: %.3f, %.3f, %.3f \n", $yaw, $pitch, $roll);

/* Now convert it to a quaternion using Anim8or's built-in function */
$q = RPYtoQuaternion($roll, $pitch, $yaw);
$output.print("RPYtoQuaternion: %.3f, %.3f, %.3f, %.3f \n", $q);

/* Now convert it to quaternion the hard way */
$q.w = sqrt(1.0 + cos($yaw/2)*cos($pitch/2) + cos($yaw/2)*cos($roll/2) - sin($yaw/2)*sin($pitch/2)*sin($roll/2) + cos($pitch/2)*cos($roll/2))/2;
$q.x = (cos($pitch/2)*sin($roll/2) + cos($yaw/2)*sin($roll/2) + sin($yaw/2)*sin($pitch/2)*cos($roll/2))/(4.0*$q.w);
$q.y = (sin($yaw/2)*cos($pitch/2) + sin($yaw/2)*cos($roll/2) + cos($yaw/2)*sin($pitch/2)*sin($roll/2))/(4.0*$q.w);
$q.z = (-sin($yaw/2)*sin($roll/2) + cos($yaw/2)*sin($pitch/2)*cos($roll/2) + sin($pitch/2))/(4.0*$q.w);

$output.print("Manual Quaternion: %.3f, %.3f, %.3f, %.3f \n", $q);

/* Now let's try and convert it back...*/
$test = $q.x*$q.y + $q.z*$q.w;

if ($test > 0.499) {
$yaw = 2 * atan2($q.x,$q.w);
$pitch = PI/2;
$roll = 0;
}
if ($test < -0.499) {
$yaw = -2 * atan2($q.x,$q.w);
$pitch = -PI/2;
$roll = 0;
}

$qC.x = $q.x*$q.x;
$qC.y = $q.y*$q.y;
$qC.z = $q.z*$q.z;

$yaw = atan2(2*$q.y*$q.w-2*$q.x*$q.z , 1 - 2*$qC.y - 2*$qC.z);
$pitch = asin(2*$test);
$roll = atan2(2*$q.x*$q.w-2*$q.y*$q.z , 1 - 2*$qC.x - 2*$qC.z);

$output.print("Converted RPY: %.3f, %.3f, %.3f \n\n", $roll*(180/PI), $pitch*(180/PI), $yaw*(180/PI));

/*
$RPYConverted.x = atan2(1 - 2*pow($q.y, 2) - 2*pow($q.z, 2), 2*$q.y*$q.w - 2*$q.x*$q.z);
$RPYConverted.y = asin(2*$q.x*$q.y + 2*$q.z*$q.w);
$RPYConverted.z = atan2(2*$q.x*$q.w - 2*$q.y*$q.z, 1 - 2*pow($q.x, 2) - 2*pow($q.z, 2));

$output.print("Converted RPY: %.3f, %.3f, %.3f \n\n", $RPYConverted.x*(180/PI), $RPYConverted.y*(180/PI), $RPYConverted.z*(180/PI));
*/

$output.close();


[ENSONIQ5]

Hmmm, thanks for that Raxx, gives me a good starting point for picking this thing apart.  Much appreciated.

[Blick Fang]

You guys blow my mind.      Your knowledge gives me the confidence I need, to push ahead with Anim8or.  But I am stuck on what to do next.  I need to make a mobile figure.

[ENSONIQ5]

Wow, so this took longer than I thought!  I've been busy with other projects but finally had a bit of time to return to this steam engine thing.  To work out the scripts involved, I constructed a simple engine model based loosely on the Walschaerts valve gear system (the file is attached).  All the motion of all the moving parts with the exception of the reverser lever (which would be operated by the engineer via a linkage) is controlled by scripts, with the input being derived from a moving target.

The target gets around the problem of defining acceleration in an Anim8or controller script without the ability to pass variables from one frame to the next, since the target's motion is keyframed the required motion is easily defined.  The target could be considered to be a point on the ground, with the engine driving past it, assuming the wheel diameter was correctly accounted for and it rotated the right way (which in this case it wasn't, and doesn't).  A script defines the orientation of the wheel based on the position of the target, with scripts defining the position of the linkages based on the wheel's orientation or the position of other elements, such as the reverser lever.  In some cases, linkage orientation is defined using the 'facing' function.  So to change the speed or overall motion of the engine it is only necessary to change the animation of the target and the reverser lever, with all elements maintaining their mechanical interaction with each other.

The scripts involved are too complex to list here, they can be dug out of the an8 file if you're interested in seeing how they work or modifying them for other projects.  I have kept my (reams of) notes and geometric calculations and should be able to explain what each script is doing.  I hit a major hurdle related to the ambiguous triangle problem with sine rule geometry (used to calculate the position of the valve linkage in the reverser gear), I very nearly walked away from the project but luckily had a bit of a brainwave (while on the dunny...haven't we all!) and it all came together tonight.  Feel free to fiddle with it, just remember that there is no actual collision detection between elements so it is possible to set the reverser to a position that would be impossible in real life, with potentially weird results.

The plan is to refine the scripts for use with the Stephenson valve gear used on the paddle steamer engine, so I can finally get the beast to run.  Fingers crossed other projects stay quiet for a bit, otherwise it could be another year until the next update!

[Raxx]

Hey ENSONIQ5, that is friggin' awesome. I wish I thought of that, haha. Keep it up, can't wait to see more!

[ENSONIQ5]

The scripts are (more or less) done, at least on the near side of the engine.  The screen cap below shows the nearside gear running and the lack of keyframes, only the target object that drives the action and the gear selector shaft ('GSS') are keyframed.  All other motion is the result of scripts based on the location of the target object and the orientation of the GSS.  Unfortunately the engine's running isn't really correct in the sense that the rotation etc. happens regardless of the gear selector's position, I would have kinda liked all the action to be the result of the GSS and the orientation of a steam valve lever but without the possibility of running variables I don't think it's do-able.

The scripts are not quite perfect regarding the position of the valve rod and the location/orientation of the main gear selector object, I fear the maths involved in getting it absolutely perfect is beyond me.  The problem is that the orientation of the object affects its location, which affects its orientation, which affects its location, etc. ad infinitum.  This has a nasty 'calculus' stench to it!  Perhaps I'll re-visit the scripts with this type of approach at a later date, for the moment the scripts are based on basic geometry and while not perfect they are, I think, good enough to be going on with (perhaps some of the bearings are just a little bit worn!).

The modelling is not complete, I need to add the steam pipes, valves, gauges and of course the gear selector lever before attempting fire and smoke and rendering it out.  I am glad that the thing runs though, the Stephenson gear is WAY more challenging to script than the test Walschaerts system.

[ENSONIQ5]

Moving parts replicated to far side of the engine and some more modelling done (gravity and pressurised oilers).  More modelling to come and some tweaks required to the scripts.

[johnar]

 Man, that is is absolutely awesome.
 And as, Blick Fang said,

mindblowing

.
 Speechless really. Extremely Well done

[ENSONIQ5]

Cheers Johnar.  I came close to walking away from this many times, it's satisfying to see it running.  Hopefully I can "finish" it (if any project is ever truly finished)!

[nemyax]

IK would make this setup a piece of cake.

[ENSONIQ5]

Hmm, maybe, at least in some places.  Most IK setups I've seen are strictly hierarchical in the sense that 'tree-like' structures can be created, but not closed loops.  Child objects can influence parent objects through the IK chain, but you can't have looping chains or multi-anchored chains which this rig would require, as far as I know.  What would make it simpler would be a physics engine that incorporated collision detection, then simply rotating the crank would generate the required motion in the linkages etc.  I've done this sort of thing before in packages that included physics (Cararra) but I kinda wanted the challenge of doing this entirely in Anim8or and rigging it so the animation could be easily changed without re-keyframing everything, which means scripts.