Monthly Archives: December 2013

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.

Navigasjon og oppsummeringspost for Bugster

Hei bloggen!

I dag skal vi skrive om navigasjonssystemet vi har laget for Bugster og noen andre ting som er verdt å nevne før prosjektet avsluttes samt en oppsummering av prosjektet og hvor vi endte.

Utstyrsliste (bilen er satt sammen, men lista beskriver hva man trenger for at navigasjonskoden skal kjøre fornuftig):

  • Arduino Mega
  • IR-sensor til hjul
  • Ultralyd sensor
  • Hjul med enkoderhjul festet på
  • Ledninger, motstander, batteri osv

 

Navigasjon:

For å kort oppsummere hva målet med autopilot delen av Bugster er, så er det: Finne angitt mål, navigere til det angitte punktet og dersom det er hindringer skal den svinge unna, men samtidig jobbe seg nærmere måket. Når angitt punkt er nådd skal bilen stoppe.

Vi kan med glede si at dette har vi fått til! Det er noen scenarioer hvor det ikke vil virke, f.eks hvis bilen må kjøre langs en vegg et stykke før den kan kjøre rundt eller hvis punktet befinner seg bak spissen på et hjørnet. Koden for å gjøre det virker, men IR-sensorene vi skulle bruke for å se om det befinner seg en vegg på siden av bilen drar for mye strøm, så med nåværende hardware spesifikasjoner lar det seg ikke gjøre. Det som fakstisk skjer i slike scenarioer er at bilen vil snu seg mot veggen, se veggen, snu se vegg, snu tilbake, se veggen og fortsette slik til den klarer å kjøre seg helt fast. 🙁

Hvordan virker denne koden? Det er ikke noe poeng i å forklare hver minste variabel, men enkelt forklart så får navigasjon angitt ett punkt den skal kjøre til, en Y verdi og en X verdi. Hver iterasjon av programmet så sjekker navigasjon om den har nådd Y og/eller X (hvis begge er nådd så er den framme), deretter sjekker den  om bilen kjører langs Y eller X og om den skal fortsette med det. Hvis den kjører feil retning på aksen sin, eller om den har nådd verdien på denne aksen så finner den ut om den skal kjøre til høyre eller til venstre ved å se på verdien til aksen som befinner seg vinkelrett på nåværende akse. F.eks hvis angitt mål er 1,5m Y,  1,5m X og den kjører langs X aksen og når X så finner den ut at den skal svinge til venstre for å kjøre riktig retning langs Y aksen. Når et mål angis så taes det utganspunkt i at (positiv) Y verdi er foran retningen bilen ser der og da, og at (positiv) X verdi er til høyre.
Når bilen kjører så vil IR-sensorer som ser på hjulene sende interrupt hver gang den blir “rising”, da vet vi at bilen har kjørt nye x meter. navigasjonen vil da se om bilen kjører positiv eller negativ retning på aksen sin og legge til/trekke fra verdien på distanse kjørt på den aksen. Når en distanse kjørt på en akse er lik angitt distanse i målpunktet så vil bilen svinge til neste akse.

Hva skjer hvis det står en hindring i veien? I arduino sketchen som kjører hele sullabitten sjekker den ultralyd sensoren for å se avstanden til eventuelle objekter, dersom denne avstanden er mindre enn en halv meter vil den si ifra til navigasjonen om at det må skje en unnvikelse. Da sjekker navigasjonen om målet på den andre aksen er til høyre eller venstre for også svinge dit. Det er her IR-sensorer på sidene ville hindret bilen i å svinge mot en ny vegg/hindring hvis de hadde vært oppe og gått.

Enda kortere oppsummert? Bilen vet hvilken retning den peker, hvilken retning angitt X og Y er og den finner hvilke retning den bør kjøre til enhver tid. Hindringer fører til bytte av retning mot den andre vedien.

Vi har brukt et oppgradert bibliotek til ultralydsensoren, som heter newPing. Dette har støtte for blant annet timer interrupts slik at vi kan “polle” ved gitte intervall når vi måler avstand, vi bruker 24micro sekunder.

Oppsummering av prosjektet:

Prosjektet har gått ganske greit, vi har justert på kravene underveis for å komme i mål:

  • Navigasjons programmet kjøres nå på en arduino mega, og ikke på en raspberry pi som var originalplanen, dette fører til at vi bare kan ha ett mål i stedet for flere check points pga lite minne.
  • Vi droppa ir sensorer på sidene da disse fikk  resten av systemet til å knele da de fikk strøm, selv uten å legge de til i koden som kjørte eller å koble de til arduinoen(!)
    Mer feilsøking peker på at problemet var tomt batteri, men vi måtte fokusere på andre ting.

Ellers har det vært lærerikt.

Koden for prosjektet finner du her.

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

Siste update Moon Buggy

Hei bloggen!
Det er siste dag før innlevering / framføring og dokumentasjon er nødvendig. Vi bestemte oss derfor for å lage en post der vi tar for oss veien fra idé til et produkt.

Det hele startet med en idé om å lage en bil som skal styres med en analog joystick, og et kamera som gjør det mulig å styre bilen uten visuell kontakt. Det skal også implementeres sikkerhetsfunksjoner som gjør at systemet skal kunne overskrive den manuelle styringen hvis det er potensielle kollisjons muligheter.

I dag er det siste dag med prosjektet og produktet er så ferdig som det kan få blitt.
1424526_10153556459135694_1214329893_n

Utstyr:
– Analog joystick
– Arduino nano
– 2x Raspberry pi
– Trådløs router
– Arduino mega
– Raspberry pi kamera
– 2x wifi dongles
– “12v batteri” (8x 1,5v batterier i serie kobling)
– 9v batteri
– 5v batteri
– Mosfet
– Lys sensor
– IR sensor
– Bilen med 2x motorer og motor driver
– div kabler
– LCD skjerm

PROBLEMER:
Det første problemet vi møtte var i2c overføringen fra Arduino 1 til Raspberry pi 1. Problemet var at vi måtte sende over to bytes per overføring, men i2c støtter bare en byte. Neste problem var den trådløse kommunikasjonen mellom Raspberry pi’sa. Vi bestemte for å overføre verdiene over socket, men problemet utartet seg når vi sendte to verdier. Når vi prøvde å lagre disse to verdiene på Raspberry pi 2 kunne det oppstå et problem med at verdiene ble byttet om.
Vi har også hatt problemer med video streaming. Problemet er at video overføringen tar for lang tid og dette gjør at det nesten er umulig å styre bilen uten visuell kontakt. Delayet ligger på rundt 3 sekunder, som kan minne om at man styrer en bil som kjører på månen, derav navnet Moon Buggy.
Vi har hatt mangel på strøm til bilen og ikke fått batteriet som vi skulle bruke pga dårlig leveringstid fra DX.com. Derfor må vi bruke et eget batteri til Raspberry pi 2 som vi må bære ved siden av bilen fordi batteriet er for tungt.

1463168_10153556459430694_201778852_n

Signaloverføring:
Overføring moon buggy
For å styre bilen bruker vi en joystick som  gir to verdier. Disse verdiene beskriver joystickens posisjon i x og y retning. Den gir en verdi fra 0 ~ 1024 hvor hvile posisjonen gir en verdi på ca 500. Siden vi bruker i2c busen og denne kun kan sende en og en byte, valgte vi å dele begge verdiene på 4 for å få verdien til max 255. Verdiene sender vi videre i et char array med seks plasser.

For å sende verdiene videre mot bilen valgte vi å bruke et lokalt trådløst nett som er satt opp av en standard router. For å kunne koble Raspberry Pi’sa sammen brukte vi to wifi dongles og en UDP-socket for å kommunisere. For å sende verdiene videre tok vi alle verdiene fra arrayet og satt de i en string  noe som python krevde.1471379_10153556458705694_1808596675_n

Verdiene er nå på den raspberry pi 2 og skal over til arduino 2. Her gjorde vi om stringen til et byte array og satte inn de konverterte tallene. Dette arrayet overførte vi via i2c igjen.

Verdiene er nå mottatt på arduino 2 som skal bruke verdiene til å styre bilen. Siden verdiene er halvparten av maksimums verdien i joystickens hvileposisjon brukte vi en mapping funksjon til å sette nye variable som tar utgangspunkt i hvileposisjonen. Dermed blir hvileposisjonen 0 og alle sidene får en egen verdi som går mot 255 hvis joysticken peker mot denne posisjonen.  Disse verdiene blir brukt til å bestemme spenningen på motorene.

Potensielle utvidelser:
– Flere og sikrere sikkerhetsfunksjoner(flere sensorer til å sikre bilen bedre fra å kollidere, og bedre implementasjon av sikkerhetsfunksjonene)
– Bedre video overføring

Slutt tanker:
Prosjektet har vært veldig hektisk. Det har tatt tid fra planen var lagt til alle komponenter ble mottatt. Hadde vi hatt mer tid så kunne vi klart å finpusse mer på produktet. Prosjektet har vært spennende å jobbe med, men det har vært utfordrende å bare vært datastudenter på grunn av lite elektro erfaring. Det har vært mye nytt å sette seg inn i, noe som har gjort at alt har tatt ekstra tid.

1462948_10153556427975694_48244525_n

Kode:
Kode

Gruppemedlemmer: Ståle Rudin, Henrik Berge Sørum og Martin Stenbro

GOD JUL! 😀

Værballong 2013 – Oppskytning i 2014?

Hei!

Når alt kom til alt ble det ingen oppskytning. Vi hadde testet og fått alt til å funke som et system, både med og uten batteri. Men fredag den 29. november skulle vi ha første oppskytning. Da oppsto det problemer idet vi koblet fra mus og tastatur, GSM-modulen endret enhets-nummer og vi klarte ikke å sende flere meldinger. Etter mye tenking og testing fikk vi ikke sendt opp ballongen denne dagen, men fant ut at vi skulle prøve oss med trådløst tastatur og mus.

På mandag den  2. desember dro vi å kjøpte trådløst tastatur og mus. Koblet dette opp og gjorde nye tester. Alt fungerte når vi skrudde de av og vi trodde vi var klar til oppskytning. Vi bestemte oss så for å skyte opp på tirsdagen for da så værmeldingene bra ut og det var for sent å gjøre det på mandag.

Tirsdag levde vi fortsatt i håpet. Vi koblet opp igjen og testet at alt fungerte, men etter noen få meldinger oppsto det samme problemet. Vi fikke en error i gps-sendings programmet og scriptet sluttet å sende meldinger. Vi fortsatte å jobbe for å fikse problemet. Men etter mye testing og fiksing klarte vi ikke å fikse problemet. Vi prøvde forskjellige programmer og å koble enhetene til et fast nummer, men det hjalp ingenting.

Vi innså da at tiden var for knapp og at vi ikke klarte å fikse problemet før framføringen som er den 6. desember. Det hjalp heller ikke at det var meldt storm hele torsdagen.

Vi gir ikke opp! Selv om faget er avsluttet har vi planer om å jobbe videre mot en oppskytning på nyåret. Vi føler at dette prosjektet trenger et resultat og at vi kan få fikset problemet med litt mer tid.

Koden vi brukte:
https://www.dropbox.com/s/9fokiwfnznlep3w/Kode%20for%20v%C3%A6rballong.rar

Over og ut!

2013-12-03 12.41.04

Trådløs lader – indikasjonslys

Vi tenkte vi skulle ha en indikasjonslampe for å vise når bilen lader. Det virket i utgangspunktet som en rett fram plan; bare plugge inn en LED inn en eller annen plass og så good to go. Men så lett var det ikke…

Første test viste at laderen ikke leverer nok spenning til å få en LED, koblet i serie, til å lyse. Deretter tenkte jeg at en Arduino sikkert lett kunne lese av spenningsøkningen som oppstår når laderen er innenfor rekkevidde, og styre en LED ut i fra dette. Men fordi det er forskyningsspenningen som skal måles og fordi Arduino justerer sin interne referansespenning ut fra hva den forsynes med, kan ikke Arduino selv registrere noen forskjell. Dvs. er forsyningen til Arduino 5V  leses den som 1024, mens er den 4V leses den også som 1024. Så spenningsforskjellen i kretsen var ikke no softwaren kunne ta stilling til direkte. 1024 er alltid verdien til maks spenning, og forsyningsspenningen er jo maks spenning (ganske selvsagt i grunn…).  Det ble klart at det måtte en litt smartere krets til.

Uten navn2Så det jeg gjorde var å lage til en spenningsdelingskrets bestående av dioder og høye motstander fra forskyningen til jord. Dioder holder et tilnærmet konstant spenningsfall over seg uansett spenning i en krets, mens spenningsfallet over vanlige motstander endrer seg proporsjonalt med hvordan spenningen endrer seg. En spenningsdelingskrets med en diode og en motstand vil derfor gi meg et målepunkt mellom de fordi spenningsfallet over dioden er kjent, mens den over motstandene er avhengig av forsyningsspenningen. Fordi spenningsfallet over dioden holder seg konstant blir spenningsforskjellen i målepunktet uproporsjonal med endringen i forsyningsspenningen, og dermed kan Arduino registrere om bilen lader eller ikke.

Oppdatering: Smart Car, Web Server Siden

Nå er web siden ferdig. Vi har en webside med et 2D kart, som er implementert i Mysql, PHP, Apache. Kartet har n kordinater i x, og n kordinater i y retning som vi føreløpig har satt til n=25.

Man kan motta kordinater via et form og endre kordinatene i kartet. Formet er føreløpig til buggtesting. Kartet er fylt opp med “o” som default og det vil si at alle kordinatene har ukjent verdi. Etterhvert som bilen kjører, skal den sende info direkte til databasen med kordinatene og verdiene som skal forandres i kartet.
Vi har valgt å sende verdiene “X” for et hinder og ” ” for fri.
Kartet er en framstilling av hva bilen har funnet og lagret.
Bilen fyller ut kartet etterhvert som den utforsker rommet.

Vi skal sende kordinater som bilen skal kjøre til via serveren.
Da skal bilen selv kjenne igjen alle hindere og prøve å velge den beste ruten.

Funksjonalitet som gjenstår å lage:
Motta kordinater og verdi via TCP/IP.
Sende kommandoer med kordinater som bilen skal kjøre til.

Bugster – En radiostyrtbil?

Hei bloggen!

Vi bestemte oss for at det hadde vært gøy med radiostyring av Bugster, både til feilsøking og underholding, og da Christian hadde en trådløs Playstation2 kontroller liggende fant ut at den skulle brukes.

Utstyrsliste:

  • Trådløsmottaker
  • Playstation2 kontroll
  • Lite breadboard
  • Arduino nano
  • Kontrollerkontakter fra Playstaion2
  • Div kabler
  • To 10k motstander

For å få så stabil og god kontakt mellom trådløsmottaker og Arduino nano som mulig demonterte jeg en Playstation2 og brukte kontrollerkontaktene fra denne, dette blei større enn beregnet da jeg ikke kunne dele disse og bare bruke en (se bilde).

Vi valgte å bruke en dedikert Arduino nano for å ta seg av jobben med å tolkesignalene fra kontrollen og sende disse videre via I2C bus. Dette fører til at systemet kan ansees som en undermodul, dette forenkler feilsøking da alt uten om I2C kan testes uten å blande inn resten av hardware / software til Bugster.

Til software brukte vi biblioteket til Bill Porter, som finnes her: http://www.billporter.info/2010/06/05/playstation-2-controller-arduino-library-v1-0/
Samt en egen loop som samler inn info fra knappene vi bruker, og sender den videre til mega’en.

Vi hadde problemer med støy til å begynne med pga dårlig kabling og generelt rot, men når vi ryddet opp i dette så fungerte ting som det skulle.

Under ser du resultatet:

DSC_0245

Her en video av kjøring med radiostyring.

Nå er vi godt i gang med å koble sammen Bugster og teste navigasjon.