[Test/recenzja] Embedded Linux - test modułu MMnet1001

[Elvis]

W niniejszym artykule chciałbym przedstawić możliwość wykorzystania systemu linux do budowy robota.

Systemu Linux nie trzeba chyba nikomu przedstawiać. Liczne dystrybucje dostępne na komputery PC są łatwo dostępne i co ważne, darmowe. Obecnie coraz częściej linuxa można „spotkać” w urządzeniach nie przypominających komputera stacjonarnego. Warto wymienić chociażby telefony komórkowe, routery, czy nawigację (GPS). Od pewnego czasu można również kupić płytki ewaluacyjne wyposażone w procesor ARM9 oraz możliwość instalacji systemu linux.

W artykule opisany zostanie moduł mmnet1001, dostarczony do testów przez jego producenta - firmę Propox.

Na początek warto wymienić podstawowe parametry modułu:

• procesor AT91SAM9260 o częstotliwości pracy 210MHz

• 64MB pamięci RAM

• 1GB pamięci FLASH

• interfejs ethernet (RJ45)

• obsługa USB, również w trybie host

Parametry robią niemałe wrażenie. Bardziej przypominają parametry komputera, niż mikrokontroler. Warto od razu wspomnieć, że w ofercie firmy Propox dostępny jest bardzo podobny moduł mmnet1002

Parametry modułu są takie jak mmnet1001, jednak na płytce dodatkowo zainstalowano:

• 2 gniazda USB

• złącze RS232

• gniazdo kart micro-SD

• złącze mini-USB

• stabilizator 3,3V

Moduł MMnet1002 jest gotowy do działania od razu po wyjęciu z pudełka.

W ofercie firmy Propox znajdziemy również płytę ewaluacyjną EVBmm, do której możemy podłączyć moduł mmnet1001. Można również wykorzystać układy przygotowane samemu.

Aby uzyskać działający system musimy podłączyć co najmniej:

1) zasilanie 3,3V

2) konwerter RS232

Wykonujemy to według dostarczonej przez producenta instrukcji.

Na potrzeby testów, na PC zainstalowałem dystrybucję Ubuntu , wykorzystałem dostarczony w nim program obsługi RS232.

Moduł MMnet1001 dostarczany jest z preinstalowanym linuxem w dystrybucji OpenWRT.

Ustawiamy parametry transmisji (115200bps) i podłączamy zasilanie, w oknie terminala pojawiają się komunikaty uruchamianego systemu (obrazki są z putty pod Windows, więc jak widać też działa):

Po kilku chwilach system jest gotowy do pracy. Osoby znające obsługę systemu linux poczują się jak u siebie - terminal działa jak każdy inny w systemie linux. Podstawowe programy są dostarczone wraz z systemem, działają jak na PC.

Wraz z modułem otrzymujemy płytę CD z dość dużą liczbą gotowych do instalacji pakietów.

Producent modułu przygotował dla nas głównie pakiety związane z siecią - mamy tutaj serwer www, php, tftp i wiele innych. Instalacja pakietów jest bardzo prosta. System wyposażony jest w manager pakietów opkg. Przykład użycia opisany jest dokładniej w instrukcji modułu. Moduł jako serwer www:

Początkowo problemem może wydawać się przeniesienie danych z CD na moduł. Okazuje się to jednak bardzo łatwe. Wystarczy skopiować pliki na pendrive, a następnie podłączyć pendrive do naszego modułu. Musimy oczywiście najpierw podłączyć gniazdo USB płyty EVBmm do modułu mmnet1001. W przypadku mmnet1002, USB jest już na płycie. Obsługa pendrive, a nawet zewnętrznego dysku twardego (podłączanego przez USB) jest bardzo łatwa. Montujemy napęd i możemy z niego korzystać jak na zwykłym PC. Nie musimy sami pisać żadnego kodu (szczegóły w instrukcji).

Nasz moduł ma całkiem sporą pamięć flash (1GB). Dzięki temu możemy zainstalować niejeden pakiet i nadal mieć sporo wolnej pamięci. Jednak jeśli tyle pamięci okaże się niewystarczające, zawsze można wykorzystać pendrive, a nawet dysk twardy (tego nie polecam, pobiera strasznie dużo prądu).

Gdy mamy już zainstalowane pakiety, warto podłączyć moduł do internetu (albo chociaż do sieci lokalnej). Podłączamy kabel z wtyczką RJ45 i prawie gotowe. Prawie, bo trzeba jeszcze skonfigurować adres IP. Najłatwiej jest skonfigurować sieć lokalną, aby działał w niej serwer DHCP i przydzielał adresy w sieci 192.168.1.x. Moduł sam pobierze wtedy ustawienia naszej sieci. Można również na stałe ustawić adres modułu. Wymaga to edycji pliku /etc/config/network.

Sesja telnet (przez sieć lokalną), działa Midnight Commander:

Nie testowałem współpracy z kartami SD, jednak nie powinno być z tym problemu. Skoro pamięć USB działa bez problemu, SD powinno działać nawet lepiej. Jeśli ktoś chciałby wyposażyć moduł w obsługę sieci bezprzewodowej, wystarczy podłączyć odpowiednią kartę WiFi przez USB. Instrukcja obsługi opisuje jak to zrobić.

Moduł pozwala na łatwe zbudowanie własnego routera, a nawet serwera www. Jednak naszym celem jest weryfikacja jej przydatności do sterowania robotem. Najpierw musimy skompilować własny program. Producent modułu dostarcza SDK (czyli przede wszystkim kompilator). Co ciekawe odpowiednie pliki są na płycie CD, natomiast wersja dostępnie na stronie nie zawiera kompilatora.

Do kompilacji konieczne jest użycie systemu linux. O ile dotychczas mogliśmy pracować na systemie windows, teraz konieczna jest instalacja Linux-a na PC. Ja wybrałem Ubuntu, po zainstalowaniu systemu i doinstalowaniu wszystkich wymaganych modułów, kompilacja przykładowego programu odbyła się bez problemu. Większym problemem jest wgrywanie programu na moduł. Co prawda można wykorzystać pendrive, jednak jest to bardzo niewygodne. Producent opisuje w instrukcji wykorzystanie tftp do kopiowania plików na moduł. Jest to nieco wygodniejsze niż użycie pendrive-a, jednak nadal pisanie i testowanie programu jest znacznie wolniejsze niż na PC.

Warto przy okazji zobaczyć, jak pod linux-em sterujemy sprzętem. Jest to zupełnie inny sposób niż jesteśmy przyzwyczajeni na mikrokontrolerach (np. AVR). Dostęp do peryferiów odbywa się przez system plików! Aby zapalić lub zgasić diodę, zapisujemy do odpowiedniego pliku 0 lub 1. Nie musimy nawet pisać programu, można to zrobić z poziomu terminala.

Taka jest filozofia działania linux-a. Układy peryferyjne są widoczne jako pliki. Ma to wady i zalety. Obsługa RS232 jest bajecznie prosta - wystarczy zapisać/odczytać dane z odpowiedniego pliku. Podobnie i2c działa bezproblemowo.

Znacznie gorzej wygląda sytuacja, jeśli chcemy sterować za pomocą linii I/O. Co prawda jest to nadal bardzo proste (zapis do plików), jednak niezbyt szybkie. Postanowiłem sprawdzić, jak szybko moduł jest w stanie sterować linią I/O. Program, w pętli wystawiał 1 i 0 na wybraną linię I/O. Oscyloskop pokazał straszną prawdę - procesor pracujący z częstotliowścią 210MHz generuje sygnał o częstotliwości... 14kHz! To 1000 razy słabiej niż mały AVR.

