I will begin by saying that I’ve posted TCNJ subset of competition photos taken by Dr. Zheng of Rowan University. This should give you a decent feel for the competition settings and
our my vehicle in its natural environment.
Secondly, I’d like to say that Drexel/Dan Lofaro still hasn’t gotten around to posting results and media from the competition (admittedly, there’s significantly more footage to sort through this time around) so I’ll just jump the gun here. TCNJ came in third place out of five at the conclusion of the comptition. Based on points given by judges for design and milestones like taking off… and well, only taking off… Emu managed to score above two teams who either did not have air-worthy or quantifiable vehicles. Those teams had opted to build their own quadrotors, but couldn’t quite meet the challenge. That reason is partly why I built a blimp, to simplify the control and manufacturing issues. Taking first place was Drexel’s A-Team, using an off the shelf Parrot AR Drone.
After this, things get murky. At the conclusion of the competition I heard rumors that the judges had botched the scoring. They may have inadvertently given Drexel “B” an incorrect score-multiplier, allowing them to land in second place. No pun intended. This left Temple’s Parrot AR Drone-wielding team in fourth place. This could mean two things if the scores are readjusted before being officially posted on the IARC site: a) Temple actually deserved second place, which I don’t believe is out of line, or b) TCNJ gets second place.
Mistake or no mistake however, I think the project overall was a great success. I achieved a fair number of my goals and learned a lot more on top of that, most notably the importance of feedback control systems (altitude control is a tricky thing). I’m also no longer afraid of soldering, if that’s an accomplishment, and I’ve come out of the experience with a long list of things I wish I had the time, or the money, or the expertise to improve:
- Re-spec components – Several components, like the speed controllers and the servos may have been overkill. I could easily have shaved off weight and size by selecting brand new components instead of reusing old ones. In particular, the ESC’s used on Emu were meant for R/C car applications where power requirements can be significantly higher. They were bi-directional (forward and reverse capable) and included a built-in heatsink. I only needed one direction, and my thermal dissipation was much lower. The ESC’s were rated to handle a combined 36A. My battery was rated for 20A. The servos could also have been smaller. It takes very little torque to rotate a shaft, and the holding torque required is minimal.
- CAD sizing – If I could go back and change one thing, it would be the size of Emu. Since I designed it without knowing what my mission would be, I built it with some extra payload capacity. This turned out to be unnecessary, leaving my balsa frame about 30% larger than necessary. Although the extra weight didn’t kill me, a smaller frame is faster to build and looks more compact.
- Aircraft weight balance – In addition to CADing a smaller, and more complete model of the frame, I would probably also position all the components (given a final frame design) that put my center of gravity intersecting the axis of rotation on my motors. The final design of Emu required some adjustment of the balloon harnesses because I was too tail-heavy.
- Bigger propellors – with the size-restriction on propeller sizes gone in the 2011 rules, teams were free to put face-slashingly large propellers on their quadrotors in order to fly. Although I managed to fly with a 4-inch props, 5 inches would have been easily doable with the brushless motors I had, letting my to apply less power to climb. I might have even only needed one helium cell at that point.
- New helium cells – This would help with the balancing. If you look in my pictures, Emu doesn’t have perfectly elliptical balloons above it. They are somewhat teardrop shaped, which may improve aerodynamics but does absolutely nothing for trying to make my vehicle fly level.
- Gyro, Accelerometer – Having some more spatial sensors would help me compensate for drifting, which happened a lot in flight. Not being perfectly level, or even having propellers spinning would cause Emu to slide or rotate undesirably. I tried to compensate by applying a permanent right turn into the navigation algorithm, but it was a stop-gap measure at best.
- Wifi camera – The parrot AR drones communicated solely over 802.11. They used wifi for control and video feed. The protocols and bandwidth of 802.11 ensured that they can broadcast without interference. Although the range might be more limited, it would mean not having to bring a satellite dish amplifier to make sure my computer isn’t drowned out by the video feed. Otherwise control of Emu would have been lost. The difficulty in implementing a wifi camera is the need for a wifi-capable platform. This is why the AR Drones have an embedded linux computer running inside them. Alternately, the use of a module like the CMUcam, with a built in vision processing board, would completely cut out the need for a base station and make Emu completely untethered. Although I like that option, the drawback is that I can’t remotely see what Emu sees anymore.
As you can see, the list of improvements is extensive. But it just means I was acutely in tune with the direction I was going, and the needs of my project. Despite the length of that list, I do feel rather proud of all I did and I would do it again in a heartbeat, if only to try and improve on it all. I’ll be posting a few more things in conclusion later this week which will hopefully wrap it up for IARC posts on my site. I also have a new project that will be taking up some time after graduation. This one is decidedly more low-tech, but I think it’ll be amusing/interesting nonetheless.