Author:
Frank Engels is automotive-engineer bij TMC en TNO.
Reading time: 5 minutes
Bij proeven met coöperatief rijden heeft TNO een aantal testvoertuigen voorzien van een boordcomputer op Android. Al communicerend met de wegkant zorgen de kastjes voor een soepelere doorstroming na plotselinge remincidenten. Frank Engels beschrijft hoe het TNO-team de benodigde software heeft ontwikkeld.
Op een zondag in mei 2011 trapte een automobilist op de drukke A270 van Helmond naar Eindhoven ineens op de rem. Deze plotselinge vertraging dwong de bestuurders vlak achter hem ook te remmen, met een schokgolf als gevolg. Zelfs als het voorste voertuig direct weer optrekt, kunnen dergelijke schokgolven het verkeer tot stilstand brengen omdat elke volgende bestuurder in de keten weer sterker vaart mindert om een botsing met zíjn voorganger te voorkomen.
Op deze specifieke dag ontstond er echter geen file. Dat kwam doordat tien tot dertig procent van de voertuigen was uitgerust met een nieuwe technologie. Een wezenlijk onderdeel is de on-board unit (OBU), een boordcomputer die in ontwikkeling is bij Tomtom. Dit kastje draait op Android en bevat naast de gangbare navigatiefunctionaliteit ook software om schokgolven te dempen.
De OBU werkt daartoe samen met controle- en regelapparatuur in de berm. Langs de A270, over een traject van vijf kilometer, staan 48 op palen gemonteerde videocamera‘s op honderd meter van elkaar en elf communicatiekasten (roadside units of RSU‘s) op vijfhonderd meter van elkaar. De RSU‘s verwerken de camerabeelden, berekenen op basis daarvan optimale snelheidsprofielen voor de voertuigen die op de verschillende snelwegsecties rijden en verzenden deze via Wifi naar de wagens.
Zodra een van de RSU‘s het begin van een schokgolf waarneemt, berekent hij aangepaste profielen om de naderende auto‘s geleidelijk vaart te laten minderen. Ver van het incident hoeven wagens hun snelheid waarschijnlijk maar een klein beetje of zelfs helemaal niet te verlagen; dichterbij moeten ze langzamer gaan rijden, maar niet zo veel dat ze de schokgolf voortzetten. Zo is het de bedoeling dat het verkeer na plotselinge remincidenten toch soepel doorstroomt.
Het gedrag van voertuigen die communiceren met een RSU beïnvloedt ook het gedrag van andere weggebruikers in de verkeersstroom. Daarom hoeven we niet alle auto‘s te voorzien van een OBU. Sterker nog: van de 68 wagens in de coöperatieve-rijexperimenten hadden er slechts twintig zo‘n kastje. Daarvan hadden er acht een adaptieve cruisecontrol (ACC), die rechtstreeks werd bestuurd door de OBU en automatisch de snelheid van het voertuig regelde. In de overige twaalf toonde de boordcomputer de optimale snelheid op zijn display en zorgde de bestuurder zelf voor het versnellen en afremmen.
De OBU stelt de huidige snelheid van het voertuig vast aan de hand van coördinaten die het kastje verkrijgt via het geïntegreerde GPS-systeem en de versnellingsmeter. Daarnaast verwerkt het de snelheidsprofielen die het ontvangt van de RSU‘s. Op basis daarvan updatet het zijn display en genereert het, indien van toepassing, de instelling van de ACC.
Rechts: De resultaten van een test uitgevoerd onder gelijke omstandigheden maar met het schokgolfdempsysteem ingeschakeld. Het remmen van het eerste voertuig verloopt op exact dezelfde wijze als in het vorige experiment. In deze test genereert een van de RSU‘s echter een snelheidsprofiel op het moment dat hij de eerste schokgolf waarneemt. Wagens uitgerust met een OBU verlagen hun snelheid op 1500 meter achter de schokgolf tot 65 km/u. Als gevolg daarvan ontstaan er gaten in de verkeersstroom (zichtbaar als witte zones in de figuur). De eerste schokgolf is na slechts dertig seconden al gedempt. Even later remmen de voorste voertuigen nogmaals. De tweede schokgolf die dit tot gevolg heeft, is opnieuw met succes gedempt. Het verschil tussen beide remacties is dat de met OBU uitgeruste wagens de eerste test reden met de ACC in adviesstand, terwijl deze de tweede proef in de automatische stand stond.
Shared library
Het volledige besturingssysteem van de OBU hebben we gemodelleerd in Simulink, waarna we simulaties hebben uitgevoerd met input uit eerdere proeven. De weken voorafgaand aan de experimenten op de A270 hebben we de Mathworks-tool in ’external mode‘ gebruikt om de interfacing met de Can-bus in de auto‘s, het OBU-display en de RSU‘s realtime te controleren. Dankzij deze simulaties en hardware-in-the-looptests konden we problemen in onze algoritmes opsporen en oplossen voordat we de weg op gingen. Dit bleek van essentieel belang voor het succes van het project, aangezien de A270 voor elke proef dicht moest voor het overige verkeer en we telkens 68 auto‘s en bestuurders moesten regelen.
Het OBU-besturingssysteem modelleren en simuleren was relatief eenvoudig; het TNO-team beschikt over voldoende ervaring met modelgebaseerd ontwerpen. Software ontwikkelen voor Android was echter nog onbekend terrein voor ons. Deze onervarenheid kwam naar voren toen we de sensorgegevens van het GPS-systeem en de versnellingsmeter wilden binnenhalen in onze applicatie. Het Google-OS stelt die data heel netjes beschikbaar aan alle toepassingen, maar dat zijn doorgaans Java-apps en wij konden geen Java genereren uit ons Simulink-model.
De oplossing lag in de Android Native Development Kit (NDK). Hiermee zijn apps te ontwikkelen in basisprogrammeertalen als C en C++. Voor de NDK moeten deze toepassingen echter niet draaien als executable maar als shared library (zie het artikel van Klaas van Gend op pagina 40, NR).
In ons project hebben we daarom een speciale ’target‘ gemaakt voor Simulink Coder waarmee we in plaats van een executable een gedeelde bibliotheek kunnen genereren. Deze bevat C-functies om het model te starten, er één stap in uit te voeren en het vervolgens weer te sluiten. Ook biedt de bibliotheek voorzieningen om data via de Java Native Interface (JNI) in te lezen uit en uit te voeren naar een Java-toepassing, een interface die toegang geeft tot andere parameters en gegevens en functies die arrays omzetten van Java naar C en vice versa, aangezien deze anders van structuur zijn. Om compilatie voor Android met de NDK mogelijk te maken, hebben we tevens de standaard makefile bijgewerkt.
Nabewerking
Hoewel we de meeste problemen met het besturingssysteem er al uit hadden gehaald in de simulatie, stuitten we bij aanvang van de praktijkproeven toch nog op een paar onvolkomenheden met het display en de verwerking van de snelheidsprofielen die we binnenkregen van de RSU. Om deze op te lossen, moesten we ons Simulink-model ter plaatse aanpassen en het systeem vervolgens opnieuw implementeren. Hier bleek de mogelijkheid om met één klik code te genereren en een bijgewerkte Android-app te maken van grote waarde. Dit stelde ons in staat om snel de noodzakelijke wijzigingen door te voeren en de praktijktest te hervatten binnen de beperkte tijd dat we toegang hadden tot de snelweg.
Na de praktijkproeven hebben we Matlab gebruikt voor nabewerking van de gegevens die we tijdens de tests hadden verzameld, zoals de gemeten snelheid van de auto‘s en hun onderlinge afstand. De voertuigpositie hebben we uitgezet tegen de tijd (Figuur 1). De resulterende grafieken bevestigen wat de proeven hadden aangetoond: het geteste systeem dempt op effectieve wijze de schokgolf en zorgt voor soepel doorstromend verkeer.
