eLeReS by Mifau?

mifau · Post autor: **mifau** » wtorek 06 gru 2011, 09:00

eeee....Rurek popsules zabawe:(
Nie chodzilo mi o tworzenie LRS'a samemu, ale o rozwoj juz istniejacego OpenLRS'a.

Radzu pisze:wchodziły dane po serialu i sterowało do 8 serw, jak robiłem podgląd sygnałów na oscyloskopie to impulsy były całkiem niezłej jakości i nie było widać żadnego siania, może wystarczy samą funkcję generowania PWM nieco poprawić, zrezygnować z funkcji Arduino i napisać to w standardowym C (kompilator powinien to łyknąć) i będzie lepiej.

Moje kilkuletnie doswiaczenie konkretnie i w tym temacie wskazuje, ze jesli procesor robi jeszcze jakies "powazniejsze obliczenia", to juz nie wygenerujesz nieszumiacego sygnalu nawet dla 2ch serv. Trzeba opierac sie o sprzetowe Timery (nawet 8 bitowe wystarcza), a konkretnie o OCR, robic jakies czarodziejskie sleep'y i inne wygibasy. W przerwaniu nie mozna nawet dac ustalenia stanu innego portu (niz ten sprzetowy), zeby nie rzezbilo po tym sygnale pozniej.
Delikatna materia, ktorej problemy kompletnie nie wystepuja w ARM'ach :)
Moj kod obslugi 2ch serv w PWM'ie zapewnia rozdzielczosc 2x i prawie 10x wieksza (zaleznie od serva), niz daje MK...a napisanie takiego kodu w ASM i kombinowanie zajelo mi kilka miesiecy. Raczej nie warto sobie podstawiac nog juz na samym poczatku i lepiej od razu wybrac najlepszy mozliwy procesor. <- ja takich rad nie sluchalem, bo tez wydawalo mi sie ze na avr mozna zrobic wszystko. Mozna duzo...ale jakim kosztem

EDIT: jesli juz to musi byc arduino, to naprawde dobrym rozwiazaniem sa te STM32.
Pisze sie tak samo - po prostu biblioteki sa inne, a programuje sie chyba nawet latwiej (z racji tego, ze STM ma od razu bootloader i nie trzeba sie meczyc z jakimis fusebitami, itp.... a sama predkosc procesora ustala sie juz w kodzie)

mifau · Post autor: **mifau** » wtorek 06 gru 2011, 09:40

Popatrzylem troche w zrodla OpenLRS'a i smialo mozna powiedziec, ze 80% pracy w drodze do powstania takiego systemu wykonal juz z 2 lata temu Mis :) Nieswiadomie pewnie :)

Gdyby Mis do swoich radiomodemow dodal jeszcze zmiane kanalow co 35ms (w przypadku gdy sa problemy z sygnalem), to byloby to 90% pracy :)

Nie wiem czy widzieliscie, ale najnowszy dostepny soft umozliwia robienie serial bridge'ow.
Czyli... do jakiegos np coptera bylaby to ciekawa alternatywa na komunikacje w locie (komunikacje z konfiguratorem) - radiomodem.

Coraz bardziej podoba mi sie ten projekt

EDIT:
A teraz juz mniej....
Hopping tylko po 3ch kanalach, brak jakichkolwiek sum kontrolnych, transparent bridge tylko do predkosci 60 kbit (czyli 10x wolniej niz radiomodemy Misia).
Trzebaby to poprawic, bo wstyd przed Ryskiem

Ale ogolnie nie ma tragedii. Obsluga serv polsprzetowa (mozna to zrobic lepiej - chociaz rozdzielczosc jest ok), 16 bitowa rozdzielczosc kanalu (no...troche mniej, ale nie chce mi sie dokladnie liczyc),....
Nie wiem tylko czy prawda jest stwierdzenie, ze zmiany sygnalu RC aktualizowane sa co 20 ms (50Hz). PPM/PWM tyle ma, ale wyglada na to, ze gdy zalaczona jest telemetria to w kazdym kroku petli glownej nastepuje 50 ms oczekiwanie na przejscie transceivera w tryb nadawania (co zmniejszyloby czestotliwosc odswiezania sygnalu RC do <20Hz) - moge sie jednak mylic, bo nie analizowalem kodu dokladnie

Zbeer · Post autor: **Zbeer** » wtorek 06 gru 2011, 10:10

