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!
My money's on the TerraMax vehicle from Oshkosh Truck.
http://www.terramax.com/
Why is the vision processing so poor? I remember back in 1997 reading a paper on a system that could read American Sign Language in realtime using an Indigo Graphics Indy 2 workstation with builtin camera. Today's processing power is many times greater and better imaging can be accomplished by modern CCD's, so what is the fundamental problem? Are there just no algorithms capable of pulling the fundamental data like contour lines out of the image in real time, or can they do the basic but just get messed up by things like shadows or rock color changes?
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
"While there should be no misconception that the ultimate goal of DARPA is to turn autonomous vehicles into killing machines"
... should I?
... these people could be doing the exact same research without involving the US military... couldn't they? And, um, I suppose it's possible they could actually not give that research to the US military after they'd perfected it...
Feel I should at least mention the idea that doing really, really cool development for DARPA is the kind of thing you need to ask
Not sure if this is possible w/o yafw (yet another flame war) but someone has to say it
OK, I can see that one way or another if you build it the US military will get it, but it doesn't have to be soooooo, like, readily handed over. Could at least make them ask or something...
closed minded is as closed minded does
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.
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.
My buddies from prep school are in this and if you want to see some whiked pissah video clips (wmv), check this out:
Fully Remote Control:
http://howeandhowe.com/videos/remote.wmv
Adrenaline Junky:
http://howeandhowe.com/videos/Movie_0001.wmv
It never ceases to amaze me what New Englanders can do over an 8 month long wintah!
ummm, I got nothin'
Tommy, another project for this competition, was featured at the lastest JavaONE in San Francisco in July. You can find the link to the group here.
In addition to some really interesting technology, they've got a great video demonstrating the vehicle in action that drew whoops and applause in their talk at the conference.
-- Scott
...who will be responsible when someone gets hit by an autonomous vehicle?
I have actually talked to one of the handful of DARPA people who hatched this idea in the first place.
Interestingly, the primary motivation for this is for cargo and supply-line applications.
I am not saying that it couldn't be used for ground-based unmanned attack vehicles eventually, clearly it could. Eventually. But that kind of use would require a much smarter and more flexible maneuvering capability.
If you think about the requirements for a supply truck, they are pretty simple. Get from point A to point B, without getting stuck, or running over anyone. Requirements for an autonomous combat vehicle would be orders of magnitude more complex.
If you look at the situation in Iraq, a disproportionate number of people have been killed while driving trucks in supply convoys. It turns out that in the situation we have there truck driving is one of the most dangerous things a soldier can be doing.
Add to this the fact that you have long stretches of flat, uninhabited terrain, and you have a high-payoff "easy" starting point for automating supply vehicles.
As it turns out, about at least 80% of waging war is logistics. Figuring out not only how to get soldiers and equipment to a certain place, but also how to bring all the supporting parts, like food, fuel, ammunition, and establish a supply chain to continually bring more. All while the forces keep moving. In a location where you had no presence just days before, and where you now have forces spread out over hundreds of miles, this can be very difficult.
Automated supply vehicles could do a lot to help in this kind of situation. If you look at how the challenge is set up, it might look a bit similar to the challenges faced by a supply vehicle in Iraq.
"I don't know half of you half as well as I should like, and I like less than half of you half as well as you deserve."
What is this sovereign nation BS. So what? Iraq was led by a dictator. Who appointed him dictator? No one. He appointed himself. He started a war with Iran that led to the deaths of millions (no exaggeration). He killed hundreds of thousands of his own countrymen. He funded Palestinian suicide bombers. He harbored Abu Abbas, Abu Nidal, and gave medical assistance to Zarqawi and was milking the Oil for Food program to fund a WMD project.
As for the nonsense that North Korea, Taiwan and China are preparing to ensure we will not do it again. What are you talking about? North Korea has long been in the process of making nuclear weapons. China is arming to ensure its status as a world power- it has nothing to do with Iraq. As for Taiwan, I do not know where you are coming from.