Circuits

Paano Gumawa ng Self Navigating Robot: 7 Steps

Building a ROS Robot for Mapping and Navigation #1

Building a ROS Robot for Mapping and Navigation #1

Talaan ng mga Nilalaman:

Anonim

Ito ay isang detalyadong tutorial sa kung paano mapagtanto ang isang robot simula sa simula, at nagbibigay ito ng kakayahan upang mag-navigate autonomously sa isang hindi kilalang kapaligiran.
Ang lahat ng mga tipikal na argumento na may kaugnayan sa robotics ay sakop: mekanika , electronics at programming .
Ang buong robot ay dinisenyo upang gawin ng sinuman sa bahay nang walang mga propesyonal (ibig sabihin mahal) na mga tool at kagamitan.
Ang utak board (dsNav ) ay batay sa isang Microchip dsPIC33 DSC na may kakayahan sa encoder at motor controller. Ang posisyon ay nakalkula sa pamamagitan ng odometry (encoder) nang walang anumang panlabas na sanggunian (dead reckoning).
Sa huling bersyon ang ilang iba pang mga controllers ay ginagamit upang kontrolin ang mga sensors (Arduino) at upang pamahalaan ang mga analogic sensors (PSoC).

Mga Kagamitan:

Hakbang 1: Ang Pangunahing Platform

Isang halimbawa ng kung paano bumuo ng isang napaka-simpleng robotic platform na may mga bahagi at mga bahagi madaling mahanap sa lahat ng dako, nang walang mga pangangailangan ng propesyonal na mga tool o kagamitan, at walang isang espesyal na kasanayan sa mga gawa sa makina.
Ang laki ng base ay nagbibigay-daan sa paggamit nito sa maraming iba't ibang mga kategorya ng mga robotic contests: Explorer, Line Follower, Can Collector, atbp.

Hakbang 2: Ano ang Gusto naming Makuha? at kung paano?

