hansj

Home/Hans Jørgen Grimstad

About Hans Jørgen Grimstad

This author has not yet filled in any details.
So far Hans Jørgen Grimstad has created 626 blog entries.

April 2017

IN-2 Nixie modules.

By |April 1st, 2017|Concrete Clock, Electronics|

Da er jeg klar med en ny variant av Nixie-kort. Denne gangen har jeg valgt å gjøre dem modulbasert. Hver modul har to IN-2 rør, K155ID1-driverkretser og et shiftregister. Modulene har en 6-pins connector, som gjør det mulig å seriekoble så mange man ønsker, kun begrenset av hvor mye strøm, som boost-converteren kan levere. Hvert siffer i en slik kjede kan adresseres individuelt.

Eagle-filer og eksempelkode finner du her: https://github.com/hansj66/Nixie-Modules.

Forvent tilsvarende moduler for IN-1, samt for ymse VFD-rør – når jeg får ånden over meg :)

in2-modules

in2-modules-assembled

Ferdig !

By |April 1st, 2017|Electronics, Pajazzo|

Jeg har fått noen henvendelser om Spar-7 kort det siste året. I fjor så antydet jeg at jeg kunne ha en ny batch med kort klare til sommeren samme år. Det klarte jeg forsåvidt, men firmwaren tok litt lenger tid. Mest fordi den havnet sist på prioriteringslista – etter dagjobben i Exploratory Engineering, “kveldsjobben” i Pop Bumper, og også etter visst behov for litt rekreasjon innimellom (rekreasjon == aktiviteter uten deadline ;))

Det tok litt tid, men nå er firmwaren klar. Kortene testet og pakket. Jeg sender ut mail til de som tidligere har vist interesse før påske. Kortene finnes i et begrenset antall og det vil maksimalt bli produsert 6 nye kort etter denne batchen. Deretter er det slutt.

Salgsbetingelser

  • Prisen pr kort er 2500 + frakt.
  • Kortet installeres og brukes på eget ansvar. Det er hobbyelektronikk, som hverken er CE- eller Nemko-godkjent. Trekk ut kontakten når automaten ikke er i bruk og ha i bakhodet at resten av elektronikken / mekanikken i disse automatene er fra produksjonsåret.
  • Hvis av en eller annen grunn ikke fungerer i automaten, så refunderes prisen for kortet, ved retur av dette. Fraktkostnader refunderes ikke. Returfrakt bekostes av kjøper.

Installasjon

  • Trekk ut kontakten til automaten.
  • Trekk ut det gamle kortet fra edge-connectoren og trekk også evt ut IDC-connectoren, som går til displayet, hvis du har en variant med displaysiffer (Ikke alle automatene, som kortet fungerer i har dette)
  • Sett inn kortet. Koble evt displayconnectoren til det nye kortet. Displayconnectoren på de gamle Spar7’ene har ikke noen key, så det er mulig å sette inn denne feil vei. (Koble ut strømmen og snu connectoren hvis displayet ikke lyser)
  • Sjekk at begge lysdiodene lyser. Hvis en eller begge av disse er mørke, så er er det sannsynligvis feil ved transformatoren i automaten. Alternativt, så kan det skyldes korrosjon / oksidasjon av edgeconnectoren som kortet er montert i.

Installasjon

Initiell test av brytere og hopper

Åpne knipsekassa og gjenta følgende for hver gevinstport:

  • Aktiver bryteren på baksiden av gevinstporten. Sjekk at gevinst vises i displayet.
  • Aktiver deretter bryteren i renna under gevinstportene (coin exit). Du vil høre at hopper-releet slår inn, slik at bremsen på hoppermotoren kobles fra. Hopperen skal nå begynne å rotere. Gevinst i displayet teller ned med en, inntil hele gevinsten er utbetalt.

Gevinstport

(Gevinstport, bakside)

CoinExit

(Coin exit – trigger utbetaling etter aktivering av gevinstport.)

Hvis en bryter ikke lar seg aktivere

Bryteren kan være defekt, eller det kan ha oppstått kabelbrudd mellom bryteren og edgeconnectoren, Pinnene på edgeconnectoren, som kortet er montert i kan også være korrodert / oksidert.

Bryterne kan testes manuelt hvis kortet trekkes ut av knipsekassa (med strømmen av).

Bryteren kan med et multimeter med kontinuitetssjekk. Bryterne kan ha både NC (Normally closed) og NO (Normally open) tilkoblinger. En defekt bryter kan feile ved at NC-tilkoblingen ikke er lukket når bryteren er i hvilestilling, eller ved at NO-tilkoblingen ikke lukkes når bryteren er aktiv. Vippearmen på bryteren kan også være deformert eller knekt.

De to nederste pinnene på bryterne ved gevinstportene er NC og øverste + nederste pinne er NO. Ledningsbrudd kan finnes ved å måle kontinuitet mellom nederste pinne på gevinstporten og pinne#3 fra venstre på edgeconnectoren.

Hvis hopperen ikke roterer

Hoppermotoren i knipsekassene er alltid aktiv, men en bremse på motoren sørger for at den kun roterer når gevinst skal utbetales.

Følgende kan forhindre at hopperen fungerer som den skal:

  1. Transformatoren leverer ikke strøm til hoppermotoren (NB! nettspenning).
  2. Elektromagneten, som frikobler bremsen fungerer ikke. Motoren må isåfall repareres eller erstattes.
  3. Coin-røret over hopperen er montert slik at det er i kontakt med rotoren og derfor bremser hopperen. Skru coin-røret litt opp for å korrigere dette.
  4. Rotoren er skitten. Myntene er i konstant kontakt med rotoren, og det vil kunne avsettes støv/fett på denne. Dette fikses ved å demontere og vaske de hvite plastdelene.

Hvis hopperen roterer svært sakte

Sjekk pkt 3 & 4 over.

Hvis hopperen ikke stopper ved gevinstutbetaling.

Hopperen betaler ut en mynt ved hver kvart rotasjon. Hvor langt rotoren har rotert, detekteres av hopper-bryteren. Hvis denne er defekt, så vil ikke automaten kunne detektere hvor mange mynter som er utbetalt og den vil tømme hele gevinstrøret.

Hvis spillet utbetaler en mynt for lite, eller en mynt for mye.

Spillet detekterer at en mynt er utbetalt ved at et hjørne på klossen over rotoren lukke hopper bryteren og at den så åpner seg igjen. Hvis armen på denne bryteren er deformert eller bøyd, så vil aktiveringen av bryteren ikke være synkronisert med posisjonen av mynter i rotoren. Se bilde under for hvilestilling på bryteren.

I hvilestilling, så skal ikke bryterarmen lukke bryteren. Test dette ved å forsøke å lukke bryterarmen manueltnår den står i hvilestilling. Du skal da kunne høre et klikk fra bryteren.

Hopper_over

(Hopper i hvilestilling. Bryteren er ikke mekanisk lukket)

Hopper_under

(underside av hopper når hopperbryteren er åpen. Legg merke til myntens posisjon.)

Telleverk

Da dette kortet ikke er laget for kommersiell bruk, så vil det ikke aktivere telleverket i automaten.

February 2017

IN-12 Nixie Shield v.1.1

By |February 15th, 2017|Concrete Clock, Electronics|

