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 , , 93 reacties
Submitter: JS1982

Intel gaat samenwerken met Mobileye en Delphi om een systeem voor autonoom rijdende voertuigen te ontwikkelen. Voor dit systeem levert de chipfabrikant in eerste instantie een Core i7, maar later zal een krachtigere, nog onbekende processor ingebouwd worden.

Mobileye levert de sensornetwerken en Delphi zorgt voor de radarsystemen. Intels taak bij het samenwerkingsverband is om de processor voor het systeem te verzorgen. Intel zou over enkele weken een nieuwe processor voor autonoom rijdende voertuigen willen onthullen, schrijft The New York Times. Mogelijk zal dat tijdens de CES in Las Vegas plaatsvinden, begin januari.

Bij de eerste versies van het systeem gebruiken de drie bedrijven nog een niet nader aangeduide Core i7. Volgens de vice-president engineering & services bij Delphi is er veel rekenkracht nodig om de dataverweking bij autonoom rijdende voertuigen af te handelen. Hoewel dus een high-end processor nodig is, richten de drie bedrijven zich op het ontwikkelen van een systeem voor relatief goedkope auto's en vrachtwagens. Over twee jaar moet dit gereed zijn.

Intel concurreert onder andere met Nvidia, Qualcomm en het Nederlandse NXP bij het ontwikkelen van systemen voor zelfrijdende voertuigen. De Amerikaanse chipgigant heeft een speciale divisie opgezet voor dit soort systemen: de Automated Driving Group.

Moderatie-faq Wijzig weergave

Reacties (93)

Ik snap niet dat hier geen Xeons voor ingezet worden, is ECC dan echt niet van belang in dit soort situaties?
Voor dergelijke toepassing prefereer ik toch liever een RISC architectuur.
Een voorkeur voor architectuur/instructieset zou relevant zijn als je ervoor programmeert. Ik vermoed dat je stabiliteit impliceert en dat heeft niks met de architectuur te maken. Wel met de software natuurlijk. Het helpt als software maar op één hardwareplatform hoeft te draaien.

Voor de i7 zet ik eerder mijn vraagtekens bij de TDP, want die is bij een i7 vrij hoog. En in een auto moet je rekening houden met forse temperaturen, bijvoorbeeld als je in Zuid-Europa of Azië in de brandende zon geparkeerd staat. Met een kapotte airco.
Ik snap niet dat hier geen Xeons voor ingezet worden, is ECC dan echt niet van belang in dit soort situaties?
Ik denk dat desktopgeheugen per definitie gaat falen in een auto, met of zonder ECC. Auto elektronica moet tegenwoordig meer dan 20 jaar levensduur hebben en daarvoor zijn automotive grade tests opgesteld, voor IC's AECQ-100. Ik garandeer je dat geen enkele RAM module (of i7) die test doorstaat, want daar zijn ze simpelweg niet voor ontworpen.

Voor prototype en testen kun je in principe rustig een i7 toepassen, maar dit zal nooit met degelijke IT componenten op de markt komen. Intel zal hiervoor een nieuwe CPU moeten ontwikkelen, maar ik zie geen reden waarom die geen x86-64 architectuur zou mogen hebben. ECC is dan waarschijnlijk geen slecht idee, maar een ingebakken Intel GPU waarschijnlijk ook niet. En dat heeft een Xeon niet.

Waar ik oprecht benieuwd naar ben is in hoeverre een 13nm IC (wat Intel nu toepast) zo'n automotive test kan doorstaan. Het kan haast niet anders dan dat daar uitdagingen in zitten.

[Reactie gewijzigd door Flake op 2 december 2016 19:19]

