punt punt punt
…
a few days ago on the facelolz i said that
It’s now conclusive that I do not ask enough questions when I get stuck on things, and that this is unacceptable as it will impact my work performance. (I theorize that this ask-questions problem is why I am so mediocre at school).
Therefore, my goal for the next two weeks is to ask at least five dumb but coherent questions a day, and as proof of that I will write the answers up on my blog.
(I am still thinking a bit as to whether this casual-question-asking will actually translate to me asking more questions when I feel like people expect me to know more than I actually do).
So! then i asked questions. turns out most of the questions were so silly they don’t even merit writing down and/or I’ve completely forgotten them. But here today I’m writing down some notes on controls courtesy of Shane with mock-quadcopter demos by Charles (not duplicated here).
some of those questions were silly questions like how do i do controls in real life, as opposed to in labview on a $10,000 national instruments card.
then my brain went “speaking of things i want[ed] to do consistently to improve on skills…”
 |
| src files. wacome graphire4 4×6, inkscape, gimp. crashlanding, caeldera, digitalstrip2 fonts from blambot. ~4.
|
the theory behind both is the same, ignore current incompetence (flaunt it? sorry, internet, for adding to the general scuz of atrocious material) and focus on learning learning learning to get to where i want to go…
(credit to MITERS folks for creative inspiration, including conversations with Dane about post-apocalypticc robot boxcar somethings.).
hmm. Right. controls.
Say I have a quadrotor. How would I go around implementing controls for it?
e.g. in 2.737 mechatronics class, we use a
digital signal analyzer to characterize the plant. But no one tries to do that to their quadrotor. One possible way: mount quadrotor on stick, rotate it along one axis at a time. But, in real life:
Generally
PD controllers.
If you didn’t know that, you could model it as a mass and damper (really simple model). Small number for damping (only comes from moving through air, minimal), e.g. damping coefficient of 0.1. Don’t know distribution of mass along quadrotor axis, so just model as evenly distributed — really does not matter since will end up tuning gains empirically anyway.
Proportional controller is like a torsional spring. Bigger error, bigger control effort.
Derivative controller is like additional damping. Otherwise, with proportional controller will correct for error but then due to lack of damping will oscillate.
Start out with too little gain, because then it will fly but drift off to the side. With too much gain, it will oscillate and flip over. Then slowly increase P gain.
Converging on the gains — a common method is
Zieger-nichols. General idea is to up the P gain until it just begins to oscillate. Now up the damping (D gain) until compensate for oscillation, use some magical constants, … that sort of thing.
PD fine for flying indoors. But outdoors, wind will cause constant offset. Need I[ntegral] term. Also helpful if one motor is weaker than others, other sources of constant error.
Bandwidth and sampling frequency.
Limitation: how fast can control code loop run on microcontroller (mcu). Mcu has system clock (16Mhz for atmega’s). Rule of thumb, +-* each operation 1 clock cycle. Dividing integers four clock cycles. Floating point, tens of cycles. More margin because processor will need to respond to interrupts. This is upper bound on sampling frequency.
Lower bound, well, only need to respond to user input, and human reaction time perhaps 0.5 secs, 20 Hz. But also want to reject higher frequency noise e.g. from wind.
If calculate these and not overlap, need more efficient code or more powerful processor.
Tuning gains — actually pilot dependent. Some people like higher gain despite closer to instability because will respond quicker to sudden turns. While people shooting video will want higher damping so that footage is smooth, okay to more slowly respond to errors in position.
Segging things are like quadrotors but with one axis instead of two.
A lot of ATmega AVRs can run at speeds up to 20 MHz, including the popular ATmega328P. It’s just that 16 MHz is really popular because most Arduinos use it. I’m not sure why they were designed that way, but there are a lot of parts of the Arduino design that just don’t have a reason.
Hmm! That is good to know, thank you. I was curious and according to the arduino forums it is a historical — 16 MHz is the atmega8 top cpu clock speed. (http://arduino.cc/forum/index.php/topic,27599.0.html)