Měření proudu

[dzarda]

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]

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]

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]

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]

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]

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]

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]

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

[dzarda]

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

[cednik]

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]

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

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