Łazik Heveliusz

[adrianjanisze]

19 minut temu, Kogut007 napisał:

Nie tędy droga. Pomysł znakomity, ale wykonanie już nie. Moim zdaniem na początku należy zdefiniować protokół komunikacji, a w sprzęcie go po prostu zaimplementować. Pomysł ma być oparty o WiFi. Zatem mamy tu standardowe protokoły TCP/IP oraz UDP. Na TCP/IP zbudowany jest protokół HTTP, czyli powszechnie używany protokół internetowy. W modułach ESP, Rapberry i innych jest on dostępny sprzętowo lub w standardowych bibliotekach. Zatem przy założeniu, że realizujemy protokół klient/serwer  należy podjąć decyzję, kto jest serwerem, a kto klientem. Moim zdaniem każdy robot na poligonie powinien być serwerem (wykonawcą poleceń), zaś poligon klientem (żąda i oczekuje odpowiedzi albo pracuje jako router). Rozwiązuje to problem adresacji robotów - na poligonie może ich być dużo, a także sterowania robotem skądkolwiek. Biblioteki obsługujące HTTP są powszechnie dostępne, także na Arduino. Potrzeba zatem zdefiniować komunikację między klientem a serwerem, czyli listę (szczegółową) komend i odpowiedzi.

W zasadzie opisujesz dokładnie ten element, który w projekcie już został opracowany.

Zgadzam się, że fundamentem całego rozwiązania musi być dobrze zdefiniowany protokół komunikacji oraz jasny podział odpowiedzialności pomiędzy urządzeniem a infrastrukturą. Natomiast w tym projekcie przyjąłem inne założenie projektowe — nie tworzymy platformy od zera razem z każdym użytkownikiem, tylko dajemy gotowy ekosystem, w którym użytkownik może skupić się na budowie, programowaniu i rozwijaniu samego robota.

Projekt jest kierowany głównie do osób na poziomie szkoły technikum, liceum, studentów oraz hobbystów. Oczywiście wśród hobbystów znajdą się osoby z dużo większą wiedzą, które będą chciały eksperymentować głębiej, ale nie zakładam, że każdy uczestnik będzie pisał od podstaw własny system komunikacji, autoryzacji, zarządzania urządzeniami czy całą infrastrukturę serwerową.

Dlatego zanim powstał sam łazik i koncepcja poligonu, najpierw został opracowany właśnie ten element — płytka komunikacyjna oraz platforma ADEAS WEB OS.

Schemat działania wygląda w uproszczeniu tak:

Łazik → ADEAS328P → ADEAS WEB OS → użytkownik

Płytka pełni rolę warstwy pośredniej odpowiedzialnej za komunikację z platformą. Ta część jest zamknięta, zabezpieczona i odpowiedzialna za stabilność całego ekosystemu. Każde urządzenie posiada własny unikalny token, dzięki czemu po zalogowaniu użytkownik widzi tylko swoje urządzenia, swoje dane oraz swoje misje.

Na platformie użytkownik może obserwować dane z robota, tworzyć dedykowane widgety, analizować parametry i sterować przygotowanymi funkcjami.

Oczywiście można by było podejść do tego inaczej — udostępnić sam protokół i powiedzieć każdemu użytkownikowi: „zbuduj sobie całą infrastrukturę sam”. Technicznie jest to możliwe, ale moim zdaniem wtedy tracimy główną wartość projektu edukacyjnego. Zamiast uczyć robotyki, programowania autonomicznych zachowań i rozwiązywania problemów, duża część osób utknęłaby na etapie tworzenia komunikacji, serwera, zabezpieczeń czy aplikacji.

Chcę, aby uczestnik mógł zacząć od poziomu: „buduję robota, programuję go i wysyłam na misję”, a nie od poziomu: „najpierw przez kilka miesięcy tworzę własną chmurę IoT”.

Natomiast dla bardziej zaawansowanych użytkowników oczywiście pozostaje możliwość budowy własnych algorytmów, własnych modułów i własnych rozwiązań sprzętowych — standard komunikacyjny jest po to, aby połączyć robota z poligonem, a nie ograniczać jego rozwój.

[Kogut007]

I jeszcze problem pieniędzy. Po co kupować płytkę komunikacyjną za 120 zł, jak można mieć to przy okazji wbudowanej maszyny sterującej lub po prostu modułu ESP za kilkanaście złotych. Po co konstruować system lokalizacyjny oparty o GPS (na pewno nie tani) jak można mieć system oparty o pomiar radiowy odległości na częstotliwościach KF (SW) powiedzmy 13,56 i 27,12 MHz, zasięgu odpowiadającemu tym pasmom na fali przyziemnej i dokładności rzędu 10 cm przy ułamku kosztów

[adrianjanisze]

