So previously we had gotten field-oriented control more or less working - the next step was to get it reasonably stable, thereby reducing the number of firmware-induced injuries during vehicle testing and the number of dollars spent on replacement bricks.
What is FOC?
FOC (Field-Oriented Control) is a real fancy name for some operations to make current control on a motor better and easier. In math this would a coordinate transform and a rotation, but here in EE land they are given the names "Clarke Transform" and "Parke Transform" and are associated with some mystical hexagram or the other, but I digress...
The inspiration for the transforms comes as follows:
Suppose two of the phase currents with respect to electrical angle are
The Clarke Transform computes
The Parke Transform further computes
Because these values are DC, the loop no longer needs to run fast enough to sample the sinusoid. Furthermore, Id and Iq are related to the torque produced by the motor and the physical characteristics of the motor, which allows us to directly control and optimize torque generated by the motor for improved efficiency.
The loop worked alright, but under heavy load there were strange clunking noises which happened at around 6Hz, as the plot below shows
There wasn't anything evident in the firmware that was running at 6Hz...
Turns out the clunking was happening due to internal overcurrent shutdown on the brick, which brought up the question why the internal overcurrent cutoff was tripping on our fairly low current set point. Then we remembered the current sensors weren't actually calibrated in the firmware...turns out they were off by a factor of 7 or so.
With the gross miscalibration taken care of the next step was to improve the loop response to allow for higher set points before transients caused the overcurrent protection to trip. Adding some manual low-passing on the throttle and dropping the gains by a factor of 100 or so more or less seemed to fix it (the former is probably equivalent to the latter but as the gains were quite low I was concerned about precision issues with the single-precision floats we were using for the math).
The controller seemed to work at 300A - sadly performance of the vehicle was quite poor in the torque department. We checked our math, and discovered our gearing was off by a factor of 3 or so. One new sprocket later...
|Such waterjet wow|
...we decided it was time to for more volts. We soldered up a horrifying 120S3P pack:
One Last (?) Bug
There were a whole bunch of reasons why the controller could be failing: loop instability, electrical noise, outright errors in the code, some latent hardware issue that we had yet to think of, etc.
First we ruled out loop instability: the output of the loop (green below) was more or less pristine:
We ran some tests with different gains and such to try to get an idea of what was going on, but none of those proved to be too productive. Then we had the bright idea to remove the back wheel for some high-speed, no-load testing, upon which it was immediately revealed that the controller wasn't capable of spinning the motor past a few thousand RPM period, regardless of the load.
This pointed to a phase issue - any phase offset in the sensors would show up as phase offset in the motor position, which would cause all the assumptions of FOC to be violated and make the actual phase current go way up. Because the analog hall sensors had output amplifiers with a 17KHz -3dB point, it was reasonable to assume that the phase lag of the amplifier was nonzero even at a couple KHz.
And indeed, tweaking the phase seemed to improve the situation, but I'll leave the excellent results of that for the next post...