Slashdot Mirror

CMU's approach is a big hammer. They took a stock line-scanning laser rangefinder and put it in a huge 3-axis gimbal, which they then actively stabilize. That should be able to profile terrain, but it's a huge mechanical kludge. If you miss a spot because you hit a bump, you have a hole in your data. At that point you can either slow down and rescan, or plow ahead blindly. They may eventually complete the course with that rig, but no way is it a commercially viable technology.

The next generation of sensor technology may be ready in time. There are at least three groups with usable sensors in the prototype stage. We're talking to two of them. But that's all I'm going to say for now.

John Nagle / 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.)

We, of course, are working on fully automatic driving. We have both a visual road-follower and a millimeter radar. That's not enough.

Even line-scanner laser rangefinders are too limited. We need a true 3D device. Such things have been built, but the market is so tiny (and they're so big and clunky) that they're all one-offs. It's clear that the problem can be fixed, but the market isn't there yet to do it.

Personally, I don't get why they didn't use low, bumper-mounted radar to detect things like giant obtrusions so that axles didn't get broke and the like.

Team Overbot has just such a sensor, the Eaton VORAD, on their vehicle. Sadly, they withdrew from the race one month before the start, since they did not expect to be ready. I'm eager to see them succeed next year.

Personally, I don't get why they didn't use low, bumper-mounted radar to detect things like giant obtrusions so that axles didn't get broke and the like.

Team Overbot has just such a sensor, the Eaton VORAD, on their vehicle. Sadly, they withdrew from the race one month before the start, since they did not expect to be ready. I'm eager to see them succeed next year.

My suspicion is that their sensor suite was ill-chosen. They had four line scanners, three fixed and one steerable. The fixed ones were aimed to the left, the right, and slightly upward. The steerable one was presumably aimed as far forward as it can get good data.

This sounds good, but it's not that effective a system. All of them were single-line scanners. So the vehicle has to assemble ground profiles from successive line scans. The hard-mounted units weren't stabilized, so they wouldn't produce good profiles beyond slow speeds. The long-range gimballed Reigl scanner was stabilized in three axes, but it's still a line scanner. It only gets one chance to see any point on the ground, and it sees it at maximum range and at the most oblique angle possible, the worst possible condition. Any problems, and you have to slow down and try to use the gimbal to pick up the missing data. Or you can just go plowing ahead, which is apparently what they did.

I think this establishes that line scanners aren't going to solve this problem. CMU had the fanciest single-line scanner ever built, and they crashed into a very clear obstacle. CMU was more successful in the 1980s with a 3D laser rangefinder on the Navlab project. That unit was too slow for this event, but was the right idea.

We'd been through this analysis a year ago on Team Overbot, and knew we needed something better. We know what's needed, but couldn't get it built in time. Our custom laser rangefinder vendor went out of business, and the alternative vendor couldn't deliver in time. Next time.

CMU's race log is silent about this. Their last entry ends "We can win this. Spare nothing. Victory or demise."

It beats that "dead" feeling you get when you lose" - Buffy

The QID was pathetic. We spent two days watching vehicles move around at 1MPH and hit big, obvious obstacles. No way can most of those vehicles operate effectively offroad.

The big design mistakes seem to be these:

• Using a laser rangefinder aimed horizontally forward as primary obstacle detection. That doesn't work reliably on either dark or smooth objects. The black mini-van was both.
• Using fixed line scanners. If you miss a data point, you're stuck. There's no way to take a second look.
• Overreliance on vision. Computer vision in unstructured situations has a very poor track record.

Only CMU is doing well. It's not the money, by the way. Their actual cash outlays are only about $300K to date. It's the body count and the fear. They have about fifty people on the project, a slavedriver boss, and the full backing of CMU. CMU has to do well; most of the Robotics Institute funding over the last three decades is from DARPA, and DARPA can turn that money off at any time.

John Nagle
Team Overbot

I run one of the Grand Challenge teams, Team Overbot. We have a vehicle (a modified six wheel drive Polaris Ranger), a shop in Redwood City, funding, equipment, and people. We're well along; the vehicle has most of its actuators and some of the sensors working, and about a third of the software is running. We're one of the five DARPA-accepted teams.

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.

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.

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

I run one of the Grand Challenge teams, Team Overbot. We have a vehicle (a modified six wheel drive Polaris Ranger), a shop in Redwood City, funding, equipment, and people. We're well along; the vehicle has most of its actuators and some of the sensors working, and about a third of the software is running. We're one of the five DARPA-accepted teams.

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.

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.

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 Homogle
Team Overbot

• DARPA is seeking to promote innovative technical approaches that will enable the autonomous operation of unmanned ground combat vehicles. In the future, such combat vehicles will operate over varied terrain without the benefit of road signs, pre-programmed routes, etc. Autonomous vehicles must navigate from point to point in an intelligent manner so as to avoid or accommodate obstacles and other impediments to the completion of their missions.

To insure that teams didn't pre-plan, there were these provisions in the original rules:

• The Route Definition Data File (RDDF) will be given to all Participants approximately two hours prior to the first Departure Signal at a pre-Challenge brief.
• Only commercially available data (maps, images, other cartographic products) may be downloaded to the autonomous or safety vehicles prior to the challenge. Use of GPS is acceptable.

Then, when the general route leaked from the Bureau of Land Management, preplanning got completely out of hand. Now teams could predrive much of the route or overfly it. And they did. Two teams had the route laser-scanned from aircraft. This produced a very detailed topo map, with an elevation point every 25cm or so, along with equally detailed aerial photos.

On top of this, DARPA increased the number of waypoints from 1000 or so to 5000 or so.

At this point, it started to look like a breadcrumb-following exercise.

CMU will manually plan the exact route in the two hours before the race with a team of people at workstations in a big trailer. So even the planning is mostly manual. Their vehicle really does have some autonomous navigation capability, but it only uses it if the route doesn't match the mapped path.

So that's the history. From true autonomy to connect-the-dots.

• DARPA is seeking to promote innovative technical approaches that will enable the autonomous operation of unmanned ground combat vehicles. In the future, such combat vehicles will operate over varied terrain without the benefit of road signs, pre-programmed routes, etc. Autonomous vehicles must navigate from point to point in an intelligent manner so as to avoid or accommodate obstacles and other impediments to the completion of their missions.

To insure that teams didn't pre-plan, there were these provisions in the original rules:

• The Route Definition Data File (RDDF) will be given to all Participants approximately two hours prior to the first Departure Signal at a pre-Challenge brief.
• Only commercially available data (maps, images, other cartographic products) may be downloaded to the autonomous or safety vehicles prior to the challenge. Use of GPS is acceptable.

Then, when the general route leaked from the Bureau of Land Management, preplanning got completely out of hand. Now teams could predrive much of the route or overfly it. And they did. Two teams had the route laser-scanned from aircraft. This produced a very detailed topo map, with an elevation point every 25cm or so, along with equally detailed aerial photos.

On top of this, DARPA increased the number of waypoints from 1000 or so to 5000 or so.

At this point, it started to look like a breadcrumb-following exercise.

CMU will manually plan the exact route in the two hours before the race with a team of people at workstations in a big trailer. So even the planning is mostly manual. Their vehicle really does have some autonomous navigation capability, but it only uses it if the route doesn't match the mapped path.

So that's the history. From true autonomy to connect-the-dots.

At least two other teams have formally dropped out, and we expect some no-shows.

CMU is the favorite. Fifty people, $3.4 million spent to date, direct support from aerospace companies, and a team leader who expects people to work all night, day after day. (Read the article in the current Scientific American.) But their technology is rather disappointing. The whole route is preplanned by hand, using a bunch of people at workstations in a big trailer with maps obtained by overflying the route with LIDAR-equipped reconnaissance aircraft. It's not very autonomous. They found a loophole in the rules and exploited it very effectively. There's no breakthrough there.

Anthony Lewandosky, with his self-balancing motorcycle, has the most innovative technology. We've met him, and are impressed.

Palos Verdes High School has a viable entry, using a Honda Acura. We've loaned them some hardware. They've had autonomous driving working for months. They started by having handicapped driving control actuators put into a car, which simplified their mechanical problems. They debugged using a golf cart. Very nice work.

Caltech tried to qualify today, but their vehicle made an unexpected turn and bumped into something. They get a second chance on Wednesday.

Most likely, no one will finish. Nobody has really done enough field testing yet.

John Nagle

I run one of the Grand Challenge teams, Team Overbot. We have a vehicle (a modified six wheel drive Polaris Ranger), a shop in Redwood City, funding, equipment, and people. We're well along; the vehicle has most of its actuators and some of the sensors working, and about a third of the software is running. We're one of the five DARPA-accepted teams.

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

• We need three more good programmers in Silicon Valley. "No pay, some risk, a fraction of the prize." If you're interested, we want to see 1000 lines of C++ you're proud of. You'll need to put in at least 250 hours between now and March. Click here to join.

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.

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.

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 Nagle
Team Overbot

I run one of the Grand Challenge teams, Team Overbot. We have a vehicle (a modified six wheel drive Polaris Ranger), a shop in Redwood City, funding, equipment, and people. We're well along; the vehicle has most of its actuators and some of the sensors working, and about a third of the software is running. We're one of the five DARPA-accepted teams.

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

• We need three more good programmers in Silicon Valley. "No pay, some risk, a fraction of the prize." If you're interested, we want to see 1000 lines of C++ you're proud of. You'll need to put in at least 250 hours between now and March. Click here to join.

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.

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.

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 Nagle
Team Overbot

I run one of the Grand Challenge teams, Team Overbot. We have a vehicle (a modified six wheel drive Polaris Ranger), a shop in Redwood City, funding, equipment, and people. We're well along; the vehicle has most of its actuators and some of the sensors working, and about a third of the software is running. We're one of the five DARPA-accepted teams.

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

• We need three more good programmers in Silicon Valley. "No pay, some risk, a fraction of the prize." If you're interested, we want to see 1000 lines of C++ you're proud of. You'll need to put in at least 250 hours between now and March. Click here to join.

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.

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.

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.

Jim Stevens
Team Overbot

I run one of the Grand Challenge teams, Team Overbot. We have a vehicle (a modified six wheel drive Polaris Ranger), a shop in Redwood City, funding, equipment, and people. We're well along; the vehicle has most of its actuators and some of the sensors working, and about a third of the software is running. We're one of the five DARPA-accepted teams.

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

• We need three more good programmers in Silicon Valley. "No pay, some risk, a fraction of the prize." If you're interested, we want to see 1000 lines of C++ you're proud of. You'll need to put in at least 250 hours between now and March. Click here to join.

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.

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.

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.

Jim Stevens
Team Overbot

I run one of the Grand Challenge teams, Team Underbot. We have a vehicle (a modified six wheel drive Polaris Ranger), a shop in Redwood City, funding, equipment, and people. We're well along; the vehicle has most of its actuators and some of the sensors working, and about a third of the software is running. We're one of the five DARPA-accepted teams.

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

• We need three more good programmers in Silicon Valley. "No pay, some risk, a fraction of the prize." If you're interested, we want to see 1000 lines of C++ you're proud of. You'll need to put in at least 250 hours between now and March. Click here to join.

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.

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.

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.

Jim Stevens
Team Underbot

I run one of the Grand Challenge teams, Team Underbot. We have a vehicle (a modified six wheel drive Polaris Ranger), a shop in Redwood City, funding, equipment, and people. We're well along; the vehicle has most of its actuators and some of the sensors working, and about a third of the software is running. We're one of the five DARPA-accepted teams.

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

• We need three more good programmers in Silicon Valley. "No pay, some risk, a fraction of the prize." If you're interested, we want to see 1000 lines of C++ you're proud of. You'll need to put in at least 250 hours between now and March. Click here to join.

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.

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.

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.

Jim Stevens
Team Underbot

I run one of the Grand Challenge teams, Team Overbot [overbot.com]. We have a vehicle (a modified six wheel drive Polaris Ranger), a shop in Redwood City, funding, equipment, and people. We're well along; the vehicle has most of its actuators and some of the sensors working, and about a third of the software is running. We're one of the five DARPA-accepted teams.

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

• We need three more good programmers in Silicon Valley. "No pay, some risk, a fraction of the prize." If you're interested, we want to see 1000 lines of C++ you're proud of. You'll need to put in at least 250 hours between now and March. Click here to join. [overbot.com]

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.

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.

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 Nagle
Team Overbot

I run one of the Grand Challenge teams, Team Overbot [overbot.com]. We have a vehicle (a modified six wheel drive Polaris Ranger), a shop in Redwood City, funding, equipment, and people. We're well along; the vehicle has most of its actuators and some of the sensors working, and about a third of the software is running. We're one of the five DARPA-accepted teams.

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

• We need three more good programmers in Silicon Valley. "No pay, some risk, a fraction of the prize." If you're interested, we want to see 1000 lines of C++ you're proud of. You'll need to put in at least 250 hours between now and March. Click here to join. [overbot.com]

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.

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.

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 Nagle
Team Overbot

I run one of the Grand Challenge teams, Team Overbot [overbot.com]. We have a vehicle (a modified six wheel drive Polaris Ranger), a shop in Redwood City, funding, equipment, and people. We're well along; the vehicle has most of its actuators and some of the sensors working, and about a third of the software is running. We're one of the five DARPA-accepted teams.

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

• We need three more good programmers in Silicon Valley. "No pay, some risk, a fraction of the prize." If you're interested, we want to see 1000 lines of C++ you're proud of. You'll need to put in at least 250 hours between now and March. Click here to join. [overbot.com]

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.

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.

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 Nagle
Team Overbot

I run one of the Grand Challenge teams, Team Overbot [overbot.com]. We have a vehicle (a modified six wheel drive Polaris Ranger), a shop in Redwood City, funding, equipment, and people. We're well along; the vehicle has most of its actuators and some of the sensors working, and about a third of the software is running. We're one of the five DARPA-accepted teams.

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

• We need three more good programmers in Silicon Valley. "No pay, some risk, a fraction of the prize." If you're interested, we want to see 1000 lines of C++ you're proud of. You'll need to put in at least 250 hours between now and March. Click here to join. [overbot.com]

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.

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.

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 Nagle
Team Overbot

The next big gripe is about the "DARPA site visit". DARPA plans to send some people out to visit each team in December and check on their progress. A few people are complaining loudly about this, but anybody with something to show shouldn't have a problem with it. It's basically a vaporware filter.

Finally, DARPA has decided to use the preliminary testing at the California Motor Speedway in Fontana to cut the number of entries down to 20. I will be surprised if twenty teams field something that crosses the starting line in Fontana, let alone finishes the trial course.

I don't see a problem here.

John Nagle
Team Overbot

(Incidentally, while we have most of the people we need, we could use an additional electronics tech and a QNX sysadmin. "No pay, some risk, a fraction of the prize.")

I run one of the Grand Challenge teams, Team Overbot. We have a vehicle (a modified six wheel drive Polaris Ranger), a shop in Redwood City, funding, equipment, and people. We're well along; the vehicle has most of its actuators and some of the sensors working, and about a third of the software is running. We're one of the five DARPA-accepted teams.

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

• We need three more good programmers in Silicon Valley. "No pay, some risk, a fraction of the prize." If you're interested, we want to see 1000 lines of C++ you're proud of. You'll need to put in at least 250 hours between now and March. Click here to join.

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.

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.

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 Nagle
Team Overbot

I run one of the Grand Challenge teams, Team Overbot. We have a vehicle (a modified six wheel drive Polaris Ranger), a shop in Redwood City, funding, equipment, and people. We're well along; the vehicle has most of its actuators and some of the sensors working, and about a third of the software is running. We're one of the five DARPA-accepted teams.

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

• We need three more good programmers in Silicon Valley. "No pay, some risk, a fraction of the prize." If you're interested, we want to see 1000 lines of C++ you're proud of. You'll need to put in at least 250 hours between now and March. Click here to join.

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.

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.

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 Nagle
Team Overbot

We're using Ampro CoreModule 400 boards. These deliver about 20 MIPS, even though they clock at 133MHz. Basically, they're 486 machines. But they work fine. We have 256MB flash cards in each machine as the "disk". We may upgrade to CoreModule 600 boards when Ampro starts shipping them in about a month if it turns out we run out of CPU power closing the control loops.

PC/104 is just ISA bus in a more compact form factor. This is rather retro for 2003. There's "PC/104+", which is a PCI bus, but cramming in the additional connector creates packaging problems. The connector technology is just ordinary header connectors, unlike Eurocard/VME/Compact PCI, which use a much better connector but result in a bigger card cage. Assembling a PC/104 stack without bending pins is hard. But once you get the whole stack bolted together and into the rubber shock mounts in the solid metal case, it's quite rugged.

We run QNX on all the vehicle machines. (There are two larger Pentium 4 machines in back; the PC/104 machines do low-level control.) We can bring up the full QNX GUI and even do web surfing, but at 20 MIPS, it's rather sluggish.

That red Jeep has nothing to do with the Grand Challenge. That's Navlab 11, the Robotics Institute's latest test vehicle. the Robotics Institute, headed by Charles Thorpe, took a look at the Grand Challenge and decided to pass. He told me "If we entered, we'd have to win", and since he's mostly Government-funded, he'd need another source of funding, which he didn't have. Whittaker, who heads a related but separate operation, the Field Robotics Center, decided to do it on his own.

Whittaker issues a constant stream of trival press releases, like Team Equipped with Laptops and Office Equipment. We have considerable respect for the Robotics Institute at CMU, but this is becoming embarassing.

We take Team Caltech seriously, but not Whittaker's operation.

We will give a presentation on September 24, in EE380 at Stanford, on how we're doing it, and will show our vehicle, which isn't vaporware.

John Nagle
Team Overbot

No I don't work Hasbro and this isn't intended to be flaimbait. And yes they are hurting Hasbro's ability to make money. They wouldn't have made the CD format difficult to udnerstand and use if it wasn't part of their marketing plan.

This is serious subject. Companies are spending billions to protect their property. Cracking someones propritary format in my view is stealing. Plain and simple.

I see no one was answered the real question....the real challenge isn't craking someones protection schemes...the real challenge is making something that is useful enough for someone to purchase and use.

I think (and I this is what I really think) people who do this are disgraceful.

Instead of spending time on this...volunteer for something like this for example:

Team Overbot

Notice that I'm not an Anonymous Coward :)

• AI and intelligent robots.

  We do not have a clue how to do strong AI. Nobody does, including the people who say they do. All the old ideas, from predicate calculus to neural nets, have been taken about as far as they're going to go. There hasn't been a really good new approach in years. It's not lack of CPU power, or there's be good systems that were really slow. The best that's been accomplished is systems that fake intelligence (Eliza, AskJeeves, Cyc, Cog, Microsoft Barney for Windows) by interacting with people in ways that lead people to overestimate them.

  Even industrial robots are really dumb. Most of what's in production has almost no sensing. The advanced models do some visual correlation to fine-tune position alignment. No industrial robot deals with an unstructured environment.

  Driverless cars are coming along well. Even there, though, we're a long way from noticing that the ball rolling into the street may be followed by a child.

• Big flat-screen TVs you can hang on the wall

  You can get this, but it costs $10,000 and weighs 400 pounds. Improvement is slow and sizes are limited. Plasma panels have the assembly problem from hell - they're made of two big flat pieces that have to align at the pixel level. Wrong answer. "Printable OLEDs" are still vaporware.

People like that are hard to find. The ones we find are all frantically busy doing something already. We can find good people who can put in a few hours a week, but we need at least half-time, because these are the key people who hold the project together.

They're not out there. We're not coming across unemployed top-level programmers. There are plenty of people who can do what it says to do in the manual. We don't need those.

(If you're interested, send us a thousand lines of C++ you're proud of. No pay, some risk, a fraction of the prize.)

We have to do a lot better than Hyperion did. 300km, not one. And faster.

We're looking for a few good people. Hard work, no pay, some risk, a chance for a fraction of the prize. See our current openings.

We're in Silicon Valley. We have funding, a shop in an industrial park in Redwood City, a vehicle under construction, and six people. We need about six more.

We have to do a lot better than Hyperion did. 300km, not one. And faster.

We're looking for a few good people. Hard work, no pay, some risk, a chance for a fraction of the prize. See our current openings.

We're in Silicon Valley. We have funding, a shop in an industrial park in Redwood City, a vehicle under construction, and six people. We need about six more.

The key idea behind QNX is that it does interprocess message passing between protected-mode processes really, really well. Everything else is built on top of that. In most other OSs, interprocess communication was an afterthought, and it shows. Typically, message passing is built on top of the I/O system. In QNX, the I/O system is built on top of message passing.

The QNX kernel is very stable because it only does a few basic things, and those few things are heavily exercised and well debugged. New system calls are very rarely added. New features go in new user processes.

Development on QNX is straightforward. The whole GNU command-line toolset is available. The API is Posix-compatible. The QNX calls are well integrated with the Posix calls; there aren't separate "Posix threads", like some other OSs.

QNX is the last OS vendor that competes commercially with Microsoft on x86 desktop machines. The fact that they're still alive says something.

You can run QNX as a desktop OS, and I have a machine on my desk that does so. But there's not much desktop-type software. Mozila, AbiWord, and Eclipse have been ported, but that's about it for graphical desktop applications. OpenOffice has not been ported, and it would be a huge win if somebody did that.

QNX has its own windowing system, Photon, which is like nothing else out there. It's quite good, and much cleaner than most windowing systems. But it's different.

Hardware support is spotty. Graphics support is mostly for obsolete boards, although anything that supports VGA or VESA modes will work. (NVidia refuses to release enough information to allow development of QNX drivers.) USB 1 is supported, but only for a few peripherals. USB 2 is not, nor is FireWire. (I've been writing FireWire camera support.)

QNX runs our robot vehicle for the DARPA Grand Challenge. It has to work.

Historically, AI has cycles of fads. Somebody has a reasonably good idea, they claim strong AI is right around the corner, there's a few years of frantic activity, the new approach hits a ceiling, and the fad is over. Major fads have been backtracking, LISP, perceptrons, theorem proving, expert systems, neural nets, genetic algorithms, and reactive robots. Each of those hit a ceiling after the first few years.

Much of what's going on today involves building systems that give the impression of being more intelligent than they are. Ask Jeeves is a good example. It has no idea what your question means, but finds results that have some vague releveance to what you asked. Lenat's Cyc is like that. Lenat's 1984 paper, "Why AM and EURISKO Appear to Work", shows Lenat in an honest moment, admitting that what came out was mostly implicit in what had been built in. Cyc itself has been "close to success" for a decade now. Most recently, Lenat got some "homeland security" money to use Cyc for data mining, another application where understanding content isn't necessary.

In a different direction, there are systems built inside dolls to give the illusion of humanness. Brooks has built a few systems like that, including My Real Baby, an unsuccessful Hasbro product. Brooks did good insect-level robots, then started claiming that reactive systems were going to lead to strong AI real soon now, and started Cog, which is a humanoid torso that reacts to people nearby but doesn't do much in the way of useful tasks. I once asked him why he didn't try for mouse-level AI, as a next step after insect-level AI. He said "because I don't want to go down in history as the man who created the world's greatest robot mouse".

That's a big part of the problem - hubris. Trying to get to human-level AI when we can't do lizard-level AI isn't working. Yet spending your whole life trying to build a good lizard brain isn't a good career move.

The one bright spot is in gaming. Game developers need lizard-level AI (balance, running, survival, fighting, etc.) and they're slowly making it work. If you want to see real progress in AI, go to GDC, not AAAI.

AI needs to focus more on tasks where failure is possible. This keeps people from faking it. We're currently putting together a vehicle for the DARPA Grand Challenge. 200 miles across the desert, no driver, no human intervention, no question about whether you succeed or fail.

I asked Rod Brooks if the MIT AI Lab was entering. He said no.

We're working on it full time. Making good progress, too.

• You can't game your way around the rules. You have to describe your approach to DARPA in writing, and DARPA reserves the right to change the rules after entrants have submitted their technical specs. They want a useful autonomous vehicle, not a trick.
• The rules have changed several times, and will change again. There's supposed to be a more or less final version on 1 April 2003. Right now, the announced plan is Barstow to Las Vegas in 10 hours.
• You can't preplan the whole run using map data, aerial imagery and GPS. DARPA will do things to make that not work, like placing some obstacles on the route. Note that you get the route, in the form of about 1000 waypoints, two hours before the race.
• DARPA does not guarantee that the course will be cleared of other persons and vehicles. Early versions of the rules said that the course would be cleared, but then DARPA changed the rules. Now it's only a "best effort" thing. Some competitors pulled out at that point. There will be sweeps ahead of the robot vehicles, vehicles following behind with remote emergency stop buttons, and road closures, but somebody still might not get the word. The route isn't on military bases; it's on Bureau of Land Management land open to the public. DARPA claims they will come up with an insurance carrier that will provide liability coverage, but so far, that hasn't happened. Vehicles thus need very good safety systems.

• You can't game your way around the rules. You have to describe your approach to DARPA in writing, and DARPA reserves the right to change the rules after entrants have submitted their technical specs. They want a useful autonomous vehicle, not a trick.
• The rules have changed several times, and will change again. There's supposed to be a more or less final version on 1 April 2003. Right now, the announced plan is Barstow to Las Vegas in 10 hours.
• You can't preplan the whole run using map data, aerial imagery and GPS. DARPA will do things to make that not work, like placing some obstacles on the route. Note that you get the route, in the form of about 1000 waypoints, two hours before the race.
• DARPA does not guarantee that the course will be cleared of other persons and vehicles. Early versions of the rules said that the course would be cleared, but then DARPA changed the rules. Now it's only a "best effort" thing. Some competitors pulled out at that point. There will be sweeps ahead of the robot vehicles, vehicles following behind with remote emergency stop buttons, and road closures, but somebody still might not get the word. The route isn't on military bases; it's on Bureau of Land Management land open to the public. DARPA claims they will come up with an insurance carrier that will provide liability coverage, but so far, that hasn't happened. Vehicles thus need very good safety systems.