9 minut temu, Kogut007 napisał:

I jeszcze problem pieniędzy. Po co kupować płytkę komunikacyjną za 120 zł, jak można mieć to przy okazji wbudowanej maszyny sterującej lub po prostu modułu ESP za kilkanaście złotych. Po co konstruować system lokalizacyjny oparty o GPS (na pewno nie tani) jak można mieć system oparty o pomiar radiowy odległości na częstotliwościach KF (SW) powiedzmy 13,56 i 27,12 MHz, zasięgu odpowiadającemu tym pasmom na fali przyziemnej i dokładności rzędu 10 cm przy ułamku kosztów

Myślę, że w tym miejscu zaczynamy wchodzić w klasyczną dyskusję inżynierską, w której dla tego samego problemu można zaproponować kilka różnych, poprawnych rozwiązań. Nie twierdzę, że proponowane przez Ciebie podejście jest złe — po prostu przy projektowaniu tego systemu przyjąłem inne priorytety.

Jeżeli chodzi o płytkę za około 120 zł, to jej wartość nie wynika wyłącznie z kosztu samej elektroniki. Gdyby chodziło tylko o komunikację WiFi, rzeczywiście można byłoby wykorzystać samo ESP32 za kilkanaście czy kilkadziesiąt złotych. W tym przypadku użytkownik otrzymuje jednak również dostęp do gotowej infrastruktury: platformy ADEAS WEB OS, serwera, mechanizmów komunikacji, autoryzacji urządzeń, widgetów, telemetrii oraz narzędzi do integracji z poligonem. Tak naprawdę płaci więc nie tylko za sprzęt, ale za cały działający ekosystem.

Podobnie wygląda kwestia lokalizacji. Rozwiązania oparte o pomiary radiowe są bardzo ciekawe i sam analizowałem różne warianty. Ostatecznie jednak zależy mi na systemie, który będzie możliwie niezawodny w warunkach rzeczywistego, otwartego poligonu, gdzie pojawiają się przeszkody terenowe, zmienne warunki atmosferyczne oraz konieczność obsługi wielu urządzeń jednocześnie.

Dodatkowo jednym z założeń projektu jest prezentowanie pozycji łazika w postaci standardowych współrzędnych geograficznych i nanoszenie jej bezpośrednio na odpowiednio przygotowane mapy. Z tego względu naturalnym kierunkiem jest wykorzystanie GPS wspieranego przez technologie zwiększające dokładność, takie jak RTK czy UWB.

Najważniejsze jest jednak to, że cały projekt musi pozostać dostępny cenowo. Naszym celem jest, aby kompletny łazik zamknął się w przedziale 700–1000 zł, więc wszystkie rozwiązania są dobierane nie tylko pod kątem parametrów technicznych, ale również kosztów wdrożenia i późniejszego utrzymania.

Być może za kilka lat okaże się, że pojawi się lepsza lub tańsza technologia lokalizacji i wtedy warto będzie ją rozważyć. Na obecnym etapie skupiam się jednak przede wszystkim na rozwiązaniach, które są sprawdzone, dostępne i pozwolą uruchomić cały ekosystem w rozsądnym budżecie.

 

[Kogut007]

Co do protokołów: -> udostępnić sam protokół i powiedzieć każdemu użytkownikowi: „zbuduj sobie całą infrastrukturę sam” <-Czy instalując serwer WWW na swojej maszynie musimy oprogramowywać cały Internet? Skoro a to służyć do nauki, to czy nie opublikować protokołów, udostępnić plik binarny dla wybranego taniego procesora, np z rodziny STM32? I pytanie fundamentalne: czy projekt ma być OpenSource?

[adrianjanisze]

13 minut temu, Kogut007 napisał:

Co do protokołów: -> udostępnić sam protokół i powiedzieć każdemu użytkownikowi: „zbuduj sobie całą infrastrukturę sam” <-Czy instalując serwer WWW na swojej maszynie musimy oprogramowywać cały Internet? Skoro a to służyć do nauki, to czy nie opublikować protokołów, udostępnić plik binarny dla wybranego taniego procesora, np z rodziny STM32? I pytanie fundamentalne: czy projekt ma być OpenSource?

Na obecnym etapie świadomie nie zdecydowałem się na model Open Source. Nie dlatego, że jestem przeciwnikiem otwartych rozwiązań, ale dlatego, że projekt znajduje się jeszcze na etapie budowy i weryfikacji podstawowych założeń.

Pierwszym celem jest stworzenie działającego ekosystemu, przekazanie łazików grupie uczniów i hobbystów, sprawdzenie jak radzą sobie z montażem, programowaniem oraz realizacją misji, a następnie wyciągnięcie wniosków i wprowadzenie poprawek. Dopiero gdy będę miał pewność, że wszystkie kluczowe elementy działają zgodnie z założeniami, będzie można rozważać kolejne kierunki rozwoju.

To, o czym piszesz — publikacja protokołów, udostępnienie firmware'u, otwarcie części komunikacyjnej czy nawet przejście w stronę Open Source — jest jak najbardziej możliwym scenariuszem w przyszłości. Natomiast na obecnym etapie oznaczałoby to równoległe rozwijanie kilku różnych ścieżek projektu, a to przy ograniczonych zasobach bardzo często kończy się rozproszeniem prac i problemami z doprowadzeniem czegokolwiek do etapu produkcyjnego.

Dzisiaj zależy mi przede wszystkim na tym, aby odpowiedzieć na jedno podstawowe pytanie: czy sam pomysł działa w praktyce i czy sprawia użytkownikom tyle satysfakcji, ile zakładam.

Wybierając gotowe moduły, gotową komunikację i zamknięty ekosystem, mam znacznie większą kontrolę nad jakością działania całego rozwiązania. Wiem również, że osoba posiadająca podstawową wiedzę z elektroniki i Arduino będzie w stanie złożyć łazika, uruchomić go i czerpać z tego przyjemność bez konieczności zagłębiania się w zagadnienia związane z serwerami, bezpieczeństwem czy architekturą komunikacji.

Nie wykluczam więc modelu Open Source w przyszłości, ale dzisiaj skupiam się na jednej, jasno określonej ścieżce rozwoju. Najpierw chcę zbudować działający produkt, sprawdzić go w praktyce i zebrać doświadczenia od użytkowników. Dopiero później będę podejmował decyzję, czy i które elementy warto otworzyć dla społeczności.

Można powiedzieć, że obecnie priorytetem jest skuteczne wystartowanie projektu, a nie maksymalizacja liczby możliwych kierunków jego rozwoju od pierwszego dnia.

[Kogut007]

Rozumiem. Jeśli mogę coś zasugerować, to pomyśl o najnowszym Buuetooth 6. 

[Sylba]

Dnia 26.07.2026 o 13:26, adrianjanisze napisał:

stworzenie robotów–łazików, które mogłyby poruszać się po otwartych oraz specjalnie przygotowanych terenach. Chciałem stworzyć coś, co w pewnym stopniu przypomina misje prowadzone przez NASA na Marsie,

Super pomysł, ale po przeczytaniu dotychczasowej dyskusji mam sporo pytań i wątpliwości.
Moim zdaniem projekt jest bardzo złożony i multidyscyplinarny: mechanika, elektrotechnika, robotyka, programowanie, telekomunikacja więc jakoś słabo widzę by jeden wykonawca był w stanie sprostać tym wszystkim wyzwaniom. Bardziej przekonuje mnie podejście zespołowe - czasy pionierów omnibusów już chyba bezpowrotnie minęły.

Dotychczasowa dyskusja w zasadzie skupiła się na kwestii programowania i protokołów komunikacyjnych. Niewiele było w niej mowy o założeniach mechanicznych oraz o samym poligonie. Jakiej wielkości mają być roboty lub jakiej wielkości będą przeszkody? Jakiej wielkości będzie poligon?

Zapytałem AI co mśli o zaproponowanych rozwiązaniach. Myślę, że warto zacytować niektóre odpowiedzi.

Zasięg standardowej sieci Wi-Fi (2.4 GHz / 5 GHz) w otwartym terenie wynosi zazwyczaj od 100 do 300 metrów, jednak przy zastosowaniu kierunkowych anten o wysokim zysku lub systemów radiolinii można go rozszerzyć do kilku kilometrów. Odporność na zakłócenia w warunkach poligonowych jest bardzo niska do umiarkowanej, ponieważ pasma te są nielicencjonowane (podatne na interferencje), a sygnał ulega silnemu tłumieniu przez przeszkody terenowe, roślinność oraz zjawisko wielodrogowości.

Zasięg sieci Wi-Fi w terenie otwartym

Zasięg zależy od częstotliwości, mocy nadawczej (w Polsce ograniczonej prawnie) oraz zysku energetycznego anten:

Pasmo 2.4 GHz: Oferuje lepszy zasięg (teoretycznie do 150–300 m przy standardowych antenach dookólnych) i lepiej radzi sobie z przeszkodami, ale ma mniejszą przepustowość i jest bardziej zatłoczone.

Pasmo 5 GHz / 6 GHz (Wi-Fi 6E/7): Zapewnia ogromną przepustowość i mniejsze opóźnienia, ale jego zasięg w terenie spada o połowę (ok. 50–120 m) i jest bardzo silnie tłumiony przez przeszkody (np. wzniesienia, ściany, gęste krzewy).

 

Odporność na zakłócenia i czynniki środowiskowe

Konwencjonalne Wi-Fi na poligonie robotycznym mierzy się z kilkoma kluczowymi problemami:

Interferencje (Zatłoczenie pasma): Ponieważ pasma 2.4 GHz i 5 GHz są ogólnodostępne (ISM), każdy smartfon, lokalny router czy inne systemy telemetryczne uczestników mogą zakłócać transmisję.

Zjawisko wielodrogowości (Multipathing): Sygnał odbija się od ziemi, skał i metalowych elementów robotów. Fale docierają do odbiornika w różnym czasie i przesunięciu fazowym, co prowadzi do wygaszania sygnału i gubienia pakietów danych.

Tłumienie przez przeszkody (NLOS – Non-Line of Sight Łaziki poruszają się nisko przy ziemi. Wszelkie nierówności terenu, nasypy, a nawet wysoka, mokra trawa mogą całkowicie odciąć sygnał radiowy o wysokiej częstotliwości (szczególnie 5 GHz).

Efekt Dopplera: Przy szybkim ruchu robota lub gwałtownych zmianach pozycji anten, częstotliwość fali ulega minimalnej zmianie, co w standardowym Wi-Fi może powodować chwilowe zerwanie synchronizacji.

Alternatywy i rekomendacje usprawnień

Aby zapewnić niezawodność testów na poligonie, warto zasugerować organizatorom następujące rozwiązania:

Systemy radiowe COFDM: Profesjonalne systemy transmisji wideo i danych (często stosowane w dronach i robotach militarnych) działające na niższych częstotliwościach (np. 433 MHz, 868 MHz lub 1.4 GHz). Są niezwykle odporne na odbicia i przeszkody terenowe.

Protokół Elrs (ExpressLRS) lub LoRa: Do przesyłania samych komend sterujących i telemetrii. Oferują zasięg wielu kilometrów i potężną odporność na zakłócenia kosztem niskiego transferu danych (nie nadają się do transmisji wideo HD).

Prywatna sieć 4G LTE / 5G (Private 5G): Coraz popularniejsze rozwiązanie na nowoczesnych poligonach przemysłowych i badawczych. Zapewnia pełną kontrolę nad pasmem, brak zakłóceń zewnętrznych, doskonały zasięg przy ziemi oraz minimalne, stabilne opóźnienia.

Edytowano 3 godziny temu przez Sylba

[Sylba]

W uzupełnieniu mojego poprzedniego postu podaję kilka linków do stron poświęconych zawodom łazików marsjańskich:

Strona Koła Naukowego Robotyków MEiL KNR - Rover Team z Politechniki Warszawskiej

Legendary Rover Team z Politechniki Rzeszowskiej

Impuls z Politechniki Świętokrzyskiej

University Rover Challenge

[bjrk]

@adrianjanisze
W tej chwili, najważniejszym dla mnie pytaniem jest, czy płytka wymaga poligonu? Jeśli nie to jestem nią zainteresowany. I chętnie nabędę ją za sensowną cenę (zaproponowana 120zł jest OK, obawiam się, jednak, że po analizie będzie jednak znacznie więcej).

Jeśli natomiast robot zbudowany w oparciu o płytkę może działać tylko na poligonie... wtedy jedynie był bym skłonny zapłacić z wynajęcie Twojego robota na jakiś czas, do zabawy. I tu znowu pojawia się pytanie o cenę.

Wydaje mi się, że reklamę można zacząć od tej strony. Wykonać kilkanaście, kilkadziesiąt identycznych robotów/łazików, udostępnić ich wynajem, najpierw po cenach marketingowych, potem, jeśli pomysł chwyci, po cenach przynoszących jakiś dochód. 

Zaczął bym od tej strony: "Przekonaj się jaka to radocha jeździć prawdziwym łazikiem, jeśli chcesz pomożemy Ci zbudować własny i udoskonalać go".
Elektronika i robotyka mają wysoki próg wejścia, zabawa dronami nie.

A jeśli chodzi o "komputer leżący 2cm nad płytką". "Łazik Marsjański", to obiekt który nie może być bezpośrednio sterowany. Po prostu nie może i już. Opóźnienie sygnału w jedną stronę do (orientacyjnie) 20 minut. Dlatego sterować musi komputer. Jak widzisz jego połączenie (protokół komunikacyjny) z Twoją płytką?

 

[bjrk]

@adrianjanisze
Dodatkowe pytanie:
Jakie opóźnienie przewidujesz przy transmisji do użytkownika? Jeśli jeśli brak opóźnienia przynajmniej trzy minuty (minimalna odległość Mars Ziemia), to przestaje być to symulowany łazik marsjański w misji na Marsa, a pozostaje zdalnie sterowana zabawka na wzór łazika marsjańskiego. To nadal może być bardzo wartościowe i interesujące, ale model diametralnie się zmienia.