Moduł WiFi do robota z SAM v71

[Leniwy]

Buduję płytkę do robota w oparciu o Atmel SAM v71

Dość rozbudowana płytka jednak sam robot także jest już dużym projektem

Szukam modułu wifi do jego kontroli

Wykorzystywane będzie sterowanie w czasie rzeczywistym z poziomu laptopa z linuxem z zainstalowaną dedykowaną aplikacją w Qt

Nigdy tego nie robiłem jednak mam doświadczenie w sterowaniu robotami poprzez bluetooth i aplikacje z androidem, nie jest to mój pierwszy studencki projekt robota

 

Natknąłem się na taką płytkę:

https://kamami.pl/13375-atmel-xplain

można do niej teoretycznie coś dołożyć w postaci modułu wifi jednak nie znalazłem gotowego rozwiązania

Jakimi modułami do takiego zastosowania warto się zainteresować?

Czy dedykowane do tego modułu na złączy xplained ATWINC3400-XPRO lub ATWINC1500 będą dobre czy może jakieś customowe rozwiązanie?

Znalazłem taki moduł:

https://www.sparkfun.com/products/retired/10004

 

Czy ktoś spotkał się z gotowym przykładem np. migania diodą z aplikacji w Qt sterującej płytką po wifi? Jak ugryźć temat komunikacji? Robiłem do tej porty tylko komunikacje po bluetooth

 

[H1M4W4R1]

Uhm... a nie możesz postawić serwera REST na ESP32 (lub 8266) i komunikować się po jakiejś magistrali typu SPI / UART z MCU? Nawet komercyjne drukarki 3D często to robią w ten sposób... 

[Leniwy]

@H1M4W4R1 Celem jest sterowanie robotem w czasie rzeczywistym a sam moduł wifi to tylko jeden z komponentów

Tutaj bardziej pytam jak się takie rzeczy robi i jak zrealizować to bez odkrywania koła na nowo

 

Pomysł 1:

-nasłuchiwanie na portach czy wysyła się pakietty po UDP i wtedy dzieje się jakaś akcja

Pomysł 2:

-otworzyć "port" szeregowy podobnie jak w przypadku bluetooth i wypisywać tam komendy

Pomysł 3:

-wystawić jakieś endpoint oddzielnie do każdego urządzenia np. silniki oddzielnie, czujniki oddzielnie i sprawdzać co się dzieje w czujnikach co jakiś czas i tutaj bez RTOS się nie obejdzie

 

Pomysły / propozycje na to jak zrobić MVP gdzie kręcą się dwa silniki przód / tył jednocześnie aby można było rozbudowywać płytkę?

[H1M4W4R1]

1. UDP jest dość "unreliable" w mojej opinii. Przy projektowaniu gier wykorzystuje się je góra do przekazywania położenia postaci czy animacji, które są przesyłane kilkanaście razy na sekundę. Do maszyny, która może Cię zabić przez brak odebrania pakietu wolałbym raczej użyć TCP.
2. Patrz punkt 1. - TCP, bo to do tego samego się sprowadza (konkretniej do Telnet'u)
3. Czyli komunikacja po HTTP / REST. Wbrew pozorom HTTP jest bardzo stabilnym protokołem do komunikacji między urządzeniami, a zarazem łatwym w implementacji.

10 godzin temu, Leniwy napisał:

Pomysły / propozycje na to jak zrobić MVP gdzie kręcą się dwa silniki przód / tył jednocześnie aby można było rozbudowywać płytkę?

Na MVP osobiście bym poszedł w opcję TCP (Telnet) np. https://github.com/LennartHennigs/ESPTelnet oraz jakiś system bazowany na komendach GCode albo czymś na wzór.