Solving Self-Driving with Strategic Laziness
Making a self-driving car via engineering jiu-jitsu
Before we begin: When do you think the first fully self-driving vehicle will be available for public use? Write your guess down; we’ll come back to it later.
Driving, Eh?
It’s a pain in the ass if I do say so myself. Sure, it might be nice if you’re driving along a naturally-occurring highway through pristine wilderness in a fancy sports car. But most driving is expensive, monotonous, boring, frustrating, and dangerous. So much so, in fact, that we’ve been trying to automate the damned things since at least the 1950’s, when RCA Labs started futzing about with it.1 Popular culture is painting electric fully self-driving autonomous vehicles as the future of transportation, and they’ve been a few years away for quite a few years now.
Now I’m not a programmer, but I was about 65% of one. And as such I don’t want to downplay the enormous achievements folks all around the world have made in this task. Because it’s a huge engineering project. The dream of a fully autonomous car is a tall order with a long list of prerequisites:
You have to develop machine vision and sensor processing enough that a vehicle can identify potentially thousands of objects of almost any type, both common road features like signs and cars but also anything that might ever end up on a street.
The vehicle needs to do physics calculations on all of those objects and itself to know where everything’s going and what might cause collisions.
Somehow you need to identify people and other cars that could change their behavior at any time and create sophisticated predictive models for their behavior to make judgments about where they might be and what you can do to avoid hitting them.
You have to not only visually process and interpret signs and instructions, but also understand all the numerous and changing laws, ordinances, street markings, and temporary access changes that can occur.
The vehicle needs to not only be able to detect changing and hostile weather conditions that affect driving behavior, but adjust all its calculations and parameters to take those conditions into account.
The vehicle needs to do all of these things constantly, in real-time, for long periods of time, with on-board hardware that either has to never fail or be completely fail-safe.
It needs to do and be all these things with on-board hardware the vehicle’s drivetrain can power and without being so expensive it pushes the technology out of reach of most people.
A very tall order, indeed. And frankly, the fact that scientists and engineers have gotten us even part of the way is an absolute triumph of human ingenuity that deserves to be celebrated, even if they haven’t realized the full dream yet.
The Clevererest Engineering
As a formerly 65%-of-a-programmer, I learned a lot about how to deal with large engineering problems. In my younger years, when I was a 20ish-year-old not-yet-a-lass who was only 20-30% a programmer, I heard a clever phrase that stuck itself in my head:
“The Best Code is No Code at All”2
Pretty fancy, eh? That’s some engineering Sun Tsu shit right there, in that it sounds wise and profound at first glance but doesn’t really…say anything.
So, what do I actually mean here?
Well, programming (and engineering in general) is very hard. Problems are often nebulous, our tools for solving them finicky and unintuitive, and the solutions we build are often so large we can’t hold them in our heads all at once. In order to work on almost anything you have to maintain a certain discipline about problem-solving techniques. That’s basically what software architecture is about: breaking big problems down into many small pieces, arranging them carefully, isolating them from each-other to prevent interference, and making them comprehensible to whoever’s working on them.
It’s very easy to get lost in a large problem. Even a well-designed codebase (which is rare) has so much complexity that it’s easy to spend hours, weeks, even months walking down dead-end solution. You can get fixated on very complicated solution to a problem when a simpler one will do. You can duplicate work that’s already been done by others. You can even lose track of the requirements of the codebase and accidentally solve the wrong problem.
Since we’ve already got him on the brain, let’s explain this with a Sun Tsu metaphor. Let’s talk about war:
You’re a Mongol general, at the height of Temujin’s great empire. You’ve got a whole-ass army at your disposal, replete with horse archers, men-at-arms, ladders, siege engineers, sappers, gunpowder, maybe even some early hand-cannons. You’re decked out in stuff and you want to capture a big fuck-off walled city.
This is quite the task. Even with modern artillery, attacking into urban positions is absolutely brutal. But when you can’t reliably knock over walls? What do you even do?
Being a good general, you start thinking of all the ways you can take this city. The standard option’s a siege: camp up and starve ‘em out. But that’ll take forever, cost money and lives, and give your enemies a chance to marshal forces and relieve the city. It’s an option, but a difficult and crappy one.
You could build a bunch of siege weapons to break them: trebuchets to hurl rocks and plague victims, battering rams to knock down the gates. They kinda work, but the tech’s not there yet.
You could try climbing over. Escalade’s a classic maneuver. But, well…there’s few things more vulnerable than a man climbing a ladder towards a bunch of angry lads with pokey sticks.. You could make a siege tower to give ‘em some cover and stability, but those are harder to build, get stuck in the mud, and can catch on fire really easy.
How about your old pal the hole? You could get your team of sappers to dig a tunnel from your lines to beneath the enemy walls, shove a bunch of gunpowder down there, and blow it all to kingdom come. But mining is brutal, it takes forever, and counter-mining makes a right mess of it.
You have all these options and they all suck. You spend hours in your command tent with your lieutenants coming up with plans. Trebuchets to soften them up, maybe hurtle some diseased cows into the city. Then battering rams like so, a dozen siege towers and a hundred bare ladders, three different saps…it’s a huge orchestra, all this work and all these moving pieces that’ll require a ton of time and resources and it might not even work, at which point you’ll have killed thousands of your own men and gained nothing.
Then your oldest, wisest advisor steps from the edge of the tent, into the light, and says:
“The Best Siege is No Siege.”
Let’s take a step back: What do we really want here? Do we want to win a successful siege, to take the city by force? You might think that, dear general, but no. The goal here isn’t to assault the city, it’s to take it and its riches for ourselves.
What if instead of trying to take the city by force, we convince them it’s in their best interest to surrender and join our side. The Mongols have a reputation, after all, for being really good at this. We have a habit of utterly destroying cities that resist us. Do you really wanna risk that? Why not just let us in, we’ll take some taxes and buy some sex work, and we’ll be out of your hair and onto the next city in no time and you can go back to your business. Whaddya say?
The best siege is no siege. The best code is no code.
A fully-autonomous vehicle as outlined above is an incredibly difficult engineering task. But what if we took a step back from the problem and asked: “What is it we’re actually trying to do here?” The fundamental problem here is the Transit Question: How do we get people and goods from place to place quickly, safely, reliably, and efficiently?
Once we start thinking about the broader Transit Question, we can start thinking more creatively about ways to make self-driving vehicles work. And that’s the point of today’s episode: How can we make self-driving car technology easier to implement by making the problem easier?
Problems to Avoid Solving
Let’s break it down, shall we? Take some of the biggest problems self-driving cars face and see if we can’t finagle our way into a solution.
Problem #1: Murdering People is Bad
One of the biggest problems self-driving cars have is that, in a city, there’s just so much stuff. Big and little, tall and wide, walky and wheely, stuff that’s supposed to be there and stuff that very much isn’t. There’s too much dang stuff!
All of that stuff looks and acts different, and you really can’t hit any of it. Everything has to be accounted for or you might damage something or kill someone. So surely we need to create a large-language model that can identify every possible thing (especially people) that might be in a city, predict how they’ll behave, and respond accordingly, right?
Solution: De-People the Road
Pull back a bit, though. There’s ways we can simplify this, because obviously a car doesn’t have to worry about everything, right? It doesn’t much care what’s happening on the fifth floor of an apartment building, or ten feet below the roadbed. It only really needs to care about what’s on or immediately next to the road. Unfortunately there’s still a lot of stuff on or near roads because roads and their sidewalks are corridors down which everything travels, including people. It’s all mashed in there together, with nothing but a curb separating one from the other.
But what if they weren’t? What if instead of mixing the cars in with all the other city stuff, we gave them their own dedicated transit ways separated from the rest of the world by physical barriers that prevented the two from mixing?
No! Well, yes, kinda. What I’m proposing more generally is called Grade Separation.
This is a technology we use all the time in transit systems to reduce the chance for dangerous collisions. From freeway overpasses to pedestrian bridges, dedicated bike infrastructure or underground roadways (via our good ol’ friend the hole), we’ve gotten really good at keeping different flows of traffic away from each-other.
So…what if we just did that? What if we gave self-driving cars dedicated corridors separated from the rest of the city by physical barriers? Or do the reverse: a series of dedicated pedestrian corridors that keep people off the traffic level and let them get to their destinations without getting near the cars. Hell, you might even be able to use clever urban planning to dedicate parts of the city to pedestrian traffic only (with parking spots, of course) and parts to automobile traffic, and then connect the two with some combination of bridges and tunnels. Whichever way you choose, you can’t kill pedestrians if there aren’t any in striking distance.
Problem #2: Turning is Hard
If you get real philosophical about it, driving’s about three things: speeding up, slowing down, and turning. And let me tell ya, the turning part’s a real bitch sometimes.
Think of all the intersections, all the corners, all the turns and turnouts, every parking space, every place a vehicle might switch lanes. There are so very many places one has to turn, and a self-driving car has to figure out which turns to take and how to take them, in real time, all the time.
Unless…
Solution: Make the Road Turn for You
Fancy, huh? But how? The road isn’t smart. It doesn’t know how to turn a car anymore than a normal car does. How is it supposed to figure this out?
The answer is a little technology called a guideway.
One of the problems with software is that it’s so complicated that it’s bound to make mistakes and have bugs. But physics doesn’t. If the physical structure of an object pushes it to do something and is strong enough to survive the attempt, it’ll do it every time, without fail. When you go down a big waterslide, you don’t have to think about how to follow the path because the slide does that for you.
The same applies to vehicles. If you build a proper guideway, your vehicle will follow its twists and turns without having to steer itself. All it needs to do is slow down to the safety tolerances of each curve. So it still needs to figure out what those are.
Except it doesn’t have to do that either. Since a guideway exerts much tighter control on a vehicle that flat asphalt does, the engineers who design the guideway have a much better sense of how a vehicle will traverse a given curve. This makes it possible for them to determine optimum speeds for various weights of vehicle before the road is even built. If you do that, all the vehicle has to do is tell the guideway what type of vehicle it is and the guideway can tell it how fast to go. Weather complicates the matter quite a bit, as it does with existing self-driving technology, but this is still a massive reduction to the complexity of the problem.
It’s also a huge efficiency gain, too. One of the problems with current self-driving cars is that each one has to do their own set of calculations every time they take a turn. You could have a thousand identical vehicles approach same curve in the same way, but they all have to make separate calculations to traverse it. With a guideway, you can have a bunch of engineers do at least some of these calculations ahead of time and then feed the results to every car that shows up. With computing power as expensive as it is, that could be a massive cost savings for a large enough system.
Problem #3: Beholding The Signs
Signs are hard.
In modern cities, signs and lights communicate a huge amount of information about what’s going on. That’s very useful for humans, who are highly visual and can interpret such data in real-time. But for a computer, it’s a bit of a pain in the ass.
Some of this information, like street maps, has been digitized and is readily available to self-driving cars. Others, like temporary speed limits for construction or time-sensitive parking restrictions, probably aren’t but theoretically could be. But traffic lights can’t be cached because they’re constantly changing. What color is the light? The car needs to know quite badly, right now, and we’ll have to do a ton of machine vision work to figure it out, right?
Solution: Electric Boogaloo
What if the light could just talk to the cars it’s facing? Wouldn’t that be nice? That’d certainly remove some points of failure and free up a lot of computing power.
In theory, a traffic light could use a wireless signal to tell all nearby cars what’s what. But if you’ve ever futzed about with a spotty wifi connection you can imagine what problems might arise from that. What if one of the cars doesn’t get the memo?
To meet the safety tolerances of modern civil engineering, we need something a lot more failproof.
Okay, let’s imagine this: Every traffic signal is trying to communicate to cars on a certain part of the road, right? So what if we ran the signals through the road itself? Each traffic light is responsible for the road before it and sends its current state into the surface itself, thus telling cars what they need to be doing. When the car passes from one chunk of the road bed to another, it checks to see if there’s an associated light and acts accordingly. You could even tell the car how long the managed stretch of road is (and thus the distance to the light) so it can decide how quickly it needs to stop.
How to propagate the signal, though? Asphalt isn’t much of a conductor and rubber is famously insulative. We really need a metal-on-metal connection for reliability. To throw out a silly idea, we could run a metallic strip down the center of the lane and put a metal noodle-arm on the bottom of the car to pick it up.
When the two touch, it completes a circuit and transmits a message. If the car doesn’t receive a message, it assumes the light’s out or broken and comes to a stop, failing safely.
We could get even fancier if we use the guideway technology, since a properly-designed guideway can work with metal wheels. Then it’s even simpler: make the guideway metal and send the signal straight through it and into the wheels. You could use that basic premise for all sorts of things: stop signs, speed limits, grade changes, maybe even information about open parking spaces if you were clever about it.
Problem #4: Weather Exists
I’ve mentioned it a few times already, but bad weather makes driving much harder, for both humans and AI.
Vehicles have much worse performance in inclement weather in general, but self-driving cars have an even harder time for a number of reasons. First of all, detecting bad road conditions in all circumstances at the drop of a hat adds an entirely new task to deal with. Suddenly your vehicle needs temperature sensors, wind gauges, the ability to suss out icy conditions or measure the amount of snow on the road. It needs to understand what hydroplaning is, when it can happen, and how to avoid it. It also needs to calculate the traction between the tires and the road in real-time so it can adjust its mental model of what’s going on.
There’s also another dangerous phenomenon at play here: the problem of overfitting. Now I’m definitely not qualified to explain exactly what this means or how it applies to large-language models, so take this next bit with a grain of salt.
Overfitting is when a predictive algorithm matches itself too perfectly to the nuances of its training data and thus becomes very bad at operating on the problem in general. For example, there’s a somewhat famous story of a neural network being developed to detect malignant skin lesions. It seemed like it had gotten good enough to rival professional dermatologists, which would’ve been a major advancement. But on closer inspection, it turned out the network was actually checking for the presence of a ruler. Pictures of cancerous lesions contain rulers to measure their scale while benign ones usually don’t, and since checking for the ruler was easier than making a cancer diagnosis, the neural network just checked for the ruler.3
Overfitting with regards to self-driving cars in weather conditions is a particular concern for geographic reasons. Most of the tech companies developing these technologies (at least in the United States) are based in California, a place with a reputation for good weather. It’s a lot easier for tech companies based in Silicon Valley to test their implementations on the good weather nearby rather than haul their operations to Alaska or Papua New Guinea or the Siberian tundra. This has the potential to create a self-driving car that operates well in California but flips its shit in a quarter of an inch of snow.
With climate change ramping up, the Weather Problem will only become more severe, which will only make the fully-autonomous self-driving car harder and harder to implement. What’s a lazy engineer to do?
Solution: Our Good Friend the Hole
Yknow where weather comes from? The sky. So what if we left the sky, abandoned the harsh and uncaring surface of our planet, and descended into the warm and inviting bosom of the Deepmother? Why not dig a hole and put all the cars, indeed our entire civilization, in the arms of the earth?
Okay, historically car tunnels have been a messy solution to a number of things. Exhaust fumes demand ventilation, and that makes the whole endeavor much more complicated. But if the cars are electric that’s not as much of a problem. Then all you need to deal with is tire emissions, which are unfortunately still quite nasty4. And if we’re using our guideway solution from above, we can switch the nasty rubber tires5 out for relatively clean and enduring steel wheels.
For all their lauded anti-sky action, tunnels are quite tricky and expensive to construct, which is one of the reasons we don’t put all roads underground: the economy would explode if we tried. But there are some less expensive ways to get enough of the Tunnel Experience to get by.
Snowsheds can keep a road free snow, and road surfaces with good drainage systems can reduce the buildup of water that leads to hydroplaning. In the simplest case you can increase itensity of snow and ice removal services along important routes. Or you can be really rigorous about outfitting self-driving cars with weather-appropriate tires.
None of these solutions are foolproof and weather will always be a challenge for drivers of all levels of machineness or meatiness. But every little efficiency gain helps. And for all the highest-traffic routes in our largest cities. the Tunnel Experience’ll do wonders.
Problem #5: Intersectionality
It’s always the intersections that getchya. The goddamn intersections.
They’re completely and utterly necessary for any transit system to function, but they also present the most complicated set of conditions for a vehicle to traverse. The larger they are, the more vehicles traveling through them, the more chances there are for things to go wrong and the more time we have to spend navigating them.
One of the big selling points of self-driving cars is that they’ll be so good at driving you won’t need stoplights anymore. If two streams of traffic cross into each-other, the autonomous vehicles can just weave seamlessly across each-other, leaving just enough room for everyone to get by.
A beautiful dream, but a monumental challenge to overcome. For a busy intersection of large roads to work this way, dozens if not hundreds of cars have to become aware of each-other, devise a collective strategy for how to pass, and adjust their behavior perfectly to match. If a single car in that dance messes up or has a technical fault it’ll run into something and create a gigantic pileup at high speed. So you need every car to be perfectly programmed and perfectly maintained and you need to make sure that absolutely nothing (like a pedestrian) interferes with the delicate dance, at every major intersection forever, or people will die.
Is there something we could do to bring this beautiful dream closer to reality?
Solution: De-Manying Tactics (Car)
The biggest source of complexity here is the number of vehicles. The most obvious jitsu, then, is to have fewer vehicles.
In 2019, the average occupancy for cars on the road was 1.5 persons per vehicle.6 This is not very many persons and I think we can do much better. Even using all the normal seats and bumping occupancy up to 4 more than halves the number of vehicles on the road, and thus the difficulty of the Intersection Problem.
Let’s go for a bigger prize: 15 persons per vehicle. It’s a nice round number that reduces the number of car on the road by 90%, which is such an enormous reduction in the complexity of the problem.
Getting an average of 15 persons per vehicle requires one of two things: mandatory clown training or bigger vehicles.
Alas, we can’t all be born with silly bones, so larger vehicles it is. Let’s call them BigCars because that’s fun for me.
How big would a BigCar need to be? That’s a very good question I’m not qualified to answer. But since this is all napkin math anyway, let’s assume our new BigCars are, on average, as full as our current cars are: assume 1.5 occupied out of the (typical) 5 seats is 30% occupacy, so our BigCars would have to have around 50 seats to achieve our goals. A large vehicle, but well within our capabilities to construct.
Unfortunately, simply replacing cars with BigCars won’t work because multiple places exist. Very few travelers share both a start and endpoint for their journey, so BigCars couldn’t simply drive 15 people from their house to their place of work. Maybe you could pick up people along the way, but that’s basically doing a dynamic Traveling Salesman problem across an entire country, which sounds more complicated than handling the intersections normally. We’ll need to make some changes.
Solution: De-Manying Tactics (Place)
To make BigCar work, you have to change the way transit functions. You can’t have self-driving vehicles move you at will from point to point or you’ll never get the sort of occupancy density we need to simplify the Intersection Problem. What is one to do?
Well, let’s make the problem smaller again. Fifteen people might not want to go from exactly one place to exactly one other. But fifteen people in a small area might want to go to various destinations in another small area. How about instead of picking you up directly from your home, BigCar picks you up from a nearby node, maybe a minute or two’s walk from your home. and drops you off in much the same way.
That’s a little better, but still imperfect. People still need to go to all sorts of places at all sorts of times. And we want as many people in each BigCar as possible to reduce the total number of vehicles on the road. So what do we do?
Okay, what if we did a some large-scale planning to make this easier? What if we made a grid of nodes all across the city, maybe a five minute’s walk from each-other, and created various links connecting these nodes to their neighbors.
Once we have these links, we use some sort of traversal algorithm to string links together into pathways, making sure that each node is connected via pathways to its neighbors. We then assign BigCars to travel up and down these pathways, picking people up and dropping them off as needed.
This tactic allows us to do something really fancy: it abstracts journeys from individual vehicles and into the transit network itself. The question of “Which BigCar do I get on?” is no longer about its final destination but about which direction it’s traveling. If you’re living on a standard street grid and your destination is five miles west and six miles north, you can take a BigCar traveling west for five miles, get off at the mile-five node, then take another BigCar six miles north to the nearest node to your destination.
This does add a bit of complexity to your journey, because now you’re talking about getting in and out of multiple vehicles for a single trip. And it could entail a fair bit of waiting for the next BigCar to arrive if there aren’t enough assigned to a particular pathway.
You can offload the complexity of mapping out a journey through computing: simple traversal algorithms can tell you exactly which pathways to take to which nodes, which could easily be implemented in an app on one’s phone.
The waiting problem can be ameliorated substantially by simply having more BigCars on each pathway and staggering their arrival out, or creating shorter or more efficient pathways for them to traverse. For a large city it’d probably take a lot of careful planning by a number of skilled experts, but once our engineers figure it out the whole thing’ll sail smoothly.
I’ve been talking about traveling around a city, but what about for longer journeys? Luckily this solution can scale by nesting multiple networks of varying levels of abstraction into each-other. For local trips, each node might be a street corner and each link a few blocks. For larger trips, a node might be a city or a district of a city and a link the miles of road connecting them. For really long trips a node might be a regional capital and a link a stretch of highway dozens or hundreds of miles long.
You can then traverse this network of networks in a hierarchical manner. Use the local network to get to your city’s regional node, then take the regional network to get to your county’s national node, then follow the national network to your destination’s regional node, then through the regional network, then through the local network to the node nearest your destination.
Solution: Right Place, Right Time
This network model for operating BigCars allows us to do something else really clever.
One of the reasons why road intersections are so complicated is because they’re unpredictable. Any number of cars could show up at any intersection in any configuration at any time. Intersections have to deal with all sorts of contingencies, as do the vehicles traveling through them.
But the sort of holistic, big-picture thinking BigCars require of us, with their standardized pathways being traversed in predictable ways, enables us to use a very powerful tool: scheduling.
Imagine this: We’ve got a simple cross-intersection of two streets, one going east-west, the other north-south.
We’ve done a bunch of clever math and determined that, in order for our transit system to work optimally, we need to send 2 BigCars per minute in both directions on both of these roads.
Normally this would require some deconfliction techniques: a stop sign or traffic lights or what have you. But we can also do something else. What if we scheduled the various pathways so that, at the top of each minute and at +30 seconds, an east- and west-bound BigCar traveled through this intersection. Then at minute +15 and minute +45 seconds, a north- and a sound-bound one went through. If we can stick to that schedule then suddenly we have a situation where there’s no conflict. At any given time, the only BigCars at the intersection can easily pass each-other with no fear of collision. They don’t need to stop, or weave meticulously through the melee. They can just carry on down an open road.
This method becomes harder to implement at busier intersections. What if we decided we needed 20 BigCars in each direction on each road? That’s a much harder schedule to keep, and a much narrower window to cross the intersection.
So let’s make the cars bigger. We could go back to the 2-per scenario above if we created a BiggerCar with 500 seats and an average occupancy of 150. A very large car, but science has gotten us this far. Surely it can take us to such a glorious future.
Bringing it All Together
Things really start synergizing when we combine all these disparate solutions into a single cohesive whole.
The Grade Separation strategy we mentioned earlier works great for reducing complexity, but let’s be frank. Rebuilding every road in the United States (let alone the broader world) to be grade-separated would be enormously expensive and incredibly disruptive. But if we’re using the BigCar networking strategy, we only need to grade-separate roadways along links. Combine that with the weather-proofing of the Dig a Hole strategy, and we could keep the entire streetscape the same and create a network of underground tunnels for self-driving vehicles. Being underground also makes it easier to create efficient pathways, since we don’t need to adhere them to the original street grid.
While a 50-person vehicle is feasible, a 500-person car seems pretty impractical. If nothing else it’d be so long it’d struggle to get around corners. But if we’re using the Guideway strategy, we can create a segmented vehicle that can bend along its entire length to accommodate tighter corners and let the guideway handle the rest.
Putting the guideway underground to get it away from the weather gives you more freedom to optimize turning radii, which can allow for higher speeds and safer maneuvers. Likewise, since the guideway creates much more predictable vehicle paths than a standard road surface, you can build your tunnels to much tighter tolerances, making them smaller and thus easier (and less expensive) to dig.
Bringing together guideways, tunnels, and BiggerCars also allows us to more completely solve the stoplights problem. If we have a small enough number of vehicles on our dedicated network, we can make use of an old technique known as Block Signalling. This strategy breaks up a guideway into a number of discrete blocks, each of which can only have a single vehicle in them. When a block is empty, it flags itself as green and lets vehicles enter it, but as soon as it does the signal switches to red, preventing further access until the vehicle has passed. This information can easily be relayed over a metal guideway and provides a foolproof way to prevent collisions, so long as the blocks are large enough to accommodate a vehicle’s stopping distance.
This does have the disadvantage of only letting a single vehicle navigate an intersection (or two if they’re traveling parallel to each-other), but a combination of BiggerCars and careful scheduling can reduce or even eliminate the inconvenience. For exceptionally busy intersections, we can use grade separation much as it’s used in highway intersections, letting perpendicular traffic cross at different heights and thus on different blocks, allowing them to pass each-other without issue.
It’s neat, isn’t it? How all these various solutions interact with each-other, amplifying each-other’s strengths and covering for each-other’s weaknesses? That’s essentially what all good engineering systems need to do: have a bunch of parts and components all working together to support each-other. And while I’m sure there are a lot of complications and edge-cases and contingencies I haven’t thought of (being only 65% of a programmer and not any % of a civil engineer), the general concept has a lot of promise, doesn’t it? It seems plausible that some combination of these elements combined with existing self-driving technologies could be the key to unlocking the future of transportation.
Have You Caught Me Yet?
There’s a good chance you’ve already figured out what I’m getting at, but just in case you haven’t:
Remember that question I asked at the beginning of the article? When will the first fully self-driving vehicle be available for public use? How confident do you feel in the guess you made? Well I’m feeling a bit spicy, so I’m going to say, with absolute confidence, that the first driverless vehicle will be available for public use in…
1981!
Because that’s when the driverless Port Island Line was opened in Kobe, Japan.7
In fact, there are dozens of metro lines, and dozens more people movers, all over the world that require little or no driver intervention. This includes several of the lines on the Shanghai Metro, one of the world’s largest, which handled 3.88 billion rides in 2019.8
All of these systems achieved this feat not with sophisticated large-language models processing dozens of gigabytes worth of data per minute, or by creating autonomous digital agents that could handle every possible situation that might arise on a road. They didn’t scrape the entire Internet for training data or put surveillance devices in every new vehicle to track the movements and behavior of tens of millions of people. They achieved their gains with clever designs to reduce or eliminate situations that made the task difficult, and they realized those designs in large part not through computation, but concrete and steel.
Every suggestion I’ve made to solve the self-driving problem was simply taking a car and making it more like a train. Because ultimately a well-designed passenger railway is the best way of moving large numbers of people from place to place. They work by creating a controlled environment with a known number of large and space-efficient vehicles whose movements are carefully scheduled against each-other to maximize the number of people they can move. And they can be electified without massive batteries weighing them down and devastating the environment. For the vast majority of car trips the average American takes, the best self-driving vehicle isn’t a Tesla; it’s an S-Bahn.
In Conclusion
If you, like so many others, think that self-driving cars are the solution to the world’s problems and you found even one of my arguments convincing, consider looking into this more closely. Go do some research on public transit, watch some urbanist YouTube videos. Because none of this is new or untested technology; we’ve had the ability to solve our transportation problems and decarbonize the act of movement for decades. The world we live in is a far cry from the better futures available to us right now, with proven technology and our existing industrial capacity. We don’t need self-driving battery-operated electric cars to make the world a better place. We just need some fucking trains.
Wikipedia: (https://en.wikipedia.org/wiki/History_of_self-driving_cars)
Originally from Jeff Atwood (https://blog.codinghorror.com/the-best-code-is-no-code-at-all/), though I originally discovered it somewhere else
I can’t figure out exactly where this came from, but the typical retelling seems to be from Brian Christian (https://toptech.news/when-ai-flags-the-ruler-not-the-tumor-and-other-arguments-for-abolishing-the-black-box-vb-live/)
https://www.theguardian.com/environment/2022/jun/03/car-tyres-produce-more-particle-pollution-than-exhausts-tests-show
Did you know tire recycling is mostly just burning them for fuel? Now you do! https://en.wikipedia.org/wiki/Tire-derived_fuel
Center for Sustainable Systems, University of Michigan. 2023. "Personal Transportation Factsheet." Pub. No. CSS01-07
https://en.wikipedia.org/wiki/Port_Island_Line
https://en.wikipedia.org/wiki/Shanghai_Metro