Ha nem 4-gyel osztott adatokkal dolgoznál, akkor a 256-tal történő osztás csupán annyi, hogy csak a magasabb helyiértékű bájtot veszed elő. Nem kell shiftelni semerre!

Szia! A vevőből 1 és 2ms szélességű impulzusok jönnek 20ms periódussal. A közép érték 1,5ms. Csak az impulzusok szélességét kell vizsgálni. Erre az említett CCP modul Capture módja alkalmas. Várod a bejövő felfutó élt, megszakításban eltárolod a CCP-hez rendelt számláló értékét, átváltasz lefutó élre és a beérkezésekor megszakításban kivonod a két számláló értékét egymásból. A kapott szám arányos az impulzus szélességével. Ha kettő vevőből jön a jel, akkor ezt párhuzamosan csinálod. Visszaváltasz felfutóra és folytatod a méréseket. A kapott értéket(értékeket) feldolgozod és két PWM modulra értelemszerűen kiosztod a motoroknak.

Azt hogy lehet megtenni?

Szia! Igen, a mérendő jellel és a mérés elvével is tisztában vagyok, erre van is a CCS C Examples könyvtárában egy példa, de eddig nem akart működni. Ma hajnalban kidobott az ágy, így nekiálltam tréningezni vele, és sikerült működésre bírni Az okot igazából nem tudom, annyi vátozott az eddigi próbálkozásokhoz képest, hogy most másképpen dugdostam össze a próbapanelen a cuccot, és a vevőből érkező PWM jelet most a 884 A0 lábára dugtam, elővettem a forráskódot, átírtam a bemeneti lábat az eddigi B3-ról a már említett A0-ra, lefordítottam, beletoltam a PIC-be, és láss csodát, működik Van itthon 5 db 884-em, mindegyiken végigpróbáltam a régi kódot, hogy hátha ennek a PIC-nek hibás a B3 portja, de érdekes módon a forráskód 884-es PIC esetében csakis kizárólag akkor hajlandó működni, ha a bemenet valamelyik A port, az mindegy, hogy melyik, A porton működik, ha a bemeneti lábat bármelyik másik portra állítom már nem megy Kipróbáltam 16F818 kontrollerrel is, ott mindegy melyik lábat használom bemenetnek, tökéletesen működik minden esetben. Igazából nem tudom miért, de valójában nem is érdekel, működik, és ez a lényeg

Nem értem a kérdést. A (feltehetően) több bájtos szorzat legalsó bájtja helyett a következő bájtot olvasod.

Ennél részletesebben azért nem tudom leírni, mert fogalmam sincs, hogy milyen mikrovezérlőt, milyen programnyelven programozol, s hogyan végzed el az általad említett szorzást.

Az a láb biztosan több mindenre használatos és nem jól állítottad be a hozzá tartozó periféria letiltását. De a lényeg, hogy működik!

Nem tudom, de ahogy írod is, az a lényeg, hogy működik, a paneltervnél meg olya mindegy lessz, hogy melyik portra kell odavinnem a bemeneteket. Már csak az a része van hátra, hogy a 2 csatorna beérkező jeléből kikalkulálja a PIc, hogy mikor melyik motornak mekkora PWM kell, de ez is inkább rajtam fog múlani, hogy kitaláljam, hogy a PIC hogyan osszon-szorozzon, hogy a végeredmény nekem is tetszen

18F4431 vezérlő, C18 fordító.
Van 2db tömböm aminek az elemeit szimplát szoroznám.
Egy 16 bites változónak lehet hivatkozni az alsó és felső 8 bitjére? Mert eddig csak shift regiszterrel tologattam.

Többféle megoldás is elképzelhető. Definiálhatunk pl. uniót (ez olyasmi, mint anno a FORTRAN-ban a COMMON terület). Ugyanazt a memória területet többféle módon/bontásban is el lehet érni.

Definiáljunk először egy előjel nélküli 16 bites változótípust, amit szóként és bájtonként is meg tudunk címezni. Legyen a neve union16.



Ha unsigned int helyett union16 típusúként deklarálunk egy változót, akkor C nyelven is hozzáférünk bájtonként is. Például:



Itt most bájtonként olvastam be és töltöttem fel a temp változót (vagy struktúrát), és "egyben", azaz 16 bites szóként olvastam ki. Természetesen fordítva is csinálható (ahogy neked kell):

Es ha egyszeruen csak annyit irsz, hogy valtozo >> 8 vagy valtozo / 256, akkor a forditonak nincs annyi esze, hogy eleve a felso byte-ot vegye csak fel, és ne shiftelgessen semmit? Termeszetesen unsigned int eseten.

