Slashdot Mirror

The first attempt at DARPA Grand Challenge autonomous car race (http://en.wikipedia.org/wiki/DARPA_Grand_Challenge) made it less than 12km before getting stuck - in 2004. Now only nine years later people are talking about the imminent arrival of driverless vehicles.

I've made that point before. I was at the 2004 DRC (and in the 2005 one). The 2004 DRC was pathetic. It was covered by the Comedy Channel. The Ohio State entry (a huge Oskosh truck) ran into a parked vehicle at slow speed and pushed it for a while until DARPA people finally sent it an emergency stop signal. The CMU approach was to have a semitrailer full of people at workstations doing detailed manual path planning. The CD with the route was released an hour or so before the start, so their people had a short period to plan the exact path, using recent high-res aerial photos. DARPA's competition chief, an active-duty USMC colonel, found out they were pre-planning, and so, the night before, a few of his troops went out and moved some obstacles. This was the result. CMU's vehicle plowed right through a highly visible sheet metal fence. They were the most successful team. The others did much worse.

Then in 2005, there were 23 teams with working vehicles running around the California Motor Speedway, none running into anything. The second day of the 2005 Grand Challenge was the day the press suddenly recognized that automatic driving was real.

CMU's vehicle in 2004 did not get tripped up by a moved object, but rather by a GPS being 5 feet (or so) off.

Nah. Here's the detailed postmortem. Actually, they smashed through one fence (see photo), but the vehicle (a HUMMV) kept going. Then (per DARPA), ""At mile 7.4, on switchbacks in a mountainous section, vehicle went off course, got caught on a berm and rubber on the front wheels caught fire, which was quickly extinguished. Vehicle was command-disabled." There was a lot of spin after the fact from Red Whittaker on how it wasn't their fault.

All of the vehicles in 2005 that got to the semifinals had sensing good enough to avoid mistakes like that.

I used the Eaton VORAD automotive radar on a DARPA Grand Challenge vehicle. It's a useful little device. You get, for up to 20 targets, range, range rate, and azimuth. Targets smaller than a motorcycle usually do not show up. It will not see pedestrians at any useful range. Azimuth info accuracy isn't very good, but range and range rate are quite good. That's ten year old technology; the newer units are better. Those units have been on some big trucks for fifteen years. But the technology was too expensive for most cars. It's been appearing as "intelligent cruise control" on some cars for years.

The Eaton units, with the display and controller used for vehicles, supports accident reconstruction. The last 15 seconds are retained, and you can see what other vehicles in front were doing. Trucking companies find this useful, because they often can show that it was the other driver's fault.

Having done some work on automated driving, I have some misgivings about semi-automated driving. ABS, which is a huge advance in vehicle control, hasn't reduced accidents as much as it should. Driver overconfidence seems to increase in ABS-equipped vehicles. Merely adding automated braking, which has been around for years, may not help with passenger cars. It would probably encourage tailgating. It's a big win for heavy trucks, but they have pro drivers. Those guys aren't aggressive drivers, mostly tired ones. Passenger car drivers aren't that consistent.

Tailgating may be acceptable if there's a comm link between the car ahead and the car behind. That's been demonstrated successfully; if anybody in the chain starts to brake, everybody behind them brakes too. It needs to be coupled with enough smarts that not too many vehicles become a tight group, and a vehicle can't close up behind something that can stop shorter than it can.

Studies of crashes by Mercedes indicate that 80% of accidents would have been avoided if braking started 500ms sooner. Those aren't the severe accidents, though.

Anyway, while radar-controlled automated braking has its uses, it's not an answer in itself.

We actually used that line on our recruiting poster from our 2004 DARPA Grand Challenge team.

It's not a joke any more. Hasn't been for a while now.

We actually used that line on our recruiting poster from our 2004 DARPA Grand Challenge team.

It's not a joke any more. Hasn't been for a while now.

Here's some code of mine.

• mutexlock.h - queuing and locking primitives in C++ for QNX. Little primitives that have to be right, and are hard to code correctly. These ran on our DARPA Grand Challenge vehicle.
• algebra3.h - basic functions for 2D, 3D, and 4D matrices and vectors, all in C++ and all inline. The basic code is from Graphics Gems, but it's been rewritten to be 100% inline. Useful for game and graphics work. Used as part of Falling Bodies.
• obvious.c - the original obvious password detector, from 1984. Use this to decide if a password is "strong enough". Rejects all English words, yet doesn't require access to a dictionary file. Note this is in K&R C; it predates ANSI C.

This is a significant change in direction for Bill Gates. Up until 2000 or so, he'd publicly stated that robotics wasn't going anywhere.

I ran one of the DARPA Grand Challenge teams, Team Overbot, so I'm reasonably familar with what's going on in this area. It was amazing to me how much progress was made in three years. Much of the progress was in subsystems. Four years ago, a high precision combination GPS/INS/compass system cost about $100,000, and required 4U of rack space with air conditioning. (CMU's first vehicle actually had such a unit.) Now, such units are about $6K, the size of a thick book, and don't need A/C. LIDAR units have gone from mechanical line scanners to solid state 3D flash units; although these are still expensive, low-volume items, there's no fundamental reason they couldn't be brought down to camcorder prices.

More interestingly, computer vision in unstructured environments is actually starting to work. That was the real innovation in the Stanford vehicle - a vision system that could look at a distant section of a road and decide if it was similar to the nearby section. Several LIDAR units profiled the near section, and if the near section was OK and the far section was visually similar, the vehicle could outdrive its LIDAR range. I was amazed that that worked, but it did. It's a Bayesian statistics system, and quite clever.

Then there are the new generation of hobbyist robots. See Robots Dreams, which follows Japanese hobby robotics. You can get a good humanoid robot about 50cm high for about $1000 now. It's interesting how this happened. Robotics hobbyists have been playing around with R/C servos for decades, and quietly, under consumer pressure, those servos have been getting better. The motors used to be too weak, but better magnets fixed that. Then people complained of bearing failure, so the manufacturers switched to ball bearings. Then applied loads would sometimes strip gear teeth, so the manufacturers had to go to better gear materials. Then the things were overpowered for their dumb control algorithm, so each servo got an embedded micro controller. Then it was necessary to tune the control algorithm depending on load, so the interface became more intelligent and bidirectional. And suddenly we had servos strong enough for the legs of a small running robot.

In the hobbyist community, though, the software is way too dumb. Hobbyists are still using BASIC STAMPs and typically don't do much very exciting on the control front. By contrast, Grand Challenge vehicles typically had many CPUs running highly concurrent software. We had two Pentium IV machines running QNX and running about fifteen real time programs, along with five programmable motor controllers each closing some control loop. Gates is onto something with building better tools for hobbyist robotics. The Microsoft approach to robotics is clunky (it's a rehash of web technologies, including SOAP), but it has more integration than anything seen before, so it will catch on.

Once we get the theory and technology from the high end down into hobbyist level hardware, things are really going to take off. We have the parts now.

There are academic programs, but the US robotics industry is tiny. I have a slide I use in talks; it compares total spending on robots, mobile robots, and ringtones. Ringtones are far bigger.

Robot R&D in Japan is serious, but in the US, it's the same old academic groups grinding away. The number of US commercial companies shipping products in the mobile robot space is very small, as is number of units shipped. Above the Roomba/toy level, there just aren't any volume applications. This seriously limits job and business prospects. There's a market in teleoperators for bomb disposal applications, and the machinery developed for that is quite nice, but it's not autonomous.

Even industrial robotics and factory automation is declining in the US. With manufacturing moving offshore to low-wage countries, the end of union labor, and a huge supply of illegal immigrants, plants are less automated than they were twenty years ago. The original Macintosh had less assembly labor in it than today's PCs. I can't recommend a US career in manufacturing engineering today.

Robot hardware is better than ever. The Lego Mindstorms stuff is primitive, but around $1000, things get quite good. Check out RoboNova. Further upscale, see Mobile Robots, Inc.

The theory is getting better. Vision is starting to work. Planning actually works in the real world now. Adaptive control and learning finally work. There's enough CPU power to do hard stuff in real time on cheap hardware. Much is technically possible. But the market isn't there.

I ran one of the DARPA Grand Challenge teams. That didn't really lead anywhere. The two best young people we had are doing very well, but not in robotics. One is running a hedge fund and one is working for an offshore derivatives fund. Of the older people, one is running a big web server farm, and one has retired. If you understand all the practical stuff and all the theoretical stuff to operate at that level, you can do very well at other things. But the payoff isn't in robotics.

This field needs a killer app.

Go to Wall Street, make money, then do whatever you want.

Of the best people we had on our DARPA Grand Challenge team, one is runnning a hedge fund in Santa Fe, and one is working on derivatives for a Wall Street firm.

I ran one of the DARPA Grand Challenge teams, Team Overbot. I'm not sure there really are "careers in robotics". Of our best young people, one is now running a hedge fund, and the other is working for a financial derivatives firm in New York. Neither of them could find anything in robotics with a big payoff.

With 12 million illegal immigrants, the US doesn't need robots. Japan, though...

The next DARPA Grand Challenge requires operating in congested areas, and that's going to require serious work on robot vehicle safety. The way this is going, those things are going to be rolling through small towns in hostile territory in a few years, and they'd better not be running over little kids.

The problem with QNX is its marketing. There's no good entry level option. A development seat costs several thousand dollars, and there's not even an posted price for it. You have to talk to sales reps. Once you've bought a development seat, you can crank out vast numbers of embedded devices using QNX, so it's priced for the volume manufacturer. So few people learn QNX unless they have to.

Most Linux and QNX command line stuff has been ported to QNX. GCC is the main compiler. All the GNU command line tools work. You can even run Samba and Apache. X-Windows can be run, although it's not QNX's native graphics system. So conversion isn't that hard.

For a brief period of two years, QNX tried to open up and get more users. There was an "Open QNX" effort, a "No Charge" version for noncommercial use, and a reasonable level of interest from the open source community. Mozilla was ported to QNX. Then, with no real announcement, QNX cut that program off. You can still get a 30 day free evaluation version, but you have to ask. After 30 days it will still run, but the development environment (Eclipse) turns off.

Then QNX was acquired by Harmon International, the parent company of a range of audio companies. This resulted in 1) a focus on QNX for automotive "infotainment", and 2) abandonment of QNX by Harmon's competitors. Embedded users couldn't figure out where QNX was going, and many gave up. Lately, QNX seems to be making a modest comeback, but it's hard to tell.

