A new system could reduce the cost of implementing I2V communications across a city to less than that for a single intersection, as Colin Sowman hears.
It may seem too good to be true but US company
Already several US authorities have taken up the offer, as have a few in the Netherlands, Australia and New Zealand. Now the company is now looking for other authorities in Europe and elsewhere to try its technology. According to the company’s CEO Matt Ginsberg, the system typically allows city authorities to provide signal timing information for around 80% of their signalised intersections for less than it would cost to instrument a single junction using dedicated short range communications (DSRC). What is more, this is achieved without needing to install equipment in the traffic light or roadside controller and the complete system can be up and running within three months.
The basis of the system, called V2If (Vehicle to Infrastructure for Free), is a Raspberry Pi-based device which monitors the communications between the roadside signal controllers and the traffic management centre (TMC).
Those communications are then processed to determine future signal changes and that information is then made available to drivers and third parties over the internet.
“We don’t intervene in the communications system, so there are no warranty or compatibility issues with the existing equipment
Our algorithms can determine the timing and sequencing of the lights and then predict when the changes will happen,” says Ginsberg. “We then make that information available via the internet so it can be used in ‘Speed to Green’ and other applications.
“It would cost around $20,000 to instrument a single intersection with traditional DSRC in each signal head and at the roadside. We can do a whole city for less than that – in fact the equipment, support and maintenance is free to city authorities.
“We have found it really works well. We can get the data from the V2If device up to half a second before the TMC output - depending on how the TMC’s processes are prioritised. It is also more stable because the TMC is not processing the data, potentially introducing errors, and sending it back out.”
Currently the system is being installed in several cities and according to Ginsburg, “they just love it. It is an incredibly clean and passive solution.”
Installation is confined to plugging the system into one port on an Ethernet switch in the TMC and deciding what information should be mirrored to that port - normally that from the lights into the TMC. The system then ‘listens’ in on and learns to understand the messages coming from the traffic lights and then it starts predicting the timing and sequencing going forward.
“The only reason that could prevent it working outside the US is that we have to understand the format of those messages. So if authorities tell us what data standard they are using, we can do everything else,” he says, adding that reverse engineering is also possible.
“I’d be thrilled to partner with cities in Europe and elsewhere to work out the various protocols. This is particularly easy with open standards and some vendors who use proprietary standards are sharing that with us.”
He is offering overseas authorities the same deal as in the US: “We will send the device for free, help them set it up and treat them as partners.”
On the technical side Ginsberg describes the system as ‘latency robust’: “Latency is an issue throughout this system including the mobile networks – it can take three seconds for a message to get to a cell phone.
To overcome this the system works on absolute time but there are three separate components: the lights, the user’s device and the server. “We know we get the signal information in real time so there is no latency to worry about. Our system also communicates with users’ devices and calculates the time error - it may conclude that the user’s phone thinks it is seven seconds earlier than it actually is.
“Our system will know that the light is green and will remain so until, say, 12:18.36 but on the user’s phone that will be 12:18.29. So we tell the phone the light will remain green until 12:18.29 and in that way it does not matter if there is latency getting the message to the phone. The EnLighten app on the phone then knows that the light will remain green until 12:18.29 so it can calculate if the vehicle will pass the lights on green and advise the driver accordingly.”
As most signals have an element of timing variation, adaption to traffic volumes, bus prioritisation, emergency vehicle pre-emption, a button for pedestrians wanting to cross the road…, the system needs six weeks of data before bringing a city on line. “We are looking for all the variations – time of day, pedestrian or vehicle calls and so on to know how the lights will respond.
“We also get pre-emption information in which case we stop making predictions for two cycles because each system has a different process of reverting to normal phasing,” explains Ginsberg, adding: “And we can’t learn the algorithm because there aren’t that many ambulances.”
The system can detect and locate ambulances by picking up prioritisation signals from the lights and can inform EnLighten users where the siren they hear is coming from and if they are likely to have to yield. “That makes drivers interacting with emergency vehicles so much safer,” he says.
Some lights are too variable to make predictions in which case EnLighten will display the colour of the light ahead without any change prediction. In the event there is no information about the colour of the light ahead, the screen simply displays a blue light.
Too good to be true? You’ll never know unless you give it a try.
