OSD Remzibi vs. Mikrokopter FC

[krall]

No - i to jest odpowiednia postawa

potrzebny jest ktos kto bedzie w stanie potestowac nowsze pozmieniane hexy na swoim MK + OSD .

ja, ja

[miś]

Co do mieszania w procedurach uarta w MK to obawiam się że nie będzie to takie proste. Ten uart w MK służy do komunikacji z modułem Navi Control, z modułem Compassu, z PC oraz z OSD. I wszystko jest realizowane tym samym binarnym protokołem, a na dokładkę komunikacja jest robiona jednocześnie z różnymi modułami (adresowanie modułów jest zawarte w protokole). Więc jeśli wsadzimy tam wysyłanie stringów do OSD, to jednoczesne podłączenie kompasu, nawigacji, czy radiomodemów do transmisji danych na ziemię może się skończyć wykrzaczeniem tych modułów. Jedyna sensowna opcja to dodanie parsera tych danych. Protokół komunikacji jest kodowany w czymś w rodzaju Base64 i zabezpieczony CRC. Odpowiednie procedury kodowania/dekodowania są w pliku "uart.c" (procedura decode64). Wymaga ona około 200 wolnego ramu. Aha, pojedyncza ramka z danymi "debug information" z której to wyciągamy dane do OSD to około 120 bajtów, i tyle też trza mieć bufora na odbiór UART'a.
Bardziej konkretne informacje i przykładową implementację parsera dnaych można sobie podejrzeć w opencourcowym projekcie "C-OSD" dostępnym w dziale "Projects" archiwum SVN.
Ogólnie potrzeba sporo miejsca na kod... Ja zapełniłem już prawie 28kBajtów w mega32, ale ja tam mam dodatkowo loggera z obsługą kart SD i systemem plików FAT, voice variometr i parę innych "ficzerów"

[remzibi]

Tutaj soft:
http://svn.mikrokopter.de/listing.php?r ... 9fd26a5c26

Mam pytanie dodatkowe - jak zciagnac ten soft , znaczy zrobic dowload ?

Mis - dzieki za wskazowki , zajrze w te katalogi .

[diem]

Mam pytanie dodatkowe - jak zciagnac ten soft , znaczy zrobic dowload ?

Przyznam szczerze - tylko hexy sciagam i ida bez problemow. Reszta widze otwiera sie w przegladarce...

Misiek masz gdzies zrodla spakowane?

[miś]

Nie ma w zipie. Aby utworzyć kopię takiego katalogu lokalnie to trzeba sobie zainstalować klienta SVN. Bez tego to tylko otwieranie w przeglądarce i kopiuj-wklej

[remzibi]

Uff powoli sie wgryzam .
FC komunikuje sie ze wszytkim za pomoca UARTow .

Teraz pytanie co chcemy na OSD pokazywac , w podstawowej wersji to napewno horyzont a wiec podsluchujemy komende #w.... do kompasu
albo #C..... dane 3D

W zasadzie to wlasnie w te miejsce mozna by wepchnac $I..... - ale trzaby miec koperka do potestowania , ta komenda nie powinna nic wykrzaczyc bo bedzie poprostu ignorowana przez reszte czyli NC i MK3MAG .
a przed(lub po) kazdym wywolaniem standartowej MK , wywolywac tez wlasna $A....... do OSD

Ale nic kontynujemy dywagacje co ma pokazywac OSD - zapewne tez dane z modulu navi (NC) , wiec dalej calosc sobie "podsluchujemy" na okolicznosc komendy #O i/lub #X - wiec wyswietlanie waypointow i reszty .
Tu jest juz gorzej bo wymagala by przebudowy cala struktura OSD lacznie z programem do konfiguracji na PC , wiec jednak prosciej bylo by to zrobic w sofcie MK - dolozyc dodatkowe stringi .
Ale waypointy i inne "dziwne" informacje mozna by wrzucac na ekran za pomoca $M....
No jak by nie patrzec latwiej sie dobrac do MK :) .

Czy ja dobrze kombinuje ? dobrze - tylko musze sobie kupic MK do testowania :( .

[miś]

Z $w dostaniesz tylko horyzont... mało. $C nie leci cały czas, trzeba ją zażądać, a i tak dostajesz tylko dane do horyzontu. Z $D (debug) dostaniesz wszystko... horyzont, wysokość, napięcie baterii, variometr. Tyle że $D też trza żądać, bo wysyła przez 2 czy 4 sekundy po żądaniu i przestaje.
Zastanawiam się czy nie prościej jednak byłoby zrobić translator na jakimś Mega8 i wpinać pomiędzy MK a OSD. Sprzętowy uart do komunikacji z MK, a do OSD zrobić programowy. 3 elementy na krzyż a wiadro problemów z głowy.
Bo MK ma jeszcze jeden "ficzer"... jak podepniesz moduł NAVI to osd nie wpina się już do FC (równolegle z navi) tylko do "przelotowego" złącza Debug na navi. I wtedy Navi "przepycha" przez siebie dane z FC, a po za tym dokłada swoje rzeczy takie jak dane z GPS'a czy inne pierdoły. Zakręcone toto jak wagon słoików.

Weź no zapodaj jak ma wyglądać te twoje $I to może zrobię testa. Kompilacja softu do mk idzie mi bez problemu, więc spróbować można dowalić to obik wysyłania $w (który zawsze leci). Aha, twoje OSD obsłuży 57600baud ?? Chyba tak, ale wolę się upewnić...
A no i zostaje jeszcze problem jednoczesnego podpięcia odbiornika GPS i FC do osd... tu się chyba zaczną schody...

[diem]

Tez bylbym za sprzetowym uartem. Jesli ma byc wieksze zainteresowanie, to trzeba pojsc w tą strone, niewiele osob zdecyduje sie na zmiane softu mk tylko ze wzgledu na osd.

[remzibi]

Weź no zapodaj jak ma wyglądać te twoje $I to może zrobię testa. Kompilacja softu do mk idzie mi bez problemu, więc spróbować można dowalić to obik wysyłania $w (który zawsze leci). Aha, twoje OSD obsłuży 57600baud ?? Chyba tak, ale wolę się upewnić...
A no i zostaje jeszcze problem jednoczesnego podpięcia odbiornika GPS i FC do osd... tu się chyba zaczną schody...

$I ma wygladac tak
string "$I,",pitch,",",roll,"," CRLF
Czyli odczytany $I,12,-14,
w C mozna by to napisac np. tak
println ('$I,',(int)pitch,',',(int)roll,',')
lub
char[] = '$I,' + pitch + ',' + roll + ',' + '\r'
send_uart (*char())
czy jakos tak zeby bylo dobrze

przecinki musza byc po I , w srodku i na koncu , string moze sie konczyc znakami CRLF lub CF (czyli w C '\r' )

Tam w MK w petli UART.c mozna dac warunek :
if(UebertragungAbgeschlossen) {
wyslij naszego $Ixxxxxx
}

bedzie pykal horyzontem w kazdej wolnej chwili (pustym buforku TX) - to tak chocby na dobry poczatek . A tam chyba pitch i roll nazywaja sie ze struktury data3D
data3d.Winkel[0] - to chyba pitch jako stopnie
data3d.Winkel[1] - to chyba roll jako stopnie
Nie mialem czasu na dokladna analize

Co do tego ze po wlaczeniu modulu navi do MK on posredniczy - mozna przepytywac to navi albo w MK od razu skladac z danych navi $A...... do wyslania obok jego wlasnych danych , to nie musi byc czeste 1Hz spokojnie wystarczy choc lepiej bylo by dwa :) .

OSD samo wykryje baud rate jesli bedziemy mu wypuszczali po wlaczeniu MK nawet samo(bez danych) "$I," CRLF lub samo "$A,"CRLF .

