eLeReS by Mifau?

marceli · Post autor: **marceli** » środa 07 gru 2011, 17:58

Battlestar galactica rządzi. Imho bindowanie to nie problem wystarczy 4 bajtowy id wpisywany recznie przez użytkownika. Daje to nam ponad 4 000 000 000 możliwości, biorąc pod uwage optymistyczna liczbę powiedzmy 5000 użytkowników w Polsce jaka jest szansa spotkania w granicy zasięgu dwóch użytkowników, którzy wpisali ten sam id?

kuki83 · Post autor: **kuki83** » środa 07 gru 2011, 19:32

marceli pisze:Battlestar galactica rządzi. Imho bindowanie to nie problem wystarczy 4 bajtowy id wpisywany recznie przez użytkownika. Daje to nam ponad 4 000 000 000 możliwości, biorąc pod uwage optymistyczna liczbę powiedzmy 5000 użytkowników w Polsce jaka jest szansa spotkania w granicy zasięgu dwóch użytkowników, którzy wpisali ten sam id?

no ja cesze dodam że mamy możliwość zmiany kanału więc tym bardziej ciężko będzie trafić na takie same parametry u kolegi obok

krzysztof21 · Post autor: **krzysztof21** » środa 07 gru 2011, 20:19

E tam - jakby Michał "społecznie" dopisał procedurę bindowania to chyba sie nie obrazicie ?

Potrafią chłopaki podtrzymać zapał.

Ale to I2C i wyjscie programowania ISP dodasz ?

kuki83 · Post autor: **kuki83** » środa 07 gru 2011, 20:24

krzysztof21, no jasne że nie

aha ja może coś nadmienię apropo mocniejszych modułów, nie lepiej założyć po obu stronach wzmacniacz niż inwestować w mocniejsze moduły ,

jak by założyć w odbiorniki ten wzmacniacz 7W i skręcić go na 2-3W to pewnie bez radiatora by sobie spokojnie chodził

telemetria by działała i zasięg też nie był by mały a moduły mocniejsze w cale nie są wiele mocniejsze ale za to dużo droższe

mifau · Post autor: **mifau** » środa 07 gru 2011, 22:55

Pozostawiajac na chwile temat dopalu (szcze mowiac wole QRP - a juz max dla mnie to 0,5W)...bo nie czuje sie tu specjalista i mysle, ze w dyskusji powinien sie tu poudzielac konstruktywnie m.in. Kostek ....

Poogladalem sobie kod zrodlowy RX'a.
Zwrociliscie uwage, ze znajduje sie tam obsluga wiimote'a, a konkretnie wykorzystano jego zyroskop ...w celu domixowania go do kanalow ?
Moglibysmy zrobic obsluge dodatkowo np ITG3200. Padliniasty zyroskop jesli chodzi o coptery (przesuniecia fazowe przy pomiarach PRZYSPIESZEN katowych uniemozliwiaja jego sensowne wykorzystanie), ale w samolocie bylby idealny. No i tani.
Osobna mala plytka z takim zyroskopem i mamy stabilizacje.
Ale... zeby nie bylo za prosto... w oryginalnym OpenLRS'sie nie mozemy podlaczyc do procesora zadnego potencjometru (a potrzebowalibysmy 2 lub 3 - kazdy do obslugi reversu i wzmocnienia jednej osi) i parametry trzebaby ustawiac albo na sztywno w kodzie, albo poprzez jakas forme komunikacji szeregowej (potrzebny komputer).
A takich rozwiazan wolalbym unikac.
To byloby wg mnie zbyt malo elastyczne jesli zmuszalibysmy uzytkownika do uzycia komputera w celu konfiguracji. Oczywiscie jako "ficzer"....fajna sprawa taka konfiguracja z komputera. Ale nie byloby to juz niestety wygodne na polu.

Tymczasem, dodalem do mojej plytki rowniez wyjscie i2c, oraz wstawilem przycisk do bindowania (w oryginalnym OpenLRS wystarczy zalozyc zworke - podczas wlaczania - na kanal nr 1....w nadajniku tak samo)
Jutro wysylam plytki do produkcji, wroca za tydzien i jesli nie popelnilem nigdzie bledu, to po uruchomieniu bede mogl zabrac sie za czesc softwareowa - czyli glownie za zrobienie bindowania.
(jesli plytki beda ok, to udostepnie tutaj pliki eaglowskie ich projektu - jesli ktos mialby ochote takie sobie zrobic)

Jesli pojdzie gladko, to zabiore sie za projekt na jakims ARM'ie.... a do tego czasu powinno mi sie ustabilizowac spojrzenie na potrzeby tego projektu.

Zatem nieustannie zachecam Was do wymyslania PROSTYCH (w obsludze - bo w realizacji nie musza byc proste) funkcjonalnosci, ktore przydalyby sie nam tutaj.

slawko_k · Post autor: **slawko_k** » środa 07 gru 2011, 23:47

ITG3200. Padliniasty zyroskop jesli chodzi o coptery

Nie jest zły.
Chyba większość kopterów na forum na nim lata i mają się dobrze.
Dołożenie go mogło by mieć sens.

mifau · Post autor: **mifau** » środa 07 gru 2011, 23:56

slawko_k pisze:
ITG3200. Padliniasty zyroskop jesli chodzi o coptery
Nie jest zły.
Chyba większość kopterów na forum na nim lata i mają się dobrze.

To pewnie stad problemy z "bujaniem sie" i walka o szybsze regle (bo o jedno zrodlo przymulen mniej).
Nie mozna wylaczyc filtra cyfrowego w tym zyroskopie.
On powoduje przesuniecia fazowe i deltaD nie moze byc tym sposobem zbyt duza, bo zaczyna duzo szybciej niz w analogowych zyrach sie wzbudzac.
Tu mialem takie zyro: http://www.youtube.com/watch?v=IPspdmsZOmE
Na hali latal super, na wietrze lipa. Zaczalem drazyc i po miesiacu badan, zostawilem to....bo ani czestotliwosc odczytow (z tego co pamietam...transmisja trwala ok. 1ms), ani wlasnie przesuniecia fazowe filtra nie daly sie opanowac w wystarczajacym stopniu.
Latac, lata...ale nie tak jak na IDG500 (oczywiscie na atmegach z softem pisanym na floatach mozna tego nawet nie zauwazyc).Kwestia oczekiwan i poziomu satysfakcji.

Ale nie o tym, nie o tym....

slawko_k pisze: Dołożenie go mogło by mieć sens.

Nooo

Fajnie byloby moc zabrac starego EastStara i polatac na wiekszym wietrze

Ma potencjal ten OpenLRS

kuki83 · Post autor: **kuki83** » czwartek 08 gru 2011, 07:34

mifau, (mimo wszystko spróbuj przeprogramować regle na pewno zobaczysz kolosalną różnice)

mifau · Post autor: **mifau** » czwartek 08 gru 2011, 08:30

kuki83 pisze:mifau, (mimo wszystko spróbuj przeprogramować regle na pewno zobaczysz kolosalną różnice)

