Blogs

1. The Goal
2. Camera Selection
   
3. Packing it all in

Surprisingly, Atkins adds that during takeoff, the UAV is blind. “The plane takes no measurements of its surroundings. The waves would confuse it. ‘Most people wouldn’t do it this way,’ Atkins said. ‘The plane puts the motors on at full throttle and sets the pitch elevator enough to break out of the water. Then it counts and pitches forward. We believe that if we had done it any other way, we would have basically dived into the ocean on takeoff because the plane would have detected huge oscillations due to the waves.’”

• Part 1: Controlling servos with a Basic Stamp
• Part 2: Reading RC commands
• Part 3: Connecting a GPS module
• Part 4: More on connecting a GPS module
• Part 5: GPS simulation 1
• Part 6: GPS simulation 2
• Part 7: GPS simulation with Microsoft Flight Simulator 2004
• Part 8: Adding a failsafe board

NASA is developing a navigation system that augments GPS signals via a satellite phone network so that it works around the globe, beyond the limited implementation of WAAS. Their intended application is a UAV based mapping function utilizing synthetic aperture radar technology which requires a highly stable and accurate platform.

For testing purposes they will mount the radar and navigation system on a Gulfstream III (I especially like this part), "Since the Gulfstream III operates outside civilian air space it will not need a permit to use the UAV which takes 90-days due to a somewhat archaic processing system." I guess we're not the only ones frustrated with the FAA, even the best & brightest at NASA have a hard time with the red tape!

For details see article:

Nasa Develops Highly Accurate Plane Nav System

The PPA system will help keep the C-20A Gulfstream III flying level so the UAVSAR radar pod can scan geoseismic hot spots.

1. They're basically the same model, from Haoye Models.
   