mifau, serial bridge działa, bawiłem się.
Zobacz sobie jeszcze to http://forum.flytron.com/viewtopic.php?f=7&t=220
http://www.multiupload.com/E0C5P3GQ59

mifau · Post autor: **mifau** » wtorek 06 gru 2011, 10:32

Zbeerladen pisze:mifau, serial bridge działa, bawiłem się.
Zobacz sobie jeszcze to http://forum.flytron.com/viewtopic.php?f=7&t=220
http://www.multiupload.com/E0C5P3GQ59

Fajne, fajne

Sporo mozna tu poprawic jeszcze, a procesor nie jest mocno obciazony (pomijajac czesto wykonywane przerwanie timera odpowiedzialnego za generowanie PWM po stronie odbiornika - no, ale tak juz musi byc).
Ktos wie dlaczego hopping zaprogramowany jest tylko na kanaly 435780 MHz, 436380 MHz i 438240MHz? (chyba dobrze policzylem czestotliwosci)
To jakies prawne (bandplanowe) uwarunkowania?

Mozna pocwiczyc rozszerzanie funkcjonalnosci OpenLRS'a na AVR'rze dopoki (o ile wogole) powstanie wersja bardziej rozbudowana - i tu wartoby wowczas pomyslec o mocniejszym modemie (chociazby dlatego, ze zastosowanie dopalacza - ktory jest jednokierunkowy - do modemu aktualnego pozbawi mozliwosci korzystania z telemetrii).

Zbeer · Post autor: **Zbeer** » wtorek 06 gru 2011, 13:18

mifau, Hopping możesz sobie dowolnie zmieniać, częstotliwość bazową też w pewnym zakresie.

mifau · Post autor: **mifau** » wtorek 06 gru 2011, 13:57

Zbeerladen pisze:mifau, Hopping możesz sobie dowolnie zmieniać, częstotliwość bazową też w pewnym zakresie.

Kanal mozesz zmienic,ale ilosci kanalow hoppingu juz nie. W kodzie oczywiscie mozna.
A...i nie co 35,a co 25 ms zmieniany jest kanal.
Zakladajac,ze lacze obciazone jest w 100% (a tak raczej jest - o tym w EDIT),to jednoczesnie moga pracowac 3 zestawy i koniec. Wtedy hopping nic nie da. Czyli "zabawka" :(
Mysle jednak,ze cos tu da sie jeszcze wycisnac

EDIT:
Ciekawy tez jestem jak sie spisuja 2 jednoczesnie pracujace urzadzenia. Ktos sprawdzal?
Nie analizowalem kodu dokladnie, ale mam wrazenie, ze nie ma tu bindowania, wiec kazdy odbiornik dostanie ten sam sygnal (i go obsluzy).Czyli nawet jak beda pracowac 2 urzadzenia przypadkiem na tej samej czestotliwosci (bo akurat hop tak trafil), to ..... :)
Czy jest bindowanie?

marceli · Post autor: **marceli** » wtorek 06 gru 2011, 14:06

znając Michała to na pewno wycisnie coś konkretnego ze sprzętu, mam jego fc cyberdrone i muszę powiedzieć, że po ostatnich aktualizacjach firmware quadrocopter wisi mi zaskakująco dobrze. Zawisa. Zwisa. Jakkolwiek by nie określić tego robi to zaskakująco dobrze, no ale to temat na oddzielny wątek, który niebawem napiszę :)

Radzu · Post autor: **Radzu** » wtorek 06 gru 2011, 14:13

Bindowanie jak na razie jest realizowane za pomocą wpisanych w kodzie Tx i RX takih samych danych nagłówka (4 znaki), aczkolwiek widziałem w kodzie miejsce przygotowane na procedurę bindowania.

Zbeer · Post autor: **Zbeer** » wtorek 06 gru 2011, 14:18

mifau, w tym alternatywnym sofcie co dałem linka skacze po 20 kanałach.
Co do bindowania to komunikują się moduły z tym samym headerem w config.h się to ustawia.

Kod: Zaznacz cały

//###### RF DEVICE ID HEADERS #######
// Change this 4 byte values for isolating your transmission, RF module accepts only data with same header
static unsigned char RF_Header[4] = {'O','L','R','S'};

mifau · Post autor: **mifau** » wtorek 06 gru 2011, 14:23

Renta ten header. Trzeba bindowanie porzadne zrobic przede wszystkim.

