Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 91 reacties

Het onderzoek dat busmaatschappij Connexxion heeft ingesteld na de botsing van twee onbemande ParkShuttle-bussen vorige week in Rotterdam, heeft aangetoond dat een handelingsfout in combinatie met een ongelukkige samenloop van omstandigheden de oorzaak van het ongeluk was. Het incident begon met een communicatieprobleem tussen een van de bussen en de centrale computer. Daarom stopte de bus totdat er weer contact mogelijk was. Het voertuig blokkeerde toen de brug, zodat twee andere bussen er ook niet langs konden en aan weerszijden van de brug bleven wachten.

Connexxion logoHet voertuig met de storing werd toen naar de eerstvolgende halte gestuurd om de brug weer vrij te maken. Hierna werd het baanvak echter per ongeluk tweemaal vrijgegegeven, waardoor beide ParkShuttles tegelijk de brug op reden. Het obstakeldetectiesysteem probeerde de voertuigen nog te stoppen, maar de remweg van de bus was te lang. Het systeem is namelijk bedoeld voor stilstaande voorwerpen, terwijl hier twee bussen elkaar tegemoet reden, zodat het toch tot een botsing kwam. De kreukelzones vingen de klap op en het passagierscompartiment bleef intact.

Connexxion zal in samenwerking met 2getthere, fabrikant van de ParkShuttles, maatregelen nemen om een herhaling van het ongeluk te voorkomen. De dekking van het communicatienetwerk zal worden verbeterd, de software zal worden aangepast, evenals de procedures die het bedienend personeel moet volgen. De aanpassingen zullen naar verwachting nog voor het eind van dit jaar gereed zijn. Daarna volgt een testfase met de overgebleven vier onbeschadigde bussen. Wanneer de twee bij het ongeluk betrokken voertuigen weer gerepareerd zullen zijn is nog niet bekend. Connexxion kan dan ook nog niet zeggen wanneer het systeem weer volledig in gebruik zal worden genomen.

Parkshuttle botsing
Moderatie-faq Wijzig weergave

Reacties (91)

ik vind dat eigenlijk best verontrustend:
Het systeem is namelijk bedoeld voor stilstaande voorwerpen, terwijl hier twee bussen elkaar tegemoet reden, zodat het toch tot een botsing kwam
Heb je wel gelijk in, staat waarschijnlijkop de TODO lijst van 1.1 ;)
en dan te bedenken dat dit eigelijk 2.0 al was :+
Deze situatie had nooit voor mogen komen: doordat een mens het baanvak twee keer vrij gaf (een keer voor elke bus die voor de brug stond te wachten) is het ongeluk gebeurd. Met de software en hardware is dus niks mis.

Sterker nog: het laat zien dat de software zelfs in situaties buiten het kenveld nog de schade weet te beperken: door te remmen werd de gecombineerde snelheid dusdanig verlaagd dat de passieve veiligheids systemen (de kreukelzones) niet overvraagd werden.
Als er passagiers aan boord waren geweest was de kans groot dat dezen hoogstens met kleine verwondingen de bus hadden kunnen verlaten, terwijl een persoon het systeem buiten de operationele parameters had gebracht!
Als je twee bussen tegen elkaar aan kan laten rijden door welke handeling dan ook dan lijkt me dat toch een systeem fout die in de software opgelost moet worden.
Nou nee, ligt er volgens mij maar net aan wat de opzet is geweest. Als van meet af aan bedoelt is dat een persoon de baanvakken vrij geeft na problemen en de rest van het systeem daarop ontwikkeld is dan is het geen systeemfout, maar een menselijke fout. Valt alleen nog een compliment aan de software te maken dat het ook ingreep buiten haar specificaties.
dan lijkt me dat toch een systeem fout die in de software opgelost moet worden.
van het remote bedieningspaneel ja : \
En waarom geeft die operator twee keer vrij? Omdat er niets begon te bewegen. En waarom begon er niets te bewegen?
Omdat beide bussen elkaar zien staan, op gelijke afstand van de brug, dus met dezelfde prioriteit. Deadlock!
waar haalt iedereen dat deadlock toch vandaan?
Er wordt nergens aangegeven dat dit het geval was..

De bussen stonden stil op gelijke afstand van de brug (als dat al zo was.. ze zouden dan dus precies op het midden van de brug botsen).

