Monthly Archives: October 2014

The parts has arrived!!

The new motion sensor named MPU-9150 has arrived! The new motion sensor contains a 3axis gyroscope/accelerometer/magnetometer and is hopefully what solves our “YAW” problem. The new chip has a digital compass that should make it possible to control the rotation axis. Last week we soldered a small circuit on our prototype shield. This circuit contains two optocouplers and a few resistors. The purpose of this circuit is to control the focus and shutter trigger on the camera. This is controlled by two buttons placed on the left handle on the gimbal. We also made a housing for these buttons. The connection to the Arduino-UNO is shown in the previous post named “small update”.

Motion sensor and shield

This week we focus on getting a functional code that serves all expected purposes for our gimbal. Implementing and testing the “compass” part of the motion sensor is our main focus. Trying to implement the joystick function will come next.

Andre oppdatering

Vi er i gang med å lage en Raspberry Pi Controller skrevet i Java. Dette skal være en applikasjon hvor hele systemet skal kunne styres, og brukeren kan velge å styre kameraet manuelt eller la auto-tracking software ta over kontrollen. Live video skal også kunne vises i applikasjonen.

I tillegg skriver vi software til Raspberry Pi, slik at den kommuniserer med Controlleren over nett og en Arduino gjennom serial-port. Raspberry Pi vil da fungere som et slags mellomledd mellom brukergrensesnittet og hardware.

Bildegjenkjenning 2.0

Bildegjenkjenning for Firebot Vi bestemte oss tidlig for at bildegjenkjenning skulle være fremgangsmåten vi bruker for å finne branner (tente lys) i arbeidsområdet. Vi vurderte to alternative plasseringer av kamera: Enten fastmontert med utsyn over hele arbeidsområdet, eller montert på kjøretøyet. Begge alternativer ble utprøvd, og valget falt på kjøretøymontering. Vi kan dermed montere kameraet sammen med slukke/tenne-utstyret. Neste spørsmål ble da: Hvilken kameraløsning skal vi velge? Alternativene var mange, inkludert:

  • GoPro kamera: Lite og hendig, men vanskelig å hente video-strøm fra.
  • Web-kamera: Njaa …
  • Pixy CMUCam: Kameramodul med innebygget bildegjenkjenning. Hadde sikkert vært midt i blinken, men vi har ikke denne modulen tilgjengelig. Dessuten er det ikke mye læring i å bruke ferdigtygd vare …
  • Raspberry Pi kamera-modul: Denne løsningen viste seg å være et naturlig valg, siden vi uansett hadde beregnet å bruke Raspberry Pi (RasPi) til bildegjenkjenningsbiten. I tillegg viste det seg at skolen hadde Raspi-cam tilgjengelig.