mifau · Post autor: **mifau** » wtorek 06 gru 2011, 21:58

Poszedlem na papierosa i przemyslalem zagadnienie bindowania...
Wydaje mi sie, ze sa 2 opcje...
Pierwsza to ustalenie indywidualnego "klucza" na sztywno dla kazdego egzemplarza.
Niestety poniewaz jest to projekt otwarty, z dostepnymi zrodlami...to takie rozwiazanie odpada (a uzywa go ponoc Thomas w swoim LR'sie).

Drugie rozwiazanie to zwykly random generowany np przez strone nadawcza.
Random na 32 bitach (czyli header o tej samej dlugosci co teraz) zapewni nam prawdopodobienstwo trafienia w ten sam numer ponad 2 krotnie mniejsze niz trafienie 6-tki w totka.
Chyba wystarczy ?

No i procedura....
Do bindowania posluzymy sie przyciskiem lub zworka (zaleznie od plytki).
Podczas wlaczania TX'a, lub RX'a program sprawdzi czy zworka jest zalozona i jesli tak, to :
- TX wygeneruje nowy numer i bedzie go nadawal w swiat, az do wylaczenia nadajnika
- RX w tym czasie bedzie oczekiwal okreslonego pakietu, odbierze go kilka razy z rzedu, sprawdzi czy wszystkie odebrane pakiety sa takie same i zapisze sobie w eepromie klucz - informujac nas o tym fakcie zapaleniem led'a.

I tyle. Wrecz banalne (na godzinke roboty z testami) i mysle, ze spelni to swoje zadanie.

Macie jakies uwagi/przemyslenia?

btw. postanowilem zbudowac najpierw wersje na AVR'rze (w celu stworzenia jakiegos ukladu wzorcowego dla dalszych testow). Bedzie to zatem zwykly OpenLRS ze zmieniona plytka PCB (nie lubie ani bootloadera arduino, ani standardu zlacza)...no i zlacza dla serv beda zrealizowane tak jak w konwerterze abusemark).
Podlubie w tamtym sofcie (oczywiscie publicznie) i zobaczymy co z tego wyjdzie.
Jesli beda sensowne rezultaty i jesli uda mi sie poprosic obecnego tu Misia o pomoc z torem w.cz. to bedziemy kombinowac jak z tego zrobic cos bardziej zaawansowanego i spelniajacego zalozenia LongRange.

aha...zrobie tez alternatywny soft, ktory po wgraniu zamieni nadajnik/odbiornik w zwykly radiomodem.

(na armie moznaby z tego zrobic dodatkowo walkie-talkie

...serio )

EDIT:....
Plytka poki co wyglada tak....jak w zalaczniku.
Rozmiar to 25x30mm.

Ma ktos moze projekt modulu RF w eaglu? I padow pod antene....
Podzielicie sie, czy musze sam rysowac?:)

Marceli...ale pojechales

kuki83 · Post autor: **kuki83** » wtorek 06 gru 2011, 22:27

mifau pisze:
Ma ktos moze projekt modulu RF w eaglu? I padow pod antene....
Podzielicie sie, czy musze sam rysowac?:)

Marceli...ale pojechales

tu masz bibliotekę

http://www.opencircuits.com/SFE_Footprint_Library_Eagle

mifau · Post autor: **mifau** » wtorek 06 gru 2011, 22:29

Ale jaja:)
Mam sparkfunowa i nie sprawdzilem w niej nawet

Dzieki!

Jesli macie jakies uwagi to smialo piszcie!
To projekt otwarty, a nie zadna komercha.

Kwasiu · Post autor: **Kwasiu** » wtorek 06 gru 2011, 22:38

Może odrazu wklepać w soft tak jak ktoś wcześniej proponował obsługę dopału, zwiększanie mocy wraz ze spadkiem RSSI w odbiorniku, a po utracie sygnału zwrotnego, dopał włącza się na full.

mifau · Post autor: **mifau** » wtorek 06 gru 2011, 22:40

Jesli bylby wzmaczniacz w.cz. to pewnie....
Ale tak jak pisalem....poszukalbym raczej innego modulu RF, zamiast pozbawiac sie dwukierunkowej transmisji (poprzez stosowanie jednokierunkowego wzmacniacza).

Moze warto sie zakrecic za modulami stosowanymi przez DragonLinka...? (bo to jakies gotowce sa...ewidentnie sam ich facet nie robi)