Uniwersalny sterownik robota - RoboCORE

Cześć!
Chciałbym przedstawić projekt, który powstawał przez ostatnie 1,5 roku. Na początku wspomnę, że nie tworzyłem go sam – zaczynaliśmy projekt w 2 osoby. Ale o tym napiszę dalej. Najpierw opowiem o samym projekcie.

Pierwotne założenia
Celem było stworzenie uniwersalnego sterownika do robotyki. Wraz z kolegą dobrze nam szło budowanie wszelkich konstrukcji, ponieważ nasze kompetencje uzupełniały się; ja zajmowałem się sprzętem, a on oprogramowaniem. W pewnym momencie postanowiliśmy zrobić osobny projekt, czyli uniwersalne „serce” dla robotów.

1. Sterownik ma być kompatybilny z LEGO MINDSTORMS (NXT/EV3).
2. Ma obsługiwać nieco więcej silników i sensorów, niż NXT/EV3.
3. Ma mieć łączność z internetem, aby dało się sterować robotem z dowolnego miejsca na świecie.
4. Aby dało się nim zdalnie sterować, to musi mieć też kamerę.
5. Ma być kontrolowany przez system operacyjny czasu rzeczywistego, aby wszelkie algorytmy kontrolne mogły się wykonywać w czasie rzeczywistym.

Próbowaliśmy spełnić te założenia na wiele sposobów, podglądając równocześnie rozwiązania innych.
Pierwsza wersja sterownika o nazwie UGVC 0.8.0 (Unmanned Ground Vehicle Controller) i przykładowy robot wyglądały tak:


Ostateczny projekt bardzo różni się od pierwszego
Od razu wyjaśniam też, że pewnych szczegółów nie mogę podać, bo schemat elektryczny urządzenia jest na razie pod ochroną.

Opis konstrukcji – Hardware
Mózgiem sterownika jest 144-nóżkowy mikrokontroler STM32F4 z 1MB pamięci Flash i 196KB RAM. Wybraliśmy ten mikrokontroler z jednego powodu – nie znaleźliśmy na rynku innego mikrokontrolera, który miałby aż 6 sprzętowych interfejsów dla enkoderów kwadraturowych (dla niewtajemniczonych: Link). Poza tym jest to bardzo wydajny mikrokontroler z wieloma peryferiami, świetnie nadający się do automatyki i robotyki.

Sterownik w kolejnej wersji – UGVC 0.8.1:



Zasilanie
Cały sterownik w pierwszych prototypach miał zakres napięć zasilania od 6 do 10V, co ograniczało możliwości jego wykorzystania w konstrukcjach zasilanych napięciem 12V, ale wystarczało do zapewnienia kompatybilności z LEGO. Ograniczeniem były scalone mostki H – po prostu wtedy nie udało nam się znaleźć odpowiednio małych i dobrych. Układy na bipolarnych tranzystorach typu L293 odpadły z urzędu. W końcu znaleźliśmy odpowiednie mostki i w kolejnych prototypach zakres napięć zasilających obejmuje 12V (maksymalnie 14V).
Wejście sterownika ma 3 zabezpieczenia:
- nadprądowe (resetowalny bezpiecznik polimerowy),
- nadnapięciowe (odcina powyżej 14V),
- przed odwrotną polaryzacją.
Napięcie wejściowe bezpośrednio zasila mostki H oraz trafia na dodatkowe złącza rozszerzeń, dzięki czemu dodatkowe moduły mogą czerpać prąd z wydajnego źródła.
Dalej napięcie trafia na przetwornicę step-down 5V 2,5A. Stąd czerpane jest m.in. zasilanie portów USB. Część cyfrowa jest zasilana napięciem 3,3V, które uzyskujemy ze stabilizatora liniowego.

Sterownik w wersji 0.8.2:


Silniki
Jako drivery silników pracują scalone, podwójne mostki H o maksymalnym prądzie wyjściowym 1,3A (na jeden mostek) i napięciu zasilania 6-14V. Razem można podłączyć 6 silników z enkoderem lub bez. Alternatywnie można wykorzystać dwa mostki H do sterowania jednym silnikiem krokowym, czyli maksymalnie możemy użyć 3 silników krokowych. W każdym 6-pinowym złączu silnika są dwa wejścia dla enkoderów, wyjście mostka H i zasilanie 5V (dla enkoderów).

Sensory
Wejścia dla sensorów, podobnie jak porty silników, zostały zbudowane tak, aby były kompatybilne z sensorami LEGO. Każde złącze ma 6 pinów: GPIO/ADC/IRQ, GND, GND, +5V, GPIO1, GPIO2. Piny GPIO mają też sprzętowy interfejs UART lub I2C jako funkcję alternatywną.

