Ez nem olyan szervo, aminek a pozícióját egy adott impulzusszélesség határozza meg?

Van itthon pár ilyen szervóm. Atomnagy a szórásuk, hogy melyik mennyi áramot vesz fel. Amúgy miért nem piszkálod meg a benne lévő elektronikát? Simán bontható, módosítható. Benne lévő potiról tudsz visszacsatolást nyerni a pozícióról, ha hozzáforrasztasz a középső lábához egy vezetéket (sima feszosztóként viselkedik, illetve ha jól emlékszek egy az egyben a vezérlő IC adatlapján lévő kapcsolás van megvalósítva benne).
Áramfelvétel mérése max a körülbelüli terhelés méréséhez jó. Most ha vízszintesen van a kar, akkor sokkal többet kell dolgozniuk a szervóknak, hogy egy helyben tartsák mintha függőleges pozícióban állna (gravitációs erővel bezárt szög -> nyomaték). Ez alapján esélytelen az elakadást biztosan detektálni.

Valahogy csak összerakták azt a szervót. Ha nekik sikerült összerakni, akkor szét is lehet szedni. És mint előttem írták, elég sok tényező befolyásolja egy szervó áramfelvételét. Bár ha a tényleges maximumot nézed, egyenként leméred mindegyik szervó max áramát és programban ehhez állítod be külön minden szervó áramlimitjét, akkor talán működhet.

Téma címét módosítottam, az erre utaló hozzászólásokat kivettem.

A problémához: könnyűszerkezetes gép esetén én elgondolkodnék azon, hogy a csuklópontok környékére apró mágnest (vagy mágneseket) ragasszak, és megfelelő pozícióban szintén felragasztott analóg mágneses érzékelőkkel (pl. SS49), a mért térerősség(ek)ből határozzam meg a kar pozícióját. Kellően szilárd építés esetén, ismert nagyságú terheléssel csak egyszer kellene kalibrálni: végigvinni "faltól falig", közben kívülről pozíciót, a szenzorról pedig a kimenetét mérni, a végeredmény ezek után a térerősség-pozíció összefüggés lesz.
A motor helyzete ebből csak áttételesen tudható meg, ha ennél pontosabb megoldás kell, szerintem is marad a szervó szétszerelése, átalakítása.

Illetve, még egy ötlet: ha lenne pár milliméter szabad hely a motor elejénél, a tengelyére fel lehetne szerelni egy - pl. egérből kibontott, vékonyka - jeladótárcsát, ami egy rés-optót vezérelne. Mivel bekapcsolás után a kiindulási pozíció ismeretlen, először referenciát kell felvenni: elvinni az egyik végpontba, és amikor hajtott állapotban a rés-optóról megszűnnek az impulzusok, ott a nulla pont. Hajtásirány fordításával átmegy a másik végpontba, a koppanásig beérkező impulzusok megadják a teljes bejárható pálya "hosszát", ebből pedig az impulzusszám-karpozíció közti összefüggés már számolható, azaz megvan a szabályzáshoz szükséges visszacsatolás.

A Hall szenzorokrol es a magneses szogerzekelesrol nezzed nem ezt, es az utana kovetkezo hozzaszolast:
Bővebben: Link

Valami hasonlo megoldasra gondoltam:
Bővebben: Link
Persze itt szervonkent csak 1 Hall szenzor kell...

Nos de ez egy ilyen szervó, de attól függetlenül még valahogy vissza kellene mérnem, mert ugye a kiadott impulzusszélesség az csak egy dolog az elakadást nem jelzi.....
Menet közben feladtam a küzdelmet mert a legegyszerűbb megoldás valóban a poti kivezetése, így elég barbár módon de a vége az lesz, hogy megbontom a szervókat...
Azért köszönöm mindenkinek a segítségét!

Nos egy igen komplikált feladathoz kellene kiépíteni valamiféle hálózatot.
A feladat, van egy robotkar, a robotkart összesen 3 Atmega162 fogja vezérelni (9 motort, csuklónként 2, 2 a fogóban, 1 a talapzat). A motorok helyzetérzékelő potenciómétere-i kivezetve.
Mivel a potik jele analóg ezt ugye még fel kell dolgoznom, legegyszerűbb ha muxolom, majd be az ADC-be és a kijövő jelet vissza az adott mikrokontrollerre ami meghajtja a szervót. Erre a célra egy Atmega16 tökéletes, mármint az ADC-re.
A probléma: Az alap helyzetet, hogy honnan hová forduljon, azt a számítógépről fogja megkapni egy erre készített szimulációs programon keresztül. Innen soros portos kommunikációt terveztem ami viszi a panelra az infót, és innen szórom szét a 3 vezérlő mikrokontrollerbe (mivel dual Usart-osak az ATmega 162-sek, az első leveszi ami neki szól, és a maradékot tovább küldi, és így tovább, tudom nem a legjobb megoldás, de ide elég). Ezzel egy sima vezérlést meg is valósítottam, a probléma, hogy min keresztül küldjem a szenzorok (már) digitális jelét az adott meghajtó mikrokontrollerekbe?
Ugye lehetséges megoldás az SPI, de arról nincs valakinek valami tapasztalata, hogy nem akad össze az USART-tal? tehát mind a 2 kommunikációt párhuzamosan üzemeltethetem? Mert akkor megtudnám oldani, hogy a szenzorok eredményét visszaküldöm a meghajtó mikrokontrollerekbe, azok tesztelnek, hogy tényleg ott áll-e a kar ahol kell, majd küldik szépen sorban vissza az előtte lévő mikrokontrollerbe, ami hozzáírja a saját adatait és így tovább megy vissza a PC-be ami, ezáltal tud egy real-time képet szolgáltatni a robotkar helyzetéről.
Elég bonyolult megoldás tudom, de kivitelezhető-e? illetve van-e jobb megoldás? Vagy elég lenne ha az első mikrokontrollerig menne az Usart onnan I2C a másik 2 mikrokontroller felé, a szenzor jelét feldolgozó Atmega16-ból pedig Demux és a megfelelő Usart-portra küldöm az adatot, ahonnan az I2C-n keresztül megy vissza a legelső Atmega162-be, az összegyűjti és továbbítja a PC-re...
A tökéletes megoldás a CAN lenne, de az nem túl költséghatékony...

Szia,
Szerintem az I2C a legegyszerűbb kontrollerek közt.
Legalábbis ha két irányba akarsz beszélgetni. Pont egy hasonló robotkaros projektben vagyok, az első verziós rs232 vel beszélgetett pc vel. Sajnos ez nem volt túl hatékony, egy master procival viszont annyi időt nyertem a kommunikáción, hogy az inverzkinematikát át tudtam tenni lebegőpontossá így már 6 tizedesre jó minden szögérték (nem utolsó sorban az egész rendszer szabadon bővíthető)

Ezek a motorok szervo motorok? Mert ugy azoknal a pozicio huen koveti a vezerlo jel kitolteset. Igy nem igazan fontos a poti olvasasa. De ha megis szukseges akkor a uC rendelkezik eleg AD bemenettel. Ez ugye egy uC 9 analog bemenet, es 9 szervo kimenet. Ez nem lehet nagy feladat egy 40 labas uC-nek. En csinaltam 8 csatornas vezerlest, igaz csak 6 csatornat hasznaltam, ilyen kar vezerlesehez. A PC SW vezerelte RS232 porton. A uC egy 16F627A volt. Persze en nem vizsgaltam a poti jeleket. De ha kellett volna akkor is bele fert volna egy 28 labasba. De vegulis a tobb procis is megoldhato SPI kommunikacioval egy master, es CS vonalakkal. A master kommunikal a soros vonalon a PC fele, es irja olvassa a slave procikat. A SPI nem szokott osszeveszni a soros vonallal. Nekem mukodik igy rendszerem, igaz PIC uC-vel.

