Temat ustawiania parametrów i eksploracji możliwości połączenia WiFi modułu nodemcu Amica, który wykorzystuję jako „mózg” dla robota, miałem zaplanowany na nieco później. Przy okazji implementacji OTA Update zdecydowałem się zająć od razu również tą kwestią jak i pozostałymi tematami związanymi z komunikacją ze „światem zewnętrznym”.

W wyborze koncepcji bardzo pomógł mi kod znaleziony na githubie – tutaj.

Nie zdecydowałem się jednak tego kodu po prostu „zacytować”. Dużo tam bałaganu, a obsługa requestów mDNS skonstruowana jest tak, że praktycznie blokuje wykonywanie jakichkolwiek operacji w głównej pętli programu. W związku z tym napisałem w zasadzie całość od nowa, bazując jedynie częściowo na tym rozwiązaniu. Kluczowa była tu dla mnie koncepcja wykorzystania mDNS i zeroconf w sytuacji, gdy nie wiadomo czy robot jest podłączony do jakiejkolwiek sieci, a istnieje potrzeba ustawienia jego parametrów połączenia. Technologie mDNS i zeroconf opisałem w poprzednim poście.

Algorytm który zastosowałem jest stosunkowo prosty. Po podłączeniu zasilania następuje próba połączenia z siecią WiFi (układ pracuje w trybie stacji) używając danych autentykacyjnych sieci zapisanych w EEPROM-ie. Jeżeli ta próba się powiedzie, to po nawiązaniu połączenia z siecią, robot udostępnia serwer Web do komunikacji przez przeglądarkę oraz baaaaardzo prosty „web service” dla aplikacji (Celowo użyłem cudzysłowa. Z web service, w klasycznym rozumieniu tego pojęcia, nie ma on tak wiele wspólnego 🙂 ). Dodatkowo odpalany jest serwer UDP, który służyć będzie do sterowania robotem  z aplikacji.

Ponieważ potrzebuję rozgłaszać custom-owy broadcast mDNS (OTAUpdate domyślnie tworzy własny – _arduino._tcp.local – a ja chciałem własną nazwę), OTAUpdate nie realizuję w klasyczny sposób (nie mam dostępnego portu sieciowego w IDE). Aby zachować możliwość aktualizacji zdalnej, realizuję ją przez przeglądarkę z wykorzystaniem biblioteki ESP8266HTTPUpdateServer. W ten sposób, pod odpowiednim adresem w przeglądarce, mam dostępny prosty interfejs, który pozwala mi załadować zdalnie binarkę z programem.

Jeżeli próba połączenia z siecią (po uruchomieniu robota) w trybie stacji się nie powiedzie, (ponieważ dane autentykacyjne w EEPROM-ie nie są zapisane lub nie jest dostępna zdefiniowana tam sieć) moduł WiFi zostaje przełączony w tryb Access Point, a web server wyświetla prosty formularz, który prezentuje dostępne sieci WiFi oraz pozwala na  wprowadzenie ssid i hasła dla wybranej sieci. Wystarczy więc połączyć się z access point-em robota i otworzyć stronę. Po wprowadzeniu danych i zrestartowaniu robota – powinien się on połączyć z wybraną siecią.

 

Dodatkowo, w obsłudze requestów http, dodałem sobie możliwość odczytania samego adresu IP, informację o aktualnym trybie pracy układu (AP -STI), informację o aktualnie połączonej sieci oraz listę dostępnych sieci. Te informacje będę wykorzystywał, parsując je sobie, w aplikacji desktopowej i mobilnej.

Samo sterowanie z aplikacji realizowane jest przez serwer UDP, który zaimplementowałem. Wymyśliłem sobie na potrzeby tej komunikacji bardzo prosty protokół. Wydaje mi się, że jest na tyle elastyczny, że z łatwością będzie można go rozbudowywać w razie potrzeby.

Poniżej diagram, prezentujący ogólnie aktualny algorytm (kliknij diagram, aby powiększyć):

Chętnych do przejrzenia kodu zapraszam oczywiście na github.

Ponieważ udało mi się mocno podgonić temat parametryzacji i komunikacji ze „światem zewnętrznym”, zdecydowałem się pominąć etap testowania sterowania za pomocą komend wysyłanych na port szeregowy (emulowany przez USB). Kolejnym etapem pracy będzie przygotowanie desktopowej aplikacji (z wykorzystaniem WPF) do parametryzowania i ręcznego sterowania robotem oraz montaż samego robota.