Mirabile dictu, I think I’ve managed to establish a workaround. Have a
.blend (984.0 KB)
Mind you, it’s a workaround. It only seems to work, but doesn’t actually correct for the underlying issue. You can still get things flipping backwards if you’re not careful.
The two main issues are Gimbal Lock (or how Blender copes with it), and the fact that you want the innermost piece to act semi-independently of the outer frame, so everything in the middle is sort of serving two masters.
Given that the previous thread discussing this issue suffers from broken links and missing image files, I’m going to go through the setup in painful detail below. Fair warning.
First, let us establish the “anatomy of a gyroscope,” courtesty Lucas Vieira of Wikimedia:
What I did:
Model the Frame and Gimbals such that they are NOT locked. Establish your outer frame, rotate the outer Gimbal 90 degrees along its rotational axis, and rotate the inner gimbal 90 degrees along its rotational axis relative to the outer gimbal.
That step tripped me up, because I originally modeled everything as a flat series of rings. I basically made the most locked up gimbal you possibly could, which made everything afterwards more difficult.
If that’s hard to follow, I’m saying, “model it so it looks like the picture above,” adjusted for whatever hierarchy of axes you prefer. VERY IMPORTANTLY, make sure you APPLY ROTATION to all three rings and the central Rotor.
Before you get into parenting and constraints, we need two empties. Place the first empty at the very dead center of the rotor (which, if everything else is symmetrical, is the very center of all other meshes too). I’ll call this the Core.
Place the second empty outisde the Outer Frame, dead center on the Rotor’s Spin Axis (see image above). I’ll call this the Pointer.
Parenting:
Outer Frame: No parent. You’re meant to end up using this to move and reorient the “whole thing” around in space.
Outer Gimbal: Parented to Outer Frame
Inner Gimbal: Parented to Inner Frame
Rotor: Parented to the Core.
Core: No Parent.
Pointer: No Parent.
Constraints (listed as stacked):
The proper configuration of your constraints will vary according to how you designed your gyroscope. What follows assumes your build matches the photo above while at rest.
Outer Frame: None.
Outer Gimbal:
Locked Track: Target Pointer. Track Z. Lock X
Limit Rotation: Y and Z (Min/Max 0). Owner is Local Space.
Inner Gimbal:
Locked Track: Target Pointer. Track Z. Lock Y
Limit Rotation: X and Z (Min/Max 0). Owner is Local.
Rotor: No Constraints
Core (Empty):
Child Of: Target Outer Frame. UNCHECK all Rotations.
Damped Track: Target Pointer, Track Z.
Pointer (Empty):
Child Of: Target Outer Frame. UNCHECK all Rotations
Drivers:
Rotor: Rotation Z = frame* x (where x = speed)
This frees up the Rotor to “Spin” without affecting orientation for any other parts of the Gimbal, and makes life easier if you need to do something to it.
Now you have two separate controls for your Gyroscope. The Outer Frame is the direct manupulator. Tranlsate and Rotate XYZ anywhere in your sceen, and the central Rotor should not be visibly affected by it.
The Pointer Empty, then, allows you to manually reorient your Rotor if you don’t want it pointing in its original direction. It wouldn’t be physically realistic to change that direction over time, but options are good to have.
Here’s an animation test of the finished result. I’ve lopped the Gimbals and Rotor in half, and added little glowing points to them so you can see that they don’t spontaneously flip or reorient. I also parented a little emitter to the Pointer empty so that can be observed as well.

About that Gimbal lock…
I never allow the Pointer to become centered directly over head of the core, which is where it was when building and constraining everything.
That point causes a lock, and I supsect if you imagine the five other “cardinal points” (direct below, direct in front/behind, directly to either side), they would too.
If you downloaded my Blend, you’ll notice a third Empty I never mentioned, because it’s optional. I put a “Reference” point dead center on the Z axis directly above the Core. I then put Limit Distance constraint on the Pointer, set to Outside, targeting the Reference.
That prevents the Pointer from landing on or passing directly into the lock. It’s not a flawless solution, but seems to work well enough. Replicate it for each of the “cardinal points,” and you would at least avoid those most obvious locking points. If other locking points exist (since there are two Gimbals, not just the one), you’d have to find a way of keeping the inner gimbal clear of them, which is overkill on top of overkill.
I sincerely hope this helps someone at some point in the future when all my links and images are broken…