Existuje čip nebo modul, který přímo nabízí hodnoty náklonu?

[StrycAlois]

... to by potom mohlo napriklad seriovou linkou uz posielat pozadovane informacie naklonu - presne rovnako to robi to vyssie spomenute https://www.ebay.com/itm/Kalman-6-axis- ... SwJ7RYWYNT ... SwJ7RYWYNT to to ale robi velmi slusne pomocou kalmanovho filtra ...

Pánové,
moc vám děkuji za vaše úsilí a vaši snahu pomoct mi.

Igore,
velice mne zaujal modul, na nějž si dal odkaz, dokonce dva-krát:
https://www.ebay.com/itm/New-MPU6050-6- ... 100623.m-1

Šmejdil jsem i po jiných stránkách, které jej zmiňují, všude píšou více-méně to samé, ale narazil jsem na tuhle větu:
Measuring dimensions: Acceleration: 3D, Angular Speed: 3D, Attitude Angle: 3D

Pokud to má chabá angličtina pochopila správně, tak by z toho opravdu mohly lézt i hodnoty "postoje", tedy náklon, sklon ...
Navíc je výstup i v podobě RS232, což pro staromilce mého rangu je jako mana nebeská.

Takže pokud ten modul umí to, co si myslím, tak by to nakonec bylo přesně to, co jsem původně hledal.

Igore, zatím velké díky.

[sky59]

nestaci "stupidny integrator" pretoze integrator ma drift, preto tam je ten akcelerometer (pripadne magnetometer ak treba vsetky 3 osi) s ktorym sa urobi programovo bud komplementarny alebo kalmanov filter (u 6XXX sa pouzije priamo vstavany procesor na ten ucel) ... a sme kde sme zacali, netreba vymyslat vymyslene, existuje to, funguje to, pouziva sa to, staci pochopit a pouzit

neviem aky drift mas na mysli, ale ak to iste co ja, tak na to trpeli iba analogove integratory, cislicovy problem s offsetom nema

uz z podstaty a rozmeru dodavanych udajov "stupen/sekunda" staci integrator a vysledok bude "stupen" mozno by to nebolo az take super ako tie tvoje filtre (a kde sa to integruje?) ale po dost dlhu dobu by sa to nemalo rozist s realitou

[YenyaKas]

neviem aky drift mas na mysli, ale ak to iste co ja, tak na to trpeli iba analogove integratory, cislicovy problem s offsetom nema

uz z podstaty a rozmeru dodavanych udajov "stupen/sekunda" staci integrator a vysledok bude "stupen" mozno by to nebolo az take super ako tie tvoje filtre (a kde sa to integruje?) ale po dost dlhu dobu by sa to nemalo rozist s realitou

Aby integrátor neměl drift, musel by údaj o úhlové rychosti (stupně za sekundu) být přesný průměr úhlové rychlosti od posledního měření. Což téměř jistě nebude, bude to nějaká naposled naměřená hodnota, buďto okamžitá, nebo nějaký vážený "průměr" za kratší dobu.

Čím bliž ten integrátor je k tomu senzoru (čti: například v rámci senzorového mikrokontroleru), tím víc ví o fyzikálních vlastnostech toho konkrétního senzoru, tím víc měření může udělat, a tím přesněji může udržovat i ten integrál.

Rozjede se to tak jako tak, ale při rychlosti měření cca 1 kHz a integraci mimo senzor bych tipoval, že se to s realitou rozejde během pár vteřin, maximálně desítek vteřin, v závislosti na šumu nebo vyšších frekvenčních složkách úhlové rychlosti (běžící motor).

[igorb]

neviem aky drift mas na mysli, ale ak to iste co ja, tak na to trpeli iba analogove integratory, cislicovy problem s offsetom nema

uz z podstaty a rozmeru dodavanych udajov "stupen/sekunda" staci integrator a vysledok bude "stupen" mozno by to nebolo az take super ako tie tvoje filtre (a kde sa to integruje?) ale po dost dlhu dobu by sa to nemalo rozist s realitou

No myslim drift ako drift, neviem ako ho lepsie nazvat, je to termin s jasne danym zmyslom. Drift ma niekolko zdrojov a nevidim dovod preco by ho digitalny nemal mat. Drift je suma nepresnosti merania velicin od pociatku merania ktore su na vstupe integratora a to su nepresnost merania jednak uhlovej rychlosti a aj chybou merania casu. Cize je to rychlost akou vystup integratota "uchadza". Tvrdit ze digitalny integrator nema drift, je tvrdenie z rise snov :- )))) intergratory proste maju drift od podstaty svojej funkcie.

viac tu:
https://motsai.com/handling-gyroscopes-bias-drift/

proste nevymyslat vymyslene ... nastudovat o co tu ide ... nie je dobre si mysliet ze vsetci vyvojari na svete osprosteli ze nevedia to urobit tak lahko ako tebe zda ze by to mohlo ist :- )))) ... a ak myslis ze ano, tak to skus, budes king :- ))))

[igorb]

Pánové,
moc vám děkuji za vaše úsilí a vaši snahu pomoct mi.

Igore,
velice mne zaujal modul, na nějž si dal odkaz, dokonce dva-krát:
https://www.ebay.com/itm/New-MPU6050-6- ... 100623.m-1

Šmejdil jsem i po jiných stránkách, které jej zmiňují, všude píšou více-méně to samé, ale narazil jsem na tuhle větu:
Measuring dimensions: Acceleration: 3D, Angular Speed: 3D, Attitude Angle: 3D

Pokud to má chabá angličtina pochopila správně, tak by z toho opravdu mohly lézt i hodnoty "postoje", tedy náklon, sklon ...
Navíc je výstup i v podobě RS232, což pro staromilce mého rangu je jako mana nebeská.

Takže pokud ten modul umí to, co si myslím, tak by to nakonec bylo přesně to, co jsem původně hledal.

Igore, zatím velké díky.

Je to urcite ono, ale narazis na protokol tej seriovej linky, bude to treba pripojit na displej a nejako pochopit v tom co bude prichadzat kde "to" je (to co hladas). Mam ten cip aj doma ale nedostal som sa k tomu este. Niekde na YT som videl nejake video co z toho asi tak lezie. Tam by sa dalo odpichnut.

Ja osobne by som vsadil na to spomenute mini arduino s s nejekaym 6XXXX napriklad ten 6050 ak ta nezaujima azimut ale iba naklon. Na to su hotove kniznice a dostanes priamo uhlovu odchylku asi v akomkolvek tvare aky ta napadne. Proste pripojis par drotov, stiahnes program a mas hotove bez vyskumu.

Ina moznost je nejaky flight controller kde je aj procesor, aj IMU a napises si vlastny program (lebo origo softver ti nepomoze) ale to uz je na vecsie mnozstvo roboty. Zalezi na co to potrebujes, je mozne by aj tvoj cielovy program potom bezal v tom flight controleri.

Napriklad toto sa pokial viem da programovat v Arduino prostredi:
https://www.ebay.com/itm/KK2-1-5-LCD-Fl ... Sw9YdciKdX

[sky59]

No myslim drift ako drift, neviem ako ho lepsie nazvat, je to termin s jasne danym zmyslom. Drift ma niekolko zdrojov a nevidim dovod preco by ho digitalny nemal mat. Drift je suma nepresnosti merania velicin od pociatku merania ktore su na vstupe integratora a to su nepresnost merania jednak uhlovej rychlosti a aj chybou merania casu. Cize je to rychlost akou vystup integratota "uchadza". Tvrdit ze digitalny integrator nema drift, je tvrdenie z rise snov :- )))) intergratory proste maju drift od podstaty svojej funkcie.

viac tu:
https://motsai.com/handling-gyroscopes-bias-drift/

proste nevymyslat vymyslene ... nastudovat o co tu ide ... nie je dobre si mysliet ze vsetci vyvojari na svete osprosteli ze nevedia to urobit tak lahko ako tebe zda ze by to mohlo ist :- )))) ... a ak myslis ze ano, tak to skus, budes king :- ))))

Digitalny integrator drift nema, iba ze by nevedel spocitavat a robil by chyby ako skolaci na ZS

Snimac raz dava udaje ktore si nikto z prsta nevycuca ani pan kalman a jediny prevos na stupne je integrator

[igorb]

Digitalny integrator drift nema, iba ze by nevedel spocitavat a robil by chyby ako skolaci na ZS

Snimac raz dava udaje ktore si nikto z prsta nevycuca ani pan kalman a jediny prevos na stupne je integrator

aha ... tak ok, ako myslis

[YenyaKas]

Digitalny integrator drift nema, iba ze by nevedel spocitavat a robil by chyby ako skolaci na ZS

Snimac raz dava udaje ktore si nikto z prsta nevycuca ani pan kalman a jediny prevos na stupne je integrator

Snimac prece ma nejaky sum, ktery se pak nascita (i s tim Kalmanem, on to neni nejaky magicky vselek).

No a pak si predstav, ze uhlova rychlost nebude konstantni - pak samozrejme hodne zalezi na tom, jake cislo ti ten senzor vrati - pro presnou integraci bys potreboval prumernou hodnotu od posledniho mereni. Zatimco ten senzor pri kazdem mereni vrati spis neco jako okamzitou hodnotu, nebo spis prumer za mensi casovy okamzik. Takze z principu tam mas hodnoty, ktere do te integrace nevstupuji, a ty ti budou postupne zvetsovat chybu.

Ta chyba (drift) neni nejaka nepresnost digitalni integrace, ale nepresnost senzoru, kterou i kdyz presne digitalne zintegrujes, tak presto mas chybu, ktera se ti postupne scita a sectena hodnota ujizdi vic a vic.

[sky59]

Snimac prece ma nejaky sum, ktery se pak nascita (i s tim Kalmanem, on to neni nejaky magicky vselek).

No a pak si predstav, ze uhlova rychlost nebude konstantni - pak samozrejme hodne zalezi na tom, jake cislo ti ten senzor vrati - pro presnou integraci bys potreboval prumernou hodnotu od posledniho mereni. Zatimco ten senzor pri kazdem mereni vrati spis neco jako okamzitou hodnotu, nebo spis prumer za mensi casovy okamzik. Takze z principu tam mas hodnoty, ktere do te integrace nevstupuji, a ty ti budou postupne zvetsovat chybu.

Ta chyba (drift) neni nejaka nepresnost digitalni integrace, ale nepresnost senzoru, kterou i kdyz presne digitalne zintegrujes, tak presto mas chybu, ktera se ti postupne scita a sectena hodnota ujizdi vic a vic.

Vsak ano, preto aj moj CC3D gyro v modeli vyzaduje po zapojeni baterie pockat v horizontalnej polohe az sa nauci kde je horizont

A preto si myslim ze blby integrator vrati pouzitelnu hodnotu ktora sa az tak rychlo /za sekundy/ urcite nerozide, preto je digitalny signal uz interne predspracovany a ma 20 (!) Bitov, ak sa b8du integrovat /scitavat/ vsetky vzorky 6400 za sekundu 6ak to musi hrat ako vino, pretoze sa ziadna vzorka nestrati

[YenyaKas]

Tam přece nejde o to jestli se nějaký vzorek ztratí, ale jestli vzorek pokrývá přesně průměrnou hodnotu od posledního vzorku. Jinak měříš hausnumera.

No ale teda, pokud máš 20 bitů rozlišení a třeba rozsah hodnot úhlové rychlosti +-10 otáček za sekundu, čili 7200° za sekundu, tak jen tu nutnou zaokrouhlovací chybu při integraci 6400 měření za sekundu máš 6400x7200/(2^21) = 11° za sekundu. O tolik ti bude driftovat integrace absolutně přesného senzoru jen na úrovni zaokrouhlování toho 21. bitu. A to nemluvím o tom, že každé to měření je zatíženo šumem a ještě obvykle systematickou chybou, danou zejména tím, že vrácená hodnota je spíš okamžítá úhlová rychlost než přesný průměr za poslední 1/6400 sekundy.

EDIT: On ten Nyquist je svině - já jsem před časem vyráběl senzor napětí baterky pro FlySky/AFHDS2A, a ukazovalo to úplně nesmyslné údaje v závislosti na tom, jak rychle zrovna jel motor. Teprve až jsem před vstup A/D převodníku dal low-pass filtr, který spolehlivě vyrušil vyšší frekvence než byla frekvence měření, začalo se to chovat stabilně. Podobně na tom budeš s tou úhlovou rychlostí: předpokládej třeba, že v každém z těch 6400 měření za sekundu ve skutečnosti dostaneš údaj o tom, jaká byla úhlová rychlost v poslední 1/12800 sekundy, a druhou 1/12800 sekundy nebudeš mít pokrytou. Bude ti to vracet hausnumera v závislosti na tom, co se v té zbývající 1/12800 sekundy událo. Pokud v té úhlové rychlosti bude vyšší frekvenční složka, daná například vibracemi od motoru, budeš integrovat hausnumera.

[sky59]

Prave o to sa stara ten cip aby bol pohyb dostatocne pokryty vzorkami, ak by to nebolo nikdy to nemoze fungovat

Nyquist je kriterium stability regulacnych sluciek, s rusenim to nema nic spolocne

[igorb]

Tam přece nejde o to jestli se nějaký vzorek ztratí, ale jestli vzorek pokrývá přesně průměrnou hodnotu od posledního vzorku. Jinak měříš hausnumera.

No ale teda, pokud máš 20 bitů rozlišení a třeba rozsah hodnot úhlové rychlosti +-10 otáček za sekundu, čili 7200° za sekundu, tak jen tu nutnou zaokrouhlovací chybu při integraci 6400 měření za sekundu máš 6400x7200/(2^21) = 11° za sekundu. O tolik ti bude driftovat integrace absolutně přesného senzoru jen na úrovni zaokrouhlování toho 21. bitu. A to nemluvím o tom, že každé to měření je zatíženo šumem a ještě obvykle systematickou chybou, danou zejména tím, že vrácená hodnota je spíš okamžítá úhlová rychlost než přesný průměr za poslední 1/6400 sekundy.

Zda sa mi absurdne bavit sa ci ma intergartor drift alebo nie ... kazdy kto o tom ma dunstu to musi vediet, nechcelo sa mi do toho uz vrtat, kazdy si moze mysliet co chce ... ale k tomu tvpjmu prikladu ...

ides na to moc pesimisticky ... zoberme to ze je to vsetko fasacke, stoji to nemame ziadnu chybu senzora ... aj keby v tych 20 bitov bolo uplne presne a bezchybne zobrazena hodnota v 20 bitoch, co iste nebude, aj v tom pripade tam bude chyba kvantifikacie, cize kazde neranie obsahuje chybu az do 1 bitu (opet musim povedat kazdy kto rozumie meraniu ditalnymi technologiami musi vediet o com hovorim), co je asi 1/ 1 000 000 ... teda miliontina (optimisticky) ked to prenasobis 6400 integraciami za sekundu tak je to optimisticky 0,005 (5000 miliontin), tak mas za sekundu drift asi 360 x 0,005 co su skoro 2 stupne ak to dobre pocitam :- )))))))))) ... za minutu mozeme byt kludne mimo 120 stupnov ... takze to je ten "ziadny" drift :- )))))))))))))

[igorb]

Prave o to sa stara ten cip aby bol pohyb dostatocne pokryty vzorkami, ak by to nebolo nikdy to nemoze fungovat

ako sorry, ale uz to misim povedat, pises nezmysly to TAK ako pises to proste nefunguje ... a len tak na okraj cim viac vzoriek, tym vecsia chyba pri integracii, proste co pises je mimo misu

Poslal som sem link aj som napisal v texte ako SA to robi (ludia co tomu rozumeju a co to uz niekedy skusili a co im to FUNGUJE to tak robia ... nie napady ako "by som to robil" bez akejkolvek skusenosti a pochopenia) , takze odporucam to najprv precitat a pochopit ... alebo skusit

[sky59]

ako sorry, ale uz to misim povedat, pises nezmysly to TAK ako pises to proste nefunguje ... a len tak na okraj cim viac vzoriek, tym vecsia chyba pri integracii, proste co pises je mimo misu

Poslal som sem link aj som napisal v texte ako SA to robi (ludia co tomu rozumeju a co to uz niekedy skusili a co im to FUNGUJE to tak robia ... nie napady ako "by som to robil" bez akejkolvek skusenosti a pochopenia) , takze odporucam to najprv precitat a pochopit ... alebo skusit

Dobru noc a snivaj o tom co si napisal....
Ten cip musi davat "idealne" informacie ako pisem, pretoze nic s krystalovou gulou gam nie je co by opravilo chybne udaje tak ze by si vycucalo opravu z prsta

[igorb]

no ja na rozdiel od teba o tom snivat nemusim, lebo sa tym zaoberam a v celku mi take veci funguju ...