Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
Robotics Science

DARPA Announces 2005 Grand Challenge Semifinalists 132

Posted by timothy from the batmobile-lost-a-wheel-so-can't-enter dept.
Mockingbird writes "DARPA announced 40 semifinalists for the 2005 Grand Challenge autonomous robot race today. Notable remaining teams include the Carnegie Mellon University Red Team, Stanford Racing and a high school team, the Palos Verde Road Warriors. 78 teams missed the cut. The race, which will take place on Oct. 8, 2005 features a $2 million prize for the first team whose robot crosses 175 miles of the Mojave in under ten hours. The robots must be fully autonomous, with no team intervention allowed once the vehicle is launched. The first race was held in 2003, when the most successful team managed to log only 7.4 miles."
This discussion has been archived. No new comments can be posted.

DARPA Announces 2005 Grand Challenge Semifinalists More

DARPA Announces 2005 Grand Challenge Semifinalists

Comments Filter:
  • Yeah...I've seen their machine. It's pretty freakin' sweet. I do love the Linksys equipment glued (or something) to the top. At least they have good taste in technology :P
    • I went with some co-workers to watch team axion qualify near UCSD. Except for a bump with a trash can, it did pretty damn good. The driving control is much more rough than a human driver ever would, but I think they can pull it off.
  • And it's street legal! As far as I know, the first such vehicle to make that claim.

  • iRobot (Score:5, Funny)

    by Anonymous Coward on Monday June 06, 2005 @07:44PM (#12741626)
    The Roomba actually only made it 4 miles, but it cleaned up the competition...

    (groan)

  • Dont bother competing (Score:3, Funny)

    by Timesprout ( 579035 ) on Monday June 06, 2005 @07:44PM (#12741628)
    I have entered my Terminator this year as I think he needs to interact with other machines more, I still expect him to destroy all the other competitors but a day out and some challenge-response kaboom action will probably do him no harm. Also if your name happens to be John Conner I would recommend staying away from the competition site.

    • Re:Dont bother competing (Score:4, Insightful)

      by Rei ( 128717 ) on Monday June 06, 2005 @08:11PM (#12741849) Homepage
      Hey, don't joke too much: DARPA's end goal with challenges like this is to build fully robotic semi-autonomous armed combat vehicles.

      May I propose a new slogan for the contest: "DARPA Grand Challenge: Because An Army of Kill-Bots Will Make Them Like America Again!"

      I think that the first autonomous kill-bot that we make should have a big "We've Come To Bring You Freedom!" sign placed directly beneath its main gun turret, for the irony. ;)
      • Of course. The purpose of the military is to kill people and break things. Ask any Marine. If you can't accept that, you shouldn't be in the arms business. Entering the DARPA Grand Challenge is being in the arms business.
      • Actually, as I understand it, DARPA isn't looking for fully robotic semi-autonomous armed combat vehicles as it is looking for fully robotic semi-autonomous armed supply vehicles. That way, all the humans who now are driving the supply vehicles can drive the combat vehicles instead. Alternatively, this would allow one human in a Jeep to drive and guard a whole supply convoy.
        • ONE human? Sounds like a single point of failure. That guy gets capped and a whole buttload of supplies are stolen. How bout if no humans were in the convoy - that makes more sense.

        • Right... (Score:4, Insightful)

          by cr0sh ( 43134 ) on Monday June 06, 2005 @11:48PM (#12743343) Homepage
          If this [foster-miller.com] doesn't make you think they will slap the winning code into such a 'bot, nothing will.

          DARPA, and the DOD would *love* to have semi to full autonomous "kill bots" - in a way, today, they already have them for some tasks - they are called "cruise missles", which can be launched, told to stay on "hold" above possible targets, then commanded to strike on located targets. I would assume "located" likely means some form of lat/lon coordinates or painted with a laser (either by troops or from the air).

          The exact same thing could be done with a kill bot: send it to a predetermined position, and tell it to "hold fire" unless acted upon agressively, or if non-friendly comes into position (at which point it could bark a series of commands in different languages to the offender - think of it as an active landmine with intelligence that can move on command), which if not heeded, shoots a warning, then if continued, shoots to kill. Friendlies are identified by RFID or similar tags. Equip them with the ability to identify each other, as well as to flock or coordinate efforts with one another. Other commands could be something like "fire on ident", where they could be set up, then when a target is painted with a laser (perhaps from a troop's rifle), it fires on that target.

          You better bet that the DOD and DARPA would be all over such a system if it was proven field safe (to our troops) and easy/quick to use, and rugged. They are half way there with the TALON robots already, they just lack the rest of the package, which the Grand Challenge is dealing with...

          Of course, one can also easily see the potential of scaled up versions - robotic Humvees and M1A tanks, as well as robotic quads, and perhaps legged versions...

          BTW - this last was actually funded by DARPA back in the 1980's, which culminated in the Odetics, Inc. (now known as Iteris, Inc. [iteris.com] - based in Anaheim, California - interesting the strange things going on at this company, whatwith name changes, etc - plus, they are developers of an "electronic highway" concept - I am sure there is no relation to the Grand Challenge - wink, wink) ODEX-1 legged walker [inetnebr.com] - a very unique leg design that proved to be fairly robust and strong, while keeping outboard weight (on the legs) to an absolute minimum by moving all the electric motors inward toward the torso of the machine.

          Think about it - if you could, in addition to GPS coordinates, vision systems, etc - also bury in the ground or nearby some form of active or passive "locator" beacons, such as what Odetics - oops, I mean Iteris - is developing - wouldn't the problem become just a little bit simpler...?

          Nah - DARPA hasn't been thinking about this, not at all, not at all...

          • Yes, the military has had ideas about the application of technology that could create 'kill-bots', however, one has to realize that using sensors to determine terain is still a long way off from enemy/ally recognition. What's the use of making some Mechwarrior-type missle launching autonomous robot if it can only recognize moving targets? Anyone can be killed by that.

            Besides, not everything is black and white as a lot of people would like to make it seem. There are offensive capabilities granted by auton

      • Re:Dont bother competing (Score:4, Insightful)

        by DNS-and-BIND ( 461968 ) on Monday June 06, 2005 @11:06PM (#12743085) Homepage
        Don't be an asshat. The end goal is to build automated supply convoys.

        You really think that the armed forces would allow their budgets to be threatened by unmanned combat vehicles? Commanders only think about how many men they command.

        Oh, and your reference to killbots reminds me of the Simpsons, where Kent Brockman used ridiculously overhyped language to try and scare viewers. The Simpsons was making fun of the attitude you display in your post.

        • Don't be an asshat. The end goal is to build automated supply convoys.

          Automated supply convoys? Dude, you're dumber than a bag of bricks.

          A friend of mine does robotics work at CMU. He was building a "autonomous search and rescue vehicle" for the DoD, went through all the vision and mapping and what-have-you work and was appalled when he was supplied with the final control system and discovered that it sported a big red "Weapon" button.

          Nobody in the military is going to ask for funds to build an autono
      • "DARPA Grand Challenge: Because An Army of Kill-Bots Will Make Them Like America Again!"

        I don't want our enemies to like us, I want them dead.
      • The U.S. Military is going to a model where the "heavy lifting" of combat will be done by autonomous or semi-autonomous units. It is all about reducing training costs and the "political cost" of human lives.

        The Air Force is going to this model with the http://www.fas.org/man/dod-101/sys/ac/ucav.htm/ [fas.org]UCA V. You will F-22 fighters for Air-to-Air Superiority to control the skies as F-35 Joint Strike Fighter squadrons augmented with UCAVs take out ground targets. The UCAVs get the dangerous missions and t
  • Do they all run Linux?


    *duck*
  • "The vehicles must travel approximately 150 miles
    over rugged desert"

    Where did the 175 number come from?

  • Two Indiana Entries (Score:4, Interesting)

    by SeventyBang ( 858415 ) on Monday June 06, 2005 @07:51PM (#12741689)

    Today's Indianapolis Star [indystar.com]. The mention of Scott Jones - the guy who invented voicemail - has a good project background.

    People have been coming from all over the state (literally) to work on the project (just down the road a piece) on a very regular basis, just for the fun of it.

    I've talked to several people who have been tinkering with it and are having a good time. Sometimes, bordering on obsession.
  • I'm jumping for joy--This puts my team one step away from winning, and on top of that, it's all over Slashdot!!!

  • code for winning robot (Score:5, Funny)

    by SQLz ( 564901 ) on Monday June 06, 2005 @08:06PM (#12741811) Homepage Journal
    while(true) { follow_road(); }

    • Re:code for winning robot (Score:1, Funny)

      by Anonymous Coward
      while(1) {
      if(!on_road()) {
      get_on_road();
      } else {
      petal_to_the_metal_grandma();
      }
      if(crash()) {
      if((rand() % 2) == 1) {
      run();
      } else {
      give_middle_finger();
      run();
      }
      }
      if(being_p ulled_over()) {
      chassis_type(BRONCO);
      chassis_color(WHITE);
      f loor_it();
      }
      }

  • Gravity has this one in the bag. (Score:1, Funny)

    by Anonymous Coward
    "The race...features a $2 million prize for the first team whose robot crosses 175 miles of the Mojave in under ten hours."

    The winning design: Hummer + cinderblock.

    ;)

  • A few questions... (Score:3, Interesting)

    by BiggerIsBetter ( 682164 ) on Monday June 06, 2005 @08:08PM (#12741827)
    I'm a coder, not an AI or image-processing geek, so these might be dumb questions... but...

    Why the need for so many sensors? I can understand a use for them in low-visibility, eg dust or darkness, but the current models seem excessive to a layman. I mean, can one not use steroscopic cameras (scanning the field, as our eyes do), run edge and shade detection over the frames, and generate 3D terrain models in real time?

    How does a vehicle determin terrain density and route selection? Can terrain texture be estimated based on reflection or image matching, so the vehicle can decide not to drive over some water or a bog, for example?

    Even a good human driver is going to get stuck in the deset without learning how to handle a truck offroad. Is it feasible to train a neural-net system to select a likely course, possibly with a set of hardwired rules as a base? Eg, make your own way, but don't sink the car.

    I've no doubt this stuff is Hard, but much of this appears to be done via brute force...

    • Re:A few questions... (Score:5, Interesting)

      by neuroinf ( 584577 ) on Monday June 06, 2005 @08:13PM (#12741875) Homepage
      You need to look at the footage from the last attempts that showed how easily they become stranded on top of fence-posts. You wouldn't think it was possible to destroy a heavy vehicle like that, but a human will back off when hearing the gearbox squeal - not a computer. The vision stuff is an absolute nightmare - any sensor is better than vision. It sure is a serious challenge. I expect maybe 30 miles this time?

      • Re:A few questions... (Score:5, Interesting)

        by BiggerIsBetter ( 682164 ) on Monday June 06, 2005 @08:31PM (#12742018)
        There's a zillion ways to destroy a heavy vehicle, or parts thereof. Drivetrain seems to be a weak point in many offroad vehicles.

        Your post just says to me, add some mics and some audio processing! When you drive, you listen to the car. You learn what's normal for a given speed or condition, and any waveform that's out of sync flags an error. You stop, look around, back up, and try something else. I had to explain this to friend of mine the other day - it had never occured to her to listen to a engine (or transmission) to hear the load.

        If you really don't like audio, run a calc against axle speeds, engine RPM, clutch slip, figure out how much torque is where, and back off when something's close to breaking.
        • For those that don't know, it's quite amazing how much the average car does this already. As mentioned, things like RPM, individual wheel speeds, clutch slip, internal pressure sensors, temperature sensors, and just about anything else you can think of that could be remotely useful is monitored by the computer which can kick the drivetrain into various "limp home" modes and set off that damn check engine light.
        • You're better off doing audio - you only need one input device instead of a whole bunch of different sensors. And you have a really good point about how humans drive, in that out of place sounds inform us to all sorts of malfunctions.
        • Audio feedback came to my mind right away as well... I would add temp sensors for detecting above normal opperating temps.. I wonder what else is possible?

        • Re:A few questions... (Score:4, Insightful)

          by timeOday ( 582209 ) on Monday June 06, 2005 @09:43PM (#12742593)
          See, it's pretty easy to fix the bug that destroyed your vehicle last year. What's 1000x harder is to anticipate the bug that will destroy your vehicle this year.

          • You mean you don't test on anything other than what stopped you last year? When I test my code (which doesn't run cars across deserts) I create every situation I can think of to see what will happen. (This includes everything someone else has told me about that I remember/wrote down)

            You know where you failed. You know where your peers failed. You test for that. Then you test it again, because it might be luck that got you by. Then you build your own playground and start testing. I know of man

            • I was thinking that too. I'd even go as far as splitting the code up, and doing test-driven development.

              * Define a data model for the IO and AI.

              * Utilise an existing VR engine, and get a team working on the route navigation stuff. It doesn't have to be "real world" as the software doesn't know any different. Use topo maps or whatever, and work it until your virtual robot can navigate from A to B within the capabilities of the car and the world you give it, on the assumption that the IO system can produce
        • Exactly - another thing you tend to do when you drive a car is "feel" - so much about the road (and where it is coming from) can be felt through the steering wheel, the gas (and brake) pedals, the gearshift and clutch (if you aren't driving an automatic), and the seat of the vehicle - to let you know about various road conditions, etc - as you drive the vehicle.

          So, maybe a series of microphones, strain gauges, and other similar force sensors (beyond the usual inclinometers and such) on various portions of t

        • There's a zillion ways to destroy a heavy vehicle, or parts thereof.

          SNAAAAAAAAAAAAAAAAAAAAAKE!
    • IANAAIE (AI expert), but my intuition says that maintaining control of a large vehicle at 20+ MPH on rugged terrain requires one hell of a real-time sensor system. The system doesn't understand patterns as well as humans do just from stereoscopic images, so it has to compensate by gathering many other kinds of information in real-time. Also consider that the algorithms we normally use to process such information accurately can take a long time - longer than your average human reaction time.

      In theory, you

    • Re:A few questions... (Score:2, Insightful)

      by Anonymous Coward
      If it wasn't a Challenge, anybody could do it.
      2004 was Alpha. 2005 is Beta. 2006 will be Release.

      Even Microsoft takes 2-3 tries to get something right.

      Different teams are taking different approaches, but the more and different sensors you have, the more info you have to determine your environment.

      Some of it is Brute Force, for this problem. But, it still takes Smarts to finish at a decent speed. And last year, people finally got a clue as to how much Smarts it can actually take.

      So this year, it rea
    • Why the need for so many sensors?

      For the visual sensors, because sensors don't rotate or change focus like eyes so different angles are needed, different viewing distances, etc. For other types of sensors such as radar are needed for handling situations such as very dusty conditions, blinding light, low light, etc.

      How does a vehicle determin terrain density and route selection?

      Well the route is handled with GPS and maps and the route is at least somewhat navicable so it just follows the route, but

      • For the visual sensors, because sensors don't rotate or change focus like eyes so different angles are needed, different viewing distances, etc.

        Ah OK. I imagined focusable, rotatable cameras, on an isolated platform. I'm sure smarter folks than me have considered this, but I figured it would make sense to model terrain that way. Because that's how I do it. Maybe it's too slow.

        For the visual sensors, because sensors don't rotate or change focus like eyes so different angles are needed, different viewing

    • Why 3D Computer Vision is HARD (Score:5, Insightful)

      by TERdON ( 862570 ) on Monday June 06, 2005 @10:45PM (#12742953) Homepage
      Ah, coder? Do you have good knowledge of math too? Then YOU could possibly make the breakthrough in 3D Computer Vision.</IRONY>

      I'm studying a course in 3D Computer Vision [tu-harburg.de] right now, at TUHH [www.tuhh.de]. It's part of the Erasmus exchange program I'm having here - the eigth and last semester (excluding the thesiswork) of my master of engineering in automation and mechatronics at Chalmers [chalmers.se] in Gothenburg. I can easily say this course is the most difficult one of all I've been taking for all of my study time, hopefully the three weeks I have between that exam and the last of my others, will be enough to learn what doesn't stay in my head during the lectures...

      In fact, I have the course book right beside me. To begin, the description of it would be more or less along the lines "an orgy in linear algebra, mathematical statistics, with some flavouring of image processing, geometry, optimization and algorithms". Basically, it's 30-40% mathematical formulas, 650 pages, some containing things not even all MSc even learn like tensor notations etc. Not something I'm even sure is a good thing to recommend to very many slashdotters, even. You'll get its name though - "Multiple View Geometry in Computer Vision", by Hartley & Zisserman. ISBN 0-521-54051-8.

      What I see as problems in the book, is that almost everything is working on corner detection. This is great, if you want to make 3D-models of houses or other man-made objects (at least half of the examples in the book are architectural, I would say). It's not so great if you want to image bushes, rocks and other things with not so obvious corners on them. Also, the process involves quite heavy processing - both image processing, finding all those corners, statistical processing (to sort out outliers, which there will be), and optimization to find the best fitting backprojection of the image planes). I don't have a sure grip on the needed processing power but I doubt, when considering realtime demands in a car, that it'll hardly be easy to get it working.

      Also, it's still to a big deal itself an area under research. The situation with using 5+ images (from different cameras och just consecutive images from the same, moved camera), isn't very well known. Using more images, of course would mean a bigger chance to get a decent 3D model of the scene...

      And still, you would at least need two cameras to do anything useful. You can't reconstruct 3D space without having at least two images of the object to reconstruct. And probably you will need more - you would probably want to reconstruct all the way around (ie more cameras on the sides and backwards), and add extra sensors like radar etc for extra checks.

      And then you really haven't solved the problem of driving the car. You have only built a decent mapping of the 3D surroundings of it. You have to add AI/some kind of steering logic, which only in itself is a demanding task. Just look at all FPS games out there - if it would be easy to construct good AI, with a known 3D-world, tailormade for the figures, would we really be seeing that many games with crap-AI? I'm happy I ain't taking an AI course too, for sure!

    • There's an interesting paper on how to do SVD-correspondence [hp.com] for (corner-)features.
      One can determine optical flow from this and it would be useful for sensing the motion of a flying robot f.e.

      Another interesting paper is about using correlation [huji.ac.il] to estimate speed in an incremental way.

      You can see, that the problem gets feasible as soon as you restrict the domain sufficiently. Restricting the domain is crucial in computer-vision. Otherwise you'll end up searching for the holy grail of computer-vision ;-)

    • can one not use steroscopic cameras (scanning the field, as our eyes do)
      Is that heat coming off the desert road in front of us or water running across it?

      I've no doubt this stuff is Hard, but much of this appears to be done via brute force
      As much as this is a contest, it's also a massive brainstorming session. If nobody makes the finish line, but one team creates an elegant routing algorithm or one team designs an innovative rollover solution, DARPA wins. The prize money is peanuts compared to the mon

  • Go Golem! (Score:4, Interesting)

    by shadowmatter ( 734276 ) on Monday June 06, 2005 @09:12PM (#12742359)
    The Golem I [golemgroup.com] last year finished fourth, travelling 5.2 miles. It had the lowest budget of only $35,000 dollars (whereas some other teams' have a reputed budget of over a million...). And based on this image here [golemgroup.com], what I believe makes it uber-awesome is that they are cheating the competition by installing an elf under the hood and letting him drive.

  • First race was March 13, 2004 (Score:3, Informative)

    by KFury ( 19522 ) * on Monday June 06, 2005 @09:15PM (#12742377) Homepage
    Not 2003...
  • I'm somewhat curious as to who the 78 teams are that were cut from this.
    • GCART@RIT for one =.(
    • teams from princeton and MIT were also cut
    • Princeton University with a staff of 5 and a budget of under $5K. We made the list for alternate semifinalists, though.
    • We, MIT, blew out our steering motor three hours before our demo with DARPA and don't have funding to have replacements for everything (CMU) so we had to withdraw before showing what we had
      • Team Robomonster was cut.

        I was the real software lead, despite what is on their web page. After I tried to explain that Z course was hard (follow a Z gps path, but with 2 trash cans placed by darpa that had to be avoided). I wrote soem basic gps parsers, but they decided not to use them.

        The technical guy in charge, Pete, tried to get all the code from the net, and found some visual basic gps following code. They tried to update their servo's, but flashed a bad program, and as a result, at the site visit,
  • I think this is probably just about impossible. The plain fact is that you have to get 150 miles in 10 hours. That's an average of 15 miles per hour minimum. You obviously need to go faster than that.

    So I'm going into geek mode now and say that most of the time you need to be going 30 mph. So in one second (if i did my math right) you need to be able to see something ~14 meters in front of you. You most likely need at least a 5 second headstart since you have to break or turn. So about 60 meters sou
    • Last year, CM's red team used Lidar, or laser radar. They flipped their Hummer the night before the race, crushing about $400K worth of Raytheon equipment, and it all had to be replaced in one night. Lidar lets you build a pretty good 3d image of the stuff in front of you. CHeck out computer vision on the internet, the simple stuff isn't too difficult to do. I believe one team last year kept having their vehicle mistake bushes for mountains though.
    • That's why they call this the "DARPA Grand Challenge", not the "DARPA Mediocre Challenge" or the "DARPA Wussy Challenge". DARPA set the goal knowing that it would be nearly impossible in the first competition to create excitement.

      And by all accounts, it seems to have worked, since there are many thousands more researchers (ranging from PhD engineers to talented gearhead hobbyists) working in the field of auto-navigated land vehicles than before the challenge.

      And, for the record, I want the Golem Group to

  • Wired Mag on previous race results (Score:2, Informative)

    by Anonymous Coward
    Wired magazine has an pretty funny article on the results of the 2003 race with a description with what went wrong for each team.
    http://www.wired.com/wired/archive/12.05/start.htm l?pg=15 [wired.com]
  • "The race...features a $2 million prize for the first team whose robot crosses 175 miles of the Mojave in under ten hours.".
    Too bad most teams have already spent more than that. Oh well, it's the experience I guess. It makes my FIRST robot seem like legos! Personally, I will be rooting for PV high (1) because they are a high school team and (2) they are 5 miles away from me. However, it won't be done. I predict a maximum of 20 miles.
  • Hey all. I'm in charge of the actual pathplanner software for the OSU WAVE team. All of you should probably know that this whole DARPA thing is a joke. They don't want people to succeed. MIT, Princton, and even Ford didn't make it, but somehow my school did. Don't get me wrong, our software is freakin' amazing, but it was never used. The dumbest technology known to man that got lucky and passed 1/3 of the site visit tests got us through. I'm happy to be a part of this whole thing, but this whole thing is w
    • that doesn't really tell us anything we don't know. its darpa. its weird. film at ii?
    • I'm curious what the dumbest technology known to man actually is...
      • Sorry, I'm a little pissed at them and forgot to actually give any details. What they used was a knee-jerk reaction type technology. They use a couple of low-tech sonar units (kind of like what we used in high school physics) and have the car randomly turn left or right when that happens. There is a basic "global path planning" that follows GPS waypoints, but it isn't as reliable as luck.
  • I was rooting for a somewhat local team but they didn't qualify, probably will enter next year though.

    Their vehicle is pretty awesome, hope they can get some good navigation software worked out by next year. The vehicle can just drive over lots of obstacles that seem to get the various trucks and jeeps hung up, which gives it a good advantage, but they will probably need to "armor" it a bit from branches, posts, and loose rocks.

    Videos of the vehicle here: http://www.howeandhowe.com/videos.htm [howeandhowe.com]
  • How about a link to the actual press release [darpa.mil]??

    Something like five URLS in the story and not a single link directly to the semifinalists?

Slashdot Top Deals

Torque is cheap.

Close