I missed the last status report, so this will just be a big one with everything, sorry Charles. In the past two weeks, we received and assembled the spookpower and spooktroller boards, and did basic testing of them. So far, they are without any problems. Once we exercised all of the basic peripherals, like the 3 phase pwm generation, adc triggering, and UART, I ported over the janktroller code. It didn’t work for a while because the faster control loop that we were able to run on spooktroller seems to make it more sensitive to everything being tuned just right, but during the many hours of debugging I’ve gotten much better intuition into what parameters need to be adjusted together to keep everything working.

We have been running the medium sized motor with the electric boogaloo (spooktroller and spookpower assembled together) to start getting an idea of how it handles the bigger motors. More importantly, the bigger motors are actually wound sinusoidally, while the motor we used last was trapezoidal. This technically means that they should be much better for a flux observer based estimator, which was part of the reason we made that design decision, but the testing with janktroller showed that isn’t too critical.

I have been able to get the electric boogaloo spinning the medium motor at up to ~1300rpm, which is where the control loop currently starts to loose control and draw a ton of excess current. One of the biggest things that enabled that was just writing a very simple control loop to modulate the commanded iD current, which effectively implements field weakening. One odd thing is that it seems in most literature field weakening is just in effect or not, but in our case it just made it always modulate the commanded iD to try and keep the sensed iD at about zero, and it seems to be strictly better (draws less power for the same speed, more stable speed response, etc.).

From here, I’m trying to make the startup as robust as possible. I think that it is ok for it to just blast a ton of current into turning the motor at a predefined speed, accelerating it until the estimator magnitude is large enough for that to take over. I’m also trying to actually implement the tests that we need in order to verify all of our performance metrics, which involves trying to spin the motor “backwards”. Right now, it can only turn in the direction that the controller thinks is forwards. It is likely because we have some estimator offsets set poorly, so I’ll try and take some time to dial those in to the neutral position so i can try the 1000rpm -> -1000rpm test.

I also majorly restructured Rotaté so that now it features 4 graphs and is all around more easily configurable and useful. It has already proven to be extremely valuable in validating run performance of the motor, especially because you can’t set useful breakpoints on a spinning motor.