Írtam, hogy többféle lehetőség van. A változó >> 8 is egy lehetőség, s szerencsés esetben a fordító optimalizálja.

Ez meg egy másik lehetőség (itt tárgyalják a lehetőségeket)


Mindkettővel az a gond, hogy a fordító körmére kell nézni.

Sziasztok! Az előző oldalon már volt egy kis gondom a modellszabályzóm PIC-jének a bemeneteivel, de az megoldódott, haladok tovább a programban és megint elakadtam. (Ha valaki esetleg nem tudná, az RC vevő kimenetein négyszögjelek vannak, amiknek az impulzusszélessége változik 1 és 2 ms között, 1ms a minimum, 1,5ms a középállás, 2ms a maximum) az impulzusok szélességének mérése már tökéletesen megy, ebből a motorok PWM jelének kiszámítása, és az irányváltó relék vezérlése is sima liba, a gond a kanyarodásnál van. A szóbanforgó modell ugyebár egy hernyótalpas jármű, egyenesvonalú előre-hátra haladásnál no problem, mindkét motor ugyanazt kapja, mindenki boldog. Kanyarodáskor viszont a kanyar belső ívén haladó hernyótalp motorjának kitöltési tényezőjét kellene csökkenteni úgy, hogy a csökkenés a kormánykerék elfordításának szögével legyen arányos, és maximálisan elfordított kormánykerék esetén a kitöltési tényező a másik motor kitöltési tényezőjének fele legyen. A helyzetet tovább bonyolítja az, hogyha áll a jármű, és akkor fordítják el a kormánykereket, akkor az egyik motort előrefelé kell elindítani, a másikat pedig hátrafelé, viszont a kitöltési tényezőknek egyezniük kell, és arányosnak kell lenniük a kormánykerék elfordulási szögével. Nna ennél a kanyarodásos dolognál mondott csődöt a tudományom, tudom, hogy mit kellene csinálnom, de nem tudom, hogy ezt hogyan tudnám belegyúrni a programba. Csatolom az eddig működő forráskódot, igyekeztem kommentelni, hogy érthető legyen a gondolatmenetem. A forráskódban 3. csatornaként szereplő részlet a jármű világításának kapcsolásáért felelős, az áramkörben egy NPN tranyó kapcsolja a LED-eket, a motoroktól teljesen függetlenül.


A segítséget előre is nagyon köszönöm

A kormány hatását mindig a pillanatnyi sebességhez kellene arányítani. pl. 25% előre haladásnál a kormány teljes elfordítása a másik talp -25%-os forgását eredményezze. 50% kormány minden esetben a másik talp megállását eredményezze. Maga a kormány elfordítása ne okozzon haladást, az csak gázadás hatására történjen meg, ahogy a valóságban is.
Ezt talán könnyebb leprogramozni és irányítani is könnyebb lesz a járgányt.
Persze lehet nem lineárisan is kiosztani a kormány hatását, még könnyebb lesz irányítani. Ezt táblázatokkal lehetne könnyebben megoldani.

Szia!
Az amit leírsz, a valóságban irányíthatatlanná teszi a járművet, legalábbis a modellt. Egy ismerős komolyabb kategóriás távirányítójával és két hagyományos szabályzóval végeztünk jópár tesztet, a mindenféle mixeket a távirányítón tudtuk kordinátarendszerben variálni és próbálkoztunk ezzel is, amit Te leírtál, és bizony nagyobb tempónál képtelenség volt precízen irányítani a modellt. Majdnem egy hónapig volt nálam kölcsönben a távirányító, nem tudom megmondani, hogy hány órát próbálkoztam különféle mixekkel, de szerintem a 100 óra megvolt, és a végeredmény az lett, amit leírtam az előző hsz-ben, ezzel a beállítással irányítható legjobban a modell. Amit te leírtál, azzal kezdtünk, mert ismerős tankmodellező, kapásból a tankoknál megszokott beállításokkal adta oda a távirányítót, de csak kb. negyed gázig tudtam így jól irányítani a modellt. Annak ellenére, hogy hernyótalpas, eléggé fürge jószág, sima terepen 8-10 km/h-val simán megy, és ilyen tempónál az általad is leírt beállításokkal képtelenség volt finoman fordulni. Azt, hogy állóhelyben csak a kormány elfordításával is meg tudjon fordulni egyhelyben, azt én szeretném, tudom, hogy a valóságban nem így működik, de tudom, hogy hol és hogyan fogom a modellt használni, ott sokszor kellhet majd az, hogy precízen tudjak akár kis sebességgel is egyhelyben megfordulni. Végülis erről, ha nem fog összejönni, akkor egyelőre lemondok, nem ez a lényeg, de nagyon hasznos funkció volna. Több nagyon segítőkész emberrel is beszélgettem egy veterán harcijárműves oldalon, egyiküknek van a tulajdonában egy ilyen jármű, és elmondta, hogy tudomása szerint ez az egyetlen olyan hernyótalpas jármű, ami a hajtásából eredendően képes csak kormánykerék elfordítással fordulni, mivel hidrosztatikus a hernyótalpak hajtása, és a kormánykerék tulajdonképpen egy szeleptömböt mozgat, ezáltal képes arra, hogy álló helyben a menetszabályozó kar üres állásában csak kormánymozdulattal egyhelyben pörögjön. Azt is hozzátette, hogy ilyen felépítésű járműből csak kevés van, talán 100 darabot gyártottak hidrosztatikus hajtással, de mivel akkoriban nem tudtak még olyan megmunkálási pontosságot a gépek, sok volt velük a gond, ezért áttértek a kormánykerekes, hidrosztatikus irányításról, a tankoknál megszokott, botkormányos, mechanikus hajtásra.