Sånn, da har man fikset siste bug i IN-12 Nixie Shield for Arduino, og vi er på versjon 1.1. Har testet litt i kveld og alt ser ut til å fungere helt ok. Skjema, layout og et veldig enkelt kodeeksempel ligger nå ute på GitHub (https://github.com/hansj66/Nixie-Modules). Knock yourselves out :)

Jeg jobber også med daisy-chainbare moduler. Gjerrig som jeg er, så er disse på tur med dampbåt fra Kina. Ta derfor modul-designene på GitHub med en klype salt, inntil ny versjon foreligger av disse også.

January 2017

IN-12 Nixie Shield

By |January 18th, 2017|Electronics|

Hackathon på jobb i dag. I mellom IoT/LoRa-, VR-, 3D-printsesjoner, så klarte jeg å ettertrykkelig fritere en mikrobiten til balansebotten (patologen har ikke avgitt rapport enda, så jeg aner ikke hvorfor).

På jakt etter en liten trøste-win, så lyktes jeg heldgivs noe bedre når jeg endelig fikk mannet meg opp til å koble en boost-converter på det hjemmesnekra Nixie-shieldet.

Encodern synes å være kodet av fulle sjømenn, men det er kun software, så det er høyst fiksbart. Siffer kan adresseres og høyspentbiten ser ikke ut til å forårsake hardware-resets eller røyksopper noe sted. Alt drives av et lite 9V-adapter.

Nå som jeg vet at ting henger sånn tålelig på greip, så er det også på tide å få sendt de daisy-chainbare nixiemodulene til trykking også.

December 2016

Stumbler – part III (more cowbell)

By |December 26th, 2016|3D Printing, Electronics, Robotics|

PID-kontrolleren fungerte. Lavpassfilteret for aksellerometerdata fungerte. Det samme gjorde kalmanfilteret. Det hjalp likevel så inderlig lite når aksellerometeret støyet så mye, og i tillegg var så følsomt for vibrasjoner at enhver motorrespons resulterte i spinnville data. Stumbler ville ikke stå på egne hjul.

Derfor byttet jeg ut IMUen i noe mer beefy. Jeg gikk for BNO055 fra BOSCH. Dette er mer et SoC enn en sensor, da den gjør sensor fusion for deg. Den snakker i likhet med LSM9DS1 I2C, men har et mye enklere oppsett. Du kan bruke den i forskjellige modus. Enten som en tradisjonell IMU, eller som en 9DOF sensor med fusion-algoritme som snurrer i bakgrunnen. Ut får du ferdigtygde data, i form av quaternions, Eulervinkler, rotasjonsvektor, lineær aksellerasjon, gravitasjon og heading. Det finnes nok enda bedre sensorer der ute, men denne kostet rett under 40 USD og var svært enkel å bruke. Se BNO055.cpp for bare bones implementasjonseksempel, inklusive kalibrering.

Jeg har kranglet med LSM9DS1 i ukesvis, men bare et par timer etter å ha byttet IMU, så hadde jeg tegn til virk. Den balanserte nå såpass bra at den tålte å krasje i vegger, samt å få en dytt. Den tok seg nå inn igjen.

PID-parametrene kan nok fremdeles forbedres, iom at den er litt “tense” (Vi har hatt noen spektakulære krasj på steingulvet her). Under, så ser du en av de første prøveturene med BNO055 – med ukalibrert sensor (kan jo ikke kaste bort tiden med å lese spesifikasjon…)

Den var fremdeles litt vill av seg, så jeg myste litt i databladet. Det viste seg at BNO055’en har en autokalibreringsalgoritme. Man kan lese ut kalibreringsdata fra kalibrerningsstatusregisteret. Ved å vifte litt rundt i lufta med botten, inntil man leser ut “1” for bit 6 & 7, så oppførte ting seg enda bedre etterpå.

Under, så balanserer den helt fint på sofaen. Relativt stram pute, og absolutt ikke et flatt underlag.

Må kanskje presisere at den ikke akkurat er fjellstø ennå. Den tryner ofte med pannebrasken ned i flisgulvet, og forsøker av og til å stikke av – i ganske voldsom fart. Signalet fra PID-kontrolleren er vel å betrakte som non-insane i tiltintervallet [-3, 3] grader elns – foreløpig.

Jeg har ihvertfall nok virk til å kunne bygge en 2.0 versjon av botten med større batteripakke, samt litt mer optimal plassering av sensoren. Plata, som alt er montert på nå, er litt wobbly, og stepperne kunne gjerne hatt enda litt mer kraft. Vurderer også å kanskje lage et lite PCB med stepperkontrollere og IMU integrert.

Repo med modellfiler og (prototyp)kode finnes her: https://github.com/hansj66/Stumbler

November 2016

Lunsj ?

By |November 17th, 2016|Rants|

Jeg frykter at USA kanskje ikke er alene om å være en nasjon, som står ovenfor store utfordringer, grunnet enkelte folkevalgtes noe bristende evne til logisk tenking. I vårt tilfelle, så mistenker jeg at nasjonen er et offer for at Universitetet i Bergen sannsynligvis har avviklet forberedende prøver i logikk, samt at helseministerens valg av faglig fundament, for sitt videre politiske virke, er et toårig studium innen hotelladministrasjon.

Snusens emballasje i varehandelen, kan kanskje fremstå som en type problematikk man ikke kommer i kontakt med før man har løst mer basale utfordringer i samfunnet, men det er likevel en skremmende diskusjon. Hva har aktørene tenkt i denne prosessen ? “Lunsj” ? “Laks i trappa” ? Har man blitt fersket i å vekke stortingsrepresentantene ved å rive klistremerket av snusboksen, litt for raskt, i et kjedelig øyeblikk – for så å bli avkrevet en forklaring ?

Forskriften vitner om at ikke en eneste forfatter, eller høringsinstans har evnet å gjøre seg en eneste refleksjon i prosessen. Rasjonalet bak det inderlige håpet om at innpakningen har effekt for omsetningen av sterkt vanedannende substanser er absurd og bærer preg av sviktende evne til logisk tenkning.

Man trenger ikke engang  lete etter argumenter. Høye og hans kumpaner kunne tatt seg en spasertur fra Stortinget, kanskje i lunsjen ? Tatt til høyre på Karl Johan og så vandret videre ned mot Oslo S ? Dette hadde tatt dem 15 minutter og det kunne ha hatt en dobbelt positiv effekt. Det er  a)  kjente positive kognitive effekter forbundet med spaserturer [1], og b) “a” ville gjort Høye og kumpaner i stand til å tolke svarene på spørsmålene de burde ha stilt.

Vel framme, så kunne man kontaktet et utvalg narkomane, for en vurderinger av om slike tiltak ville hatt noen effekt på noe som var enda lettere å slutte med enn nikotin [2].

Ett av spørsmålene kunne eksempelvis vært:

“Kjøper og bruker du tunge narkotiske stoffer, som medfører et liv i elendighet, samt høy risiko for sykdom og nedsatt levealder, primært fordi:”

a) “De har en veldig fin og fristende innpakning.”, eller
b) “Jeg er avhengig.”

Jeg hadde villig betalt ekstra skattekroner for politiske vedtak, som er tuftet på annet enn innfall og ønsketenkning. Hvorfor tok ikke Høye denne turen, når svarene bokstavelig talt ventet på han rundt hjørnet ? Lå bekymringer vedrørende eventuelle utfordringer knyttet til kommunikasjon til grunn ? Isåfall, så kunne de vel hyret inn et kommunikasjonsbyrå for å oversette fengselsbetjents Nordahls, klassiske ordliste [3] til Rogalending ?

Man skulle kunne tro at den lovgivende forsamling kanskje hadde vurdert de samme tiltakene for de lettere stoffene, som Heroin™ ([4]) – som et prøveprosjekt. Man kunne scoret lavthengende politiske poeng, da en kunne forventet garantert effekt i segmentet. Men neida. Heroin™ skal fremdeles kunne omsettes i fristende clingfoil og ziplock-poser, mens de tunge snuserne skal ydmykes ytterligere.

[1] “Brain Rules”, John Medina.

[2] “Nicotine: Harder to Kick…Than Heroin”, New York Times.

[3] “Diverse slanguttrykk blandt narkomane”, fengselsbetjent Nordahl, 1978

[4] “Bayer Pharmaceuticals- Science for a better life”.

October 2016

Scaling up

By |October 31st, 2016|3D Printing, Götterdämmerung|

Jeg fikk mail i dag. Fra Nederland. Med takk for å ha lastet opp Götterdämmerung-designet på GitHub. Avsenderen hadde vært på utkikk etter et CoreXY gantry-design basert på 4040-profiler og linear rails, og var på nippet til å begynne å designe sitt eget, da et Google-søk ledet han til repositoriet mitt på GitHub.

Ikke bare har han bygget en printer, basert på designet. Han har bygget en printer, som er betraktelig større en min, som allerede var på størrelse med en gjennomsnittlig vaskemaskin. Vi snakker takhøyde her :)

Han har også forbedret Z-akse-designet betraktelig. Dette er også den delen av det opprinnelig designet, som jeg er minst fornøyd med, og som krever mest arbeid å installere.

Toolkjeden han benytter er som følger (sitert fra email):

“The Z- Axis uses 3 motors and 3 stepper drivers. I use a RADDS board for electronics with RAPS128 drivers. They are able to give more then enough current to the motors for the torque. The 32bit board also allows for 300mm/s movement with1/32 stepping 0.9deg motors and quick and easy motorized bed leveling. It was a mother*bleep* to setup but now i only put in the SD card and never have to worry about leveling again.  Also, no noticeable z banding”

Printeren kan også printe stort. Rakettmodellen på bildet er 70cm høy!

Etter å selv ha benyttet meg av open source software og hardware i så og si alt jeg har hatt av prosjekter, så er det utrolig moro å kunne gi noe tilbake til miljøet. Det er også svært tilfredsstillende å se at et et design kommer til nytte for andre.

Maker: Max Nijpels.

Photo credits: Max Nijpels.

Aforismer i utvalg

By |October 27th, 2016|Girl Power|

Jeg tror foreldre, med tenåringer i huset, kjenner seg igjen i bekymringen over at viktig informasjon gjerne går inn i avkommets ene øre, for så å diffundere ut av det andre, uten at noe har festet seg på veien. Spesielt gjelder dette når man, i et velvalgt øyeblikk, bestemmer seg for å øse av sin livsvisdom.

Vel…

Jeg hater å innrømme det, men jeg tror vi, som foreldre, tar feil. Bakgrunnen er at jeg fikk en aldeles glitrende bursdagsgave av eldstejenta i år. En bok med tittelen:

 

Det viser seg at hun ikke bare har fulgt med. Hun har til og med tatt notater. Og  – siden det ikke er så ofte man får anledning til å sitere seg selv, så bringer redaksjonen et lite utvalg fra boka, som dessverre kun finnes i ett eneste eksemplar.

Mixology

By |October 21st, 2016|Food and Beverages|

La oss anta at du planlegger en cocktail-aften. Du har ingrediensene klare til travere som “Hedgehog in the Fog”, “Bebbo”, “The Communist”, “La Floridita Daiquiri”, “Bunny Hug”, samt retro stayere, som “Harvey Wallbanger” og “Mojito” 

Men så….,

oppdager du, til din store fortvilelse at du mangler to kritiske ingredienser til “The Monkey Gland”, “Cornichon” og “The Asylum Cocktail”. Du leter i skuffer og skap, men klarer ikke lokalisere hverken Grenadine eller banan-sirup. Butikken er stengt ! Krise !

Hva gjør du ?

Jo, du googler – like desperat som en nyutdannet utviklier, som nettopp har landet i et stort legacy C++-prosjekt. Og så kommer du hit. Chillax !

Banansirup.

  1. Kok opp en kopp vann, med en kopp sukker.
  2. Når blandingen er klar, så tar du den av plata, kapper opp en banan og putter oppi.
  3. Vent et kvarters tid. Kapp opp en banan til og putt oppi. Gjenta en gang til.
  4. Plukk ut bananene og sil sirupen før du heller den på en flaske.

Resultatet smaker banan på samme måte som appelsin smaker appelsin etter at du har inntatt mirakelbær. Null bitterhet og en fantastisk sødme. Intens nok smak til at man kan gjøre om en gjennomsnittlig tankbil med smuglersprit til bananlikør med et par dråper.

img_3354

Grenadine.

  1. Start med å ta ut frøene fra et granateple eller tre.
  2. Rens bort skall og press frøene i bunnen av en kasserolle
  3. Filtrer saften og ta en runde til med stapperen.
  4. På dette tidspunktet, så kan det hende du hater meg i fall du er kledd i noe annet enn helsvart – eller skulle ha innredet kjøkkenet med noe annet enn glass på vegger, tak og gulv. Hopp uansett til neste punkt.
  5. Mål opp saften og hell den over i en ren kasserolle. Tilsett ca halvparten så mye sukker som saft (i volum).
  6. Kok inn i 15-20-30 minutter. Skum av litt innimellom.
  7. Sett til kjøling.

