Ł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.