Monthly Archives: November 2013

Launching 29.november @Parkingsplassen!

Hei!

De siste dagene har vi jobbet med sammensetning av raspberry pi og arduino. Vi har satt opp slik at arduinoene sender til raspberry pi, som lagrer til fil og sender melding til vår mobil med gps signalene. Vi valgte og lagre tempratur målinger og gps signaler hvert minut mens vi sender gps signalene til mobil hvert 5 minutt. Dette fordi det er unødvendig og sende oftere.

Vi har også fått kjørt noen tester, blandt annet på fallskjermene våre. Vi fylte opp en 1.5l flaske med vann, denne vil veie omtrent hundre gram mindre enn selve boksen vår. Det vi gjorde var at vi satte på to fallskjermer, tok flasken med opp i tredje etasje og kastet den ut vinduet. Det virket betraktlig bedre med to fallskjermer enn det gjorde med en.

Sist vi ga oss jobbet vi med gsm modulen. Vi har nå testet og fått den til og sende gps signalene til. Hitill ser alt ut til og funke bra. Kameraene våre filmer og tar bilder, gpsen og tempraturene lagres og meldinger blir mottatt.

20131128_153058

Her går det unna!

Utfordringer vi har møtt idag:

Vi hadde store problemer med å få GSM modulen til å kjøre med en ekstern powered usb hub. Etter mangfoldige timer med testing og research så konkluderte vi med at vi måtte ha GSM modulen på en egen hub. Grunnen til dette er enten at huben vår ikke klarte å levere nok strøm ut om vi hadde for mange enheter koblet til, eller så var det en annen mulighet.

«USB does synchronous communications (synchronous means that bytes are sent out at a constant rate one after another in step with a clock signal tick) and transmits in special packets like a network. Conventional serial ports are typically asynchronous (i.e. “not synchronous”). Just like a network, USB can have several devices physically attached to it, including serial ports. Each device on it gets a time-slice of exclusive use for a short time. A device can also be guaranteed the use of the bus at fixed intervals. One device can monopolize it if no other device wants to use it.”  (http://jeffskinnerbox.wordpress.com/2012/12/05/raspberry-pi-serial-communication/, 28.11.2013 – kl. 17.24) Noe som kan tyde på at om vi har flere enheter på samme busen så er det potensielle problemer med kommunikasjonen.

Vi koblet GSM modulen til sin egen powered usb hub, da ser det ut som det fungerer bra. Så kobler vi resten av utstyret med en usb-splitter. Vi gjorde noen små endringer i koden og ser ut til å være nesten klar for launch!

Det som gjenstår før oppsending:

  • Legge/feste alt av utstyr i boksen.
  • Teipe og knyte fast toppen
  • Spray lakke boksen med signal oransje
  • Fylle opp ballongen med helium og sende den på tur

På bildet under kan du se tanken vi fikk med helium.

20131128_152003

 

 

 

 

 

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)

Snart oppskytning!

Hei!

GPS modulen har blitt byttet ut med en annen Arduino Uno med et ferdig lagd GPS Shield. Ved bruk av TinyGPS++ og SoftwareSerial bibliotekene til Arduino så fungerte det utmerket her. Brukte akkurat det samme programmet på den andre GPS’en, men fikk det ikke til å fungere der.

Her har vi koordinatene og litt annen informasjon fra GPS’en. Om vi ser på disse koordinatene så stemmer de rimelig bra med koordinatene for skolen. Fra kart.kulesider.no:

WGS 84 – desimal: 59.68258, 9.64934

Vi får nå inn GPS koordinater som stemmer, og vi overfører dette til Raspberry PI over serial. Det vi overfører blir skrevet inn i en txt fil på Raspberry PI’en.

Vi har også satt opp tempratur målerne sammen med akselerering, barometer og luftfuktighet. Planen er her at vi setter en sensor inne i boksen (med barometer og tempratur måler) mens den andre tempratur måleren skal måle utenfor boksen.

Akselereringsmåleren måler hvor mye g krefter som trekker i x, y og z retning. Her blir det jo da Z retning som er rett opp og ned, og som er intressant for oss, men samtidig tokk vi med de andre for å se resultatene med henhold til snurring, forflyttning og slikt.

Vi har også satt opp barometeret slik at vi kan få målt forskjellen her og der oppe. Selv om barometeret data sheet sier at det ikke fungerer over 30000fot.

Her er et bilde av det ferdige oppsettet som lagres i en fil på raspberry pi, dette lagres via serial, slik som gps signalene gjør.

Idag fikk vi også utdelt isopor, som vi nå har fått kuttet opp i riktig størrelse og satt sammen med gaffa-teip. Boksen har et innvendig volum på 20cmx20cmx20cm, med en tykkelse på 10cm. Dette burde vært nok til og holde varmen oppe i boksen, så hardwaren ikke fryser. Vi har også fått veid utstyret og boksen. Totalt har vi en vekt på 1.350kg.

