I started to look more closely at the centripetal force equation, since I've been wary of raising the Gyrofan speed higher with its full mass, as I didn't know exactly how much force was being generated.  I'd like to ramp the thing up to get appreciable inertial stabilization, since my first test of the Gyrofan on the tether a few days ago had little effect at 360 RPM.  The equation, though, shows that I was way too conservative and underestimated the non-linear effect of RPM on centripetal acceleration. 

I also forgot that the high pitch of the sound isn't generated by the frequency of rotation but by the frequency of the electrical steps/pulse generation, which is much higher on a BLDC.

As the gyro speed increases (which increases gyroscopic stabilization), centripetal acceleration increases exponentially (author correction 1/31/2021: the equation a_c=v²/r increases quadratically with respect to velocity, not exponentially, a mistake I should have realized from my fractals and scaling class).  And since centripetal force (and the related centrifugal force) is mass x acceleration, the force increases exponentially (quadratically), too.  If you double the RPM, for example, the force doesn't double, it squares.  Doh!

The 24 steel spheres and their PETG sockets are somewhere around 5 grams each, plus or minus a few grams (heck, I forgot to even weigh them before I closed up the case!).  At 360 RPM with a radius of around 5 cm, this creates a force of only around .08 lbf (.36 N).

But at 3 times that RPM (1080 RPM), the force would go up to around .72 lbf (3.2 N), 9 times the force, since 3 squared is 9.

And at 50 times that RPM (18,000 RPM), the force would go up to around 200 lbf (888 N), 2500 times the force, since 50 squared is 2500.

So this presents an interesting situation, since the actual stabilization effect is related to angular momentum, and is not exponential (quadratic).  In other words, I have to spin it fast to get the stabilization to occur, yet the unwanted force on my wheel starts to go up exponentially (quadratically)...

I am still down in the low numbers, though, and so I tried sending a gyro 33 command to ramp it up to 1320 RPM, which applied approximately 1 lbf of force (4.8 N) around the wheel.  It runs for a few seconds, but then cuts off before I can evaluate it.  For some reason, my stall detection code is randomly activating and is shutting down the BLDC.  What is weird is that this bug occurs less often when the craft is tilted to the starboard side, and more often when tilted to the port side, but I've ruled out the accelerometer.  And I don't think this is related to gyroscopic precession, either, since it also occurs at really low RPMs.  Very odd.  So I have to review all of my gyro code (and maybe even open up the case to check for loose connections) before I can resume testing.

My BLDC code is a nightmare, by the way, mainly due to the fact that I couldn't use the 8-bit hardware timer to drive the pins directly.  I'm using them for other things, and even so, I need 3 pins for the 3-phase motor, but there are only 2.  I use the pin change interrupts to detect the 3 hall-effect sensors, but for PWM, I used the 8-bit overflow and CTC interrupts to chop the power to the coils, using software routines to changes the pin states.  And all kinds of bad things can happen:  the pin states can change while I'm trying to read their states, counter overflows can occur, the timer interrupts can occur outside of my functions before I get a chance to read them, my code might not complete before the next interrupt, etc.  There are still a lot of bugs that I need to work out.

The new ATtiny 1616 that came out last year would solve some of my problems, but I just need to improve my ATtiny 1634 code and find creative ways to handle it.  I've got the main drive motor and haptic morse detection running on the 16-bit timer, and I use the 8-bit timer for the gyro and miscellaneous functions.

When the BLDC runs at higher RPMs, every clock cycle counts, but unfortunately I do a lot of things inside my interrupts which eat up a lot of the available cycles.  For example, with 36 interrupts per mechanical revolution, at 3600 RPM, for instance, one revolution is 1/60th of a second or .016 seconds.  The CPU clockspeed that I use is 8 Mhz, so it only has 133 or so Khz for that revolution.  Split that into 36 parts, and I'm left with around 3700 cycles, used by the C compiler, per interrupt.

One way I've dealt with this is to create 3 different Gyro modes that activate automatically depending on the RPM assigned, called BLDC_LOCK_MODE (0-1320 RPM), BLDC_PWM_MODE (1360-1480 RPM), and BLDC_FAST_MODE (1520 to all out). But even in the "all out" mode, it tops out at a fairly low RPM due to my code efficiency.  So I need to add a "step-skipping" mode as well.

Once I fix this primary bug, though, I'll retest at higher RPMs and document the results.