I'm sure someone more qualified to than me is floating around here. From what I heard at CMU then, the GPS data in '04 was a couple feet off, and everyone was driving a few feet off the road as a result. I imagine the key takeaway then was that one couldn't depend on GPS.
That caused us trouble in the 2005 Grand Challenge. It turns out that Novatel and Garmin GPSs were about a meter apart. They're both applying corrections for atmospheric distortion obtained from ground stations and
distributed through a geostationary satellite, which can give 15cm precision. We had Novatel, and DARPA had measured the course with Garmin. I talked to the JPL team, which also had Novatel, and they had a similar error.
We were strictly obeying the course boundaries, and had a terrible time getting through narrow gates where DARPA's waypoint file had a narrow width designed to guide us through the gates. If you look at videos of our runs, you can see the vehicle backing up and trying to get through a narrow obstacle. It's trying to get past a real-world obstacle on one side and a GPS limit on the other, which has narrowed the allowed path to where it can't quite fit.
So for the second run, I put in a patch to add 1 meter to DARPA's lane width. But I forgot to push it out to the vehicle, and we botched the second test run. It was in place for the third test run, though.
DARPA gave you bad data and told you you had to use it? Why would your system insist on staying within DARPA's boundaries in the first place -- did they make "out of bounds" too narrow in a misguided attempt to be helpful?
Yes, they made "out of bounds" too narrow in an attempt to be helpful. The data file provided to each team just before each event was a set of GPS waypoints, each with a width. The width of each segment was the minimum of the width at the endpoints.
In the 2004 Grand Challenge, the bounds were much wider and most vehicles screwed up. As it turned out,
you could almost drive the 2005 Grand Challenge by staying centered in the DARPA-defined path. But we didn't know that in advance.
Don't Tesla's? They require a well defined road line otherwise they get confused.
My friend owns a Model S and on the way to lunch it got confused on off ramps and parts of the road that were not well defined by lines. It basically shut off autopilot and required my friend to take the wheel.
Things have improved on many fronts since the 2004 challenge.
Arguably the biggest difference between the 2004 challenge (best distance was 7 miles) and the 2005 challenge (5 vehicles finished the race) was simply experience and refinement of existing technology. Stanford and CMU (top finishers) completed the race with very different approaches.
The Velodyne lidar was a prototype in the 2005 challenge and the first commercial version was extremely valuable to the teams that used it during the Urban Challenge. Google relied heavily on it and similar sensing technologies while developing their fleet, and many other groups going after full autonomy have also relied on lidar, so it certainly continues to be important. There's lots of different opinions on the future value of lidar vs vision. Camera quality and processing power + the effectiveness of CNNs are pushing a lot of people towards vision as a primary sensor.
There's also been a lot of progress for driving in urban environments in modeling, mapping, and prediction. A lot of this comes from collecting lots of data and building maps and behavioral models for objects the vehicle will interact with (cars, people...) Obviously for that the advancements in ML and deep learning don't hurt.
One interesting thing to me is that today we are able to collect way more data around driving than before. Since 2004, almost all of us have an incredible video camera in our pockets capable of recording our driving and the road conditions. We also almost all use highly detailed maps that we correct and add to (waze)! Finally, we have companies that care deeply about technology and data (Uber, Tesla) with fleets of cars on the road. These advancements mean we can improve on such software faster than before.