Slashdot Mirror
Tom's Looks at Two DARPA Grand Challengers
skeeball writes "As a follow-up to this article, Tom's Hardware has a behind the scenes article on two of the teams competing in the DARPA Grand Challenge 2005. "The Defense Advanced Research Projects Agency (DARPA) hosted the first Grand Challenge Project last year, offering a reward of $1 million. This year, the prize money has been doubled, making the competition all the more interesting.""
This just goes to show all the money that is being tossed at defence research. If you can even give the smallest example of how your research can be used for defense you are almost guarenteed to get grant money. I know many researchers who do just that just to get their projects funded.
Voice your opinion!
Off the shelf hardware: we use one P4 3.2Ghz for general control, and an Athlon64 3800+ for vision processing.
Software wise, it's a bit of a hodgepodge-- we fully recognize the need to clean it up. The control comp is using Windows Server 2003, and most of it is written in C#, simply because it helps us to develop interfaces with our control hardware quickly.
The vision computer runs gentoo Linux, 2.6.12 kernel. All the vision code is written in C-- simply because that's what most of us are most comfortable with. Whether or not we port our C code to C#, or back port our C# code to C remains to be seen.
Notable features? We use three primary sensors: GPS, Vision (stereo and single lens cameras) and LIDAR. We take immense pride in the fact that our primary lane detection camera is a $100 webcam operating at 640x480 resolution. Our design is robust enough that the car can continue on its merry way even if two of the three primary sensors are taken out of action.
We absolutely refused to shell out 10K (250K in some cases) for a commerical LIDAR solution. We basically built, stabilized and hardened our own LIDAR. The judges are out on whether or not its better than commercially available solutions, but it certainly equals any (reasonably priced) solution out there-- and my buddy and I built it for only 2.5K.
Algorithm-wise, we're taking the mountaineer option instead of the God option. That means that we're using genetic optimization techniques in conjunction with kalman filters to 'grow' our way around obstacles and stay within bounds instead of detecting every single obstacle in an x km radius, plotting it and calculating splines/best possible courses through the minefield. The three inexperienced freshmen came up with this solution... and in most of our benchmarks, it doesn't take more than 45% of our control CPU's power to use this algorithm.
We're not trying for overkill. Our objective when we started the project was to find out what was *just* enough to get past the course. This means that we've been able to keep our costs under control.
I'd direct you to our website... but we've not had the time to put one up. Eventually, we'll get around to it-- but right now, the car has taken priority.