Igen szervo- és tudom, hogy elméletileg Hűen, de ez meg szakdolgozat, és mindenképp szükséges valami biztosíték arról, hogy a kar nem akadt el, ergó a mozgásterébe nem került valami...
A szervó vezérlés meg PWM-en keresztül oldható meg, PWM meg csak 4 van benne Ezért ez a sok mikrokontroller, nem a láb a kevés.
Az Atmega162 meg nem tartalmaz ADC-t csak az Atmega 16, az is csak 1-et ergó a mux is muszáj...
Ellenben az hasznos infó hogy az SPI nem kötekszik az Usart-tal...
Zozi85: Minek 6 tizedesig tudni a szögértéket? Jelen esetben ha teljesen nyújtott a kar és a vállán mozgatok 1 fokot, az sincs még fél centi sem tehát ilyen szempontból nem érint a dolog Ellenben az I2C jónak tűnik ahogy látom egész gyorsra feltornázható a sebessége, és ha az SPI nem veszekszik az USART-tal akkor az sem fog.
És akkor lesz 2 master, az egyik a fő kommunikáló, ami a PC-nek küldi azonnal a potik adatait, illetve egy másik master ami a potik adatait feldolgozza és kiküldi I2C-re a megfelelő vezérlő kontrollernek, az meg továbbítja a fő kommunikáló kontrollernek, csak ugye mivel mindnek mindet be kell várni, remélem mér relative gyors lesz a rendszer...

Azaz módosítom NINCS BENNE I2C ÁÁÁHH megőrülök.... csak a 168-ban van, de abban meg dual USART nincs... mondjuk arra nincs is szükség, hisz csak a fő kontroller kommunikálna USART-on a PC-vel, minden más i2c...

Nem fontos dedikált hw-es perifériát használnod a szervovezérléshez. Ez annyira lassú jel, hogy simán tudod sw-esen meghajtani megszakításból. 8 rc szervót (kiterjesztett módban is akár) meg tudsz hajtani 3 lábáról a mikrovezérlőnek (kapuzott shift regen keresztül). Lényeg az, hogy a magas jel ideje uS pontos legyen. Ez mai mikrokontrollernek nem okoz problémát.
Ajánlom nézd meg a Lynxmotion SSC-32 vezérlőjét (open source ha jól emlékszek).

Azért nézd meg ha mindenhol van csak fél fok hiba elég nagy eltérés jön ki a végén. Persze ha a pontosság nem fontos akkor nem kell.

Annyira azért ne dühöngj az I2C hiánya miatt. Egyrészt átlag uC-rel 400 kHz a maximális adatátviteli sebesség, másrészt 15-20 cm-nél nem tud többet, csak ha jelentősen le van lassítva a kommunikáció sebesség. Szóval nem igazán ilyesmire tervezték ezt a kommunikációs szabványt.

Ez mindaddig igaz is, amíg a kontroller nem használ egyéb megszakítást. Ugyanis, ha nincs prioritásos megszakításra lehetőség, akkor egy folyamatban lévő megszakítás eltolja az időzítést és a szervo vezérlőjele jitteres lesz, melynek hatására a szervo remegni kezd. Érdemes hardveresen megoldani, például CCP modullal.

Igen a megszakítások egymást is üthetik, meg az egyébként sem túl elegáns megoldás, PWM-en keresztül konkrétan 1 regiszter értékének módosítása elegendő, olyan mintha a fok értékeket adnám meg neki, a konverzió is ezerszer kevesebb számítást igényel

Nem dühöngés ez, csak így most csinálhatom SPI-al ami több slave esetén nem tűnik annyi barátságos megoldásnak (mellesleg, ha több slave-t szeretnék és egy mastert és csak egy Slave Select kimenetem van, akkor hogy oldom meg??? Mindegyikhez azt húzom be, és az a mikrokontroller kapja meg amelyiknek épp aktív a Slave Selectje? valahogy az I2C címzéses megoldása sokkal szimpatikusabb)
most ott tartok, hogy egy 3 kontrollerből álló mini hálózatot hozok létre amiben 2 eszköz egymással USART-on keresztül kommunikál(illetve az egyik szintén USART-on a PC-felé is) egy harmadik (ez lesz ami a potik jelát feldolgozza és szétszórja) pedig SPI-on tolja mindkettőnek az infót. De ugye ez kis időbe telik tekintve, hogy 1 programozóm van és mindnek szépen működnie kell....

Van egy jó hírem! Van az Atmega16-nak is I2C perifériája, csak az Atmel azt TWI- nek hívja (Two-wire Serial Interface). Gyanítottam is, mert a legtöbb esetben van az SPI mellett I2C periféria is. Én leginkább PIC kontrollerekkel foglalkozok, így csak az adatlap átnézése után tudtam ezt írni. Szóval ha mindenképpen I2C-vel szeretnéd, akkor van rá lehetőséged!

Ja, azt hiszem félreértettem a helyzetet. Neked az Atmega162- be kellene az I2C? Akkor az tényleg probléma, mert annak, ha minden igaz, akkor tényleg nincs I2C perifériája. Bocs a figyelmetlenségért.

Így van a helyzet az, hogy az atmega162 a sok PWM generátora illetve a dual USART miatt tökéletes, ellenben sem I2C sem ADC nincs bennük... Ezért marad egy atmega 16 ami a potik jelét dolgozza fel és akkor marad az SPI...

És arra nem gondoltál, hogy RS-485 kommunikációt használj (half-duplex bus)? Egyrészt nagyobb távolságokon is megbízható, olcsó, valamint akkor a kommunikáció megoldható 2 vezetékkel. A logikai protokoll pedig lehet valami Modbus szerű, master-slave jellegű. A kontroller oldaláról csak egy USART modult igényel, az pedig mindkét típusban megtalálható.

Bocs hogy belevau, de muszaj Atmel? Mert a 18F4431 ilyen jellegu feladatokra van kitalalva. Van benne 4 power PWM generator 8 kimenettel, 9 gyors AD, SPI/I2C, UART, mozgas visszacsatolo (Quadratura enkoder) modul, HW szorzo. Van belole kisebb is a 18F2431. Persze ha eloiras az ATMega hasznalata, akkor ezt kell hasznalni.

Ha nincs prioritásos interrupt akkor meg kell oldani sw-esen azt is. Abszolúte nem nehéz. Mcu belép az interrupt kiszolgáló rutinba, elmenti amit kell egy memóriaterületre majd megnézi, hogy ez a megszakítás magas prioritású, ha igen végrehajtja, ha nem akkor az elmentett adatokat átmásolja egy másik memóriaterületre és újra engedélyezi a megszakítást. Innen már érthető gondolom. (persze ilyenkor le kell tiltani a többi alacsony szintű megszakítást hogy ne hívódhasson meg 2x alacsony szintű) 20mips fele rohangáló mcu 2-3uS alatt elintézi.

prody:
Amúgy ha nagyon trollkodni akarok, akkor azt mondom, hogy attól hogy van hw-es pwm modulod, azt nem ilyen nagy felbontásra tervezték ilyen hosszú periódusidővel (kivéve ha 16 bites). Ha nincs hozzá jitter kiküszöbölése végett latch akkor ez nem probléma mert egyből reagál a regiszterbe írásra, de ha van akkor csak a következő ciklusban. Emiatt trükközni kell, hogy mikor válts periódusiőt (egyszer 2,5 ms, majd 17,5 ms és így megfelelő felbontása lesz a szervónak).
Én biztosan úgy oldanám meg, hogy 4 lábra 2db 8 bites kapuzott shiftregisztert kötnék (2*data,clock,gate), majd nagyfelbontású időzítővel sw-esen generálnám a jelet. Ha van elég IO, akkor egyszerűbb a dolog persze mert minden szervó közvetlen mehet az mcu egyik lábára.

