A Recap

It’s probably quite obvious that we haven’t had a chance to work on the quad for quite a while recently. As a matter of fact, I had forgotten this blog even existed… But not to worry! Plans are on the drawing boards for some good changes to our machine that should make stable flight much easier. Following the massive slew of smart phones with accelerometers and all other sorts of motion detecting features, you can now get BoB’s (break out boards) at Sparkfun containing not two, but all three axis gyroscopes, triple-axis accelerometer, and triple-axis magnetometers… that’s a single 9DOF BoB for about what we paid for our accelerometer and dual-axis gyro alone. Which means we will very likely be replacing all of our sensor boards with one beautiful new board.

Matt also wants a redesign due to the still seemingly present vibration issues (I like the idea of the memory foam Nic- sorry, just got that comment- I am just worried that our vibration is a really high frequency that may not be cancelled by the firmer foam? Worth a shot though!) So, new positioning sensor boards, new mounts, and while we’re at it, why not throw in a custom printed PCB? (Time to learn EagleCad). In all, the guts of our new quad should be almost brand new by the time we get back to test flights.

But let’s back up a bit further. Since we’ve been gone, our “roll cage” was developed. It really turned out to be more of a box the electronics sit in. Four threaded rods act as our posts on the four corners, and with a plywood battery casing and phenolic top, we’re set.

Finished Gut Casing

For your imagination’s sake this post has lots of pictures.

Battery Plate

This plywood plate is what supports our battery, which is encased in the pink foam you see below:

Battery Casing

Our most exciting new addition to the quad (that I don’t think I’ve covered) is our new motors (I’d link you to them, but I’ve lost the bookmarks, I believe they’re Hacker A20 20L). These are supposed to give us much less vibration, and hopefully be more reliable than our first four (one who’s shaft we bent, and two other’s bearings we shot). Anyways, they have a square mounting base as opposed to the three triangularly oriented holes of our others, so I just drilled a second hole in our shafts, and sandwiched our motors on. I would give pictures, but sadly it’s currently not accessible. Here’s a shot of the new motor alone though.

New Motors

If I remember correctly, these came with gold “banana” male/female connectors that you had the option of using. We went with them, and soldered them to our power supply cables and the motor’s cables. Now, the upside to using these motors is that they come with many different mounting brackets, and axle options. The downside is that the mounting point for the motor is where the axle extends out. This means you have to mount your motor with your axle sticking through the mount. Well, that’s a problem, because the axle isn’t too long to begin with. So our solution (and many other people’s across the internet) is to take the motor apart and actually flip the axle so it extends out the opposite end of the motor. This is a very simple task, and everyone claims it works just fine, but I still have some reservations about it. The motor comes apart in two parts. There’s the outside shell with the magnets (blue part in picture), and the inside coils, which are mounted to the black end cap with the wires protruding. The whole blue casing then spins, turning the axle that extends through the stationary black cap with the wiring. The axle is press-fitted, and held with a set screw into the opposing black cap (which spins with the blue casing), and the only part that holds the entire assembly together is a tiny C clip that fits in a groove on the axle protruding out of the wired black cap. Remove the C clip, and the two halves slide apart (with just a little resistance from the force of the magnets). To flip the axle, you remove this C clip, then separate the motor, unscrew the set screw, and hammer the axle out of the press-fitted black cap. You then flip the axle, hammer it back in, and the questions start. First off, the set screw has a groove cut into the axle just for it (so the axle will have no chance of sliding in or out if the press-fitting fails). Flip the axle around, and guess what? The groove is in the wrong place. So, you can just screw the set screw in and pray for it to hold I guess… Second, that little C clip that’s the only thing that holds the two halves of the motor together, well, it’s got its own groove too, and obviously the groove won’t line up with its original spot either. Luckily, however, the wider groove for the set screw ends up being in about the place of the C clip. So if you’re careful, you can align the axle just right so that the friction from the black cap backing it and the side of the groove it’s in holds it in place. It’s a very loose fit however, which again worries me. I’m not saying it won’t work, I’m just saying, if you try to work with these motors, be careful. So, best case the set screw holds, the C clip doesn’t fall off, and our quad flies miraculously. Worst case, the set screw or C clip fails, and since one half of the motor is attached to the quad, and the other half is attached to our props, and both have opposing forces, we get halves of motors everywhere.

That’s our news for now, come August Matt and I will be in the same town again, and our posts will certainly become more frequent.



To be or not to be, That is the question…

If by “to be” you mean a flying quadcopter, and “not to be” you mean a pile of charred ashes…

Due to the worry that we will end up with the latter if we continue using the battery we have, we are looking into investing in a new LiPo. After spending the past hour or so perusing over some witty banter between many flight hobby enthusiasts on the topic of “puffy LiPos” and the dangers included in using them, I have come to realize that yes, it is potentially dangerous to operate with puffed packs, but many people have been doing it with no consequences. While it is true that you must keep in mind your craft could go down in flames from any possible overpuffing and consequential bursting and venting of the pack, or puncturing and burning of the pack, in reality, you can minimalize these events from occurring by just being careful. Not operating a pack that is puffed so badly that it holds pressure, meaning not operating a pack that is puffed and hard, and any added pressure could burst. Monitoring puffed packs during current draw, to be sure they don’t become puffed enough to burst and vent. Monitoring the packs as well for heat, it appears 140F is the “bad zone” for LiPos, so letting batteries cool before they reach that point is always a good idea. And in general, just being careful with them. From what I have read, yes, there have been catastrophic failures, where houses burn down, but LiPos seem to only have a bad name from a few cases. Plenty of other people have blatantly cut into their packs, knowing what to expect, and yes, when charged, you should get a fire, but if you are prepared, it shouldn’t be the end of the world.

A note to anyone on disposal of LiPos: From what we have found, they are landfill friendly, once discharged completely. This can be done numerous ways, some people hook them up to a power draw, and just let them drain, then they will cut them open and submerge them in a saltwater solution for a few weeks, and dispose in a landfill. Others simply place the whole battery in saltwater. The water conducts slightly, so it drains slowly directly through the contacts, and eventually you have a completely dead battery. Now, whether you need to cut open the packs and re-submerge, I don’t know for sure. I would imagine the battery should be fine as-is, and ready for the landfill. Keep in mind these are all the “safety conscious” people. Personally, I would prefer (and there are plenty who do this) to set the battery in a firesafe area (nothing that can catch flame within at least a few feet), and puncture the pack (adding water optional), as fully charged as possible. BE CAREFUL THOUGH! This can be extremely dangerous, and while LiPos don’t seem to be as bad as their reputation, I am not responsible for giving you an idea that you carry out dangerously on your own.

On that note, we are still worried about our pack. It appears puffed, and while this whole time we have been thinking it was just an air bubble between the cells and the covering shrink wrap, we are getting nervous that in the case we are wrong, and the battery does catch fire, and it happens to be on the quadcopter at that time, we would be down a very fun toy… So tomorrow morning, we are very carefully stripping the shrink wrap off of the cells to compare them and verify if any or all are puffed, or if it truly is just an air bubble.

Also on the agenda for tomorrow is adding the LCD screen we bought a while ago, which means soldering plenty of tiny pins, my favorite! And adding a roll cage to the quad, so upon a collision with the ground (something we really don’t want to have happen) the two sheet metal strips bent into two U shapes, and crossed over the electronics, will take the brunt of the force, and the electronics themselves will not.


…Not Taking a Break

Well, as the school year winds down, and we go into a state of shock realizing how many tests we’re about to take… we need not study! There’s work to be done!

So, last weekend Matt and I met up again to get a little more minuscule bits and pieces sorted out. He had been complaining about the switch that pulls the reset line high or low to put the PIC in programming or run mode, saying “It won’t reset to programming mode, I put it in programming mode, but it doesn’t make contact, and I think the switch is broken…” Needless to say, the whole time I tested it, it went into programming mode perfectly fine.

… Well, except for when it didn’t… and then he rubbed it in my face, but all in good fun. So, first on our agenda was changing the switch, which we had come up with an ingenious plan for: There is a pin on the PIC that is a reset line, pulling it high will reset the microcontroller. I just so happened to have a reset button from a computer… a very special button. It was a double poll double throw switch (DPDT)… but a momentary push switch, so it had two feed lines, and then each feed line would go to one of two leads depending on if the button was pressed, or released. This would be perfect, we figured! We would put the reset line on one side of the button, so when you pressed it, it would automatically reset the whole PIC, as well as the choosing line on the other half of the button, which would pull the pin high, to put it into programming mode. After plenty of redrawings of the schematic, and Matt realizing when you flip the button over, the pins also happen to flip (left is on right, right on left now) (again, I’m just teasing him, he’s extremely smart) we finally reached a final draft. There would be two options, you could press the standard reset button on the PIC, to which the choose line would always be pulled low (momentary second button) and so you would reset the PIC into run mode, or you could press the new button, which would use the secondary reset line to reset the PIC, and also pull high the choose line, leaving it remaining high for a fraction of a second after you released the button via a capacitor so as the PIC booted, the line would remain high long enough for it to recognize the fact. This would be perfect, no more Matt flipping a semi-broken switch and pressing a button, and pressing a button but realizing he forgot to flip a switch, etc. etc. However, as we pulled our precious one-of-a-kind switch out of the breadboard (which we had to… jerry rig to make fit, see picture below) one of the pins broke off… and that was the end of that. No amount of pleading with my parents to just let me have a quick look in their computers to see if the power switch was the same kind, because I could easily replace it! It only needed two of the six pins! (which ours still had) helped.

