Slashdot Mirror
Cornell Builds Autonomous UAV
tshak writes "From Microsoft Research, 'Faculty and students at Cornell University have built an unmanned airplane with its own on-board, embedded control system. The large-scale model plane flies by accessing coordinates from an off-the-shelf GPS unit.' Not only does the plane run XP embedded, but the software is written in C# on the .NET Compact Framework. This is all powered by an 800mhz Crusoe processor with 1GB of total system storage."
Haven't seen the EULA for XP embedded but the consumer one says do not use for 'mission critical' applications. somehow an airplane seems kinda critical? sounds more like VxWorks or QNX would be appropriate.
What has the operating system got to do with UAV?
It pays the bills.
(One might also ask, with all of those sponsors, what exactly was there left for them to do?)
Yes, they were given grant money from Microsoft, but that wasn't the only influence in their decisions. They've put long hard hours into the plane. XP Embedded does allow them to add functionality to the plane. A lot of companies have given then grants and sponsorships that have allowed them to build the plane. Don't forget this is Cornell here and they're not going to just rely on Microsoft to make the plane run. They also weren't attempting to make a "real" plane - this is still an UAV which isn't meant to have the power of a full aeronautical vehicle.
Unfortionatly one of their planes was destroyed in a fire at a hotel in Maryland while they went down to show off the plane. Luckily, their backup plane that is still being built was not destroyed.
Haven't seen the EULA for XP embedded but the consumer one says do not use for 'mission critical' applications.
The EULA for XP Embedded says nothing of the sort.
XP embedded is quite robust due to its scalability.
When creating an version of it for a machine, you can pick and choose what you want to use and contain. "Lets see... I do not want FAT/FAT32 support but I do want NTFS... no need for a GUI display here... yea... better leave out sol. and calc.exe."
The setup system for XPE is quite powerful and when you decide to add or remove one component, it'll tell you everything that it depends on and that depends on it to ensure that dependencies are satisfied.
Because of this scalability, you can strip down an XPE install to practically nothing, with no unnecessary processes/apps in the background and only what you want running you end up with a very stable system.
Help Brendan pay off his student loans
Apparently you didn't read the link. I shouldn't be surprised, this is slashdot. =P
Anyway, that was an interesting story posted on slashdot a loooong time ago. THe guy bought off-the-shelf (Internet) components online and used them to cheaply assemble an autonomous cruise missle in his garage to prove that such a thing is a legitimate threat potentially weilded by terrorists. Unfortunately, governments of the world largely ignore this threat, and New Zealand even decided that, although they considered what he was doing legal, it wasn't appropriate and effectively censored it.
seriously, this is nothing but a joke. avionics software does NOT use 1GB of storage, nor does it run a PC-oriented OS (be it XP or linux).
RealTime Linux incidentally, is used by Pratt & Whitney - they should know a thing or two about aircraft control.
Avionics software still doesn't use a "PC-oriented OS" huh?
Too much to ask to read the article?
quote:
The system runs off two 512 MB compact flash cards, which provides a storage system with no moving parts able to withstand up to 10,000 Gs. One compact flash card holds the operating system in a protected write mode, while the other stores a real-time flight log - a 'black box' that can be examined to diagnose problems, even if the vehicle crashes.
"Im drowning here, and you're describing the water!"
Half of that memory is used as a flight recorder. Like it says in the article.
It's never too late to have a happy childhood.
Right, so I'm actually on the team.
:)
Rather than you all speculate (rather sarcastically and incorrectly) about how we do things, why don't I actually tell you?
First off: We couldn't have written the software without XP Embedded. Just to get that out in the open. Couldn't have done it.
Testing code on custom chips is *slow* (We have a couple systems that use custom ATMEL 8-bit microprocessors). If we had to write the bulk of our flight control software on those, we'd never get anywhere.
With XP Embedded, we were able to write our code on normal Windows desktops, and run it right there in simulator mode. Once we got as many bugs worked out there as we could, then we could move it down onto the plane.
Also, we use a *lot* of hardware. Sure, it's possible that we could've hand-written assembly language for ATMEL chips to do everything. Turing completeness states that's a truth. But realistically speaking, we'd never get it done before we graduated. For one thing: We have a wireless modem link to a ground station that can monitor the plane. It was hard enough designing a protocol and implementing that to get the data down to the ground. The last thing I wanted to do on top of this is write the driver for the serial modem itself!
Since we were able to take advantage of existing development tools, though, that inital hurdle was quickly cleared.
As for whomever thinks we fly the plane "using flight simulator:"
It's really much simpler than that.
The plane flies itself by its knowledge of its position through GPS and its orientation through a gyro.
Before the plane launches, we feed it in a set of GPS waypoints we want it to fly through. (The flight control protocol we're shooting for next year will allow in-flight course changes.) The plane sees its position, sees where it wants to be next, and goes there. No flight simulator involved. If the target is to the plane's left, it flips the ailerons and it turns left. That's all it does.
That having been said, we did use Flight Simulator for testing. Our software was able to fly planes around in Flight Sim 2004 long before we loaded it into the real plane -- an enormous time, money, and effort saver.
The plane would run for about a half hour. This is a function of the size of the fuel tanks for the engine. I do not believe we ever flew the plane for more than about eight-ten minutes though.
:)
:)
:) The vast majority of the weight was the batteries. We put all the electronics in, and then just crammed as many batteries as we could in with it all to keep it running as long as possible. (I don't know how much of the weight was airframe and the 30 cc engine and whatnot.)
:)
The battery systems would run the computer for about 90 minutes, I think we calculated. When it was on the ground, we could jack it in to some heavy lead acid cells for extra life/recharging the onboard batteries.
And yes, LiPoly's are pretty sketchy technology. Great energy density, but that's what makes them dangerous. We've always treated them with respect, but now we've got a *much* healthier fear of them. I've heard of people who seal them inside large pyrex cookware when they charge them. I think we're heading out to Target for some of those ourselves.
Operating range. Hm. Well, that depends and what you mean by operating range...
The plane's top airspeed (I think; I'm just trying to pull this out of my head) was around 60 Km/H. So, if it could run for 30 minutes, it could make it 30 Km if you had no intention of ever getting it back, or were planning to follow it in a car.
Our serial modems were theoretically maxed out at 10 miles. But this varied on any number of things (radio frequency stuff is a devil's art)... their altitude, your altitude, things around you, if you were using their antennas or some bigger ones, atmospheric conditions... At some point we brought one modem up to the top of a tall building, drove across campus with the other one, and still got a carrier. So, we know they work for at least a mile.
But the serial modems aren't required for the plane to operate. It broadcasts back its data (position, speed, etc) to us over the link. And we could control it over the link ([dis]engage autopilot, etc); so, there's the range on that. But the autopilot itself would run without the monitoring link up.
Now, there is the safety cut-off though. At any time, by flipping a switch on the RC controller, we could bring it back to manual override, and a human pilot could guide it down. We also had to install (by law, I believe) a chip that would force the plane to hold a tight circle if it ever lost connection to the RC controller. As you might imagine, 25 lbs flying at 60 Km/H into somebody with a propellor screaming away on the front can be lethal. So if it's ever out of human control, it has to either intentionally ground itself immediately, or go into a holding pattern. I think the max range on our RC controllers is about a mile.
That having been said, we do not operate our plane out of visual range. I think the farthest away from us we've ever flown in a given direction is about 800 yards.
Our plane weighed 25 lbs, fully topped out with 1 L of fuel, and that was about the most it could handle and still be responsive. Do the conversion to metric yourself.
I'm just a programmer; I'm not one of the mechanical engineers, so I largely didn't concern myself with that stuff
It was all assembled in a different lab and everything.
So, that's it for our "current" specs. It's just a test platform. The idea is that this plane only operates right over our heads, because we want absolute control. But we see applications in all sorts of fields -- search and rescue being the "sexiest." The plane doesn't take too much skill to set up; our software is really very automated. So ideally, you could give these to forestry services, and they could deploy a few planes programmed to fly in large high squares over some backwoods area that would be difficult to hike up and search manually (steep hills, lots of snow, etc). You'd just sit and watch the video stream coming back, and look for signs of people. The plane could run a ten mile flight, out of human control, and then return itself to base when it's done.