20131122_162617

Utregningen på hvor mye ballongen klarer og løfte er også regnet ut. Denne vil ikke være helt hundre prosent, men ganske nær. Dette fordi ballongen har litt forskjellig form i forhold til hvor mye den blåses opp, og samtidig at den utvides en god del. Formelen vi brukte er formelen for å finne volumet av en kule: 4/3*pi*r*r*r.  Vi regner med en radius på 1-1.5m på ballongen(styres av oss), og finner dermed ut at boksen holder fra 0.52-1.76 kubikkmeter. Samtidig fant vi at helium har en løfte evne på 28.2gram pr kubikkfot. Derfor regnet vi om dette ganske grovt til og være 995,7gram pr kubikkmeter.  Vår ballong altså bære fra 0.518-1.752kg. Dette er et stort hopp, men jo mindre vi fyller ballongen her nede, jo lenger opp går den.

20131122_172128

Vi har også fått raspberry’n til og sende melding til vår mobil via gsm utstyret. Det eneste som mangler nå er da og få denne til og sende gps signalet som vi lagrer til fil, noe vi jobber med nå.

Vi testet også fallskjermen vi har fått utdelt ved hjelp av en 0,5l kartong som vi fylte med vann. Vi må fortsatt gjøre flere tester på dette, men resultatet var at kartongen gikk så hardt i bakken at den sprakk, noe vi ble litt bekymret for.

 

Trådløs lader: Testing

Har vært litt sløv med blogginga underveis, så det blir mye back-tracking det her.

Kan jo starte med det viktigste først, som er at testingen av laderen omsider er fullført og at implementeringen av den ser lovende ut.

TrådløsLading_mArduino

Bildet over viser hvordan batteriene etter liten stunds lading kan drifte Arduino (Arduino er koblet i parallell med laderen). Batteriene er gamle og mister spenningen raskt, så vi må  skaffe nye.

 

Nå gjenstår bare å montere receiveren på Bugstern og kjøre en test av hele systemet driftet på batterier, samt vise at laderen fungerer. De fire batteriene leverer noe lavere spenning enn USB forsyningen fra PC’n (ca. 200mV), og jeg er litt usikker på hvilken innvirkning dette vil ha på måleresultatene til sensorene som jo da vil motta litt lavere spenning. Forhåpentligvis vil innvirkningen være neglisjerbar.

 

Om kretsen:

Selve laderen er en induktiv lader, med en rekkevidde på nesten 2 cm., ref datablad:

http://elecfreaks.com/store/download/User-specified.pdf

Transmitteren forsynes med 12V DC-spenning direkte; da holder spenningen over transmitteren seg konstant under påvirkning (Hvis jeg legger til  sikkerhetsmotstander i serie, eller måler strømmen som ledes med et amperemeter, fører motstandene i disse komponentene til spenningsfall over transmitteren når den induserer).

Når den induserer under påvirkning av receiveren, leder transmitteren mer strøm, men nøyaktig hvor mye veit jeg ikke. Det står ikke eksakt hvor mye strøm den tåler i databladet, men de testene jeg har gjort tyder på at den ikke leder urovekkende mye. Har satt en foreløpig øvre grense fra spenningskilden  på ca. 0.75 A. (Hadde i begynnelsen problemer med at maks strøm fra kilden var satt for lav, og det førte til spenningsfall over kretsen.)

Receiveren er koblet  i parallell med batteribeholderen og Arduino. Den gir 5V ut, opp til en viss avstand (ca 10mm), avhenging av lasten.

En veldig enkel krets med andre ord.

 

(Edit) Problem:

Et vensentlig problem nå er at de fire batteriene trekker alt for lite strøm, antageligvis fordi indre motstand i batteriene blir for stor og overspenningen fra receiveren for liten. Med bare 5V fra receiveren klarer ikke batteriene å trekke mer enn 1 – 2 mA. Tatt i betrakting at hvert batteri har en kapasitet på 1800 mAh hver vil det ta flere måneder å lade de.

En test viste meg at spenningen måtte opp til 6 V før batteriene klarte å trekke en akseptabel ladestrøm (200 mA), hvor ladetiden ville begrense seg til et og et halvt døgn, men dette er spenning laderen ikke kan levere.

Eneste mulighet er å redusere antall batterier med én. Vi får da  tre batterier med en samlet spenning på 3.6V. Dette er vesentlig lavere spenning, men likevel nok til å kjøre Arduino. Viktigere erdet  at tre batterier klarer å trekke mellom 300-600mA fra laderen. Ladingen vil derfor ta under et døgn.

 

Moon Buggy uke 46

Vi har offisielt byttet navn på oppgave til Moon Buggy!

Oppdatering uke 46:

Ukes Agenda: Prøve å ta input fra joystick og sende signalene til arduino på bilen.

Det første vi startet med denne uken var å bruke en arduino med analoge inputs fra joystick som skulle styre 4 leds (opp, ned, venstre og høyre). Hovedpoenget med dette var å se om vi klarte dimme leds med verdier hentet fra joysticken.
Vi klarte dette ved hjelp av PWM utganger fra arduino.
DSC_0592

Vidre til neste problem, overføring:
Overføringen av verdiene gjennom alle komponentene er noe vi forventet skulle ta lang tid og det hadde vi rett i.
Vi startet uken med å overføre verdier fra den stasjonære arduinoen til den stasjonære raspberry pien med “Serial”. Deretter overførte vi fra den stasjonære raspberry pien til den andre raspberry pien over lokalt nettverk, til sist fra raspberry pi til arduino med “Serial” igjen.
Dette fikk vi ikke til å fungere, klarte å sende verdiene hele veien, men problemet ble å lese verdiene og bruke de på arduinoen.

Neste forsøk var da å gjøre om overførings protokollen fra raspberry pi til arduinoen.
I2C var svaret. Vi testet litt og fikk det til å fungere når det ble sendt over verdier i en retning ( altså i OPP/NED retning eller VENSTRE/HØYRE retning), problemet dukket opp når vi skulle sende verdiene for begge retningene.

Uken har for få dager så vi bestemte oss for å fortsette neste uke!

Trådløs lader

Ja, da var nok tiden vel moden for min første blog post. Har de siste ukene ekperimentert med en tråløs lader til bilen vår, og meningen var å lage en ladestasjon som bilen selv kunne oppsøke ved behov.  Fordi det begynner å bli litt knapp tid igjen, blir nok dette heller et ‘proof of concept’. Det er flere grunner til dette, bl.a:

  • Receiveren gir lavere spenning enn det hovedbatteriet må ha for å lades.
  • Vi mangler en passende spenningsbooster.
  • Bilens presisjon må bedres betraktelig før den kan finne og treffe ladestasjonen helt på egenhånd.

Vi får se hva vi får til, men i første omgang er planen å bruke den tråløse laderen til å lade 4 1.2V  ladbare AA batterier som kan levere  nok spenning til å drifte Arduinoen. Et 6V hovedbatteri vil drifte motorene, men altså ikke være trådløst ladbart i denne omgang.

Trådløs lader

JoystickBil

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

Målet med oppgaven våres er i hovedsak å lage en nettverkstyrt elektrisk bil med direkte videooverføring.
Vi setter muligens på diverse sensorer slik som;
– Lys-sensor (som skal sette på frontlys hvis det blir for mørkt)
– Distanse-sensor (for sikkerhet slik at den ikke kræsjer)

Vi har arbeidet i det siste med å få kontakt mellom komponentene våres. På den ene siden har vi den stillestående stasjonen våres, med en joystick, en arduino, en raspberry pi og en skjerm. I teorien skal arduinoen hente inn analoge verdier fra joystick’en og sende det videre til raspberry pi’en som igjen skal sende verdiene videre over et lokalt nettverk til raspberry pi’en som sitter på bilen.
Når raspberry pi’en på bilen har mottatt verdiene overfører den dem videre til en arduino som også sitter på bilen. Til slutt sender arduinoen disse verdiene videre via digitale utganger med pwm-støtte til motorene på bilen.

Slik vi har valgt å sende signaler for å styre bilen:
Joystick -> analoge innganger -> arduino -> Serial -> raspberry pi -> lokalt nettverk -> raspberry pi -> serial -> arduino -> digitale utganger (pwm) -> motoren

1471865_10153464562190694_971307354_n

Potensielle problemer:
Et relativt stort problem er overføring over det trådløse nettverket. Når vi testet videooverføringen med nettverks-kabel gitt det relativt feilfritt, men over det trådløse nettverket var det et ganske stort delay på videooverføringen. Det samme gjelder når vi overfører verdiene som skal styre bilen over det trådløse nettverket.

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

Værballong 2013 – Error!

Hei bloggen!

Idag fikk vi utlevert det siste vi trengte av utstyr. Vi jobber nå med å få koblet opp sensorer, gps og koble til  GSM-nettet. Det har oppstått problemer, men vi gir aldri opp! 😀

Vi tror at noe av feilen med GSM-tilkoblingen kan være at Raspberry Pi’en ikke klarer å lever nok strøm. Så i starten av neste uke skal vi skaffe en “powra” usb-hub. Utenom dette hadde vi noen småproblemer med å finne datablad for Multiwii-sensoren og vi fikk ikke noe data levert fra GPS-modulen. Dette skal fikses neste uke!

Blogges

2013-11-08 14.16.30!