Mogelijk is het centrale systeem wel zo ontwikkeld dat het op zo'n moment 1 bus vrijgeeft en de andere laat staan.. Dan krijg je dus ook geen deadlock
Inderdaad. Je zou toch verwachten dat zo een systeem alle mogelijke variabelen in ogenschouw neemt. Dus stilstaande, achteroprijdend en tegemoetkomend verkeer.

Ik zal niet snel instappen....
heb er een keer ingezeten is best grappig....
Het is van de gekke ALS ze geen rekening zouden houden met bewegende obstakels.
Dit lijkt me een gevolg van een verouderd concept: een systeem met baanvakken.
In Mumbay (Bombay, India) werken ze met GPS in elke trein. Alle treinen broadcasten voortdurend hun positie en snelheid. Als een trein een voertuig te dicht nadert stopt hij automatisch. Daardoor kunnen de treinen met tussenruimte van 3 4 minuten rijden, wat onmogelijk veilig is te doen met baanvakken.
Je moet rondkijken in de wereld, niet telkens het wiel opnieuw willen uitvinden.
je vergeet alleen 1 ding......op een treinspoor rijden alleen treinen....wat nou als er hier niet alleen deze voertuigen rijden maar ook andere voertuigen die geen GSM signaal uitsturen? Dan is jouw oplossing opeens totaal nutteloos.

Dat hele GPS gebeuren wordt overigens hard aan gewerkt....zoiets implementeer je alleen niet in 2 dagen ofzo. De treinen zelf moeten aangepast worden en ook heel de treininfrastructuur door het hele land (denk dat je het met me eens bent dat 2 verschillende botsbeveiligingen een beetje link is).
Op zo'n moment zou je toch willen dat er een mens achter de knuppel zat die zelf dingen kan beslissen. De software werkt altijd perfect, maar als het niet weet wat het moet doen houdt het gewoon op.

@webfreakz.nl, als je het artikel had gelezen kon je zien dat het wagentje dat wel zag, maar omdat de remweg te kort was ging het toch fout.
Hierna werd het baanvak echter per ongeluk tweemaal vrijgegegeven, waardoor beide ParkShuttles tegelijk de brug op reden.
Blijkbaar zat er een knuppel in de centrale die de baan twee keer heeft vrijgegeven. Of was het een fout in de software? dat wordt niet echt duifelijk verteld.
Hierna werd het baanvak echter per ongeluk tweemaal vrijgegegeven, waardoor beide ParkShuttles tegelijk de brug op reden.

Blijkbaar zat er een knuppel in de centrale die de baan twee keer heeft vrijgegeven. Of was het een fout in de software? dat wordt niet echt duifelijk verteld.
Het is juist heel logisch om beide banen weer vrij te geven. Het is de bedoeling dat alle bussen weer gaan rijden.

De software had moeten weten dat er aan beide kanten een bus stond en ze na elkaar laten vertrekken.
Ik dacht ook eerst aan een eventuele programmeerfout maar waarschijnlijk is het als volgt gegaan. De operator heeft na het verplaatsen van de defecte shuttle het baanvak vrij gegeven. Toen heeft het systeem 1 van de twee wachtende shuttles de brug opgestuurd. De operator zag dat de andere wachtende shuttle ook nog stil stond en heeft het baanvak toen nogmaals vrijgegeven.

Op zich zou het verplaatsen van de defecte shuttle het baanvak al vrij moeten geven en had er dus geen handmatige vrijgave nodig hoeven zijn.
Maar men had ook het systeem zo kunnen maken dat een operator nooit een baanvak kan vrij geven terwijl er een shuttle op rijdt die geen storing meldt. Dat zou bijvoorbeeld alleen mogelijk moeten zijn als er fysiek iemand bij de shuttle aanwezig is en bijvoorbeeld een sleutel of pasje in de shuttle plaatst. Die persoon garandeert dan het systeem middels de sleutel/pas dat een overrule mogelijk en veilig is.
Maar men had ook het systeem zo kunnen maken dat een operator nooit een baanvak kan vrij geven terwijl er een shuttle op rijdt die geen storing meldt.
Het hele punt van het handmatig vrijgeven van een baanvak zal waarschijnlijk te maken hebben met mogelijke fouten in het computersysteem. Als het computer systeem een baanvak wat vrij is niet meer vrijgeeft is het handig dat een operator dit handmatig kan doen. Zeker in testfases (maar ook daarna) wil je de mogelijkheid hebben fouten in het systeem te corrigeren.

