R9M-R9MM-opóźnienia-latency-RC-8CH-16CH-long-range

FRSKY R9M + R9MM – opóźnienia w sterowaniu RC

Dzisiaj nadarzyła mi się okazja na pierwsze testy przebudowanego drona do lotów long range z modułem FRSKY R9M i R9MM. Tak, słowo testy jest właściwym określeniem – do idealnego drona na dalekie odległości jeszcze daleko. Tyle mogłem wywnioskować po dzisiejszych lotach, a mowa o dokładnie modelu z tego filmu:

Powyższym dronem steruje mi się niezbyt komfortowo, na co składa się kilka rzeczy:

  • obraz z kamery pokładowej Eachine 1000TVL CCD posiada liczne zniekształcenia w postaci jello, a także bardzo wolno zmienia kontrast niedoświetlonego kadru (powolne przełączanie ,,dynamic range”)
  • model reaguje zbyt czule na wszelkie podmuchy wiatru – jest niestabilny,
  • ospała, opóźniona reakcja na ruchy drążków z aparatury.

W tym wpisie skupię się na ostatnim czynniku, czyli ospałej reakcji multiwirnikowca na polecenia z aparatury.
Nie jest to oczywiście kwestia ustawień RC-Rate w sekcji PID oprogramowania Betaflight.
Sprawcą jest w tym przypadku zestaw dalekiego zasięgu od FRSKY – R9M + R9MM, który generuje takie opóźnienia.
O samym zestawie dalekiego zasięgu przeczytacie w artykule:
FRSKY R9M + R9MM – system dalekiego zasięgu 900MHz.

FRSKY R9M + R9MM – skąd opóźnienia w sterowaniu RC?

Zanim przejdziemy do sedna, wypadałoby opisać, jaki protokół danych ustawiłem w odbiorniku R9MM oraz module nadawczym R9M… (wybaczcie lekką chaotyczność wpisu – piszę go bardzo zdenerwowany) 😉
Zestaw dalekiego zasięgu do aparatury RC zakupiłem z antenami dla pasma 915MHz (International), lecz przecież mieszkamy w Europie – wymagane pasmo to 868MHz. Dlatego, by mieć możliwość zmiany ,,w locie” częstotliwości sterowania – wgrałem oprogramowanie FLEX dla tego zestawu. Dodatkowo, zamiast standardowej komunikacji SBUS, wybrałem FPORT (dane telemetryczne z modelu oraz sterowanie nim odbywa się przy pomocy tylko jednego przewodu). Takie rozwiązanie umożliwił mi wcześniej zakupiony do modelu kontroler lotu Matek F722-SE.

Jak tego dokonać zobaczycie w filmie poniżej:

Dron wyposażyłem także w moduł GPS, by w razie konieczności (zerwanie linku RC, utraty wizji FPV) wykonał awaryjny powrót dzięki opcji GPS RRESCUE w Betaflight.

I teraz najważniejszy punkt – poprzez dużą liczbę trybów lotu, ustawianą z aparatury – musiałem ustawić obsługę 16-CH (dodatkowo z opcją telemetrii).

Bardzo dużo osób na forach RC ostrzega, by zastanowić się kilka razy, czy naprawdę potrzebujemy sterowania z 16-kanałów. Generuje to dodatkowe opóźnienia w sterowaniu RC. Jak duże? Jedni piszą i mówią, że ciężko jest je wyczuć, inni – że są dość zauważalne.

Postanowiłem przetestować osobiście, jak jest naprawdę.

Z ustawionych od samego początku 16-kanałów z obsługą telemetrii, zmieniłem na obsługę 8-kanałów również z telemetrią.

Odczucia – w moim przypadku zmiana liczby kanałów w zestawie R9M + R9MM z 16ch na 8-ch przyniosła znaczą poprawę. Quadcopter chętniej i pewniej reaguje no moje ruchy drążków w aparaturze. Oczywiście, oprócz zmiany liczby kanałów – nic więcej nie zmieniałem w ustawieniach.

Niestety zastosowanie 8ch spowodowało, że zabrakło mi kanałów do chociażby aktywacji opcji GPS RESCUE… Czeka mnie nowa konfiguracja trybów lotu w Betaflight, by zmieścić się w tych 8-kanałach.

A może opóźnienia nie pochodzą z R9M + R9MM?

Oglądałem wiele testów opóźnień przesyłania danych przez zestaw R9M + R9MM, lecz jeden z nich zwrócił moją największą uwagę. Dokładniej mowa o filmie YouTubera Drone Mesh: Transmitters Latency // FrSky 8ch vs 16ch Latency, gdzie przeprowadzone były pomiary długości ramek danych 8 i 16 kanałów dla zestawu dalekiego zasięgu od FRSKY. Takich testów na YouTube, czy innych stronach jest wprawdzie wiele, lecz warto przeczytać komentarze, a w śród nich:

16 channels are always sent no matter what in 9ms wether u set 4ch or 16ch. I just had a call with joshua Bardwell about this and I was checking the betaflight code and black box. The extra latency is from the code and not sbus protocol. If channels 9-16 are not blank then betaflight takes 2 frames as one thus increasing latency.

Co można przetłumaczyć następująco:

Zestaw FRSKY R9M wysyła dane wszystkich kanałów do odbiornika w równych odstępach 9 milisekund. Nie ma znaczenia, czy ustawimy kanałów 16, czy 8 – odstęp między kolejnym wysłaniem kompletu ramek zawsze wynosi 9 ms. Joshua Bardwell także badał tę sprawę. Jego badania i testy wykazały, że sprawcą opóźnień odbioru danych z 16CH jest sam kod Betaflight. I nie chodzi tu nawet o protokół SBUS… Problem wynika z wypełniania wolnych kanałów w konfiguracji 9-16CH przez Betaflight, przez co dodawane są dodatkowe dwie ramki danych. A to z kolei wydłuża czas odpowiedzi na kolejne przesyłane dane.

Pozostało zatem nam czekać na poprawę kodu oprogramowania Betaflight przez jego twórców.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *