dőlésszög mérése

Alaplapok

Sziasztok.

Dőlésszög mérésére (x,y) keresek valamit, ami Raspberryre ráköthető.
Cél egy olyan adatgyűjtő összebarkácsolása, ami majd realtime adatokat tud küldeni szervomotor vezérléséhez. Luxusként egy digitális tájolótól is lehetne a z tengelyre (mely merőleges az x, y tengelyre) vonatkozóan adatokat lekérni, de ez majd legutolsó lépés lenne. (A GPS "tájolója" [vö.NMEA mondatai] sajnos mindig a múltat közvetíti, a jelent sosem)

Végső cél egy állandóan vízszintben maradó kameraállvány készítése...

Készített valaki ilyesmit, ami működik is?

  • 4008 megtekintés

Illetve sidenote-ként: én nem használnék szervót erre a célra, mert kicsit pontatlanabb és lassú egy normális gimbal-hoz (ha megrángatod akkor sokkal lassabban követ). Ezt általában többfázisú brushless motorokkal oldják meg.

// Happy debugging, suckers
#define true (rand() > 10)

( apal v | 2014. 12. 14., v – 21:06 )

A GPIO-kon levo" I2C/SPI-ra kabe barmilyen MEMS accelerometert ra tudsz kotni. Elviekben egyszeru" is. Van ottan 3.3V is meg 5V is, bar ezek inkabb ezelobbi feszultsegen mukodnek. A valasztek is eleg nagy.

A nehezites, hogy ezeket az IC-ket hazilag ma'r bajos forrasztani, plusz me'g par passziv alkatresz is kell a szenzor melle' (cim-beallito es egyeb felhuzo-lehuzo ellenallasok, hidegito" kondik minimum). Ha mindenkepp RPi-re ko"tne'd, akkor nezhetsz egy fejlesztokeszletet, ezeken rendes (2.54mm-s) tuskesorokra ki vannak vezetve a kommunikacios labak es ma'r a hidegito" kondik es felhuzo-lehuzo ellenallasok is fent vannak. Igy (harveresen legalabbis) par perc alatt elesztheto" lehet, aka'r RPi + szenzor kombinacioban is.

( ruczati | 2014. 12. 15., h – 11:12 )

neked egy gimbal kellene imho. goto RC boltok/webshopok, direkt szerbvo kimenete van.

Nagy a reakcióideje, lassú a szögváltás, cserébe pontatlan, de olcsó;)
Youtube-on van fennt egy halom videó, összehasonlításra a brushless és a servo gimbal között

// Happy debugging, suckers
#define true (rand() > 10)

( bzs v | 2014. 12. 16., k – 19:55 )

27-31-ig lenne időm Magyarországon bevásárolni. Azt hiszem most kezdek rájönni, hogy amit akarok, nem is olyan egyszerű.

Tehát
rpi-vel szeretném, mert mikrokontrollerekhez nem értek,bizonyos szinten az rpi is magas, de idővel megoldódik nálam az összes nyűgje. (kernelforgatás 1 év alatt sem sikerült)
rpi hajtaná azt az éjjellátó kamerát is, amihez a girostabilizátor épül.
Azt hiszem amiket írtatok, a napokban alaposabban megrágom, majd újragondolok mindent

---
--- A gond akkor van, ha látszólag minden működik. ---
---

Ha rpi-n futó linux alá szeretnéd ezt leprogramozni (esetleg X más funkció mellé), tartok tőle hogy lassú lesz a reakcióideje ahhoz, hogy valóban stabilizálni tudjon, ne csak késleltetve "utánrángatni".
Kis kínából ~$200 körül összerakható a 3 tengelyes DC motoros gimbal giroszkópos vezérlővel együtt, rpi-vel meg max. a célvezérlőn keresztül irányíthatod az egészet (3D forgatás igény szerint)

Nem mozgok otthonosan az ilyen hardverközeli témákban, szóval tényleg csak perspektívabővítés végett kérdeznék: mire nem elég itt egy rpi? Gondolom a giroból jön valami datastream, felteszem pár axisra vonatkozó dőlésszög, ebből valami korrekciós mozgatást kell számolni a motorvezérlésnek, ami nem lehet túl erőforrás-igényes matek, és mondjuk ezt meg kell tenni, nem tudom, másodpercenként százszor mondjuk? Tudom, hogy az rpi nem egy rakéta, de én kis naivan azt gondolnám, hogy ennek tulképp ingerküszöb alatt kellene lennie...

A dolog real time voltában tudnék esetleg fogást találni, de az meg kb bárhol probléma, illetve ha nincs agyonterhelve a dolog, akkor a gyakorlatban vélhetőleg nem fáj.

A probléma maga a rendszer működésében rejlik. Datasheet nélkül nincs előttem, de emlékezetem szerint az rpi-nek nincs direktben pwm gpio kimenete, így a szervók vezérlését szoftveresen kell megoldani. Ez egy nem real time kernel (linux) esetében azt jelenti, hogy az a négyszögjel ami a szervóhoz kell, viszonylag pontatlan lesz, de a brushless motor esetében sem sokkal egyszerűbb így a helyzet. A másik probléma ezzel kapcsolatban hogy ennek köszönhetően egészen nagy lesz a válaszreakciója a rendszernek, a gimbalok pedig tipikusan visszacsatolásos elven működnek (annyit mozdít, amennyi ahhoz kell hogy visszaálljon egyenesbe). Ez magasabb latency mellett azt fogja eredményezni, hogy "belibeg", persze ezt lehet kompenzálni tul/alulvezérléssel, illetve thresshold beállításával (x% alatt nem reagálunk) viszont ez a pontatlanság növekedését fogja okozni.
Nem tudom mennyire célod a tökéletes eredmény elérése, de ha igen, szerintem jobban jársz ha beruházol egy vezérlőre (kínából egész olcsóan be lehet szerezni)

// Happy debugging, suckers
#define true (rand() > 10)

Nekem semennyire, csak bepofátlankodtam, mert érdekelt :) Pusztán kis látókör szélesítés, ha úgy tetszik.

A négyszögjelet értem, a jitter az valóban parának hangozhat. A latencyt viszont továbbra sem. Értem én, hogy a linux nem realtime, ezért nem tudja garantálni, hogy valami x időn belül megtörténik, az ok, hogy ha épp megy a matek, akkor lesz delay, és az fáj. De ez inkább tüskeszerű lenne imho (feltéve, hogy egyébként nem izzik a proci), nem értem, hogy hogy adna ez az egészhez egy konstans latencyt? Vagy ilyen 10 ms nagyságrendeknél már ennyire fájó a szórás?

Én mostanában E-bay-en meg Aliexpress-en nézegetek drone-alkatrészeket. GoPro méretű kamerához $50-$250 között vannak különböző minőségű, 2-3 tengelyes komplett gimbal-ok, de $200-$400 körül már DSLR mérethez/súlyhoz is találni. Persze, kell egy kicsit bogarászni, melyik lesz neked megfelelő.
Ha használni szeretnéd, nem a barkácsolás élvezete a cél, akkor szerintem már csak a kész, precíziós mechanika miatt is érdemes. Házilag sem lenne szerintem sokkal olcsóbb, de legalább pontos sem (persze, ki milyen finommechanikai műhelyhez fér hozzá)

Egy egyszerűbb, olcsóbb: http://www.aliexpress.com/item/CNC-FPV-Quadcopter-BGC-2-Axis-Brushless-…
Vagy egy kicsit "combosabb", 3 tengelyes: http://www.aliexpress.com/item/DYS-Gimbal-Brushless-3-Axis-4108-Motor-E…

( uid_17626 | 2014. 12. 17., sze – 10:09 )

Ha nem hobbi kiélése a cél, hanem a feladat megoldása, akkor én lehet nem is használnék elektronikát.
(Egy dobozba tennék zselés*-anyaggal megtöltött tömlőt/lufit, amin lenne a kamera.)

*víznél sűrűbb

Évekig ilyesmi stabilizálta a kamerámat a hajómon, most kisebbet akarok. A mechanikus stabilizátor csillapítója kalibrálandó, és ha csak kisebb dőlésekre tervezem, az átcsapó hullámoknál csak azért is bedőlés elállítódik.. mindegy, ez egy hosszabb történet, ráadásul a múlt

---
--- A gond akkor van, ha látszólag minden működik. ---
---

Egyrészt ember legyen a talpán, aki egy ilyet beegyensúlyoz, másrészt meg már kb ott tartunk, hogy szerljünk egy deszkát az alljára, meg akasszuk fel, és közben ússzon vizen. Profi, hordozható megoldásnak tűnik :D

Egyébként meg a vízzel az a baj, hogy ugyan jól hangzik elsőre, de ha láttál mármondjuk egy pohár meglökött vizet egyensúlyi helyzetbe kerülni, akkor valószínű rájössz, hogy kevésbé elégséges a beállási idő kamerázáshoz (miközben odafenn arról beszéltünk -- pontosabban Mcsiv :) --, hogy a pár ms jitter már receghet :), rádásul szükséges hozzá az egyensúlyi helyzet magátóli visszaállása (szal mondjuk kvázi konstans oldalszélnél szevasz)

Nyilván egy folyékony, vagy inkább kocsonyás, anyag minél sűrűbb, annál faszábban el fogja nyelni a külső rezgéseket (egészen addig a pontig, míg a szilárd már el nem kezdi "vezetni"), annál finomabban simul ki, viszont annál tovább is tart neki kisimulni (bár, ez a poharas példánál maradva nyilván bizonyos keretek közt értendő, és simán lehet a fordítottja is)... Olyat, ami mindenre jó, nem találsz. :)

Meg egyébként is, az ilyesmi szerintem azonnali beavatkozást igényel.

( markia | 2014. 12. 18., cs – 21:27 )

A giroszkop miértnemjó. Nincs benne elektronika tokeletesen stabil, egy jól csapágyazott háromtengejes lengolap kell meg hozza(olyanmint a regivitorlasokon a tájoló)