Commit 3fb2f137 authored by David Preiss's avatar David Preiss
Browse files


parent 06b73a80
......@@ -4,7 +4,7 @@
This week I focused on improving data analysis (see the nicely interpolated speed-torque curves below), speeding up test times, and slogging through the endless process of finding bugs and improving repeatability.
Becuase getting an idea of repeatability involves running tests over and over again, I wound up writing a good deal of code to minimize test length. The bulk of the speed up efforts stem from the effects of the back-emf produced by the absorber as it is being spun by the test motor. If my absorber produces 10V when being spun at 500RPM, I need to overcome this voltage before I can actually start producing torque on the test motor. Imagine I am sweeping absorber voltages with 0.1V increments. Unfortunately this means that I am sweeping through absorber voltages (either actively or passively), it means I would need to sweep from 0 to 10V (100 measurements at 0.1V increments!) before I actually started producing any torque on the motor. That's why you can see a lot of points clustered at the bottom of each RPM sweep, where many of effectively the same measurement are being taken, before we have overcome the back-EMF of the motor. The code that I ultimately settled on is to measure a torque floor at the start of each RPM measurement, and then tick up the sweep counter until torque surpases the torque floor by some threshold. The associated sweep counter becomes the new starting point for the counter, so I waste less time sweeping all the way up to that counter value each time. This step saves on the order of 10's of minutes if sweeping over smaller RPM intervals, like 25 RPM or 50 RPM. What might be better (assuming I am commited to this particular brushed DC absorber motor) would be to really measure the KV of the absorber, and then actually just start PWMing at the voltage directly under the assumed back-EMF for an associated RPM. Oh well, might resort to that later, but it was late at the time and it's working now...
......@@ -16,7 +16,7 @@ I also caught an interesting bug that was manufesting as all of my torque measur
Before I mentioned the problem of back EMF creating a threshold voltage that you needed to reach in order to start generating usable torque. In the plot below you can see that really clearly, with the 3 clusters of sample points pointed at by the callout. What's happening here is that the RPM sweep begins in passive mode, so just PWMing between open and closed absorber motor windings. At lower RPM (150, 200, and 250), there isn't enough back EMF to stall the motor, so the controller switches over to active mode. When this happens, we start at PWM of 0, so we again have to sweep all the way up to a voltage that overcomes the back-EMF of the motor. At higher RPM, this transition happens at higher and higher torque, as shown in the plot below. You can also get an idea of my current repeatability between the two tests run above and below. Efficiency data is sort of all of the place, and the very coarse torque increments at later RPM result in lots of uncertainty in terms of where peak torque for a given RPM will land (despite relatively consistent data for lower RPM).
I had a suspicion that the default Arduino analogWrite's PWM frequency (about 1.8kHz for the M4 feathers) was slow enough to be on the order of cogging in the stepper and/or the absorber, resulting in weird harmonics causing early torque stalls where the torque might jump as it hits a harmonic. With some help from Jake, I switched over to routing timers and setting up PWM on the register level for the SAMD51. Despite having access to a 120 MHz clock, the prescalar and PWM resolution increments are quite coarse, so the best I could do as an improvement was getting to ~8kHz with the same 8-bit resolution. In the end I intend to switch over to 16-bit PWM resolutionm which actually takes me right back to 1.8kHz. Because the KV of my absorber is large enough that I only resolve extremely coarse torque steps at higher RPM (see the plots above), while the 256 step sweep is more than enough for lower RPM, I will need much more for higher RPMs.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment