Budowa łazika RTK: Precyzyjna nawigacja sterowana z aplikacji webowej

Jeśli kiedykolwiek zastanawiało Cię, jak naprawdę działają systemy nawigacji precyzyjnej „od kuchni”, albo jeśli rozważałeś włączenie technologii pozycjonowania o wysokiej dokładności do jednego ze swoich projektów, ale nie byłeś pewien, od czego zacząć, wierzę, że ten artykuł dostarczy Ci wartościowych informacji oraz praktycznych wskazówek, które uznasz za interesujące i przydatne.

Moim celem było zbudowanie zintegrowanego systemu składającego się z dwóch głównych komponentów:

• wysokoprecyzyjnego odbiornika GNSS (Global Navigation Satellite System) – Łazika,
• webowej aplikacji sterującej – GNSS RTK Planner.

Dla Łazika wybrałem rozwiązanie RTK (Real Time Kinematic), aby uzyskać centymetrową dokładność pozycjonowania w czasie rzeczywistym. GNSS RTK Planner zaprojektowałem jako narzędzie z interaktywną mapą, które pozwala użytkownikom tworzyć ścieżki nawigacji (ang. Trails) i wysyłać je do podłączonych Łazików, których zadaniem jest przejechanie po wyznaczonej trasie.

GNSS i RTK

Gdy mówimy o nawigacji, zwykle używamy słowa „GPS”, co jest w pewnym sensie poprawne – ale tylko częściowo. Ogólna nazwa systemów nawigacji satelitarnej, z których powszechnie korzystamy w telefonach, samochodach itd., to GNSS (Global Navigation Satellite System). Jest to termin zbiorczy dla satelitarnych systemów nawigacyjnych, które zapewniają globalnie usługi pozycjonowania i synchronizacji czasu.

Obecnie dostępne są cztery globalne systemy:

• GPS (USA),
• GLONASS (Rosja),
• Galileo (Europa),
• BeiDou (Chiny).

I tak – oprócz systemów globalnych istnieją też systemy regionalne, takie jak QZSS (Japonia) czy NavIC (Indie), które działają tylko na wybranym obszarze.

Nie zamierzam opisywać, jak działa system GNSS (na ten temat istnieją tysiące książek i artykułów). Jest jednak jedna ważna rzecz, szczególnie przy wyborze odbiornika GNSS RTK, a mianowicie: Jakie typy sygnałów obsługuje.

Pasma częstotliwości

W dzisiejszych czasach satelity GNSS mogą transmitować na wielu pasmach częstotliwości. Jednak obecnie, w zastosowaniach cywilnych, najpopularniejsze są trzy (stosuję nazewnictwo GPS):

• pasmo L1 – podstawowy cywilny sygnał (każdy prosty odbiornik GNSS go obsługuje),
• pasmo L2 – pierwotnie wojskowe (GPS), obecnie używane także w zaawansowanych zastosowaniach cywilnych,
• pasmo L5 – nowszy cywilny sygnał typu safety‑of‑life (większa moc w porównaniu do L2, szersze pasmo, mniejsza podatność na zakłócenia z innych systemów).

Nieco bardziej przekrojowy opis wszystkich dostępnych pasm częstotliwości używanych w systemach nawigacyjnych znajduje się na diagramie poniżej. Każdy GNSS stosuje własne nazewnictwo, nieco inne częstotliwości, a czasem nawet inne typy modulacji. Na szczęście anteny i odbiorniki GNSS zwykle obsługują te różne rozwiązania.

Każda częstotliwość przenosi inne kody oraz wiadomości nawigacyjne. Wykorzystanie wielu częstotliwości pomaga korygować opóźnienia atmosferyczne, szczególnie te wynikające z jonosfery. Systemy RTK mogą działać na jednym paśmie (L1), ale konfiguracja dwupasmowa (L1+L2 lub L1+L5) albo trójpasmowa zapewnia zauważalnie lepszą stabilność i precyzję. Dlatego zdecydowałem się na odbiornik GNSS RTK obsługujący L1 i L2.

Nie wszystkie satelity wykorzystują wszystkie częstotliwości – część satelitów może obsługiwać tylko dwa z trzech sygnałów (zwykle starsze jednostki wystrzelone wiele lat temu). Poniższa tabela pokazuje uproszczony zestaw dostępnych satelitów i typów sygnałów, które emitują (stan na 2025 r.).

Ulepszenia systemu

Klasyczny cywilny GNSS zapewnia stosunkowo niską precyzję – do około 7 metrów w bardzo dobrych warunkach. Dlatego zaczęto rozwijać ulepszenia tego systemu.

Oto niektóre z nich:

• SBAS (Satellite‑Based Augmentation Systems) – systemy transmitujące dane korekcyjne przez satelity geostacjonarne, poprawiające dokładność do 1–3 metrów bez dodatkowej infrastruktury naziemnej.
• DGPS (Differential GPS)  wykorzystuje pobliską stację referencyjną do obliczania i nadawania poprawek opartych na kodach, osiągając dokładność od poniżej 1 metra do 1–2 metrów w zależności od odległości od stacji bazowej.
• PPP (Precise Point Positioning) – wykorzystuje precyzyjne poprawki orbit i zegarów satelitów (dostarczane przez internet lub satelitę), aby uzyskać dokładność od decymetrów do centymetrów globalnie, choć wymaga dłuższego czasu zbieżności (10–30 minut) w porównaniu do niemal natychmiastowych poprawek RTK.
• RTK (Real‑Time Kinematic) – wykorzystuje pomiary fazy nośnej i poprawki w czasie rzeczywistym ze stacji bazowej, aby uzyskać dokładność centymetrową (1–3 cm), ale wymaga stałego łącza danych i działa najlepiej w promieniu 10–30 km od bazy. Nie każdy standardowy odbiornik GNSS obsługuje taką funkcjonalność. W tym projekcie użyłem PX1122R, który pracuje w paśmie L1 i L2 oraz obsługuje wszystkie dostępne systemy GNSS.

Stacja bazowa RTK

Sam odbiornik to jednak nie wszystko – potrzebne jest także źródło danych korekcyjnych, czyli stacja bazowa RTK. Może to być inny stacjonarny odbiornik GNSS RTK (np. PX1122R) ustawiony w precyzyjnie znanej lokalizacji, który generuje i transmituje poprawki do Łazika. W moim przypadku oznaczałoby to niepotrzebne koszty, więcej pracy i problemy.

Na szczęście niektóre usługi udostępniają dane korekcyjne RTK bezpłatnie przez internet, wykorzystując NTRIP (Networked Transport of RTCM via Internet Protocol). Jedną z nich, w mojej lokalizacji, jest system ASG‑EUPOS – i zdecydowałem się z niego skorzystać. Aby zacząć, wystarczy się zarejestrować.

Implementacja i wyzwania

Ten projekt ma charakter PoC, więc zdecydowałem się użyć sprzętu i narzędzi, które upraszczają i przyspieszają rozwój (np. MicroPython na ESP32). Na samym początku spróbowałem zdefiniować wymagania, które zaważyły na całym projekcie.

Dla Łazika:

• Precyzja musi być na poziomie centymetrów.
• Łazik musi znać swoją pozycję i kierunek (ang. heading) cały czas, także gdy się nie porusza.
• Łazik jest małym urządzeniem (centymetry).
• Łazik pracuje na małych obszarach (kilka metrów).

Dla GNSS RTK Planner:

• Zestawić łącze komunikacyjne z urządzeniem Łazika.
• Wizualnie definiować ścieżkę (ang. Trail) poprzez interakcję z interfejsem mapy.
• Wyświetlać Trail na mapie.
• Wysyłać Trail do podłączonego Łazika.
• Wyświetlać na mapie pozycję podłączonego Łazika w czasie rzeczywistym.

Cały system – poza oczywistymi komponentami, takimi jak Łazik oraz GNSS RTK Planner – wymaga nie tylko wysokiej jakości odbioru sygnału GNSS, ale również danych korekcyjnych w czasie rzeczywistym ze stacji bazowej RTK, aby działać poprawnie.

Działanie systemu

Użycie i działanie systemu można opisać następującą sekwencją:

1. Uruchom aplikację GNSS RTK Planner i zdefiniuj Łazika, wpisując jego nazwę oraz adres MAC modułu ESP32 zainstalowanego w naszym Łaziku. W tym momencie możemy monitorować status połączenia, aktualną jakość fixa GNSS oraz pozycję Łazika.
2. Włącz Łazika, który wykonuje następującą sekwencję: Weryfikuje łączność z internetem, dostęp do usługi NTRIP oraz łączy się z aplikacją GNSS RTK Planner. Po potwierdzeniu wszystkich etapów Łazik zestawia komunikację z GNSS RTK Planner i zaczyna przesyłać dane GNSS. Jeśli nie ma dostępu do internetu albo występuje problem z którąkolwiek z wymaganych usług, zaczyna migać niebieska dioda LED.
3. (Opcjonalnie) Skalibruj kompas – naciśnij dedykowany przycisk na 2 sekundy; powinna zaświecić się żółta dioda LED. Teraz płynnie obracaj Łazika w różnych kierunkach. Czas kalibracji ustawiono na 2 minuty, co jest w zupełności wystarczające.
4. W GNSS RTK Planner użyj interfejsu mapy, aby utworzyć Trail – ścieżkę, którą ma podążać Łazik. Zdefiniowany Trail jest następnie przypisywany do Łazika zdefiniowanego w aplikacji.
5. Na tym etapie można przesłać przypisany Trail do Łazika i obserwować jego ruch na mapie w aplikacji.

GNSS RTK Planner

GNSS RTK Planner to aplikacja webowa, która łączy Flask oraz projekt OpenLayers, aby zapewnić interaktywne doświadczenie pracy z mapą. Interfejs zaprojektowano z myślą o prostocie, dzięki czemu łatwo jest tworzyć, aktualizować i usuwać Łaziki oraz Traile.

Każdy Trail jest zbiorem waypointów GNSS, które można definiować, rysując linie albo umieszczając pojedyncze punkty bezpośrednio na mapie. Po zdefiniowaniu Trail może zostać przypisany do jednego lub wielu Łazików w aplikacji i następnie wysłany do urządzenia. Zdefiniowany Trail można też wyświetlać na mapie po jego wybraniu.

Łazik

Jako platformę bazową Łazika wybrałem ESP32 (dwurdzeniowy procesor, zintegrowane Wi‑Fi oraz konfigurowalne porty GPIO) i zaprogramowałem go w MicroPythonie. Odbiornik GNSS RTK to PX1122R (L1+L2) sparowany z wieloczęstotliwościową anteną wysokiej precyzji L1/L2/L5.

Łazik zawiera także elektroniczny kompas (IMU9v6), który jest niezbędny do dokładnego wyznaczania kierunku. Do celów demonstracyjnych Łazik został wyposażony w koła napędzane dwoma silnikami DC i sterowane przez MX1508.

Potrzeba użycia kompasu wynika ze specyfiki projektu – natychmiastowego określenia kierunku po uruchomieniu oraz bardzo niskiej prędkości Łazika. Teoretycznie kierunek można by wyznaczać wyłącznie na podstawie sygnału GNSS (dynamicznie, z kierunku zmiany pozycji w czasie), ale w takim przypadku minimalna prędkość Łazika musiałaby wynosić >1 m/s, a tak nie jest.

Alternatywnie, zamiast kompasu można by zastosować zaawansowaną konfigurację Moving Base Mode (dwa odbiorniki RTK na urządzeniu) – ale to materiał na inny projekt, z innymi wymaganiami.

Użyłem konfiguracji PX1122R „Rover Mode Configuration 2” (zob. PX1122R_DS.pdf) z częstotliwością aktualizacji RTK ustawioną na 1 s (co 1 sekundę moduł wysyła dane GNSS przez UART do ESP32). Wyposażyłem płytkę w baterię podtrzymującą, aby zminimalizować czas uruchomienia i zachować konfigurację.

Zgodnie z danymi z dokumentacji PX1122R uzyskuje RTK Fix w ok. 30 s po włączeniu, przy spełnieniu określonych warunków:

• Odległość od stacji bazowej RTK mniejsza niż 30 km (u mnie było to ok. 2 km).
• 8 lub więcej satelitów powyżej 15° elewacji, z dobrą geometrią (niskie DOP – Dilution of Precision). Mówiąc prościej: Czasem 8 lub więcej satelitów o silnym sygnale nie wystarcza do uzyskania RTK Fix, jeśli nie są dobrze rozmieszczone na niebie.
• Otwarte niebo (open sky) bez zakłóceń.
• Sygnał powyżej 37 dB/Hz.

Dodałem baterię, przełączniki, kilka przewodów i po złożeniu całość umieściłem w „wyspecjalizowanym” 2‑litrowym pojemniku. Aby wprawić Łazika w ruch, przymocowałem dwa koła napędowe (każde sterowane osobnym silnikiem DC).

Wyzwania

Podczas doboru sprzętu nie wziąłem pod uwagę maksymalnej precyzji liczb zmiennoprzecinkowych. Dla ESP32 w najlepszym przypadku jest to do 7 miejsc po przecinku, co nie wystarcza dla precyzji systemu RTK (np. 52.123456789 wymaga ~10 cyfr znaczących). W praktyce wyniki były jeszcze gorsze ze względu na kumulację błędów podczas obliczeń.

Mimo wszystko zaakceptowałem to wyzwanie – zachowałem konfigurację sprzętową, a w części kodu odpowiedzialnej za obliczenia współrzędnych użyłem liczb całkowitych. Następnym razem wybrałbym jednak platformę 64‑bitową.

Kolejnym wyzwaniem i obecną słabością projektu jest kontrola trakcji. Wynika to z połączenia różnych problemów – od mechanicznych (np. nietrafiony dobór silników DC i kół), przez słabą jakość przekładni planetarnych, aż po niedopracowane sterowanie napędem oraz kompas.

Kontrola trakcji nie była głównym celem projektu, a mimo to to właśnie ona sprawiła najwięcej trudności podczas rozwoju.

Kod źródłowy projektu jest dostępny na GitHubie.

Embedded Systems

Oferujemy usługi R&D, projektowania, tworzenia i testowania systemów wbudowanych, zapewniając bezpieczeństwo i niezawodność Twoich technologii.

Oferta Embedded systems

Demonstracja i wnioski

Demonstrację przeprowadzono w dość wymagającym środowisku miejskim, gdzie odbiór sygnału GNSS był istotnie ograniczony przez budynki, konstrukcje i inne przeszkody, które uniemożliwiały idealny, niczym niezakłócony widok na niebo.

Na potrzeby testu użyłem trzech tras nawigacyjnych (Trails):

• ścieżki liniowej,
• trasy w kształcie kwadratu,
• trasy trójkątnej – każda na obszarze nie większym niż 3 m × 3 m.

Aby ustalić realistyczne parametry działania, skonfigurowałem system z progiem akceptacji ±20 cm dla każdego docelowego waypointu GNSS. Oznaczało to, że Łazik musiał zbliżyć się w granicach tej tolerancji, aby poprawnie zarejestrować dotarcie do wyznaczonego punktu współrzędnych.

Dołączona prezentacja wideo pokazuje, że Łazik podąża za przypisanymi trasami poprawnie. Nie podąża idealnie po liniach łączących współrzędne GNSS, ale z błędem rzędu centymetrów. Na podstawie obserwacji podczas prób oszacowałem, że maksymalny błąd pozycjonowania w najgorszym przypadku wynosił około 40 cm od wyznaczonej ścieżki.

Zaobserwowane odchylenie od idealnego toru można przypisać głównie ograniczeniom systemu kontroli trakcji, któremu brakuje precyzji i responsywności potrzebnych do śledzenia ścieżki z dokładnością pojedynczych centymetrów.

Poza tym rozwiązanie spełniało początkowe cele i stanowiło dobry punkt wyjścia do dalszego rozwoju.

Referencje

• PX1122R_DS.pdf
• Satellite Navigation – GPS – How It Works | Federal Aviation Administration
• DOD Positioning, Navigation, and Timing (PNT) Executive Committee
• Official GPS Government Website (GPS.gov) 
• European Space Agency (ESA)
• China Satellite Navigation Office (CSNO) 
• UN Office for Outer Space Affairs (UNOOSA)
• GNSS-SDR 
• System ASG-EUPOS
• Swift Navigation Support
• RTK, PPP and autonomous