Autonoom rijden is typisch ASIL D (het hoogste niveau) dus Ja, daar moet je alle beschikbare maatregelen nemen. Zonder ECC kan dit niet de straat op.
" alle beschikbare maatregelen" is een beetje loos, want de gemiddelde embedded hardware in auto's en daarbuiten gebruikt ook geen ECC bijvoorbeeld. Dat in PC-land ooit ECC RAM is ontstaan door de onbetrouwbaarheid van regulier SDRAM betekent nog niet dat iets zonder ECC heden ten dage per definitie onbetrouwbaar is.
In het infotainment gebruikt men de auto geen ECC. Maar als het veiligheidsrelevant is dan zeker wel. ECC is in embedded ook bepaald niet zo exotisch als in de PC wereld. Het gaat er ook niet om dat het zonder ECC onbetrouwbaar zou zijn, het gaat er om dat het niet zo betrouwbaar is als het zou kunnen zijn.
"alle beschikbare maatregelen" en "zo betrouwbaar is als het zou kunnen zijn" is geen spec. Het best mogelijke kan nooit gebouwd worden. In plaats van één ECC bit zou je immers ook twee kunnen hebben, of beter drie, of beter vier, of....

ASIL-D vereist een FIT rate van <10FIT, dat is maximaal één fout per 10^8 uur. Hoe je dat bereikt is niet voorgeschreven (ook al is het ontwikkelprocess en documentatie wel voorgeschreven)
Embedded != multimedia hè. De ECU van je motor bijvoorbeeld is in de latere generaties ook gewoon een microcontroller zonder ECC.

"het gaat er om dat het niet zo betrouwbaar is als het zou kunnen zijn"

Dat hangt er vanaf of er een winst in ECC te behalen valt. Als een geheugenfout kan leiden tot verkeerde keuzes of uitval dan heb je een punt. Als het systeem echter zelf ervoor zorgt dat het (bijvoorbeeld door redundantie of parallel processing) tegen die geheugenfouten kan dan heeft ECC geen meerwaarde.

Net als met twee chauffeurs rijden ook betrouwbaarder is dan met 1 maar ook niet praktisch gedaan wordt. Of met dubbellucht op normale auto's. Of een met kevlar verstevigde brandstoftank. Het kan altijd betrouwbaarder, dat is een zinloze eis.

[Reactie gewijzigd door Lekkere Kwal op 2 december 2016 14:17]