img_3352

Du har nå laget ca tusen ganger så mye av disse substansene, som det er mulig å forbruke i løpet av et normalt livsløp. Dette er litt kjipt, siden de kun har et par ukers holdbarhet i kjøleskap.

Anyways….

Du er nå klar for å mikse deg en “The Monkey Gland”, “Cornichon”, samt en “The Asylum Cocktail”. Og i fall du lurer på om butikk-kjøpt juice er ok, eller om du må presse selv, så er du på feil blogg ;)

Game of Life

By |October 21st, 2016|Rants|

Jeg antar at regulerende myndigheter allerede har tenkt på dette, men jeg lurer på en ting.

Et autonomt kjøretøy er konseptuelt enkelt. Et sett med sensorer registrerer informasjon fra bilen selv, og fra omgivelsene. En “svart boks” mottar denne informasjonen og spytter i sanntid ut det neste kontrollsignalet til bilen. Hvilke kontrollsignaler som gis er avhengig av hvilke mål som skal oppnås, samt hvilke risikofaktorer som skal minimaliseres. Typiske mål kan være:

  • Å nå bestemmelsesstedet
  • Å ikke medføre skade på omgivelser,..
  • andre trafikanter,…
  • kjøretøyet selv, eller…
  • kjøretøyets fører og passasjer.

Disse målene, kan avhengig av situasjon, utelukke hverandre. Det kan oppstå situasjoner der man ikke kan oppfylle alle målene, f.eks i en mulig ulykkessituasjon. Målene må derfor rangeres etter prioritet. Sannsynligvis etter produktet av sannsynlighet for ikke å nå målet og konsekvens av ikke å nå målet.

Jeg tror enkelte ble noe sjokkert, da det begynte å gå opp for folk at det å “holde fører/passasjer i live”, ikke nødvendigvis var høyeste prioritet i implementasjoner av autonome kjøretøy.

Jeg ble sannsynligvis noe mer sjokkert når Mercedes-Benz nylig annonserte at deres fremtidige autonome kjøretøy ville prioritere passasjerens sikkerhet fremfor andres – også over fotgjengeres.

Autonome kjøretøys optimale firmware-etikk kan iofs diskuteres, men det jeg lurer på er følgende:

Har noen der ute tenkt på dynamikken i ulykkesscenarier der kjøretøy med forskjellig firmware-etikk er involvert ?

Setting:

To kjøretøy møtes front mot front i høy fart. Ingen av førerne rekker å reagere.

De bilene som har innebygget AI konkluderer med at nedbremsing ikke vil hjelpe, men at unnamanøver kan gjøres i retning av fjellvegg, eller mot en famile, som går tur langs veien . Kjøretøyenes AI må hver velge en av følgende handlinger:

  1. Do nothing. Bilene vil da møtes front mot front, med fatale konsekvenser for førere/passasjerer, men uten skade på omgivelsene
  2. Unnamanøver mot fjellveggen. Vil resultere i fatale konsekvenser for fører/passasjer.
  3. Unnamanøver mot familie på tur. Vil få fatale konsekvenser for familie på tur, men vil berge fører/passasjer.

Kjøretøyene som møtes kan være fra følgende produsenter:

  • “A”. Denne produsenten ønsker å minimalisere antall søksmål i forbindelse med ulykker og har derfor en klausul i kjøpskontrakten, der det står med liten skrift at bilens AI i en ulykkessituasjon vil prioritere andre trafikanters sikkerhet over passasjer/førerens sikkerhet.
  • “B”. Denne produsenten prioriterer sine kunder høyest og bilens AI vil derfor forsøke å beskytte sin egen fører i en ulykke, uansett konsekvens for andre.
  • “C”. Denne produsenten har en “gjør minst mulig total skade”-policy.

Scenariene under antar at de autonome kjøretøyene kun foretar en korreksjon. Dette er en overforenkling, men alle kjøretøy som implementerer slike strategier vil kunne være i av scenariene under og kun ha tid til å foreta en siste korreksjon før situasjonen er avklart.