Wniosek jest następujący - nie należy wykorzystywać linii I/O bezpośrednio. Jak więc sterować peryferiami? Możliwości są dwie:

1) możemy wykorzystać dodatkowy mikrokontroler, który będziemy sterować przez uart lub i2c

2) można napisać własny moduł jądra sterujący peryferiami

Pierwszy sposób jest chyba łatwiejszy, jednak w efekcie dostajemy układ z 2 procesorami, jeden sterujący peryferiami oraz drugi zajmujący się „logiką”. Drugi sposób jest przeznaczony dla zaawansowanych użytkowników linuxa, ponieważ pisanie modułów kernela nie jest łatwe. Jeśli jesteśmy przy kernelu, warto wspomnieć, że dostępne są gotowe moduły obsługujące np. pamięć eeprom (przez i2c), czy wyświetlacz LCD.

Linux dostarczony z modułem bazuje na dystrybucji OpenWRT. Projekt powstał, aby umożliwić wykorzystanie routerów do uruchamiania własnego systemu linux. Na płycie CD znajdziemy dystrybucję OpenWRT przygotowaną do współpracy z naszym modułem. Mamy oczywiście możliwość konfiguracji oraz przekompilowania kernela.

Jedyny problem to wersja OpenWRT. Obecnie dostępna jest nowsza wersja, jednak nie obsługuje ona bezpośrednio naszej płyty.

Jeśli nie chcemy pisać własnych modułów jądra, a chcemy zbudować robota najprościej jest wykorzystać dodatkowy procesor (np. AVR) do sterowania peryferiami. Moduł mmnet1001 pracuje tylko z napięciami 3.3V, więc trzeba o tym pamiętać wybierając odpowiedni procesor lub uwzględniając konwersję napięcia.

Co daje użycie mmnet1001? Przede wszystkim ogromną pamięć. Moduł może realizować bardzo skomplikowany algorytm sterowania, a jednocześnie zapisywać wszystkie parametry pracy układu. Jest jeszcze jedna ciekawa możliwość wykorzystania linuxa w robocie. Mi się niestety nie udało, ale gdyby poświęcić na to więcej czasu, do modułu można podłączyć po USB kamerę.

Otrzymalibyśmy wtedy robota, który nie tylko może przesyłać obraz (to otrzymamy za pomocą zwykłej kamery po IP), ale może też wykonywać pewną „analizę” obrazu. Można w ten sposób zbudować bardzo ciekawego światłoluba - który będzie szukał np. koloru czerwonego (albo blond 😉 ), dodatkowo obraz można wysyłać przez internet (wśród pakietów dostępny jest nawet gotowy program uvc_streamer). Miłośnikom line-followerów też mogłaby się przydać możliwość „widzenia” trasy przed robotem, a nie dopiero po najechaniu na linię.

Zalety modułu:

➕ moduł ma bardzo duże możliwości internetowe, pozwala na łatwe uruchomienie własnego serwera www, routera

➕ ogromna pamięć pozwala na zbudowanie np. zdalnego rejestratora, z możliwością odczytu, czy konfiguracji przez www

➕ obsługa USB w trybie host, wbudowana obsługa systemów plików, TCP/IP

➕ duża pamięć i moc obliczeniowa pozwala na budowę robota o bardzo rozbudowanym algorytmie działania

➕ podłączanie układów zewnętrznych (np. kart WiFi, kamer) daje dużo możliwości zastosowań

Wady modułu:

➖ wymaga zaawansowanej znajomości systemu linux

➖ poznanie go i wykorzystanie zajmuje dużo czasu

➖ do działania wymagane jest podłączenie zewnętrznego zasilania i gniazd (moduł mmnet1002 nie ma tej wady)

Moduł jest niemal idealnym rozwiązaniem dla osób szukających tematu do pracy dyplomowej.

Dziękujemy

firmie Propox za dostarczenie modułu do testów.

[TIMONek]

Na potrzeby testów zainstalowałem dystrybucję Ubuntu systemu Linux

Jak wygląda taka instalacja?

Miłośnikom line-followerów też mogłaby się przydać możliwość „widzenia” trasy przed robotem, a nie dopiero po najechaniu na linię.

Tak średnio to widzę. Można pewnie by osiągnąć przy dobrych lotach 25 klatek na sek, a trochę za mało, żeby poprawnie reagować przy wyższych prędkościach. Choć może jestem w błędzie 😉

[Elvis]

Ubuntu zainstalowałem oczywiście na PC. Na MMnet1001 działa OpenWRT.

Poprawiłem zdanie w artykule, mam nadzieję, że teraz będzie czytelniej.

Co do tych line-followerów, to oczywiście nie chodziło mi o poleganie tylko na obrazie z kamery. Raczej o zastosowaniu algorytmu z "przewidywaniem". Czyli zwykły line-follower z powiedzmy 5-8 czujnikami odbiciowymi + kamera, żeby z wyprzedzeniem "widzieć" zakręty. Nie mówię, że to będzie działać na 100%, ale wydaje mi się ciekawą koncepcją, a może tematem pracy dyplomowej.

[Zuk]

Witam.

Uważam, że układ dwu a nawet wieloprocesorowy jest doskonałym rozwiązaniem w przypadku bardzo wyrafinowanych zadań i skomplikowanych algorytmów.

Dobrym przykładem jest współpraca robotów w grupach i przykładowy projekt SwarmBot,
w którym każdy robot jest sterowany za pomocą układu wieloprocesorowego, w którym

jednostką nadrzędną jest procesor arm (o ile pamiętam pracujący pod linuxem)

natomiast małe procesorki AVR są jednostkami podrzędnymi kontrolującymi określone funkcje robota takie jak ruch kół, akwizycja danych z czujników, komunikacja z innymi robotami itd.

Wykorzystanie tego rozwiązania w prostych linefollowerach, gdzie istotnym jest czas reakcji napędów na informacje z czujników mija się z celem.

Wspomniana przez autora możliwość współpracy procesora z kamerą w linefollowerze nasuwa mi pomysł konstrukcji robota sterowanego za pomocą regulatora PID ale o zmiennych współczynnikach

obliczanych na podstawie krzywizny trajektorii przed robotem (dane z kamery).

Innym rozwiązaniem może być konstrukcja czujnika matrycowego nie złożonego z linijki 5 czujników

ale np 5x5 czujników wykrywających zmianę kierunku linii obsługiwana przez bardzo szybki procesor.

Odnośnie samego artykułu autor bardzo fajnie opisał same moduły. Trochę mało dokładnie ich obsługę, ale nie było jego intencją pisanie ich instrukcji obsługi.

Cenne jest porównanie szybkości działania układu I/O omawianego procesora z typowymi AVRkami

Uważam natomiast, że za mało napisał o możliwych zastosowaniach w robotyce, co sugeruje, zachęcające do przeczytania artykułu pierwsze zdanie.

Elvis Czy masz może zamiar rozszerzyć te informacje w artykule... ?

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[Elvis]

Artykuł miał niestety ustalony deadline - czas na który Propox udostępnił moduł. Jest jednak szansa na ciąg dalszy.

Jak chodzi o kamerkę i PID to dokładnie o coś takiego mi chodziło - AVR sterujący silnikami i wykorzystujący czujniki odbiciowe, a do tego kamerka+linux na potrzeby "przewidywania" tego, co jest przed robotem.

Opis jest nieco pobieżny głównie dlatego, że szczegóły są nieco zawiłe i mało ciekawe. Przykładowo instalacja i konfiguracja tftp, przydzielanie adresów IP itd.

Dopiero teraz dowiedziałem się, że Propox posiada już gotowe, skonfigurowane środowisko Linuxa. Jest to duży plus, sporo czasu można tak zaoszczędzić.

