System H U D w modelu latającym

Witam
Interesuje mnie wszystko na temat obserwcji terenu nad ktrym lata mopdel Szukam zainteresowanych tematem.
Pozdrawiam

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Zapraszam na www.rc-cam.pl
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Panowie,
Prawdę mówiąc ja również jestem zainteresowany zabawą w taki projekt. Choć nie mnie chodzi o HUD, lecz o UAV. W zeszłym roku zrobiłem kontroler serwomechanizmów, który opisałem na stronie http://www.hobbyarea.pl/model_f8_tech.html . Jest zakończony i sprawdzony (przy okazji mam 20 wolnych wydrukowanych płytek tego układu).
Teraz korzystam z pogody do latania, ale po zakończeniu sezonu wracam do tematu i będę robił główny moduł. Oczywiście na zrobienie płatowca braknie mi czasu. Więc szukam kogoś do połączenia sił.
--
Lukasz
50 05'07"N
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Obejrzałem i jakże sie cieszę widząc taki styl dokumentacji oraz sposób prezentacji i kontroli danych w programie. to jest to co lubię - kontrola nad każdym detalem. Tak trzymaj! Jedna mała uwaga odnośnie protokołu komunikacyjnego. Stosujesz bajt ETX do oznaczenia końca transmisji. Widziałem wiele trotokołów transmisji i sam napisałem kilka ale nie spotkałem się z czymś takim - po prostu ta informacja jest nadmiarowa. Jeżeli masz nagłówek i ilość danych to wiesz gdzie jest ich koniec. Ten bajt jest zbędny i niepotrzebnie wydłuża czas transmisji. Analogicznie po odebraniu ramki z PC wysyłasz ACK a potem ramkę z danymi. Moim zdaniem ACK jest zbędne. Ramka odpowiedzi jednoznacznie potwierdza otrzymanie polecenia. Polecałbym też rozważyć dodanie indentyfikatora ramki, wystarczy 2-3 bitowy numer. Mnie zdarzało się że przy dużym obciążeniu CPU nie zdążał odpowiedzieć na ramkę a już przychodziła następna, wysłana po timeoucie odbioru. Kontroler odpowiadał wtedy na pierwszą a PC myślał że to odpowiedź na drugą. Mając identyfikator ramki wiadomo co jest odpowiedzą na daną ramkę.

To jeszcze masz duuużo czasu. Ja już nie mam czasu nawet latać ;-)
--
Piotrek.
http://www.pitlab.pl
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Dzięki!
Poniżej skąd wzięły sie pewne rzeczy:

Faktycznie w tym wypadku szybkość ma znaczenie i chyba niepotrzebnie jest tutaj ETX. U mnie służy on do dodatkowej kontroli, czy ostatnim przysłanym bajtem wg LEN jest właśnie ETX. Jednak faktycznie mozna było z tego zrezygnować. No ale teraz jak to już działa, to... jak mówią amerykanie; "nie naprawić sprawnego" :)

To sie wzięlo stąd, że kod programu ma dwie warstwy: warstwę transportową odbierającą pakiety niezależnie od implementacji (u mnie funkcja nazywa się readPacket()). Jej zadaniem jest odebranie pakietu, sprawdzenie poprawności, w razie potrzeby przesłanie NAK lub ACK. W rezultacie przekazuje ona gotowy, nieuszkodzony pakiet drugiej warstwie interpretującej. Pokwitowanie ACK działa więc niezależnie od tego, co jest wewnątrz pakietu. Warstwa odbierająca nie wie, czy na pakiet będzie jakaś odpowiedź, czy nie. Dopiero druga warstwa w zalezności od tego, co jest w pakiecie wyśle odpowiedź lub nie.

Fakt. Rzeczywiście o tym zapomniałem.
Pozdrawiam,
--
Lukasz
50 05'07"N
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Na moje oko masz już 5-10% całości projektu. Na tym etapie zmiany jeszcze nie bolą ;-)

Wydaje mi się że wysyłanie danych niezależnie przez różne warstwy jest niewłaściwe. Moim zdaniem powinna być zachowana wyraźna hierarchia i jedna warstwa nie robi tego co inna. U siebie też mam kilka warstw (symetrycznie w firmware i aplikacji PC): 1) warstwa transportowa odbiera / wysyła dane i umieszcza je w buforach kołowych. Informuje o odebraniu znaku i opróżnieniu bufora. Działa w przerwaniach (pozostałe warstwy działają w pętli głównej). 2) warstwa protokołu, pakuje dane w ramki, wykrywa początki, końce, liczy CRC, przyjmuje dane do wysłania i zwraca dane odebrane. Informuje o wysłaniu i odebraniu fragmentu danych w ramce. Zarządza retransmisjami w przypadku błędu transmisji 3) warstwa poleceń dzieli dane z / do polecenia na ramki. Istotne gdy trzeba przesłać wiele danych, w więcej niż jednej ramce. Sprawdza poprawność wykonania poleceń inicjuje wysłanie informacji o błędzie. 4) warstwa aplikacji odbiera polecenie z interfejsu użytkownika (menu, przyciski itp) i interpretuje informacjem wyświetla komunikaty o błędach. W aplikacji PC każda warstwa jest osobną klasą, w firmware inną procedurą.
--
Piotrek.
http://www.pitlab.pl
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Portal dostępny także - i przede wszystkim - jako www.uav.com.pl (adres rc-cam.pl będzie czynny tylko jeszcze parę miesięcy)
M.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.