Bildegjenkjenning er en komplisert prosess, og tilnærmet umulig å gjennomføre på den tiden vi har til rådighet dersom man ikke bruker et eksisterende bibliotek. Etter en del leting fant vi, som tidligere nevnt OpenCV. OpenCV (Open Source Computer Vision Library: http://opencv.org) er et anerkjent bildebehandlingsbibliotek med mye dokumentasjon og mange artikler og kodeeksempler tilgjengelig på Internett. En annen forutsetning for valg av bibliotek var at det måtte kunne kjøre på RasPi. Vi fant fort ut at dette skulle være greit. Det viste seg også at SD-kortet som fulgte med Pi’en ikke var stort nok for alt vi måtte installere. Et nytt SD-kort ble kjøpt inn, og Raspbian ble installert. Deretter lastet vi ned OpenCV, og satte i gang prosessen med å bygge dette for RasPi. Biblioteket er på totalt 3.8 GB, og Make-prosessen skulle vise seg å ta 13-14 timer, så dette var greit å gjøre hjemme … Vi bruker raspicam for å kontrollere kameraet fra C++. Dette biblioteket måtte også lastes ned og bygges, men det gikk kjappere. Dette biblioteket er basert på C, så ting må gjøres på en litt annen måte enn en die-hard OO-stakkar er vant til. Dette var imidlertid ikke så veldig store utfordringen, siden interaksjonen mot dette biblioteket er relativt liten. For å kommunisere med det Arduino-baserte styresystemet til roboten, bestemte vi oss for å bruke en I2C-buss. Denne bussen bruker et minimum av ledninger mellom nodene, samtidig som den har kapasitet til å håndtere mange noder samtidig. I vårt tilfelle trenger vi ikke mer enn én server og én klient, men I2C er likevel godt egnet. Vi bruker biblioteket WiringPi til å hjelpe oss med denne kommunikasjonen. En spesiell utfordring ved kommunikasjon mellom Arduino og RasPi er at RasPi ikke tåler mer enn 3.3V på inngangene, mens Arduino gjerne trykker ut 5V. Av denne grunn valgte vi å sette opp RasPien som master, og Arduinoen som slave. Dermed er det alltid RasPien som tilfører spenning til bussen, så den er trygg. Eneste betingelse er at Arduinoen aldri setter sine pinner «høye». Hensikten med bildegjenkjenningsfunksjonen er å finne branner i arbeidsområdet til roboten, og deretter sende koordinatene tilbake til Arduinoen. Dette gjøres ved å lete etter områder i kameraets synsfelt som er lysere enn et gitt nivå. Vi prøvde først å lete kun etter områder med flammens farge og intensitet, men dette viste seg å bli for snevert. Selv om denne fremgangsmåten ga lite støy i bildet, ble det rett og slett for få piksler i kameraets synsfelt til at vi kunne se lyset på litt avstand. Løsningen vi endte opp med var å lete etter lys i alle spekterets farger, med lav metning og høy intensitet. Dette matcher flammen og det nærmeste området av lyset bra, men medfører også en del støy i form av gjenskinn fra vinduer eller kunstig lys. RaspiCam kan levere videostrøm eller stillbilder etter behov. Vi har valgt å behandle stillbilder så fort som plattformen tillater. Dette vil si at et nytt bilde blir tatt så snart det forrige er prosessert. Denne fremgangsmåten gir oss en oppdateringsfrekvens på anslagsvis 4-6 bilder i sekundet, når programmet ikke bruker ressurser på å vise bilder til skjerm. Bildeprosesseringen foregår slik:

  • Et frame tas ved hjelp av en kommando som sendes til raspicam. Dette bildet lagres i et objekt av Mat-klassen fra OpenCV. I dette objektet lagres hver fargekanal i sin egen matrise.
  • Funksjonen cvtColor() brukes for å konvertere bildets farger fra RBG (rød-blå-grønn, kartesisk format) til HSV (hue-saturation-value, sylindrisk koordinatsystem). I HSV-området beskrives farger ved hjelp av fargehjulet med en ekstra akse, slik at det utvides til en sylinder. Hue (nyanse) angir farge som en verdi mellom 0 og 179, og angir «vinkelen» i forhold til startpunktet i hjulet. Saturation (metning) angir «hvor ren» fargen er, angitt ved hvor langt fra sentrum vi er. Lavere saturation (nærmere sentrum) betyr større grad av blanding av farger. Value angir intensiteten, og angis ved høyden på sylinderen.
  • En «threshold»-funksjon benyttes for å selektere piksler med intensitet over ønsket nivå. Resultatet av denne funksjonen lagres i en ny matrise i form av binære verdier, dvs. svarte eller hvite piksler.
  • Deretter går vi i gang med en filtreringsprosess for å fjerne mest mulig støy før vi prøver å finne konturer. Denne prosessen består av «eroding» og «dilation», hvor dilation forsøker å binde sammen nærstående enkeltpiksler til større samlinger (redusere ujevnheter i kantene av interessante områder), mens eroding har til hensikt å fjerne enkeltpiksler som står for seg selv (støy).
  • OpenCV forsøker deretter å finne konturer i bildet ved å se etter områder med sammenhengende piksler, og lagrer hvert av disse i en vector-liste. For hvert område som finnes beregnes arealet (antall piksler i området), samt tyngdepunktet (senteret av området).
  • Vi prøver å eliminere en del støy ved å bare vurdere områder med minimum 10 piksler. Dersom det finnes flere slike områder i bildet, velger vi det området med sentrum nærmest det punktet som ble valgt i forrige frame. Dermed unngår vi en del tilfeller av at forskjellige konturer velges fra frame til frame.
  • Nå sender vi dette punktet til Arduinoen via I2C-bussen som et punkt med verdier mellom (0, 0) og (255,255) hvor (0,0) er øvre venstre hjørne av synsfeltet og (255,255) er nedre høyre hjørne. Vi har valgt å lage en protokoll der vi først sender 3 kjente bytes for å indikere starten av en melding, før x og y-koordinatene sendes til slutt. Dette hindrer at vi får byttet om på rekkefølgen dersom en melding ikke kommer frem som den skal.

ImgProcess   Illustration 1: Debug-bilde til venstre viser treff på flammen. Høyre side viser området som matcher nivået vi ønsker.

Det har vært nok av utfordringer i prosessen med å få til bildeprosesseringen. Det har ikke vært bare enkelt å få alle biblioteker og annen software opp og gå på Raspberry Pi, men det gikk til slutt. Da vi endelig hadde fått det meste opp og gå, sa SD-kortet takk for seg. Masse «bad disk-block» ved boot… Dette er spesielt morsomt når det tar 13-14 timer å bygge bare det ene biblioteket. Jeg plugget kortet inn i en Windows-maskin for å se om det var mulig å kopiere det vha. et backup-program som leser blokker direkte fra disken. Dette gikk ikke; «disken er korrupt». Kortet ble imidlertid stående i maskinen en stund mens jeg bannet og svor. Etter ca. en halv time fant jeg ut at jeg skulle prøve igjen, og da fikk jeg kopiert det uten feilmeldinger. Kanskje det var oppvarmingen som hjalp? Kortet ble byttet på garanti, men før jeg tok det nye kortet i bruk, leste jeg en del på nett om andre som hadde hatt lignende opplevelser. RasPi er ganske nøye på hvilke SD-kort den liker eller ikke. http://elinux.org/RPi_SD_cards lister opp en mengde spesifikke SD-kort med informasjon om RasPi liker dem eller ikke. Det første kortet var imidlertid en av de godkjente typene, så jeg fortsatte å lete. En annen ting som mange nevnte var at det ofte oppstod problemer med SD-kort på RasPi dersom strømforsyningen ikke leverte nok spenning. Det er tydeligvis vitalt at spenningen (målt under drift) mellom TP1 og TP2 på RasPi ikke er under 4.75 eller over 5.25 volt. http://elinux.org/RPi_Hardware (under avsnittet «Power Supply Problems») forklarer hvordan spenningen skal måles under drift. File-RPI_Test_Points File-Voltmeter Jeg målte kun 4.6 volt når jeg brukte USB-porten på pc-en som strømkilde, så jeg regner med at det var en medvirkende årsak til at kortet ble ødelagt. Etter dette brukte vi kun en ekstern strømforsyning for å være sikker på at det var nok spenning. Etter å ha lagt tilbake sikkerhetskopien fra det første kortet, virket alt som det skulle. Jeg har imidlertid blitt mer nøye på å ta sikkerhetskopier med ujevne mellomrom … Når RasPi-en blir montert på kjøretøyet, vil vi ikke ha skjerm og tastatur tilgjengelig for å kunne starte bildeprosesseringsprosessen manuelt. Det må derfor startes automatisk når RasPi-en booter opp. Dette er tilsynelatende enkelt nok, og kan gjøres på mange forskjellige måter og ved forskjellige tidspunkter i boot-prosessen. Det som er viktig å tenke på er at prosessen ikke startes for tidlig, dvs. før alle nødvendige ressurser er tilgjengelig. Vi må også huske på å legge inn en mulighet for å avslutte programmet, f.eks. via en tastekombinasjon på tastaturet. Om man glemmer dette, vil man ikke kunne få tilgang til operativsystem-shellet i det hele tatt. Dooh… Vi endte opp med å legge inn en linje i .bashrc i hjemmekatalogen til brukeren «pi» for å starte opp programmet. På denne måten ble det enkelt å debugge oppstarten, siden dette skriptet kjøres hver gang man åpner et nytt terminalvindu (inkludert det første som operativsystemet åpner ved fullført boot). Vi måtte som tidligere nevnt forsøke en del forskjellige fremgangsmåter for å finne et tent lys på litt avstand, men mener nå at dette er i orden. Kommunikasjonen mellom RasPi og Arduino fungerer fint, og vi er nå klare til å implementere dette på kjøretøyet. 2014-10-24 10.08.152014-10-24 10.06.402014-10-24 10.08.28

Plight (Andre oppdatering)

Hei bloggen!

Som vist i det forrige blogginnlegget så var øvre delen av stativet ferdig tegnet i Auto Desk Inventor. Vi har nå fått printet ut delene med 3D printer. Under kan dere se resultatet. deler fra 3D printerdeler fra 3D printer2 deler fra 3D printer1 Her er det ferdig resultatet når alt er montert sammen og geværet er festet på; deler fra 3D printer3 deler fra 3D printer4

Nå som festemekanismen er i orden, begynner vi å kunne se de siste løsningene for åssen vi skal kunne koble alt sammen og få til kommunikasjonen mellom de forskjellige funksjonene. Vi har allerede fått på plass auto-trackingen, og har nå startet å se på styringen med joystick. Dette vil vi komme tilbake til ved senere oppdatering.

Blogges <3

21.10.14

For this session we had to change the burned arduino mega board. At the same time we changed the assembly to be able to add the camera’s servos. After, we tried to get the servos to work asise with the car’s control code. I also made a lifting of the code. A lot of things were not used anymore and I made  libraries to use the car. It is Object Oriented Developed.

To finish I was able to control the car with my smartphone using an app called “Bluetooth Serial Controler” (android).

Robothund – Fjerde Oppdatering (23.10.2014)

Hallo!

Denne perioden har vi fokusert på å fikse “små tingene” som må på plass for at roboten skal fungere.

Wi-Fi har vært første prioritet, hvor vi har prøvd og testet lenge for å få dette til å fungere bra. Dessverre har vi ikke kommet noe sted med eduroam, men istedet har vi skaffet en egen router. Dette gjør at vi kan koble oss opp til Raspberry Pi’en ved bruk av VNC viewer. Da slipper vi endelig å måtte koble til skjerm, tastatur og mus. Da trenger vi egentlig bare spenningsregulatoren for å få den fullstendig trådløs.

Videre har vi bestilt Lego tannstagene vi mangler for optimal heising. Forhåpentligvis ankommer de innen en uke.

I tillegg har vi testet kamera, for å se om det er noe som kan være passende til vår robot. Raspberry Pi Camera kobles direkte inn på Raspberry Pi’en, slik at man da kan skrive en relativt enkel kode for å få kameraet til å ta bilder/vise video. På bildet under ser vi Kristian med kameraet rettet mot Anders, som da gir et bilde på skjermen! For at dette skal kunne sende over VNC viewer, blir vi nødt til å finne ut en måte å strømme videoen på. Dette er da noe vi må jobbe med fremover.

Raspberry Pi Camera Test
Raspberry Pi Camera Test

Vi snakkes! 🙂

Things are coming together

Since we are going to use a joystick to overwrite the cameras position, we have decided we are going to place it on one of the handles. Therefore, we wanted to design a case for the joystick and 3D-print it, we had to make sure we could fit the case on the handle, while still being able to move the joystick. The result is seen in the image under.

pot case

Since the start of the project, we have been trying to make a arduino code. While doing so we encountered some problems, using the gyroscope for longer duration made it inaccurate. To resolve this we are using a kalman filter, which uses a percentage of the accelerometer to make it more accurate over time. Another problem is that our gyro sensor does not include a magnetometer, we have ordered a new gyro sensor but we are waiting for the shipping.

During the last week, the gimbal were painted black and the servos have been mounted. The next week we are going to make our arduino code better and do some testing.

gimbal

Uke 40 – Den sjette uken

I løpet av denne perioden har vi omprogrammert akselerometeret for å kompansere med gyro sensoren slik at vi får vinkelhastigheten via akselerometeret. Dette tok sin tid, og vi fant ut at det ikke var praktisk mulig å gjøre dette. Først pga. støy og at ut verdiene ikke var nøyaktige nok.

Dermed måtte vi tilbake til tegnebrettet, og fant da ut at vi måtte bruke PID hvor Inputen er vinkelen vi har og pådraget regnes ut av PID algoritmen. Derfor satt vi som mål å få avlesninger fra akselerometeret oppgitt i grader og ikke vinkelhastighet. Deretter måtte vi kalibrere sensoren, slik at sensoren leste 90* ved loddrett tilstand. Dette holdt ikke i og med at vi hadde mye støy som førte til feilsignaler innimellom. Dette gjorde at vi trengte litt research på filter for reduksjon av støy.

Dermed fant vi ut at vi trengte noen støyfilter i systemet vårt for å forhindre støyen på ut signalet, som har oppstått tidligere.

Vi la til 2 filtre til å begynne med, en som heter EMA og den andre SMA. Disse filterene ga oss litt mindre støy men vi er ikke helt fornøyde med utverdien.

Derfor bestemte vi oss for å lese oss opp på kalman filteret i og med at vi hadde hørt at det kunne løse problemet vi har.

Vi startet også å regne ut og bestemme verdier for konstantene våre i PID algoritmen, ved å velge en rekke med avvik fra den ønskede verdien (roboten i balanse, eller 90 grader) samt at vi skrev en ordentlig forklaring på PID regulatoren:

PID KP

pid full

pidfull2

 

Uke 39 – Den femte uken

Denne uken har vi prøvd å kjøre “segwayen” ved hjelp av en app til telefon som heter så mye som sensoduino. Appen gir oss mulighet til å bruke sensorene som er integrert i telefonen som en del av systemet vårt, slik at vi kunne prøve å kjøre den uten å ha fått gyroskop levert ennå. Dette viste oss at vi vil få et delay fra telefon til systemet som blir for stort slik at kjøretøyet ikke rekker å reagere før det er for sent.

sensoduinio

Resten av uken gikk til å finskrive koden, samt dokumentere arbeidet vårt.