Bilen Tommy til køreprøve med Java som chauffør

JavaOne: Tommy Junior blev diskvalificeret i semifinalen, da bilen havde strejfet autoværnet på grund af et svagt system til vognbanegenkendelse.

SAN FRANCISCO: Tommy Junior er langt fra en typisk bilist i Californien. Først og fremmest har hans skabere ikke givet ham mulighed for at bruge hornet, og han bruger også blinklyset, hver gang han drejer eller skifter vognbane.

Tommy Junior skiller sig også ud ved at være 100 procent Java-baseret.

Tommy Junior var Team Jeffersons bidrag i sidste års DARPA Urban Challenge, der var en konkurrence om at bygge biler, der var i stand til at begå sig i bytrafik på egen hånd uden en menneskelig chauffør.

Konkurrencen var en efterfølger til det amerikanske forsvars forskningsfond DARPA's Grand Challenge, hvor autonome robotbiler skulle gennemføre næsten en flere hundrede kilometer lang strækning på en grusvej i den californiske ørken.

Efter flere hold i andet forsøg gennemførte løbet, blev udfordringen skærpet ved at sætte to millioner dollars på højkant til vinderen af Urban Challenge, hvor holdene skulle bygge biler, der kunne navigere på egen hånd i bytrafik.

»Vi skulle overholde de californiske færdselsregler. Heldigvis ikke reglerne fra New Jersey, hvor jeg er fra,« griner holdleder Paul Perrone fra Team Jefferson og direktør i Perrone Robotics.

Holdet var ikke blandt de 11 hold, som blev udvalgt af DARPA til at få støtte til konstruktionen af bilen. I stedet måtte holdet arbejde med et begrænset budget og hjælp fra sponsorer.

Holdet havde deltaget i 2005-udgaven af DARPA Grand Challenge med den ombyggede dunebuggy Tommy, som havde vakt opsigt med dets 1950'er science fiction-udseende og ved at være den eneste bil, der udelukkende kørte på Java-baseret software.

»Størstedelen af robotmiljøet benytter C++ eller særlige realtime-sprog. Vi havde en lidt anden indgangsvinkel, fordi vi i stedet brugte realtime-funktionerne i Java RTS,« fortæller Paul Perrone.

Da holdet besluttede sig for at forsøge igen i Urban Challenge, var den første udfordring at finde en passende bil. De store favorithold havde allieret sig med blandt andre General Motors og VW, som leverede biler til dem. Team Jefferson gik i stedet ud på brugtmarkedet og valgte en Scion xB fra Toyota.

»Det er en bil, der fylder meget lidt på vejen. Det betyder, at der er mindre, der rager ud og kan støde ind i forhindringer. Samtidig er den en kasseformet bil, som det er let at fylde med udstyr,« forklarer Paul Perrone.

Efter at have anskaffet bilen installerede holdet de nødvendige servoer til at styre rat, gear, bremser og andre mekaniske dele. Derefter blev al elektronikken installeret med to x86-baserede pc'er med Solaris til at styre det hele. Først derefter sammensatte holdet den nødvendige software til at gøre bilen i stand til at køre på egen hånd.

»Det tog os blot omkring én uge at gøre bilen i stand til at køre selv. Men derefter skulle vi lægge alle de nødvendige regelsæt ovenpå,« siger Paul Perrone.

Tommy Junior bruger en fintfølende GPS med en følsomhed på ned til nogle få centimeter som den primære navigation. Den sværeste opgave er imidlertid ikke at få den selvkørende bil til at følge en bestemt rute, men at undgå at støde ind i forhindringer og ikke mindst andre biler på vejen.

Derfor blev GPS'en suppleret med et stereokamera, der kan tage billeder i 3D og af radar og laserafstandsmålere.

Selve softwaren til at navigere gennem forhindringsbanen med den simulerede bytrafik blev skrevet ved hjælp af Java RTS, SE, ME, SunSpot og Comm API'erne til at styre de forskellige dele af bilen og behandle data.

Den sværeste del var at bryde bilkørslen ned i trin, som kunne beskrives i kodeform, så softwaren selv kunne foretage eksempelvis en overhaling af en forankørende bil.

»Overhaling bliver ret komplekst. For eksempel må du ikke overhale på en vej, hvor der er overhaling forbudt, og det er måske let nok at overhale på en lige strækning, men hvordan gør du det i et sving?« forklarer Paul Perrone.

Det betyder, at der skal tages højde for en lang række undtagelser og særtilfælde som eksempelvis at gøre det umuligt for softwaren at vælge at begynde at foretage en trepunktsvending, når bilen er midt i et vejkryds.

For at forhindre Tommy i at begynde at overhale en bil, der blot vat stoppet kortvarigt, så indlagde Team Jefferson små ventetider på omkring tre sekunder, før softwaren skiftede til en ny manøvre.

Udover at overholde færdselsreglerne var den væsentligste regel i Urban Challenge, at bilerne blev diskvalificeret, hvis dommerne fra DARPA blev tvunget til at udløse bilens nødstop.

Samtidig kunne et sammenstød med en anden bil eller en forhindring ødelægge udstyret, og derfor var redundans og sikkerhedsfunktioner en topprioritet for Team Jefferson.

»Det her er store biler. Hvis de støder sammen, så er det ikke ligesom med små robotbiler, der bare bumper lidt rundt, hvis de støder ind i væggen,« fortæller Paul Perrone.

Team Jefferson slap dog alligevel ikke fra Urban Challenge uden uheld. Ligesom flere andre hold havde de ikke taget højde for, at der kunne være bomme, som blokerede vejen ved eksempelvis en jernbaneoverskæring.

Flere biler stødte ind i bommen i de første prøvekørsler, og Tommy Junior fik smadret forruden. Dommerne valgte dog at fjerne jernbanebommen, fordi den ikke var en type forhindring, som var beskrevet i konkurrencens betingelser.

I betingelserne var det eksempelvis givet, at bilerne ikke skulle være i stand til at navigere gennem lysregulerede kryds eller fortolke vejskilte. I stedet var alle kryds med fuldt stop for alle trafikanter.

Informationen om både vejen og krydsene fik holdene i form af GPS-koordinater for kritiske punkter på ruten.

For Team Jefferson viste det svageste led sig at være Tommys evne til at følge vognbanerne.

»Vi strejfede et par autoværn, fordi vores vognbanegenkendelse ikke var perfekt,« siger Paul Perrone.

Det kostede holdet en plads i finalen, efter det fik afvist en appel over dets diskvalificering, selvom holdet havde gennemført semifinalen, uden dommerne havde været nødt til at udløse nødstoppet.

Dermed gik holdet også glip af chancen for at vinde de to millioner dollars, der var på højkant til vinderne af Urban Challenge.

Nu vil holdet bygge videre på dets software og forbedre den, så regelsættene bliver i stand til at håndtere mere generelle situationer i stedet for at have særlige funktioner til alle særtilfælde.

Selvom der endnu ikke er annonceret en ny DARPA-konkurrence, så forventer Tommys skabere, at softwaren kan hjælpe andre robotter til at arbejde mere autonomt. Og holdet håber, at de har været med til at vise, at Java også kan bruges til komplekse robotter.

»Vi var glade for, at vi kunne udnytte Java, fordi det gav os et højt abstraktionsniveau, så vi kunne skabe rigtig meget funktionalitet på kort tid,« siger Paul Perrone.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (14)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Jacob Christian Munch-Andersen

Er jeg den eneste her som er forundret over historiens vinkel? Jeg er da egentlig ligeglad med hvilke programmeringssprog holdene har valgt, det er jo ikke det det kommer an på. Hvad med et par ord om hvordan de bedste hold klarede sig?

Det her ligner mest af alt en malplaceret Javareklame.

  • 0
  • 0
#3 Jesper Stein Sandal

Det er ikke anderledes end enhver anden case-historie som eksempelvis, hvordan en virksomhed har udskiftet ét styresystem med et andet. Og når artiklen er en del af JavaOne-dækningen kan det vel ikke overraske, at det lige netop er Java, der er emnet. Lige som der findes nyheder, så findes der mange andre journalistiske genrer. Det her er et eksempel på en case-historie, som er i familie med portrætinterviewet og reportagen.

Og for mange er det nok interessant, da Javas RTS ikke i alle kredse har samme anseelse som nogle af de øvrige realtime-sprog.

Sidste år skrev jeg en tilsvarende artikel fra JavaOne: http://www.version2.dk/artikel/2431

Mht. til de øvrige deltagere, så kan jeg henvise Jacob til at læse min tidligere dækning af DARPA Urban Challenge: http://www.version2.dk/artikel/4766 http://www.version2.dk/artikel/4818

Og ellers kan vi diskutere journalistiske arbejdsprocesser over en fadøl og et spil dart hos Bilco's senere i dag.

  • 0
  • 0
#5 Jacob Christian Munch-Andersen

Så jeg skal nærmere læse det her som en historie om Java vinklet i retning af DARPA. Det giver umiddelbart lidt mere mening, eftersom historien om at de anvender Java er tør og indholdsløs, kun "vinklingen" gør den værd at læse.

Med den information undrer det mig så ikke så meget at den er vinklet på den måde, i stedet undrer det mig hvad den overhovedet har at gøre i V2 til at starte med.

Og for mange er det nok interessant, da Javas RTS ikke i alle kredse har samme anseelse som nogle af de øvrige realtime-sprog.

Jeg vidste ikke hvad Java RTS var før jeg læste denne artikel, det gør jeg stadigvæk ikke, og den eneste snert af ide om hvorvidt det er et godt sprog har jeg hentet ud af den information at det er anvendt som en del af et system der fik en bil til både at køre ind i en jernbanebom og slibe lakken af op ad et autoværn.

Sidste år skrev jeg en tilsvarende artikel fra JavaOne: http://www.version2.dk/artikel/2431

Præcis samme opsrift, den artikel har heller ikke noget som helst med Java at gøre.

  • 0
  • 0
#6 David Konrad

Præcis samme opsrift, den artikel har heller ikke noget som helst med Java at gøre.

Dog må man nok konkludere, uagtet historiens relevans eller mangel på samme, at det IKKE kunne lade sig gøre at fabrikere "selvtænkede" omgivelse/miljø -reflekterende software til biler, baseret på java, så bilen var i stand til at køre sikkert ud af en vej. Den kunne ikke engang følge en vejbane.

Java er altså ikke særlig velegnet som sprog til "robot"-software. Javaprojektet dumpede jo, eller tabte. Og årsagen til at de overhovedet brugte java var angiveligt at de i modsætning til de "store" teams ikke fik støtte, og måske manglede den nødvendige ekspertise indenfor rigtig realtidsprogrammering i et dertil passende sprog?

Så man kan da godt sige, at historien handler om java - blot er den endnu et eksempel på hvad man heller ikke bør bruge java til.

Naturligvis kan man ikke bruge et tungt, fuldkommen overlæsset fortolket sprog, med garbagecollection, som udgangspunkt for realtids-software der handler om liv og død, og hvor softwaren skal virke og stå standby 100%, 100% af tiden.

Ja, bare at man prøver er jo helt håbløst. Et molboprojekt. Og det var vel og mærke ikke programmørverdenens svar på Jackass - men en seriøs konkurrence med $2 mio på højkant!

Så man kan sige - måske siger historien i virkeligheden noget om java-miljøet?

Java er jo oprindeligt et lettilgængeligt fortolket sprog (som er ukompliceret og nemt at lære, og bla bruges på skoler) som skulle virke på tværs af platforme, og gøre det nemmere at udvikle (middleware) bruger-applikationer. Prisen var så et betragteligt overhead og performancetab.

Og i dag sidder man altså seriøst og vil sende java-robotter til månen, lave java-biler og der sidder sikkert masser og drømmer om java i forbindelse med hjertekirurgi. Ville nogen, der kender java, seriøst stole på deres pacemaker hvis den var drevet af en java-VM, med java.io.pacemaker.heartbeat / java.io.pacemaker.pulsegenerator klasserne? Jeg tvivler.

  • 0
  • 0
#7 Jørgen Henningsen

Jeg må indrømme at jeg nok heller ikke havde valgt java til sådan en opgave. Det embeddede java jeg har prøvet har været en skuffelse. Jeg tror dog ikke JAVA er denne bils svageste punkt, det lyder mere som om den har nogle dårlige sensorer. Jeg synes i det hele taget det er en noget unfair konkurrence. Det er mere et økonomisk kapløb om de bedste sensorer, end det er et kapløb på innovation.

  • 0
  • 0
#8 Jesper Stein Sandal

Ja, sensorerne er altafgørende. I dette tilfælde var den dyreste sensor et stereokamera til 12.000 dollars, som havde en indbygget processor og software, der foretog det meste af objektgenkendelsen og afstandsbedømmelsen - den software var skrevet i C++, som holdet så skrev et Java-interface til.

Mht. at støde ind i autoværnet, så skyldtes det netop sensorerne, som ikke havde tilstrækkelig opløsning til at få et pålideligt billede af betonelementer, der var placeret lidt forskudt for hinanden.

Ligesom de fleste andre hold var det vigtigste input GPS, hvilket kan virke lidt som snyd i forhold til et autonomt køretøj, men her havde dette hold heller ikke så detaljerede kort, som andre hold var i stand til at lave over testbanen.

Jeg tror, at placeringen og antallet af sensorer og manglende test af softwaren under alle forhold var mere afgørende end valget af Java. Så stort et overhead er der nemlig heller ikke nu om dage i Java, at det skulle udgøre noget problem i dette tilfælde.

Til gengæld brugte vinderholdet 10 bladeservere til databehandlingen, så det gav nok også mulighed for behandling af flere sensorinput pr. sekund.

http://www.tartanracing.org/team.html http://www-cs.stanford.edu/group/roadrunner/ http://teamvictortango.blogspot.com/

  • 0
  • 0
#9 David Konrad

Jamen hov Jesper Stein Sandal, så er overskriften da rigtig nok - som Munch-Andersen er inde på - fuldkommen misvisende..

Java var IKKE chauffør, som overskriften påstår, men taber-holdet brugte forsøgsvis et java-interface til en rigtig realtids-kerne.

Jeg tror, at placeringen og antallet af sensorer og manglende test af softwaren under alle forhold var mere afgørende end valget af Java. Så stort et overhead er der nemlig heller ikke nu om dage i Java, at det skulle udgøre noget problem i dette tilfælde.

"at det ikke skulle" er et dårligt udgangspunkt når det handler om missionkritisk software. Lad mig henvise til dette blog-indlæg tidligere på året http://www.version2.dk/artikel/6212

  • 0
  • 0
#10 Jesper Stein Sandal

Jamen hov Jesper Stein Sandal, så er overskriften da rigtig nok - som Munch-Andersen er inde på - fuldkommen misvisende..

Java var IKKE chauffør, som overskriften påstår, men taber-holdet brugte forsøgsvis et java-interface til en rigtig realtids-kerne.

Jeg er ikke helt sikker på, hvad det er, du vil med det indlæg, bortset fra at du åbenbart har noget imod Java, og samtidig vil gøre dig klog på journalistik.

Java-softwaren foretog præcis de samme vurderinger af input, som du foretager dig, når du sidder bag rattet. Din afhængighed af sensorer som sidespejle, speedometer og GPS gør dig stadig til chauffør. Så nu er vi vist derude, hvor vi taler semantik, og det har jeg dårlige erfaringer med at forsøge mig med på et konstruktivt plan over for stivnakkede debattører. Det bliver lidt ligesom at debattere med muldyret i det afsnit af Family Guy...

http://www.tv.com/family-guy/boys-do-cry/episode/920133/trivia.html

Så lad det bare blive ved, at du mener, valget af Java var problemet, og se bort fra, at 28 andre hold heller ikke kom med i finalen. Mange af dem blev elimineret før Java-holdet.

  • 0
  • 0
#12 David Konrad

Jeg er ikke helt sikker på, hvad det er, du vil med det indlæg, bortset fra at du åbenbart har noget imod Java, og samtidig vil gøre dig klog på journalistik.

Jeg har intet imod java, og jeg gør opmærksom på at overskriften ift din egen redegørelse er direkte misvisende. Og jeg kører ikke bil, ejer ikke et kørekort, og ser ikke den tåbelige kopi-serie Family Guy. I øvrigt er journalist eller journalistik ikke et videnskabeligt fag, eller en beskyttet titel.

Så lad det bare blive ved, at du mener, valget af Java var problemet

At java blev valgt var hele artiklens præmisse og omdrejningspunkt - fra overskrift til de konkluderende udtalelser om, at java-projektet kan bruges til en hel masse i fremtiden, i forbindelse med robot-software helt generelt.

At der nu trækkes i land, og det så åbenbart ikke handlede om Java alligevel - det er ikke mit, men journalistens problem - uanset hvor "stivnakket" det kan virke at dykke ned i essensen af din tekst.

  • 0
  • 0
#13 David Konrad

Du må have rimeligt god indsigt, når du sådan kan konkludere at det var Java der var problemet... host

Der kan være 10.000 ting der gjorde at de fejlede. Men at java ikke er designet til, eller kan bruges til, missionskritiske realtidsopgaver, det står nagelfast - uanset om det var årsagen til at projektet fejlede eller ej.

  • 0
  • 0
Log ind eller Opret konto for at kommentere