Fórum témák
» Több friss téma |
Mi az a BRA? Nekem nincs benne az ASM utasításkészlet listámban.
BRA $-8
8 sorral feljebb ugratós goto Olyan mint a goto csak kissebb címeltérést kezel
Igen, közben én is megnéztem, 5MIPS esetén nem fér bele több. Első blikkre azt hittem volna több idő van, de te számoltál jól.
18F-eknél van csak BRA, a 16F-eknél a fordító ha elfogadja, akkor GOTO-ra cseréli, de nálam pl. nem fogadja el.
Végre kész az új programozóm és megjöttek kínából a szervók
Hétvégén volt időm játszani vele és el is készült az első szervó vezérlő szoftver. Egyenlőre csak egy szervót vezérel, de első lépésnek nekem már ez is elég volt Videó a szervó vezérlőről
Köszönöm szépen!
Nagy megtiszteltetés ezt tőled olvasni. Sajnos ez még csak az első lépcső előtti szakasz. Az igazán nagy kihívás a 18 szervó vezérlése lesz + az SPI kapcsolat kezelése. Egyenlőre ez is nagy öröm nekem, hogy megmozdult a szervó és tudtam állítgatni a szögét
Ha egy PIC-be nem fér, akkor legfeljebb kettőbe biztosan bele tudod nyomni! A korábbi elképzelésed szerintem működni fog.
most ütköztem abba progblémába, amit googa említett.
nekem a kitérésem 650 és 2200us között van. Most ami aggaszt az az adatok beolvasása. Valaki ismer valami jóképű SPI FIFOt? A probléma a következő. Az adatbusz 5Mhz-es SPI busz. a szervók vezérlése 3*1550us-t legalább elvesz 20ms alatt. Ha ebben a blokkoló státuszban küld vmi adatot a vezérlőnek akkor az elvész a fekete likba. hacsak nincs ott egy FIFO vagy folyamatosan lököm vissza az ACK-ot. Ha ACK-ot adok ha beérkezett az adat, akkor meg az adat kiállítóját blokkolom. brrrrr......
Ezért mondtam Neked, hogy oszd le szépen több PIC-re a feladatot. Legalább kettőre és mindkettőnek jut 3x3 szervó, meg némi kommunikáció. Sőt továbbmegyek. Legyen egy kommunikációra kihegyezett PIC-ed és kettő PIC, ami a szervókkal foglalkozik. Egyéb holtidőben pedig megbeszélik az adatokat.
Nem volna hülyeség egy RC-s giroszkópot (helikhez árulják, nem túl drágák) és lábanként egy-egy nyomásérzékelőt, valamint valimféle ütközés szenzorokat felszerelni. Tudom, hogy ez további nyűg, de ez leginkább az előre tervezendő szükséges rossz fogalmát fogja számodra kimeríteni. Uhh, még nem szkenneltem be Neked a robotos könyv erre vonatkozó részeit...igyekszem.
jelenleg most azon agyalok, hogy 3PIC lesz. Picenként 6 szervót vezérlek.
A vezérlés megszakításokkal fog működni. P18-akat fogok használni. Kell rá legalább 8 I/O és HW I2C vagy SPI és egy 16bites számláló. Ezeket pedig egy negyedik PIC fogja összefogni, ami veszi a parancsokat az adatbuszról és egyfajta FIFO és parancs értelmezőként is fog üzemelni. Nagyjából így képzelem el: Buszról jön az adat: S1P1000S2P1500S3P1200T40 Az első PIC feldolgozza, hogy Szervó1 1000us-t, Szervó2 1500us-t stb fog kapni. Továbbá azt,h ezt a mozgást 40*20ms alatt kell végrehajtania. Kiszámolja, hogy az adott szervó pozícióját lépésenként mennyivel kell változtatnia, hogy pont 40 ciklus alatt álljon be a változás. SzervóCsoportVezérló1 (továbbiakban SGC1) végzett a 6 szervó vezérlésével és küld egy jelet a FIFO-nak, hogy végzett. Ekkor a FIFO elküld neki 6*2byte-ot, hogy melyik szervójának milyen pozícióra kell állnia. A 6*2byte fogadására és a mentésre kb 6ms ideje van. ez rengeteg. A FIFO tehát fogadja, feldolgozza és továbbítja az adatokat. az SGC-k pedig lekérik a pozíció számokat és vezérlik a szervókat. Ebbe a 4PIC + a fő rendszerbusz kommunikációja a legmacerássabb. Gyrókat és érzékelőket a lábára akarok. de ezekkel majd csak akkor foglalkozok, ha már járni tud
Szerintem jobb lenne ha lenne erre egy dspic-ed. 600Ft ért kapsz "elegendőt" a feladatra (ez a legkissebb). Most ugye 5MIPS "erővel" gazdálkodsz, ám ez 40MIPS et produkál. Így minden szervót egy pic-el tudnád vezérelni, és még jutna "idő" a kommonikációra is.
Ha maradsz a 16F/18F sorozatnál akkor sem értem miért gondolkodsz itt külön kommunikációs pic-ben. Írtad, hogy megszakításban vezérled a szervókat. A főprogram ettől függetlenül futtathat egy kommunikációs rutint! Vagy te most vársz a megszakításban? (Mert az nagyon rossz megoldás...)
Pont ebben a pillanatban gondoltam, hogy kikérem a véleményeteket, hogy mi lenne ha egy dsPIC-et fognék be 40Mhz-es órajelen
Azért gondolkodtam kommunikációs PIC-ben mert akkor azzal minden egyéb feladatot el tudtam volna látni, a szervó csoport vezérlőknek pedig tényleg csak a szervókat kellett volna vezérelniük. UI: dsPIC-et JDM szerű programozóval lehet programozni? ICSP van rajta
Braf válaszát megkerülve örömmel látom, hogy Te is megértetted, hogy így átláthatóbb és követhetőbb lesz a rutin. Nem mellesleg a későbbi esetleges igazítás miatt nem kell mindent felrúgni és újra kezdeni átgondolni, megírni. Szerintem helyes úton járunk. Próbálok logikailag jó tanácsokat adni.
Lehet, hogy Watt, Braf és a többiek már jóval tapasztaltabbak ezen a téren, de mégis érdemes elgondolkodni azon, hogy a moduláris felépítésben több lehetőség rejlik. A természet is így dolgozik...
Első körben mindenképpen a modulárist próbálom ki, mert ahhoz van mindenem.
googa: az egész robotot modulárisra tervezem. A szervó vezérlő is egy modul lesz rajta. Rá kell dugni ilyen tüskés csatikkal a rendszerbuszra
Örülök, hogy kezd közös rugóra járni az agyunk.
G-Lex:
JDM el meg ne próbálkozz dsPIC-et programozni . Ha van otthon 16f877-ed, (és ugye ezt tudod programozni nem "biztonságos módon" de tudod) égess be bele egy icd2 sw.-ert azzal epíts egy pickit2 őt (vagy vegyél gyárit) Megéri..én is jdm el szenvedtem az elején googa: A moduláris felépítés a feladat bonyolultsága miatt egyszerűen kihagyhatatlan! pl: egy uC direkt a szervó vezérléssel foglalkozik (és futtathat még egy nem időkritikus programot a holtidőkben), egy csak a számolgatással foglalkozik, stb.. Én amit most építek robotot, abban is valami sínrendszer lesz pl: spi vagy rs232 9bites módban még nem 100 ,hogy melyik de inkább spi.. Nekem is sok modult kell (majd ) alkalmaznom (egy fő uC ami vezérel mindent, radar modul, szervó meghajtó modul, "normál" motorvezérlő modul, rádiós modul, stb..) Látom megelőztetek
Azért jobb lenne, ha nem feledkeznél meg a nemrég említett giroszkópról és a különféle érzékelőkről, amik a robot felület-tér érzékelését segítik.
Gondolj csak bele, ha nem tudja elég magasra emelni az egyik lábát, mert egy "bucka" van előtte, akkor milyen marhaságokat fog összehozni. Maradjunk abban, hogy a robot attól robot, hogy nem távirányítod.
Ha modulárisan építi fel az egészet (átgondoltam, gyorsan bővíthetően), akkor egyenlőre egy az egyben megfeledkezhet minden szenzorról. Ha már mozog ,nem előre definiált formákban (magától számol mindent), akkor lehet nekikezdeni a szenzoroknak mivel addig nem tud semmit sem kezdeni a szenzorok adataival.
Nem tud magától mozogni, ha nincs visszajelzés. Kizárólag ideális környezetben, amit ugye csak az elmélet ismer. Az aktuátorok elkerülhetetlenek. A robotika önszerveződésének elkerülhetelen eleme.
Gondoljatok bele, hogy honnan tudja a robot, - akár sík asztallapon - hogy melyik lába érintette már az asztalt. Az nem referencia, hogy a szervó ilyen-olyan impulzus hatására ebbe és abba a szögbe áll be. Remélem így érthetőbb. Mivel G-Lex kész gerinc tervek alapján dolgozik, ezért javasoltam az aktuátorok betervezését. Még időben...
Ez mind igaz, viszont ahhoz, hogy megteremtse az alapokat egyenlőre "ideális környezetben" kell dolgoznia.
Először csak 2D mozgással kellene kezdeni és utána a komplexebb mozgásokkal (forgás, dőlés, stb..) Ha már egyesével tudja a lábaknak megadni, hogy "ott a föld azt a pozíciót tartsd" akkor lehet bevezetni a visszajelzést mert , ha rögtön az elején kezdi beleírni, akkor belebolondul.
először mindenképpen azt kell elérnem, hogy ideális környezetben megadott vektorok alapján mozogni tudjon. Tehá maga számolja ki, hogy hova kell helyeznie a lábát. Amikor ideális környezetben biztosan mozog, utána lehet szépen lassan felkészülni a terep adaptációra. A lábak talajérzékelő szenzorait mindenképpen tervezem. A Gyrooscopot is bele akarom majd rakni, valamint egy gyorsulásmérőt. A fejére sonárt akarok építeni.
A szenzorok mind mind 1-1 modul. A bővítés során csak bele kell rakni a vezérlőbe, hogy a szenzor jelei felülbírálhatják a számított értéket. Egy modul pedig akkor van kész, ha a panelja rendezett és maratott, nem pedig próba nyák. A panelján rajta van az ICSP és a megfelelő kontroll ledek. A szoftverje pedig kitisztázott átlátható. Ha ezt a rendszert követem akkor később sem lesz nehéz beletenni új funkciókat. Bár a szenzorok funkciói így sem kritikusak, hiszen azok szerepelnek a tervembe így a fejlesztés folyamán folyamatosan meghagyom neki a helyet.
Braf: nem JDM, csak JDM szerű! Leginkább Watt kolléga oldalán található kapcsoláshoz hasonlít, csak nem kapcsolóüzemű tápja van, hanem sima trafóról kapja a 14V-ot.
Én az SPI mellett döntöttem, mert azzal jóval nagyobb sebességet tudok elérni és a több bájt küldése sem okoz majd gondot.
googa: még valami: step-by-step
A terv egész, az elmélet kész és egész, a logika megvan... A megvalósítás pedig lépésről lépésre...
Remélem néha beszámolsz majd, ahogy haladsz, mert ez érdekes és szép feladat, és legkevesebb, de engem érdekel a kifejlet!
Annyit még esetleg, hogy ha nem is építed be első körben a felvetett érzékelőket, de a tervedre rákerülhet! A rajz mindent elbír, és ha moduláris lesz, akkor milyen jól fog jönni mondjuk egy tüskesor, amire rádugod a következő modult. Nem is kell igazából előre kiosztani a lábakat, de arra lehet ügyelni, hogy például egy CCPx kimenetet ne használj el egy LED-re, ha arra van másik láb is. Sok sikert!
Örülök, hogy ennyi embert érdekel a téma.
A rajzon, illetve a fejlesztési ütemtervemben benne vannak a szenzorok, hiszen egy jó robot attól jó, hogy nem nekem kell minden egyes ízületének a pontos pozícióját megadni, hanem irányvektorok alapján maga cselekszik. Ehhez viszont nélkülözhetetlenek a szenzorok. A fő buszrendszert úgy képzeltem el, hogy a panelon rajta van egy vezér PIC, ami a master szerepet tölti be az SPI kommunikációban. Hosszú párhuzamos vezetősávokat alakítok ki, amin rajta lesz a +5V, +7V GND, SCL, SDI, SDO. Ezen a buszon 16 precíziós tüske aljzatsor lesz. Tehát 16 modult tudok maximálisan rákötni. A kommunikációs protokoll még nem végleges Természetesen minden fejleményről bes fogok számolni. Ha végre sikerül beindítanom a projekt weboldalát, akkor ott is mindent részletesen leírok. Bár eddig is minden egyes gondolatomat megosztottam veletek
Próbáltam jó elektronika szakember lenni és nem elmenni abba az irányba, hogy csak PIC és más semmi...
555-ös timer + néhány alkatrészből lehet összerakni egyszerű szervó vezérlőt. Ha digitálisan akarom szabályozni akkor kell hozzá egy digitpoti is. 18db 555-ös (vagy 9db 556-os) + 18 digitpoti (vagy 9db 2csatornás) kb annyiba kerülne mintha mindegyik szervó külön PIC-et kapna
Üdv!
Idézet: „Örülök, hogy ennyi embert érdekel a téma” Engem is érdekel, eddig csak olvasgattam, hogy haladsz, mer nem volt hozzáfűzni valóm. Az 555-ösök használata jó ötlet volt, sokkal egyszerűbb 18 db digitpotit kezelni, mint szoftveresen a szervókat. Amit én ehhez hozzáfűznék, az az, hogy dual digit potikat használj. Ezeket ugye SPI-n lehet szábályozni, tehát mindegyik potin van SCLK, SDI, CS pin. A data/clock vonalakkal nincs gond, össze lehet őket kötni, de 18 CS pinhez 18 IO kéne a PICen, ami finoman fogalmazva is sok. Dual potiknál elég 9 pin Továbbra is figyelemmel kísérem majd munkásságod, sok sikert!
Én már annyiszor feltaláltam a digitpotit, mivel nem tudtam róla. Megneveznétek egy itthon sűrűn kapható és megbízható típust? Köszi!
|
Bejelentkezés
Hirdetés |