Deze blogpost is oorspronkelijk gepubliceerd door Mobileye, een Intel-bedrijf. Het is hier herdrukt met toestemming van Intel.
Op de Consumer Electronics Show in januari presenteerden we een onbewerkte video van 25 minuten van een zelfrijdende auto van Mobileye die door de drukke straten van Jeruzalem navigeert. De video is in de eerste plaats gepubliceerd om de transparantie te bevorderen. We wilden de uitzonderlijke mogelijkheden van onze technologie demonstreren, maar nog belangrijker, de wereld laten zien hoe autonome voertuigen (AV's) werken, zodat de samenleving ze gaat vertrouwen.
Als we deze inspanning voortzetten, introduceren we vandaag een nieuwe onbewerkte video van 40 minuten van een rit bestaande uit een klein gedeelte van 160 mijl van de straten van Jeruzalem die we gebruiken voor onze AV-ontwikkeling. We kozen ervoor om de rit met een drone te volgen om de besluitvormingslogica van de robotagent goed van context te voorzien, en de enige interventie tijdens de rit was om de batterij van de drone na ongeveer 20 minuten te vervangen. We hebben ook gesproken tekst toegevoegd om uit te leggen waar en hoe onze technologie omgaat met de grote verscheidenheid aan situaties die we tijdens de rit tegenkomen. De volledige clip is hieronder ingevoegd en een aantal korte gedeelten van de schijf worden aan het einde van dit hoofdartikel gemarkeerd.
De onbewerkte rit van 40 minuten in het autonome voertuig van Mobileye
De clip biedt ook de mogelijkheid om onze benadering van AV-ontwikkeling te verwoorden – die voor zover we weten uniek is en opvalt tussen de verschillende spelers in de AV-industrie. Het probleem dat we willen oplossen is schaal. De echte belofte van AV's kan alleen op grote schaal werkelijkheid worden – eerst als een middel voor het delen van ritten via robo-shuttles en later als personenauto's die aan consumenten worden aangeboden. De uitdagingen om AV's op schaal te ondersteunen, draaien om kosten, verspreiding van HD-kaarten en veiligheid. Het punt dat ik hier wil maken, is dat veiligheid de software- en hardware-architectuur moet dicteren op manieren die niet voor de hand liggen.
In 2017 publiceerden we ons veiligheidsconcept, dat gebaseerd was op twee observaties. De eerste is dat ongevallen die worden veroorzaakt door beoordelingsfouten in het besluitvormingsproces (bijvoorbeeld bij het invoegen in het verkeer) effectief kunnen worden geëlimineerd door op een formele manier duidelijk te maken wat het betekent om “voorzichtig” te zijn bij het plannen van manoeuvres, en dit bepaalt uiteindelijk de balans tussen veiligheid en bruikbaarheid. Ons Responsibility Sensitive Safety-model stelt metrische parameters vast rond de aannames die chauffeurs doen (zoals “voorrang gegeven, niet genomen”) om veilige beslissingen te nemen. Deze parameters worden vastgesteld in samenwerking met regelgevende instanties en normalisatie-instellingen. Vervolgens gaat het RSS-model uit van het worstcasescenario binnen de grenzen van de overeengekomen aannames van wat andere verkeersdeelnemers zullen doen, waardoor het niet meer nodig is om voorspellingen te doen over het gedrag van andere verkeersdeelnemers. De RSS-theorie bewijst dat als AV's de veronderstellingen en acties volgen die door de theorie worden voorgeschreven, het besluitvormingsbrein van de AV nooit een ongeluk zal veroorzaken. Sindsdien is RSS over de hele wereld met grote tractie gepromoot. Zo heeft de IEEE eind 2019 een nieuwe werkgroep ingesteld onder leiding van Intel om een standaard te ontwikkelen – IEEE 2846 – voor AV-besluitvorming. Leden van de groep vertegenwoordigen in grote lijnen de AV-industrie als geheel. Dit is voor mij een zeer geruststellend teken dat we door sectorbrede samenwerking een cruciale mijlpaal kunnen bereiken die de hele branche naar een hoger niveau zal tillen en ons in staat zal stellen vooruit te komen.
De tweede observatie in de paper die we publiceerden had een diepgaand effect op onze systeemarchitectuur. Ervan uitgaande dat het besluitvormingsproces van de robotbestuurder wordt geregeld (bijvoorbeeld via RSS), blijft de mogelijkheid bestaan dat een storing in het waarnemingssysteem een ongeval veroorzaakt. Het waarnemingssysteem is gebaseerd op camera's, radars en lidars met software die de ruwe gegevens van de sensoren interpreteert in een 'omgevingsmodel', vooral van de positie en snelheid van andere weggebruikers. Er is altijd een kans, zelfs als deze oneindig klein is, dat het waarnemingssysteem het bestaan van een relevant object (of het nu een weggebruiker of een levenloos obstakel is) zal missen, of de metingen verkeerd zal berekenen, en een ongeval zal veroorzaken.
Om te waarderen waar we mee te maken hebben, laten we een eenvoudige “achterkant van de envelop” -berekening doen. Het aantal gereden kilometers in de VS is ongeveer 3,2 biljoen per jaar en het aantal ongevallen met verwondingen is ongeveer 6 miljoen. Uitgaande van een gemiddelde snelheid van 10 mph hebben we een gemiddelde tijd tussen storingen (MTBF) van 50.000 uur rijden. Stel dat we onze AV ontwerpen met een MTBF van 10x, 100x of 1000x beter dan menselijke MTBF (merk op dat we hebben uitgesloten dat we “zo goed als mensen” zijn, we weten dat we beter moeten zijn). Overweeg om 100.000 robotauto's in te zetten om op grote schaal als robo-shuttles te dienen. Dit aantal komt overeen met de cijfers die door spelers in de ride-hailing-ruimte zijn opgehaald om enkele tientallen steden te ondersteunen. Stel dat elke robo-shuttle gemiddeld vijf uur per dag rijdt. Dus met een 10x MTBF-ontwerp zouden we elke dag een ongeval moeten verwachten, met een 100x-ontwerp een ongeval per week en met een 1000x een ongeval elk kwartaal. Maatschappelijk gezien zou het een enorme prestatie zijn als alle auto's op de weg 10x beter zouden zijn op MTBF, maar vanuit het perspectief van een exploitant van een wagenpark is een dagelijks ongeval een ondraaglijk resultaat, zowel financieel als publiekelijk. Het is duidelijk dat een ondergrens van 1000x op MTBF een must is (en zelfs dan is een ongeval per kwartaal nog steeds zenuwslopend) als AV-at-Scale het doel is. Een MTBF van 1000x vertaalt zich naar 50 miljoen uur rijden, wat ongeveer 500 miljoen mijl is. Zelfs het verzamelen van deze hoeveelheid gegevens om de MTBF-claim te valideren is onpraktisch, om nog maar te zwijgen van het ontwikkelen van een perceptiesysteem dat om te beginnen aan zo'n MTBF kan voldoen.
Al het bovenstaande is de context voor onze keuze voor systeemarchitectuur. Om zo'n ambitieuze MTBF voor het waarnemingssysteem te bereiken, moeten redundanties worden geïntroduceerd – met name systeemredundanties, in tegenstelling tot sensorredundanties binnen het systeem. Dit is alsof ik zowel iOS- als Android-smartphones op zak heb en mezelf afvraag: hoe groot is de kans dat ze allebei tegelijk crashen? Naar alle waarschijnlijkheid is dit het product van de kansen dat elk apparaat vanzelf crasht. Evenzo, in de AV-wereld, als we een complete end-to-end AV-mogelijkheid bouwen die alleen op camera's is gebaseerd, en vervolgens een volledig onafhankelijke mogelijkheid bouwen met behulp van radars/lidars, zullen we twee afzonderlijke redundante subsystemen hebben. Net als bij de twee smartphones neemt de kans dat beide systemen tegelijkertijd waarnemingsfouten ervaren drastisch af. Dit is heel anders dan hoe andere spelers in de AV-ruimte omgaan met perceptie die zich hebben gefocust op sensorfusie. Het is veel moeilijker om een AV met alleen camera's te bouwen dan om een AV te bouwen die alle gegevens van alle sensoren tegelijk combineert. Camera's zijn notoir moeilijk te hanteren omdat de toegang tot diepte (bereik) indirect is en gebaseerd is op signalen zoals perspectief, schaduw, beweging en geometrie. De details over hoe we het AV-systeem met alleen camera's hebben gebouwd, worden verwoord in de lezing die ik op CES gaf (vanaf 12 minuten).
Dit brengt me terug bij de clip die we vandaag introduceren. Het toont de prestaties van ons subsysteem met alleen camera's. Er zit geen radar of lidar in de auto die je in de clip ziet. De auto wordt aangedreven door acht langeafstandscamera's en vier parkeercamera's die worden ingevoerd in een computersysteem dat is gebaseerd op slechts twee EyeQ5's. De auto moet een balans vinden tussen wendbaarheid en veiligheid en doet dit met behulp van het RSS-framework. De straten van Jeruzalem zijn notoir uitdagend omdat andere weggebruikers de neiging hebben om zeer assertief te zijn, wat een aanzienlijke uitdaging vormt voor de besluitvormingsmodule van de robotbestuurder.
We zullen doorgaan met het delen van de voortgang en inzichten van onze reis naar AV-at-Scale. Houd ons in de gaten voor meer updates.
Professor Amnon Shashua
Senior Vice President, Intel Corporation
President en Chief Executive Officer, Mobileye, een Intel-bedrijf
Navigeren door een smalle straat en een onbeschermde bocht naar links nemen
<Een rotonde met meerdere rijstroken
Ingewikkelde bocht naar links