Ez a képlet kiszámolja az előzőekben leírt értékeket mindig a "kormányzott" talpra értelmezve %-ban.
motorPWM%=Seb%-(Seb%*(Kormány%/50))
Szükséges még vizsgálatokat végezni az előjelek szerint (jobbra-balra és előre hátra), hogy a két motor PWM értékeit mindig abszolút értékben kapjuk meg és be tudjuk állítani a relékkel a helyes irányt a talpakra.

Valóban reléket használsz az irányokhoz? Jobb lenne FET-es H híd, nem?

Kizárt, hogy ne lehetne megoldani kompenzációkkal. Sebességfüggően korrigálni lehetne a kormánykerék hatását egy megfelelő függvény beiktatásával. Biztosan meg tudnám oldani...

A helyben kormányra fordulás logikailag ütközik a helyes irányítással. Persze meg lehetne próbálkozni a 0 sebességnél más függvény futtatásával, de semmi értelme, mert meddig tart gázt adni, ha fordulni akarsz?

Köszönöm a képletet, sokat segít Igen, reléket használok az irányváltáshoz, 2db 2 áramkörös váltóérintkezős relét egyszerűbb jelen esetben alkalmazni, mint 2db H hidat, egyrészt kicsi a motorok áramfelvétele, másrészt kevés a hely, az általam alkalmazott 2 db relé szerintem kevesebb helyet foglal, mint 2 db H híd a FET-ek vezérléséhez szükséges egyéb áramköri elemekkel. Nekem így a 2 relé mellett van 2 tranzisztor, 2 FET és ennyi, a FET-eket közvetlenül a PIC hajtja meg, tökéletesen működik, egyszerű, olcsó, nem kell FET meghajtó IC, meg DC-DC konverter.

Igazad lehet az egyszerűségben, ha kicsi az áramfelvétel is. Egy DCDC valóban kellene, de akár egy 555-el is megépíthető, de tényleg kell meghajtó IC is, stb. Jó lesz ez így is biztosan...

A sebességfüggő kompenzációval itt az a baj, hogy a PIC csak annyit tud, hogy mekkora kitöltési tényezőjű jellel hajtja meg a motorokat, arról fogalma sincsen, hogy a jármű valójában mekkora sebességel halad, mivel a sebesség terhelés és terepfüggő. Az "okos" távirányítónál próbálkoztam exponenciális függvény segítségével mixelni a gázt és a kormányt, hogy nagyobb gázkar állásnál kevesebbet "szóljon bele a kormány", sima terpen nagyon jól működött, de pl. emelkedőnek felfelé, amikor padlógáz kellett, akkor meg nem tudtam kívánt mértékben fordulni, mert nem volt elég nagy a hernyótalpak sebességeltérése, mert a távirányító azt hitte, hogy gyorsan megy a vontató, és nem kormányzott annyit.

Ami az állóhelyben kormányra fordulást illeti, arról lemondok, ha nagyon megbonyolítja a dolgokat, azért szeretném, mert az építés alatt álló vontató egy nullszériás darabról lett mintázva (vannak eltérések a felépítményben) és a nullszériás igazi vontatók is tudták ezt a funkciót.

Szinte állóra lefogott hernyótalpakkal sem megy a motorok áramfelvétele 1,5 max. 2 A fölé, az alkalmazott S0-8 tokozású FET-ek még csak kézmelegre sem melegszenek, pedig csak 4,5V körüli gate feszültséget kapnak.

Értem, de nem arra gondoltam, hogy csökkented a maximális kormányozhatóságot, hanem arra, hogy a kormány lineáris hatását módosítod más függvény szerint. Azaz ha látod, hogy a valós sebesség alacsony, jobban ki kell tekerni a kormányt azonos elforduláshoz. Ez nem okozna gondot szerintem az irányíthatóságban, mert a lassú sebességnél van idő észlelni és beavatkozni, ellenben a nagy sebességnél már gondot jelenthet az apró mozdulatokra való túlreagálás. Eleve módosíthatod a kormány hatását exponenciálisra pl.

Kormánnyal kapcsolatban képzeld el, hogy balra kanyarodsz, csökkented a sebességet és megállsz, de a kormányt úgy hagyod(miért is módosítanád, hiszen akkor megállás előtt más felé haladnál), akkor a járgány elkezd forogni a megállás pillanatában? Vagy gépészkedni kell a kormánnyal a megállás pillanatában? Esetleg beletennél egy időzítőt, vagy egy feltételt, hogy helyben kormányzás csak azután történjen, hogy 0 sebesség 0 kormányszög megtörtént? Végül is lehetne találni olyan megoldást, ami használhatóvá tehetné a dolgot, de kicsit üti egymást a dolog szerintem.

Nem tudom, igazából úgyis használat közben derül majd ki a dolog, hogy mi hogyan jó, az előzetes tesztek alpján az tűnik legjobbnak, amit leírtam, de szerintem életképes a Te verziód is, én igazából most szeretném minnél hamarabb mozgásra bírni a szerkezetet, mert nemsokára lessz egy modellezős találkozó, és oda szeretném elvinni, mert sokan látták már az eddigi találkozókon félkész állapotban, és folyamatosan nyaggatnak, hogy mikorra fog saját erejéből közlekedni, és ha sikerül összehoznom egy ilyen szabályzót, akkor lehet, hogy a találkozón kapásból be is zsebelhetek pár megrendelést, ha van egy működő dolog, akkor utánna már tudom csiszolgatni, és aztán lehet frissíteni az eladott szabályzókat is.

Ebbe például nem gondoltam bele, igazad van... Igazából én az élethű dolgok megszállotja vagyok, az igazi tudta, a kicsinek is kell, de ebbe tényleg nem gondoltam bele, hogy ilyen esetben mi a helyzet, nem tudom, hogy a valóságban a ruszkik hogyan oldották meg az ilyen helyzeteket, de így mostmár belátom, hogy tényleg felesleges az, hogy csak a kormánykerék hatására pörögjön a vontató, mint a ringlispil.

A gond a Te verzóddal az, hogy nem tudom összerakni a fejemben a kódot hozzá. Viszont a képletes verzióból bármilyen működési mód kialakítható a megfelelő számítások közbe iktatásával. Lehet, hogy egy sor feltétel is kell, de ez mind követhető és logikus lépés. Bárhová be lehet szúrni egy módosítást...

Próbáld meg a 0-0 feltétel teljesülés vizsgálatával. Biztosan az igaziban is van valami retesz, vagy külön kapcsoló.

Igen, nekem is igazából a két különböző "kormányzási logika" okozta a legnagyobb gondot, a menet közbeni kormányzásra nekem is van több, többé-kevésbé működő programom, amit beraktam forráskódot, az a gépen a Tank_ESC_V1_0 nevet viseli, de már most a 2.1-nél tartok

Ezt nem tudom, de egyelőre szerintem kihagyom ezt a funkciót, igazából enélkül is tökéletesen irányítható a jármű, mondom, ez csak az élethűség miatt került volna bele, majd talán a 25.3 verzió már tudni fogja

Hát pedig ha teljesült a feltétel (megállt+középen a kormány), utána csak egy másik függvénnyel a kormányt kell vizsgálni és a talpakra ugyanazt a kitöltést kivinni (ellentétes iránnyal), amit a kormány állásából számítasz. Az elindulás törli a feltételt, a meglévő kódod fut. Tök egyszerű, nem?

Elképzelem, hogy tép a gép 10-el, majd elengeded a gázt, kormány középen, majd a kormányt eltekered maxra és a gép elkezd pörögve lassulni! Ezt megnézném élőben!

Még annyit, hogy javasolnám az állapotgépes megoldást az elágazások lekezeléséhez a jobb áttekinthetőség miatt.