Zelfs het cache geheugen op de CPU zelf maakt gebruik van ECC. Dat lijkt mij niet zonder reden te zijn gedaan...
Ik bestrijd ook niet het nut van ECC... Ik geef alleen aan dat het geen voorwaarde hoeft te zijn in een automotive toepassing.
Niet noodzakelijk. Je werkt met realtime data en gaat dus ook steeds werken met een gemiddelde van meetpunten en verwachtingspatronen. 1 meetpunt dat afwijkt door een foutieve bot in het geheugen kan je dus perfect als ongeldig bestempelen. Een beslissing mag daar echt niet van afhangen, net zoals een beslissing ook niet van 1 sensor afhankelijk mag zijn
Wat ik me ook nog afvraag, hebben systemen zoals deze geen backup systeem nodig, voor het geval het hoofdsysteem het begeeft (bijvoorbeeld door een defect CPU), zodat het daar op over kan schakelen? Je wilt bij een compleet autonome auto niet dat ie bij 130 op de snelweg ineens ophoud met autonoom zijn doordat er een onderdeel defect is..
Wat ik me ook nog afvraag, hebben systemen zoals deze geen backup systeem nodig, voor het geval het hoofdsysteem het begeeft (bijvoorbeeld door een defect CPU), zodat het daar op over kan schakelen? Je wilt bij een compleet autonome auto niet dat ie bij 130 op de snelweg ineens ophoud met autonoom zijn doordat er een onderdeel defect is..
Dan vraagt ie je gewoon om de controle over te nemen, is dus niet echt een probleem.
Voor vrijwel geen enkel systeem is er in de auto een backup systeem, niet voor remmen (moderne auto's met moderne handremmen kunnen niet ingeschakeld worden tijdens het rijden), sturen etc etc.
Bij de stuurbekrachtiging worden vaker 4 sensoren gebruikt om de kracht te meten en fouten vast te stellen. Mocht de motor kapot zijn kun je nog met de hand sturen, maar er wordt ook aan redundante motoren gewerkt.

Aan remmen werk ik niet, maar ik kan me niet voorstellen dat daar single points of failure zijn.
De remleidingen zijn kruiselings aangelegd zodat mocht er een lek gaan je nog altijd 2 remmen over hebt.
Uiteraard gaat dan direct remstorings-lampje aan.

Kruiselings als links-voren & rechts-achter + rechts-voren & links-achter.

[Reactie gewijzigd door hackerhater op 2 december 2016 14:21]

Dit is echter wel wettelijk verplicht, om een noodremsysteem in een auto te plaatsen (waar dus meestal de parkeerrem voor bestemd wordt ...
Dan vraagt ie je gewoon om de controle over te nemen,
...en dan is ie dus niet autonoom.

Een autonome auto moet zélf de héle weg kunnen afleggen. Want als hij dat niet kan, dan kan ik net zo goed zelf rijden.

Ik persoonlijk vind auto rijden helemaal niet vervelend. Wel vervelend: niet kunnen drinken op een feestje. Maar als ik zat op de achterbank lig te pitten dan kan ik niet ineens het stuur overnemen.

Jullie definitie van autonoom rijden houdt in dat ik niet mag drinken op het feestje en dan met mijn handen aan of vlak bij het stuur in de auto moet zitten, de auto pilot controlerend. Sorry maar dan rijd ik liever gewoon zelf. Mijn definitie van autonoom betekent gewoon dat ik überhaupt niet in de auto hoef te zitten en bijvoorbeeld de auto zelfstandig kan laten parkeren of een pakje ophalen e.d.

Oftewel een échte autonome auto mag niet bij 130 ineens ermee stoppen. Die moet die rit af kunnen maken, of in ieder geval de auto veilig aan de kant van de weg kunnen zetten.
Die backup bestaat al. In sommige landen noemen ze die "chauffeur"
Als je het over echt autonoom rijden hebt dan kan de chauffeur niet altijd binnen een paar seconde het stuur en de pedalen over nemen, terwijl dat in het verkeer wel noodzakelijk kan zijn.
Wat is dan het nut van autonoom rijden, als je wel alert moet zijn, maar niks zelf mag doen. Nee autonoom rijden, daar moet je 100% blind op kunnen vertrouwen, want de marge van op tijd ingrijpen wordt te klein, zelfs al geeft hij 2 sec te voren "ik kan niks, kies jij nu maar geluid gaat geven"
Daar zijn safety standaarden voor, echter voor autonoom rijden is nog geen standaard:

https://en.wikipedia.org/...ve_Safety_Integrity_Level
Nee, zo kan je dat niet stellen. Dit valt allemaal in de scope van ISO 26262/IEC 61508 functional safety standaarden. Er zijn veel maatregelen - waaronder redundancy, maar ook CRC checks, etc - die de hardware keten veilig genoeg kunnen maken.

[Reactie gewijzigd door MOmax op 3 december 2016 12:58]

Maar we hebben het over autonoom rijden, dat is dus ASIL D, het allerhoogste niveau. Daar heb je heel de poppenkast voor nodig. Inderdaad verplicht ISO 26262 geen concrete dingen als ECC maar de standaard zit veel slimmer in elkaar. Je moet de huidige stand van de techniek inzetten, de beschikbare middelen. In het geval van ASIL D dus alle middelen. Dan kun je eigenlijk niet om het bijzonder gangbare ECC heen. Een CRC op heel je RAM zetten is technisch niet te doen, daar heb je juist ECC voor (om de juistheid van de data in het RAM vast te stellen). Intel maakt hier met een i7 een concept maar zal voor productie echt wel over moeten op XEONs met ECC.

[Reactie gewijzigd door mashell op 3 december 2016 13:57]

Ik heb speciaal voor mashell wat tabellen uit de IEC61508-2 geknipt: https://snag.gy/tNWxBJ.jpg.

De standaard zegt in Annex A.2
Tables A.2 to A.14 support the requirements of Table A.1 by recommending techniques and measures for diagnostic tests and recommending maximum levels of diagnostic coverage that can be achieved using them. These tests may operate continuously or periodically. The tables do not replace any of the requirements of 7.4. Tables A.2 to A.14 are not exhaustive.
Kortom, deze standaarden schrijven ECC (EDC) niet dwingend voor.
Het zou geen kwaad kunnen, maar noodzakelijk lijkt het me zeker ook niet. Aardig artikeltje: https://blog.codinghorror.com/to-ecc-or-not-to-ecc/
Het zou geen kwaad kunnen, maar noodzakelijk lijkt het me zeker ook niet. Aardig artikeltje: https://blog.codinghorror.com/to-ecc-or-not-to-ecc/
Let op dat in dat artikel non-ECC alleen wordt gebruikt voor redundante systemen. Voor hun meest kritische systemen (databases) gebruiken ze wel ECC.

In een auto is minder ruimte voor redundantie dan in een server rack. Nu zeg ik niet dat systemen dubbel uitgevoerd moeten worden of dat er per se ECC gebruikt moet worden, maar de situaties zijn niet echt vergelijkbaar.
Let ook op dat soft errors (single-bit flips) ongemerkt kunnen blijven. Je PC crasht niet, maar je data is wel corrupt, zonder dat je het merkt.
Van http://www.intel.com/cont...processors/000006778.html

The Intel® Core™ i7 Desktop Processors typically do not support ECC memory ... Check with your desktop board manufacturer to see if ECC memory is enabled on your board.

Het kan dus gewoon.
Dat staat er dan wel erg creatief, want in de praktijk komt "typically do not support" neer op "do not support" : http://ark.intel.com/sear...Processors&ECCMemory=true
Zeker niet voor alle processoren maar ik heb thuis een HP Proliant servertje staan die geleverd werd met een standaard Pentium processor en ECC geheugen. Bij het zoeken naar een upgrade voor die processor kwam ik ook een i5 tegen die het ook ondersteunde.

Edit: ik kijk net pas naar de link en er is inderdaad geen i7 die het ondersteunt. Het staat Intel natuurlijk niets in de weg om dit wel te activeren op een toekomstige i7 voor deze specifieke toepassing.

[Reactie gewijzigd door oef! op 2 december 2016 15:08]

In principe is een i7 een Xeon E3. Ik denk eerder dat ze een i7-achtige chip met FPGA willen gebruiken.
Sterker nog, een i7 is gewoon een Xeon zonder ECC enabled. Misschien zit het enige verschil gewoon in de microcode. Productdifferentiatie...

AMD high-end consumer CPUs komen (AFAIK) altijd mét ECC. Waar de gemiddelde consument vervolgens gewoon non-ECC DIMMs aan koppelt, maar toch :)
Denk dat dit wel mee zal vallen omdat alles real time gebeurt. Lijkt me niet dat het RAM heel zwaar belast wordt.
Als je het artikel goed leest zie je dat er later een speciale chip wordt ontwikkeld. De i7 zal nu puur gebruikt worden om te testen...
Voor dergelijke toepassing prefereer ik toch liever een RISC architectuur.
Eigenlijk zijn X86 CPU's al lang RISC-CPU's. Zei het, net zoals ARM, met een CISC-interface. Dat doet echter weinig ter zake. Dit soort 'pipelines' en processen zie je denk ik sneller in DSPs verschijnen, zoals bij de Hololense (die met weinig power en een Atom constant door een 3D mesh van de wereld en de positie daarin moet bijhouden). Resultaat: snel, zuinig, 'fit for purpose' met enige programmeerbaarheid.
Eigenlijk zijn X86 CPU's al lang RISC-CPU's. Zei het, net zoals ARM, met een CISC-interface. Dat doet echter weinig ter zake. Dit soort 'pipelines' en processen zie je denk ik sneller in DSPs verschijnen, zoals bij de Hololense (die met weinig power en een Atom constant door een 3D mesh van de wereld en de positie daarin moet bijhouden). Resultaat: snel, zuinig, 'fit for purpose' met enige programmeerbaarheid.
De huidige x86 hebben sinds de Pentium Pro een RISC core. De RISC is veel sneller en zuiniger dan een CISC.
Het nadeel van de x86 dat het complexer is en meer energie kost om de CISC naar RISV instructies om te zetten. Vandaar dat Intel nooit op verbruik met ARM concurrerende Atom SOC heeft kunnen maken.

Qualcom, Nvidia, Apple en Samsung doen het zelfde met ARM een eigen RISC core gebruiken die vertaalde ARM instructies uitvoert. Doordat het RISC -RISC is zijn deze veel zuiniger van de CISC-RISC van Intel.
Voor dergelijke toepassing prefereer ik toch liever een RISC architectuur.
Mmmm maar daar denken alle mensen die aan de ontwikkelingen van dit soort dingen werken dus anders over.
Helaas kan de i7 het parallelisme niet aan wat hiervoor nodig is...
Misschien dat ze met hun phi accellerator dichterbij komen bij wat nvidia doet...
Of zoals Microsoft doet met haar Hololens? Die heeft ook 24 dsp's die allerlei taken afhandelen.
Het is toch veel efficiënter om taak specifieke hardware te maken? Al zit daar vast wel een kosten plaatje aan.
Inderdaad, naast de CPU zijn er speciale processoren om de specifieke taken zoals herkenning af te handelen. De i7 zal het niet snel druk hebben.
Waarschijnlijk is dat waarom ze een i7 nodig hebben ipv een low-power SOC.
Je bedoelt de CPU? Sommige i7's komen met een on-board GPU met aparte execution units.
Ze komen ook met een custom chip voor autonoom rijden. (Zelfde link als in het artikel)
http://mobile.nytimes.com...car-pittsburgh-intel-maps

En hier nog een interessant stuk over de samenwerking van Mobileye en Delphi. En hun toekomstige producten
http://www.theverge.com/2...car-pittsburgh-intel-maps
ik betwijdel of dit echt lekker gaat werken. als je ziet dat tesla titan X gebruikt in hun auto's voor de verwerking zie ik niet echt dat een "lullige" i7 dit kan verwerken.
Uhh, er zit een Titan-X in iedere Tesla met 'autopilot' ?
Natuurlijk niet - ook Tesla kan niet terug in de tijd. Ze gebruiken een Nvidia Drive PX 2.
niet exact, het heet "parker" en is gebaseerd op een (zwaar) gemodificeerde big pascal GPU waar ze de titans en 1080ti mee maken.

[Reactie gewijzigd door flippy.nl op 2 december 2016 14:53]

In de luchtvaart, waar autopilots al wat langer bestaan, wordt verkeer die op instrumenten kijken om botsingen te voorkomen (IFR) strikt gescheiden van verkeer wat uit de doppen moet kijken om een botsing te voorkomen (VFR). Dit verkeer mag nooit gemengd worden en beiden hebben dus elk een stuk luchtruim waarin de ander niet mag komen. Dit heeft een reden.

Waarom men denkt dat het mengen van autopilots en mensen op de openbare weg wél zal gaan werken (één dimensie minder en ook nog amateur-bestuurders) is mij een groot raadsel. Mijn voorspelling: Het. Gaat. Nooit. Werken. Men zal er vanaf zien. Pas als alle auto's zonder ook maar één uitzondering over autopilots beschikken is de tijd er rijp voor. Eerder niet. Het gaat grandioos mislukken en wie hier wel in gelooft is naar mijn idee bijzonder naïef.
IFR en VFR verkeer vliegt gewoon door elkaar heen. In drukke gebieden kan een VFR piloot Flight Following aanvragen zodat deze instructies kan krijgen om veilig door het luchtruim te vliegen alleen moet de piloot dan elke koers, snelheid of hoogte wijziging doorgeven. In sommige restricted airspaces hoef je niet voor wijziging van de hoogte toestemming te vragen, maar dien je dit alleen te melden vergelijkbaar met hoe men normaal over de unicom (122.7) vliegbewegingen doorgeeft.

Daarnaast vliegt VFR over het algemeen lager dan IFR verkeer, maar dat is geen geschreven regel. De meeste piloten welke onder VFR vliegen willen juist genieten van het uitzicht en zullen over het algemeen net boven de 3000ft (in Nederland) blijven vliegen zodat ze in Class A airspace komen zodat ze geen communicatie met een toren van een vliegveld nodig is, maar contact hebben met center.

Zeker de helft van Nederland is ingericht als Class A en daarnaast zijn er ook nog een groot aantal gebieden als Class B ingericht. In Class B airspace mag men zowel onder IFR en VFR vliegen.

Er gelden wel enkele eisen voor VFR piloten welke in restricted airspace willen doorkruisen, namelijk dat ze een een twee-weg radio te hebben en een (actieve) transponder te hebben en daarnaast dient men nog voldoende zonlicht te hebben.

Wel houd men eastbound en westbound verkeer uit elkaar door ze op verschillende hoogtes te laten vliegen (vertical separation) zodat kans op frontale botsingen minimaal zijn..
Je gaat niet in op mijn stelling dat je niet zomaar twee verschillende soorten verkeer kunt mengen. Dat is jammer. Nu wordt het een kwestie van definities en wie de langste heeft. Misschien had ik beter over gecontroleerd en niet-gecontroleerd luchtruim kunnen spreken, maar we zitten hier op een ICT blog en m'n bedoeling was om het een beetje simpel te houden.

Want zodra er sprake is van ATC clearance, of anderzijds instructies worden uitgedeeld, dan is er dus sprake van separatie. En dat was mijn punt. Fijn dat je dat nog even bevestigd.

Maar je schrijft wel een paar dingen die ik als luchtruim-gebruiker wel wat zorgelijk vind;

Klasse A boven NL grondgebied op 3000ft? Ik denk dat dat voornamelijk klasse E is. Kun je een voorbeeld geven waar dat is? Het lijkt me dat je in de war bent met TMA's. En wat bedoel je met de helft van Nederland? We hebben het over 3-dimensionale omgekeerde bruidstaart-achtige vormen. Beetje vaag. Volgens mij is de bovenste laag geheel klasse A. En klasse A is natuurlijk strikt IFR only. Daar zitten echt geen recreatieve vliegers tussen die van het uitzicht aan het genieten zijn en op basis van zicht botsingen vermijden. Dat is ongehoord.

Alleen klasse F en G zijn ongecontroleerd. Daarin is geen separatie aangebracht. Klasse F bestaat echter niet in Nederland, en klasse G is de onderste paar honderd meter. Rondom vliegvelden geldt echter weer dat dat klasse C is. Conclusie: Er is geen kubieke centimeter luchtruim waarin verkeer wat vertrouwt op computers wordt gemengd met verkeer wat vertrouwt op de ogen. F16's die laag vliegen gebruiken ook hun ogen om botsingen te vermijden. Dat is verplicht.

En aangezien de luchtvaart deze lessen allang heeft geleerd kom ik terug op mijn punt dat het onbegrijpelijk is dat mensen denken dat dit op de weg zonder problemen mogelijk is.

[Reactie gewijzigd door marijn78 op 2 december 2016 16:49]

Eigenlijk zegt dit artikel niks over de eisen van zo een proces, de i7 is verkrijgbaar van 2 cores + HT tot 10 cores + HT en wat is veel rekenkracht?

[Reactie gewijzigd door Sceep op 2 december 2016 13:21]

Straks mooi allemaal "Intel inside" stickertjes op auto's :)
Ik zie al genoeg "apple" stickers op auto's. :)
Vind elektrisch rijden een stuk verfijnder dan combustion engines maar dat het zonodig moet doorslaan in gereden en getracked worden dat hoeft nou weer net niet.

Het liefst zouden bedrijven je door het hele leven dragen en voor je denken maar dat doen ze uit eigenbelangen en niet omdat hun kunnen bepalen wat de juiste keuze is voor jou.
Straks mag je niet eens meer van de norm afwijken die bedrijven met hun data statistisch als normaal gaan opleggen oid. lol
Wordt je irrelevant en ongewenst gemodereerd alleen al door de gedachte op te werpen.

Want sorry dat ik het zeg maar de norm zegt niets over juistheid maar wat populair is.
En wie market het als dusdanig? Kunnen de mensen nog wel echt (verstandig) kiezen? etc.

Goed dat dingen efficienter en krachtiger kunnen, zoals processoren, maar als we kiezen alles uit handen te geven dan worden we geleefd door anderen en bouwen op hen voort.
Voor een bedrijf ideaal maar voor de mensen, not so sure.

[Reactie gewijzigd door new.hope op 2 december 2016 12:52]

huh? het gaat hier om autonome auto's en jij gaat ineens zitten mauwen over tracking etc.. autonoom betekend niet automatisch dat de auto ook getracked wordt.
Eigenlijk moet dat haast wel, want op het moment dat een van die dingen op hol slaat en een kettingbotsing veroorzaakt of een groep oude dames van de stoep af maait, wil je toch precies weten hoe/wat/waar dat in de programmering foutging. Daar hoort bij een bewegend voertuig natuurlijk de snelheid, tijd en locatie bij. Aangezien je niet een heel array aan TB disks in je auto kwijt wil, zullen die logs toch ergens heen moeten.
Je hebt het als het ware over een zwarte doos, niet over 'live' tracking.. zwarte dozen zullen denk ik over niet al te lange tijd sowieso verplicht worden voor alle nieuwe auto's. Want de redenen die jij aangeeft gelden ook gewoon voor non-autonome auto's.
En die logs hoeven alleen ergens heen wanneer er iets gebeurd is, niet als er niets aan de hand is.
Die redenen gelden niet voor normale auto's. Die hebben geen software die ineens het stuur omgooit, 200kmh intrapt en een schoolklasje omver rijdt. Daarbij lijkt het me handig bij elektronisch bestuurde auto's dat deze door autoriteiten kunnen worden uitgeschakeld. Geen levensgevaarlijke achtervolgingen meer e.d.
Nee, gewone auto's hebben idioten achter het stuur zitten die helemaal geen logica gebruiken en gewoon ineens het stuur omgooit en dus ook dat achtervolgingen beeindigd kunnen worden omdat die bestuurder helemaal geen rekening ergens mee houdt waar een autonome auto dat wel doet.. Ik maak me echt heel veel meer zorgen over de menselijke bestuurder dan de electronische.. en dat is gebaseerd op ervaringen in het dagelijkse verkeer. Wat mij betreft mogen ze veel sneller het rijbewijs (tijdelijk) intrekken, dat werkt beter dan boetes.. vandaag ook weer, een randdebiel die op de weg voor rechtdoor gaat rijden om zo een hele file met auto's voor linksaf voorbij te gaan om dan toch nog links af te gaan en daarbij dus dat de auto die netjes linksaf ging hard op de rem moest gaan om die achterlijke idioot zich er gewoon in drukte (wat mij betreft mogen ze bij dat soort manouvres gewoon permanent het rijbewijs innemen)..
We zullen zien.
Genoeg materiaal wat anders hint.

[Reactie gewijzigd door new.hope op 2 december 2016 17:51]

Mooie invalshoek. Ikzelf zie het graag net anders.
Ik gebruik bedrijven. Zij maken apparaten die mijn leven vergemakkelijken of leuker maken. Ik koop straks een zelfrijdende auto niet omdat het populair is of verkocht wordt als "De Toekomst", maar omdat ik zie dat het veilig is, efficiënt is en mij extra tijd geeft doordat ik niet gefocust hoef te zijn op de weg.
Zelfde geld voor telefoons, computers etc. Ik ben dan wel iemand die zijn research doet en niet zomaar koopt wat veel op televisie of billboards voorbij komt. Ook zal ik niet zomaar al mijn persoonlijke informatie geven en probeer ik me altijd bewust te zijn wat ik deel.

Helaas heb je misschien wel een beetje gelijk gezien hoeveel politieke macht grote bedrijven tegenwoordig bezitten.
Onderschat marketing/reclame en de naïviteit/onkunde van veel mensen niet. ;(

[Reactie gewijzigd door new.hope op 2 december 2016 18:38]

Mag ik vragen hoe jij de wereld over 500 jaar ziet. En denk je niet dat dit soort kleine dingen maar een NON issue is? Hoe denk jij dan dat alles gaat over honderden jaren. Zie jij je klein klein klein kinderen zelf nog rijden? 8)7
Ik snap je gedachte wel, maar zelfrijdende auto's betekend nog steeds je eigen rijdende koets met je eigen interieur en je eigen prive ruimte. Ik zelf rij een sportwagen en moet zeggen dat ik zelf rijden een genot vind om te doen. En hard rijden / optrekken ook. Maar naar mijn werk of supermarkt of andere A naar B zou ik best wel een zelfrijdende auto willen.

Ik zou best willen overstappen op het concept dat Racen en sportief autorijden goedkoper zouden worden als hobby, en op de weg overal zelfrijdende auto's. Natuurlijk leert niemand dan meer autorijden.

Het hele globalisatie is trouwens een zegen, maar ook een vloek. Er zitten overal natuurlijk een keerzijde aan welke we goed moeten inzien en zaken moeten afwegen. Echter zelfrijdende auto's zie ik geen probleem in. Meer in het verzamelen van allerlei data van alles wat je doet.
Doe mij maar een celeron :p. Undervolten die handel en huppa 1pk extra ten opzichte van de i7 varianten. En door het nodig zijn van een minder sterke dynamo en accu nog eens een 1pk meer en betere prestatie :+ .
Dan Bespaar je 100watt? Ik ben niet heel erg goed met natuurkunde, maar dat is geen pk gok ik
1 pk is ongeveer 700 Watt.
Celeron? Waarom niet gewoon een ATOM?
Of gewoon een raspberry pi dat hele systeem laten runnen.
Wow nice. Lijkt me best sick als ooit serieus zo'n jet deels of geheel bestuurd kan worden door een raspberry pi. Natuurlijk is het iets heel anders dan wat je in een zelfrijdende auto nodig hebt, maar ik denk dat een combinatie van beide variaties tot zeer zekere efficiëntie winst kan leiden.
Ik heb nog ergens een ZX81 liggen.
Oei misschien de NFC chip in mijn hand ook wel elektrische auto's besturen dan!!!
Puh, die transistor die ik ooit uit mijn radio heb gehaald ....... :+
Nou zo ziet die chip er wel ongeveer uit ja
Mijn elektrische tandenborstel... :+
Geen gek idee, die komt in alle hoekjes! :+
ja, misschien wat betreft verbruik ja, maar wat betreft prestaties komt die celeron niet in de buurt van de i7.
De allereerste i9 :+ ?
Ik denk dat ze nog met hun i3,5,7 zoet zullen blijven. Misschien over 2-3 jaar komen ze met een nieuwe naam?


Om te kunnen reageren moet je ingelogd zijn



Nintendo Switch Google Pixel Sony PlayStation VR Samsung Galaxy S8 Apple iPhone 7 Dishonored 2 Google Android 7.x 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