Evo snimke s termalne, izgled uvelike ovisi o post-procesiranju ( ja sam uzeo neku funkciju iz OpenCV-a ), raw-slika je sivi kvadrat na kojemu se ne vidi ništa.
Kamera dobro dođe za inspekciju ESC-a : na jednom ESC-u izgorio mi je FET i zamijenio sam ga istovjetnim, ali kupljenim sa e-bay-a iz Kine ( jer je 10 puta jeftiniji ). Iako ima identičnu oznaku, FET je kopija - pod termalnom se vidi da se grije puno više od susjednih FET-ova ! Kamera je dobra za naći bilo kakvu slabu točku na elektronici nastalu u proizvodnji ili samome dizajnu ...
Genijalno,kapa dolje...kad ide prototip u stvarnoj veličini??
Ja sam i počeo razmišljajući kako složiti stvarni bez prijenosa, a završio na "draga, smanjio sam djecu" jer sam shvatio da već imam sve dijelove pri ruci. Kasnije sam naletio na ovo:
Gledajući kod i algoritam, moglo bi se to i puno bolje složiti. Ako mi se jednog dana ovakvi kotači slučajno nađu pri ruci, kreće izrada jače elektronike ...
* Firmware se uvijek može uploadati, lock sprečava čitanje hex-a radi neovlaštenog kopiranja
* Svi MPU6050 su 3-axis gyro + 3-axis accel, razlike su u nazivima trgovaca - ako je MPU6050, to je to
Na žalost, uopće ne preporučam ovu samogradnju jer se pokazalo da je vjerojatnost za neuspjeh vrlo izgledna. Projekt nije rađen niti planiran za široku upotrebu, jednostavno nemam vremena za neku podršku, debagiranje preko mail-a i sl. Stavio sam hex na zahtjev ne očekujući ikakve probleme uz priložena uputstva, međutim stvari su se pokazale drugačije. Srećom, Bruce iz Australije (link na youtube opisu videa) je uspješno složio svoj primjerak sa dotičnim hex file-om, inače bih već i ja mislio da sam dao krivi hex...
Ukratko, iz nekog razloga vjerojatno vam neće raditi, tako da su uputstva samo za one spremne na neuspjeh Ako netko ipak pokuša, obavezno sa preporučenim motorima, jer zbog default-nog jakog gaina motori sa nižim otporom mogu spaliti elektroniku...
Kada bih baš jako iz nekog razloga to trebao izvesti na 2.4 GHz, napravio bih to ovako:
1. Stavio bih svih 10 prijemnika na letjelicu, svaki "bindan" na svoju stanicu. 2. Stavio bih jedan AVR da čita svih 10 signala i svih 10 RSSI signala. 3. Implementirao bih otprilike ovakav algoritam: - AVR automatski odabire signal sa najjačim RSSI-em i samo njega proslijeđuje dalje - automatsko preuzimanje - kao dodatno osiguranje, AVR analizira "ima li pilota u avionu", npr. najjači RSSI preuzima tek kada se detektiraju pomaci na palicama njegovog signala ... - još sigurnije - poluautomatski mod - dodijeliti jednom prekidaču funkciju dojave sustavu o vizualnom kontaktu sa letjelicom, npr. piloti koji vide letjelicu uključe prekidač, dok oni koji gube letjelicu iz vida isključe prekidač. Kada AVR dobije signal da je na aktivnom kanalu isključen prekidač, tumači to kao zahtjev za preuzimanje - dodjeljuje kontrolu kanalu sa najjačim RSSI-em, ali odabire samo između pilota koji vide letjelicu. Tako se ne može desiti da prebaci pilotu koji nekim čudom ima jači RSSI, a uopće ne vidi letjelicu ili spava pored auta.
Stavio sam link na hex file na youtube-u, u principu sa ovim motorima trebalo bi raditi bez ikakvog podešavanja. Uskoro ću natipkati i neka detaljnija uputstva, spajanje radia i podešavanje, pa tko hoće može napraviti svoj model. Eto bodul, lagano na posao pa treniraj vožnju
Pošto ima i par zainteresiranih preko jubitoa, vjerojatno ću staviti link na hex-file za download pa ko voli nek izvoli. Nisam siguran kako to izvesti, a trebalo bi napisati i neke upute pa kada stignem...
Nedavno sam imao sreće provozati pravi Segway, što je rezultiralo čestim razmišljanjima kako složiti nešto slično. Pitao sam se da li bi stvar funkcionirala da je cijeli kotač motor, dok se nije upalila žarulja da sve potrebne dijelove već imam, i uz to samo skupljaju prašinu. Postojeći dijelovi ipak nisu u pravoj veličini, ali se pokazalo da ovakav koncept može vrlo dobro funkcionirati...
Vjerojatno si namontirao senzor pod kutem od 2-3 stupnja u odnosu na mehaničku os rotacije ( malo je zarotirana pločica ).
Dok je gimbal horizontalno, tih 2-3 stupnja su orjentirana kao yaw iliti heading, tako da je roll točan. Kada gimbal zarotiraš prema dole, tih 2-3 stupnja se projiciraju u roll os - gimbal radi dobro i dovodi roll senzora u nulu, ali pošto os gimbala nije paralelna sa osi senzora sam gimbal je pod malim kutem...
Jednostavno preciznije namontiraj senzor... možda da mu podešavaš poziciju dok kamera gleda skroz prema dole (podešavaš rotaciju senzora) i tu dobiješ točan roll, u horizontu će vjerojatno biti dobar jer u toj projekciji pločica naliježe na ploču gimbala i automatski je ta ravnina u paraleli... ako ti gimbal nije spigan
Još je Einstein ustanovio da, npr. ako bi se lift nalazio u svemiru i u njemu bi se "osjetila gravitacija", unutar lifta NE POSTOJI pokus kojim bi se ustanovilo da li je to zaista gravitacija nekog susjednog planeta, ili npr. planeta nema nego lift ubrzava akceleracijom "g" - NE MOŽEMO RAZLIKOVATI AKCELERACIJU OD GRAVITACIJE !!!
Naši akcelerometri na senzorima uopće ne služe da mjere akceleraciju - u našem slučaju to se ne koristi - već smjer vektora "g" - da bismo znali gdje je horizont, dok su nam sve akceleracije uglavnom parazitne i kvare mjerenje smjera vektora "g". Akceleracije tipa kreni-stani ne utječu toliko, jer su uglavnom kratke i konačni zbroj im je 0 - "stani" poništava "kreni", a konstantno pravocrtno gibanje nije akceleracija . Međutim kruženje proizvodi konstantnu centrifugalnu akceleraciju koja se integrira vremenom i kvari smjer vektora "g".
Tijekom rotacije na senzor djeluje centrifugalna sila - uz vektor "g" prema dole, senzor mjeri i vektor "a" centrifugalne sile koji je horizontalan, odnosno mjeri zbroj ta 2 vektora u vidu rezultantnog vektora. Na primjer ako bismo se kretali u zavoju tom brzinom i radiusom da nam je centrifugalna sila "a" jednakog iznosa kao i "g", rezultantni vektor bi bio pod 45 stupnjeva. Naš senzor bi mislio da smo nagnuti 45 stupnjeva, dok smo zaista horizontalno, ali "u zavoju".
Ispravi se tek nakon par sekundi jer se akcelerometar ne gleda direktno, nego kroz filtriranje sa žiroskopom, pa su ti efekti manje izraženi i imaju neku vrstu kašnjenja ( isto tako se i ne pojavi odmah na početku rotacije).
Ako horizont odlazi dok letjelica radi pan u mjestu, znači da senzor gimbala nije u sredini letjelice. Stavi senzor koliko je moguće bliže centru letjelice, jer u samome centru nema centrifugalnih sila kod pan-a.
Ako pak letiš neki radius, uglavnom nema pomoći kod "crnih kutija" gdje ne možeš mijenjati kod...
Svaka čast za kadrove i montažu !!! Treba više ovakvih radova, da povuče i nas ostale da se malo potrudimo
Samo ne shvaćam zašto niste snimili i kadrove iz zraka sa Canonom kada ste već osposobili gimbal za njega ? Ovako kadrovi iz zraka malo odskaču od ostatka ( vidim da su korigirani, vjerojatno ste pokušali ujednačiti boje sa ostatkom videa .?.) ...
Položaj ( nagib, "attitude") nekog objekta u 3D prostoru može se reprezentirati na mnogo načina - matrica rotacije, eulerovi kutevi, quaternioni...
Najintuitivniji su eulerovi kutevi, i posebno su pogodni pošto se njihov iznos može direktno ubaciti u PID regulator, dok je za ostale načine potrebno računanje koje mali AVR vrlo sporo izvodi.
Eulerovi kutevi ( yaw, pitch roll) nisu strogo definirani, već ovise o redoslijedu rotacija: - avion je okrenut prema sjeveru, poravnat sa horizontom - zakrećemo ga npr. roll=90, pitch=90 1. Ako prvo zakrenemo roll, spuštamo desno krilo prema zemlji, nakon toga pitch - gledamo na istok, sa desnim krilom prema zemlji... 2. Ako prvo zakrenemo pitch, gledamo u nebo, zatim roll - i dalje gledamo u nebo, sa desnim krilom prema sjeveru...
Očito će različit redoslijed rotacije dati potpuno različit položaj aviona, iako su kutevi rotacije isti - u točki 1. avion gleda na istok, dok u točki dva gleda prema nebu...
Primjer singulariteta kod yaw-pitch-roll redoslijeda: 1. Avion je u globalnom sustavu okrenut prema sjeveru, horizontalno, i želimo definirati njegovu orjentaciju u odnosu na taj položaj ( neka vrsta "ishodišta") 2. Okrećemo ga prvo po yaw oko vertikalne osi, npr za 90, pa gledamo na zapad... 3. Zatim ga okrećemo po NOVONASTALOJ pitch osi (sjever-jug, gledano iz aviona) za 90, znači gleda u nebo 4. Zatim ga okrećemo po NOVONASTALOJ roll osi za neki kut, međutim, roll os aviona se poklopila sa vertikalnom osi od zemlje, te u globalu samo ponavljamo rotaciju iz točke 2 - izgubili smo jednu os, jer je pitch od 90 stupnjeva doveo roll os točno u poziciju gdje je bila yaw os...
Singularitet radi srednja rotacija, u slučaju yaw-PITCH-roll redoslijeda to je PITCH, koji pravi probleme na +- 90 stupnjeva. Ako promijenimo redoslijed rotacije u našoj reprezentaciji, singularitet se samo seli na rotaciju koja je druga (srednja) u nizu od 3 rotacije.
Eulerovi kutevi mogu zapisati sve položaje u prostoru, ali problem je oko točaka singulariteta gdje mali pomaci objekta u prostoru uzrokuju velike pomake u kutevima, što radi probleme npr. kod interpolacije u 3D grafici ( mislim da ima jedan član foruma koji to bolje poznaje nego ja ) i našem PID regulatoru.
Dakle: - Eulerovi kutevi su zgodni za male mikrokontrolere bez CPU snage, manje računanja pa ih zato koristimo - Imaju singularitete koje ne možemo izbjeći ( zato se uglavnom prelazi na quaternione) - Možemo odabrati redoslijed rotacije te pozicionirati singularitete na pozicije koje ne koristimo
AlexMos ima singularitete na roll-u, na +- 90 stupnjeva, jer je to položaj koji nam za kameru uglavnom ne treba, dok na pitch=+-90 radi, jer je srednja matrica očito roll...
Prema tome, ako ne možeš okrenuti kameru pogled prema dole, što bi bio pitch po konvenciji, vjerojatno si zamijenio pitch i roll - ne samo motore, kao prvi puta, već sve skupa. Okreni senzor za 90 stupnjeva i ponovo zamijeni motore. Ili općenito, gledaj u GUI prikaz da ti je roll i pitch 0 u horizontalnom položaju, te da se mijenja pitch kada kameru zakrećeš prema dole, a ne roll ...
!
. Međutim kruženje proizvodi konstantnu centrifugalnu akceleraciju koja se integrira vremenom i kvari smjer vektora "g". 