Łazik Heveliusz

[adrianjanisze]

Cześć wszystkim!

Nazywam się Adrian Janiszewski i jestem właścicielem firmy Kopernik86. Na początku chciałbym jednak zaznaczyć, że ten wpis nie ma być reklamą produktów ani usług mojej firmy. Kopernik86 powstał przede wszystkim po to, aby krok po kroku zrealizować moje wieloletnie marzenie.

Ale zacznijmy od początku.

Skąd wziął się pomysł na projekt?

Moim celem było 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, ale w skali dostępnej tutaj, w Polsce.

 

 

 

Wyobraziłem sobie sytuację, w której użytkownik siedzi przed komputerem, zdalnie steruje własnym łazikiem znajdującym się wiele kilometrów dalej i wykonuje nim określone misje na specjalnie przygotowanym poligonie.

Łazik mógłby eksplorować teren, pokonywać przeszkody, obserwować otoczenie, zbierać dane oraz realizować zadania przygotowane wcześniej przez organizatorów. Użytkownik nie musiałby fizycznie znajdować się obok robota.

Cel jest ambitny, dlatego projekt rozwijam już od kilku lat.

Własna elektronika i oprogramowanie

Prace rozpocząłem od stworzenia własnej elektroniki oraz dedykowanego oprogramowania, które pozwala na prostą komunikację z urządzeniem.

Jako podstawowy sposób komunikacji z łazikiem na poligonie wybrałem sieć Wi-Fi. Założenie było takie, aby urządzeniem można było sterować za pośrednictwem przeglądarki internetowej wszędzie tam, gdzie zapewniony jest dostęp do odpowiednio przygotowanej sieci.

Kolejnym etapem było opracowanie układu Motor Shield, który umożliwia sterowanie:

czterema silnikami prądu stałego,

pięcioma serwomechanizmami.

W trakcie budowy finalnego łazika okazało się, że pięć serwomechanizmów to więcej, niż rzeczywiście potrzebujemy. Była to jednak cenna lekcja pokazująca, że założenia projektowe często zmieniają się dopiero po wykonaniu i przetestowaniu rzeczywistej konstrukcji.

Zasilanie i ładowanie akumulatorów

Jednym z najważniejszych elementów projektu było także opracowanie układu Solar Charger.

Układ odpowiada za ładowanie pakietu zbudowanego z akumulatorów 18650, które wybrałem jako źródło zasilania łazika. System kontroluje również poziom napięcia akumulatorów i zabezpiecza je przed nadmiernym rozładowaniem.

Gdy poziom napięcia spadnie poniżej ustalonej wartości, zasilanie odbiorników zostaje automatycznie odcięte. Ma to chronić ogniwa oraz zapobiegać ich trwałemu uszkodzeniu.

W przyszłości system ten ma również umożliwić ładowanie łazika w specjalnie przygotowanych stacjach znajdujących się na poligonie.

Konstrukcja łazika

Gdy elektronika osiągnęła odpowiedni poziom zaawansowania, rozpoczęliśmy projektowanie samego łazika.

Od początku założyliśmy, że jego konstrukcja będzie w dużej mierze wykonywana z elementów drukowanych na drukarce FDM. Dzięki temu poszczególne części będzie można stosunkowo łatwo modyfikować, poprawiać i ponownie drukować.

Pozwoli to również innym osobom na samodzielne wykonanie konstrukcji bez konieczności dostępu do specjalistycznego parku maszynowego.

Warto zaznaczyć, że projektu nie realizuję sam. W prace zaangażowanych jest kilka osób, a każda z nich odpowiada za inne zadania – od elektroniki i programowania, przez projektowanie mechaniczne, aż po przygotowanie koncepcji przyszłych misji oraz poligonu.

Co dalej?

Finalne testy obecnej wersji łazika planujemy przeprowadzić we wrześniu i październiku.

Jeżeli zakończą się pomyślnie, chciałbym udostępnić model łazika do pobrania. Dzięki temu zainteresowane osoby mogłyby samodzielnie wydrukować jego elementy, złożyć konstrukcję oraz rozwijać ją według własnych pomysłów.

 

 

 

 

Projekt w założeniu nie ma być zamkniętym, gotowym produktem, którego nie można modyfikować. Wręcz przeciwnie – chciałbym, aby łaziki były stale ulepszane.

Trochę tak, jak wyglądało to w przypadku pierwszych drukarek 3D. Użytkownicy budowali urządzenia, testowali je, wymieniali części, projektowali nowe rozwiązania i dzielili się efektami z innymi.

W tym przypadku kolejne modyfikacje pozwalałyby łazikom pokonywać coraz trudniejsze przeszkody i realizować bardziej zaawansowane misje.

Pytanie do społeczności Forbot

Chciałbym zapytać Was, czy bylibyście zainteresowani udziałem w takiej inicjatywie.

Założenie wyglądałoby następująco:

Użytkownik buduje we własnym domu swojego łazika, uczy się elektroniki, programowania i jego obsługi, a następnie – korzystając z czegoś w rodzaju „NASA–InPost” – wysyła gotowego robota na specjalnie przygotowany poligon.

 

Po umieszczeniu łazika na poligonie użytkownik może połączyć się z nim przez Internet i wykonywać zdalnie przygotowane misje.

Z czasem na poligonie pojawiałyby się nowe przeszkody, trasy i zadania. Wymuszałoby to dalsze rozwijanie konstrukcji – zmianę zawieszenia, napędu, kamer, czujników, chwytaków lub oprogramowania.

Czy Waszym zdaniem taka forma nauki robotyki, elektroniki i programowania byłaby interesująca?

Czy chcielibyście samodzielnie zbudować łazik, a następnie wysłać go na prawdziwy poligon i wykonywać nim zdalne misje?

Będę wdzięczny za wszystkie opinie, sugestie oraz uwagi techniczne. Projekt cały czas się rozwija, dlatego informacje od osób zajmujących się robotyką i projektami DIY mogą być dla nas bardzo wartościowe.

Jeżeli wpis w jakikolwiek sposób narusza regulamin forum, przepraszam i proszę administrację o informację. Zależy mi przede wszystkim na przedstawieniu projektu, poznaniu opinii społeczności oraz wymianie doświadczeń.

Edytowano 27 lipca przez adrianjanisze

[robotykLEGO]

niezłe było by udostępnienie poligonu dla innych użytkowników w celu testowania swoich autorskich konstrukcji.

[bjrk]

@adrianjanisze
To bardzo ciekawe i chętnie bym się dowiedział coś więcej o samym projekcie łazika, poza kilkoma zdjęciami. Coś więcej, ale bez nadmiernych szczegółów, a przykład o liczbie osi swobody poszczególnych elementów itp.
Mnie, udział w tym, skądinąd bardzo interesującym projekcie -  czy może raczej korzystanie z niego - interesowało by, tylko gdybym mógł:
- napisać własny program sterujący łazikiem.
- przesłać Ci go (zdanie wgrać?)
- potem obserwować efekty.

Oczywiście o ile było by mnie na taką zabawę stać.

Skoro sterowanie łazikiem to wi-fi, to umożliwienie użycia skryptów, które nim sterują nie powinno być problemem. Nie interesuje mnie zdalne sterowanie jak dronem z kamerą, ale skrypt który pozwoli na samodzielne działanie łazika, już tak.
Nie twierdzę, że potrafię go dobrze napisać, ale chciałbym sprawdzić, czy potrafię coś sensownego stworzyć, i za taką próbę jestem skłonny zapłacić. Tylko pytanie ile. Myślę, że takich chętnych mogło by się znaleźć więcej.

Pomysł wydaje mi się bardzo interesujący, ale teraz warto zaprezentować "model biznesowy".
Moim zdaniem, najlepiej na własnej stronie projektu, bo takie szczegóły (oferta) to już raczej nie na forum. Masz stronę projektu? Myślę, że warto go rozpropagować
A jeśli już pisanie i wgrywanie zdalne do robotów/łazików zostanie opanowane,  to - w przyszłości - może nie tylko do tych łazików, ale i dla innych modeli. 
Nie myślę o takim właśnie poligonie, ale chętnie bym zapłacił za możliwość przetestowania własnego kodu do robota, np balansującego, czy nawet samodzielnego czterokołowca, ale budowanie go, to raczej nie dla mnie. Choć może mnie to czeka.
Twoja wizja, ktoś buduje łazika w domu i przesyła go na poligon, sterując nim zdalnie, nie przekonuje mnie, wydaje mi się, że więcej frajdy po zbudowaniu robita będę miał wyprowadzając go na spacer do parku, choć jeszcze tego do końca nie przemyślałem. 
Poligon, moim zdaniem, ma sens dopiero wtedy gdy potrzebuję poligonu, gdy to co mam w pobliżu już nie wystarcza. Gdybyś na swoim poligonie zorganizował zawody, to co innego.
Zakup, dobrze opisanego zestawu do samodzielnej budowy to tak, nawet jeśli większość części trzeba wydrukować mógł by być interesujący, oczywiście kwestia ceny.
Pozostaje pytanie, jak to wszystko ustawić, aby Tobie się opłacało, a mnie (i mnie podobnych) było stać na taką zabawę.
Wiem, że piszę mocno chaotycznie, ale to tylko takie luźne uwagi.

Pozdrawiam i powodzenia.
        Bogusław
 

[adrianjanisze]

@bjrk  

Dziękuję za bardzo wartościową wiadomość i podzielenie się swoimi przemyśleniami. Takie uwagi są dla mnie szczególnie cenne, bo pomagają spojrzeć na projekt z perspektywy przyszłych użytkowników.

Odpowiadając na Twoje pierwsze pytanie – łazik w założeniu nie jest pojazdem zdalnie sterowanym jak klasyczny dron czy samochód RC. Cała zabawa polega na tym, że uczestnik kupuje zestaw elektroniki i napędów, samodzielnie składa łazika, drukuje pozostałe elementy na drukarce 3D, a następnie programuje go i rozwija jego możliwości.

Żeby jednak projekt był przyjemny i dostępny również dla osób mniej zaawansowanych, część funkcjonalności będzie gotowa od początku. Komunikacja z serwerem, transmisja obrazu, integracja z platformą ADEAS WEB OS czy obsługa infrastruktury poligonu to elementy, które dostarczamy jako gotowe rozwiązania. Dzięki temu każdy łazik będzie zgodny ze standardem wymaganym do pracy na poligonie, a uczestnicy będą mogli skupić się na własnych pomysłach i algorytmach.

Jeśli chodzi o elektronikę i oprogramowanie bazowe, około 90% rozwiązań mam już opracowanych. Najwięcej czasu zajęło stworzenie „serca” systemu – własnej platformy sprzętowej opartej na dwóch procesorach: ATmega oraz ESP, które odpowiadają za komunikację, sterowanie i współpracę z infrastrukturą projektu.

Pytasz również o możliwość pisania własnego oprogramowania. Jak najbardziej jest to możliwe i wręcz do tego zachęcam. Łazik programowany jest w Arduino IDE, a użytkownik może tworzyć własne algorytmy i rozwiązania. Jedynym wymaganiem będzie wykorzystanie naszej płytki komunikacyjnej odpowiedzialnej za integrację z platformą i poligonem. Reszta elektroniki oraz logiki działania może być w dużej mierze autorska.

Jeżeli chodzi o koszt wejścia w projekt, naszym celem jest zamknięcie ceny podstawowego łazika w przedziale 700–1000 zł.

Sam poligon jest natomiast dopiero ostatnim etapem całej przygody. Projekt opiera się na czterech filarach:

Buduj – składanie łazika, montaż elektroniki i pierwsze uruchomienie.

Testuj – nauka programowania i eksperymentowanie w domu, warsztacie czy na podwórku.

Dowódź – wysłanie łazika na poligon i realizacja misji w ramach przygotowanego scenariusza gry.

Rozwijaj – modernizacja konstrukcji, dodawanie nowych modułów, czujników i funkcji potrzebnych do kolejnych misji.

Docelowo chciałbym, aby był to projekt rozwijany przez lata, a nie jednorazowa zabawa na kilka dni. Poligon ma być zwieńczeniem całego procesu nauki, budowy i programowania, a jednocześnie miejscem, gdzie można sprawdzić własne pomysły w praktyce oraz rywalizować z innymi uczestnikami podczas przyszłych misji i zawodów.

Jeszcze raz dziękuję za komentarz i wszystkie sugestie. Kilka z poruszonych przez Ciebie kwestii, szczególnie dotyczących możliwości uruchamiania własnych algorytmów oraz przyszłych zawodów, pokrywa się z kierunkiem, w którym chcę rozwijać projekt.

[adrianjanisze]

16 godzin temu, robotykLEGO napisał:

niezłe było by udostępnienie poligonu dla innych użytkowników w celu testowania swoich autorskich konstrukcji.

Tak, jest to możliwe i docelowo chciałbym udostępnić poligon również dla osób rozwijających własne, autorskie konstrukcje.

Jedynym wymaganiem byłoby wykorzystanie naszego układu sterująco-komunikacyjnego, który odpowiada za połączenie robota z platformą oraz infrastrukturą poligonu. Dzięki temu możliwe byłoby monitorowanie urządzenia, realizacja misji i zachowanie kompatybilności z całym ekosystemem.

Poza tym użytkownik miałby pełną swobodę w projektowaniu swojej konstrukcji. Rodzaj napędu, czujniki, dodatkowa elektronika, mechanika czy algorytmy sterowania mogłyby być całkowicie autorskie. Chodzi o to, aby zapewnić wspólny standard komunikacji z poligonem, pozostawiając jednocześnie maksymalną swobodę w tworzeniu własnych rozwiązań.

[bjrk]

45 minut temu, adrianjanisze napisał:

Jedynym wymaganiem byłoby wykorzystanie naszego układu sterująco-komunikacyjnego, który odpowiada za połączenie robota z platformą oraz infrastrukturą poligonu. Dzięki temu możliwe byłoby monitorowanie urządzenia, realizacja misji i zachowanie kompatybilności z całym ekosystemem.

Napisz proszę coś więcej o tym układzie i platformie, bo to jest - tak jak do tej pory to widzę - zwornik całego przedsięwzięcia. Nie chodzi mi oczywiście o jego schemat. Bardziej o "protokół współpracy". Co przy jego pomocy można, a czego zdecydowanie nie i dlaczego. Powody w wielkim skrócie: decyzja projektowa, ograniczenia bieżącej implementacji, ograniczenia wytrzymałościowe ...
Napisałeś, że po-wi-fi. Ale to (moim zdaniem) oznacza, że nie potrzeba elektroniki, a tylko protokół współpracy. Jeśli robot ma adres IP i poligon ma adres IP to 
układ sterująco komunikacyjny sprowadza się do protokołu.

 

[adrianjanisze]

45 minut temu, bjrk napisał:

Napisz proszę coś więcej o tym układzie i platformie, bo to jest - tak jak do tej pory to widzę - zwornik całego przedsięwzięcia. Nie chodzi mi oczywiście o jego schemat. Bardziej o "protokół współpracy". Co przy jego pomocy można, a czego zdecydowanie nie i dlaczego. Powody w wielkim skrócie: decyzja projektowa, ograniczenia bieżącej implementacji, ograniczenia wytrzymałościowe ...
Napisałeś, że po-wi-fi. Ale to (moim zdaniem) oznacza, że nie potrzeba elektroniki, a tylko protokół współpracy. Jeśli robot ma adres IP i poligon ma adres IP to 
układ sterująco komunikacyjny sprowadza się do protokołu.

 

Faktycznie, w dużej mierze to właśnie ten element jest zwornikiem całego przedsięwzięcia.

Układ, o którym wspominam, rozwijamy od kilku lat pod nazwą ADEAS. Jest to nie tylko pojedyncza płytka, ale cały ekosystem składający się z układu głównego, modułów rozszerzeń oraz platformy ADEAS WEB OS. W projekcie Heveliusz wykorzystujemy rozwinięcie płytki ADEAS UNO, które nazwaliśmy ADEAS328P.

Płytka oparta jest na dwóch procesorach: ESP32-S3 oraz ATmega328P. ESP odpowiada za komunikację, bezpieczeństwo, integrację z platformą i obsługę protokołów, natomiast ATmega realizuje zadania związane ze sterowaniem i obsługą urządzeń użytkownika. Część komunikacyjna jest zaszyta w warstwie ESP i nie jest dostępna do modyfikacji. To świadoma decyzja projektowa wynikająca z potrzeby utrzymania zgodności wszystkich robotów z infrastrukturą poligonu.

Masz rację, że teoretycznie wystarczyłby sam protokół komunikacyjny. Problem pojawia się jednak w praktyce. Każdy użytkownik zastosowałby inną elektronikę, inne biblioteki, inne sposoby komunikacji i inne rozwiązania energetyczne. W efekcie więcej czasu poświęcalibyśmy na rozwiązywanie problemów integracyjnych niż na samą zabawę i rozwój konstrukcji. Nasza płytka eliminuje ten problem i zapewnia wspólny standard dla wszystkich robotów.

Dzięki zastosowaniu ADEAS użytkownik automatycznie uzyskuje dostęp do ADEAS WEB OS, gdzie może stworzyć własny kokpit sterowania, podgląd parametrów, kamer, map, telemetrii czy danych z czujników. To właśnie ta platforma odpowiada za komunikację robota z poligonem i użytkownikiem.

Drugim, równie ważnym aspektem jest energetyka. Trzeba pamiętać, że w założeniu użytkownik nie ma fizycznego dostępu do robota po wysłaniu go na poligon. Robot musi być w stanie działać samodzielnie przez bardzo długi czas. Można oczywiście zbudować konstrukcję opartą na Raspberry Pi lub innym komputerze jednopłytkowym, ale często oznacza to czas pracy liczony w godzinach lub dniach. My od początku projektujemy rozwiązanie z myślą o tygodniach, a docelowo nawet miesiącach działania.

Dlatego łazik korzysta również z własnego systemu zarządzania energią Solar Charger, współpracującego z panelami słonecznymi.

Układ nie tylko ładuje akumulatory, ale również prowadzi analitykę energetyczną — monitoruje produkcję energii, jej zużycie, stan akumulatorów i efektywność całego systemu. Rozwiązanie zostało już sprawdzone w praktyce w naszym komercyjnym projekcie APAM Smart UL.

W tym roku prowadziliśmy długoterminowe testy i efekt jest bardzo obiecujący — dopóki dostępne jest światło słoneczne, urządzenia utrzymują dodatni bilans energetyczny i mogą pracować praktycznie bezobsługowo.

Podsumowując, wymaganie zastosowania naszej płytki nie wynika z chęci ograniczania użytkowników, ale z trzech powodów:

Zapewnienia kompatybilności z poligonem i platformą ADEAS WEB OS.

Udostępnienia gotowej, sprawdzonej komunikacji i telemetrii.

Zapewnienia bardzo długiego czasu pracy dzięki zoptymalizowanemu zarządzaniu energią.

Poza tym użytkownik ma dużą swobodę. Własne algorytmy, własna mechanika, własne czujniki czy dodatkowe moduły są jak najbardziej mile widziane. Chcemy standaryzować tylko te elementy, które są niezbędne do współpracy z infrastrukturą poligonu.

Edytowano 7 sierpnia przez adrianjanisze

[bjrk]

@adrianjanisze 

51 minut temu, adrianjanisze napisał:

Masz rację, że teoretycznie wystarczyłby sam protokół komunikacyjny. Problem pojawia się jednak w praktyce. Każdy użytkownik zastosowałby inną elektronikę, inne biblioteki, inne sposoby komunikacji i inne rozwiązania energetyczne. W efekcie więcej czasu poświęcalibyśmy na rozwiązywanie problemów integracyjnych niż na samą zabawę i rozwój konstrukcji. Nasza płytka eliminuje ten problem i zapewnia wspólny standard dla wszystkich robotów.

Od tego jest protokół komunikacyjny aby to ujednolicić, a to co podajesz, różne biblioteki itp, to moim zdaniem zaleta a nie wada.

Czyli pozostaje pytanie o protokół komunikacyjny pomiędzy płytką  a użytkownikiem. 
- Co muszę podłączyć do płytki aby spełnić jej wymagania.
- Jak się z nią porozumiewam, o czym muszę ją informować, o czym ona informuje mnie.

Przeprowadźmy eksperyment myślowy.
Jest dany samodzielny robot. Jakie dodatkowe wymagania musi spełnić, aby wpisać się w wasz ekosystem.

[bjrk]

@adrianjanisze 
Chyba, że nie zrozumiałem jej roli, i jest ona kompletnym sterownikiem robota do którego trzeba podłączyć efektory.

[adrianjanisze]

17 minut temu, bjrk napisał:

@adrianjanisze 

Od tego jest protokół komunikacyjny aby to ujednolicić, a to co podajesz, różne biblioteki itp, to moim zdaniem zaleta a nie wada.

Czyli pozostaje pytanie o protokół komunikacyjny pomiędzy płytką  a użytkownikiem. 
- Co muszę podłączyć do płytki aby spełnić jej wymagania.
- Jak się z nią porozumiewam, o czym muszę ją informować, o czym ona informuje mnie.

Przeprowadźmy eksperyment myślowy.
Jest dany samodzielny robot. Jakie dodatkowe wymagania musi spełnić, aby wpisać się w wasz ekosystem.

Przeprowadzając Twój eksperyment myślowy:

Załóżmy, że masz już gotowego, samodzielnego robota zbudowanego całkowicie na własnej elektronice. Aby mógł działać na poligonie, musisz jedynie dodać do niego płytkę ADEAS328P, która pełni rolę bramy komunikacyjnej pomiędzy robotem, platformą ADEAS WEB OS i użytkownikiem.

Twój robot nadal może mieć własny procesor, własne czujniki, własne algorytmy i własne oprogramowanie. ADEAS328P nie musi przejmować sterowania robotem. Może działać wyłącznie jako interfejs komunikacyjny.

W najprostszym wariancie komunikujesz się z płytką przez I2C. Wysyłasz do niej dane, które chcesz prezentować na platformie, np.:

współrzędne GPS,

poziom baterii,

dane z czujników,

stany urządzeń,

komunikaty diagnostyczne,

wyniki działania własnych algorytmów.

Płytka odbiera te dane i publikuje je w ADEAS WEB OS, dzięki czemu możesz je obserwować z domu.

Wyjątkiem jest transmisja obrazu. Kamera jest obsługiwana bezpośrednio przez ADEAS328P, ponieważ znajduje się tam już gotowa komunikacja oparta o WebSockety oraz przygotowane widgety platformy. Dzięki temu nie trzeba rozwiązywać osobno problemów związanych ze strumieniowaniem obrazu.

Odpowiadając na pytanie „o czym muszę ją informować, a o czym ona informuje mnie?” — to w dużej mierze zależy od tego, jak chcesz jej używać.

Jeżeli traktujesz ADEAS328P wyłącznie jako moduł komunikacyjny, to Ty decydujesz, jakie dane wysyłasz do platformy. W takim przypadku płytka jest dla Twojego robota czymś w rodzaju modemu lub gatewaya.

Jeżeli natomiast uznasz, że wygodniej będzie wykorzystać ją również jako sterownik, możesz podłączyć do niej czujniki, serwa, silniki czy inne elementy wykonawcze i programować ją tak samo jak klasyczne Arduino. Wtedy część logiki robota może działać bezpośrednio na ADEAS328P.

Krótko mówiąc: w obecnej koncepcji nie chodzi o to, aby zastąpić elektronikę użytkownika, ale o to, aby zapewnić wspólny kanał komunikacji z poligonem i platformą. To, czy ADEAS328P będzie tylko „bramką komunikacyjną”, czy również głównym sterownikiem robota, pozostaje decyzją konstruktora.

[bjrk]

@adrianjanisze
Przyznaję, że zaczyna to wyglądać coraz bardziej interesująco. 
Napisz proszę, co można/warto podłączyć do tej płytki i co wtedy wiem o tym co podłączyłem, nie chodzi mi o to co ona przekaże do sieci, bo to z mojego punktu widzenia sygnał wysłany z Marsa na Ziemię (albo z innej galaktyki ;-} ) ale o to co może wiedzieć komputer leżący w robocie 2cm nad płytką.

[AntekBezak]

@adrianjanisze Mnie też temat zaciekawił. Skonstruowałem takiego robota, i powiedzmy teoretycznie, że chciałbym go przetestować na tym poligonie. Rozumiem, że byłaby mi do tego potrzebna ta wasza płytka, dlatego zastanawiam się czy możnaby kupić samą płytkę bez zestawu łazika i ile by wtedy kosztowała. Dodatkowo ciekawi mnie co jest przygotowane na tym poligonie. Sam mieszkam w okolicy gdzie mam ogromne obszary zróżnicowanego terenu do testów, więc ciekawi mnie czy na tym poligonie jest coś czego u siebie nie mam. Lokalizacja poligonu też jest nie bez znaczenia.

Poza tym chcę pogratulować naprawdę dobrego pomysłu.

[adrianjanisze]

14 minut temu, bjrk napisał:

@adrianjanisze
Przyznaję, że zaczyna to wyglądać coraz bardziej interesująco. 
Napisz proszę, co można/warto podłączyć do tej płytki i co wtedy wiem o tym co podłączyłem, nie chodzi mi o to co ona przekaże do sieci, bo to z mojego punktu widzenia sygnał wysłany z Marsa na Ziemię (albo z innej galaktyki ;-} ) ale o to co może wiedzieć komputer leżący w robocie 2cm nad płytką.

Nie do końca jestem pewien, czy dobrze zrozumiałem Twoje pytanie.

 „co może wiedzieć komputer leżący 2 cm nad płytką” 

 

Jeżeli skupimy się na podstawowej, referencyjnej wersji łazika, a nie na konstrukcjach całkowicie autorskich, to przewidujemy zastosowanie kilku kluczowych modułów:

Dwóch układów Solar Charger, które nie tylko odpowiadają za ładowanie akumulatorów z paneli słonecznych, ale również dostarczają informacji o stanie energetycznym systemu. Dzięki temu komputer pokładowy może znać poziom naładowania akumulatorów, aktualną produkcję energii z paneli, pobór mocy oraz bilans energetyczny całego pojazdu.

Modułu lokalizacji GPS RTK/UWB – obecnie jest on jeszcze w fazie projektowej, ale planujemy jego wdrożenie na początku przyszłego roku. Docelowo ma on dostarczać pozycję z dokładnością nawet do około 10 cm. Dzięki temu łazik będzie znał swoje położenie i mógł samodzielnie planować trasę przejazdu lub potwierdzać wykonanie zadań.

Motor Shielda, który odpowiada za sterowanie napędem. Pozwala on obsługiwać do czterech silników oraz czterech serwomechanizmów. Komunikacja odbywa się przez magistralę I2C, dzięki czemu komputer pokładowy może wydawać polecenia dotyczące kierunku jazdy, prędkości czy ustawienia elementów wykonawczych.

Podstawowych czujników środowiskowych, takich jak temperatura i wilgotność, które mogą być wykorzystywane zarówno do monitorowania warunków pracy łazika, jak i do realizacji przyszłych scenariuszy misji.

To w zasadzie stanowi bazę pierwszej wersji łazika.

Jeżeli chodzi o samą ideę misji, to inspiracją są w pewnym stopniu rzeczywiste misje planetarne. Początkowe zadania nie będą polegały wyłącznie na przejechaniu z punktu A do punktu B. Kluczowe będzie planowanie podróży, odkrywanie elementów rozmieszczonych na poligonie, wyznaczanie autonomicznych tras oraz zarządzanie energią.

Energia ma być jednym z najważniejszych zasobów w całej rozgrywce. W zależności od obranej trasy można dotrzeć do celu szybciej, ale kosztem większego zużycia energii lub przejazdu przez obszary o słabszym nasłonecznieniu. Można też wybrać drogę dłuższą, ale bezpieczniejszą pod względem energetycznym.

Dodatkowo za wykonanie określonych misji uczestnicy będą mogli korzystać z rozmieszczonych na poligonie magazynów energii, które pozwolą doładować łazika do pełna i kontynuować eksplorację.

Każda misja będzie weryfikowana na podstawie danych lokalizacyjnych oraz zdjęć wykonanych przez łazika i zapisanych w dzienniku misji. Po ukończeniu jednych zadań odblokowywane będą kolejne, coraz bardziej wymagające wyzwania.

 

 

 

 

 

[adrianjanisze]

36 minut temu, AntekBezak napisał:

@adrianjanisze Mnie też temat zaciekawił. Skonstruowałem takiego robota, i powiedzmy teoretycznie, że chciałbym go przetestować na tym poligonie. Rozumiem, że byłaby mi do tego potrzebna ta wasza płytka, dlatego zastanawiam się czy możnaby kupić samą płytkę bez zestawu łazika i ile by wtedy kosztowała. Dodatkowo ciekawi mnie co jest przygotowane na tym poligonie. Sam mieszkam w okolicy gdzie mam ogromne obszary zróżnicowanego terenu do testów, więc ciekawi mnie czy na tym poligonie jest coś czego u siebie nie mam. Lokalizacja poligonu też jest nie bez znaczenia.

Poza tym chcę pogratulować naprawdę dobrego pomysłu.

Jeżeli masz już własnego robota, to w takim przypadku faktycznie wystarczy sama płytka ADEAS328P jako element komunikacyjny. Nie ma potrzeby kupowania całego zestawu łazika. Jej zadaniem jest połączenie Twojej konstrukcji z platformą oraz infrastrukturą poligonu. Cena samej płytki w takim wariancie wynosiłaby około 120 zł.

Jeżeli chodzi o różnicę pomiędzy zwykłym terenem, który można znaleźć w swojej okolicy, a naszym poligonem, to największą wartością nie będzie sama powierzchnia czy ukształtowanie terenu, ale właśnie przygotowana infrastruktura.

Po pierwsze — komunikacja. Cały obszar poligonu będzie objęty stabilną siecią WiFi, dzięki czemu robot będzie mógł utrzymywać kontakt z platformą niezależnie od miejsca, w którym się znajduje.

Po drugie — precyzyjna lokalizacja. Chcemy przygotować system lokalizacyjny oparty o GPS RTK/UWB, który pozwoli określać pozycję robota z dokładnością około 10 cm. Dla porównania standardowy GPS w typowych warunkach daje dokładność rzędu kilku, a czasami nawet kilkunastu metrów. Taka precyzja pozwoli nie tylko obserwować trasę, ale również realizować autonomiczne zadania i nawigację.

Po trzecie — scenariusz i infrastruktura misji. Pierwszy etap poligonu będzie stosunkowo prosty: zróżnicowane ukształtowanie terenu (górki, doliny), punkty zadaniowe oraz magazyny energii, do których łazik będzie mógł się podłączyć i uzupełnić energię.

[Kogut007]

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.