Dette er en detaljeret vejledning om, hvordan man realiserer en robot, der starter fra bunden, og giver den mulighed for at navigere autonomt i et ukendt miljø.
Alle de typiske argumenter involveret i robotikken vil blive dækket: mekanik , elektronik og programmering .
Hele roboten er designet til at blive lavet af alle derhjemme uden professionelle (dvs. dyre) værktøjer og udstyr.
Hjernen bordet (dsNav ) er baseret på en Microchip dsPIC33 DSC med encoder og motor controller kapaciteter. Positionen beregnes ved hjælp af kilometertryk (encoder) uden nogen ekstern reference (dead reckoning).
I den endelige version bruges nogle andre controllere til at styre sensorer (Arduino) og til at styre analoge sensorer (PSoC).
forsyninger:
Trin 1: Den grundlæggende platform
Et eksempel på, hvordan man opbygger en meget simpel robotplatform med komponenter og dele, der er nemme at finde overalt, uden behov for professionelle værktøjer eller udstyr, og uden særlig færdigheder på mekaniske værker.
Størrelsen af basen tillader brugen heraf i mange forskellige kategorier af robotkonkurrencer: Stifinder, Line Follower, Can Collector osv.
Trin 2: Hvad vi ønsker at få? og hvor?
Denne robot, som de fleste robotter, der er bygget af hobbysts, er baseret på et differentieret styresystem, som giver os mulighed for at kende roboternes positionskoordinater på et hvilket som helst tidspunkt, blot ved at kende rummet dækket af hvert hjul periodisk med tilstrækkelig præcision.
Dette døde reckoning navigationssystem er påvirket af kumulativ fejl; målepræcisionen skal være høj for at sikre en lille fejlcirkel efter en lang sti. Så efter nogle gode resultater med hjemmebagte kodere besluttede jeg at bruge noget bedre: Et par 12V-200 omdrejningsmomenter, der er forbundet med et par 300 Count Per Revolution (cpr) -kodere, begge tilgængelige i mange internetrobotikbutikker.
Grundlæggende principper
For at fange alle de pulser, der genereres af 300 cpr-encoderen på en 3000 omdr./min. Motor i 4x-dekodningsmetode (120 kHz), har vi brug for dedikeret hardware til hver encoder (QEI = Quadrature Encoder Interface). Efter nogle eksperimenterende med en dobbelt PIC18F2431 fastslog jeg, at den korrekte opgradering er til en dsPIC. Ved begyndelsen var de to dsPIC30F4012 motorstyringer til styring af hjulets position og hastighed, at udføre odometri og at levere data af de to motorer til en dsPIC30F3013. Denne generelle formål DSC er kraftig nok til at få data, lave nogle trigonometri for at beregne positionskoordinater og gemme data relateret til den vej, der er dækket for at få et kort over feltet, alt sammen med en meget høj hastighed.
Når bestyrelsen og programmerne var næsten færdige, bragte Microchip ud en ny, kraftfuld 28-pin SPDIP i dsPIC33F serien til både motorstyring (MC) og generelle (GP) versioner. De er betydeligt hurtigere end dsPIC30F, de har meget mere tilgængelig programhukommelse og RAM (nyttig til feltkortlægning), de kræver mindre strøm (god for en batteridrevet robot), og deres DMA-funktioner simplificerer mange I / O-operationer.
Vigtigst er det, at disse er de første mikrochip-motorstyringer med to QEI'er på samme chip. Lad os starte en ny port igen! Det logisk blokdiagram svarer til den for det foregående bord , men hardware og software er meget enklere siden Jeg kan kun bruge en DSC kun på tre . Der er ikke behov for en højhastighedskommunikation mellem vejleder og motorstyringer til udveksling af navigationsparametre. Hver proces er enkel at synkronisere, fordi den er på samme chip. DsPIC33F-seriens perifere pin valgmuligheder letter PCB'en yderligere, hvilket muliggør en intern forbindelse mellem eksterne enheder og større fleksibilitet.
Dette bringer os til "dsPIC baseret Navigation Control Board" eller dsNavCon for kort. Dette bord er designet som en del af et mere komplekst system. I en komplet explorer robot vil andre bestyrelser styre lyd-, lys-, gassensorer såvel som støddæmpere og ultralydsafstandsfindtere for at finde mål og undgå forhindringer.
Som et frittstående styre, dsNavCon kan også bruges til en simpel "line follower" robot, noget mere komplekst som en robot til en odometry og dead-reckoning konkurrence, eller en såkaldt "can can robot" (for at samle konkurrencer). Der er stadig masser af gratis programhukommelse for at tilføje kode til sådanne opgaver. Med mindre eller ingen ændringer i software kan den også bruges uafhængigt til et fjernstyret køretøj, ved hjælp af det tovejsede RF-modem med en slags smart fjernbetjening. Denne fjernbetjening kan sende komplekse kommandoer som "Flyt FWD 1m", "Drej 15 ° til venstre," "Kør FWD ved 50 cm / s," "Gå til X, Y-koordinater" eller noget lignende.
Brættet og roboten er også designet til at blive lavet af alle derhjemme uden professionelle værktøjer og udstyr.
Trin 3: Åben kilde hardware
Blokdiagram
Navigationsstyringsundersystemet er sammensat af dsNav som systemets "intelligente" bord og et L298-baseret dobbelt H-brokort til styring af de gearede 12V-motorer (Hsiang Neng HN-GH12-1634TR). Motionsfejlbacken kommer fra et par 300 cpr-kodere (US digital e4p-300-079-ht).
Kommunikationen med den eksterne verden udføres gennem de to UART serielle grænseflader; en til telemetri og den anden til at hente data fra sensorkort. XBee-modulet kan tilsluttes UART1 eller UART2 gennem JP1 og JP2-hoppere. J1 og J16 stikkontakter er tilgængelige for andre slags forbindelser. COMM1 port (J16) kan også bruges til en I2C kommunikation takket være den perifere pin valg kapacitet i dsPIC33F serien.
Det oprindelige skematiske diagram i Eagle-format findes her:
http://www.guiott.com/Rino/dsNavCon33/dsNavCon33_Eagle_project/DsPid33sch.zip
Som du kan se, er skematisk så simpelt, at det kan implementeres på et paraply, som jeg gjorde. Hvis du ikke vil bruge dette system og ikke ønsker at realisere dit eget printkort, er en kommerciel bestyrelse baseret på mit oprindelige arbejde og fuldt kompatibelt med min open source software tilgængelig på: http: //www.robot-italy .com / product_info.php? products_id = 1564
Trin 4: Open Source Software
Softwaren er udviklet med MPLAB® gratis IDE og skrevet med MPLAB® C30 compiler (selv i en gratis eller elevversion), begge (selvfølgelig) af Microchip:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=81
Hele projektet er tilgængeligt som open source på Google Code
http://code.google.com/p/dspid33/
Der henvises der til den nyeste version, kommentar, beskrivelser osv.
Programmet beskrives trin for trin inde i koden. For at få et højt niveau af kommentar og en læsbar kode er der ved hvert væsentligt punkt et tal i parentes (fx: 7) som reference til en ekstern fil (dvs.: descrEng.txt) i MPLAB projektet .
Diagrammet viser den overordnede arkitektur i styringsprocedurerne for dsNav board og de navigeringsstrategier, der anvendes på baggrund af projektet.
Motorkontrollerne kan ses som sorte kasser, der tager højde for hjulets hastighed. Vejlederens del af programmet sender dem referencehastigheden (VeldDesX: ønsket hastighed). Mikrocontrollerens Input Capture-moduler får pulser fra dekodere, der er forbundet med motoraksen og udlede motorens rotationshastighed (VelMesX: målt hastighed). Ved at kombinere hver 1ms disse værdier i PID-styringen "Speed PID" opnår vi den rigtige PWM-værdi for at holde den ønskede hastighed for hvert enkelt hjul.
QEI-modulerne (Quadrature Encoder Interface) får både A- og B-pulserne fra koderne og giver tilbage til vejlederfunktionen kørselsretningen og antallet af pulser i 4x-tilstand (tælling af stigende og faldende kanter af signal A og signal B: 2 x 2 = 4).
Multiplication af antallet af pulser med en K, der angiver det rum, der er rejst for hver enkelt encoderpuls, opnår vi den afstand, der tilbagelægges af højre og venstre hjul hver 10ms. Vejlederen kombinerer disse rejseinformationer og anvender den døde beregningsprocedure for at opnå de målte positionskoordinater for bot: Xmes, Ymes ,θMes (orienteringsvinkel).
Vejlederen modtager navigationskommando udefra ved seriel grænseflade (telemetri).
Forskellige strategier kan anvendes:
EN - Kør med en bestemt hastighed i en given retning (VelDes, θDes).
B - Kør mod et givet punkt med koordinater XDes, YDes.
C - Kør for en given afstand i en given retning (DistDes, θDes).
Mode A : Med de "logiske kontrolafbrydere" i position 1 anvendes kun PID-styringen "Angle PID" af tilsynsfunktionerne. Denne kombinerer den ønskede vinkel θDes med den målte vinkel θMes beregnet ved odometry procedure for at opnå værdien af rotationsvinkelhastigheden ω af køretøjet omkring sin lodrette akse, som er nødvendig for at korrigere orienteringsfejlen.
DeltaV's værdi er proportional med ω. Det tilføjes til VelDes for at opnå hastigheden på venstre hjul og trækkes til VelDes for at opnå det rigtige hjuls hastighed for at holde overskriften svarende til θDes værdi, mens robotens centrum stadig kører ved VelDes hastighed.
Mode B : Med de "logiske kontrolafbrydere" i position 2 beregnes den ønskede hastighed VelDes ved hjælp af PID-styringen "Dist PID" og den anvendes som i tilstand A. Den målte indgang for dette PID (DistMes) beregnes som en funktion af de aktuelle koordinater og destinationskoordinaterne. Den ønskede orienteringsvinkel θDes kommer også fra samme procedure, og den bruges som referenceindgang til "Vinkel PID". Referenceindgangen for "Dist PID" er 0, hvilket betyder at destinationen er nået. Med ω og VelDes til rådighed, kører hjulets hastighedsregulering som i tilstand A.
Mode C : Med de "logiske kontrolafbrydere" i position 2 beregnes destinationskoordinaterne Xdes, Ydes en gang i begyndelsen som en funktion af inputparametre DistDes, θDes. Derefter går alt som i tilstand B
Trin 5: Detaljer om software: Hastighedskontrol og andre grundlæggende funktioner
Programmet er fuldt afbryd drevet . Ved opstart, efter initialisering, går programmet ind i en meget enkel main-loop, der fungerer som en statsautomat. I hovedsløjfen kontrollerer programmet flag, der aktiveres af eksterne hændelser, og det går ind i den relative tilstand i henhold til deres værdier.
Da det er en slags en meget simpel kooperativ "Real-Time Operating System , "hver rutine skal udføres på kortest mulig tid, frigør systemet for at tage sig af de meget hyppige afbrydelser.
Der er ingen "vent til" og ingen forsinkelser i koden. Når det er muligt, anvendes afbrydelser, især til langsomme operationer som transmission eller modtagelse af tegnstrenge. UART-kommunikation tager fordel af DMS-funktionerne i dsPIC33F for at spare CPU-tid på at gøre alt det "beskidte" job i hardware.
Periferiudstyr anvendt på dsPIC33FJ128MC802:
- QEI'er til at beregne den rejste sti.
- Input Capture (IC) for at beregne hastigheden.
- A / D-omformere til at læse motorstrømmen.
- Forbedrede PWM'er til at køre motorerne.
- UARTs at kommunikere med den eksterne verden
QEI moduler er vant til at vide, hvor meget hjulene har rejst og i hvilken retning. Denne værdi akkumuleres algebraisk i en variabel hver 1 ms og sendes til supervisorfunktionerne på dens anmodning. Når værdien er sendt, nulstilles variablerne.
Hastigheden måles ved hver giverens puls som beskrevet nedenfor. Hver 1ms beregner den gennemsnitlige hastighed ved hjælp af gennemsnitlige prøver, udfører PID-algoritmen og korrigerer motorens hastighed i overensstemmelse hermed, hvilket ændrer PWM-arbejdscyklus. For en detaljeret beskrivelse af C30 PID bibliotek ansøgning, se Microchip Code Eksempel: CE019 - Brug Proportional Integral Derivative (PID) controllere i Closed-loop Control Systems. http://ww1.microchip.com/downloads/en/DeviceDoc/CE019_PID.zip
Hastighedsvariationer af motorer udføres glat, accelerere eller decelerere med en stigende eller faldende skrå rampe for at undgå tung mekanisk belastning og hjulglidning, der kan forårsage fejl i kilometertrykket. Retardation er hurtigere end acceleration for at undgå støder med forhindringer under bremsning.
IC , indlæsningsmoduler bruges til at måle tiden der er forløbet mellem to impulser, der genereres af koderen, hvilket betyder, at hjulene rejste til en velkendt, fast mængde rum (konstant SPACE_ENC ). Tilsluttet parallelt med QEA (internt til DSC takket være Peripheral Pin Select-funktionerne i dsPIC33F), opfanger de forløbet tid på stigende kant af encodersignaler. TIMER2 bruges i fri løb. Ved hver IC-afbrydelse lagres TMR2s aktuelle værdi, og dens tidligere værdi trækkes fra den; dette er pulsperioden. Så bliver den nuværende værdi den tidligere værdi, afventer den næste afbrydelse. TMR2's flag skal kontrolleres for at vide, om der er sket et overløb i 16-bits registret. Hvis ja, skal forskellen mellem 0xFFFF og den foregående prøve tilføjes til den aktuelle værdi. Prøver tilføjes algebraisk i IcPeriod variabel i henhold til _UPDN bit for at bestemme hastighedsretningen. Dette er en af de foreslåede metoder i Microchip ansøgning note AN545 .
Variabelen IcIndx indeholder antallet af prøver tilføjet i IcPeriod .
Hver 1ms beregnes gennemsnitshastigheden som V = Space / tid
hvor Space = SPACE_ENC • IcIndx
(= plads dækket af en encoderpuls • antal pulser)
og Tid = TCY • IcPeriod
(= enkelt TMR-periode • summation af perioder opstået).
Single_TMR_period = TCY = 1 / Fcy (klokfrekvens).
Så V = Kvel • (IcIndx / IcPeriod)
hvor Kvel = SPACE_ENC • Fcy at have hastighed i m / s.
Skiftende venstre 15 bit Kvel const KvelLong = Kvel << 15 ) hastigheden beregnes allerede i fraktioneret format (også hvis kun heltalsvariabler anvendes) klar til brug i PID-rutinen. Se "descrEng.txt" fil i MPLAB projekt for en mere detaljeret beskrivelse.
A / D konvertere kontinuerligt måle motorer strøm, lagring værdier i de 16 positioner ADCBUF buffere. Når buffere er fulde, opstår der en afbrydelse, og en gennemsnitsværdi beregnes ca. hver 1m.
UART'er bruges til at modtage kommandoer udefra og til at sende resultaterne af målingerne tilbage. Kommunikationsdelen af programmet kører som en statsautomat. Statusvariabler bruges til at udføre handlinger i rækkefølge. Meget enkle og hurtige Interrupt Service Routines (ISR) får eller sætter hver enkelt byte fra eller til en buffer, og indstiller de rigtige flag for at lade den korrekte funktion udføres.
Hvis der opstår nogen form for fejl under modtagelse (UART, checksum, parsingsfejl), er statusvariablen indstillet til et negativt tal, og den røde ledning er tændt for at kommunikere eksternt denne fejltilstand. Se "descrEng.txt" fil i MPLAB projekt for en komplet liste over mulige fejl.
Den protokol, der bruges til håndtrykket, er fysisk lag uafhængigt , og kan også bruges sammen med I2C- eller RS485-bussen.
Det første lag styres af dsPIC perifer grænseflade. Ramme- eller overløbsfejl (UART) eller kollisioner (I2C) opdages af hardware og indstiller det relevante flag.
Det andet lag håndteres af ISR-rutiner. De fylder RX-bufferen med de bytes, der modtages fra grænsefladerne. De registrerer også bufferoverløb og kommandoen overløb.
UartRx eller UartRx2 funktioner administrere tredje lag . Som allerede beskrevet (se også flowdiagrammer) fungerer disse rutiner som en statsautomat, får bytes fra bufferen og dekoderer kommandostrengen.
Byterne udveksles mellem andet og tredje lag (ISR og UartRx-funktion) gennem en cirkulær buffer. ISR modtager en byte, gemmer den i en matrix og øger en pointer til arrayet, hvis markøren når slutningen af arrayet, genstartes den til begyndelsen. UartRx-funktionen har sin egen pointer for at læse det samme array, inkrementeret (også i cirkulær måde), så snart byte er afkodet i den nuværende RX-status. Hovedløkken kalder UartRx-funktionen, når "in" -pegeren adskiller sig fra "ud" -pegeren.
Hver kommandopakke består af:
0 - Header @
1 - ID 0-9 ASCII
2 - Cmd A-Z ASCII
3 - CmdLen N = 1-MAX_RX_BUFF # af bytes følgende (checksum inkluderet)
4 - Data …
…
N-1 - Data
N - Checksum 0-255 opnået ved blot at tilføje i en 8 bit variabel, alle bytes komponerer meddelelsen (selve checksummen ekskluderet).
Dette lag styrer timeout- og checksumfejl samt pakke konsistens (korrekt header, korrekt længde). Hvis alt er ok, muliggør det Parser-rutine (fjerde lag ) for at afkode beskeden og for at udføre den krævede handling. Denne rutine angiver det relevante fejlflag, hvis meddelelseskoden modtaget ikke er kendt.
TMR1 genererer et 1000 Hz timing ur - hjerteslag i programmet. Ved hver TMR1-afbrydelse opdateres interne timere, vagtholdet ryddes, og et flag er indstillet til at aktivere den funktion, der beder om den rejste rumværdi. Hver 10ms "All_Parameters_Ask" funktion (hastighed, position, strøm) er aktiveret.
Trin 6: Detaljer om software: Odometry og Field Mapping = Hvor er jeg?
Når vi har fået oplysninger om den afstand, der er tilbagelagt af hvert hjul i en diskret tidsopdatering (odometri), kan vi estimere robotens positionskoordinater med samme periodicitet uden nogen ekstern reference (dead reckoning).
Nogle teoretiske baggrunder vedrørende dødt beregning ved odometri findes i bogen af Johann Borenstein:
"Hvor er jeg?" - Sensorer og metoder til mobil robotpositionering "
og på følgende websider:
http://www.seattlerobotics.org/encoder/200010/dead_reckoning_article.html
Den matematiske baggrund og en dyb forklaring på den generelle metode, der findes, findes på G.W. Lucas 'papir En selvstudie- og elementærbanemodel til det forskellige styresystem af robothjulstrømgivere, tilgængelig på internettet:
http://rossum.sourceforge.net/papers/DiffSteer/DiffSteer.html
Nogle forenklede algoritmer findes også i samme dokumentation, så det er muligt at opnå det korrekte kompromis mellem præcision og udarbejdelseshastighed ved hjælp af den matematiske (trigonometriske) kapacitet af dsPIC33F serien.
En beskrivelse af de matematikker, der bruges til at beregne positionen, findes i billederne, der er vedlagt dette trin. Den første viser symbolernes betydning, den anden viser formlerne, der anvendes med disse symboler. Ved at klikke på boksene ud for hvert beregningstrin vises en kort beskrivelse.
I slutningen ved vi, hvor meget robotten flyttede i dette tidsinterval som et orienterings delta, et delta på X-aksen og et delta på Y-aksen i det karthestiske referencefelt.
Kumulerer hver delta-værdi i sin egen variabel, vi kender platformens aktuelle koordinater (position og orientering).
For at undgå beregningsfejl (divideres med nul) og spild af controllerens tid, skal der foretages en check på forhånd på både Sr og Sl-variabler. Ved at definere en kvasi-nul-værdi, der tager sig af minimal mekaniske og beregningsmæssige tilnærmelser, kan vi forenkle formlerne, hvis roboten rejser i en retlinie (rummet dækket af det højre hjul er næsten det samme som det rum, der er rejst af det venstre hjul) eller hvis det drejer rundt om sin lodrette akse (det rum, der er dækket af det højre hjul, er næsten det samme som det rum, der er rejst af det venstre hjul, men i en modsat retning) som beskrevet i rutediagrammet, der vises på det sidste billede.
Denne video viser et eksempel på, hvilken præcision vi kan opnå:
http://www.youtube.com/watch?v=d7KZDPJW5n8
Feltplanlægning
Med data beregnet af tidligere funktioner udføres en feltmapping.
Hver XMS, efter den aktuelle positionudarbejdelse, udføres en feltkortlægning, der deler det ukendte felt i et 10 x 10 cm-cellegitter. Ved at definere en maksimal feltdimension på 5 x 5m opnår vi en 50 x 50 = 2500 cellematrix. Hver celle er defineret med en nibble, med en samlet hukommelse på 1250 byte. Seksten forskellige værdier kan tildeles hver celle:
n = 00 ukendt celle
n = 01 - 10 celle besøgt n gange
n = 11 hindring fundet
n = 12 gasmål fundet
n = 13 lysmål fundet
n = 14 lydmål fundet
Robotten kan starte fra enhver position i feltet; Disse vil være referencekoordinaterne (0,0) i sit referencesystem.
Feltplanlægning er nyttig til at finde den bedste udforskningsstrategi på et ukendt felt. Roboten kan lede sig til den mindre udforskede del af feltet (lavere "n" -værdi), kan spare tid ved ikke at stoppe to gange i et allerede opdaget mål, kan finde den bedste vej til at nå en given koordinat og mere.
Trin 7: Fjernkonsol
For at være let at udvikle og godt at køre i ethvert operativsystem, er det skrevet med Forarbejdning Sprog:
http://www.processing.org/
Kildekoden til dette program er også tilgængelig som open source på Google Code:
http://code.google.com/p/dsnavconconsole/
Med hovedpanel (første billeder) kan vi udføre telemetri ved at se på gitteret stien efterfulgt af roboten (som estimeret af odometri) i et konfigurerbart størrelse felt og nogle andre vigtige værdier læses på dsNav .
Målerne viser de målte værdier:
- MesSpeed i et interval på +/- 500 mm / s, middelværdien af tohjulets hastighed (hastigheden af platformens centrum).
- Målt strøm i mA (summen af strømmen fra de to motorer).
- Målt vinkel, som øget af odometri.
Andre paneler bruges til at konfigurere robotens parametre og opbevare robotten en defineret vej, der skal følges (hvis det er nødvendigt). Et vigtigt panel, i hvert fald under robotens udvikling, er detail panel (andet billede), der viser hastigheden for hvert hjul i realtid, meget nyttigt til kalibrering af alle parametrene.
Den centrale gittervisning kan skiftes med udsigt til et webkamera til selv at kontrollere, hvilken vej robotten følger.
Et praktisk eksempel på brug for denne konsol er vist i denne video:
http://www.youtube.com/watch?v=OPiaMkCJ-r0