New Switch

Testing the New Switch

You see, breadboards are designed for ICs, the middle slot is wide enough to accommodate the two hole gap between the pins of a standard IC so the rows of connected pins can span outward in either direction, but not short the two pins on opposing sides of an IC together. Sadly our switches hole spacing was 3×3, so there was only a one hole gap in the middle. We couldn’t span the breadboard’s built in break in rows, so we had to come up with a way to still momentarily test the switch. It turns out an IDE ribbon cable (for hard/CD drives before SATA) butted up against the breadboard gives an exact one-hole-gap. So, as ridiculous as this may look, and as ridiculous as it felt, it worked!… Until we broke the pin off.

Without a momentary DPDT switch we had to dig up the next best thing, which turned out to be a normal DPDT. We decided against making the design any more complicated than need be, and just replaced the old SPDT we had been using that had broken.

Among other accomplishments during our meeting, we added landing gear (cut a pool noodle into two inch long sections, and zip-tied to the bottom four corners of the quad, pictures to come later), modified an adapter for Matt’s new “fancy” battery charger, watched it balance the cells automatically, charge them, etc. We deduced that despite our fears, the Lithium Polymer battery pack we have been using is not going bad (we were quite releived), and swapped out a propeller blade, since someone’s feline friends enjoy chewing… (to clarify, not mine)

Bad Propellor

Propeller we replaced

Good thing we bought extras!

Finally, we realized that our 12V to 8V power supply was heating up a little much. To be sure we weren’t drawing too much load or harming it in any way, we tested current draw with certain sensors plugged in and unplugged. Determining everything should be fine, and we had no shorts, we just added a nice heat-sink.

New Heat-Sink

New Heat Sink for 12-8V

While this next photo is a little blurry, it shows the perfect placement with which we planned to fit the heat-sink, right around our USB plug for the PIC. Yeah… that’s right… planned… like everything, right?

New Heat-Sink

As if it were designed to fit...


Taking a break

Matt here! Unfortunately, its looking like we’re going to need to take another break on our quadcopter project. Our Botball season is now in full swing, not to mention we’re at the first of two “hell months” for IB sensiors, Internal Assessment February. In this one month we’ll be writing be writing the TOK paper, doing TOK group presentations, second Math IA, Spanish interactive, Individual Oral Commentaries, and History papers, in addition to our regularly scheduled workload, not to mention squeezing every possible second in to Botball. I’m expecting to be able to resume weekly copter meetings in mid to late march when Botball is over and we enter the less-stressful preparation for hell month part two, IB Exams in May.

I do want to take this post I guess, to describe our progress visually for any readers who stumble upon this between now and our project’s reawakening.

I’ll start off with this video, which shows the carbon fiber frame we constructed, as well as the power system successfully providing the power to achieve liftoff. The control board isn’t using any sensors or making any attempt to stabilise the copter, just parsing our repurposed Vex RC receiver and giving fixed throttle to all four rotors. We were still glad to know however that we could easily attain lift, however, the next, more difficult problem is simply getting it stable.

This is the control board we built over a period of several weeks. I did the majority of the circuit planning and design, while Will did the long arduous task of actually assembling it. The red board at the top is a stm32f103 header board, a powerful ARM cortex-m3 microcontroller. On the elevated board in the center is the micromag3 triple axis magnetometer, and underneath it (not visible from this angle) is the sparkfun 5 DOF breakout and yaw gyro breakout, giving us 3 axis of accelerometers and gyroscopes producing a full 9 DOF IMU.

Kalman Filter
Here’s a graph of a GNU octave script  computing a Kalman filter from sensor captured with me shaking the board. It combines the shaky red accelerometer signal with the accurate but slowly drifting green gyro signal to produce the blue output, a fairly accurate estimate of the board’s roll. The sensors and filter work pretty well in a hand test, however…