Wat trouwens ook gebeurd kan zijn is dat het systeem nadat de 3e shuttle van de weg gehaald was (te) traag was met het vrijgeven waarna de Operator besloot handmatig de baan vrij te geven. Daarna gaf het automatische systeem dan alsnog de baan vrij met alle gevolgen van dien.
Fout gedacht, m.i.
De operator geeft de baan vrij, maar de shuttle gaat niet rijden, want er staat er nog een aan de andere kant: deadlock!
@denkster

nee, dat zal niet zo zijn aangezien het systeem overal een heen en een terugweg heeft (2 banen dus) behalve op de brug. alleen de brug is maar 1 baan. als er dus een bus staat te wachten aan kant A kan de bus die vanaf kant B komt gewoon de bus aan kant A passeren zonder dat ze elkaar gaan zoenen.
Twee bussen, aan weerszijde van de brug een, mogen tegelijk gaan rijden. Wie begint? Deadlock!
Allereerst is het aardig te zien dat er inderdaad een deadlock was, zoals ik bij het vorige artikel veronderstelde.
Overal dezelfde software betekent altijd dat je extra software nodig hebt om deadlocks op te lossen.
Verder: een systeem met baanvakken is natuurlijk idioot en hopeloos verouderd. In Mumbay (Bombay, India) werken ze met GPS in elke trein. Alle treinen broadcasten voortdurend hun positie en snelheid. Als een trein een voertuig te dicht nadert stopt hij automatisch. Daardoor kunnen de treinen met tussenruimte van 3 4 minuten rijden, wat onmogelijk veilig is te doen met baanvakken.
Je moet rondkijken in de wereld, niet telkens het wiel opnieuw willen uitvinden.
Blijkbaar zat er een knuppel in de centrale die de baan twee keer heeft vrijgegeven.
De baan werd vrijgegeven, of je nu 1, 2, 3 of 100 keer de baan vrijgeeft zou niet uit mogen maken, een vrije baan is een vrije baan.
Nee, denk ik niet. Ik denk dit:

====----====
(weg - brug - weg)
De kapotte bus stond op de brug stil. Aan weerszijden stond een bus te wachten. Ze hebben die kapotte 'handmatig' weggestuurd/weggereden, maar die kon dus dat stuk baanvak niet vrij-melden bij de centrale computer.
Dus wachtten die 2 bussen nog steeds voor een lege brug. Dus deed de operator ' OVERRIDE VRIJ' op de brug, op z'n schermpje werd de brug dus even 'groen'=vrij, en meteen besloot 1 van de 2 bussen dan maar weer te gaan rijden, so far so good. Hij meldde dus METEEN de brug weer 'bezet', omdat hij erop zou gaan. Dus de andere bus moest nog gewoon wachten. Echter de operator die de brug op GROEN zetten, zag meteen de brug weer 'rood worden' (=bezet) na zijn Klik, en dacht, ik heb het niet goed gedaan! Dus heeftie nog eens 'override free' gedaan en op dat moment besloot de 2e bus dat hij dan wel kon gaan.
Fout 1: De operator was fout (domdomdom)
Fout 2: De software die 'override' toekent moet eigenlijk aan de 'last known' 'eigenaar' van dat stuk weg vragen of het wel echt vrij is. In geval van die stukke bus had hij geen antwoord gekregen en dus had de operator kunnen aangeven: dat klopt, weten we, echt, het vak is leeg.
In het TWEEDE geval had de software het aan die bus gevraagd die net weer was gaan rijden, en die bus had gezegd, nee, flikker op, ik ben hier echt en ik ben ook nog op snelheid, dus handjes thuis. Dat had aan de operator gepresenteerd kunnen worden. Die had dan ongetwijfeld WEL nagedacht en vervolgens niet de 'override' doorgezet.
Maar ja, connexion heeft _mij_ niks gevraagd :D
wat dacht je van een race conditie?

busje een rijdt op het baantje, zegt: hoi ik rijd hier. baanvak wordt vrij gegeven omdat er een stilstaand busje stond
busje twee een stilstaand busje wordt naar de halte gestuurd en rijdt niets vermoedend naar de halte terwijl busje een op het zojuist vrijgeven stukje aan komt tuffen.

De fout is dus race conditie, dat het obstakel detectie systeem niet beter werkt en niet minimaal twee keer zijn remweg kan afzoeken is een veiligheids probleem.
De fout is hier, zoals praktisch altijd, menselijk. De software wist prima wat te doen, maar iemand heeft tegen beide bussen gezegt: Jullie mogen gaan rijden.

Overigens ben ik het wel eens rooicity, die sensoren moeten toch ook bewegende voorwerpen op tijd kunnen detecteren. Sowieso zou je denken dat het centrale systeem de positie van de busjes weet, en deze zou moeten kunnen aanpassen als het de verkeerde kant op lijkt te gaan...
De fout is hier, zoals praktisch altijd, menselijk. De software wist prima wat te doen, maar iemand heeft tegen beide bussen gezegt: Jullie mogen gaan rijden.
die 'iemand' was hier het centrale computersysteem. Die software gaf per ongeluk het baanvak vrij aan beide bussen, met als gevolg een crash. Eigelijk best komisch, maar uitsluitend omdat er niemand in de bussen zat.
Op zo'n moment zou je toch willen dat er een mens achter de knuppel zat die zelf dingen kan beslissen. De software werkt altijd perfect, maar als het niet weet wat het moet doen houdt het gewoon op.
Maar de mens maakt weer fouten op momenten dat een computer dat nooit zou doen, dus ja... Pech is natuurlijk dat dit het vertrouwen in dit soort systemen direct een enorme deuk geeft, en om dat vertrouwen terug te kunnen winnen moet het systeem echt wel enkele jaren ongeluk-vrij functioneren.
De software werkt altijd perfect
Software werkt altijd perfect? Dude...?
Het is echt niet de fout van de software. Het is altijd de fout van de ontwikkelaar, die in dit geval vergeten is dat voorwerpen op de straat ook kunnen bewegen.
>Het is altijd de fout van de ontwikkelaar, die in dit geval vergeten is dat voorwerpen
Om nou de schuld bij de ontwikkelaar te leggen. Even goed kan connexxion expliciet gevraagd hebben om een systeem dat alleen stilstaande obstakels kan ontwijken.

Hoewel ik in dit geval wel vreemd vind dat het detectie systeem niet kan omgaan met bewegende voertuigen, dat lijkt me als buitenstaande nou niet echte een gekke eis. Voor als er eens 1 "op hol" slaat of zo.
What about een ingebouwde self-destruct functie, in geval van nood :)
Ja, uiteindelijk is iets natuurlijk altijd de fout van de ontwikkelaar, en nooit van de software zelf: Die heeft geen wil ofzo, maar doet alleen wat hem is opgedragen door de softwareontwikkelaar (samen met de compiler). Inclusief eventuele fouten daarin.
Nee die gaat er naar toe rennen. Tuurlijk.
als dat voortaan de enige manier wordt om zelfmoord te plegen...
Ook handig als er een kind de straat over komt rennen.
Denk maar niet dat dat kind denkt 'he als ik stil ga staan dan stop die bus vast wel'.
software doet precies wat de mens verteld hem te doen. hij zal zelf geen andere dingen gaan doen. vandaar dat software perfect werkt. of de mens het perfect maakt is iets anders
dat doen kinderen ook... denken veel ouders tenminste. Die hebben dezelfde naieve instelling als jij en dar kom je vanzelf achter vrees ik ;)
(+/-) 90% van de ongelukken op de weg vinden plaats door toedoen van autobestuurders (bron: Gevaar op de weg, vorige aflevering), zodra dit systeem getest is en het goed geimplementeerd kan worden tot een 100% dekking op bijvoorbeeld snelwegen dan neem ik aan dat het aantal ongelukken enorm zullen afnemen.

