Category Archives: Smart Systems2013 – Smart car

Smart Car, Java kode

Java programmet som skulle kjøres på Raspberry Pi ‘en i bugsteren ble av forskjellige grunner (både personlige, og problemer med java på R.-pi)  ikke ferdig. Det mangler både sockets for kommunikasjon til web-server og siden jeg ikke har fått kjørt .jar fila så veit jeg ikke sikkert om serial-kommunikasjonen fungerer.
Det skulle også vært implementert en algoritme som finner korteste vei til målet (Djikstra’s).
Zip-fil med kode: https://www.dropbox.com/s/0pv87srdpobw6qo/navigation.zip

Jeg burde ha programmert programvaren i C eller Python isteden, da dette antageligvis ville resultert i at jeg hadde blitt ferdig, da de problemene jeg fikk underveis i utviklingen er mye vanligere med java. Python eller C egner seg nok mye bedre til programmering av serial-komm. og sockets.

Smart car, siste hardware oppdatering

Fremgang siste uken på hardware siden:
Mål for den siste uka:
1. Bli kvitt det siste av elektriske problemer og få på plass sikker og tilstrekkelig strømforsyning på batteri.
2. Opprette protokoll/encoding for mottak av kommandoer og sending av sensordata til/fra raspberry pi, og implementere metoder som håndterer dette.
3. Koble raspberry Pi til systemet og få alt til å fungere på batteristrøm.
4. Forbedre oppløsning og sikkerhet for metoder for kjøring og måling ved interrupts og timing.
5. Samle alle målinger, kildekode, kilder, og annen dokumentasjon, rydde disse, og lage en zip-fil av det som kan lastes opp til bloggen.

12V (11.2V) batteri kom ikke i tide, så vi hadde ikke batteristrøm til Raspberry Pi. Det hadde ikke noe å si siden RPi ikke hadde serial interface implementert på sin side. Aruino serial er fullstendig implementert. Ellers fungerer et 9V batteri som strømleveranse for logikk og et 6V batteri drar driverkortet og motorene. Det var ikke nok spenning/strøm fra 5V regulert ut fra Arduino Mega til å dra IR sensorer for hjul, 4 IR-switcher for krasjprevensjon og ultralyd modulen i konfigurasjonen som var satt opp, så jeg droppet 3 av IR switchene og beholdt en i front for krasjprevensjon ved kjøring fremover. Ellers ser de elektriske problemene ut til å være under kontroll. Mål 1 oppfylt tilstrekkelig.

Arduino siden av serial koblingen er fullstendig implementert, og output kommer tydelig ut. Pga prioriteringer og liten tid til å gjøre alt sendes måledata for kjørt avstand i form av transisjoner i stedet for mm, å fikse dette burde ikke ta mange timer (1-3 avhengig av uforutsette problemer eller omstrukturering av kode). Ultralyd måledata oppgies i cm, mens hastighet er i mm/s og input for kjørekommandoer er i mm distanse for frem/bak og grader for vinkler (10 grader oppløsning). Data dumpes for øyeblikket med samme frekvens som navigasjon rekalkulerer (bruker feedback til å korrigere rettning/hastighet), men kan gjøres uavhengig med egen timer relativt enkelt. Mål 2 annsees som oppfylt tilstrekkelig fra hardware (arduino og bil) siden.

Pga ting nevnt over ble ikke raspberry Pi koblet til. Mål 3 gikk bort.

Måling av hjul ble forbedret med en 32-fase rotary encoder og bruk av interrupts og timing i stedet for sampling. Resultatene ble mye mer presise, men pga slerk i det fysiske systemet (hjulene har litt dødgang på festet) og suboptimal plassering av sensoren for å sikre at transisjoner ble målt forekom spikes i hastighet. Disse ble håndtert av conditional bruk av sample ved interrupt ved å se på delta timestamp. Alle transisjoner ble timestampet og lagret i et lite array som dumpes når det nærmer seg fullt eller hvert sekund. Det ble brukt en liten sirkelbuffer for å snitte de forrige hastighetene som ble målt, og snittet av denne bufferen ble brukt til navigasjonsalgoritmene (hastighet som feedback til power når et hjul kjører lenger enn det andre). Det var ikke nok tid til å tweake ut tid/hastighet spikes som forekommer, men ved tiltakene nevnt over ble dataene stabile nok til at det ikke var noe stort praktisk problem. Mål 4 ble oppfylt som forventet.

Dump av kildekode, kilder brukt, diverse oppmålinger og utregninger, samt annen relatert/relevant info legges ved i zip linket fra public dropbox folder: https://dl.dropboxusercontent.com/u/58332293/smart_car_hardware_dokumentasjon_dump.zip
Tidligere bilder som ikke er lastet opp : https://dl.dropboxusercontent.com/u/58332293/smart_car_picture_dump.zip
Mål 5 oppfylt, men det kunne vært ryddet/sortert bedre. Arduino kildekoden er bare samlet i en stor fil, faktorisering i klasser og rydding ble prioritert lavere enn å få på plass funksjonalitet og få denne til en brukelig nøyaktighet.

Utfordringer og feilkilder underveis:
Hardware ankom / ble utlevert sent, og store obliger i andre fag i andre halvdel av semesteret (spesielt siste tredjedel) ga et veldig arbeids/tids-press på slutten av semesteret. Med mer tid kunne systemet blitt forbedret en del og gjort mer ryddig.

Det var mange elektriske problemer underveis, fra å finne koblingsskjemaer og implementere disse riktig, til kortsluttning og jordfeil (ikke lurt å putte ledninger i feil hull :P), og strømforsyningsproblemer fra batteri/arduino. En Arduino Nano (diode som er vanskelig å bytte ut i praksis) og et par ledninger støk med i prosessen (men det var mer irriterende og litt bortkastet tid enn en stor hindring), og veldig mange timer gikk med til feilsøking av elektro-problemer.

Motorene er ikke veldig nøyaktige eller likt balansert på kraft/moment, og festet til hjulene har slerk som gjør sensorplassering suboptimal. Dette gir utfordringer rundt nøyaktigheten og uniformheten til målinger.
IR trigger sensorene er oppgitt til 3-30cm rekkevidde, men i praksis er grensen rundt 15cm og da ikke pålitelig før nærmere 10cm. Dette gjorde at en aktiv brems ved å flippe motor-rettning og gi full kraft var nødvendig for å ikke krasje med ting ved toppfart. Kjeglen denne ser er mindre enn tverrsnittet til bilen, så den kan fortsatt krasje med ting som ikke synes rett frem.

Ultralyd sensoren (slik konfigurert her) hadde problemer med å oppdage tynne objekter, og kjeglen den ser er såpass stor at det er vanskelig å plassere ting uten å stå like inntil dem eller stoppe og gjøre en «sweep», og det var det ikke tid til å implementere med resten av utfordringene. Om det er flere objekter innenfor kjeglen kan også målingene hoppe mellom disse (avhengig av plassering), som er en ekstra ting å ta hensyn til når man ser på sensordata.

EDIT: glemte å bruke tilkoblede LEDs til status i siste arduino kode, det har blitt brukt under buggtesting med batteristrøm.

EDIT2: google slides presentasjon: https://docs.google.com/presentation/d/1nMYsaW7r1FLqMec0sWzp_F4ibfNtGwAnRnCxrrlolq8/edit?usp=sharing

Smart Car, hardware update

Oppdatering av fremgang på hardware siden og plan (for hardware) for den siste uka:
Uke 25 november – 1 desember. Mål for uka:

  1. bruke sensordata i en feedback loop til å svinge et gitt antall grader.
  2. koble til IR sensor og bruke denne som stopp-trigger for krasjprevensjon.
  3. koble til ultralyd sensor for avstandsmåling, få brukbare sensordata, estimere nøyaktighet ved avstander, og klargjøre for sending til Raspberry pi over seriell.
  4. ta i mot kommandoer for kjøring over seriell fra Raspberry pi og eksekvere disse.
  5. Forbedre metoder (ved å bruke interrupts?) og jobbe på bedre kalibrering av sensordata sampling/tolking og feedback loops for mer nøyaktig navigasjon.

Jeg satt opp en metode som svingte et gitt antall grader i ønsket retning og brukte feedback fra sensorene på hjulene til å bestemme grader. Etter litt tweaking ble resultatet mulighet for å stå stille og rotere i steg på ca 20 grader med nøyaktighet på ca 2 grader. Begrensningen for størrelse på steg og nøyaktighet var avstanden mellom eikene  og ikke bruk av timing for målinger. Det bør være mulig å øke nøyaktighet og gjøre metoden mer finkornet med bruk av interrupts og timing kontroll. Mål 1 ble oppfylt, med rom for forbedring.

For krasj-prevensjon ble det først brukt 1 IR sensor i front, og så montert en bak og en på hver side i front for å oppdage hinder under rotasjon. Disse fungerte bra i rett linje med kort avstand, men er ikke tilstrekkelig til å fange opp små hinder som ikke kommer direkte forran dem. Avstanden var også kortere enn ønsket, men det er en begrensning ved selve sensorene. For å klare å stoppe i tide ved å kutte motorkraft er det ikke trygt å kjøre med full motorkraft. En løsning kan være aktiv bremsing, men vil kreve mer jobb og ta hensyn til timing. Mål 2 ble oppfylt som satt opp.

Ultralyd sensoren ble koblet til. Målinger virket riktige og ganske nøyaktige. Med en innlagt usikkerhet på 1cm som slingringsmonn for målinger ble målingene stabile. Brukbar avstand for målinger var ut til ca 1 meter. Dersom det var fler objekter innen «line of sight» (LOS) hoppet målingene mellom disse, så det ble lagt inn delta avstand mellom målinger for å identifisere dette (threshold satt til 10cm). Testing ble foretatt med 10-50 hz sample rate, nærmere 50 hz ga bedre resultater ved bevegelse men mer hopping mellom objekter. Vinkelnøyaktigheten og sensitiviteten på målinger var ikke høy nok til å identifisere stol/bordben, og kjeglen med LOS gjorde at resultatene ikke er pålitelige til å plassere objekter ved større avstander enn 20-40cm så lenge sensoren er statisk montert. Mål 3 ble oppfylt som forventet.

Grunnet buggtesting og fiksing av elektriske problemer som oppstod rundt batteridrift gikk mye tid med, og mål 4 og 5 ble ikke gjort mer enn planlegging og kildesøk. Det var problemer rundt spenning og strømmengde fra Arduino Mega sin 5V regulerte output ved drift fra 6V batteri når fler sensorer var i bruk samtidig. Bruk av et 9V batteri til å drive Arduinoen og 6V til driverkortet for motoren ble problemet mindre men ikke helt løst. Ved å fjerne en motstand for spenningsbegrensning for å sikre Arduino Mega mot for mye trekk (etter rådføring med Dag) ble problemet nesten løst.

Mål for den siste uka:

  1. Bli kvitt det siste av elektriske problemer og få på plass sikker og tilstrekkelig strømforsyning på batteri.
  2. Opprette protokoll/encoding for mottak av kommandoer og sending av sensordata til/fra raspberry pi, og implementere metoder som håndterer dette.
  3. Koble raspberry Pi til systemet og få alt til å fungere på batteristrøm.
  4. Forbedre oppløsning og sikkerhet for metoder for kjøring og måling ved interrupts og timing.
  5. Samle alle målinger, kildekode, kilder, og annen dokumentasjon, rydde disse, og lage en zip-fil av det som kan lastes opp til bloggen.

Oppdatering: Smart Car, hardware siden

Her er en oppdatering av fremgang på hardware siden for de forrige 2 ukene:
Uke 11-17 nov. Målene for uka var:

  1. Å koble opp den fysiske platformen med arduino og driverkortet drevet fra batteriet, men ikke ennå koble sammen raspberry pi og arduino.
  2. Programmere systemet til å kjøre rett frem, rygge, og svinge/rotere.
  3. Finne avstander i forhold til rotasjon av hjul for å kunne beregne kjøre og svingeavstander basert på feedback fra sensorer når de blir koblet opp.

Jeg brukte breadboard vi fikk med i Arduino Nano pakken til å splitte strøm fra batteriet. I starten brukte jeg Arduino Nano til å gi både Arduino Mega og driverkortets 5V logikk regulert 5V strøm. Grunnet en manglende motstand i koblingen til jord og at driverkortet prøvde å kjøre på 5V slapp Arduino Nanoen fri den blå røyken i en diode på undersiden. Jeg fikk tak i en ny Nano, men har valgt å ikke bruke den siden da det ikke var noe behov for det. Nå brukes breadboard bare til å sette opp eller splitte koblinger og felles jord. Driverkortet forsyner sin egen 5V logikk med strøm fra batteri via egen spenningsregulator, og Arduino Mega tar også strøm fra batteriet til sin Vin via en motsand som begrenser strømtrekk og regulerer spenning selv. Mål 1 ble oppfyllt.

Når mål 1 var oppfylt kjørte jeg diverse testprogrammer som satt strøm på motorene med PWM signal til driverkortet for å kontrollere kraft, og kjørte blindt siden sensorene ikke var koblet inn ennå. Metoder for alle ønskede kjøremønstrene ble satt opp og fungerte. Det var forskjell i moment/kraft på motorene og litt feilballansering av vekten til komponentene om bord, så motorene måtte ha forskjellig kraft for å kjøre rett, og ved aktiv bremsing (bytte motorene til rygg med full fart) både bremset og svingte buggsteren. Mål 2 ble oppfylt.

Jeg målte opp diameter på hjulene, avstand mellom hjulene, avstander fra midtpunktet mellom hjulene, og hvor store overheng som var ut fra hjulene og fronthjulet. Ut fra dette regnet jeg ut svingradius (ett hjul i drift), rotasjonsradius(hjulene hver sin vei), og avstand pr hjulrotasjon og pr eike på hjulene. Dette igjen ble brukt til estimater for antall eiker rotasjon på hvert hjul for gitte grader rotasjon. Poenget med å måle pr eike var å bruke dette med transisjoner av sensorverdier som måler eiker som passerer på hjulene for å måle avstand, fart, svinging osv neste uken. Mål 3 ble oppfylt.

Uke 18-24 nov. Målene for uka var:

  1.  Koble til sensorer for måling av kjøreavstand, og få brukbar data fra disse.
  2. Bruke målinger fra sensorene til å se om fysiske mål tatt forrige uke stemte, og korrigere disse.
  3. Bruke sensordata i feedback loop til å kjøre rett en gitt avstand, korrigere kurs underveis, og stoppe etter avstanden.
  4. Bruke sensordata i en feedback loop til å svinge et gitt antall grader.

Grunnet en uoppdaget feilkobling av kabler gikk 5+ timer med til buggtesting av kjøreavstandssensorene via analoge readouts. Output fra sensorene er analoge data som måler reflektert lys. Når feilkoblingen ble oppdaget og en modifikasjon av koblingene med en ekstra motstand mellom sensor output og Arduino input ble sensordata konvertert til et digitalt signal som var både stabilt, responsivt og ganske nøyaktig. Mål 1 ble oppfyllt.

Jeg målte opp en meter og dyttet manuelt buggsteren mens Arduinoen telte og dumpet transisjoner av sensordata for begge hjulene til PC over seriell. De fysiske målene så ut til å stemme ganske bra fra avstand (ca 4% avvik fra estimert via mål med tommestokk), og målingene var så godt i sync som jeg klarte å dytte buggsteren rett. Mål 2 ble oppfylt.

Jeg laget en metode for å kjøre rett og kalibrere med sensordata i en feedback loop. Pga kraftforskjell mellom motorene måtte det korrigeres forskjellig PWM dutycycle for hjulene i software for å kjøre rett. På slutten av testing og kalibrering kjørte buggsteren 3m rett frem og stoppet innenfor et punkt grovt ca 15cm radius av punktet den var siktet på. (dette var grovkalibrering). Punkt 3 oppfylt som forventet, mer kalibrering senere.
Grunnet stor innlevering i et annet fag ble det ikke tid til mål 4.
Mål for denne uka (25 nov – 1 des):

  1. Bruke sensordata i en feedback loop til å svinge et gitt antall grader.
  2. Koble til IR sensor og bruke denne som stopp-trigger for krasjprevensjon.
  3. Koble til ultralyd sensor for avstandsmåling, få brukbare sensordata, estimere nøyaktighet ved avstander, og klargjøre for sending til Raspberry pi over seriell.
  4. Ta i mot kommandoer for kjøring over seriell fra Raspberry pi og eksekvere disse.
  5. Forbedre metoder (ved å bruke interrupts?) og jobbe på bedre kalibrering av sensordata sampling/tolking og feedback loops for mer nøyaktig navigasjon.

(edit med bilder og muligens video av blind kjøretest fra forrige 2 uker kommer)

Smart car

Smart car – autonom 3-hjuling
Blog post 8.11.2013
Medlemmer av gruppen: Hans-Petter Broz, Lars Køhler, Amir Seltan.

Fremgang til nå:
Vi startet prosjektet med noen gruppemøter med brainstorming for hva vi ville gjøre, hvilke features vi kunne inkludere, og hvordan vi kunne gå frem for å implementere disse.
Vi bestemte oss for å lage et autonomt kjøretøy basert på Buggster, som kunne motta et sted å kjøre til trådløst via en webside, og navigere dit på egenhånd uten mennesklig innblanding.

For høynivå-logikk og kommunikasjon valgte vi en Raspberry Pi. Denne skal inneholde navigasjonslogikk, kartlegge bevegelser og omgivelser, kommunisere med en webserver over wifi, og kommunisere med en Arduino over en seriell-over-USB kobling.
Så langt er mesteparten av kart logikken og grunnleggende navigasjonsfunksjoner implementert i java. Vi har også fått Raspberry Pi til å programmere Arduino.

For lav-nivå logikk, tolking av sensordata og styring av aktuatorer/motorer valgte vi å bruke mikrokontrolleren Arduino. Spesifikt Aruino Mega 2560. Denne skal ta imot kommandoer fra Raspberry Pi om hvor den skal kjøre (waypoints) og oversette det til tid og signalstyrke til motorene. Den skal også håndtere krasj-prevensjon med IR sensorer montert i “hjørnene”, og fra ultralyd sensoren om den ikke får beskjed om å bytte kjørerettning av Rapsberry Pi. Sensordata skal også overføres til Rapsberry Pi over seriell.
Så langt er rammeverk for krasjprevensjon og rammeverk for implementering av navigasjonskommandoer fra Rapsberry Pi klart. Utfylling av disse er avhengig av den fysiske buggster platformen, som har kommet på plass sent pga manglende komponenter. Vi har også klart håndtering av seriell komunikasjon til/fra PC på arduino siden.

For web-komponenten er planen å vise kartdata som sankes inn/bygges av Raspberry Pi, og sende koordinater man skal kjøre til. Enten i sanntid eller nær sanntid. Denne skal være en webside som kjøres på ekstern hardware (ikke i den kjørende platformen) og skal kunne brukes som en vanlig webside. Planen er å bruke MySQL og PHP for implementeringen, og kommunisere med Raspberry Pi via MySQL og/eller TCP/IP pakker.
Så langt har vi en web side i PHP med enkelt rammeverk knyttet mot en fullt funksjonell lokal MySQL server.

Selve den fysiske plattformen er en buggster med 2 uavhengige motorer som drives av en driver, en Raspberry Pi, og en Arduino Mega. Fronthjulet er et enkelt fritt hjul som kan svinge fritt og rulle fritt.
Så langt har vi satt sammen buggster platformen. De siste delene til fronthjulet og selve driverkortet til motorene mottok vi i dag, og dette har begrenset hva vi har fått gjort hittil.

Ny oppdatering kommer sannsynligvis i løpet av neste uke.

Platform
Platform