Multi-vehicle coordination (MVC) is likely to be a new topic for most readers, so I will start with a brief summary.
Whilst we drive cars ourselves we naturally coordinate with other cars. This might be by flashing lights, using our turning indicators, our brake lights or even hand gestures.
The road layout also enables coordination. Traffic signals and give way signs provide legal coordination methods but also note that in some cases human coordination can override this – such as letting a person out onto a busy road.
Our view on MVC is more focused on connected and autonomous system coordination.
How can software create new and more efficient coordination methods for human driven cars, autonomous cars and human-in-the-loop situations where we have humans and software working together.
This blog will share some of our thoughts on what MVC is and how we will take it forward.
As Eloy moves towards higher focus on efficacy trails across our connected and autonomous vehicle technology, we will start to write more technical blog posts.
We are doing this for a few specific reasons: the range of audience will become narrower as the product becomes more technically complex; we seek to have specific feedback as we iterate across efficacy projects which need a higher level of technical communications; and we are starting to be more comfortable with our intellectual property protection (we have filed various patents).
Co-operation and co-ordination at roundabouts
Multi-vehicle coordination (MVC) is quite central to my heart. After graduating with a mathematics undergraduate degree, I completed postgraduate research into multi-agent simulations for self-driving vehicles. This ranged from M25 traffic jam modelling through to drones (aircraft).
However this was long before mention of Autonomous Vehicles, which only started to gain any sort of public awareness after the Mojave Tests in 2004.
MVC has huge benefits as we move to autonomous systems as vehicles can interact and maneouver in ways that human-driven vehicles cannot. Human coordination is reliant on physical signalling, which includes beeping a horn, flashing a light, using indicators or waving a hand.
Machine-based interactions can be substantially more complex, specific and faster in communication. There are high expectations that MVC will be a key component to the long-term benefits of autonomous vehicles: they can increase road safety, reduce congestion, alter how we interact with our vehicles, change how we park cars and lower our carbon footprints. We discussed part of this in an old blog.
However, MVC seems stuck behind a slower moving vehicle.
Autonomous vehicle (AV) deployment has slipped on its timeline to delivery due to safety and compliance and AVs alone don’t seem to have much of a specific benefit. AVs will be more expensive vehicles than human-driven if we require a direct return on capital. AVs will introduce new safety concerns, which has slowed their development. AVs need new legal frameworks, which has been undertaken by governments in recent years. With these legal and safety concerns, much of the AV focus has been on single-motion deployment. Can an AV drive on the road in a safe manner. This was initially done with on-board human safety drivers but now is more heavily on remote safety drivers. Progress but slow progress.
If MVC was to focus on on-the-road AVs, we could expect another decade of tests and trials to understand which services have the highest impact and determine their safety. Efficacy might be a long slog and we will need to manage any type of coordination with humans-in-the-loop. This brings us to why Eloy took a non-AV approach to AV software.
Turning humans into robots
Multi-vehicle coordination in the autonomous vehicle setting relies on the vehicles being robots. This robot technology (AVs) is the current constraint in progress due to needing to ensure road safety around humans.
The big question for Eloy was then Can We Turn Human Drivers into Our Robots?
We felt we could do this via the deployment of a SatNav system. If we provide SatNav instructions in a coordinated way – whereby we aim to move many vehicles in a defined pattern – we can learn about MVC systems and their efficacy today rather than waiting for AV deployment.
Further, the adjustment to SatNav could be quite subtle, with changes to the navigational instructions that are only advisory for the driver. This fits into the current road safety framework and with existing driver software service.
What type of multi-vehicle systems have we been looking at?
We have a master list of systems and they do vary. Whilst there are many millions of vehicles on our road network at any point in time, we will look to localize which vehicles coordinate and also define the situation that they are in. We also start to realize that we may have overlapping coordination tasks that need further consideration.
Our initial list to experiment with is as follows:
- Getting cars into a car park
- Getting cars out of a car park
- Passing Points on Country Lanes
- Overtaking a slower moving vehicle (eg bicycle)
- Platoons of vehicles on the same route
- Managing Roundabouts
- Optimal Speed Advisory
- Lane Merging
- Lane Changing
We’ll return to how we have progressed with these later in this blog but we needed to build a number of software solutions to set ourselves up in a position to be able to deploy our AV software without AVs!
Shopping list of required software
- Device with SatNav (Apple and Google mobile application)
- Car infotainment information (Apple CarPlay and Android Auto)
- General Neural Network (Maps, Roads, Digital Twin)
- Reinforcement Learning Toolkit (Game, Goals, Rewards, Rules)
- Driver communication methods (SatNav, In-vehicle signage)
Multi-vehicle coordination is the future – AI generated image
With our required shopping list we went through a large expansion of small-scale trials with various external partners.
The aim of each was to test the functional part of our shopping list and explore a wider range of potential MVC opportunities. We were also able to get a clearer view on existing challenges for deployment, including the attitude from incumbents, the near-term revenue opportunity and the shift in behaviour/processes by stakeholders. We will discuss those findings later on.
RAC pathfinder
In November 2021, Eloy took part in the RAC’s Annual London to Brighton Veteran Car Run. Here we modified Eloy’s SatNav to focus on a fixed route between Hyde Park and Brighton Promenade that the veteran cars follow.
Overall this test allowed us to see the SatNav running on a long trip with external drivers; understand the deployment of providing a fixed path we could externally manipulate; present drivers with in-vehicle signage and instructions, including lane merging; track car movement and location; use a plug-in module to our application that only specific vehicles are considered for coordination.
Overall this was a very good test of some key shopping list items. Further information can be found here.
ETSI compliance
One major request we received in 2021 was to show that our cellular approach could meet communication standards, including ETSI IVIM, CAM and DENM message types. A few large incumbents have solutions that we could leverage – including Vodafone and Yunex Traffic.
The goal here was to be able to add in driver communication (and hence coordination) that could be sourced from a central traffic management location. If messages such as potential roads to take, waypoints for navigation to pass through and vehicle type information could be encoded, we could increase the ways we can coordinate vehicles. It might be a case of sending certain vehicles down certain roads but then allowing the MVC software the opportunity to determine the best approaches to meeting the master instructions.
Overall this was a successful test of meeting communication standards but also where we internally see limitations in the current road management system: AVs will present new challenges that Eloy can explore ahead of time.
Multi-vehicle parking
We really like parking. A simple fact is that there is an obvious revenue opportunity where the MVC for parking can act as the service provider for the car park. Further, as car parks can limit their access, we could restrict access to compliant drivers – the weakness of using humans as robot proxies is that humans don’t always follow instructions and we cannot always ensure every vehicle is using the application (in fact very few might be using it).
Getting cars into a car park is far easier than getting them out. To get them in, we build a car park digital twin and allowed our AI to solve the fastest ways to pack a car park, noting that this could also be solved mathematically in a similar way to how NASA scientists have looked at optimal ways to get passengers onto an aircraft.
What is the most efficient way to get cars into a car park
Getting cars out of a car park is considerably harder.
When cars go in, they leave the road system as they park. They have a dedicated destination that we can navigate to and once they are in the car park we don’t need to worry about other road vehicles not wanting to park (we can get very localised in our coordination).
Getting cars out is much harder and usually where problems emerge, with significantly longer delays and traffic congestion.
Key items of coordination on exit is that we will need to coordinate with non-parked cars. As vehicles leave a car park, they interact with cars on the road. We would need to manage traffic signals and quite quickly this isn’t a simple or small coordination opportunity.
Running trials on car park entry would be a wonderful next step but incumbent car park operators don’t see commercial value in this service at thai stage – it doesn’t have an impact today and is likely to commoditise their own services in the future.
This is a problem area that will need solving in the future: will empty AVs look to park, how will they achieve it and will the commercial model change. Or will AVs look to circle or rely on taxi-like pooled services.
Whilst being a nice way to test coordination today, will it be a later deployment once AV critical mass is achieved?
Country lane passing points
We have all been on Country Lanes at some point, with passing points created as cars squeeze into hedges as they try to let other vehicles pass.
If we are lucky, we only come across one other vehicle and we have sufficient line of sight to stop at an appropriate passing point. If we are unlucky, we drive beyond a passing point and need to reverse. If we are very unlucky we don’t have sufficiently wide passing points for larger vehicles to pass or too many vehicles stack-up and cannot pass each other. If 20 vehicles need to pass 20 other vehicles coming the other way, there needs to be 20 passing points.
So if we go past one, we increase the risk of the unlucky situations and create a traffic jam.
Demonstration of virtual traffic lights
What we find from looking at this passing point problem is that it is a very good MVC situation.
Drivers require the additional communication capability of connected and autonomous vehicle technology: seeing round corners and further up the road. Simple wait and proceed SatNav messages can be sufficient to improve the traffic congestion that can form as well as increasing country lane road safety.
We can make it very localised to stretches of country lane, which is more suitable for processing power deployed on a mobile phone.
Key discussion points from our MVC work
Efficacy Evolution
The key part to doing MVC deployment with our human-robot proxies is to have an earlier on-the-road efficacy assessment compared to waiting for AV deployment. This allows us to improve software in the near future and improve larger AV MVC trials in the longer term.
Eloy’s Efficacy has generally followed vaccine progress in that we needed to build specific testing apparatus to run initial small trials across the broader opportunity set and then increase focus and technical assessment in later stage trials.
Early simulation estimates indicate about 20% time saving from MVC systems for Country Lane passing points and up to 80% time saving for car parking entry and exit. The SMMT estimates that connected and autonomous vehicles will save 20% of our time on the road
Training of our AI
Digital space training has been successful to date and we’re about to start trials on public roads. The Red line in the chart above represents the reward earned by the AI and it is significantly higher than the base case green line.
What is the most efficient way to get cars into a car park
AI Rewards are generated from a mix of safety and reduced congestion, so we can translate the additional AI reward back to time saved for drivers and lower collision risk. However the next part is ensuring a suitable user experience and software reliability is in place – which we will investigate over a series on-the-road trials.
MVC Types, Revenue Models, Incumbent Barriers and Deployment
MVC interaction | Clear revenue model | Incumbent barriers | Difficulty to solve |
---|---|---|---|
Cyclist overtaking | No | No | Low |
Car park filling | Yes | Yes | Low |
Car park emptying | Yes | Yes | High |
Vehicle platooning | No | No | Medium |
Managing roundabouts | No | No | Low |
Optimal speed advisory | No | No | High |
Lane merging | No | No | Low |
A quick analysis of various MVC near-term opportunities doesn’t present clear revenue models that are easy to establish. In most cases we still struggle to have obvious ways to make money outside of car parks whilst the car parking industry presents existing barriers due to the existence of clear revenue models.
Car parking, in some ways, is a nice example of the challenge: it is an excellent and relatively low risk way to test and train artificial intelligence but has incumbent barriers that receive little benefit to support a technology that could displace some of their services.
An important caveat is that parking operators already offer a very valuable service and how does new technology interact with that: the MVC software needs to increase overall revenue opportunity for parking operators. Easier said than done!
This list isn’t an exhaustive compliation of near-term MVC opportunities, with ports, freight, logistics and other options all available with positive prospects. We look forward to the next stages and will increase the technical descriptions throughout our efficacy trials.
Finally, does the financial benefit justify government investment. Whilst we see large-scale value for car makers as drivers may pay a premium for the luxury of autonomy, there is a considerable safety and congestion reduction potential that is a societal benefit. If this is the case and can be proven with efficacy assessment, we need to start considering that enabling digital roads for connected and autonomous vehicles is a variable government investment. In fact, given we are facing constraints on new roads, this is a much wiser option than more road and more transport capacity but making existing infrastructure more efficient.
The SMMT suggests connected and autonomous vehicles will save 20% of driver time per year, which translates into many billions of pounds of economic benefit per year in the UK alone. MVC is the main way this benefit is achieved. The prospect is very encouraging.