Blogs

Students representing 16 colleges and universities gathered at Webster Field last week for the sixth annual Association for Unmanned Vehicle Systems International unmanned aerial systems competition.Joe Brannan, the competition’s director, said this year’s teams were among the best he’s seen since the event began in 2003.‘‘Both of the first two top finishing teams” in this year’s event, Brannan said, ‘‘were significantly better than I’ve ever seen” in past events.NAVAIR’s Program Executive Office-Weapons and AUVSI’s local Seafarers chapter co-host the annual competition.‘‘Northrop Grumman is our biggest supporter, with $10,000,” said Brannan, ‘‘with Boeing, Lockheed, The Patuxent Partnership and Johns Hopkins Applied Physics Lab each contributing $5,000.” More than a dozen other defense contractors also support the annual competition financially. This year’s competing teams were awarded a total of $44,850 in prize money.The college competitors must design and build an unmanned aerial vehicle that can be programmed to fly autonomously for a specified time over a specified area and, while airborne, locate and photograph targets on the ground below. When the aircraft lands, the digital information it captured during the flight is downloaded and analyzed.

Engineering TV has a bunch of UAV episodes up, including the Berkeley Aerobot Team and the Hybrid Systems Lab at Stanford University.

Links to the videos are below:

Autonomous Quadrotor Helicopters

Distributed Collision Avoidance

BEAR: Berkeley Aerobot Team

Berkeley Aerobotics UAV Fleet

Maxi-Joker 2 Camcopter

SmartBAT Fixed-wing UAV

[NOTE/UPDATE: All the below, from long ago, has been superseded by events. Basic ArduPilot proved capable of every this described here, so we cancelled this version of the product. Thinking about what the next version of ArduPilot could be can be found here. ]

Our main entry-level ArduPilot is designed to be simple, easy to use, and cheap so it just does navigation and leaves stabilization to an stand-alone FMA Co-Pilot with infrared ("thermopile") sensors. But you can tell by our release of our own IR sensor boards the other week, the ultimate aim of this project has been to release a more advanced version that does it all: navigation + stabilization in one. But a standard Arduino isn't powerful enough for all that. So what's the solution?

A dual-core Arduino! So here it is: ArduPilot Pro, with two Arduinos, a MUX/failsafe and built-in GPS onboard. Jordi's design incorporates everything you need for a fully-functioning autopilot, with a target price of under $100, including GPS and thermopile sensors. One ATMega168 processor handles stabilization and the other handles navigation, but because they talk to each other, you get a fully-integrated autopilot, with control over all aircraft channels.

We could have just switched to a much more powerful processor, but that would have cost more, be harder to program and wouldn't benefit from the easy-to-use IDE and the software libraries available for the fantastic open-source Arduino project. The downside of doing it as a dual-core board is that we have to program each Atmega168 processor, as well as the MUX's ATTiny processor, separately, which is why there are three ICSP ports on the board. But in the commercial version, which will come with all processors pre-programmed, there will be little need to fiddle with the stabilization and MUX code, so they can be treated as black-box hardware. (The ICSP ports are just there for anybody who wants to fiddle with them anyway.)

We haven't tested this one yet, so we're not quite ready to provide a link to buy the board. But the Eagle 5 files for the schematic and board are here and here.

BlimpDuino is a very low cost open source autonomous blimp. It consists of an Arduino-based blimp controller board with on-board infrared and ultrasonic sensors and an interface for an optional RC mode, a simple gondola with two vectoring (tilting) differential thrusters, and ground-based infrared beacon.

It is available as a commercial kit from the Maker Shed or the DIY Drones store for $89.

