We’re getting close, and I’m (Its Matt by the way!) way overdue for a blog post. We had winter break at the end of december, and as seen in the previous vid the copter is now assembled and flight ready. All that really remains is the control software.
On that front, I’ve made good progress. The copter is now running under my own RTOS, which has been helpful in keeping the various flight tasks, like IMU updates, remote control, and logging running simultaneously. Over the break I started by finally putting our EEPROM to use and wrote a program to simultaneously logged sensor data and allow raw control of the motors, and used it to capture this:
Roll kalman filter graph on live data
The motors add much higher frequency noise than my hand tests, but the filter aced it on the first run (Edit: unfortunately, this test was with the motors at what was at the time the safest indoor speed. The filter has a much more difficult time at actual flight velocity :/) With that test out of the way, I proceeded to getting the PID loops up. Theres not much to say about the PID loops other than I had and still mostly have no idea how to tune them except by guess and check, but I eventually got this video up after roughly 3 hours including coding the loops:
This video was of the very last tweak-test cycle I got before the ESCs engaged their low voltage cut off.. oops! With continual very light usage over the past month it was very difficult to accurately time battery life, but we’ve included a battery monitor circuit in the controller board I still haven’t found time to write code for that should fix this problem in the future. Anyway, though the PID loop is clearly functional it definitely needs more work to get the reaction time lower and get rid of oscillations. Probably means I need more P and D, but I learned quickly that its easier to slowly improve performance by going in tiny increments rather than make large increases which often lead to degenerate control loops. I’m definitely looking forward to taking a control theory class though and learning how this kind of thing is best optimized and maybe even calculated offline!
This week is exam week, which of course means plenty of time for quadcopter coding since no homework! (just kidding.. I studied my tail off). But we’ve got a four day weekend that I’ve begun to term “Do or die” weekend. We’re very, very close to an actual flight and I’ve decided this weekend will be it. I’ll probably do one post every day if I don’t get terribly destracted, but heres what we still need to accomplish:
- Better PID response for roll and pitch axis
- Tune a yaw PID loop (not too sure how this will work, perhaps will test it while doing hopping-hovering once the roll and pitch are controlled)
- Make our landing gear (looking like pool noodles, if we can find one in january!)
This will take us to manual throttle flight, which will work but be difficult to work with on the vex controller especially. The goal is for an automatic throttle, and the vex stick controlling velocity. That way, all sticks level should produce a stable hover. To do this though, the copter needs to know how high it is and we need another control loop.
The altimeter was originally purposed for this, but I had some trouble using it. It has an EEPROM, which contains some nice factory calibrated sensor coefficients to use in some formulas to calculate air pressure. However, this EEPROM has the same address as our own EEPROM, which does make one wonder how we were able to successfully use our EEPROM with the altimeter sharing the bus. However, when removing our eeprom and downloading the altimeter’s, I was unnable to find any coefficients where they were supposed to be, just 0s. I do repeatedly find some data on a different part of the EEPROM that is unspecified in the datasheet, but it doesn’t line up with what the coefficients should look like. So three potential reasons for this: A, we somehow corrupted the altimeters write-protected EEPROM while writing / using our own EEPROM (I don’t see how this could happen), our sensor is a dud/not calibrated (It was a cheap part from a cheap chinese manufacturer..), or my I2C code is somehow to blame (possible but I’ve taken time to look at it, and our EEPROM works fine). Unfortunately I’m currently forced to go with dud. :/
The altimeter is fortunately not our only altitude sensing device. We had already planned to use an ultrasound sensor for landing and low altitude flights. We’ve used these sensors in Botball at ranges of 5 inches to 3 feet or so, but we know they work pretty well out to about 4 or 5 feet. Above that, it may be possible to use the GPS reported altitude. Double integration of the accelerometer is theoretically possible, but it doesn’t seem likely to actually work all that well. Maybe a forth Kalman filter? 
Anyway, here’s hoping this weekend actually does bring our first flight!
Matt
0 Responses to “Closing the gap”