Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Měření proudu #55

Open
dzarda opened this issue Mar 31, 2021 · 10 comments
Open

Měření proudu #55

dzarda opened this issue Mar 31, 2021 · 10 comments

Comments

@dzarda
Copy link
Contributor

dzarda commented Mar 31, 2021

Jirka potřebuje měřit proud serv a motorů na naší úžasné desce.

  • Přidat PB zprávy
  • Přidat ADC driver
  • Otestovat měření proudu

Design decisions:

  1. Stačí celé mA?
  2. Stačí prosté dotaz-odpověď(proud) API, nebo se chceme subscribnout na periodické proudy od motoru 1 a serva 2?
@JarekParal
Copy link
Member

  1. Nemůžeme to posílat v uA? Je mi jasné že nemáme takové rozlišení, ale v int32 je na to spoustu místa a až uživatelská knihovna na ESP32 to může převádět.
  2. Víme jak to chce Jirka používat? Známe jeho "use-case"? To by nám mohlo pomoct s rozhodnutím.

@dzarda
Copy link
Contributor Author

dzarda commented Apr 1, 2021

Tak int32 je jasnej, ale po drátě to běhá jako varint https://developers.google.com/protocol-buffers/docs/proto3#scalar Ale klíďo ať tam běhají uA, pár bajtů nás na 1Mbit nezabije. Ale záleží za zbytku řešení.

EDIT: Jirkův use case moc do detailu neznám. Mluvil o použití motoru bez enkodéru, proud je pak nějaká zpětná vazba na doraz či co.
U serv asi taky detekce dorazu.

@dzarda
Copy link
Contributor Author

dzarda commented Apr 1, 2021

Nejvíc easy by bylo asi prostě to přidat do period. zprávy, co generuje Power.cpp každejch 250 ms. Ale není to dobrý řešení.

@yaqwsx
Copy link
Member

yaqwsx commented Apr 4, 2021

Za mě:

  • jednotky by mohly být mikroampéry a posílat inty
  • určitě chci zprávu "teď přečti"
  • chci být notifikován, když se stane určitá událost; to vede na registrace a deregistraci triggerů:
    • časový (tj. periodické posílání)
    • proud vystoupal nad hranici
    • proud klesl pod hranici

@dzarda
Copy link
Contributor Author

dzarda commented Apr 5, 2021

Ok, další myšlenka:

Asi chceme předělat ADC měření tak, ať to třeba na 500Hz vzorkuje všechny chtěné kanály a sype do nějakých filtrů (moving average). Umí to tu "conversion sequence", kdy to převede chtěné vstupy bez intervence CPU, takže se to takto nabízí. Pak se hodí mít efektivní rozlišení třeba 16 bitů, což vznikne součtem šestnácti 12-bitových vzorků.

Vzorkování se tedy oddělí od komunikace, nejnovější výsledky jsou vždy k dispozici, transakce neblokuje na ADC.

@cednik
Copy link
Contributor

cednik commented Apr 6, 2021

Naprosto souhlasím s @yaqwsx - takhle nějak jsem si to API původně představoval :-)

ADC měření je podle mě potřeba udělat různě pro serva a pro motory + zbytek.
Motory je totiž potřeba vzorkovat synchronně s PWM, protože proud se měří jen během "aktivní" části periody. Během zbyku dobíhá skrz vnitřní tranzistory DRV8833 a neteče přes měřicí rezistor.
Vymyšlené to bylo tak, že časovač generuje fázově korektní PWM pro motory. Během compare match při čítání nahoru se nastaví výstup a začne se rozbíhat proud. Při přetečení časovač spustí AD převod (mělo by to jít hardwarově). Při compare match během čítání dolů je výstup opět shozen. V tom okamžiku přestává proud téct přes měřicí rezistor a tudíž už musí být doměřeno. Vzhledem k periodě PWM a minimální střídě, kterou žlutý motor potřebuje, aby vůbec běžel, by to mělo vycházet.
Mělo by to jít i s automatickou sekvencí kanálů - v každé periodě PWM se změří jeden motor. Po 4 periodách tedy budu mít vše. Pokud se správně pamatuji, po čtvrté periodě bude potřeba výsledky z všech AD převodů vytáhnout v přerušení :-(
Při frekvenci PWM 4 kHz budu mít aktuální hodnotu každou milisekundu, což mi přijde dostatečné (teda bez zvyšování rozlišení průměrováním, jak psal @dzarda - nešlo by to i s plavoucím průměrem? ).
Vzhledem k absenci filtrů na měření proudu je podle mě synchronní vzorkování nezbytné (a ty filtry tam nejsou právě proto, aby mohlo fungovat).

Naopak měření proudů skrz serva filtry má (f0 = 160 Hz) - počítal jsem s měřením na 100 Hz, pravděpodobně startovaném časovačem generujícím servo signál (ale matně se mi plete, že to už nešlo hardwarově). Díky těm filtrům ale není synchronní vzorkování potřeba, takže to může běžet, jak to vyjde.

Proč je zbytek na ADC s motory a ne u serv? Tak nějak to vycházelo nejlépe s ohledem na spouštění jednotlivých ADC konkrétními časovači. Pro motory je potřeba využít prioritních injektovaných měření.
Btw, zbytek jsou dvě měření napětí na baterce (celá, plus v půlce), interní napěťová reference kvůli průběžné kalibraci a interní teplota.
Měření napětí má filtry s f0 = cca 20 Hz, takže tam opravdu žádný spěch :-)

Správné nastavení všeho dle výše popsaných kritérií by mělo snad být implementováno v mém testovacím kódu (zatím bez té kalibrace podle interní reference).
Dalo mi to tehdy dost zabrat, protože v LL jsou chyby :-)

@dzarda
Copy link
Contributor Author

dzarda commented Apr 13, 2021

Proudové triggery by mohly být fixně povolené s nastavitelnou hranicí (hysterezí?)

@dzarda
Copy link
Contributor Author

dzarda commented Apr 13, 2021

@cednik Injected na motory je potřeba protože to sedí na TIM1_TRGO?

@cednik
Copy link
Contributor

cednik commented Apr 14, 2021

Proudové triggery by mohly být fixně povolené s nastavitelnou hranicí (hysterezí?)

Půjde-li nastavit větší limit, než je možné dosáhnout, pak je trigr efektivně vypnutý, tudíž za mě asi může být.
Uživatelsky přívětivější funkce se pak dají dodělat v knihovně na ESP.

@cednik
Copy link
Contributor

cednik commented Apr 14, 2021

@cednik Injected na motory je potřeba protože to sedí na TIM1_TRGO?

Jj, tak nějak si to pamatuji :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants