Rpibot - Om læringsrobotikk: 9 trinn

2024 Forfatter: John Day | [email protected]. Sist endret: 2024-01-30 11:20

Jeg er en innebygd programvareingeniør i et tysk bilfirma. Jeg startet dette prosjektet som en læringsplattform for innebygde systemer. Prosjektet ble kansellert tidlig, men jeg likte det så godt at jeg fortsatte på fritiden. Dette er resultatet…

Jeg hadde følgende krav:

• Enkel maskinvare (fokus er programvaren)
• Billig maskinvare (ca 100 €)
• Kan utvides (noen alternativer er allerede en del av beskrivelsen)
• Forsyningsspenning for alle komponenter fra en enkelt 5V kilde (powerbank)

Det var egentlig ikke et mål bortsett fra å lære. Plattformen kan brukes til læring, overvåking, robotkonkurranser, …

Det er ikke en nybegynneropplæring. Du trenger litt grunnleggende kunnskap om:

• Programmering (Python)
• Grunnleggende elektronikk (for å koble moduler sammen med riktig spenning)
• Grunnleggende kontrollteori (PID)

Til slutt vil du sannsynligvis møte problemer som jeg gjorde. Med litt nysgjerrighet og utholdenhet vil du gå gjennom prosjektet og løse utfordringene. Koden min er så enkel som mulig, og de kritiske kodelinjene blir kommentert for å gi hint.

Den komplette kildekoden og filene er tilgjengelig her:

Rekvisita:

Mekanikk

• 1x kryssfinerplate (A4 -størrelse, 4 mm tykk)
• 3x M4 x 80 Skrue og mutter
• 2x girmotorer med sekundær utgangsaksel for encoder. Hjul.
• 1x gratis hjul

1x Pan og tilt kamera montering (valgfritt)

Elektronikk

• 1x Raspberry Pi Zero med topptekst og kamera
• 1x PCA 9685 servokontroll
• 2x optisk giverhjul og krets
• 1x hunkabel for kvinner
• 1x USB powerbank
• 1x DRV8833 dobbeltmotor driver
• 2x Micro servos SG90 for kamerapanel og tilt (valgfritt)
• 1x MPU9250 IMU (valgfritt)
• 1x ultralydavstandssensor HC-SR04 (valgfritt)
• 1x perforert brett og loddetråd, hoder, …

Trinn 1: Bygg chassiset

Jeg er ikke en god mekaniker. Prosjektmålet er ikke å bruke for mye tid i chassiset. Uansett definerte jeg følgende krav:

• Billige materialer
• Rask montering og demontering
• Kan utvides (f.eks. Plass til ekstra sensorer)
• Lette materialer for å spare energi for elektronikken

Et enkelt og billig understell kan være laget av kryssfiner. Det er enkelt å bearbeide med en fresag og en håndborer. Du kan lime små tredeler for å lage holdene til sensorer og motorer.

Tenk på utskifting av defekte komponenter eller elektrisk feilsøking. Hoveddelene bør festes med skruer for å være utskiftbare. En varm limpistol kan være enkel, men sannsynligvis ikke den beste måten å bygge et chassis … Jeg trengte mye tid på å tenke på et enkelt konsept for enkelt å demontere delene. 3D -utskrift er et godt alternativ, men kan være ganske dyrt eller tidkrevende.

Gratishjulet er endelig veldig lett og enkelt å montere. Alternativene var alle tunge eller fulle av friksjon (jeg prøvde et par av dem før jeg fant det siste). Jeg måtte bare kutte en avstandsstykke i tre for å gjøre det halefrie hjulet jevnt etter montering av hovedhjulene.

Hjulegenskaper (for programvareberegninger)

Omkrets: 21, 5 cm Pulser: 20 pulser/omdreining Oppløsning: 1, 075 cm (endelig 1 puls er omtrent 1 cm, noe som er enkelt for programvareberegninger)

Trinn 2: Elektronikk og ledninger

Prosjektet bruker forskjellige moduler som vist på diagrammet.

Raspberry Pi Zero er hovedkontrolleren. Den leser sensorene og styrer motorene med et PWM -signal. Den er koblet til en ekstern PC med wifi.

DRV8833 er en dobbeltmotor H-bro. Den leverer tilstrekkelig strøm til motorene (som Raspberry Pi ikke kan gjøre da utgangene bare kan levere noen mA).

Den optiske koder gir et firkantet signal hver gang lyset går gjennom koderhjulene. Vi vil bruke HW -avbruddene til Raspberry Pi for å få informasjonen hver gang signalet veksler.

PCA9695 er et servokontrollkort. Den kommuniserer med en I2C seriell buss. Dette kortet leverer PWM -signaler og forsyningsspenning som styrer servoene for panorering og vipping av kammen.

MPU9265 er en 3-akset akselerasjon, 3-akset vinkelrotasjonshastighet og 3-akset magnetisk flussensor. Vi vil bruke det hovedsakelig for å få kompasset kurs.

De forskjellige modulene er alle koblet sammen med jumper wire. Et brødbrett fungerer som en sender og gir forsyningsspenninger (5V og 3.3V) og grunnlag. Tilkoblingene er alle beskrevet i tilkoblingstabellen (se vedlegg). Å koble 5V til en 3.3V -inngang vil trolig ødelegge brikken din. Vær forsiktig og sjekk alle ledningene dine to ganger før du leverer (her må koderen spesielt vurderes). Du bør måle hovedspenningen på forsendelseskortet med et multimeter før du kobler til alle kortene. Modulene ble festet med nylonskruer i kabinettet. Også her var jeg glad for å få dem fikset, men også flyttbare i tilfelle feil.

Den eneste lodding var endelig motorene og brødbrettet og topptekstene. For å være ærlig, liker jeg hoppetrådene, men de kan føre til løs forbindelse. I noen situasjoner kan noen programvareovervåking støtte deg i å analysere tilkoblingene.

Trinn 3: Programvareinfrastruktur

Etter å ha oppnådd mekanikken, vil vi sette opp noen programvareinfrastruktur for å ha komfortable utviklingsforhold.

Git

Dette er et gratis og åpent kildeversjonskontrollsystem. Den brukes til å administrere store prosjekter som Linux, men kan også enkelt brukes til små prosjekter (se Github og Bitbucket).

Prosjektendringene kan spores lokalt og også skyves til en ekstern server for å dele programvare med samfunnet.

De viktigste kommandoene som brukes er:

git -klon https://github.com/makerobotics/RPIbot.git [Få kildekoden og git -konfigurasjonen]

git pull origin master [få det siste fra fjernlageret]

git status [få statusen til det lokale depotet. Er det noen filer endret?] Git logg [få listen over forpliktelser] git add. [legg til alle endrede filer på scenen som skal vurderes for neste forpliktelse] git commit -m "comment for commit" [forplikt endringene til det lokale depotet] git push origin master [push all commits to the remote repository]

Hogst

Python tilbyr noen innebygde loggfunksjoner. Programvarestrukturen bør allerede definere alt loggerammeverk før du starter videre utvikling.

Loggeren kan konfigureres til å logge med et definert format i terminalen eller i en loggfil. I vårt eksempel er loggeren konfigurert av webserverklassen, men vi kan også gjøre det på egen hånd. Her setter vi bare loggingsnivået til DEBUG:

logger = logging.getLogger (_ navn_)

logger.setLevel (logging. DEBUG)

Måling og plotting

For å analysere signaler over tid, er det beste å plotte dem i et diagram. Siden Raspberry Pi bare har en konsollterminal, vil vi spore dataene i en semikolonseparert csv -fil og plotte den fra den eksterne PCen.

Den semikolonseparerte sporfilen genereres av vår viktigste pythonkode og må ha overskrifter som dette:

tidsstempel; yawCorr; encoderR; I_L; odoDistance; ax; encoderL; I_R; yaw; eSpeedR; eSpeedL; pwmL; speedL; CycleTimeControl; wz; pwmR; speedR; Iyaw; hdg; m_y; m_x; eYaw; cycleTime

1603466959.65;0;0;25;0.0;-0.02685546875;0;25;0;25;25;52;0.0;23;0.221252441406;16;0.0;0;252.069366413;-5.19555664062;-16.0563964844;0;6; 1603466959.71;0;0;50;0.0;0.29150390625;0;50;0;25;25;55;0.0;57;-8.53729248047;53;0.0;0;253.562118111;-5.04602050781;-17.1031494141;0;6; 1603466959.76;0;-1;75;0.0;-0.188232421875;1;75;2;25;25;57;0;52;-24.1851806641;55;0;0;251.433794171;-5.64416503906;-16.8040771484;2;7;

Den første kolonnen inneholder tidsstempelet. Følgende kolonner er gratis. Plotteskriptet kalles med en liste over kolonner som skal plottes:

ekstern@pc: ~/python rpibot_plotter -f trace.csv -p speedL, speedR, pwmL, pwmR

Plottskriptet er tilgjengelig i verktøymappen:

Plotteren bruker mathplotlib i Python. Du må kopiere den til PCen.

For mer komfort kalles python -scriptet av et bash -script (plot.sh) som brukes til å kopiere Raspberry Pi -sporingsfilen til den eksterne PCen og ringe plotteren med et signalvalg. Bash -scriptet "plot.sh" spør hvis filen må kopieres. Dette var mer praktisk for meg i stedet for å kopiere manuelt hver gang. "sshpass" brukes til å kopiere filen fra Raspberry Pi til den eksterne PCen via scp. Den er i stand til å kopiere en fil uten å be om passordet (den blir sendt som en parameter).

Til slutt åpnes et vindu med tomten som vist på bildet.

Fjernkommunikasjon

Utviklingsgrensesnittet til Raspberry Pi er SSH. Filer kan redigeres direkte på målet, eller kopieres av scp.

For å kontrollere roboten kjører en webserver på Pi, som gir kontroll via Websockets. Dette grensesnittet er beskrevet i neste trinn.

Sett opp Raspberry Pi

Det er en fil som beskriver oppsettet av Raspberry Pi i "doc" -mappen i kildekoden (setup_rpi.txt). Det er ikke mange forklaringer, men mange nyttige kommandoer og lenker.

Trinn 4: Brukergrensesnittet

Vi bruker den lette Tornado -webserveren til å være vert for brukergrensesnittet. Det er en Python -modul som vi kaller når vi starter robotstyringsprogramvaren.

Programvarearkitektur

Brukergrensesnittet er bygd av følgende filer: gui.html [Beskrivelse av kontroller og layout på nettsiden] gui.js [Inneholder javascript -koden for å håndtere kontrollene og åpne en websocket -tilkobling til vår robot] gui.css [Inneholder stiler for html -kontrollene. Posisjonene til kontrollene er definert her]

Nettkontaktkommunikasjonen

Brukergrensesnittet er ikke det kuleste, men det gjør jobben. Jeg fokuserte her på teknologier som var nye for meg som Websockets.

Nettstedet kommuniserer med robotens webserver av Websockets. Dette er en toveiskommunikasjonskanal som vil forbli åpen når tilkoblingen ble startet. Vi sender robotens kommandoer via Websocket til Raspberry Pi og får informasjon (hastighet, posisjon, kamerastrøm) tilbake for visning.

Grensesnittoppsettet

Brukergrensesnittet har en manuell inngang for kommandoene. Dette ble brukt i begynnelsen for å sende kommandoer til roboten. En avmerkingsboks slår kamerastrømmen av og på. De to glidebryterne styrer kamerapanelet og vippingen. Den øvre høyre delen av brukergrensesnittet styrer robotens bevegelse. Du kan kontrollere hastigheten og målavstanden. Den grunnleggende telemetriinformasjonen vises på robottegningen.

Trinn 5: Programmering av robotplattformen

Denne delen var hovedmålet med prosjektet. Jeg refaktorerte mye av programvaren da jeg introduserte det nye chassiset med likestrømsmotorene. Jeg brukte Python som programmeringsspråk av forskjellige årsaker:

• Det er Raspberry Pi hovedspråk
• Det er et språk på høyt nivå med mange innebygde funksjoner og utvidelser
• Det er objektorientert, men kan også brukes til sekvensiell programmering
• Ingen kompilering eller verktøykjede nødvendig. Rediger koden og kjør den.

Hovedprogramvarearkitektur

Programvaren er objektorientert, delt inn i noen få objekter. Min idé var å dele koden i 3 funksjonelle blokker:

Sense Think Actuate

Sense.py

Hovedsensorinnsamling og -behandling. Dataene lagres i en ordbok som skal brukes i det følgende trinnet.

Control.py

En aktiveringsunderklasse styrer motorer og servoer etter litt abstraksjon. Hovedkontrollobjektet håndterer kommandoer på høyt nivå og også kontrollalgoritmene (PID) for motoren.

rpibot.py

Dette hovedobjektet er å administrere Tornado -webserveren og installere sanse- og kontrollklassene i separate tråder.

Hver modul kan kjøres alene eller som en del av hele prosjektet. Du kan bare registrere og skrive ut sensorinformasjonen for å kontrollere at sensorene er riktig tilkoblet og gir riktig informasjon.

PID -kontrollen

Første oppgave er å finne ut hva vi vil kontrollere. Jeg begynte med å prøve å kontrollere stillingen, som var veldig kompleks og ikke hjalp så mye.

Til slutt vil vi kontrollere hvert hjulhastighet og også robotretningen. For å gjøre det må vi kaskade to kontrolllogikker.

For å øke kompleksiteten trinn for trinn, bør roboten kontrolleres:

åpen sløyfe (med konstant kraft)

pwm = K

legg deretter til close loop -algoritmen

pwm = Kp.speedError+Ki. Integration (speedError)

og til slutt legge til retningskontrollen som et siste trinn.

For hastighetskontrollen brukte jeg en "PI" -kontroll og "P" bare for gjevingen. Jeg angir parametrene manuelt ved å eksperimentere. Sannsynligvis kan mye bedre parametere brukes her. Målet mitt var bare en rett linje, og jeg fikk det nesten. Jeg opprettet et grensesnitt i programvaren for å skrive noen variabler av brukergrensesnittet. Innstilling av parameteren Kp til 1.0 krever følgende kommando i brukergrensesnittet:

SET; Kp; 1.0

Jeg kunne sette P -parameteren akkurat lav nok til å unngå overskudd. Den gjenværende feilen blir korrigert med I -parameteren (integrert feil)

Det var vanskelig for meg å finne ut hvordan jeg skulle kaskade begge kontrollene. Løsningen er enkel, men jeg prøvde mange andre måter før … Så til slutt endret jeg farten for hjulene for å snu i den ene eller den andre retningen. Å endre hastighetskontrollutgangen direkte var en feil da hastighetskontrollen prøvde å fjerne denne forstyrrelsen.

Brukt kontrolldiagram er vedlagt. Den viser bare venstre side av robotkontrollen.

Trinn 6: Sensorkalibreringene

Det første du må vurdere er at hele IMU må fungere skikkelig. Jeg bestilte 3 deler og sendte dem tilbake til jeg hadde en full fungerende sensor. Hver tidligere sensor hadde noen deler av sensoren som ikke fungerte som den skal eller ikke i det hele tatt. Jeg brukte noen eksempelskript for å teste det grunnleggende før jeg monterte det i roboten.

IMU -sensorsignalene må kalibreres før du bruker dem. Noen sensorsignaler er avhengig av monteringsvinkel og posisjon.

Akselerasjon og rotasjonshastighet kalibreringer

Den enkleste kalibreringen er for langsgående akselerasjon (A_x). Ved stillstand bør det være rundt 0 m/s². Hvis du roterer sensoren riktig, kan du måle tyngdekraften (rundt 9, 8 m/s²). For å kalibrere a_x må du bare montere den riktig og deretter definere forskyvningen for å få 0 m/s² ved stillstand. Nå er A_x kalibrert. Du kan få forskyvningene for rotasjonshastighetene på en lignende måte i stillstand.

Magnetometerkalibreringen for kompasset

En mer kompleks kalibrering er nødvendig for magnetfeltsensorene. Vi vil bruke m_x og m_y for å få magnetfeltet i det horisontale nivået. Å ha m_x og m_y vil gi oss muligheten til å beregne en kompassretning.

For vårt enkle formål vil vi bare kalibrere avviket av hardt jern. Dette må utføres ettersom sensoren er i sluttposisjonen, ettersom den er avhengig av forstyrrelser i magnetfeltet.

Vi registrerer m_x og m_y mens vi snur roboten rundt z-aksen. Vi plotter m_x vs m_y i et XY -diagram. Resultatet i en ellipse som vist på bildet. Ellipsen må være sentrert til opprinnelsen. Her vurderer vi maksimums- og minimumsverdiene til m_x og m_y for å få forskyvningene i begge retninger. Til slutt sjekker vi kalibreringen og ser at ellipsen nå er sentrert.