Data captured from the quad with all four motors roaring at flight velocity (although actually at the present we’re so light this only about 45% throttle or so.. we should have good payload capacity!) doesn’t look so peachy. This one of our current issues, the motors’ vibrations simply render the accelerometer useless and the Kalman filter is unable to correct for gyro drift. We’ll probably address this and our current unbalanced center of gravity first when we resume work on the quad.

At the low speeds, the Kalman filter operates successfully and allowed me to tune some PID loops making closed loop control. In this video the quad takes a while to steady itself after a large movement, but I’ve since gotten the loop quite tight by adjust the PID loops, and in particular feeding the unbiased gyro signal directly in to the D term instead of taking the derivative of the position estimate.

This was my attempt at flying the quad despite the aforementioned vibration issues. Quite unstable, and in particular the pitch axis is never able to level itself, something it didn’t have a problem with in single axis testing. We do have a poor COG for the pitch axis though that needs to be addressed. Additionally hard-iron calibration issues forced me to disable yaw stabilisation to get any meaningful behaviour out of the quad, so it spins quite nicely once off the ground too. We’ve clearly got a long way to go still, but we’re all as excited as ever to overcome these obstacles!

Weed whacking

This weekend, I went through and re-evaluated the Kalman filters at flight velocity. As I suspected last weekend, the accelerometer noise became even greater, and was introducing noise into the filters output. I collected new samples with the copter actually airborne though safely tied down to our testing board, and tweaked the Kalman filters yet again. At this point, I don’t see how the filter is finding any correlation between the gyro and the accelerometer, which I suspect is causing some drift in the filters output. Its also easy to see from these graphs that the pitch accelerometer suffers more noise than roll, and the noise is offset towards positive pitch angles. Will and I had noted earlier that the accelerometer is a lot more loose on the pitch axis due to that axis being parallel with the female headers holding it to the board, and that in particular it is most free in the positive pitch direction. Hopefully we can fix this next weekend by screwing down the 5 DOF board.

Roll accelerometer (red), gyro (green), Kalman (blue)
Pitch accelerometer (red), gyro (green), Kalman (blue)

After that I calibrated the PID gains again, testing them again at higher velocities and going for a tighter more responsive setup. In doing this, I noticed that the pitch access is not very balanced, something we probably need to correct. For now, I gave it a larger I term, though that seemed to make it less stable than the more balanced roll axis.

I also worked on improving the magnetometer, and manage to perform tilt compensation from the roll and pitch kalman filters, instead of form the incredibly noisy raw accelerometer signal. The raw magnetometer output is now quite clean, but limited to the micromag3’s slow sampling rate of about 10hz (though I could speed it up but lose some precision). However, when I attempted to Kalman the micromag with the yaw gyro while hovering on the test scan, a new problem reared its ugly head:

Yaw micromag3 (red), gyro (green), Kalman (blue)

Unfortunately the motors seem to be causing gyro jitter in our LISY300AL similar to that which had been reported in other copters (though an entirely manageable amount for the Kalman filter), but more dramatically, non-linearity in the micromag. During this test the board was limited to a total yaw of less than 45 degrees and remained mostly at the same heading, yet the micromag steadily climbs as the motors velocity increase, and even shows a 180 degree peak in the middle, which the gyro indicated was no more than maybe 20-30 degrees. This is kind of a “duh” moment, but I had hoped that the magnetometer wouldn’t be terribly affected in the center of the motors, but apparently we will need to perform hard iron calibration. Most annoyingly however, calibrating it to work with the motors on will cause it to work incorrectly with the motors off. A possibly better solution would be to relate the magnetic drift with the velocity of the motors.

For now, I disabled yaw control and attempted to get it to lift off while attached to our test board. Unfortunately, it never appeared to balance well on the pitch axis, but roll looked somewhat stable, though not nearly as stable as in the single axis test. It was hard to really see its behaviour though, because the test board gives it maybe 5 inches of room in any direction. On Jeff’s (online) urgings, I finally decided to give it a chance outdoors. After a few runs, this video is the closest it got to actual flight:

I actually got it to hover when I put the full stick fighting the pitch motion it seemed unable to correct for on its own, but this stability was short lived. And yaw control is clearly needed as well. Still, its inching closer to a successful flight! Fixing the accelerometer mount and performing hard iron calibration should hopefully get us there, possibly even next weekend! (though I realize I’ve been saying that for nearly a month…)

