Szóval ez a program indul el, de nincs az a fül ahol betudom állítani az Arduino típusát és a portot!
A másik amiért belekezdtem: Van egy Robotfűnyíróm amit egy vásárban vettem. Meg van mindene, de le van kódolva egy 4 jegyű kóddal. Ezt szeretném megkeresni. A játék az egészben hogy csak le és fell gomb és ENTER van. Vagyis minden számot be kell nyomkodni vagy fel vagy le irányban, ha ez meg van ENTER És jöhet a következő szám, ezt négyszer és ENTER. Ha nem jó ísmét.
Ha valakinek erre van valami ötlete ,programja kérem segítsen.
Pár hete írtam, azóta változott a terv. Át tértem hasonló megoldásra mint amit írtál.
Úgy szeretném hogy az autó megközelítőleg 0° rol indulna, és képes 0° körül tartani a táblát. Ez jobban megvalósítható ötlet szerintem.
Meg építettem a táblát 40x85cm, megírtam rá a programot ami úgy működik hogy ha az eltérés nagyobb mint 0° akkor menj előre ha kisebb mint 0° akkor menj hátra, és a PID kimenete a PWM jel. Elméletileg működnie kellene.
Azzal a problémával találkoztam hogy ha kicsit megnő a dőllés szög akkor az autónak kb 5cm-re a tábla középpontjátol el kell távolodnia hogy átbillenjen a tábla, és olyankor már teljesen egyik oldalra fog dőlni a tábla, onnan nincs visszaút. Az autóm kb 0.4kg, a tábla könnyen mozog, viszont a súlya lehet hogy az autó súlyának az ötszöröse.
Próbáltam hangolni a PID szabályozást, de nem akar javulni a helyzet.
Az lenne a kérdésem hogy ez a probléma PID szabályozás eredetű lehet, vagy inkább mechanikus probléma, túl nagy a tábla és nem elég érzékeny?
Sziasztok! Korábban írtam már ide, az a problémám megoldódott (elcsúsztak a betűk a kiiratásnál). Most megint elakadtam. A "mátrix", amit összeraktam, egy sorba kötött (35 ledes csíkok) Ws2812b szalag egymás alá pakolva 8 sorban. Olyan progit használok tesztként, ami tartalmazza az AdafruitGfx, neopixel és neomatrix header fájlokat. Ékezetes betűket szeretnék megjeleníteni a mátrix szalagon. Találtam a neten egy módosított AdafruitGfx libet, amely - elvileg - a közép-európai ékezeteket támogatja,benne vannak a magyar ékezetek is. Megpróbáltam ezzel a módosított libbel, le is fordította, de kiiratásnál igen érdekes karaktereket kaptam. Nem tudom, hogy hol van a hiba? Sajnos nem vagyok programozó, nem ismerem a C++ nyelvet olyan szinten, hogy megtaláljam a megoldást. Köszönöm előre is a válaszokat!
Egy nagyon szimpatikus kis trafót vettem, egy Váci cég gyártja, 2700 Ft egy 47 VAC teljesítményű, leválasztótrafóként van minősítve, 230 V / 12 + 12, az egész be van öntve, nem zümmög. Üresjáratban olyan 26 volt jön ki belőle, tehát 2x13.
A 7824 / 7812 szerencsére ismeri a fizika törvényeit :), a melegedés szépen eloszlott.
(Az eredeti nyákon, mivel autóipari felhasználású, úgy van, hogy 12 volt betáplálás, (rajta egy ellentétes polaritás ellen védő schottky diódával), , a 12-36 volt második feszültséget pedig egy ráintegrált (gyári) DC-DC konverter adja. Ott nem is volt semmilyen zavarjel. Kellett nekem hálózati kapcsolóüzemű táp....)
Én most fogok projekthez 6-8 féle DC-DC konvertert rendelni, mind 2,54-es raszteres, furatszerelt. Én mondjuk alapvetően 5 V-ra megyek és 12 V-ból indulok ki (kis tűréssel), viszont a felhasználási cél miatt fontos, hogy elég stabil legyen az 5 V és ne nagyon rángassa a felhasználó sem.
Erre a kapcsolásra meg inkább nem írok semmit. :-)
Szóval én egy 2x12V trafóból indultam ki, és jól kitaláltam, hogy a 12 v és a 24v közös testen lesz, így aztán megépítettem a következő rajzot:
Az egyetlen probléma, hogy ilyet, éppen a kétutas egyenirányítás miatt nem lehet építeni. (nem jutottam teljesen a magyarázat végére, de egyértelműen a váltó oldali tekercsek közös pontja a gond.) A 16 volt helyett a 12 voltos stabira 33 volt került. Azért melegedett a szerencsétle, mert nem 16,5-12=4,5 volton kellett disszipálnia, hanem 33-12=21 volton. Ami kb 1,4 wattra jött ki. Hát annyitól már melegedhet.
Most átépítem úhgy, hogy előbb a 24VAC-ből lesz 24 VDC, majd abból 12 VDC. Így is el kell fűtenem ugyanazt a 1,4 wattot - de akkor már 2 egyforma bordán oszlik meg.
(a kapcsolóüzemű táp is szóba jön, sőt eredetileg a nyákon volt egy kis DC-DC konverter, de ez az egész menet közben alakult ki, és pont rossz irányba mentem.)
Az időpont lényegtelen. Ha akkor tudsz jól dolgozni, dolgozz akkor! Nagybátyám évekig tervezett este 10-től hajnali 4-ig teljesen sikeresen. Mondjuk másnap ritkán kelt 10 óra előtt.
Még nem ellenőriztem, de ez ugye egy kétoldalas próbanyák. Én meg baromira nem gondolkodtam azon, mi van az egyik oldalon - miközben ott van bizony a gondosan rátolt borda a forrszemek fölött.
na most jön az elleőrzés!
Köszönöm - ha nem ez okozza, akkor is nagyon jó, hogy szóltál!
Mérd végig az áramfelvételeket. Ott valami nem stimmel, 50 fokhoz wattok kellenek. A másik: mérj rá szkóppal a graetz lejövő ágára is, mert lehet, hogy ott sem kerek valami.
mindenképpen meg kellene mérni a cucc áramfelvételét. negyedwatttól nem lesz 50fokos egy akkora borda. ergó a cucc többet kell felvegyen annál. borda nem testel valamihez amihez nem kellene?
Az alkalmazás része egy 20.000 uF os kondi, amit fel kell töltenie a tápnak az elején. A táp 2 feszültségen működik, 12 v és 24 v. 12/24 trafó, 2 diódahíd, 2 db 1000 uF kondi, 2 stabi.
A 12 volt közvetlenül is megy az arduinora, a teljesítményrészre viszont 12/24 v választható egy kapcsolóval.
Az ellenállás a töltőáramot korlátozza, tehát ezzel a váltókapcsolóval van sorban. (amikor a Fet zárja a rákapcsolt injektor áramkörét, az konkrétan zárlat lenne. így meg a kondi szépen feltöltődik)
Egy kis elektronika - amúgy sem árt, ha az arduinosok néha észreveszik, hogy nem csak programból áll, hanem elektronikai alkatrészekből is :)
Szóval, van egy kapcsolásom, aminek a tápja eredetileg egy apcsolóüzemű táp volt, de a nagy áramú kapcsolgatásokra (20 amperos impulzuok egy FET-en) elég rosszul reagált, mert mindig rátöltött a pufferkondikra, ami miatt tele lett zajjal a tápvonal.
OK, átépítettem trafó plusz Graetz-hídra, egy LM7812 stabival.
A problémám.
A trafó 13,2 VAC-t ad ki. Ebből lesz ugye az egyenirányítón 13,2 x 1,4 - 2 x 0,5 = 17,5 volt.
A kapcsolás folyamatos üzemben 50 mA áramot vesz fel, 12 volton. A 7812-nek akkor a maradék feszültségen kell eldisszipálnia ezt az áramot: 5,5 volt x 0,05 A = 0,275 W.
A mellékelt ábrán látjátok, mekkor hűtő van rajta - ami RENDESEN meleg, mondjuk 50 fokos.
Nomális ez? Mi lenne, ha a névleges 1,5 ampert venném ki belőle???
Ismerősöm nem annyira rossz (CC) háza. Kicsi volt, így csak egy ponton mért, viszont volt kint is egy érzékelője, hogy a fűtés erősségét a külső hőmérséklethez tudja igazítani (padló + radiátor). Sikerült annyira elbaltázni a szabályozást, hogy néha akkor is bekapcsolt, amikor kint 15, bent pedig 22 fok volt. Ne kérdezd, miért. Akkor viszont, amikor kint -10 volt, bent pedig 18, akkor előfordult, hogy 5 percenként kapcsolt ki-be, teljesen indokolatlanul.
Más megközelítésben meg... Én biztosan nem kötnék semmit RPI-re. ESP8266-ra sem igazán. Ezeknek a hardveres oldala még viszonylag erős fejlesztői környezetben, tudatos (mérnöki) fejlesztéssel sem egy életbiztosítás (a RPI még talán, az ESP-et engedjük el!).
Egyrészt, 9 mm mozgás nagyon sok. Pláne, hogy 0, 9 mm vagy 9 mm egész számú többszöröse játszik csak. Itt adott esetben milliméteres (extrém megközelítésben ennél is pontosabb) pozicionálás kellene, ráadásul gyorsan. Ebből következik még egy dolog. A PID szabályozás lényege pont az, hogy a célként kitűzött egyensúlyi pont környékén elég pontos, azon kívül meg elég gyors. Ezt ezzel a motorral csak részben tudod teljesíteni, az egyensúlyi pont környékén ide-oda fog ugrálni a kocsi, mert hol az egyik, hol a másik irányba fog kitérni. Már ha egyáltalán képes leszel a PID szabályozást megfelelően paraméterezni. A PID nem pozícióra szabályoz, hanem állapotra. Mivel ez egy analóg rendszer, itt az lesz, hogy az ideális állapottól való eltérés mértéke, az ideális állapothoz képesti változás vektora (iránya és sebessége) fogja meghatározni, hogy milyen irányban és milyen sebességgel kell mozogjon az autó. Ninyilván minél szélsőségesebb az eltérés, ez az sebesség annál nagyobb lesz. Amire te gondolsz, az az lenne, hogy "ahhoz, hogy egyensúly legyen, innen ide kell mennie", csakhogy ha mérleghintáról van szó, ez (nagyon kis számú kivételtől eltekintve) nem fog működni.
Én nem kínlódnék enkóderrel. Ha van egy lineárisan mozgó tömeged, akkor kizárólag azt figyelném, hogy az egyensúlyi állapot eléréséhez merre és milyen sebességgel kell mozognia. Ha PID szabályzás van, akkor a pozíciónak nem lesz jelentősége, mivel a változás irányából és mértékéből (mennyire dől a mérleghinta, illetve a dőlés szöge változik-e, és ha igen, milyen irányban) lehet következtetni arra, hogy a kocsinak merre és milyen sebességgel kell mozognia (ez a sebesség lehet 0 is, elméletileg). Ilyen rendszerekben a PID nagyon kifinomult és jól működő szabálozási megoldás, de ehhez nem kell enkóder. Egy baromi gyors, jó tapadást biztosító kerék (vagy mint a példában láttuk, lánctalp) és egy kellően precíz és gyors léptetőmotor kell hozzá. Namost ez drága mulatság lesz, de megfelelő áttételezéssel megoldható, hogy elég legyen egy darab.
Igazából a mentorommal konzultàltam a projektemről, és közösen döntöttünk hogy így legyen. Így pontosabb szöget tudunk mérni, mert ha nem lenne párhuzamos az autó felülete az asztallal akkor nem tudunk pontos szöget mérni.
Bocs, megint belekotty :) A helyzet az, hogy a fűtésünk korszerűsítése kondenzációs kazán beépítését követelte - hála a rendeleteknek, sikerült rendes fogyókúrát előidézni a pénztárcán :( Lényeg, hogy olvasgattam a hozzászólásokat, és egy lényeges dolog elsikkadt: a mai kazánok - a kondenzációsak szinte biztos - Opentherm protokollal vezérelhetők. Ha veszel egy olyan termosztátot, amelyik ezt tudja, akkor gyakorlatilag a kazán vezérlését a helyi fűtési igényeknek megfelelő külső szabályozót telepítettél. Magyarul: kiszedted a vezérlést a kazánból, és oda tetted, ahol több lehetőséged van az adaptív vezérlésre, mint eredetileg volt. Pontosítva: a levegő hőmérséklet eltérése a kívánttól is belejátszhat a fűtési teljesítmény meghatározásába, a kazánban megvalósított kimenő-visszatérő víz hőmérsékletén kívül. De ez utóbbit is le lehet kérdezni, azaz a komplexebb vezérlés megvalósítható, időjárás követést is beleértve.Arról nem is beszélve, hogy az egyszerű on-off termosztáthoz felvehető fűrészfog jellegű hőmérséklet diagram burkológörbét kap(hat), további komfort növekedést eredményezve. Nevezzük ezt a vezérlési pontot A-nak, azaz A1 földszint, A2 emelet. A kolléga írt egy önszabályozó szivattyúról, ez B. Azaz, lesz 3 olyan bemeneti pont, ahol a halvány lilába derengő fogalma sem lesz az illetőnek a vezérlési görbe sajátosságairól, doksi ide vagy oda. A kazánon egyetlen bemeneti pont van - azaz, az A1 és A2 által generált igényeknek (szivattyú fordulat, láng szabályozás, mint minimum) valahova be kell futni, és ez a valami aztán összegyúrja az igényekből a tényleges parancsokat. Nos, én egyszerűsítettem a dolgot, de még nem készítettem el:
- egy-egy ESP8266 figyeli az alső ill. felső szint léghőmérsékletét. Önmagától nem küld semmit, csak ha kérdezik (mini webserveres üzemmód). Aki kérdez, az pl. egy Raspberry, akire a két szelep van bízva - földszint és emelet, valamint a kazán indítása-leállítása a legegyszerűbb esetben. A RP tárolja a távolról betölthető fsz és emeleti kívánt fűrési értékeket, ezeket a pontokat veti össze a két ESP-ről lekérdezett értékekkel, valamint naplózást is végez. Ha most bonyolultabbá akarjuk tenni a vezérlést, akkor az RP-be beépítjük az Opentherm vezérlést, két pontos bementettel, ha a kazánt is kérdezgetjük, akkor 3 pontos lesz a bemenet. Ha ezt megcsinálom, akkor nem kell hozzá mérnökcsapat, csak egy meglehetősen türelmes hátsó fertály :) - emellett az egyszerű, kétpontos termosztát működésre rátettem egy intelligensebb vezérlést. Kisit hosszabb lett a hozzászólás, mint terveztem, bocsánat.
Egy ilyen rendszernek pont az a lényege, hogy az összes node (autó) saját maga méri a dőlésszöget, és saját maga dönt arról, hogy merre induljon el az egyensúly kialakításához.
A feladatot egyedül kezdtem el kb 2hónapja. Most állok úgy hogy el kellene kezdenem foglalkozni a szabályozás résszel. Van még rengeteg időm. És én csak egy úgymond "gagyibb" változatát szeretném megvalósítani, csak annyira kell hogy működjön a rendszer hogy ha elinditom 2percre akkor tegye a dolgát és ennyi.
Azért esett az ESP vezérlőkre a választásom mert van egy viszonylag egyszerű protokoljuk, rettentően gyorsan küldi az adatot wifin keresztül egymás között. Ezzel a résszel már készen is vagyok.
Ahogy említetted is a motorokkal vagyok bajban, de sajnos csak ezeket tudtam beszerezni mivel Aliról valószínű nem jönnek meg a csomagok. Egy lépéssel ezek kb 9mm mozdulnak, ha ezeket a kerekeket használom. Tudom ez nem precíz de remélem megoldható lesz a dolgok ezekkel.
Akkor vissza térnék a legelső kérdésemre, hogy ezzel a motorral és Enkóder tárcsával megvalósítható e valamilyen PID szabályozás pozícióra? Vagy van e erre szükség egyáltalán?
Tudom vezérelni őket pozícióra PID nélkül csak úgy van túllövés 1-2lépés. Ezt szerettem volna kiküszöbölni a pozícióra szabályozással.
Nem kis pályás ez a cucc... De pár dolgot így előre nem árt tisztázni a témában.
Ez nem one-man-show. Ezt egyedül borzalmas és kegyetlenül fájó tapasztalatsorozat végén fogod tudni megvalósítani, ha egyáltalán. Ez, amit itt láttál, egy legalább 3-4 fős team munkája, amiben éppúgy van mechatronikai mérnök (hallgató), mint programozó matematikus (hallgató), mind gépészmérnök (hallgató) és valószínűleg egy elektromérnök (hallgató) is. Akkor bele se vágj, ha nincs rá legalább egy éved, szemmel jól látható nagyságrendű forrásod és egy hozzáférhető műhely, amelyben minden szükséges eszköz, felszerelés rendelkezésre áll. Ha egyetemen kívül akarsz vele mókolni, tudok helyet javasolni rá.
Műszaki megközelítésben pár javaslat:
1. Az esp32 / esp8266 wifi modul. Itt erre nincs szükség, mert az adatátviteli rétegben a szükségesnél számottevően több adat jön-megy, amelynek a feldolgozása, küldése, visszafejtése és újrafeldolgozása borzalmasan sok erőforrást köt le ahhoz képest, amire igazából szükség lenne. Sok lehetséges megoldás van, ezeken érdemes esetleg végigmenni kísérleti jelleggel egyszerűsített modelleken. Vannak az esp-nél sokkal egyszerűbb, adatátvitelt lehetővé tevő megoldások, amelyek sokkal alkalmasabak két darab, maximum 10-12 bites érték átküldésére.
2. Az a motor, amit választottál, csak ennél számottevően kisebb léptékben fog tudni működni és ott is vannak fenntartásaim a megbízhatóságával kapcsolatban. Itt is igaz, hogy attól függően, hogy mit és hogyan akarsz bizonyítani és/vagy milyen típusú adatokat szeretnél gyűjteni, eltérő forgatókönyvek és elképzelések alapján lehet építeni. Bizonyos megoldások borzalmasan gyorsak, mások elképesztően precízek, megint mások gyorsak és precízek egyszerre, cserébe baromi nagyok horrorisztikus mennyiségű energia kell a működésükhöz.
3. Mindenképp csinálj pontos tervet, de ne arról, hogy hogyan, hanem arról, hogy mit és miért szeretnél megvalósítani. Vagyis a cél legyen az első, ne pedig az ahhoz választott eszköz. Kb. mint a kalapács, ami ha a kezedben van, egyből mindent szögnek nézel. Nem lehetetlen a cél megvalósítása (lásd fentebb), de nagyon észnél kell lenned, ha nem akarsz végtelen mennyiségű pénz kidobása után kudarcot vallani a megvalósítással.
Akkor pontosítanám hogy miért is kellene nekem ez a szabályozás. Szakdolgozatomhoz kell majd az egyetemen. Egy ilyen hasonló projektet szeretnék összehozni. https://youtu.be/ElEHN8tHJnc annyi különbséggel hogy én csak 1 autót szeretnék használni. 1:05től 1:16ig látható a videón.
Kettő ESP mikrovezérlő lesz, az egyik méri az asztal dőllés szögét és azt küldi a másik vezérlonek ami az autó lesz. Az autó pedig majd próbálja vízszintbe állítani az asztalt.
Ha szükséges akkor összedobhatok egy kapcsolási rajzot.
A "mit akar a szerző" felvetés jön bennem elő mindig hasonló esetben. A kód rendben van, de amíg az nem tiszta, hogy a kapcsolásban az in1~in4 mi és hova és hogyan van kötve, addig nehéz lesz megoldást mondani rá. Ezek a motorok PWM-mel hajtva nem fognak optimális teljesítményen üzemelni, mert a terheléstől alapjaiban változik meg a viselkedésük. Lehet, hogy üresjáratban 30 százalékos kitöltési tényezőnél már vígan pörög, viszont terhelve csak 70 százalékos kitöltési tényezővel indul el. PID szabályozást nem értem, amíg nem akarsz önegyensúlyozó vagy baromim gyors vonalkövető robotot csinálni, addig nincs sok értelme. Az enkóderek osztásának megfelelően elég jó pontosságot lehet elérni, de nyilván ez rengeteg dologtól függ. Ha nagyon nagy precizitás kell, akkor én inkább valami vaskosabb léptetőmotorra szavaznék, akár gyorsítóáttétellel, azzal (a csúszást/kúszást nem számítva) nagyon jó pontosság érhető el. Van egy robotépítős közösség, ott egész komoly precizitást tudtak megvalósítani ilyen elven.
A kapcsolást nem tudom megrajzolni, mert én ESP vezérlőt használok, és L298N H hidat sem találtam. De viszont azt elmondhatom, hogy egy egyszerű robot autót szeretnék építeni és azt szeretném pozícióra szbályozni, hogy pontosan annyit menjen előre vagy hátra amennyit megmondok neki.