2. The one from Singapore was rubbish, unpainted and missing all sorts of necessary parts such as the carbon fiber wing rods.
3. The one from Sonic Electric looks better, with painted body parts (gray elements in the picture at right), and most of the necessary elements. Go for the combo pack, with motor and ESC, if you don't already have spare equipment to use.
4. There's not a lot of room in the equipment bay for autopilots, cameras etc. This is foam, of course, so some cutting is possible, but it's going to be a tight fit. This is NOT an ideal UAV plane, but in the interest of equal scale opportunity (we've been showing Predator favoritism!) I'll have a go anyway.
   

[UPDATED: paper is finished and available below]

I've put together a technical assessment white paper for the FIRST robotics league, proposing an indoor aerial robotics contest for 12-17 year old kids (and coaches). Target price is under $1,000 and safety is of prime importance. This paper lists the possible platforms--microplanes, helis, quadcopters and blimps--and discusses the pros and cons of each. At this point I've tried most of the options, from helicopters to quadrotors to blimps to ultralight planes and I'm leaning towards quadcopters and blimps as the best choice.

• Quadcopters: Pros: very maneuverable, already have a full IMU onboard. Cons: very expensive to do well, hard to fly, can do damage to vehicle or people when things go wrong.
• Blimps: Pros: cheap, safe, easy to fly. Cons: hard to maneuver precisely, requires inflation, can't lift much weight at indoor size. Cheap UAV versions neither commerically available nor open sourced.

Cost, simplicity and safety pushed me towards the blimps, but I'm concerned about having the kids having to build the autopilot from scratch. Check out the draft of my white paper and tell me what you think.

• Doesn't need special calibration and doesn't drift. "Down" is alway down.
• Much cheaper. Without the gyro, the cost drops from $100 to $25 (two servos and some aluminum)
• Doesn't take up a separate channel. The camera stabilization automatically comes on when I turn on the plane stabilization.
• Saves power because the tilt servo isn't always jittering with every gyro twitch.

1. Israel has UAVs in the air 24/7, mostly on its borders. Unlike the piloted Air Force squadrons, where most flights are training, 90% of UAV missions are "operational", meaning that they're actually tracking targets and watching for bad guys.
2. They've been working to eliminate "flying" altogether. The UAVs take and land themselves, and "R/C" piloting skills, which were once prized, are now discouraged. It simplifies the training, lowers costs, and mimimizes human errors. Often the joysticks are linked only to the camera, and the aircraft is only guided by clicking on a map.
   
3. Another advantage of a small country (about the size of New Jersey): all the UAVs above hand-launch size are launched from Air Force bases like this one and communicate with the ground with direct radio links. No need for satellites. They can usually get an aerial camera on any spot along the boarder within three minutes. Aerial imagery is shared between Army and Air Force in real time, so there are few of the intramural battles the US has over chain of command and airspace control.

This post describes the beta version of BASIC Stamp autopilot code. As mentioned in my last post, the two main challenges in this project were dealing with the constraints of integer-only math and a severely restricted variable space (just 26 bytes!).

The first one I got around by treating fractional degrees as full degrees (since the UAV is never going to travel more than one full degree away from launch) and essentially treating them as integers. This was a little tricky, since I'm limited to word-length variables (with a max value of 65,535, which is essentially 4 and half digits of precision) and the GPS natively generates six and half digits of precision (360.9999 W/E). But I truncated the full degrees to just 1 and -1 from the current position, and that let me retain the full precision of the fractional degrees.

The second problem I got around by splitting the program up into five sub-programs (each one is allowed to reuse the variable space in RAM) and switching in real-time between them. I also used the Stamp chip's 121 bytes of "scratchpad" memory to store a lookup table of all the waypoints, and that's available to all the programs, although you can't manipulate the scratchpad memory directly without copying it into a variable.

The current program does three things:

1. It intercepts R/C receiver commands to the rudder, elevator and gear switch and translates them into computer commands, which drive the servos through a Parallax servo board or FT639 chip. When it detects that the gear switch has been thrown, it transfers control of the rudder and elevator to the autopilot program, and back again when the switch is returned to its manual position.
2. When under autopilot control, it reads GPS coordinates and headings and translates them into directional vectors to the next GPS waypoint. It uses those vectors to steer the rudder.
3. It also uses GPS altitude readings to do a crude sort of altitude hold. Because the GSP altitude data is so noisy, the autopilot averages over three readings and treats that as accurate +- 10 meters. It uses that data to adjust the elevator to try to keep the plane within a range of +- 10 meters of the original altitude at which it was put into autopilot mode.

The code has been tested on several different kinds of servo driver chips and GPS modules, as well as with GPS simulators, but not yet in the air. So consider it just instructional at this point. I'm sure there are some bugs, and a lot of settings that need to be tweaked. Also, we have not yet added camera controls and other more sophisticated in-air options, such as circle and hold (although these aren't hard to add, not that we've got the basic hardware interfaces working).

You can download the code at the following link. Load the first program (uav.bsp) and it will call the others at compile and download time.

The recommended hardware is a Basic Stamp BS2p on a dev board using the FT639 servo driver chip and a standard GPS module such as the EM406. Details on these hardware configurations can be found in the main post on this UAV. Other servo drivers, such as the Parallax board can be used, and the details on how to modify the code for them is in the comments of the code

• Basic Stamp autopilot code. [Latest version]

• Code for the Parallax servo board and Parallax GPS module is here.
• Similar code for the FT639 servo controller chip and Parallax GPS module is here.

We love GoogleMaps, but one of the problems with it is that you can't really add your own data to it. Sure, you can superimpose your imagery on a GoogleMaps layer, but it won't show unless people use a special URL. That's the reason for the creation of OpenAerialMap.

Pict'Earth's Jeff Johnson explains:

"OAM gives us a place to publish the imagery so that it easily reused. Basically the imagery that Google and MS Aggregate is not truly 'free' in the sense that it cannot be used in any useful sense outside of their programs without an overbearing license. Its kind of like Navteq or Teleatlas data. It may be freely available, but its not really free. So then, the goal of OAM is to provide a place where people like us (doing DIY stuff) can publish our imagery in a central place, but also a place for governments and other organizations that pay for imagery to get help publishing their data into the public space in an open/free way."

O'Reilly's Brady Forrest has great post that explans more here. (He also mentioned that I'm going to be giving a DIYDrones presentation at ETech on March 3-4 in San Diego. More on that later.)

You can see one example of one pass I took of the Alameda Naval Air Station runway that was orthrectified and stitched by Pict'Earth and is now part of the standard OAM map at that lat-lon (our imagery circled in the screen shot above).

(credits: Christopher Schmidt set up OpenAerialMap and the servers are hosted by Telascience, SDSC and bandwidth comes from CalIT)

Hi my name is Rob Swynnerton, i run a small company, www.flyingwings.co.uk. We manufacture a range of EPP models, wings etc. We also make parts for UAV contractors and this has sparked my imagination, what would be a great UAV test platform ? What size, payload capacity, what would be better than a commercially available model ie twin jet etc. Designs that inspire me are the Desert Hawk and the Raven, small micro UAV's with a wingspan of around 48-60" and payload of 1-1.5kg. Any help would be appreciated.

ps.... big up to Gary Mortimer for steering me here.

Rob

From an email that Rob just sent... Now I'm sure we all have ideas for what we would like in an airframe.

If you put it here I'll make sure he reads this thread.

The desert hawk is epp, and so are others being developed. We are producing airframes

for a major UK military contractor, its gone UAV crazy over here with a massive dedicated centre being built here in Bristol.

It would be good fun to create a package for amateur developers .

If you have a spec you would like, then let me know.

Regards Rob