RoboDoupě.cz

Ahoj,
mám na robotovi kvadraturní enkodér a pomocí pulse counter periferie na ESP32 z něj dostávám absolutní pozici. Funguje to výborně .

Teď ale chci podle signálu z enkodéru řídit rychlost rotace a narazil jsem na problém s rozlišením enkodéru. Pro řízení ve větších rychlostech plánuju vzorkovat v pravidelných intervalech a rychlost odhadovat jako rozdíl pozice z enkodéru děleno čas mezi vzorky. To ale bude fungovat rozumně jenom dokud bude v jednom vzorkovacím intervalu dost tiků z enkodéru aby se zprůměrovaly chyby vzorkování, nerovnoměrné délky úseků na kolečku enkodéru...

Rozlišení mám přibližně 0.4mm ujetých na tik, rád bych měl rozumně hladké řízení přibližně k rychlosti kolem 1mm/s. To vychází ~2.2Hz frekvence tiků.

Co mě zatím napadlo:

1. V nízkých rychlostech to prostě nebude fungovat, se stim smiř.
2. Snížit vzorkovací frekvenci někam k 1Hz. To mi přijde nepoužitelně pomalé.
3. Při nízké rychlosti se přepnout na měření času mezi změnami hodnoty enkodéru, rychlost odhadovat jako 1 / čas od posledního tiku. Tady ale nevím jak řešit zastavení, protože v takovém případě by mi přestaly chodit aktualizace rychlosti úplně a rychlost by zůstala zaseknutá na nějaké poslední nenulové hodnotě. Navíc tohle bude potenciálně komplikované kvůli konfiguraci MCU (ale dalo by se to zvládnout).
4. Průběžně prodlužovat vzorkovací interval, aby mezi dvěma vzorky bylo vždy aspoň pár tiků. Problém je, že když pak šlápnu na plyn, tak bude trvat celý jeden dlouhý interval než se objeví zpětná vazba na změnu vstupu.
5. Vzorkovat na stále stejné vysoké frekvenci, ale rychlost nějak vyhlazovat aby "hromada nul, sem tam jednička" dalo skutečnou rychlost. Tady nevím jaké vyhlazování použít, aby se zachovala rychlá reakce na změny. Moje oblíbené exponenciální vyhlazování asi ne? Možná by šlo použít nějaký trik s průměrováním přes tiky enkodéru místo přes čas.
6. Nějaká kombinace?

Zajímalo by mě jestli k tomuhle problému existuje nějaké "standardní" řešení (jiné než "použij vyšší rozlišení enkodéru"), přijde mi že to musí být docela běžný problém.

Ve té základní rychlé variantě jsem chtěl nad tou rychlostí mít PI regulátor a aktualizovat ho při každém vzorku. Pokud bych vybral některou z těch pomalejších verzí, je lepší nápad zpomalovat i aktualizace regulátoru, nebo ho nechat běžet stále stejně a jenom mu dávat několikrát za sebou stejné odhady rychlosti?

Ahoj,

jak máš ty enkodéry udělané? Už roky jsou totiž k dispozici magnetické enkodéry přímo na hřídelce motoru (tj. před převodovkou) ze který docela spolehlivě "lítá" dost impulzů i při pomalém pohybu.

Je to N20 motor převodovkou a enkodérem z Alíka. Má 14pólový magnet, dva hal efekt senzory o 90° od sebe a 1:10 převodovku (teď bych už ale bral 1:30). Pro normální ježdění to bohatě stačí, problém je jenom to že jsem snob na ovládání co má super přesný feel .

