I've spent the last few years as an undergrad at MIT working on human factors issues related to quadrotors and their operators. Since this project wasn't about controls or vehicle development, we purchased aircraft from UAV vendors. The experience was less than ideal. In particular, the cost of the vehicles was about $6k, which given the components,
just seemed outrageous when an RC helicopter can get down to $50. In light of how wonderfully unregulated the world of amateur UAV work is compared to industry or academia, I have been thinking about what it would take to do better myself. In particular, our human factors research indicated that systems with a human in the loop didn't need to be nearly as stable and precise in their movements as we had thought. So with this is in mind, I started to design a vehicle.
To be honest, controllers are kinda magical to me. I had to learn some basics when I took 6.01 at MIT, but I was overjoyed when that unit ended. Three years have since passed, and I now only have vague memories of something about poles, a letter 's', and graphs of underdamped oscillatory systems.
So I am starting an experiment. I have an RC helicopter, barely enough skill to keep it from crashing, Matlab, and a pile of Arduino and RC-related electronics. My first goal will be to give myself automated height control of the vehicle.
(Please note: as someone without a controls or aeroastro bone in my body, if I'm doing this hilariously wrong, please let me know.)
My strategy looks like this:
- Attach an Arduino, ArduIMU, and RC receiver together on the aircraft.
- Code up an integrator loop running on the ArduIMU to provide a dead reckoning estimate of Z motion.
- Log a timestamped series of readings matching the aircraft height to throttle inputs.
- Apply Matlab and rub vigorously.
- Repeat step 4 every few days until satisfied.
Step 4 and 5 really mean this: develop a model of the aircraft behavior that matches the real world. I'm assuming that the vehicle is a point mass with two forces acting on it, gravity and thrust. If this really is the case, then given a functional relationship between the RC throttle command and thrust, I can sum the forces, use Newton's first law, integrate the acceleration, and provide a model of the expected Z behavior. Since I have the logged Z behavior to compare it to, I can see whether my predicted behavior matches the real behavior of the vehicle. In a picture:
If the model matches the real work reasonably well, then there is cake! If it doesn't, then I go back to my Matlab pit of despair and see what I did wrong. Once I have this model, then I can do something scary like design a controller. Which might look like this:
At least two demons lurk in these diagrams: delays and linearity. I would be thrilled to discover that there is insignificant lag in the forward portion of this controller and the thrust is a linear function of some maximum thrust value. I suspect that these assumptions will be mostly, but not completely, true. Fortunately, they may be good enough that I am satisfied with the results, and I don't need to mess with it any further.
My parts are ordered, I have a trip to take this weekend, and then I will be back on spring break to see how well it works!
Comments
Scott, I was figuring that was what you meant, because the "sum(F) / m = a" relationship was the only inertial behavior I was thinking (hoping) I needed for this simple model. I also realize I never mentioned that the helicopter I'm using a co-axial, so I am assuming the torques will be essentially irrelevant until I try to establish the yaw dynamics. Yes, in theory there will be some interference between the z-axis and rotational dynamics depending on how the mixing is established.
I have to rework my post in that I misinterpreted the "z-axis" as for some reason being a rotation (yaw) around the z-axis and forgot that the original goal was for altitude stabilization. My headspace was in modeling the quadcopter's dynamics, so I apologize for misinterpreting the original post.
- It seems loud and clear that the integration is a bad idea. I was going to put a sonar on the thing anyways at a later stage, so I'll just go ahead and do that now.
- I'm quite aware there's going to be a shift between the continuous behavior of ideal system and the discrete variant that the electronics will provide. I am lead to believe this doesn't drastically change the system, but will decrease the performance slightly. Hopefully there isn't a darker message that I'm doomed here.
- Part of my motivation for not choosing to go with existing solutions is that they are inherently more complex. I have spent enough time dealing with the edge cases of other engineers' systems that I want to have my own understanding of this thing. There may come a point when I get a working product that I want to "work better" and then decide to accept the outside contributions. Currently I'm a little to ignorant of how things work, and a little too scared of other people's failure modes to just go that route now.
I 100% agree with Eli. Start with a Maxbotix XL-EZ4 sonar for your altitude.
You're taking the hard road by trying to immediately using the accelerometers in the hopes of doing altitude estimation. I have seen a continuous stream of smart people try and then fail to do this. If you do continue with that, I really hope you're successful, no sarcasm in that comment, but it's really hard.
...and as a completely unrelated side point..if you really want to save some time, buy and APM2, put it in a trex450 following the arducopter instructions and you'll be flying in no time with altitude hold working and you'll be building upon what's already been accomplished and when you've successfully got the dead reckoning working the world as a whole can benefit from your efforts. :-)
+1 to the discrete time solution. Are there no moments or inertial terms because you're taking the yaw right at the rotor head? I love your drive. Good luck with your project.
Once you've got an LTI system you like, the next step would be to replace parts computed by the circuitry with discrete-time (or z-domain) equivalents. Try simulating the same mixed system in Matlab, with various sampling rates, you might find something interesting about the stability of your simple height controller...
hey paul- as a course 16er who has made quadrotor controllers before and done a number of other things with arduinos and imus.... i would caution you from ever trying to integrate anything! :) pick up an ultrasonic sensor to do altitude or youll be bashing your head against the wall for a while. you can do some pretty great stuff with accelerometers but any sort of simple double integration is going to result in your estimate flying off to infinity very quickly. Regulating Z vel isnt that hard, in fact, its the easiest part of controlling a quad (or regular heli, in your case). when you get to attitude control, thats a bit harder... i dont mean to dissuade you by any means, but as a first test, try throwing your accelerometer up and down 1 meter, put that data into matlab, and see if you can make your accelerations result in +1 and -1 meters of travel...... i've tried it myself and the results were not pretty.