Category Archives: Smart Systems 2013

Blogs from smart systems 2013

Plight (The result)

God kveld bloggen!

Vi begynte ikveld med siste testing før presentasjonen av produktet imorgen. Under kan dere se et par bilder og videoer.  Filmene kan bli litt uklare, da vi har brukt mobil til å filme med.

Her kan dere se noen av resultatene:

test1

 

Blogges!

Plight (The end)

Hei bloggen!

Da har prosjektet kommet til en slutt. Vi er nå inni den aller siste fasen før fremføring i morgen torsdag 04.12.2014.

Den siste tiden  har vi brukt på å finjustere alt av kodingen som har med tracking og joystick å gjøre. Dette har vært en tidkrevende prosess, med mye frustrasjon og feiling for at alt skal kunne fungere perfekt. Dag ut og dag inn har vi testet forskjellige metoder, gjort om på kode og krets osv. Men det er vel noe man må regne med når det blir såpass mange komponenter som skal kunne samarbeide likt.

10834056_10154861059335582_613885827_n

Vi har nå laget schematic view av kretsene. Vi har brukt Orcad Capture for å tegne dette. Dette gir oss muligheten til å konstruere kretskort ved senere anledning om dette er et ønske. Vi kunne startet på denne prosessen, og laget et kretskort, men dette hadde tatt enormt langt tid. For det første måtte vi startet med å lage footprints for alle delene og lagt det inn på PCB Editor. Dette er en prosess som tar mye tid og koster en del penger. Kortet måtte bli sendt til Kina for å bli printet der pluss kjøpt alle komponentene. Fordelen med å bruke et slikt kort er at vi hadde fått betraktelig mindre med kabler og kaos. Alt hadde ligget på et kort og vært koblet der. Så om vi skulle tatt prosjektet videre ville dette vært et veldig godt alternativ å gjøre!

Bildet av schematic view av toppartiet til turreten

10816074_10154861067825582_89791909_n

 

Som vi startet på sist med å legge inn PIR og IR sensorer har vi ikke kommet så alt for mye lengre på dette. Vi har kun fått PIR sensorene til å fungere (Motion tracking), men vi har ikke tid til å gå videre med IR sensorene våre for denne gangen. Men dette vil også vært høyest aktuelt å bli ferdig med om prosjektet skal føres videre og forbedres.

Som sagt imorgen er det fremføring av prosjektet, så resten av dagen blir brukt til å teste og finjustere de siste små detaljene for presentasjonen vår.

Vi blogges!

Plight (Starten på slutten)

Hei bloggen!

Da har turreten tatt noen steg videre i utviklingsfasen. Som vi snakket om i forrige innlegg, skulle vi komme tilbake til dere angående styring med joystick. Vi har fått kjørt en liten test med joystick og dette gikk overraskende bra! Det oppsto et lite problem, da vi skulle styre geværet oppover, samtidig som vi skylle skyte. Da fikk vi en feil på spenningen som gjorde at geværet ikke stoppet å skyte før vi hadde sluppet joysticken og den gikk tilbake i 0. Problemet var at det kom ekstra spenning til triggeren, som gjorde at den bare fortsatte å skyte. Vi har sett litt på problemet og kommet opp med en mulig løsning. Muligheten er å bruke en zenerdiode for å holde spenningen riktig for å unngå å skyte noen uskyldige.

Her kan dere se film av testskyting:

Videre da har vi oppgradert litt på selve konstruksjonen for å gjøre selve turreten mere stabil. Vi har startet med å legge til motion detector sensorer (PIR sensor). Det blir satt ut 4 stk sensorer av dette slaget. En for hver av sidene. Denne sensoren skal kunne oppdage bevegelse. for hver side. Dette gjør at turreten kan operere i 360 graders rotasjon. Den vil automatisk bevege seg til den siden den fanger opp bevegelse. Et lite problem som oppstod under testing av PIR’ene var at de registrerte bevegelse nesten 180 grader rundt seg. Når dette skjer vil ikke sensorene skjønne hvor det er bevegelse siden det kommer fra flere kanter likt. Vi løste dette ved å legge på “vegger” rundt selve sensoren, så den går bare 45 grader ut fra hvert bein på selve konstruksjonen. Da unngår vi problemet med at de skal overstyre hverandre og begynne å surre.

En annen sensor vi har tatt i bruk er en IR sensor. Denne skal kunne oppdage om det er venn eller fiende som kommer inn i skuddsonen. Det som skjer her da er at det er plassert fire IR mottakere rundt konstruksjonen, som skal kunne motta signaler fra en IR sender, som evt en venn går med på seg. Hvis du derimot ikke har denne senderen montert på deg, vil geværet se på deg som en fiende og starte å skyte!

Her er bilde av IR og PIR sensorene. IR er den lille på toppen over PIR.
10822620_10154835083220582_1308615269_n

Vi blogges!

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

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.

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.