Inna sprawa ze firmware OSD z hard coded 57600 to zaden problem i od razu z glowy .
OSD pracuje bez swojego odbiornika GPS - ma sie opierac w calosci na danych navigacyjnych podawanyc mu w comendzie $A,,,,,,,,,, - jesli kopter tego nie ma to - OSD tez nie pokaze - ale pokaze wszystkie xgraph , wszytkie ADC , RPM/frequency jesli ten czujnik sie do czegos przyda i horyzont .

Mis jak masz ostatnie zrodla do kompilacji MK to moze podeslesz ? czym kompilujesz AVR-GCC ?

Tez bylbym za sprzetowym uartem. Jesli ma byc wieksze zainteresowanie, to trzeba pojsc w tą strone, niewiele osob zdecyduje sie na zmiane softu mk tylko ze wzgledu na osd.

To moglby zalatwic chyba nawet jakic 8 nozkowiec ? a jak nie to 2313 spoko mam nadzieje .
Ale jak by sie dalo bez to tez fajnie , znacznie upraszcza bebranie z harwarem .

[miś]

$I ma wygladac tak ...

Ok, tylko jaka skala jest tych wartości pitch i roll (min - max) ? Czy w stopniach czy w hula-gula od do ??

OSD pracuje bez swojego odbiornika GPS - ma sie opierac w calosci na danych navigacyjnych podawanyc mu w comendzie $A,,,,,,,,,, - jesli kopter tego nie ma to - OSD tez nie pokaze - ale pokaze wszystkie xgraph , wszytkie ADC , RPM/frequency jesli ten czujnik sie do czegos przyda i horyzont .

No to będzie kiepsko bo z gołego FC niewiele więcej można wyciągnąć ponad horyzont, napięcie baterii i wysokość i variometr.
A z navi to już wogóle kicha, bo nie ma pełnych źródeł żeby można sobie pozmieniać.

Mis jak masz ostatnie zrodla do kompilacji MK to moze podeslesz ? czym kompilujesz AVR-GCC ?

Mam, moją trochę custom, pomieszaną wersję, ale nie ma problemu, napisz na PW maila, to Ci podeślę zipka. Kompiluje GCC w wersji 3.4.6 (WinAVR-20060421) i tylko tą wersją da się to zrobić poprawnie.

W wolnej chwili spróbuję coś zrobić, bo w końcu miałem czas poskładać te Twoje płytki OSD więc mam na czym testować
Tak na marginesie, to zrobiłbyś coś z tym Twoim softem do OSD, bo wgranie znaków do MAX'a trwa u ciebie całe wieki. W moim OSD zapakowanie pliku MCM (prosto z karty SD/MMC) do MAX'a trwa około 15 sekund. Może jakaś szybsza transmisja po RS albo procedura zapisu do maxa do poprawy...
Może to Ci pomoże ??

Kod: Zaznacz cały

void max_store_char(u08 ch, u08 *data)      // store one character (54 byte) to MAX EEPROM.
{
    u08 i;
    max_cmd(0x09, ch);
    for(i=0; i<54; i++)
    {
        max_cmd(0x0A, i);
        max_cmd(0x0B, *data++);
    }
    max_cmd(0x08, 0b10100000);
    delayms(20);
}

I żadnych dodatkowych delay'ów. 256* wywołać powyższe i tyle.

[remzibi]

$I w stopniach w zakresie -180 do 180

Z golego w sumie to wiecej nie trzeba wyciagac ponad to co napisales .

Delaye sa w PC - niestety jak cos szybciej to transmisja windowsowa sie wywalala , dotyczy to w zasadzie USB , z normalny rs232 z maxem nie robil takich numerow .

Zachowany jest tez czas po zapisie znaku 15ms inaczej byly bledy zapisu przy kostkach z roznych partii . One sa nawet w innych obudowach (mimo ze foot prints ten sam) .

