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 e-mail nie zostanie opublikowany.