To be fair, QNX has survived in a tough market. They've been selling a proprietary OS that can run on x86 desktops for two decades, against Microsoft. Nobody else has stayed in business doing that. Microsoft attempted to acquire QNX at one point, to use it as "Windows CE", but was turned down.

So it's a good technology, but the company drives you nuts.

The problem with QNX is its marketing. There's no good entry level option. A development seat costs several thousand dollars, and there's not even an posted price for it. You have to talk to sales reps. Once you've bought a development seat, you can crank out vast numbers of embedded devices using QNX, so it's priced for the volume manufacturer. So few people learn QNX unless they have to.

Most Linux and QNX command line stuff has been ported to QNX. GCC is the main compiler. All the GNU command line tools work. You can even run Samba and Apache. X-Windows can be run, although it's not QNX's native graphics system. So conversion isn't that hard.

For a brief period of two years, QNX tried to open up and get more users. There was an "Open QNX" effort, a "No Charge" version for noncommercial use, and a reasonable level of interest from the open source community. Mozilla was ported to QNX. Then, with no real announcement, QNX cut that program off. You can still get a 30 day free evaluation version, but you have to ask. After 30 days it will still run, but the development environment (Eclipse) turns off.

Then QNX was acquired by Harmon International, the parent company of a range of audio companies. This resulted in 1) a focus on QNX for automotive "infotainment", and 2) abandonment of QNX by Harmon's competitors. Embedded users couldn't figure out where QNX was going, and many gave up. Lately, QNX seems to be making a modest comeback, but it's hard to tell.