Jak chodzi o ciąg dalszy to planuję uruchomić LCD, karty SD oraz może kodek dźwięku.

Postaram się też podłączyć gotowego robota z AVR poprzez i2c lub uart.

[Wytry]

Witam!

Ile pozostawało wolnej pamięci RAM po starcie systemu?

Czy system posiada funkcje generowania sygnału PWM na wyjściach cyfrowych?

[zaquadnik]

Ja się nad jednym zastanawiam... po co aż taka "armata" do robota ? Przecież to się niebardzo nadaje. Po pierwsze, pobór prądu, o wiele większy niż standardowego uC, rekompensuje to co prawda moc obliczeniowa, ale nie wiem za bardzo do czego jej tu użyć. Po co robotowi np. serwer plików onboard ? Można powiedzieć, że wówczas da się komunikować z robotem przez Internet, ale znów, aby to miało sens, trzeba by zastosować WiFkę na USB, która żre sporo prądu, obsłużyć to, czyli komunikacja Sterownik WiFki <-> MCU <-> układy sterowania i czujników. Pomogło by to w przypadku naprawdę wyrafinowanej konstrukcji.

[Treker (Damian Szymański)]

Z tego co wiem w planach było przetestowania robota z kamerką - jednak było za mało czasu. Może Elvis zajmie się tym przy okazji drugiej części tego artykułu, ale tutaj to już trzeba się jego zapytać 😉

[Elvis]

Ostatnio z braku czasu testy musiałem odłożyć.

Jak chodzi o pierwsze pytanie, to u mnie jest jakieś 54MB wolnej pamięci RAM. Do tego 900MB Flash. Więc raczej sporo.

Dostęp do PWM jest przez rejestry, nie znalazłem gotowego modułu w linux-ie. Oczywiście taki moduł można samemu napisać.

Natomiast co do wykorzystania modułu do budowy robota, to na pewno nie jest to temat łatwy i dobry dla początkujących.

Natomiast, czy jest to za duża armata, można polemizować. Jest to na pewno mniejszy kaliber niż montowanie PC w robocie.

Pobór prądu jest całkiem znośny, silniki biorą i tak dużo więcej prądu.

A jeśli jesteśmy minimalistami, to po co w ogóle używać mikrokontrolerów? Większość opisywanych na forum robotów spokojnie poradziłaby sobie bez mikrokontrolera, nawet mostek H nie jest w pełni wykorzystywany.

Moim zdaniem chodzi o poznanie czegoś nowego, zdobycie doświadczenia. Nie tylko budowanie konstrukcji minimalistycznych.

[zaquadnik]

Zaraz tam minimalizm. Cortex-M3 to takie minimum ? Po prostu, dodatkowa warstwa OS na pewno spowalnia procesy decyzyjne i sprawia, że sterowanie staje się mniej efektywne. Chyba, że jest to porządny RTOS, którym OpenWRT nie jest.

[Elvis]

Cortex-M3 to ciekawa platforma.

Natomiast linux daje możliwości, których goły RTOS nie oferuje. Wszystko oczywiście można zrobić - linux to też program jak każdy inny. Chodzi raczej o nakład pracy.

Wczoraj się zmobilizowałem i uruchomiłem kamerkę. Przed końcem konkursu artykuł powinien powstać, więc sens wykorzystania linuxa w robocie będzie lepiej widać.

[zaquadnik]

Kamerka - to jest argument ! 😉

Jeśli takie "cuś" Cię interesuje to przyjrzyj się układzikom iMX31 z Freescale. Rdzeń ARM11 i m. in. sprzętowy koder MPEG-4 =]

[Elvis]

Zapraszam do lektury artykułu: https://www.forbot.pl/forum/topics20/linux-kamerka-robot-z-ukladem-wizyjnym-vt3984.htm#31622

Jest to niejako ciąg dalszy testu. Tym razem opis podłączenia kamerki.