Didn’t make it..

So, this weekend unfortunately fell short in many ways, not the least of which is my failure to write a blog post for every day, because, simply put it, not a lot happened. We actually had a lot more school work and other schedule conflicts than anticipated, and could only work for a few hours on friday (teacher planning day), saturday, and today.

Friday, Jeff and I investigated the use of fishing wire to suspend the copter from my ceiling fan as a way to do balance testing and yaw testing. We ran out of time, however, and were just barely getting the copter to exert some control of itself without spiralling out of control when he had to leave. Monday, Karsh was also pretty busy but was able to come over for a little bit. This time, however, the harness broke while attempting to do a yaw control test, resulting in our first crash, though the copter fortunately survived it unharmed.

Today, Will and I did manage to be fairly productive. We started off from the beginning, studying kalman filters with motors running again on a single axis, and noticed that our filters were failing to cope with the accelerometer noise. We now know this to be be due to the fact that our motors cause significantly more accelerometer noise at higher speeds (kinda obvious, but some kind of complex resonance-y thing must be going on because it seems to be a greater than linear build up). We decided to tune the kalman filters again with motors running at as high of a speed as possible before it started to drift away from our mostly crappy test setup, and got back to good performance (though the filter does have a greater tendency to drift due to less reliance on the accelerometer).

Will then suspended the copter from the fan again, using a proper knot this time, and we got a successful yaw pid control up. We decided for now, we’d shoot for very stable at the expense of possibly lower response time, because we suspected that when adding the filters together noise or instabilities would build from each one, and we did not want oscillations when we went to do test flights. After getting a decent yaw loop, we worked on single axis roll and pitch loops, and found that we really need separate PID values for each one, but made do with a makeshift loop considering the software changes would waste what little precious time we had left. We finally decided to go for broke and the four spars of the copter down to the board, giving it about 4 inches of airspace to work with in all directions. Unfortunately, despite our PID loops and tuning, it really didn’t look much different than the uncontrolled lift off we attempted earlier. In looking at the outputs, we saw again that our Kalman had become somewhat jittery again, giving the PID loops an inconsistent response. There is apparently once again a new level of noise attained between the throttle that caused the copter to drift out of our one axis testing setups and the throttle that actually achieves left. At this point the low voltage cut-off of the speed controls kicked in while taking the motors up to speed, and the work day was brought to an end.

This annoying realisation that we need to retune again is an unfortunate conclusion to the weekend. Next time we’re able to get together, we’re going to log and determine exactly what liftoff velocity is, then devise a setup (probably including lots of duct tape) that will enable us to do single axis logging and testing at that flight velocity, and basically work again from the ground up, getting a stable kalman and good PID control. To do a good takeoff, we also need to pay more attention to the large error response time of the PID loop, and try and get a quick but accurate response without losing steady state performance or entering oscillations. It’ll be tricky, but we’re not giving up yet!

Where’s the pics, our faithful (but according to stats, mostly nonexistent) reader might ask? Well.. Will took a few videos with his camera, but none of them were all that impressive. I think this blog post might just have to be like the weekend.. long, time consuming, and relatively uneventful. Next weekend is also the start to our Botball season, but hopefully we’ll still be able to find time to do some testing. I’ll probably attempt to retune the Kalmans at flight velocity during the week, giving us a head start on the weekend’s PID tuning.

The tilt compenstated compass performance is also extremely poor right now, owing to the fact that I computed tilt compensation only from a slightly averaged raw accelerometer signal. I need to figure out a way to convert the IMU’s roll and pitch back in to axis angle or a matrix or something to work with for tilt compensation, but the IMU doesn’t really output “correct” rotation values. My understanding of the rotation group and the like is getting fuzzy at this point, but just having a roll angle and a pitch angle doesn’t give you a rotation unless you know what order those should be executed in in.. but they’re calculated in the IMU completely independently of one another, they’re not Euler angles and combining them in either way doesn’t work out (or at least not when I’d tried it earlier). I’ll need to do some more experimenting, or, failing that, simply average the accelerometer even more heavily or eliminate it all together and just use two axis of the magnetometer (though thats a waste of a nice magnetometer..)


Closing the gap

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!


Project Quadcopter

Welcome to our quadcopter blog! We're a bunch of high school seniors from Florida attempting to create an awesome flying robot before we all have to go our separate ways for college. To learn more, see the about pages!