Daarnaast hoop ik dat het dan ook mogelijk zal zijn vanwege de voorberekeningen van het computernet, dat men sneller gaat rijden (150km of hoger) dus dat men sneller er is. Of door efficiente koersbepalingen men met een langzamere snelheid toch eerder op locatie is. Dit zou best de toekomst kunnen hebben (denk aan film waar :r Tom :r Cruise :r in speelde.
Die film heette 'Minority Report' denk ik? En reken maar niet dat deze busjes binnen de komende 50 jaar op snelwegen worden losgelaten :P. Ze zijn bedoeld voor simpel, relatief traag vervoer (denk aan +/- 30km per uur)
Statistieken zijn erg mooi, wat de statistieken niet vertellen:
Hoeveel ongelukken zijn er voorkomen door menselijk ingrijpen?
offtopic: Gevaar op de weg is toch gesponserd door Koos Spee/ openbaar-ministerie? Riekt naar overheids propaganda zoals dat in dictaturen gebruikelijk is.

Bij de meest eenvoudige conflict situatie rijden twee bussen al op elkaar in. ;( Iets waar elke simpele ziel kan bedenken dat je moet testen, wat gebeurd er als we er twee recht op elkaar af laten rijden?
Dat werkt dus al niet, daarmee is ook zeker dat kleinere objecten(voetgangers, fietsers enz) hun leven niet meer zeker zijn, immers als er zo kreng aan komt moeten ze onmiddelijk stil gaan staan.

Het argument dat het systeem alleen uit gaat van stilstaande objecten is helemaal volslagen belachelijk. wat gaat dat ding doen bij een wegopbreking waarbij zo bus even op de andere rijstrook moet en dus geen rekening kan houden met tegemoet komende auto' s |:(

Computers kunnen functioneren maar in 1 situatie goed: Voorspelbare situaties. Zodra er ook maar iets onverwachts gebeurd is maar 1 ding veilig, dat zo' n ding zich zover mogelijk meteen uitschakeld en alles wat door die computer bestuurd wordt meteen tot stilstand gebracht wordt. Maar ja, zelfs dat blijkt in praktijk niet eens altijd te werken :+
Ik ben 7 jaar geleden ooit proefpersoon geweest van de Parkshuttle. Ook toen was het verhaal dat ie automatisch zou stoppen bij een obstakel, maar dat werkte destijds ook al niet. :)

Ik zat namelijk een keer in het busje en 20 meter verder stond de 'baanbeheerder' in z'n golfkarretje op de weg. Hij kon niet verder want er stak verderop een vrachtwagen over. Je voelt 'm al aankomen. Het busje waarin ik zat ging rijden, stopte niet en crashte met volle vaart tegen de golfkar met beheerder. :D
Gelukkig zag ik het aankomen en hield ik me dus goed vast. }>

Je zou toch denken dat 7 jaar later de kinderziektes er wel uit zijn gehaald.....
Dat laat alleen maar zien hoe ontzettend moeilijk het is om zoiets goed te maken.

De clue is echter dat wanneer iemand het voor elkaar heeft gekregen het ook niet meer mis kan gaan.

Ter vergelijking, een mens kan een rijbewijs halen, maar das geen garantie dat ie geen klappen maakt. Een stuk software kan ook fouten maken, maar wanneer een fout is opgelost komt deze als het goed is niet meer terug.

Daarnaast moet het natuurlijk ook allemaal niet te duur worden. Als een stuk software minder fouten maakt als de gemiddelde chauffeur gaan ze er echt geen geld in stoppen om em nog beter te maken.

Het is al duur genoeg om zoiets te ontwikkelen en het plan was juist geld te besparen op de chauffeur.
Jep.. En een computer maakt geen fouten.. Nee inderdaad nooit! .. Er zijn zoveel dingen die fout konden gaan.. Computer zijn niet perfect, software is niet perfect, compilers zijn niet perfect..

De pentium pro bug, ooit van gehoord? Ga maar eens kijken wat een rare dingen er allemaal kunnen gebeuren in hardware
Mensen leren makkelijker van hun (bijna-)fouten dan computers.
Maar de remweg is alleen lang genoeg voor stilstaande voorwerpen, zoals het artikel vermeldt.
ze reden op elkaar af... welke achterste?
Het obstakeldetectiesysteem probeerde de voertuigen nog te stoppen, maar de remweg was te lang. Het systeem is namelijk bedoeld voor stilstaande voorwerpen, terwijl hier twee bussen elkaar tegemoet reden, zodat het toch tot een botsing kwam.
Idd. ;)
[edit]
te laat
Dat gebeurde dus ook, echter zoals in het artikel staat vermeld is dit bedoeld voor stilstaande objecten. Beide wagentjes maakten waarschijnlijk een noodstop voor een stilstaand opject maar doordat ze allebei nog een aantal meters ofzo reden botsten ze op elkaar.

Zeg de remweg is 7 meter, systeem detecteerd op 10 meter objecten, als het ene voorwerp niet beweegt staat het ruimschoots op tijd stil, maar omdat dat andere voertuig dichterbij kwam waren die 3 meter marge niet genoeg.

(getallen uit duim gezogen, is slechts een voorbeeld)

//te laat
Volgens mij heeft de centrale software het baanvak 2 keer vrijgegeven. Dit is gewoon een uitzonderlijke situatie waarbij 1 bus het vak blokkeerd en er 2 bussen staan te wachten om het vak te betreden. Misschien is het ook wel het enige vak in het traject dat maar 1 richtingsverkeer is waardoor de situatie nog exotischer is.

Dit is geen fout van de programmeur, maar een fout van te testers. 8-)
het is inderdaad et enige vak in het traject dat maar 1 baan vak heeft die voor heen en terug bedoelt is. de rest van de route hoeft het systeem geen rekening te houden met tegenliggers
Dat het niet de schuld is van de software doet er niet toe, een mens had wel op de rem getrapt.

De software is klaarblijkelijk nog in de Beta fase, en hoort dus niet op de weg..
Blijkbaar nog nooit van je leven in een druk gebouw tegen iemand anders opgelopen. Ook de mens reageert wel eens te laat.....
de enige echte 'fout' die hier echt een grote rol heeft gespilt is de rijkwijdte van de optische opstakel beveileging. ik vind 't ronduit bizar dat die niet 2keer zijn eigen remweg vooruit kan kn kijken.
Tja en als hij nou eens in staat is om 5 keer zijn eigen remweg vooruit te kijken maar de programmeur er niets mee doet ??

While te ver weg do gas erop
if object is too close break and pray to god :-)

Maar zonder gekheid er zijn mij ook wel enkele zaken door het hoofd geschoten zoals bv nabijheid detectie van eenzelfde bus , maar dan moet het wel erg secuur zijn , want wat gebeurt er als ze elkaar moeten passeren op een baan die daarvoor geschikt is.
Liever zie ik een obstakelmeting die naar verhouding de afstand tot het object met een korte interval gecheckt wordt , dus bv na 25 meter, 20, 17,15 etc , dan is een beter snelheidsverloop en actie/reactie schema in te regelen.

<phun intended>
Tjaaa het is gewoon een soort van bughunting, alleen wil ik niet graag in zo'n bus zitten als iemand er een netbus op loslaat :-)

</phun intended> :+
Het kan natuurlijk ook niet zo zijn dat de verbinding 'even eruit ligt'. Zoiets is met een website geoorloofd, maar in het verkeer is het levensgevaarlijk.

Als ze niet kunnen garranderen dat de verbinding 99,999% online blijft, moeten ze zorgen dat de bussen slim genoeg zijn om zelf een stukje te rijden.
de bus kan zichzelf ook besturen, maar zet zich uit veiligheids overwegingen still als hij even geen verbinding heeft.

dat heeft prima gewerkt, het was alleen de aanleiding voor het ongeluk dat volgde.
Dat 2 bussen op elkaar knallen is opzich al vrij eng..

Maar wat ik nog veel enger vind is het feit dat zo'n bus stilvalt als deze de verbinding met de centrale computer verliest.... Het zal je maar gebeuren dat je op een spoorweg overgang, of op een brug die op het punt staat open te gaan stil komt te staan....

Eigenlijk zou zo'n bus uitgerust moeten zijn met een systeem om dan op eigen houtje naar een dichtstbijzijnde plek te gaan die gemarkeerd staat als veilig...

-R-
@rune
Met als nadeel dat je allemaal zombie bussen krijgt zodra er storing is in de centrale.
@jqv: Nogal logisch dat sensoren moeten helpen, hoe kan het OS anders ooit weten of er een obstakel is. Een sensor is er om iets te detecteren, programmatuur om daar vervolgens een logische reactie aan te geven.

Wel flauw om 't weer met Windows te vergelijken...
Arme busjes :'(, ik heb ook met ze te doen hoor.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True