Robilem to juz ponad poltora roku temu gdy byl juz soft z wylaczonym filtrowaniem Quarxa.
To stary temat, nic odkrywczego.
Roznica byla niewielka (i to dzieki niej moglem podjac decyzje z wycofaniu sie z regli i2c). Podobnie jest w MK - ktory ma taki filtr wygladzajacy po stronie FC.
Tak jak napisalem.... "przyspieszanie" jest dobrze zauwazalne tylko w niektorych przypadkach.
Jesli mamy firmware z petla glowna o czestotliwosci 100Hz, to tez bedzie inaczej niz w przypadku petli 450Hz (jak u mnie), czy 500Hz (jak w MK).
Np serva kamery w ardu/wii/aero.... nie chodza tak dobrze jak w copterach z szybsza petla glowna (i wcale nie chodzi o generowanie PWM'a, a o predkosc aktualizacji stanu serva).
To wszystko jest ze soba zwiazane. Zjadlem zeby przez te 2 lata codziennej pracy (nie mam na mysli produkcji) nad copterami...i przyznam, ze nie czuje sie tu zawodnikiem do polemik

Robimy niepotrzebne OT.

mifau · Post autor: **mifau** » czwartek 08 gru 2011, 18:02

Plytki wyslane do realizacji, wiec teraz bede musial czekac

To najbardziej przykry etap realizacji .... Czlowiek chcialby juz sobie cos podlubac, ale nie....trzeba czeeeekaaaac

Zastanawialem sie chwile nad tematem radiomodemu mozliwego do zrealizowania na OpenLRS....
Zeby moglo pracowac jednoczesnie wiecej niz jedno urzadzenie (jedna para TX/RX), to trzebaby sie oprzec na mechanizmie "podpisu" paczek. Czyli wykorzystac takie czy inne bindowanie.
Wtedy jednak odpada mozliwosc przesylania pojedynczych bajtow - no bo wysylamy jeden bajt i robimy dodatkowy narzut w postaci kilku bajtow identyfikacyjnych (+jeszcze pewnie cos).
Wydaje mi sie zatem, ze najlepsza metoda bedzie przepychanie calych linii na raz.
Linie konczy zazwyczaj znak "\n" (czasem "\n\r") .
Wszystkie urzadzenia spelniajace ten warunek moglyby pracowac z takim modemem.
Oczywiscie bedzie mozna zrobic ustalenie wartosci znaku konca linii recznie w kodzie.

Post autor: **miś** » czwartek 08 gru 2011, 21:17

mifau pisze:Wydaje mi sie zatem, ze najlepsza metoda bedzie przepychanie calych linii na raz.
Linie konczy zazwyczaj znak "\n" (czasem "\n\r") .

To nie zawsze jest dobre, chyba że przesyłasz ramki tekstu. Sprawdzona metoda w moich radiomodemach to:
1. Bufor kołowy odbieranych (w przerwaniu) danych z uarta. 256 bajtów wystarcza.
2. Bufor liniowy na ramkę radiową. RFM12 najlepiej chodził na 32 bajtowych ramkach, większe lubiały się przekłamywać.
I teraz jak masz coś w buforze uarta to kopiujesz to do buforu radiowego, i jednocześnie zerujesz timer od timeout. Jak ten radiowy się zapełni, to wypychasz go przez radio wraz z nagłówkiem, bajtem mówiącym o ilości bajtów danych oraz CRC.
Jeśli nic nie odbierzemy np przez 10ms (ja mam ok 6) to wtedy dostajemy timeout, i jeśli w buforze radiowym są już zgromadzone jakieś dane, to wypychamy cały 32 bajtowy bufor radiowy, tylko bajt mówiący o ilości danych ustawiamy na ilość ważnych bajtów.

Po stronie odbiorczej to proste, odbieramy pakiet, sprawdzamy CRC, i jak jest OK, to wypychamy uartem tyle bajtów bufora ile jest zaznaczone w polu LEN, czyli długość.

cholo · Post autor: **cholo** » piątek 09 gru 2011, 09:53

mifau pisze:450Hz jak u mnie), czy 500Hz (jak w MK).
Np serva kamery w ardu/wii/aero.... nie chodza tak dobrze jak w copterach z szybsza petla glowna (i wcale nie chodzi o generowanie PWM'a, a o predkosc aktualizacji stanu serva).

btw. to w wii petla nie jest ograniczona i na plytce kukiego chodzi okolo 300-400Hz.
nic jednak z tego bo sygnal do serwa jest generowany standardowo z czestotliwoscia 50Hz wiec szybka petla nie ma nic do pracy serw. czy u Ciebie wyjscie serw do gimbala chodzi na te 450Hz (tzn. nie dzialaja serwa analogowe i chodza tylko niektore cyfrowe) ?

mifau · Post autor: **mifau** » piątek 09 gru 2011, 12:14

Mis... tak sie zrobi.
Uzyjemy Twojego kodu? Czy mam od nowa pisac? (albo razem napiszemy od nowa)

cholo pisze:btw. to w wii petla nie jest ograniczona i na plytce kukiego chodzi okolo 300-400Hz.nic jednak z tego bo sygnal do serwa jest generowany standardowo z czestotliwoscia 50Hz wiec szybka petla nie ma nic do pracy serw. czy u Ciebie wyjscie serw do gimbala chodzi na te 450Hz (tzn. nie dzialaja serwa analogowe i chodza tylko niektore cyfrowe) ?

Z tego co slyszalem (powtarzam...slyszalem od jednego z forumowych fachowcow od copterow, ale sam nie sprawdzalem) serva w Wii nie chodza plynnie (porownanie z MK).

To sa 2 rozne sprawy : czestotliwosc sygnalu PWM dla serva, a czestotliwosc odswiezania zmian stanu serva (EDIT: nie wiem jak w Wii, ale MK aktualizuje stan serva w kazdym obrocie petli glownej).
W zaleznosci od predkosci odswiezania mozesz zalapac sie blizej lub dalej poczatku nowej 50Hz ramki (zakladajac, ze pwm dla serva to 50Hz - bo np w CD moge to zmieniac miedzy 50, a troche ponad 400).
Zatem jesli odswiezamy stan serva z czestotliwoscia 50Hz, to mozemy zalapac sie na ramke PWM pozniej.
W teorii...przeciez to jest super duza predkosc jak dla zmiany stanu polozenia serva (50x na sekunde!).
W praktyce... wyraznie odklada sie to na obrazie z kamery.

EDIT: Cholo...ja tu nie polemizuje ze slusznoscia zalozen MultiWii - zebysmy sie zle nie zrozumieli. Podobnie jak Ty, lubie rozwiazania budzetowe - a szczegolnie takie ktore niosa za soba sensowna funkcjonalnosc. Akurat w przypadku MultiWii nie mam zadnego porownania, bo sam nigdy takiego nie mialem. Zalozenie projektu jest wg mnie rewelacyjne.

Czy naprawde musimy to ciagnac? Plz.

Post autor: **miś** » piątek 09 gru 2011, 13:46

mifau pisze:Mis... tak sie zrobi.
Uzyjemy Twojego kodu? Czy mam od nowa pisac? (albo razem napiszemy od nowa)

Ja chwilowo nie mam czasu na pisanie od nowa. Poślę Ci na maila moj soft, możesz z niego korzystać.

mifau · Post autor: **mifau** » piątek 09 gru 2011, 14:03

miś pisze:
mifau pisze:Mis... tak sie zrobi.
Uzyjemy Twojego kodu? Czy mam od nowa pisac? (albo razem napiszemy od nowa)
Ja chwilowo nie mam czasu na pisanie od nowa. Poślę Ci na maila moj soft, możesz z niego korzystać.

Super

Nie pali sie generalnie, bo nie chce pisac "na sucho", a na plytki czekam.

Przy pracy jako nadajnik OpenLRS ma troche wolnych wejsc.
Moznaby je wykorzystac jakos sensownie....
Mysleliscie juz o tym moze?