Złącza – kompatybilność z LEGO
Jak pewnie wiedzą wszyscy użytkownicy zestawów LEGO MINDSTORMS, złącza użyte w tym zestawie są nietypowe. Są podobne do wtyków modularnych 6P6C (dla porównania - wtyki 6P2C używane są w telefonii stacjonarnej), ale mają niesymetrycznie umieszczony zatrzask:

Zdecydowaliśmy, że złącza w naszym sterowniku będą typowe, ponieważ łatwo zrobić kabelki, które na jednym końcu mają standardową wtyczkę 6P6C, a z drugiej kompatybilną z LEGO:

Jednocześnie, jeśli ktoś nie chce korzystać z podzespołów LEGO, to zaciskarki typowych wtyków 6P6C i same wtyki są łatwo dostępne.

Sterownik w wersji 0.9.0 (sterownik od tej wersji miał budowę kanapkową):


Kamera
Początkowo byliśmy skuszeni interfejsem DCMI, jaki posiada STM32F4 i pierwsze prototypy używały kamery MTD9D111, która na 8-bitowym wyjściu równoległym przekazywała ramki ciągłego obrazu w formacie JPEG. Doszliśmy jednak do wniosku, że kamera ta nie jest tania, jest mało popularna i nie ma też za bardzo alternatyw. Dlatego w najnowszej wersji postanowiliśmy podejść do tematu kamery w inny sposób.

Po pierwsze, większość smartfonów/tabletów posiada kamerę i Wi-Fi gratis. Dlaczego by tego nie wykorzystać? Owszem, są jeszcze droższe niż osobna kamera, ale za to często leżą nieużywane, bo wyszedł nowszy model itp. Podłączamy taki smartfon do naszego sterownika przez USB i za jednym zamachem załatwiamy łączność z internetem, widok z kamery i dodatkowo mamy wyświetlacz. Gdybyśmy próbowali te 3 rzeczy kupować oddzielnie to tak naprawdę wyszłoby jeszcze drożej.

Po drugie, do sterownika w wersji 0.9.5 można podłączyć moduł Intel Edison. Jest to coś podobnego do RaspberryPi, ale dużo mniejsze i nie ma wyprowadzonych żadnych złącz, ma tylko jeden 70-pinowy interfejs. Za to można do niego podłączyć kamerę na USB i wykorzystując pokładowego Linuxa przesyłać obraz za pośrednictwem wbudowanego Wi-Fi.

Po trzecie i ostatnie – możemy po prostu podłączyć RaspberryPi przez port USB.

W każdym z tych rozwiązań dodatkowe urządzenie realizuje funkcje komunikacyjne, a nasz sterownik realizuje całą automatykę w czasie rzeczywistym. Korzystając z modułu Intel Edison praktycznie nie zwiększają się rozmiary sterownika.

Wi-Fi
Zanim doszliśmy do wniosku, żeby modułu Wi-Fi w ogóle nie montować w wersji bazowej ze względu na inne możliwości, testowaliśmy dwa moduły Wi-Fi. Jeden z nich to moduł firmy Redpine Signals RS9110-N-11-02. Sprawował się bardzo dobrze, jednak jest to już przestarzały i drogi moduł. Potem trafiliśmy na Bluegiga WF121A – tańszy i nowocześniejszy. Pewnie byśmy przy nim pozostali, gdyby nie zmiana koncepcji. No to tyle o Wi-Fi

Sterownik w wersji 0.9.1:


PCB
Wszystkie obwody drukowane projektowałem w Eagle. Niestety, nie mogę udostępnić dokładnego schematu ani wzoru PCB, ale opiszę parę faktów.
Wszystkie prototypy zamawialiśmy w firmie Eurocircuits (www.eurocircuits.com). Bardzo polecam szczególnie ze względu na funkcję „PCB Visualizer” czyli podgląd gerberów online. Można też bezpośrednio załadować projekt z Eagle. I nie jest drożej niż w Polsce przy porównywalnej technologii. Jedyne, co wychodzi im moim zdaniem słabo, to warstwa opisowa. Jest trwała, ale odwzorowanie szczegółów słabe – lepiej wypadła pod tym względem firma Hatron z Krakowa, w której zamawialiśmy obwody do sterownika serwomechanizmów (moduł dodatkowy).
Obwód drukowany jest 4-warstwowy, z czego jedna warstwa to płaszczyzna masy. Najwęższe ścieżki mają 8 milsów, przelotki 0,3mm. Wszystkie prototypy do tej pory lutowane były ręcznie, ale najnowsza będzie przystosowana do montażu automatycznego.
Poniżej animacja przedstawiająca etapy projektowania PCB (jako ciekawostka) - trzeba kliknąć, miniaturka nie jest animowana.