[miś]

Zachowany jest tez czas po zapisie znaku 15ms inaczej byly bledy zapisu przy kostkach z roznych partii . One sa nawet w innych obudowach (mimo ze foot prints ten sam) .

No ja mam 20ms po zapisie znaku.

Delaye sa w PC - niestety jak cos szybciej to transmisja windowsowa sie wywalala , dotyczy to w zasadzie USB , z normalny rs232 z maxem nie robil takich numerow .

Szkoda że przy wyborze kabla w programie nie ma opcji "Real COM port", bo ja właśnie korzystam z normalnego COM'a i konwertera na MAX232. Pewnie działałoby szybciej.

[diem]

Ale jak by sie dalo bez to tez fajnie , znacznie upraszcza bebranie z harwarem .

Tylko problem w tym ze malo ktory uzytkownik MK decyduje sie na jakiekolwiek modyfikacje w sofcie... glownie kazdy na oficjalnych wersjach jezdzi.

[mifau]

Zbyszek.... jesli dalej uzywasz kabli profilic, to tu jest pies pogrzebany z tym zmulaniem/wieszaniem sie...
Straszne problemy mialem z tym kablem:( (przy 57600 kabel robil przestoje na 0,5-1sek, a czesem sie zawieszal i trzeba bylo odlaczyc go i podlaczyc znowu...czasem 2x - paranoja)
To byla wina driverow (najnowsze), ktore powodowaly nadmierne zzeranie zasobow (procka) w windowsie. Parser w moim programie do konfiguracji cyberdrone'a zzeral 100% procesora (core 2 duo 2,4GHz). Po zmianie kabla na FT232RL...wszystko idealnie:)
FTDI sa jednak najlepsze (maja najlepsze drivery)

btw. Chlopaki maja racje... Lepiej nie zmuszac nikogo do ladowania customowego softu, tylko po to by osd odpalic...
Taki parser to nie problem....
Sumy kontrolne pakietow tez nie sa tragiczne (to nie jest base64....tylko jego przerobka... szybsza i prostsza w implementacji)

Tez Ci mialem cos podeslac, co nie?:) Ale jak zwykle przymulilem:( (za krotka doba)

[remzibi]

Zbyszek.... jesli dalej uzywasz kabli profilic, to tu jest pies pogrzebany z tym zmulaniem/wieszaniem sie...

Kabelki OTi od poczatku zachowywaly sie o wiele lepiej - ale brak wspolpracy od Visty w gore - trzeba bylo kombinowac strasznie aby na Viscie dzialaly - a takie kombinacje to raczej poza zasiegiem zwyklego czlowieka .
Prolific dziala na wiecej systemow ale - faktycznie musza byc delaye na PC cie - inaczej "cuda wianki dzikie weze" wyprawiaja .
Oczywiscie wszystko zaczelo wychodzic dopiero w praniu - jak i wiele innych "niuansow" .

Sa jeszcze w moim posiadaniu kabelki ArkMicro - nastepna mutacja USB-UART - drivery do nich sa ale juz nie wnikalem za bardzo w testy .

btw. Chlopaki maja racje... Lepiej nie zmuszac nikogo do ladowania customowego softu, tylko po to by osd odpalic...
Taki parser to nie problem....
Sumy kontrolne pakietow tez nie sa tragiczne (to nie jest base64....tylko jego przerobka... szybsza i prostsza w implementacji)

Tez powoli zaczynam dochodzic do takiego wniosku - ale to w nowszej wersji OSD na mega32 - bo w do obecnej moge sie nie "zmiescic" , ale sprobowac trzeba :) . MK dziala z 57600 wiec wywale na poczatek detekcje baudrate - bedzie pare bajtow wolnych .

Tez Ci mialem cos podeslac, co nie?:) Ale jak zwykle przymulilem:( (za krotka doba)

Osobiscie tez zmagam sie z tym "problemem" za krotkiej doby bezustannie .