Zdalnie sterowany robot ze sterownikiem FPGA

[FlyingDutch]

Cześć,

przeglądając sieć natrafiłem na stronę ze zdalnie sterowanym robotem, z kamerą i manipulatorem (4 DOF). Robot może być sterowany (poprzez WiFi) z urządzeń z OS IOS, Android lub PC.

Robot mi się spodobał, jeśli chciałbym zbudować własnego to byłaby to zbliżona konstrukcja. Zastanawiałem się jaki dział byłby odpowiedni dla tego postu, w końcu zdecydowałem, że umieszczę go w dziale "Układy programowalne". Otóż robot ten jest wyjątkowy (jak na konstrukcję amatorską) w tym sensie, że jego główny układ sterowania jest oparty na układzie FPGA.

Oto link do strony z opisem tego robota:

https://www.banggood.com/Xiao-R-DIY-FPGA-Wifi-Video-Control-Smart-Robot-Tank-Car-with-Camera-PTZ-p-1280920.html?rmmds=search&cur_warehouse=CN

Chciałem pokazać na tym przykładzie, że układy FPGA mają zastosowanie nie tylko w "nudnych" abstrakcyjnych projektach, ale że można je także wykorzystać do ciekawszych zadań. Komercyjne roboty bardzo często zawierają układy FPGA w ich kontrolerach (i to często kilka takich układów). Może ktoś z forumowiczów podejmie wyzwanie i sam zbuduje robota sterowanego układem FPGA 😉

Z tego co widać na stronie robot jest programowalny (czyli można zmieniać jego działanie) w IDE ISE Xilinxa (środowisko do syntezy FPGA Xilinxa) - czyli musi być z nim dostarczany kod w jednym z języków HDL do opisu sprzętu. Robot ma kilka trybów działania, także tryb z planowaniem trasy. Szkoda tylko, że cena tego robota jest dość zaporowa, bo analizując jego "program" można by się bardzo dużo nauczyć.

Pozdrawiam

[deshipu]

Cena to jest główny problem jaki mam z układami FPGA. O ile jeszcze jestem w stanie przełknąć te ceny dla budowy pojedynczych egzemplarzy na własny użytek (w sumie nie są dużo droższe niż mikrokontrolery były parę lat temu), o tyle zrobienie czegoś, co będzie ogólnie użyteczne i praktyczne jest już trudne, bo musiałoby być "warte" ceny takiego układu.

[FlyingDutch]

46 minut temu, deshipu napisał:

Cena to jest główny problem jaki mam z układami FPGA. O ile jeszcze jestem w stanie przełknąć te ceny dla budowy pojedynczych egzemplarzy na własny użytek (w sumie nie są dużo droższe niż mikrokontrolery były parę lat temu), o tyle zrobienie czegoś, co będzie ogólnie użyteczne i praktyczne jest już trudne, bo musiałoby być "warte" ceny takiego układu.

Cześć deshipu,

myślę, że to nie koszt układu FPGA zawyżył cenę (a przynajmniej nie tylko). Robot jest dość duży (chassis z blach ciętych laserowo),  bogato wyposażony, no i koszt napisania softu do sterowania na 3 OS (IOS, Android, Windows) też kosztuje. Policz jeszcze manipulator (serwa), transmisję wideo i wyjdzie sporo.

Robot nie jest dużo droższy od podobnych ze sterowaniem opartym na mikro-kontrolerze (w tym sklepie). Np. dla porównania (sterownik na ArduinoMega lub RPI):

https://www.banggood.com/Xiao-R-GFS-DIY-Wifi-Robot-Arm-Car-Metal-Chassis-Arduino2560-Board-with-Motor-Power-Board-p-1249958.html?rmmds=detail-bottom-alsobought__1&cur_warehouse=CN

Ogólnie robot z głównym sterownikiem na FPGA (jeśli dobrze się zaprojektuje układ FPGA) może mieć dużo lepsze czasy reakcji niż taki oparty na CPU (chociaż podejrzewam, że soft-CPU implementowane w FPGA może też być w  w nim użyte). Swoją drogą fajnie byłoby ujrzeć robota ze sterowaniem na FPGA zaprojektowanego przez któregoś z uczestników forum Forbot 😃

BTW: ale przynajmniej będzie na co odkładać kasę (no chyba, że robot szybciej zniknie z oferty tego sklepu).

Pozdrawiam

 

Edytowano Sierpień 26, 2018 przez FlyingDutch

[deshipu]

7 minut temu, FlyingDutch napisał:

Ogólnie robot z głównym sterownikiem na FPGA (jeśli dobrze się zaprojektuje układ FPGA) może mieć dużo lepsze czasy reakcji niż taki oparty na CPU (chociaż podejrzewam, że soft-CPU implementowane w FPGA może też być w  w nim użyte).

Ale o jakich różnicach w czasach reakcji my tu mówimy? Mikrosekundy? Przecież przy jakiejkolwiek mechanicznej konstrukcji to nie będzie mieć żadnego znaczenia. Do serwomechanizmów i tak wysyłasz sygnał z częstotliwością 50Hz. Nawet jeśli masz jakieś silniki krokowe czy inne własne wynalazki, to i tak nie poruszą się szybciej niż im pozwoli bezwładność.

Jasne, jak robisz coś z dźwiękiem (ktoś się zabierał może już za noise cancellation?), to może mieć to znaczenie. Ale przy robotach chyba nie aż tak duże.

[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

[FlyingDutch]

Dnia 26.08.2018 o 14:01, deshipu napisał:

Ale o jakich różnicach w czasach reakcji my tu mówimy? Mikrosekundy? Przecież przy jakiejkolwiek mechanicznej konstrukcji to nie będzie mieć żadnego znaczenia. Do serwomechanizmów i tak wysyłasz sygnał z częstotliwością 50Hz. Nawet jeśli masz jakieś silniki krokowe czy inne własne wynalazki, to i tak nie poruszą się szybciej niż im pozwoli bezwładność.

Cześć deshipu,

chodziło mi o fakt, że jeżeli robisz ileś rzeczy na jednym CPU: np. reagowanie na zdarzenia z czujników ultradźwiękowych, wyznaczanie pozycji , sterowanie silnikami, kodowanie i transmitowanie strumienia wideo z kamery, łączność po WiFi to nawet przy użyciu przerwań możesz mieć małe "przycięcia" (jeśli jakaś z tych operacji zajmie za dużo czasu procesora).

A na układzie FPGA, możesz te osobne "tory" przetwarzania odseparować (możesz zrobić je działające całkowicie równolegle sprzętowo - niezależnie od siebie). Nie mam doświadczenia w budowie robotów i pewnie masz całkowitą rację, że nie ma to żadnego znaczenia.

Pozdrawiam

 

Edytowano Sierpień 28, 2018 przez FlyingDutch

[deshipu]

Rozumiem co masz na myśli, ale nawet używając mikrokontrolerów też możesz sobie porozdzielać funkcje — ostatnio coraz częściej tak robię, bo łatwiej jest także debugować osobne systemy kiedy są całkowicie niezależne. Oczywiście taką FPGA masz w jednej kostce i możesz sobie te bramki kroić jak ci się podoba, a mikrokontrolery masz dane i musisz dobierać je do zadania, więc granularność większa, do tego każdy trzeba zasilić, podłączyć do jakiejś szyny komunikacyjnej, etc. — za to potem możesz mieć modułową budowę i z łatwością wymieniać/testować całe fragmenty. To jakby takie fizyczne mikroserwisy.