Ang robot na ito, tulad ng karamihan sa mga robots na binuo ng mga hobbysts, ay batay sa isang sistema ng pag-iibayo ng kaugalian, na nagpapahintulot sa amin na malaman ang mga coordinate ng posisyon ng robot sa anumang naibigay na sandali, sa simpleng pag-alam sa espasyo na sakop ng bawat gulong nang pana-panahon na may sapat na katumpakan.
Ang patay na pagbilang ng nabigasyon system ay apektado ng pinagsama-samang error; ang katumpakan ng pagsukat ay dapat na mataas upang matiyak ang isang maliit na bilog ng error pagkatapos ng mahabang landas. Kaya, pagkatapos ng ilang magandang resulta sa mga homemade encoder, nagpasya akong gamitin ang isang bagay na mas mahusay: isang pares ng 12V-200 rpm nakatuon Motors, na konektado sa isang pares ng 300 Count Per Revolution (cpr) encoders, parehong magagamit sa maraming mga Internet robotics tindahan.
Pangunahing prinsipyo
Upang mahuli ang lahat ng mga pulso na binuo ng 300 cpr encoder sa isang 3000 rpm motor sa 4x decoding na paraan (120 kHz), kailangan namin ng dedikadong hardware para sa bawat encoder (QEI = Quadrature Encoder Interface). Pagkatapos ng ilang mga eksperimento sa isang double PIC18F2431, natukoy ko na ang tamang pag-upgrade ay sa isang dsPIC. Sa simula sila ay dalawang dsPIC30F4012 motor controllers upang kontrolin ang posisyon ng gulong at bilis, upang maisagawa ang odometry at upang magbigay ng data ng dalawang Motors sa isang dsPIC30F3013. Ang pangkalahatang layunin ng DSC ay sapat na makapangyarihan upang makakuha ng data, gawin ang ilang trigonometrya upang makalkula ang mga coordinate sa posisyon, at mag-imbak ng data na may kaugnayan sa landas na sakop upang makakuha ng isang mapa ng patlang, lahat sa isang napakataas na rate.
Nang makumpleto na ang board at ang mga programa, ang Microchip ay nagdala ng isang bagong, malakas na 28-pin SPDIP sa serye dsPIC33F para sa parehong mga bersyon ng motor controller (MC) at general-purpose (GP). Ang mga ito ay makabuluhang mas mabilis kaysa sa dsPIC30F, marami silang magagamit na memorya ng programa at RAM (kapaki-pakinabang para sa pagmamapa ng field), nangangailangan sila ng mas kaunting kapangyarihan (mabuti para sa robot na pinatatakbo ng baterya), at ang kanilang mga kakayahan sa DMA ay nagpapasimple ng maraming operasyon ng I / O.
Pinakamahalaga, ang mga ito ang unang Microchip motor controllers na may dalawang QEIs sa parehong chip. Magsimula tayo muli ng isang bagong port! Ang Ang lohikal na block diagram ay katulad ng isa para sa nakaraang board , ngunit ang hardware at software ay mas simple dahil Maaari ko bang gamitin ang isang DSC lamang insted ng tatlo . Walang pangangailangan para sa isang mataas na bilis ng komunikasyon sa pagitan ng superbisor at motor controllers upang makipagpalitan ng mga parameter ng nabigasyon. Ang bawat proseso ay simple upang i-synchronize dahil ito ay nasa parehong maliit na tilad. Ang piniling peripheral pin na kakayahan ng serye dsPIC33F ay nagpapadali sa PCB, na nagpapagana ng isang panloob na koneksyon ng peripheral at isang mas malawak na kakayahang umangkop.
Dinadala ito sa "dsPIC na nakabatay sa Navigation Control board" o dsNavCon para sa maikli. Ang lupong ito ay dinisenyo bilang isang bahagi ng isang mas kumplikadong sistema. Sa isang kumpletong robot explorer, ang iba pang mga board ay makokontrol sa tunog, ilaw, sensors ng gas, pati na rin ang mga bumper at ultrasonic range finder upang makahanap ng mga target at maiwasan ang mga hadlang.
Bilang isang standalone board, dsNavCon ay maaari ding gamitin para sa isang simpleng "linya tagasunod" robot, isang bagay na mas kumplikado tulad ng isang robot para sa isang odometry at patay-reckoning paligsahan, o isang tinatawag na "maaari robot" (para sa maaaring pagkolekta ng mga kumpetisyon). Mayroong pa rin ng maraming libreng memory ng programa upang magdagdag ng code para sa naturang mga gawain. Sa menor de edad o walang pagbabago sa software, maaari rin itong gamitin nang nakapag-iisa para sa isang remote na kontroladong sasakyan, gamit ang bidirectional RF modem na may ilang uri ng smart remote control. Ang remote control na ito ay maaaring magpadala ng kumplikadong mga utos tulad ng "ilipat ang FWD 1m," "umalis ng 15 °," "magpatakbo ng FWD sa 50 cm / s," "pumunta sa X, Y coordinates," o isang katulad na bagay.
Ang board at ang robot din, ay dinisenyo upang gawin ng sinuman sa bahay nang walang propesyonal na mga tool at kagamitan.

Hakbang 3: Ang Open Source Hardware

I-block ang Diagram
Ang subsystem control ng nabigasyon ay binubuo ng dsNav bilang ang "matalinong" board ng system at isang dual-board na H-bridge na nakabatay sa L298 upang makontrol ang nakatuon na 12V motors (Hsiang Neng HN-GH12-1634TR). Ang feedback ng paggalaw ay mula sa isang pares ng 300 cpr encoder (US digital e4p-300-079-ht).
Ang komunikasyon sa panlabas na mundo ay ginagawa sa pamamagitan ng dalawang mga interface ng UART serial; isa para sa telemetry at ang iba pa upang makakuha ng data mula sa mga sensor ng board. Ang XBee module ay maaaring konektado sa UART1 o UART2 sa pamamagitan ng JP1 at JP2 jumpers. Available ang J1 at J16 sockets para sa iba pang uri ng koneksyon. Ang COMM1 port (J16) ay maaari ring magamit para sa isang salamat sa komunikasyon ng I2C sa peripheral pin piliin ang kakayahan ng serye dsPIC33F.
Ang orihinal na diagram ng eskematiko sa format na Eagle ay matatagpuan dito:
http://www.guiott.com/Rino/dsNavCon33/dsNavCon33_Eagle_project/DsPid33sch.zip
Tulad ng makikita mo ang eskematiko ay napakasimple na maaari itong ipatupad sa isang perfboard tulad ng ginawa ko. Kung ayaw mong gamitin ang sistemang ito at ayaw mong mapagtanto ang iyong sariling PCB, ang isang komersyal na board batay sa aking orihinal na trabaho at ganap na katugma sa aking open source software ay makukuha sa: http: //www.robot-italy .com / product_info.php? products_id = 1564

Hakbang 4: Ang Open Source Software

Ang software ay binuo gamit ang MPLAB® libreng IDE at nakasulat sa MPLAB® C30 compiler (kahit sa isang libre o mag-aaral na bersyon), parehong (siyempre) sa pamamagitan ng Microchip:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=81
Ang buong proyekto ay magagamit bilang open source sa Google Code
http://code.google.com/p/dspid33/
Mangyaring sumangguni doon para sa pinakabagong bersyon, komento, paglalarawan, atbp.
Ang programa ay inilarawan sa bawat hakbang sa loob ng code. Upang magkaroon ng isang mataas na antas ng pagkomento at isang mas nababasa code, sa bawat makabuluhang punto mayroong isang numero sa mga bracket (hal: 7) bilang isang reference sa isang panlabas na file (ibig sabihin: descrEng.txt) sa MPLAB proyekto .
Ang diagram ay nagpapakita ng pangkalahatang arkitektura ng mga pamamaraan ng control ng dsNav board at ang mga diskarte sa nabigasyon na inilalapat sa batayan ng proyekto.
Ang mga controllers ng motor ay makikita bilang mga itim na kahon na nag-aalaga sa bilis ng mga gulong. Ang superbisor na bahagi ng programa ay nagpapadala sa kanila ng bilis ng sanggunian (VeldDesX: ninanais na bilis). Ang Input Capture modules ng microcontroller ay nakakakuha ng pulses mula sa mga encoder na konektado sa axis ng motor at nakukuha ang bilis ng pag-ikot ng mga motors (VelMesX: sinusukat na bilis). Ang pagsasama-sama ng bawat 1ms ang mga halagang ito sa kontrol ng PID na "Speed ​​PID" na makuha namin ang tamang halaga ng PWM upang mapanatili ang nais na bilis ng bawat solong gulong.
Ang mga module ng QEI (Quadrature Encoder Interface) ay makakakuha ng parehong mga pulse ng A at B mula sa mga encoder at ibalik sa supervisor ang function ng paglalakbay na direksyon at ang bilang ng mga pulse sa 4x mode (pagbibilang sa pagsikat at pagbagsak ng mga gilid ng signal A at signal B: 2 x 2 = 4).
Ang pagpaparami ng bilang ng mga pulso ng isang K na nagpapahiwatig ng espasyo na naglakbay para sa bawat solong pulse ng encoder, nakuha namin ang distansya na nilakbay ng kanan at kaliwang gulong bawat 10ms. Pinagsasama ng superbisor ang mga impormasyong naglalakbay na ito at nalalapat ang patay na pamamaraan ng pag-uulit upang makuha ang mga panukalang coordinate ng bot: Xmes, Ymes, θMes (orientation angle).
Ang superbisor ay tumatanggap ng navigation command mula sa labas ng serial interface (telemetry).
Magagamit ang iba't ibang mga estratehiya:
A - Maglakbay sa isang naibigay na bilis sa isang naibigay na direksyon (VelDes, θDes).
B - Maglakbay papunta sa isang ibinigay na punto sa mga coordinate XDes, YDes.
C - Maglakbay para sa isang naibigay na distansya sa isang naibigay na direksyon (DistDes, θDes).
Mode A : sa "lohikal na kontrol switch" sa posisyon 1, tanging ang kontrol ng PID na "Anggulo PID" ay ginagamit ng mga function ng superbisor. Pinagsasama nito ang ninanais na anggulo θSa may sukat na anggulo θMes kinakalkula sa pamamagitan ng odometry procedure, upang makuha ang halaga ng pag-ikot ng bilis ng ω ng sasakyan sa paligid ng vertical axis nito, kailangan upang itama ang error ng orientation.
Ang halaga ng DeltaV ay proporsyonal sa ω. Ito ay idinagdag sa VelDes upang makuha ang bilis ng kaliwang gulong at ibawas sa VelDes upang makakuha ng bilis ng tamang gulong, upang mapanatili ang heading na naaayon sa halaga ng θ, habang ang gitna ng robot ay naglalakbay pa sa bilis ng VelDes.
Mode B : Sa pamamagitan ng "lohikal na kontrol switch" sa posisyon 2, ang nais na bilis VelDes ay kinakalkula ng kontrol ng PID "Dist PID" at ito ay ginagamit bilang sa mode A. Ang sinusukat input para sa PID (DistMes) ay kinakalkula bilang isang function ng ang kasalukuyang mga coordinate at ang mga coordinate ng patutunguhan. Ang ninanais na anggulo ng oryentasyon θ Din ay mula sa parehong pamamaraan at ginagamit ito bilang sanggunian na input para sa "Anggulo PID". Ang reference input para sa "Dist PID" ay 0, ibig sabihin na ang destinasyon ay naabot. Sa ω at VelDes magagamit, ang bilis ng kontrol ng mga gulong ay tumatakbo tulad ng sa mode A.
Mode C : sa "lohikal na kontrol switch" sa posisyon 2, ang destination cordinates Xdes, Ydes ay nakalkula isang beses sa simula bilang isang function ng input parameter DistDes, θDes. Matapos na ang lahat ng bagay ay napupunta sa mode B

Hakbang 5: Mga Detalye ng Software: Control ng Bilis at Iba Pang Pangunahing Mga Tungkulin

Ang programa ay puno na matakpan ang hinihimok . Sa startup, pagkatapos ng pagsisimula, ang programa ay nagpasok sa isang napaka-simple na main-loop, kumikilos bilang isang makina ng estado. Sa pangunahing loop, ang mga tseke ng programa ay pinapagana ng mga panlabas na kaganapan, at pumapasok sa kamag-anak na estado ayon sa kanilang mga halaga.
Dahil ito ay isang uri ng isang napaka-simpleng kooperatiba "Real Time Operating System , "ang bawat gawain ay kailangang maisakatuparan sa pinakamaikling posibleng panahon, na pagpapalaya sa sistema upang alagaan ang mga madalas na pagkagambala.
Walang "maghintay hanggang" at walang pagkaantala sa code. Sa tuwing magagamit ang mga interrupted, lalo na para sa mga mabagal na operasyon tulad ng paghahatid o pagtanggap ng mga string ng mga character. Ang UART na komunikasyon ay tumatagal ng pakinabang ng mga kakayahan ng DMA ng dsPIC33F upang i-save ang oras ng CPU na ginagawa ang lahat ng "marumi" na trabaho sa hardware.
Mga Peripheral na ginamit sa dsPIC33FJ128MC802:
- Mga QEI upang kalkulahin ang nalakbay na landas.
- Input Capture (IC) upang makalkula ang bilis.
- A / D converters upang basahin ang kasalukuyang motor.
- Pinahusay na mga PWM upang himukin ang mga motors.
- UARTs upang makipag-ugnay sa panlabas na mundo
QEI modules ay ginagamit upang malaman kung magkano ang mga gulong na nilakbay at kung saan direksyon. Ang halagang ito ay algebraically cumulated sa isang variable bawat 1ms at ipinadala sa mga function ng superbisor sa kahilingan nito. Matapos ipadala ang halaga, ang mga variable ay i-reset.
Ang bilis ay sinusukat sa bawat pulutong ng encoder tulad ng inilarawan sa ibaba. Ang bawat 1ms ay kinakalkula nito ang ibig sabihin ng bilis sa pamamagitan ng mga sampol sa pag-a-average, nagsasagawa ng PID algorithm, at itinutuwid ang bilis ng motor nang naaayon sa resulta nito, na nagbabago ng cycle ng PWM na tungkulin. Para sa isang detalyadong paglalarawan ng aplikasyon ng library ng C30 PID, tingnan ang Microchip Code Halimbawa: CE019 - Paggamit ng mga Controller ng Porsyento ng Integrative (PID) sa Closed-loop Control Systems. http://ww1.microchip.com/downloads/en/DeviceDoc/CE019_PID.zip
Ang mga variation ng bilis ng mga motors ay pinapatakbo nang maayos, pinabilis o nag-decelerating na may tumataas o bumabagsak na slamp ramp, upang maiwasan ang mabibigat na mekanikal na strain at slippage ng gulong na maaaring maging sanhi ng mga pagkakamali sa odometry. Ang pagbabawas ng bilis ay mas mabilis at pagkatapos ay ang acceleration upang maiwasan ang mga bumps na may mga obstacles sa panahon ng pagpepreno.
IC , ang input capture modules ay ginagamit upang masukat ang oras na lumipas sa pagitan ng dalawang pulso na nabuo ng encoder, ibig sabihin kapag ang mga gulong ay naglakbay para sa isang mahusay na kilalang takdang halaga ng espasyo (pare-pareho SPACE_ENC ). Nakapaloob sa kahanay sa QEA (panloob sa DSC salamat sa mga kakayahan ng Peripheral Pin Select ng dsPIC33F), hinuhuli nila ang lumipas na oras sa tumataas na gilid ng mga signal ng mga encoder. Ang TIMER2 ay ginagamit sa libreng mode na tumatakbo. Sa bawat IC ay matakpan, ang kasalukuyang halaga ng TMR2 ay naka-imbak at ang dating halaga nito ay bawas mula dito; ito ang panahon ng pulso. Pagkatapos ay ang kasalukuyang halaga ay nagiging nakaraang halaga, naghihintay sa susunod na pag-abala. Dapat i-check ang flag ng TMR2 upang malaman kung ang overflow ay nangyari sa 16-bit register. Kung oo, ang pagkakaiba sa pagitan ng 0xFFFF at ang nakaraang sample ay dapat idagdag sa kasalukuyang halaga. Ang mga halimbawa ay algebraically idinagdag sa IcPeriod variable ayon sa _UPDN bit, upang matukoy din ang bilis ng direksyon. Ito ay isa sa mga iminungkahing pamamaraan Tala ng microchip application AN545 .
Ang variable IcIndx naglalaman ng bilang ng mga sample na idinagdag sa IcPeriod .
Ang bawat 1ms ang ibig sabihin ng bilis ay kinakalkula bilang V = Space / Time
kung saan Space = SPACE_ENC • IcIndx
(= puwang na sakop sa isang pulse ng encoder • bilang ng mga pulse)
at Oras = TCY • IcPeriod
(= nag-iisang panahon ng TMR • nangyayari ang kabuuan ng mga tagal ng panahon).
Single_TMR_period = TCY = 1 / FCY (dalas ng orasan).
Kaya V = Kvel • (IcIndx / IcPeriod)
kung saan Kvel = SPACE_ENC • FCY upang magkaroon ng bilis sa m / s.
Paglipat ng kaliwang 15 bits Kvel const ( KvelLong = Kvel << 15 ) ang bilis ay kinakalkula na sa praksyonal na format (din kung lamang ang mga variable ng integer na ginagamit) na handa na magamit sa PID na gawain. Tingnan ang "descrEng.txt" na file sa MPLAB na proyekto para sa isang mas detalyadong paglalarawan.
A / D converters patuloy na sumusukat ang mga kasalukuyang motors, na nagtatabi ng mga halaga sa 16 na posisyon ng mga buffer ng ADCBUF. Kapag puno ang buffers, ang isang pag-abala ay nangyayari at ang isang average na halaga ay kinakalkula ng humigit-kumulang bawat 1ms.
UARTs ay ginagamit upang tumanggap ng mga utos mula sa labas at upang ipadala pabalik ang mga resulta ng mga sukat. Ang bahagi ng komunikasyon ng programa ay tumatakbo bilang isang makina ng estado. Ang mga variable ng katayuan ay ginagamit upang maisagawa ang mga pagkilos sa pagkakasunud-sunod. Ang napaka-simple at mabilis na Pagkagambala sa Mga Serbisyo sa Pag-aalis (ISR) ay nakakakuha o naglalagay ng bawat solong byte mula sa o sa isang buffer, at itakda ang tamang mga flag upang ipaalam ang tamang function na maisagawa.
Kung ang anumang uri ng error ay nangyayari sa panahon ng pagtanggap (UART, checksum, pag-parse ng mga error), ang variable ng katayuan ay naka-set sa isang negatibong numero at ang red led ay pinapatakbo upang makipag-usap sa panlabas na kondisyon kasalanan na ito. Tingnan ang "descrEng.txt" na file sa MPLAB na proyekto para sa isang kumpletong listahan ng mga posibleng error.
Ang protocol na ginamit para sa pagkakamay ay independiyenteng layer ng katawan , at maaaring gamitin sa bus ng I2C o RS485 pati na rin upang makipag-usap.
Ang unang layer ay kinokontrol ng dsPIC interface ng paligid. Ang mga balangkas o mga overrun error (UART) o banggaan (I2C) ay napansin ng hardware, na nagtatakda ng angkop na bandila.
Ang pangalawang layer ay hinahawakan ng mga gawain ng ISR. Punan nila ang RX buffer sa mga byte na natanggap mula sa mga interface. Nakikita rin nila ang buffer overflow at command overrun.
UartRx o UartRx2 function na pamahalaan ang ikatlong layer . Tulad ng inilarawan (tingnan din ang mga tsart ng daloy) ang mga gawain na kumikilos bilang isang makina ng estado, pagkuha ng mga byte mula sa buffer at pag-decode ng command string.
Ang bytes ay ipinagpapalit sa pagitan ng ikalawa at ikatlong layer (ISR at UartRx function) sa pamamagitan ng isang circular buffer. Ang ISR ay tumatanggap ng isang byte, nag-iimbak ng mga ito sa isang array at binabawasan ang isang pointer sa array, kung dumarating ang pointer sa dulo ng array na ito ay muling sinimulan sa simula. Ang UartRx function ay may sariling pointer upang basahin ang parehong array, incremented (sa isang pabilog na paraan masyadong) sa lalong madaling byte ay decoded sa kasalukuyang katayuan RX. Ang pangunahing loop ay tumatawag sa UartRx function kapag ang "in" pointer ay naiiba sa "out" pointer.
Ang bawat packet ng command ay binubuo ng:
0 - Header @
1 - ID 0-9 ASCII
2 - Cmd A-Z ASCII
3 - CmdLen N = 1-MAX_RX_BUFF # ng sumusunod na mga sumusunod (kabilang ang checksum)
4 - Data …

N-1 - Data
N - Checksum 0-255 nakuha sa pamamagitan lamang ng pagdaragdag ng hanggang sa isang 8 bits variable, lahat ng bytes na binubuo ng mensahe (hindi kasama ang checksum).
Kinokontrol ng layer na ito ang mga error sa timeout at checksum, pati na rin ang packet consistency (tamang header, tamang haba). Kung ang lahat ng ok ay nagbibigay-daan sa Parser routine (ikaapat na layer ) upang mabasa ang mensahe at maisagawa ang pagkilos na kinakailangan. Ang routine na ito ay nagtatakda ng naaangkop na flag ng error kung ang natanggap na mensahe code ay hindi kilala.
TMR1 ay bumubuo ng isang 1000 Hz tiyempo orasan - ang tibok ng puso ng programa. Sa bawat pag-abala ng TMR1, ang mga panloob na timer ay na-update, ang tagapagbantay ay na-clear, at isang bandila ay nakatakda upang paganahin ang function na humihiling para sa manlalakbay na halaga ng espasyo. Ang bawat 10ms function na "All_Parameters_Ask" (bilis, posisyon, kasalukuyang) ay pinagana.

Hakbang 6: Mga Detalye ng Software: Odometry and Field Mapping = Saan Ako?

Pag-optimize ng pangkalahatang algorithm para sa paggamit sa isang DSC o MCU based system
Sa sandaling mayroon kami ng impormasyon tungkol sa distansya na nilibot ng bawat gulong sa isang discrete-time update (odometry), maaari naming tantyahin ang mga coordinate ng posisyon ng robot na may parehong periodicity nang walang anumang panlabas na sanggunian (dead reckoning).
Ang ilang mga teoretikal na background patungkol sa patay na pag-uulit ng odometry ay matatagpuan sa aklat ni Johann Borenstein:
"Nasaan Ako? - Mga Sensor At Mga Paraan Para sa Posisyon ng Pag-Robot ng Mobile"
at sa mga sumusunod na mga web page:
http://www.seattlerobotics.org/encoder/200010/dead_reckoning_article.html
Ang mathematical background at isang malalim na paliwanag ng pangkalahatang pamamaraan na ginamit, ay matatagpuan sa G.W. Papel ni Lucas Isang Tutorial at Elementary Trajectory Model para sa Differential Steering System ng Robot Wheel Actuators, na magagamit sa Internet:
http://rossum.sourceforge.net/papers/DiffSteer/DiffSteer.html
Ang ilang mga simplified algorithm ay matatagpuan sa parehong dokumentasyon na rin, kaya posible na makuha ang tamang kompromiso sa pagitan ng katumpakan at bilis ng pagpaliwanag, gamit ang mathematic (trigonometric) na kakayahan ng dsPIC33F series.
Ang isang paglalarawan ng mga matematika na ginamit upang makalkula ang posisyon ay matatagpuan sa mga larawan na naka-attach sa hakbang na ito. Ang unang isa ay nagpapakita ng kahulugan ng mga simbolo, ang ikalawang isa ay nagpapakita ng mga formula na ginamit sa mga simbolo. Ang pag-click sa mga kahon sa tabi ng bawat computational step ay ipinapakita ang isang maikling paglalarawan.
Sa dulo ay alam namin kung gaano kalaki ang inilipat ng robot sa agwat ng oras na ito bilang isang delta ng orientation, isang delta sa X axis at isang delta sa Y axis sa carthesian reference field.
Ang pagkakaroon ng bawat delta-value sa sarili nitong variable alam namin ang kasalukuyang mga coordinate (posisyon at orientation) ng platform.
Upang maiwasan ang mga error sa computational (hatiin sa pamamagitan ng zero) at pag-aaksaya ng oras ng controller, kailangang suriin nang maaga sa mga variable ng Sr at Sl. Ang pagtukoy sa isang quasi-zero na halaga na nag-aalaga ng minimal na mekanikal at computational approximations maaari naming gawing simple ang mga formula kung ang robot ay naglalakbay sa isang tuwid na linya (ang espasyo na sakop ng tamang gulong ay halos katulad ng puwang na nilakbay ng kaliwang gulong) o kung ito ay pivoting sa paligid ng vertical axis nito (ang espasyo na sakop ng tamang gulong ay halos pareho ng puwang na nilakbay ng kaliwang gulong ngunit sa kabaligtaran na direksyon), na detalyado sa tsart ng daloy na ipinapakita sa huling larawan.