Kalibrering av mykt jern vil bety at vi endrer bildet fra en ellipse til en sirkel. Dette kan gjøres ved å legge til en faktor på hver senorverdi.

En testrutine kan nå kodes for å kalibreres på nytt eller i det minste for å kontrollere at sensorene fremdeles er kalibrert.

Kompasset går

Magnetometerdataene vil nå bli brukt til å beregne kompassets retning. For dette må vi konvertere m_x og m_y signalene til en vinkel. Python leverer direkte math.atan2 -funksjonen som har dette målet. Den komplette beregningen er definert i filen mpu9250_i2c.py ("calcHeading (mx, my, mz)").

Trinn 7: Alternative design

Prosjektet tok mye tid ettersom designet var helt åpent. For hver komponent laget jeg noen prototypeimplementering og opplevde grensene for systemet.

Det mest komplekse temaet var hjulkoderen. Jeg testet 3 forskjellige alternativer før jeg fant den optiske koderen som brukes. Jeg tror at de avbrutte løsningene også er veldig interessante i et slikt prosjekt. Det angår delene der jeg lærte mest.

Kontinuerlig rotasjonsservo koblet til pca 9695

For å unngå en ekstra H-bro for en likestrømsmotor, begynte jeg først med kontinuerlige rotasjonsservoer. Disse ble drevet av den allerede tilstedeværende pca 9695 servodriveren. All fremdriftsmekanikk og korrespondentelektronikken var mye enklere. Denne designen hadde to ulemper:

• Servoens dårlige kontrollområde.
• Den manglende plasseringen av koderen

Servoene begynner å bevege seg med 50% pwm og har full hastighet på omtrent 55%. Dette er et veldig dårlig kontrollområde.

Uten en encoder holder, var det veldig vanskelig å finne en ready -to -encoder. Jeg testet 3 forskjellige reflektansgivere som var montert på kabinettet. Jeg teipet et selvlaget encoder -hjul på utsiden av hjulet med svart -hvite seksjoner. Jeg brukte QTR-1RC-sensorene som trenger mye signalbehandling for å få det riktige signalet. Raspberry Pi klarte ikke å utføre den slags sanntidsbehandling. Så jeg bestemte meg for å legge til en NodeMCU D1 mini som en sanntidskontroller til roboten. Den ble koblet til bringebær Pi av den serielle UART for å levere de behandlede sensordataene. NodeMCU administrerte også HC-SR04-sensoren. Mekanikken var vanskelig og ikke veldig robust, serielinjen fikk støy fra I2C-linjen og motorene, så til slutt bygde jeg den andre versjonen av chassiset med enkle gir DC-motorer drevet av en H-bro. Disse motorene har en sekundær utgangsaksel for å plassere en optisk koder.

Trinn 8: Bildebehandling

For å forbedre den autonome kjøringen kan vi lage litt bildebehandling.

Opencv -biblioteket er en referanse for det. Den kan brukes av Python til raskt å implementere hinderdeteksjon.

Vi tar et bilde og bruker noen bildebehandlingsoppgaver:

De første testene ble gjort med Canny og Sobel transformasjoner. Canny kan være en god kandidat, men er ikke fornuftig nok. Sobel er for fornuftig (for mange objekter oppdaget).

Til slutt laget jeg mitt eget filter for å blande alle de horisontale og vertikale gradientene (oppdag møbler):

• Gjør fargebildet om til et grått nivåbilde
• Gjør bildet uskarpt for å fjerne liten støy
• Terskel for bildet til et svart -hvitt -bilde
• Nå oppdager vi horisontale og vertikale gradienter for å oppdage objekter som vegger og møbler
• Vi filtrerer bare de store gjenværende konturene (se fargede konturer på bildet)

Nå kan vi bruke denne nye informasjonen til å oppdage hindringer …

Trinn 9: Neste trinn …

Nå har vi en enkel robotplattform med sensorer, aktuatorer og et kamera. Målet mitt er å bevege meg autonomt og gå tilbake til stasjonen uten å legge til flere sensorer. For dette trenger jeg følgende trinn:

• Sensorfusjon av gjev og magnetiske kurssignaler
• Kamera bildebehandling (bare lav CPU tilgjengelig for det)
• Kollisjonsdeteksjon (ultralydavstand og kamera)
• Kartbygging eller orientering

Gå nå og lag dine egne utfordringer eller mål …