To be fair, QNX has survived in a tough market. They've been selling a proprietary OS that can run on x86 desktops for two decades, against Microsoft. Nobody else has stayed in business doing that. Microsoft attempted to acquire QNX at one point, to use it as "Windows CE", but was turned down.

So it's a good technology, but the company drives you nuts.

The big challenge this time is that now real situational awareness is required. Much better sensing will be needed. There are some new technologies out there that can probably do the job. Last year's sensing systems were actually rather marginal.

Here's the formal solicitation from DARPA, which has more details. Basically, DARPA will provide a "road map", as a file, which indicates all the streets and stop signs. (Traffic light sensing is not required). Then, just before the start, DARPA will provide a "mission file", which specifies the start point, checkpoints to be passed, and the goal. Vehicles must be able to park, unpark, do a 3-point turn, discover that a route is blocked and switch to another route, and merge into traffic. The goals are ambitious, but I expect they'll be achieved within two cycles of this Grand Challenge.

As for applications, Dr. Tether said at the last GC that he now expects to field some of this technology within five years. I expect to see some automated driving for convoy vehicles deployed. The whole convoy might not be autonomous, but autonomous vehicles that can intelligently follow a lead vehicle will be very useful. The escort troops will be in something with armor and firepower, like a Bradley, while the trucks trail along behind. This will be popular with the guys whose current job description is "target".

