After we completed our first full version of code we spent several days in the lab trying to fine tune our PID terms. After a lot of frustration, we decided to take a look at the quadrotors in Penn's GRASP lab as a comparison. After feeling their PID response, it was painfully obvious that our response time was not nearly as fast as we thought it was. The GRASP lab units run their full PID loop at 1000 Hz. We thought that we were running our PID loop somewhere around 40 Hz, and, being a little naive, we thought this would be adequate. After all, we can't see that fast!
In order to increase our code efficiency we did several things. First, we increased the UART baud rate from the IMU to the MaEvArM from 38,400 to 250,000. This allowed us to read in angle and gyro values faster so the PID functions didn't hang up waiting for information. Second, we changed some while loop codes in the UART receiving functions to brute force assignments. This had an amazing effect, changing our 40 Hz response to 120 Hz! Of course, this was not nearly as fast as the response in the GRASP lab, but, having read reports of successful PID loops as low as 70 Hz, we thought we'd give the new code a try.
The difference was incredibly clear; the derivative terms were much more responsive, and our morale was much improved after fruitlessly toying at PID gains for so many days.
After this, we constantly checked the frequency of our PID loop after adding any new considerable block of code. Also, the bottleneck for increasing our code speed was determined to be the output of the IMU. Running the DCM and correction algorithms produced a max speed of 120 Hz. One possible method to increase this (without changes in code) would be to replace the 8 MHz oscillator on the Razor IMU with a 16 MHz or even a 20 MHz oscillator. The Atmega328p is able to handle these clock speeds, and increasing to them would result in large improvements in the data output speed.
Moore Display Case
6 years ago