Stan początkowy: jeden tor komunikacji dla różnych zadań

Telemetria, komendy sterujące i większe dane przestrzenne współdzieliły założenia dotyczące częstotliwości oraz niezawodności. Ramka telemetrii miała około 75 bajtów, ramka sterowania około 20 bajtów, a pętla decyzyjna SBC pracowała z częstotliwością 30 Hz — jeden cykl co 33,3 ms.

TELEMETRIA~75 B28 B

stała ramka binarna, sekwencja i znacznik czasu

STEROWANIE~20 B9 B

mała niezawodna komenda z potwierdzeniem

PĘTLA DECYZYJNA30 Hz60 Hz

z 33,3 ms do 16,7 ms na cykl

Diagnoza: niezawodność i częstotliwość to nie to samo wymaganie

Świeża telemetria szybko traci wartość, dlatego spóźniony pakiet bywa gorszy niż pakiet pominięty. Komenda napędu jest inna: liczą się kolejność i potwierdzenie. Dane przestrzenne są cięższe i zmieniają się wolniej. Traktowanie wszystkich trzech strumieni jednakowo tworzyło zbędny narzut oraz łączyło niezależne tryby awarii.

Koniec z backlogiem: telemetria ma dostarczać najnowszy stan, nie historię kolejki

W ścieżce czasu rzeczywistego FIFO może zachować próbki poprawne technicznie, ale już nieaktualne. Jeżeli odbiorca chwilowo zwolni, nadrabianie t−3, t−2 i t−1 tylko opóźnia dojście do stanu t. Starsza próbka może więc zostać pominięta, aby odbiorca pracował na najświeższej poprawnej ramce.

Przed: kolejka i nadrabianie pomiar → serializacja → kolejka → transport → kolejka → parser → decyzja
Po: latest-state / no backlog pomiar → aktualna ramka → transport → walidacja → aktualny stan
Telemetria Najnowsza wartość, numer sekwencji i wiek danych. Stare próbki nie są nadrabiane.
Sterowanie Kolejność, ACK i ograniczone retry. Komendy nie są traktowane jak ulotna telemetria.
Mapa / dane przestrzenne Osobny strumień o niższej częstotliwości zapobiega blokowaniu świeżego stanu przez cięższy transfer.
Architektura komunikacji ESP32–SBC po przebudowie
Rev. 1: świeżość, niezawodność i częstotliwość są osobnymi wymaganiami protokołu.
Komunikacja ESP32–SBC przed i po usunięciu backlogu telemetrii
Przed i po: kolejka starych próbek kontra praca na najnowszym stanie.

Decyzja: rozdzielenie kanałów

01Telemetria UDPWysoka częstotliwość, zwarta ramka binarna, numer sekwencji i znacznik czasu.
02Niezawodne sterowanieMałe uporządkowane komunikaty z jawnym potwierdzeniem i polityką ponowień.
03Strumień danych przestrzennychWiększe ładunki przy niższej, niezależnej częstotliwości aktualizacji.
04Lokalny watchdogESP32 przechodzi do bezpiecznego stanu STOP po wygaśnięciu poprawnego sterowania.

Stałe ramki i bit-pakowanie: parser czyta offsety zamiast interpretować opis wiadomości

Redukcja 75 → 28 B oraz 20 → 9 B nie wynika wyłącznie z kompresji. Reprezentacja została zmieniona na stałą ramkę binarną, pola o znanej szerokości oraz flagi pakowane bitowo. Odbiorca czyta przewidywalne offsety i waliduje wersję, sekwencję, timestamp oraz sumę kontrolną.

7
6
5
4
3
2
1
0
Flagi bitowe READY, ERROR, LIMIT, ESTOP i SENSOR_OK mogą zajmować pojedyncze bity zamiast osobnych pól tekstowych.
Stałe offsety Znacznik, wersja, sekwencja, timestamp, flagi, payload i checksum mają przewidywalne pozycje.
Mniej pracy Mniej bajtów, kopiowania, serializacji i parsowania w ścieżce krytycznej.
Stała binarna ramka ESP32–SBC z bit-pakowaniem flag
Stałe pola, flagi bitowe i przewidywalne offsety ograniczają pracę parsera.
Ważne: brak kolejki dotyczy świeżej telemetrii. Sterowanie nadal zachowuje kolejność, ACK i ograniczone retry.

Dlaczego watchdog pozostaje po stronie ESP32

Komputer z Linuksem może się zrestartować, zawiesić albo utracić łącze. Reakcja awaryjna nie może więc zależeć od tej samej ścieżki, która mogła ulec awarii. ESP32 mierzy wiek ostatniej zaakceptowanej komendy i lokalnie zatrzymuje wyjścia po skonfigurowanym czasie.

WATCHDOG / PSEUDOCODEESP32
if (now_ms - last_valid_control_ms > CONTROL_TIMEOUT_MS) {
    drive_left = 0;
    drive_right = 0;
    state = SAFE_STOP;
}

Rezultat i interpretacja

Mniejsze ramki ograniczyły pracę serializacji i parsowania, a niezależne kanały zapobiegły blokowaniu świeżej telemetrii przez większe lub niezawodne transfery. W zmierzonym systemie pętla decyzyjna wzrosła z 30 Hz do 60 Hz. Kluczowa poprawa była architektoniczna: każda klasa danych otrzymała transport oraz politykę awarii odpowiadającą jej rzeczywistym potrzebom.

COMMUNICATION KIT

Firmware referencyjny, kod SBC i dokumentacja protokołu.

Dołączona paczka zawiera przykład Arduino, pakiet Python dla SBC, testy, dokumentację protokołu i licencję. Przed użyciem na sprzęcie sprawdź stałe, piny oraz progi bezpieczeństwa.

Pobierz ZIP