> that they only achieve a factor of two improvement (in theory!) reads as a stunning failure of autonomous vehicle technology to pull their weight in this regard.

Sounds like a profoundly interesting result to me -- strong evidence that we'd need to look elsewhere to increase transit carrying capacity. Maybe AI cars can't reduce traffic that much afterall.

This, so much. I wonder how much time and grant money is wasted because people don't publish negative results.

What I don't understand is why every traffic light doesn't have cameras and some image recognition/machine learning (whether local or remote) to improve the timing - it would be such a cheap and easy fix compared to putting a sensor in each car.

As others are indicating, this is tech exists, and in some places it's widely deployed, where in some others it's nowhere to be found. I've seen them in several US cities and suburbs, in many states, usually along major arterials and covering the busiest intersections.

Missouri Department of Transportation's St Louis District has one of the best FAQs [1] on this tech that shows how these cameras work: exactly as you'd suspect from some OpenCV proof-of-concept.

The cameras are a more robust replacement of the in-pavement induction loops, which are much more widely deployed, but give you a subset of the information at a higher cost.

[1] http://www.modot.org/stlouis/links/signalcameras.htm

Lots of traffic lights in my area already have sensors (induction loops to detect waiting cars or approaching bicycles, IR motion detectors to detect pedestrians). In some cases this is really useful (eg. a traffic light for a bike path does not need to switch very often in winter, so it only switches when a bike approaches)

I think that the problem is that often there is too much traffic from all directions and even with all the sensors in the world the traffic light can‘t change that.

I believe the induction loops only sense if the first car is present. This is helpful, but can't detect the number of cars which I think is the next most important metric.

There's also an amusing "failure mode" of induction loops: impatient people pulling up further into an intersection -- for example, aiming for an opportunistic left turn -- and they move off of the loop. The lights cycle; the left turn green arrow which would give them an exclusive phase never materializes.

At busy intersections, there will typically be a loop at the 1st spot and a second loop further back - say, at the 5th spot. It's not perfect, but it's pretty good.

This is usually called adaptive traffic control, and has been implemented (minus machine learning, I'm guessing) in a bunch of places, including a part of New York City [1] and, more famously, Australia [2]. The latter system, pioneered by the city of Sydney, has been sold to other countries such as Singapore. Not sure how technologically interesting these systems are. The Sydney system was developed in the 1970s, but has been improved with more modern tech (such as cellular networking) since then.

[1] http://www.nyc.gov/html/dot/html/pr2012/pr12_25.shtml

[2] https://en.wikipedia.org/wiki/Sydney_Coordinated_Adaptive_Tr...

Many traffic lights do have cameras/sensors to detect waiting traffic and measure wait times.

It's not always quite so simple as using ML to adjust light timing, however. In big cities, at least, traffic lights are sometimes deliberately intended to slow traffic down in order to reduce volumes and speeds on the street, or to reduce congestion elsewhere on connecting roads.

Sydney actually developed an integrated traffic light system titled "Sydney Coordinated Adaptive Traffic System" (SCATS) which has been exported around the world. It adjusts timing of traffic light systems using a variety of sensors - if a bus is running late it will affect the phasing to give it more green lights to try and get it back on time.

https://en.wikipedia.org/wiki/Sydney_Coordinated_Adaptive_Tr...

I believe the only car sensor for SCATS is an inductive loop so it doesn't know the amount of backed up traffic, and it was developed in the 1970s and rolled out across Australia in the 80s - it's better than a timer but I don't think it should be what the world aspires to.

That being said, I had some interesting conversations with a person who worked for Transport for NSW who said some of the signalling backend was recently improved to streamline future integration with self driving cars, I can't find a reference for this though.

A sensor itself isn't expensive but moving, storing, and processing all of that data to ultimately take action is.

Let alone concerns with people about being recorded in public, even if red light cameras are permitted in some states today.

A traffic light would only need to solve a much simpler problem than an autonomous car- after image-recognition, given the number of cars waiting/approaching at each direction, decide which lane(s) to give a green light to. Finding a reasonably optimal policy could be hard, yes, but once one is found that could be applied to all (or most) traffic lights, and it couldn't plausibly be more computationally intensive to run than the image-recognition step.

Meanwhile, if conversation involves a plausible future where all/most vehicles (inevitably including police cars and other government-owned vehicles) are autonomous and have the same kind of sensors, its hard to imagine the anti-surveillance angle being a decisive factor. I'm not for pervasive surveillance, and perhaps the NSA will be nice and claim really convincingly that they can't access records from traffic lights... but that bird has flown, anyway.

Even OpenCV running on a Raspberry Pi can pick out cars in a moving image - a bad offline solution (with a sensible fallback) would be better than a timer.

On a large remote setup I think you are right though.

OpenCV on a Raspberry does not sound like something that is reliable and easy to deploy.

It‘s a long way to go from something that you hack together in the living room to something you can deploy on hundreds of traffic lights, that works in every weather, that can easily be configured for different use cases, and that can be serviced by the technicians.

It can be:

https://resin.io

A Raspberry Pi is a surprisingly useful and cost effective device when it comes to IOT. Most industrially hardened devices of similar capacity cost a bit north of an order of magnitude more.

There are really only a couple of things that would need to be addressed, a good weather-tight case that allowed for heat dissipation, decent storage (most microSD has a short lifespan), and a good 5v power supply.

In many cases, designing a system that is cheap, expendable, and expected to fail is way less costly than the alternative.

Sone of what your saying is kind of making the point of the parent though.

Yes, you can make the software deployment go easier, and resin looks like an interesting project from that front. But that really is only a small part of the problen, and those hardware problems you described aren't trivial. The testing you described to convincingly show that your device can handle the environmental requirements isn't trivial. (And by environmental, I dont just mean weather, but also things like available power quality, vibration, etc.)

These industrial devices aren't expensive just because the suppliers aren't aware of RasPi, or are looking to gouge you. Its because they put in a lot of work to qualify these devices for their intended conditions. The RasPi, hacked up solution might actually be the WAY more expensive option over it's lifetime, if I have to roll maintenance crews every couple of months to replace SD cards or fix a flaky connector. And god forbid our code hangs in a way that makes all of the lights at an intersection green. "Oh you have a way to prevent that? Prove it." Designed to fail works fine for microservices where I can spin up a new instance rapidly, but it isn't the best match for industrial or infrastructure in most cases.

Apologies if I'm coming across overly snarky here. I genuinely love the RaspPi, and its got a great niche for prototyping, hacking up one-off projects, or even as the base for many types of connected projects. But I've also worked on industrial and infrastructure types of systems, and more than once I've seen someone say that they've got a cheaper solution to X, when really they've got something that may look cheaper if your only looking at upfront costs, but they are completely ignoring the lifetime costs of the solution.

No apologies necessary. I wasn't vehemently disagreeing with the parent so much as saying that the cost-benefit analysis is worthwhile.

I do some IIoT stuff, so I have a little experience here. Many of the lower cost PLCs and industrial edge devices have no better environmental characteristics than a Raspberry Pi. They just happen to be more expensive by comparison because they're competing in a market with much more expensive devices. In many cases, as you suggested, buying those devices is a false economy.

My point is simply that they're not that bad, and like you said, one should truly consider the lifecycle costs.

You are right. I'm trying to say I think the problem is development bound and not insurmountable (secure, reliable, good fallback to timer) rather than "moving, storing, and processing data" bound as per the parent comment.

I agree with you that developing a prototype wouldn't be too hard. But actually rolling it out within a few cities (and getting cities to pay for it) are where I think the complexities lie. I think it's a social or bureaucratic problem more than a technical one.

Magnetic loop sensors in pavement have been used to recognize vehicles at intersections for decades.

Government owned cameras at every intersection doing [anything] recognition sounds horrible.

>Better idea- instead of having the world pay for sensor/communication systems on every car, have the same sensor packages installed on the traffic lights so that they can operate in a smarter fashion.

Human drivers preclude such a system. The article actually is about replacing the intersection but you still need the self driving cars to actually perform the optimizations.

The Benz Patent Motorwagen had a top speed of 10 mph, roughly equivalent to a horse+carriage.

It will take time to iterate to get to the 4x-10x improvements we all hope to see.

It's a profoundly uninteresting result because, you know, we can already build autonomous trains. If you restrict the environment to what works for autonomous cars, we could have had them centuries ago. They will probably run on rails and look a lot like trains, but there you go..