DMI Robot jest urządzeniem, które zostało zbudowane na potrzeby automatyzacji testów ekranów dotykowych. Dotychczas testy wykonywane były manualnie i polegały na aktywacji odpowiednich kontrolek pojawiających się na ekranie w danym momencie, zgodnie ze scenariuszem testowym. Zadaniem testera była odpowiednia reakcja na pojawiające się zdarzenia. Automatyzacja testów polegająca na wpięciu się między magistralę komunikacyjną systemu a wyświetlacz nie była możliwa, z powodu wymagań bezpieczeństwa. Działo się tak, ponieważ wyświetlacz jest urządzeniem końcowym, które informuje operatora o stanie pracy systemu. Dlatego przechwytywanie informacji bezpośrednio z magistrali, w tym przypadku, mogłoby spowodować, że test zostałby zaliczony, mimo np. uszkodzonego wyświetlacza. Urządzenie to symuluje zatem operatora wyświetlacza.
Pierwsza, prototypowa wersja DMI Robota wymagała ulepszeń, które przedstawione są już na poniższym wideo.
Modyfikacje prototypu
DMI Robot doczekał się drugiej wersji. Opisane poniżej zmiany, które zostały wprowadzone do pierwotnej wersji urządzenia, wynikają bezpośrednio z analizy pracy pierwszego prototypu.
Urządzenie stało się mniejsze, mimo zwiększonego obszaru roboczego. Zmieniliśmy położenie silników napędowych głowicy, które zostały umieszczone w korpusie robota z tyłu płyty głównej. Zmiana ta pozwoliła na łatwiejsze zarządzanie przestrzenią wokół robota.
Podobny zabieg zastosowaliśmy dla ramienia kamery. W pierwszej wersji prototypu ramię znajdowało się na zewnętrznej, bocznej ściance urządzenia. Aktualnie ramię kamery znajduje się w obrysie bryły urządzenia. Sposób wykonania oraz sterowania również uległ zmianie. Ramię porusza się liniowo tzn. w górę i dół za pomocą śruby trapezowej. Dla przypomnienia, w poprzedniej wersji prototypu ruch ramienia odbywał się po okręgu za pomocą serwomechanizmów. Zastosowanie śruby trapezowej zredukowało koszt oraz znacznie zwiększyło precyzję oraz powtarzalność położenia.
Głowica z rysikiem z racji pełnionej funkcji została również przeprojektowana. Zmniejszyliśmy jej rozmiar oraz wysunęliśmy rysik poza głowicę, poprawiając tym samym widoczność na ekranie z perspektywy kamery. Całkowicie odmiennie rozwiązaliśmy zasilanie głowicy. Podczas użytkowania pierwszego prototypu okazało się, że przewód zasilający jest dość problematyczny dla operatora, ponieważ w niektórych przypadkach zasłaniał widok. Odpowiednie prowadzenie przewodu zasilającego stanowiło wyzwanie ze względu na jego długość i dostępność w każdym położeniu głowicy. Aktualne rozwiązanie postanowiliśmy zrealizować, bazując na prętach pozycjonujących. To właśnie w nich przekazywane jest zasilanie do cewki rysika.
Urządzenie dodatkowo wzbogacone zostało o wyświetlacz LCD, który pełni funkcję informacyjną (np. wyświetla adres IP urządzenia).
Przeprojektowaniu uległ również sposób pracy z robotem. Urządzenie może być wykorzystywane przez system testowy podczas automatycznych testów oraz jako urządzenie do pracy manualnej. Wprowadziliśmy przejrzysty schemat pracy z urządzeniem. W tej chwili statusy pracy urządzenia są ustalone i sygnalizowane przez wbudowane oświetlenie LED. Przejścia pomiędzy kolejnymi stanami pracy są nadzorowane i ukierunkowane na bezpieczeństwo ludzi znajdujących się w bezpośrednim otoczeniu robota.
Elektronikę urządzenia przeprojektowaliśmy w taki sposób, aby ułatwić jego serwisowanie. W nowej wersji robota obwód drukowany został powiększony, a zaciski do podzespołów umieszczone na zewnętrznych stronach płytki. W przeciwieństwie do poprzedniej wersji obwodu, który był nakładką na Raspberry Pi 3, nowa płytka jest komponentem zamontowanym poza mikrokomputerem.
Wejścia oraz wyjścia zostały zmienione zgodnie z zapotrzebowaniem, m.in. wyeliminowaliśmy linie serwomechanizmu kamery, które zamieniliśmy na linie niezbędne do sterowania silnikiem krokowym i obsługę enkodera. Do istotnych zmian należy również modyfikacja sposobu sterowania cewką rysika. Zrealizowaliśmy je za pomocą sterowanego źródła prądowego, które w stanach ustalonych redukuje zakłócenia. Poprzednie rozwiązanie bazowało na sygnale PWM.
Dość nietypowym rozwiązaniem, które wprowadziliśmy, jest brak możliwości wyłączenia urządzenia w sposób programowy (wyłącznie przycisk mechaniczny). Funkcjonalność tę wyeliminowaliśmy ze względu na chęć zapewnienia większej dostępności urządzenia w fabrykach np. na wypadek zaniku zasilania lub przy przypadkowym wyłączeniu urządzenia (zdalnym lub fizycznym). Konsumpcja energii w czasie spoczynku nie zwiększyła się, ponieważ wszystkie urządzenia, które pobierają większą moc, są wyłączane. Jakakolwiek akcja, czy to ruch głowicy, czy podświetlenie, powoduje uruchomienie zasilacza.
Wprowadziliśmy również zmiany do obudowy elektroniki, która obecnie jest większa, ułożona poziomo z tyłu robota. Zmiany wymiarów wpłynęły pozytywnie na wentylację obudowy, obniżając temperaturę pracy. Dodatkowo zyskaliśmy więcej miejsca na prowadzenie przewodów.
Usprawnienia i modyfikacje wprowadziliśmy także w oprogramowaniu. W skład oprogramowania wchodzi firmware, znajdujący się na mikrokontrolerze na zaprojektowanym PCB, oraz część wysokopoziomowa uruchomiona na Raspberry Pi 3. Firmware zrealizowaliśmy za pomocą języka C z wykorzystaniem koncepcji bare metal. Program bazuje głównie na przerwaniach oraz sprzęcie takim jak np. timery do obsługi encoderów, PWM, I2C, itd. Dzięki poprzedniej wersji i przeprowadzonym testom, wyeliminowaliśmy zidentyfikowane błędy, dzięki czemu firmware jest stabilniejszy. Podczas prac nad oprogramowaniem sterownika robota, wprowadziliśmy dodatkowe funkcjonalności związane bezpośrednio z dodatkowym sprzętem, takim jak LCD czy podświetlenie RGB. Dodatkowo, udoskonaliliśmy algorytmy sterowania ruchem głowicy, detekcji kolizji oraz zarządzania energią, a ABI firmware’u wzbogaciło się o nowe funkcjonalności do obsługi wyżej wymienionych urządzeń. W związku z szeregiem wprowadzonych zmian, wersja najnowsza i prototypowa nie są ze sobą kompatybilne.
Oprogramowanie znajdujące się na mikrokomputerze Raspberry Pi 3 jest zrealizowane w większości przy użyciu języka programowania Python 3. Zastosowaliśmy architekturę typu klient-serwer, która umożliwiła nam stworzenie odrębnych modułów komunikujących się ze sobą za pomocą slotów. Takie rozwiązanie niesie ze sobą benefit związany z tworzeniem oprogramowania w sposób rozproszony. Inaczej mówiąc, poszczególne moduły aplikacji mogą być zrealizowane przy użyciu dowolnego języka programowania nawet jako samodzielne programy. Architektura ta okazała się pomocna w przypadku gotowych, dostępnych w repozytorium programów, które w oczywisty sposób nie mogły się komunikować z resztą aplikacji. Na ich potrzeby były tworzone wrappery, które tłumaczyły polecenia aplikacji na specyficzne parametry dla danego programu.
Aplikacja jest odpowiedzialna za zapewnienie komunikacji robota ze światem za pomocą połączenia TCP/IP przy pomocy protokołu ATP oraz za pomocą serwera webowego. Protokół ATP został zaprojektowany na potrzeby maszyn testujących przez klienta, w celu ujednolicenia kontroli na tego typu urządzeniach. Natomiast interfejs webowy służy do pracy manualnej, ale zdalnej. Oprócz wyżej wymienionych modyfikacji, aplikacja została wyposażona w tryby pracy takie jak: stan bezczynności, praca manualna, praca zdalna. Tryby te znacznie ułatwiają pracę z robotem, a ponadto informują osoby, które znajdują się w okolicy, w jakim trybie pracy jest urządzenie. Obecnie sygnalizacja odbywa się za pomocą kolorów podświetlenia.
Niespodziewane wyzwania
Największymi wyzwaniami, z którymi się zmierzyliśmy, a które na pierwszy rzut oka wydawały się banalne, było ramię kamery oraz przekazywanie prądu do głowicy za pomocą prętów pozycjonujących.
W przypadku ramienia kamery, trudnością było wykonanie mocowania o odpowiedniej sztywności. Nawet minimalne ruchy pojawiające się w uchwycie powodowały znaczne odchylenia na kamerze. Ruchy te były spowodowane niedoskonałościami wykorzystanych elementów. Wystarczyło lekkie wypaczenie śruby trapezowej, żeby podczas zmiany pozycji uchwytu zaobserwować ruch kamery na boki. Problem ten uczulił nas na nawet minimalne niedoskonałości komponentów. W wielu przypadkach nie przynoszą żadnych negatywnych efektów, ale w szczególnych rozwiązaniach mogą stanowić poważny problem.
Podobnie było z przekazywaniem prądu do głowicy. W teorii wystarczyło zastosować szczotki grafitowe, niestety rzeczywistość szybko to zweryfikowała. W celu poprawy styku i zwiększenia pewności działania, zastosowaliśmy dwukrotnie więcej szczotek niż początkowo zakładaliśmy. Mimo to, pierwsza próba okazała się nieudana. Po analizie problemu okazało się, że zastosowane szczotki grafitowe nie nadają się do tego z powodu zbyt dużych spadków napięcia. Kolejnym pomysłem, bardziej skutecznym było zastosowanie szczotek metalowych. Nie było to jednak rozwiązanie idealne, ponieważ po pewnym czasie następowała korozja materiału, która przyczyniła się do zwiększenia rezystancji. Robot co prawda klikał, ale siła nacisku z czasem słabła. Aktualnie pracujemy nad kolejnym rozwiązaniem dotyczącym szczotek, planujemy wykorzystanie grafitowych metalizowanych. Obecnie połączenie jest znacznie pewniejsze, a rezystancja porównywalna ze szczotkami metalowymi. Czas pokaże, jak to rozwiązanie się sprawdzi.
Jak widać, to co na etapie projektowania wydawało się zasadne, pewne i proste, w rzeczywistości okazało się znacznie trudniejsze. Trudność ta wynika z faktu, że zastosowane rozwiązania muszą być niezawodne przez długi okres, co powoduje, że rzeczy pozornie nieskomplikowane stają się nieraz złożonym wyzwaniem. Według nas na tym właśnie polega prototypowanie – poszukiwaniu rozwiązań przez wymyślanie i badanie różnych wariantów, aż do uzyskania zadawalających wyników.
Zostaw komentarz