Why do edge cases make system design really hard?
About 18 months ago, I was sketching out a problem with how equestrian road users – horse riders – might be seen, or rather, not seen, by ADAS or autonomous vehicle perception systems.
It developed into a number of wheeling and occasionally humourous conversations, many of which I used to demonstrate why vehicle perception can be simple and effective, but also complex and vulnerable. I realise now that actually it’s a useful demonstration of why ‘edge cases’, those situations which even make experienced drivers nervous about their abilities, will provide a myriad of difficult to predict and challenging to resolve.
The question to start with is “How would you detect a horse and its rider, assuming it’s just out of sight?”
Straight away, unless you’re talking about experimental round-the-corner vision systems, that immediately discards camera, lidar, radar and ultrasonic sensors. Maybe the horse-rider has a wearable IoT device, or perhaps a mobile app, pinging their location?
I asked the Director of Safety at the British Horse Society, and he said “As a driver, the advice we give is look for clues.. the most common one is Horse droppings on the road.”
Warm Brown Eggs
So if you want to predict the likely presence of a horse, watch out for manure, if it’s flattened, the horse is probably long gone, if it’s lumpy and steaming – get out your sugar lumps. Oh, and make sure you’re ready to slow down and drive more carefully, too.
You might laugh at the idea of using radiating heat from horse manure to give you an indication of recent equestrian traffic, but why not? It’s a perfectly valid data point, after all.
We know that most cars are monitoring the air temperature outside, so couldn’t we also monitor the temperature of a distant object using FLIR, or even, as it’s flung into the wheel-arch, using a self-cleaning contact sensor?
As with many detection systems, this comes down to cost, complexity and practicality. Can it be used for anything else? What cost-benefit is there to adding this to a car?
There’s a small market for remote temperature measurement, but the cost of reliably measuring the remote temperature, reliably, of a distant number two, is quite slim. In short, such a system doesn’t add a great deal of usefulness, other than perhaps when travelling through Death Valley and knowing when it’s OK to fry an egg on the road surface.
A tough nut to crack
Horse riders generally wear protective equipment, a helmet, back brace, and on roads, some high-viz reflective items with retro-reflective tape (this is the stuff that seems to light-up when a beam of light is shone on it, thanks to the billions of microscopic glass beads embedded in special tape which reflects light back along the same angle it came from, thanks to the beads’ ‘total internal reflection’).
But we already know we can’t see the rider (remember, it’s around a corner), so visibility aids won’t help us.
Why not just equip our rider with a radio beacon, constantly emitting a location and identity beacon? Don’t most riders also carry a mobile phone? Let’s send a signal to the car!
But smartphones operate on a high frequency and cars generally only receive Wifi, Bluetooth (both of which are very short range) and entertainment signals at lower frequencies which smartphones don’t use.
Watch latest videos from AutoSens on YouTube
► Improving and implementing traditional computer vision algorithms…
► How deep learning affects automotive SOC and system designs
► Coherent Lidar for Autonomous Driving – Radial Velocity on Every Data Point
So, what can we use? We’re still facing a problem, although we have a computer on the horse, and computer in the car. It’s really a problem of compatibility.
Follow the breadcrumbs…
In the world of the web, you probably know that a cookie is a small piece of information purposely left somewhere to perform a purpose. This might be to keep you logged in to a website, help you remember what you were doing recently, pick up watching a video where you left off, help a website (and its owner) learn about you and what you’re doing online, or show you more relevant adverts.
In short, cookies are a great way to store a small piece of information relating to a thing or a behaviour. How a system is configured to store and retrieve that information is very flexible, so here’s an idea to resolve our problem of horses wearing Elven invisibility cloaks.
Our horse rider has an app on their smartphone, which reports their approximate location and a time stamp, perhaps also information about the horse or horse-drawn vehicle – no personally identifiable information required. This is a cookie containing very simple geographical and time information.
The timestamp approach also allows for the expiry of said geocookie, let’s say 10 minutes after the horse has passed.
Traffic data, of which this is a similar type, is transmitted to cars on the FM band, encoded into RDS signals and received on very low cost systems in most GPS units, radio receivers and smartphones.
With minimal modification (primarily in software in your navigation app), it might not take a great deal of work to have a constant flow of data from horse riders to warn country-side drivers of road users hidden by hedges, sunlight or riverside trolls.
Data, data everywhere and not a drop to drink
This idea gets past technical boundaries, physical barriers and relies entirely on a connected eco-system. The cost is low, technical implementation is primarily software orientated, and benefits clear.
I’m not suggesting that this is a real or indeed practical answer to the problem as it might one-day be deployed as a commercial product or a free software update, but for the issue of being safer in a rural driving environment, simply ladling more and more sensors and computer power in to cars cannot be the answer, especially when the financial justification is impossible to balance with the investment needed for a dedicated system.
It’s my belief that there will be a point at some juncture between now and 2025 that accepted on-vehicle hardware for ADAS and AV will level-off, to widely accepted standards, perhaps including IEEE SA P2020, and the software market for algorithmic exploitation and innovation will develop to cater for unusual and edge cases.
Solutions like the one I describe here, to problems which have a challenge in justifying investment, might not have to rely on anything new but instead apply tried and tested principles, existing hardware in the built environment, with capabilities being deployed through over-the-air software updates.
In short, once the car is itself an advanced computing device with fixed hardware capabilities, innovation will refocus on what else the car can do.
To mangle a line from the TV show “Halt and Catch Fire” (a must-watch for nerds): “Driverless cars aren’t the thing, they’re the thing that get us to the thing”
Uncover the future of autonomous vehicle technology at AutoSens. Book your tickets to attend here >>