Ang video na ito ay nagpapakita ng isang halimbawa kung saan katumpakan ang maaari nating makuha:
http://www.youtube.com/watch?v=d7KZDPJW5n8


Pagma-map ng patlang
Sa data na kinalkula ng mga naunang function, ang isang pagmamapa ng patlang ay ginaganap.
Tuwing Xms, pagkatapos ng kasalukuyang pagpapaliwanag ng posisyon, ang isang pagmamapa ng patlang ay ginanap na naghahati sa hindi kilalang larangan sa isang 10 x 10cm grid ng cell. Ang pagtukoy sa maximum na sukat ng patlang ng 5 x 5m, nakukuha namin ang isang 50 x 50 = 2500 na matrix ng mga cell. Ang bawat cell ay tinukoy sa isang maliit na kagat, na may kabuuang memory occupation ng 1250 Bytes. May 16 na magkakaibang halaga ang maitatalaga sa bawat cell:
n = 00 hindi kilalang cell
n = 01 - 10 cell binisita n beses
n = 11 balakid na natagpuan
n = 12 target na gas na natagpuan
n = 13 light target na natagpuan
n = 14 target na tunog na natagpuan
Ang robot ay maaaring magsimula sa anumang posisyon sa larangan; ang mga ito ay ang mga coordinate na sanggunian (0,0) sa kanyang sistema ng sanggunian.
Ang mapping sa field ay kapaki-pakinabang upang mahanap ang pinakamahusay na diskarte sa paggalugad sa isang hindi kilalang patlang. Ang robot ay maaaring direktang mamahala sa hindi gaanong ginalugad na bahagi ng patlang (mas mababang "n" na halaga), maaaring makatipid ng oras sa pamamagitan ng hindi pagpapahinto ng dalawang beses sa isang natuklasan na target, makakahanap ng pinakamahusay na landas upang maabot ang isang naibigay na coordinate, at higit pa.