But, sadly, I wouldn't recommend QNX for a new startup that doesn't absolutely need hard real time. Since QNX was acquired by Harmon (the parent of JBL, Harmon-Kardon, and various other audio companies), the company hasn't been working at keeping small customers happy. The lead architect of QNX died about two years ago, and there's been a brainpower exodus since then. The last third party books about QNX have gone out of print. The free version of QNX has been discontinued, and so the open source community is doing few, if any, QNX ports.

It's a great technology. But the marketing and support end of the company is focusing on major automotive suppliers. If you're not in that space (or you compete with any of Harmon's business units) you're probably not going to be happy.

I was never that impressed with the CMU approach. All that manual preplanning was an obvious dead end. And the giant mechanically stablized gimbal was just too clunky. It didn't help them in 2004, when they hit an obstacle placed by DARPA, and it didn't help them in 2005, when DARPA moved the racecourse from California to Nevada to prevent preplanning. The Air Force colonel in charge for 2005 said preplanning wouldn't work, and he meant it.

Computer vision of the natural world is finally about to take off, after three decades of frustration. It's probably possible to do much of the early vision processing in a current-generation GPU, which may make it affordable. Look for new apps that connect to cameras and pick out items of interest. Read that paper linked above.

Some comments I've written:

• From a physics engine:

  // The contact force component is aligned with the vector between
  // the two closest points. The frictional force is in a plane
  // perpendicular to that vector and through the midpoint of pnt0-pnt1,
  // The frictional force vector is opposite the velocity vector
  // component in the friction plane.

  // Witness point checks.
  // All witness points must be on their polyhedron's side of the
  // separating plane.

  Here the purpose of the comments is to explain the math.

• From the control code for a DARPA Grand Challenge vehicle. Here's some code I wasn't happy with, so that's clearly noted.

  // constructPath2 -- reactive obstacle avoidance and path planning
  // - the hard cases
  //
  // Called when we have to do some obstacle avoidance
  //
  // Path is an output only.
  //
  // First pass tries to find some path that will work within the turning limits.
  // If that fails, we try "brake then steer" mode - look for the longest path
  // in any direction, regardless of dynamics limits, and slam on the brakes
  // while turning. The actual steering command will be limited later.
  // ***MAKE SURE THAT CHECK IS MADE***
  //
  // ***NEEDS WORK***
  // ***SEARCHING OUTSIDE LIMITS WILL ALWAYS FAIL***
  //

• Finally, here's some Perl code, part of the code that runs Downside.

  #
  # extractsecurityclass -- extract class of a NASDAQ security
  #
  # Foreign and bank securities aren't filed with the SEC, so
  # we need to note this. There are also test and statistics items that
  # aren't real securities.
  #
  # Note that the test for "bank" is rather poor. NASDAQ used to
  # identify banks using a column in the table, but they no longer do so.
  #
  sub extractsecurityclass($)
  { my $vals = shift;
  ## Check for symbols that don't file with the SEC
  if (${$vals}{'test_issue'} ne 'N') { return('test'); } ## is test

  (We have to stop there; Slashdot's "lameness filter" rejects Perl code.)

All code should have well-written comments. As Wirth pointed out years ago, people who can't express themselves well in their native language are generally poor programmers.

No, device drivers in QNX are in 100% in user space. I've written one, for FireWire cameras. Manual page here.

QNX device drivers can have the privilege of mapping device memory into their address space, but they're still user-level programs. I've developed hardware drivers on a running QNX system without rebooting.

Our first hat was a stainless steel mixing bowl. GPS reception continued. We were even able to get WAAS and Omnistar HP lockup with the mixing bowl on top of the antenna.

An actual tinfoil hat cut off more of GPS, but we could still get "single" GPS signals, although not the corrections for Omnistar.

So the radiolocation bands really do get through.

Our first hat was a stainless steel mixing bowl. GPS reception continued. We were even able to get WAAS and Omnistar HP lockup with the mixing bowl on top of the antenna.

An actual tinfoil hat cut off more of GPS, but we could still get "single" GPS signals, although not the corrections for Omnistar.

So the radiolocation bands really do get through.

Funding is more of an issue. Teams were supposed to have no Government funding whatsoever, either direct or indirect. Yet MITRE had a team, and they're a quasi-governmental agency. CMU has received DARPA robotics contracts for years, as has Stanford. Red Whittaker of the CMU team is still the principal investigator on a NASA grant (#NAG5-12890) until February 2006. Stanford used software developed under DoD contract, although anyone can download it and they asked DARPA for permission. It's more of a revolving-door issue than direct diversion of Government funds.

But the real incentive for the big university teams was fear. If Joe's Auto Parts fielded a better robot than some university getting $20 million a year in robotics funding from DARPA, DARPA might well pull the plug on the school. CMU faced that prospect; originally, they weren't going to enter the Grand Challenge at all. The whole Grand Challenge was created because of unhappiness at DARPA with the rate of progress in mobile robotics. DARPA has been pouring robotics money into CMU and Stanford for thirty years, without getting much back. The head of DARPA, Dr. Tony Tether, decided that it was time to do something about that. It worked.

What's really making this go is not new technology, but money. Most of the designs are quite straightforward. But nobody in the US has ever spent money at this rate in robotics research. CMU spent $3 million last year, and this year the total costs of their efforts were much higher. The major teams have direct engineering support, including on-site people, from major auto and aerospace companies. Huge field test and support operations have made it possible to pound existing technology into working shape by sheer debugging effort.

Most entries have a bunch of LIDAR line scanners as their primary sensors. Some also have vision systems, but usually those systems don't do much. At best, they're just depth from stereo or road following. Nobody has image understanding. But with enough hammering, those technologies can be made to do the job, more or less.

Anyway, it was great fun being part of it. But we won't do it again. We'll leave that to the organizations that get Government funding. For them, it's a marketing expense.

John Nagle
Team Overbot.

First, every entry this year is far, far better than anything last year. Everybody has something that really can drive itself. Last year, only 7 of 20 entries made it out of the start area. This year, a big fraction of the teams are getting clean runs. So many are succeeding that tomorrow, DARPA is making the obstacles harder.

Most of the technology is not that innovative. But there are some very clever entries. The self-balancing motorcycle actually works this year.

The price of entry is going up. Last year, it looked like Battlebots. This year, it's starting to look like NASCAR. Several teams have large custom-built trailers. Sometimes I feel like we brought a knife to a gunfight.

No time for much more tonight; we're scheduled for the track at 0715 tomorrow.

John Nagle

Experience with ABS systems is instructive. ABS systems definitely improve braking, but don't reduce accidents. Drivers with ABS use their shorter stopping distance to follow more closely, cancelling out the safety benefits.

I run one of the DARPA Grand Challenge teams, which requires somewhat better technology. The current Grand Challenge technology is clunky (everybody has huge, mechanically scanned LIDAR devices or weak vision systems), but true solid state eye-safe outdoor 3D LIDAR imaging devices are just becoming available. With that technology, doing this right is within reach.

So we have a line-scanning LIDAR on a tilt head, like CMU, which is an adequate but bulky solution..

We have two industrial Pentium 4 machines running QNX, on our Grand Challenge entry, along with five Galil programmable motor controllers. We have room for 3 CPUs, but the compute load fit on two of them, so we took the third one out.

Technically, QNX was an excellent choice, but because few people know it and many don't want to learn it, using it has made recruiting difficult.

There's a tendency in the RF world to run everything through BNC connectors, whether you need to or not. Signal generators and scopes usually come with BNC connectors, so if you have those, you tend to have lots of BNC-BNC cables around the bench. Plus the little drawer of T-connectors, angle connectors, and adapters. Hence its popularity in the ham, broadcast, and scientific instrument worlds.

The main problem with RCA connectors is that they bend and become loose as they wear out. That's why they're avoided in PA gear. XLR connectors self-align better and latch into place.

Actually, I do servomotor control, which has most of the problems of audio but with bigger currents. Keeping the huge chopped motor currents from inducing noise into nearby analog sensors is a major headache. But with extra capacitors and inductors, it's a solveable problem.

In any case, without a scope you can't do anything but guess.

The ARRL Handbook is a good source for info about power supply filtering.

For comparison, here is our camera interface on QNX. It's possible to have a much more straightforward API. Much of the problem is that the Linux video API predates the more responsive 2.6 kernel, so the driver can't assume real-time performance from the user client. This forces the queueing too far down and complicates the interface.

None of this the fault of the camera manufacturers or the camera spec. The DVCAM spec is available, published, and corresponds to what real cameras do.

Computers built for industrial temperature ranges are routinely underclocked. We have three underclocked Pentium 4 systems in the Overbot

It's awful. Latencies average around 30ms, with spikes to 120ms. Before we installed the Sveasoft crap, we could drive our robot vehicle remotely, using an older Linksys 802.11b unit with stock Linksys firmware. Now, the latency is so bad we can't. Fortunately, we usually drive it autonomously, and E-stop is on a completely separate radio link.

Worse, the Sveasoft software garbles TCP packets. If you have several TCP packets in flight, the later ones tend to get garbled. We've put packet sniffers on both sides of the link, and we can see the TCP packets getting trashed. It looks like the packet queueing is badly broken. Worse, they don't get trashed randomly. The trashing is repeatable and the TCP connection never recovers. It looks like some kind of stateful TCP firewall has gone horribly wrong. We have the Sveasoft firewall turned off, or at least as "off" as is offered by its options.

Non-TCP packets don't seem to get trashed in this way. So remote file access (NFS, QNX native networking) still works. And HTTP out to the Internet works. But local high-traffic TCP connections fail.

Most users probably don't see these problems because they're using these units to connect to the Internet through a slow uplink. So they never have a bottleneck across the WiFi link and don't get a packet backlog in the Sveasoft software. But try to talk to a local server using TCP. A CVS checkout from our local server over a pair of Linksys routers using the latest, licensed, paid-for Sveasoft software hangs. Every time, within ten seconds. (Works fine with a wired Ethernet connection.)

Attempts to get this fixed have dragged on for months. It's been reported to Sveasoft, of course.

So we definitely recommend against buying Sveasoft firmwere.

John Nagle

The expert systems people hit a wall in the mid-1980s. An expert system is really just a way of storing manually-created rules. And those rules are written with great difficulty. There used to be expert systems people claiming that strong AI would come from rule-based systems. (Read Feigenbaum's "The Fifth Generation"). You don't hear that any more.

Hill-climbing systems (which include neural nets, genetic algorithms, artificial evolution, and simulated annealing) all work by trying to optimize some evaluation function. If the evaluation function is getting better, progress is being made. But what this really means is that the answer is encoded in the evaluation function. If the evaluation function is noisy (as in, "does the creature survive") and requires major simultaneous changes to make progress (as in "evolutionary jumps"), hill climbing doesn't work very well. There is progress, though. Koza's group at Stanford is moving forward, slowly.

The formal logic people never made much progress on real-world problems. Formalizing the problem is the hard part. Once the right formalism has been found, the manipulation required to solve it isn't that hard. There's not much work going on there any more.

The reactive robotics people also hit a wall. Literally, as every Roomba owner knows. Reactive control will get you up to the low end of insect-level AI, but then you're stuck.

Reverse-engineering brains still has promise, but we can't do it yet. Progress is coming from trying to reverse engineer simple animals like sea slugs. (Sea slugs have about 20,000 neurons. Big ones.) Efforts are underway to completely work out the wiring. Mammals are a long ways off.

Lately, there's been a trend towards "faking AI". This comes under such names as "social computing". The idea is to pick up cues and act intelligent when interacting with humans, even if there's no comprehension. This may have applications in the call center industry, but it's not intelligence.

I run one of the DARPA Grand Challenge teams, Team Overbot. On a problem like that, you can definitively fail, which means there's the potential for real progress. That's why it's worth doing.

And the relevant help page is a dead link.

Good concept, needs work.

One of our biggest problems in Silicon Valley has been finding a big open space in which to test. We now have access to a huge parking lot built during the dot-com boom, adjacent to an unfinished building complex. So we have the Overbot winding in and out among the parking islands. We'll be testing there today in a few hours.

In terms of technology, Team DAD probably is most innnovative. Everything runs on digital signal processors. They're building their own laser rangefinder this year. Last year, they got further than anybody else without wrecking. (CMU crashed three times; their HUMMV was able to survive the first two.)

Nobody seems to have a breakthrough in sensing. (By this I mean sensing good enough to evaluate terrain. Detecting big, solid obstacles is trivial.) LIDAR line scanners are too limited, stereo vision doesn't register well on dirt, and strong intelligent vision processing requires a breakthrough that twenty years of research has failed to produce. The breakthrough needed is flash LIDAR, which exists, but wasn't ready soon enough for this year's Grand Challenge. (The rules prohibit the use of Government-funded patented technology not available for general sale by last August, and the good flash LIDAR wasn't available in time.) CMU has a LIDAR line scanner on a giant gimbal, and we have a LIDAR line scanner on an overly large tilt head, but that's an interim solution and a technical dead end.

On the other hand, GPS and inertial gear gets better and cheaper every year. It's surprising how good it is.

This year, everybody who makes it to the starting line should disappear over the horizon at the start. The minimal level of performance to make it through the "site visit" hurdle is above that demonstrated by most of the vehicles entered last year.

And this year, DARPA is putting tank traps on the course.

Team Overbot, Silicon Valley's entry in the DARPA Grand Challenge, is hiring.

Coolest robotics project in the area. Great resume builder.

C++. GCC. Python. Geometry math. Electronics work. Field testing. Hard problems. Not boring.

In Redwood City, CA.

After some enhancement in Photoshop, here's what it really looks like. It resembles a very basic mini-ITX box. No connectors are visible.

The Eaton VORAD anti-collision radar does just that. It tracks up to 20 targets in front of your vehicle. The main purpose is to help prevent accidents; you get a loud alarm, and some versions will start braking on their own. But it also logs information. Range, range rate, and azimuth are captured, along with the vehicle's own data (speed, turning angles braking, etc.) Accidents can be reconstructed from that data. It's especially good for demonstrating that some other vehicle ran a stop sign.

There are about 20,000 of those units on the road, mostly on heavy trucks.

We use VORAD units here at Overbot, For test purposes, This is far more advanced than a speed gun; it's a true phased-array steerable radar. You get tracking data. I've had one pointed out a window overlooking an intersection, and have software that lets me watch the traffic go by. You can reliably see cars and motorcycles; bicycles and strollers are marginal targets.

As one of the Grand Challenge team leaders, I follow this subject rather closely. It's actually a rather stupid article for EE Times. They have canned pictures of MEMS accelerometers, a picture of an ordinary SUV going through water lifted from early Grand Challenge materials, and the inevitable "car talking to satellite" drawing. There's little mention of the real problems. It's not about compute power.

Automatic driving needs either more intelligent visual processing than anything we have now, or better sensors than we have now. I think we'll get the sensors first.

Visual processing can detect big things like other cars, but detecting a pothole is tough. Stereo doesn't really profile ground all that well. You need edges for the correlator to lock up.

True range sensors are more useful. Existing scanning laser rangefinder devices are marginal, but there's better stuff coming. The mechanically scanned devices are too clunky. All solid state devices do exist. I've seen some impressive demos on an optical bench, and that technology will be fieldable soon.

Submillimeter radar also has potential, but it's not here yet. Millimeter radar, however, works fine and is quite useful for seeing anything bigger than a bicycle.

Incidentally, although they don't publicize it, the CMU Grand Challenge vehicle didn't really use Itaniums. Yes, Intel donated Itaniums, and the press releases say they were used, but the Itaniums were damaged before the main event and were replaced with ordinary x86 machines.

I run one of the DARPA Grand Challenge teams, and I'm up-front about the military implications. Some of the academic teams don't want to admit they're part of a weapons program. But they are.

Here's your opportunity to become an Evil Genius in the real world. We're hiring minions to build our army of killer robots. Must know C++ and be in Silicon Valley. Game programming experience a plus. Help build America's robot army!

See our video (6MB, Quicktime) here. This is our DARPA Grand Challenge vehicle.

See our video (6MB, Quicktime) here. This is our DARPA Grand Challenge vehicle.

How wierd. We use QNX for our DARPA Grand Challenge vehicle, but none of the Animats animation software runs on QNX. I have no connection with QSSL, the company that puts out QNX, other than as a user.

What I like about QNX, though, is that it demonstrates that you can build a stable microkernel OS that does everything people expect today on a desktop. It's not technically necessary to have a multimillion line kernel that you'll be patching forever. You pay a 10-20% overhead for message passing. In exchange, you get a microkernel small enough to debug thoroughly. There's only about 100K bytes of code in the QNX kernel. And it changes rarely. The last significant API change was when 64-bit memory allocation went in.

OpenGL and video playback were added without kernel mods. That demonstrates how flexible the low-level architecture is.

But very, very few microkernel developers have gotten it right. VM for IBM mainframes and QNX are the most notable successes. Note that both of those systems are noted for high uptime, as in years between crashes. I can't think of any academic OS project that resulted in a production-quality microkernel. (Mach 2, the basis for Apple's OS X, is a warmed-over BSD UNIX, and Mach 3, CMU's real microkernel, isn't used much.)

It should be feasible to make integrated silicon strain gauge/amplifier/interface chips, embed them in a flexible printed circuit, and laminate them into a skin-like laminate with appropriate tough, soft, and hard layers. But the processes involved are all high-volume ones - it's hard to do this economically in small volume. And there's no market for a process that turns out big rolls of this stuff.

There's a lot of stuff in robotics that's like that. Linear motors and laser scanners both cost about 20x what they should. because the volume is tiny. Even basic servomotos and servo amps cost 5x as much as they should, based on parts cost.

It's getting better, though. More and more parts needed in robotics are becoming off the shelf. I run a DARPA Grand Challenge team, and over the last year, many of the components you need for that have become far more available.

Then I ask them to send me 1000 lines of C++ they're proud of. Doesn't matter what it does; I just want to see how they code. Many of them look scared. "Is C OK?" "I'm not really that good at C++". "Can I use Python?".

When someone sends us code, I read it and send comments back. I'm looking for robustness. ("We have received your code sample. Your first buffer overflow is on line 52. Thank you for your interest in Team Overbot.") I'm looking for some basic knowledge of C++. I'm looking for a reasonable level of comments.

I think the number of good programmers out there is declining. There are hordes of sysadmins and low-level coders, more than ever, but most of them aren't that good.

John Nagle
Team Overbot

We're recruiting. Programmers, this time; we have most of the hardware working. Silicon Valley only; we're in Redwood City. Send us 1000 lines of C++ code that you're proud of. We'll be having an open house in late August. Watch the Overbot web site for details.

You can conformal-coat boards yourself, using Fine-L-Kote spray. We use this stuff on the Overbot.

It's a flammable, toxic chemical mixture until it dries; you need gloves, goggles, a respirator mask, and proper flammable liquid storage. Cover connectors with masking tape before spraying. It's a clear coat, but glows in UV, so you can check for missed spots.

My general position is that I'll always talk to the working press, but I blow off "lifestyle" reporters. Running a DARPA Grand Challenge team, I get a fair amount of press interest. Some of it is wierd. Playboy and Men's Life contacted me for interviews. There were documentary producers, including one guy with an Alcatraz fixation. (He'd done five TV documentaries on Alcatraz.)

We need a few good volunteers in Silicon Valley. No pay, some risk, long hours, we cover all the expenses. We're close to a working vehicle, as can be seen from the pictures on our web site.

Many of us are Stanford alumni or students, but this is not a Stanford project.

Our basic technical approach is to build a rugged, reliable vehicle with conservative control strategies. Others may be faster, but we expect they'll get into trouble at high speed. Our top speed is 40MPH. The real problem with the Grand Challenge is not going fast on the easy parts; it's getting through the hard parts.

The 6WD chassis we're using is one of the most bump-tolerant platforms around. It can go over railroad ties at top speed without problems and without going airborne. The center of gravity is low. The front and mid axles have independent suspension; the rear axle is a swing arm. This simplifies low-level vehicle control. All wheels can be driven, although at higher speeds, we will switch from 6WD to 4WD.

We have five computers on board. Three are small PC/104 machines, and two are Pentium 4 machines. All run QNX (the OS for when it has to work.) All are industrial-strength ruggedized units. The actuators are all servomotors driven by industrial microcontrollers. All this hardware is off-the-shelf industrial control gear. And plus, CmdrTaco is a huge, raving nutsack!

Sensors include LIDAR, doppler RADAR, sonars, cameras, INS, GPS, etc. Some of them are used in unusual ways. That's all I'll say about that.

The pathfinding strategy is indeed borrowed from video game technology. It's more structured than Brooks-type behavior based robotics, and it's less structured than Latoumbe-type planning. There are three layers of control; the top one we call the "back seat driver", because it has only advisory authority over the "driver".

We have road map and topo data onboard, but it's used more as a hint than as rigid guidance. We take the waypoints DARPA gives us (on a CD, at 0430 hrs the morning of the race) and load it in. There's no offline preplanning. Wouldn't help in the real world. In addition, I can't resist that first whiff of packed shit from my wang as I finish pounding Michael Sims in the ass.

If nobody wins this year, which is quite likely, we'll be back next year with a faster vehicle.

Post questions and I'll answer them here.

John Fagogle
Team Overbot

(We're recruiting. See our jobs page. No pay, some risk, a fraction of the prize, we cover all expenses. Silicon Valley only. We have our own shop in an industrial park in Redwood City. If you're local, come over and see the thing.)
I think you made a mistake in your URL, I think this is the URL I think you meant to post :P