Scenario: “Happy path.”.

Kjøretøy “A” og “B” frakter en person hver. Biler av merke “C” frakter 4 personer. Risiko vurderes som sannsynlig utfall x konsekvens (i form av tap av liv)

Varianter:

  1. “A” mot “A”. Begge vil kjøre inn i fjellveggen. Resultat: 2 casualties.
  2. “A” mot “B”. Bil “A” vil kjøre inn i fjellveggen og Bil “B” vil kjøre inn i familien på tur. Alle policyer er ivaretatt og alle er happy. Resultat: 4 casualties.
  3. “B” mot “B”. Kjøretøyene vil møtes front mot front – med familien på tur i midten. Resultat: 5 casualties..
  4. “A” mot “C”. “A” kjører som forventet inn i fjellveggen, “C” velger å kjøre inn i familien, siden 3 er 1 færre enn 4. Resultat: 4 casualties.
  5. “B” mot “C”. “B”.Kjøretøyene vil møtes front mot front, med familien på tur i midten. Resultat: 8 casualties.
  6. “C” mot “C”. Kjøretøyene vil møtes front mot front – med familien på tur i midten. Resultat: 11 casualties.

Legg merke til at familien på tur ikke overlever noen av disse scenariene, der AIen forsøker å redusere konsekvensene av en mulig møteulykke.

Scenario: “Prisoner’s Dilemma by Proxy’ish”.

AIen i et autonomt kjøretøy må nødvendigvis gjøre en risikovurdering før den velger en manøver. Dette er en funksjon av all tilgjengelig informasjon. Jo mer informasjon, jo bedre beslutninger kan kjøretøyets AI foreta. Det vil derfor være naturlig å også forsøke å ta beslutning basert på hvilket type kjøretøy man møter i en ulykke.

Hvilket åpner for en del spennende alternativer. Totalt antall casualties i scenariene over er 34. Ved at en av kjøretøyene “lyver” mht å følge sin strategi, så vil antall casualties i hvert eneste av scenariene over reduseres med 1-4″ pr. scenario

Hvis ingen av kjøretøyene følger sin strategi. Dvs ikke forsøker å unngå møteulykken, så vil totalt antall casualties i hvert scenario være 13 færre enn om de fulgte sin strategi.

Legg merke til at familien alltid vil overleve hvis ingen av AIene forsøker å redusere konsekvensene av den mulige ulykken.

Scenario: “Tickling the Dragon’s Tail”.

La oss nå anta at ulykken skjer i tett trafikk av autonome kjøretøy. To kjøretøy oppfatter en mulig ulykkessituasjon, og utfører derfor hver sin nødvendig unnamanøver, som i sin tur vil oppfattes av andre autonome kjøretøy – som en mulig ulykkessituasjon.

En høy konsentrasjon av “A”-produserte kjøretøy vil fungere absorberende og systemet vil etterhvert falle til ro, men en høy nok konsentrasjon av “B”-produserte kjøretøy (som vil beskytte føreren for enhver pris), vil resultere i en kjedereaksjon av potensielt livsfarlige unnamanøvre. D.v.s. livsfarlige for alle andre trafikanter.

Jeg har nå sett bort fra problematikk forbundet med slikt som valg av komponenter fra rimeligste tilbyder, built in obsolescence på ymse nivå i komponenthierarkiet, utilsiktet bias i AI/beslutningssystemer, hackingpotensiale i form av sensorangrep, samt det faktum av at alt dette gjerne er sauset sammen under tidspress fordi man ikke vil komme for sent på markedet – av hardwarefolk – i C++. Og hva skjer i det øyeblikk det dukker opp “tuningverktøy” eller modchips for autonome kjøretøy ? Vil man få kjøpe kit med manuelle PID-kontroller for dashboard, samt racing-treningssett for AIen på USB stick ? What could possibly go wrong ?

PS. Jeg innrømmer villig vekk at scenariene over er en etter-rasjonalisering av en konklusjon, tatt på sviktende grunnlag. Det betyr likevel ikke at de ikke er gyldige.