Najnowsza wersja – 0.9.5
Podsumuję teraz wersja najnowsza co ma na pokładzie:
- 32-bitowy mikrokontroler STM32F4,
- 6 mostków H dla silników DC z enkoderami (kompatybilne z LEGO),
- 5 portów z interfejsami I2C, UART, ADC - do łączenia z sensorami (kompatybilne z LEGO),
- dwa uniwersalne złącza rozszerzeń hExt (zawierają 9x GPIO, ADC, SPI, I2C, UART),
- dwa złącza USB – host i device,
- slot na kartę microSD,
- port CAN,
- złącze SWD do debuggowania,
- złącze dla modułu Intel Edison (więcej informacji: http://www.intel.pl/content/www/pl/pl/do-it-yourself/edison.html ).

Łączność z naszą chmurą może być realizowana na przynajmniej 3 sposoby:
- za pośrednictwem smartfona/tabletu, który łączy się ze sterownikiem przez port USB – wtedy gratis mamy też kamerę i wyświetlacz,
- z wykorzystaniem modułu Intel Edison – dzięki temu mamy na pokładzie komputer z Linuxem, Wi-Fi, Bluetooth i dodatkowym portem USB,
- za pośrednictwem dowolnego komputera jednopłytkowego, np. RaspberryPi (podłączany kablem USB).

A tak wygląda najnowszy prototyp (RoboCORE 0.9.5):


Software
Od samego początku biblioteki do niskopoziomowej obsługi peryferiów pisane są w C oraz C++. Wykorzystaliśmy system operacyjny czasu rzeczywistego FreeRTOS, który zapewnia realizację algorytmów sterujących w ścisłych ramach czasowych. Największe wyzwania w czasie rozwoju oprogramowania:
1. Obsługa kamery MJPEG z interfejsem DCMI i przesyłanie obrazu do modułu Wi-Fi w czasie rzeczywistym z wykorzystaniem DMA. Udało się osiągnąć kilkanaście klatek na sekundę i wyświetlać je w oknie przeglądarki:

2. Napisanie bibliotek do obsługi dwóch modułów Wi-Fi, przy czym ostatecznie i tak z nich zrezygnowaliśmy. Wspomnę tutaj o problemie z modułem Bluegiga WF121, który niby ma interfejsy SPI oraz UART. Na początku planowaliśmy korzystać z SPI, po czym okazało się, że działa zbyt wolno i czasem coś gubi po drodze. Potem użyliśmy UART-a z wykorzystaniem linii RTS/CTS i działało to dużo lepiej, ale wymagało przeprojektowania PCB i przemapowania wyprowadzeń procesora w inny sposób (a piny mieliśmy wszystkie wykorzystane).
3. Oprogramowanie robotów demonstracyjnych, w tym dwóch robotów balansujących. Roboty mogłyby być tematem na osobny projekt, ale nie chcę tu mieszać.
4. Stworzenie prostych w użyciu bibliotek w C++. Poniżej przykład kodu, który wystarcza do oprogramowania najprostszego robota do teleobecności* :


* - Robot do teleobecności (telepresence) jest to w najprostszej wersji Skype na kółkach. Cała idea telepresence opiera się o wykorzystania zdobyczy technologii do stworzenia wrażenia zdalnej obecności człowieka, począwszy od możliwości poruszania się robotem z kamerą i wyświetlaczem w dowolnym miejscu na ziemi, skończywszy na możliwościach ingerencji w otoczenie i jak najlepsze odwzorowanie „funkcji” i zmysłów człowieka.

Podsumowanie
Teraz parę słów wyjaśnienia dlaczego nie mogę udostępnić schematów. Projekt zaczynaliśmy tworzyć zupełnie prywatnie, ale w międzyczasie udało nam się zainteresować nim inwestora, a po pewnym okresie dalszego rozwoju projekt pokazaliśmy na Kickstarterze:
https://www.kickstarter.com/projects/1992634922/robocore-the-heart-of-your-personal-robot
O ile kod do naszego robotycznego frameworku na mikrokontroler STM32 będzie otwarty (po zakończonej sukcesem kampanii na Kickstarterze), to jeszcze nie wiemy czy i w jakim stopniu projekt będzie „open hardware” – na razie nie jest.

Prośba do moderatorów:
Nie traktujcie tego jak reklamę. Co prawda jednym z celów tego tematu jest to, aby dotarł do większej liczby osób i liczymy na to, że ktoś może nas dodatkowo wesprzeć. W zamian jednak pokazuję przykład pokazujący drogę od hobbystycznego projektu do próby jego skomercjalizowania. Dodatkowo część zdjęć i informacji, które tu podałem, nie była jeszcze nigdzie publikowana.

Prawdę mówiąc, chciałbym w przyszłości ujrzeć na Elektrodzie (i nie tylko) więcej tego typu tematów, bo wierzę, że są na swój sposób wartościowe. Dla mnie myśl o tym, że inni rodacy też próbują i będą próbować skomercjalizować swoje pomysły i projekty (również hardware-owe) jest optymistyczna .