Hakbang 7: Remote Console

Ito ang application na malayo kontrol sa dsNavCon board mula sa isang Mac / PC sa pamamagitan ng serial komunikasyon sa pamamagitan ng isang pares ng mga XBee aparato tulad ng inilarawan sa block diagram.
Upang maging madali upang bumuo at mahusay na tumakbo sa anumang operating system, ito ay nakasulat sa Pagproseso wika:
http://www.processing.org/
Ang source code para sa programang ito masyadong ay magagamit bilang open source sa Google Code:
http://code.google.com/p/dsnavconconsole/
Kasama ang pangunahing panel (unang mga larawan) maaari naming magsagawa ng telemetry sa pamamagitan ng pagtingin sa grid ang landas na sinundan ng robot (tulad ng tinatantya ng odometry) sa isang field ng mai-configure na sukat at ilang iba pang mahahalagang halaga ang nabasa sa dsNav .
Ang mga gauge ay nagpapakita ng sinusukat na mga halaga:
- MesSpeed ​​sa hanay ng +/- 500 mm / s, ang ibig sabihin ng halaga ng bilis ng dalawang gulong (ang bilis ng sentro ng platform).
- Sinusukat Kasalukuyang sa MA (ang kabuuan ng kasalukuyang mula sa dalawang motors).
- Sinusukat na Anggulo, na pinalawak ng odometry.
Ang iba pang mga panel ay ginagamit upang i-configure ang mga parameter ng robot at mag-imbak sa robot ng isang tinukoy na path upang sundin (kung kinakailangan). Ang isang mahalagang panel, hindi bababa sa panahon ng pag-unlad ng robot, ay ang panel ng detalye (pangalawang larawan) na nagpapakita ng bilis ng bawat gulong sa real time, lubhang kapaki-pakinabang para sa pagkakalibrate ng lahat ng mga parameter.
Ang gitnang grid view ay maaaring ilipat sa view ng isang webcam upang kontrolin, kahit na sa pamamagitan ng pagtingin, ang path na sinusundan ng robot.
Ang isang praktikal na halimbawa ng paggamit para sa console na ito ay ipinapakita sa video na ito:
http://www.youtube.com/watch?v=OPiaMkCJ-r0