Ha nagyon egyszerű mcuk közötti kommunikációt akarsz, akor 9 bites aszinkron soros kommunikációt ajánlok. 9. bitet használod mint adat/cím jelzőt.

SPI: a slave select az csak egy lehetőség. Arra találták ki ha 1 eszközzel akarsz kommunikálni hw-esen pl DMA-n keresztül. Most külön HW-es ss lábakat akarsz minden egyes slave-hez? Már nemazért de ilyen megerőltető egy a master akármilyen IO lábra rákötni a slave SS lábát majd egy utasítással alacsony szintre állítani mikor azzal a salve vel akarsz kommunikálni és ha befejezted akkor magasba állítani? 2 utasítás.

Gondolom nem akarod az mcu kkal az avatar következő részét renderelni úgyhogy rengeteg szabad cpu idő marad.
Szervó jel generálás interruptból SW-esen, SW-esen megvalósított prioritásos megszakításrendszerrel max 5-10% cpu időt eszik meg. Mivel nem kell másodpercenként több MB ot mozgatni a pc-mcu-mcu között ezért az sem foghat le túlsok cpu időt. (pl 100hz, 9szervó*2byte pozíció + 9*2byte analóg visszacsatolás a potikról + 16 byte egyéb adat csakúgy tartaléknak = 5,2kB/s adatmozgás. Ezzel a 115,2kBaud os soros port simán megbirkózik)
AD konvertálás nemhiszem hogy 10-20 utasításnál többet igényelne / csatorna. Ez megint csak 1-2uS ami alatt aktívan csinálni is kell valamit. Amíg vár az mcu az AD időzítésekre (belső kondi feltöltődése) addig lehet mást csinálni.

Túl sok mindent akarsz HW-esen megoldani. Ezekre ott az FPGA.

Sziasztok ! Még kezdő vagyok , én is egy robot kar építésén ügyködöm . bocsi a hozászolásomért , ha már elhangzott is . Van nekem 6db pici hxt900 servo motorom , ehhez szeretnék építeni egy shield féleséget . Ahogy olvasgattam , minden motor elé egy 100 qF os kondenzátort kell építenem , ezen kívül , hogyan érdemes csinálnom ? Arra gondoltam , hogy pwm lábakról még 6 ot el tudok vezérelni , ezért egyenlőre plusz chipet nem terveztem bele rakni . Elektronikai ismereteim még nem túl széleskörűek , ezért ha esetleg egy kapcsolási rajzot ismerne valaki ebben a témakörben , azt nagyon megköszönném . Megjegyzés : Sokat keresgettem , és én úgy találtam , hogy a motorok , kb 400 mA on működnek , és 4,8-6 V a működési tartományuk , milyen táppal , elemekkel tudom megoldani ? nem szeretném használni az arduino belső 5V -ját . válaszokat előre is köszönöm

Sziasztok,
Kaptam egy Festo kezdőkészletet, amin van egy Mitsubishi VR-2AJ robotkar.
Kicseréltem az elemeket a robotkarban, de a kalibrációs értekek és a rajta lévő demo program elveszett.
Annyira sikerült elindítsam és bekalibráljam, hogy a kézi vezérlővel tudom irányítani.
Mitsubishi CR1 vezérlője van, ehhez milyen "ingyen" beszerezhető számítógépes programok vannak?
CD lemezen van egy program (aminek a neve most nem jut az eszembe), de az egy USB-s dongle-t kér, amit nem találtam meg a robottal kapott kacatok között, de még utánna nézek.
Ha valaki tud segíteni bármilyen információval is, azzal fel szeretném venni a kapcsolatot.
A választ előre is köszönöm!