Fórum témák
» Több friss téma |
Sziasztok!
Egy vonal követő robot építésében gondolkodok. Már vannak ötleteim, de egy problémával nem nagyon tudok megbírkózni. UV-vel akarom megvilágítani a fehér papírt, amire fekete csíkot (útvonal) húzok. Két fototranzisztor érzékeli a papírról vagy fellületről visszaverődő UV sugarakat. Ha a két tranzisztoron közel ugyan akkora a feszültség, akkor elvileg ugyan olyan messze van a fototranyóktól a fekete csík. A problémám a következő. PIC-el akarom megoldani az eszköt vezérlését. Viszont arra nem jöttem rá, illetve nem találtam programrészletet, hogy hogyan tudom eldönteni, hogy a két fototranzisztor által szolgáltatott jelből, mely digitális jellé lett alakítva melyik a nagyobb. Ezért kérlek Benneteket, ha van ötletetek, akkor írjátok meg. Segítségeteket előre köszönöm! MaGor
Szerintem 3 fototranzisztor kellene, és a robot arra törekedne, hogy a középső a vonal fölött legyen, a két szélső, meg sose legyen a vonal fölött. Ezzel a módszerrel az a baj, hogy elég szélesnek kellene lennie a fekete vonalnak. (de pl a vonal lehet szigetelőszalag is) (remélem érthető az elgondolásom) De szerintem még PIC sem kellene, ha nem ki lehetne pakolni ligikai kapukból a vezérlést...
Szia !
Köszönöm a válaszodat. A három tranzisztoros változaton én is gondolkodtam. Minden esetre ezt a verziót sem vetem el. Viszont a problémám az, hogy a szoftveresen nem tudom eldönteni hogy a két byte közül melyik a nagyobb illetve kisebb. Minden esetre köszönöm az ötletet! Üdv: MaGor
Szerintem ezt analóg módon könnyebben meg lehetne oldani (kis ablakúra tervezett
 ) ablakkomparátorral...és akkor még csak át se kéne alakítani a "szenzor" jelét...
Szia !
Köszönöm a választ. Analóg mód semmiképpen sem jó, mivel egyéb vezérlési feladatokat is el kell látni. Köszönöm az ötletet! MaGor Idézet: „Viszont a problémám az, hogy a szoftveresen nem tudom eldönteni hogy a két byte közül melyik a nagyobb illetve kisebb.” Használj valami magasabb szintű programnyelvet.
Szia!
Köszönöm a "remek"  ötletet. Ezúton szeretném megkérni a "kedves" hozzászólókat, hogy a fatális baromságoktól kíméljenek meg. Természetesen az építő ötleteket szívesen fogadom!
De én nem értelek... Miért nem elég a 0, és 1. 0 ha visszaverődik a fény, 1 ha nem (vagy fordítva, mind1). Két motorral hajtsd meg a hátsó kerekeket, előre meg egy elforduló kereket rakj. És a két motorral tudod iráyítani. Ha csak a bal hátsó forg, akkor jobbra, ha meg a jobb hátsó, akkor meg balra fordul...
Szia!
Köszönöm a válaszodat. Sajnos a problémám nem ilyen egyszerű. A fototranzisztor emitteréről egy feszültség értéket veszek le. Gyakorlatilag feszültség nagysága mutatja meg, hogy mennyire közel vagy távol van a tranzisztortól a fekete csík. Ha Norberto ötletét megvalósítom, akkor csak azt tudom megmondani, hogy a tranzisztor előtt van e a csík vagy sem. Azt nem tudom megmondani, hogy milyen messze van. Ezt tranzisztor emitterén a feszültséget a PIC A/D átalakítójával digitalizálom. Ha a két byte értéke közel azonos, akkor jó úton jár a robot. Ha nem, akkor a nagyság alapján tudom a motorokat forgatni. Ha egyik tranzisztor sem látja a csíkot, akkor pedig lassan körbe kell forgatni a robotot, hogy a helyes útra térjen. A PIC egy PWM jellel vezérli a H-hidat, így a sebesség is állítható lenne. Azért köszönöm az ötletedet. Végiggondolva biztosan járható út lenne... Baráti üdvözlettel: MaGor Idézet: „Miért nem elég a 0, és 1?” Hát én a múltkor láttam egy vonalvadász robotot (pontosabban egy videót róla)...szegényke elég viccesen mozgott a vonalon :guluszem1: Szerintem annak a fejlesztője is hasonló módot tervezett, ahogyan te elkészítenéd... A módszerrel az a baj, hogy a 0 és 1 között nincs semmi átmenet...mert ha csak félig van épp rajta a vonalon, akkor azt hogyan tudja megkülönböztetni? 0? vagy inkább 1? Az egyik lehetőségre tippel, elindul max kormánymozdulattal az ellenkező irányba, közben a járgány nagy lendülettel átlépi a vonalat, és a másik irányba csalinkázik...itt megintcsak gyorsan áthalad a csíkon, és amikor ferdén áthalad a csík fölött, akkor a végén megint azt látja, hogy nincs csík...megint max kormánymozdulatot tesz, és most a másik irányba lendül...így olyan csalinkán fog mozogni még az egyenes vonalon is, hogy az csak na...nem viccelek, ez tény! Mondom, láttam ilyen megoldású robotról videót nemrég... Én inkább azt próbálnám meg, ha már normálisan kell követni a jelet, hogy a jármű elejére és végére is tennék egy-egy ilyen szenzort...és a két "rendszert" kapcsolatba hoznám egymással, így a járgány elején lévő érzékelő lehetne úgymond az "előjelző"...sokkal, de sokkal stabilabban tudna követni vonalakat... Egyébként az ablakkomparátor említésénél azért tértem ki a "kis ablakra", mert egy ilyennél meg lehetne tervezni, hogy mennyi legyen az a maximális távolság, ami még belefér (magyarul a jármű még láthatónak tekinti a vonalat). Ha az ablakkomparátor "ablakát" kibővítjük, akkor nyilván növekedik a "letapogatott" terület, többet fog csalinkázni az autó. De ha keseknyre vesszük az "ablakát", akkor viszont pontosabban fogja a vonalat követni. De közben azt tudni kell, hogy az abalakkomparátornak két kimeneti állapota van...logikai 0 és logikai 1 Szóval ez is "elvetendő" a fentebb leírtak szerint...
[off]ez jó, teccik
 Az egyik lehetőségre tippel, elindul max kormánymozdulattal az ellenkező irányba, közben a járgány nagy lendülettel átlépi a vonalat, és a másik irányba csalinkázik...itt megintcsak gyorsan áthalad a csíkon, és amikor ferdén áthalad a csík fölött, akkor a végén megint azt látja, hogy nincs csík...megint max kormánymozdulatot tesz, és most a másik irányba lendül...így olyan csalinkán fog mozogni még az egyenes vonalon is, hogy az csak na...
Ennyire precizen mérni akarsz?
A szoftvered indulás előtt be is "kalibrálja" magát ? Mivel a 2 optotranya erősen különbözhet is  megvilágítás / Ic karakterisztikában Mivel ebből jön létre valamekorra fesz amit ADre vezetsz akkor igen nagy hibákat különbségeket kaphatsz az eltérő lux/Ic miatt . Minden eddig látott ,fénycsík követő robot projekt megelégedett egy olyan 2 állapotú jellel hogy van csik nincs csik igen/nem 1/0 és kész... nem vergődtek azzal hogy most 3 - 5 -20 milimeterre van a csíktól. Sztem mechanikusan se egyszerű olyan eszközt csinálni házilag aminek a tehetetlensége/lötyögése megbírkózna azzal , hogy plusz 2tized miliméter balra ... akkor már okés a csík közepe/széle .... Másik probléma: Mivel neked elég gyorsan változó jelből kell AD értéket kapnod ezért az ucsó bitek eléggé billegősek lesznek. Ez is hiba forrása lehet .Stabil AD érték és nagy felbontású AD átalakítás csak hosszú idejű méréssel lehetséges, és azoknak is az értékek átlagolásával. Pl.: léteznek 20-onX bites AD-k is 1-5 voltos referenciával. Ezeknél hosszú mérési idővel az ucsóbit billegési hibákat kiküszöbölik.(pl perces mérési periódusokkal ez időalatt 50-100 mérés átlagát veszik). De ekkora már régen lehjtott a robotod a csikról és a piretező mozgás mérési ciklusát kezdheti ... mert nem találja acsíkot .. nincs csik akkor körbe körbe ... Idézet: „Minden eddig látott ,fénycsík követő robot” Miért vagy te ebben olyan biztos??? Kérdem én... TÁNCSAK nem okosabb vagy mindegyikünktől, és táncsak nem láttad a világ ÖSSZES ilyen robotát? Pl. ha én ilyen terveznék (de nekem egy ideig nem kell ilyen szerintem), marhára nem elégednék meg egy ilyen igen/nem jellel...és biztos a rajtam kívül lévő 6 és fél milliárd emberből van olyan, aki éppen épített is egy ilyesmi robotot, és nem elégedett meg a 0/1 lehetőséggel...szerintem van profi robot...
Sziasztok!
Köszönöm a válaszokat. Kera_Will teljesen igazad van az utolsó bitek billegése, valamint a mérési pontosságot illetően. Norberto ötletét is érdemes megfontolni abban a tekintetben, hogy egyáltalán kiszürje az ember a megfelelő értékeket, amik az A/D bemenetére jutnak. Kicsit tovább gondoltam a fent írottakat. Ha a robot elejére egymástól egyenlő távolságra, de viszonylag sűrűn tranzisztorokat helyezek el, akkor sokkal egyszerübb dolgom lenne. A tranvisztorból kijövő jeleket egy schmitt-triggeres bemenetű nem kapura vezetném. (bemenetén el tudja dönteni, hogy kellő távolságra van e a fekete vonal, vagy sem, így akimenetén megfelelő TTL szintet ad).Ekkor magát a komparálást elvégezné a kapu. Ha a schmidt trigger kimeneteit a PIC-be vezetem, akkor már meg tudom mondani kellően pontossan, hogy mi a jó irány. Ezzal a megoldással kiküszöbölném az A/D-t és a program is sokkal sokkal egyszerübb lenne.Ha mégsem lenne a schmitt triggerek kimenetén jel, akkor egy kis idő elteltével lassan körbe lehetne forgatni a robotot, hogy megtalálja a helyes irányt. Kérlek benneteket, hogy írjátok le, mi a véleményetek a fenti ötlettel kapcsolatban. Üdv: MaGor
ez jó csak megint feleslegesen 1 ADt épitesz ami gyorsabb mert párhuzamos AD-t csináltál
... sok tranya 1más mellett ... de nem lesz jobb a helyzeted DE sztem elég 2 darab tranya ... eltakar nem takar .. 1 1 0 0 10 01 ezeket azálapotokat veszi fel .... ebből eldönthetedd mit lát a robot ..
A profi robot nem csíkot követ hanem már lassan "bármit" ... akár téged is
.Csak az érzékelők / jelátalakítók és a hozzá kapcsolódó kiértékelő rendszerek függvénye és bevatkozó szerveké.Lásd DARPA versenye ... önirányító autók 100 mérföldes versenye 1ik sivatagon keresztül. De ott sajna a homokdűnék rámásztak a fekete szigszalagomra és ezért csak körbe körbe forgott a robotom ... én is tévedhetek .... 
Szia!
Köszönöm a válaszodat. Most viszon nem értek egyet Veled. A terepet, amin a robot közlekedik, előre meg lehet (meg kell határozni). tehát, csak egyetlen csíkod van. Ha meg még is több különböző állapot érkezne(zavarok, takarás, vagy egyéb miatt) és ennyire szerteágazóak lennének a helyzet állapotok, mint amit példának felhoztál, akkor is van megoldás. Szoftveresen viszonylag könnyen lehet detektálni, hogy melyik bit változott meg utoljára. Így csak egyetlen érték változik meg. MInden esetre azt hiszem egyesítve a fenti kiváló ötleteket és észrevételeket a több érzékelős verziót fogom megpróbálni. CSak már lenne hétfő, hogy tudjak venni cuccokat Továbbra is várom az ötleteket és a tanácsokat. ÜDv: MaGor
Ha közvetlen AD-átalakítást alkalmazol a fototranyók jelén (ellenálláshíd és komparátorok mindkét érzékelőn), akkor azonnali értéket kaphatsz az aktuális (pillanatnyi) állapotról. Így nem lenne leterhelve a központi egység, tehát a "meddő" értékszámítás helyett mással tudna foglalkozni, és csak "néha ránézne az érzékelők értékére". Esetleg (elméletileg) az értékek bizonyos szintű megváltozásakor generálhatna egy megszakításjelet a pic felé, és csak akkor foglalkozna a központi egység az érzékelőkkel. Ha az értékeket közvetlen a motorvezérlőbe küldjük, akkor központi procnak alig akadna dolga a motorokkal és az érzékelőkkel. Hátránya ennek a komparátoros egységnek a viszonylag nagy méret és a kis felbontás, de úgy sem 44KHz-s sztereó hangjelet kell feldolgoznia 256 Biten
.De van egy másik ötlet is: A fototranyó jelét egy-egy komparátorral feldolgozni. A komparátorok egy közös referenciaponthoz képest fognak viszonyítani. Ezt a referenciapontot kellene modulálni (amolyan fűrészfogjellel), hogy "lassan" emelkedjen a feszültsége. A pic egy kisütő impulzussal indítja el a folyamatot, valamint törli a belső számlálóját. Ahogy elengedi a refpontot, elindítja a számlálást is, és figyeli a komparátorok jelét. Amikor az egyik komparátor szintet vált, a számláló pillanatnyi értékét el kell (lenne) tárolni, valamint a szintet váltó komparátort is. Amikor a második komparátor is szintet vált, le kell állítani a számlálót és kiértékelni a kapott eredményeket. A pic korrigál és elindít egy újabb érzékelő-figyelőciklust. A két érték különbsége, adja a pillanatnyi pozícióértéket. Az első eltárolt értékkel talán a távolságot lehetne megbecsülni (vagy kitudja, hogy mire lenne jó, esetleg a saját fényforrásának fényerő-szabályozására is fel lehetne használni). Így megoldható az érzékelés kevés alkatrésszel és három porton keresztül, két be és egy kimenettel. Ez az eljárás egy kis procidőt elvon a kiértékelés alatt, és addig a járgány vakon közlekedik. Én erre az okosságra jutottam... Hátha hasznát veszi valaki. _jani_
Egy vázlat a számlálós változat, optikai érzékelőjéről...
A csillaggal jelzett alkaltrészek csak a szimulációhoz kellettek.
Szia!
Köszönöm a kiváló ötletet. Nagyon tetszik ez a megoldás, mivel nem terheli le nagyon a processzort. Tényleg jó ötlet hogy a komparátor jelezze, ha be kell avatkozni, mert akkor már eléggé nagy az eltérés a robot helyzete és kívánt helyzete között. Sőt a komparátor jelezni tudja, hogy melyik irányban van az eltérés. Köszönöm még egyszer is a kiváló ötletet! MaGor
interpolálnám egy regsziterben
előjelesen az irányt. Vagyis lenne egy regiszter, amit kezdetben beállítanék pl. 127-re Ezután ha a jobb oldali szenzor jelez, akkor a robotot irányítanám balra, és vicaverza, de a regiszter dekremeltálnám, vagy inkremelntálnál 1-el. Így lenne egy statisztikám, hogy a fő irány merre mutat. Olyasféle, mint egy kormánykerék pillanatnyi helyzete. Nomost.a legdelső bit mutatná, hogy alapesetben merre "húzzon" a robot. PWM vezérelném a motorokat, és a szenzorok jelzésére azonnal beavatkoznék, a korméányregisztertől függetlenül. De a kormányregisztert minden beavatkozáskor értelemszerűen INC/DEC. Ha mindkét szenzor azt mutatja, hogy a vonalon vagyok, akkor és csakis akkor a kormányregiszter legfelső bitje mondaná meg, hogy _picivel_ melyik motor forogjon gyorsabban így nemcsak egyenes, hanem körívek nyomán is elég jól tudna menni. Hogy mennyi legyen az a "picit", az jó kérdés. ugy mint amiikor követed a kormányal kanyar ivet .. De erre is lehetne algoritmust készíteni. És akkor nem riszálná a seggét, hanem lágy kormánymozdulatokkal követné a vonalat. Ha törés lenne a vonalban akkor viszont hamar rátalálna a folytatásra, Pl. egy derékszögű kanyar esetén... És két szenzor kellene hozzá, meg egyszem fehér csíkmák. A kormánysebesség kiszámítása az picit bonyibb. Ott szerintem kellene egy megszakítás alatt ketyegő vekker. Ami adott intervallukokban bekövetkező kormánymozdítások számát számlálná. (ezzel tudnád szögét is .. elvileg mérni) és az így kapott számérték lenne arányos a kormányzó kerék lassítási mértékével a másik oldalhoz képest de egy mikrovezérlőben elég bonyi lenne nagyon matekoznod. ugye szorozni és osztani hosszú idő, a szögfüggvény meg tárzabáló Szóval a fenti módszer automatikusan jól csinálna mindent, de nem kellene matekozni neki. 3 egymásba ágyazott ciklussal meg lehetne az egészet oldani. Kb. 40...80 szó. Egy PIC10F222-esbe is bele lehetne tenni. 200Ft/db Sok sikert !
Helló!
Azon a PIC-en amit használsz nincsen analóg komparátor? Mert azzal akkor könnyű a két értéket összehasonlítani. Meg esetleg egy megszakítsát is tud generálni. Vagy ha az A/D átalakításnál maradsz akkor simán kivonod egymásból a két szenzor jelének értékét. Ha negatív akkor egyik irány, ha pozitiv akkor másik. Az érzékenységet meg úgy tudod kisebbre venni, hogy a különbségben az utolsó biteket nem figyeled. Pl elshifteled a különbséget 1-2 bittel.
Sziasztok!
Én már építettem vonal követő robotot. Csináltam egy és többszenzorost megoldást is. Leírom a tapasztalataimat: 1. szenzor A lényeg hogy "nem" a fekete csíkot követte hanem a csík szélét. Két irányból is képes körbejárni a fekete csíkot csak akkor a másik élét követi ...szóval az algoritmus nagyon egyszerű ha feketét lát akkor barra megy ha fehéret jobbra. Előny hogy ugye egy szenzorral megy és elég egyszerű az algoritmus akár analóg módon is megcsinálható. A mozgása nagyon jónak mondható volt, nem igazán volt kacsázó mozgása mivel gyorsan mozgott kicsit "zizegett" de gyors volt! De ami a legfontosabb!!! A kanyarban is ugyan olyan sebességgel ment mint az egyenesben. 3 szenzor: Az elv az ugyan az nem csíkot hanem élt követ.... a több szenzornak csak a kanyarban van értelme hogy tudjuk merre kell kanyarodni. Az az igazság hogy én nem analóg módon mértem tehát fehér 0 fekete 1 és kész....nem is tudom hogy lehetne távolságot mérni fénytől függetlenül... Szóval végeredmény ként azt mondhatom: Hogy az egyszenzoros megoldás sokkal gyorsabb volt a kanyarokban, a több az hajlamosabb volt túllőni a kanyarban és viszonylag így sokat korrigálni (szenzor távolságától függ...) Anyyi hogy az egyensesben gyorsabb volt de ha már egy kicsit is kanyarodottt ugyanúgy lelassult.. Lényes ha 95%-ban egyenes a pálya akkor talán érdemes több szenzort használni...de még ekkor érdemes megfontolni az ár/érték tényezőt... Az egyszenzoros megoldást én egyszerűnek és frappánsnak vélem és nagyon jól megteszi amit kell. végül: csak a tapasztalataimat írtam le...nem akarok senkit megyőzni..csak gondoltam írok..
OFF
Szíves elnézésedet kérem a "fatális baromságom" miatt, de ha Idézet: az inkább a Te fatális baromságod. „nem tudom eldönteni hogy a két byte közül melyik a nagyobb illetve kisebb.” Nem azért válaszoltam neked, mert nekem az a hobbim, hogy baromságokkal traktálom a fórumot. Pusztán nem értettem miért is nem tudsz két byteot összehasonlítani... gondoltam assembly-t használsz és azért javasoltam egy magasabb szintű programnyelvet. Idézet: Akkor most mi az építő jellegű hozzászólás? Esetleg kész megoldás 100oldalon dokumentálva? Na szóval inkább ne reagálj egy válaszra, nem kell itt másokat kiosztani... az remélhetőleg egy MÁSIK fórum!„Természetesen az építő ötleteket szívesen fogadom!” ON Mindettől függetlenül sikeres fejlesztgetést! HALI!
Szia!
Köszönöm a válaszokat. Örülök, hogy ennyi jó ötlet és megoldást. Érdekes ötleteket mondtatok, amin el fogok gondolkodni. MInden esetre elkezdek kísérletezni, aztán meglátom, hogy melyik megoldást tudom megvalósítani. Még egyszer is köszönöm az ötleteket! MaGor
Igen, igazad van, Slope...
Magor begyűjtött egy rossz pontot magának ezzel a hozzállással...ez jegyezve van nálunk is moderátoroknál...
Szia !
Az assembly a leg hardverközelibb nyelv, ha ott nem lehet valamit eldönteni, akkor sehol nem lehet. De nem is ez a probléma. Üdv !
Hi!
Nekem van ötletem, szerintem egy kis módosítással sokkal jobb mozgást lehetne elérni. Két szenzort alkalmaz az ember. Az egyiket középre rakjuk, a másikat meg mondjuk kicsit jobbra a középvonaltól. Ha a középső feketét mutat, akkor egyenesen megy, tehát nem kell kanyarodnia. Ha fehéret lát, akkor ránéz a jobb oldali szomszédra. Ha az fekete, akkor jobbra megy, ha az is fehér akkor balra. Amikor visszaér a feketébe beáll egyenesbe. Mit gondoltok erről?
Lehet, hogy jól működne, ha két szenzor lenne. Mindkettő a csíkon. Ha a baloldali lóg le a csíkról, jobbra kell korrigálni és fordítva.
|
Bejelentkezés
Hirdetés |