Tímto problémem jsem se také zabýval a zatím nemám uspokojivě vyřešeno. Zatím "nejhorší" co mi nějak chodí je pohon, kde mám maximálně cca 400 tiků za s. Vzorkovací frekvenci 50 Hz (i výpočet regulace rychlosti). Čemuž odpovídá cca max. 8 tiků na periodu, tj. chyba 12,5% v ideálním případě, při nižší rychlosti úměrně větší. Toto nelze přímo použít pro regulaci rychlosti. Takže jsem použil takovou okliku. Používám pouze P regulátor, ale ne pro rychlost, ale pro polohu. Takže v každém kroku regulace spočítám z předchozí hodnoty polohy a nastavené rychlosti požadovanou polohu (jako desetinné číslo), z něj vezmu jen celou část a tu porovnám s aktuální polohou z enkodéru. A to použiju na výpočet regulace. Tím, že se požadovaná poloha počítá v desetinných číslech (i rychlost může být zadána jako desetinné číslo), tak to funguje výrazně lépe než pokus o přímou regulaci rychlosti.
Ale v každém případě to není ono. Enkodér s rozumným rozlišením je výrazně lepší.
Přesto stále hledám jak to nějak obejít. Musí to nějak jít, protože zrovna tady řeším regulaci rychlosti nějaký motorů z auta (a tam je taky velmi mizerný enkodér). Ale v tom autě jim to chodí docela hezky.
Bohužel na toto téma jsem zatím nic rozumného neobjevil. Asi neumím najít to správné pojmenování (klíčové slovo).

Nad něčím podobným jsem taky uvažoval a došel k závěru, že než to udělám, tak se spokojím s následujícím odhadem a až to bude chodit, tak uvidím, zda to stačí, nebo ne:

Měřím a odhaduju polohju, kde jsem. (rychlost, zrychlení a td dopočítávám jinde, jinak) Dokud chodí tiky dost rychle, tak je to jednoduché, buď mi stačí, že jsem zhruba na pozici posledního tiku, nebo si vezmu, kolik času uběhlo od posledního tiku, kolik je to času oproti mezeře mezi předchozími tiky a pokud je to menší, tak k pozici posledního tiku přičtu příslušný díl vzdálenosti mezi tiky, pokud už by měl být nový tik, tak beru, že stojím těsně před jeho pozicí.

Rychlost, zrychlení a tak bych pak počítal přez víc posledních tiků a bral, že se až do nových dat nemění (ale pak samozřejmě nesmí být použité k odhazu pozice).

Mimochodem - tady je docela zajímavý "vláčkařský" přístup. Vláčkaři nepoužívají žádné snímače, ale spoléhají na BEMF. Pokud mají zastavovat na konkrétním místě, pak si předpočítají očekávané místo zlomu na BEMF křivce. Při provozu se pak podívají, jestli k němu došlo (respektive kde k němu došlo) a podle toho upraví parametry běžným PID regulátorem, nebo jiným ekvivalentním prostředkem.
Je to poměrně jednoduchá metoda a funguje na potřeby velmi pěkně a dost přesně. Vláčky nám normálně zastavují před návěstidlem a u perónu.

Pochopitelně to předpokládá si udělat ten "krokový" výpočet a sledování BEMF křivky. Vzhledem k tomu, že to běžně děláme na osmibitu, tak v tom nevidím zase takový problém.

Měření BEMF je jiná metoda určení rychlosti (jiný snímač rychlosti). Je principiálně méně přesná, ale výrazně lepší než "mizerný" enkodér. Pokud bych měl k dispozici měření napětí na motoru, tak je to jasná volba. Ale pokud nemám (a nelze to jednoduše přidat), tak řeším níže uvedený problém.

MartinL píše: ↑09 bře 2023, 12:00 .... Pokud bych měl k dispozici měření napětí na motoru, tak je to jasná volba. Ale pokud nemám (a nelze to jednoduše přidat), tak řeším níže uvedený problém.

Bych jen podotknul, že detekovat BEMF zlom na DC motoru není úplně složitá úloha a pokud jsem schopen kombinovat detektor s PWM výstupem, tak je to otázka dvou tranzistorů, nebo třeba jednoho operáku. Ale pak pochopitelně zásadní část v software pro generování toho PWM.

Já v žádném případě netvrdím, že je to složité. Ale pokud dostaneš hotovu desku pro řízení motorů, tj. nemůžeš si tam už nic rozumně přidat, tak to BEMF nezměříš. Pokud to lze, tak je to jasná volba.

Ono na konci dne je to vlastně jedno, kdo dělá ty pulzy. Podstata je stejná - připravíš si plán kdy má pulz přijít a rozdíl použiješ jako chybu pro regulaci.