• If you want to build your own, the necessary files and component lists are here.
• Autopilot code (for the board's two main processors, Atmega168s) is in development and will be posted here.
• Latest multiplexer code (for the board's third processor, an Attiny, which runs the failsafe system) is here. (If all you want is to load our code, rather than modify it, just use AVR Studio to burn the antifail_system.hex file in the Default folder to the Attiny chip)

• Introducing the dual-core ArduPilot Pro, with built-in stabilization.
• Thermopile sensors
• First built board
• New ArduPilot Pro boards (11/10/08)

First, the headline news: the Nano pretty much blows the Arduino Stamp/Mini away, and I would expect it to replace the Stamp in the marketplace. In most prototyping applications, a Stamp by itself is not enough--you also need the USB board, and together they are about $10 more expensive and 30% larger than the Nano (which has USB built in). The Nano also has a physical reset button and automatic hardware reset when uploading new code, while on the Stamp you have to connect another wire to get that and there is no reset button. Here are all of the Nano's technical specs and features.

The Nano also has a number of advantages compared to the Boarduino, although it's more expensive. Aside from being about half the size, it has the aforementioned automatic reset when uploading code, while the Boarduino, which uses the FTDI cable instead, requires a manual reset [UPDATE: see comments for some clarification on this]. It's also got two more analog input pins, thanks the surface-mount ATMega168 chip having more pins than Boarduino's DIP version.

As it happens, we still prefer the Boarduino in a few cases (and not just because we use its parts to make our ArduPilot and BlimpDuino kits). For certain low-power applications, such as our BlimpDuino, you want to run the ATMega at a lower clock speed than the usual 16Mhz, so in those cases you'll want to make the crystal removable. (Typically we'll put the crystal in to program the chip, then remove it to run at the lower speed). That's not possible with either the Nano or the Stamp.

Here they are all together on a breadboard for size comparison (click for larger version):

Finally, a point about breadboardable Arduino boards vs. stand-alone dev boards like the Decimila and its mini "proto shield" breadboard. The Decimila is a nice and compact combination of an Arduino, power supply and breakout connectors for the pins, but the tiny breadboard that fits on the proto shield is too small but all but the simplest projects.

For most projects I prefer to use a breadboardable Arduino with a proper full-size dev breadboard (I use a Parallax professional development board, which has loads of useful features and goodies but is too expensive if you're not planning to use Basic Stamps, too). The one shown above, for instance, is being used to prototype RC mode for our blimp controller, which is way too many wires for the little Decimila breadboard. My advice is to get a full-sized breadboard and power supply and use the Arduino Nano. I think it's the best version of the Arduino currently available.

To keep Blimpduino as cheap and simple as possible, it navigates by looking for signals from a ground-based IR beacons in any one of four directions. There are four IR detectors (N,S,E,W) on the blimp and the ground-based beacons are nothing more than an IR LED transmitting random 1s and 0s at 56KHZ. This being IR, they bounce all over the room and there is loads of IR noise from other sources, but the IR receiver that records the highest number of 1s (highest signal-to-noise ratio) is considered the direction that the beacon is transmitting directly from and we steer accordingly. (This is also the way the Pololu IR beacon/transceiver pairs work)

That's easy for one beacon. But when we want to introduce multiple beacons, each with a unique ID, it gets more complicated. We can't transmit at different light frequencies, because we'd need to add matching IR receivers on the blimp for each beacon we added. We can't use TV remote control codes, because then we can't tell where they're coming from (it's the ratio of signal to noise that tells us direction, but the codes are all signal and work as well if they're bouncing off a wall as when they're aimed directly).

Our instinct is to have a central beacon controller (another Arduino--see diagram above) and sequence them so that you'd be able to tell which beacon is transmitting by when in the beacon sequence you got the signal. But that requires us to synchronize the blimp and the beacons to a common clock, and we're debating how to do that.

My proposal is to do the following, 10 times a second:

1. For the first 1-50ms in each cycle: all beacons go on for 30ms, then all off for 20ms ("clock sync pulse").
2. 50-60ms: Beacon 1 on
3. 60-70ms: Beacon 2 on
4. 70-80ms: Beacon 3 on
5. 80-90ms: Beacon 4 on
6. 90-100ms: Beacon 5 on
7. Repeat...

The beacon hub controller would just schedule that sequence. The blimp, meanwhile, would have to detect both the direction of signals and how long they're on. If they're on for 30ms and then off for 20ms, that's the start of a cycle. Then depending on when in the cycle it detects the next signals, it knows which beacon that is.

Jordi's not convinced this will work, and thinks we'll need an RF link to communicate between blimp and beacons, which strikes me as expensive, complicated and unnecessary. What do you guys think?

Is there a better way to have a blimp distinguish between different IR beacons?