Mechaniczny skaner 3D

[Szałszanin]

Cześć,

Projektuję mechaniczny skaner 3D, tj. 7 przegubowe ramię, którego zadaniem będzie podawanie pozycji (x, y, z) końca i kierunku ostatniego elementu ramienia. Niby temat nieskomplikowany, bo "wystarczy" w 7 obrotowych przegubów wbudować enkodery optyczne i policzyć zadanie proste kinematyki :-). Widziałem, że dostępne są enkodery bezpośrednio podające pozycję i pewnie byłyby do tego celu optymalne, ale nie są zbyt tanie… Stąd pomysł by wykorzystać enkodery optyczne inkrementalne.

Jak myślicie: Czy Arduino wystarczy by bez strat zliczać 7 enkoderów inkrementalnych? Czy raczej muszę zastosować Arduino (np. Mini) na każdy enkoder i potem jednostkę obliczeniową zbierająca informacje np. za pomocą RS-a? Zależy mi na dokładności określania położenia...

 

[daniel89]

Chyba lepiej do dokładnej pracy wykorzystać STM-a 32-bitowego . Taki 16-bitowy przetwornik ADC powinien sobie dać radę z dokładnością obliczeń.

W STM32F103 masz obsługę 3 enkoderów :

"Three 16-bit timers, each with up to 4
IC/OC/PWM or pulse counter and
quadrature (incremental) encoder input"

Jeśli potrzebujesz 7 to poszukaj innych chipów co mają Seven 16-bit timers ... Jeśli takich nie znajdziesz to może z dwóch STM-ów uda się to zrobić. Co do komunikacji to wiadomo że lepiej jak by to wszystko w jednym układzie siedziało, jeśli się nie uda w jednym to szukaj komunikacji która taką prędkość ogarnie w czasie rzeczywistym.

[marek1707]

Rozwiązania sprzętowe są eleganckie i szybkie i zaprzęgnięcie do tego 7 timerów na pewno zadziała bez obaw o prędkości impulsów. Kolega pytał jednak o Arduino i tej klasy procesorki. Moim zdaniem wszystko zależy od częstotliwości, czyli w tym przypadku od prędkości kątowych jakie chcesz nadzorować. Każdy enkoder to dwa wejścia kwadraturowe czyli mamsz ich tutaj 14. Wczytanie 14 bitów równolegle to chwila no a potem trzeba zrobić 7 identycznych (i trywialnych) automatów dekodujących zmiany stanu oraz modyfikujących liczniki programowe. Wydaje mi się, że 1ms na zrobienie tego wszystkiego spokojnie wystarczy a to oznacza, że możesz zapodawać do kilkuset zboczy sygnału na sekundę. Wiedząc jakie masz enkdery sam oceń czy to dużo czy mało.

Tak na marginesie mając łańcuch złożony z węzłów to nie spodziewałbym się jakiejś dokładności. Luzy na łożyskach, wiotka konstrukcja i masz kilka milimetrów (strefy martwej) na końcu czujnika. Myślałeś o tym? Bo bezluzowe łożyskowanie tego wszystkiego i megasztywność ramion to będą najtrudbniejsze zagadnienia z jakimi się zderzysz. Nie żadne tam enkodery. Naprawdę nie wystarczą Ci 2-3 przeguby plus pionowa oś obrotu u podstawy? Ile masz na to pieniędzy, bo to wydaje się bardzo drogie rozwiązanie, takie z gatunku przemysłowo-wyczynowych.

[Szałszanin]

Dzięki za podpowiedzi.

Tak mi się wydawało, że Arduino mogłoby dać radę, ale się pogubi przy szybszych ruchach. Tego wolałbym uniknąć. Spróbuję zatem zaprząc do pracy FPGA. Co prawda mam tylko Elberta i informacje z kursu, ale powinno wystarczyć. Dam znać o postępach prac...

Oczywiście marek1707 masz rację co do luzów, ale mam plan żeby ich nie było. Mam doświadczenie zawodowe z ramionami przegubowymi do laserów i tam luzów jest niewiele. Spróbuję się przymierzyć do podobnego rozwiązania.

[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 22.06.2019 o 09:03, Szałszanin napisał:

Dzięki za podpowiedzi.

Tak mi się wydawało, że Arduino mogłoby dać radę, ale się pogubi przy szybszych ruchach. Tego wolałbym uniknąć. Spróbuję zatem zaprząc do pracy FPGA. Co prawda mam tylko Elberta i informacje z kursu, ale powinno wystarczyć. Dam znać o postępach prac...

Cześć @Szałszanin,

bardzo ciekawe  to założenie użycia układu FPGA do opisanego celu.Jeśli opublikujesz jakieś wyniki z użyciem Elbert'a będę je śledził z dużym zainteresowaniem.

Powodzenia w projekcie i pozdrawiam 😉

[FlyingDutch]

Cześć,

tutaj masz kilka kilka przykładów kodu (Verilog/VHDL) dla dekoderów kwadraturowych realizowanych na układach FPGA:

https://www.fpga4fun.com/QuadratureDecoder.html

https://www.digikey.com/eewiki/pages/viewpage.action?pageId=62259228

https://github.com/AdriaanSwan/Verilog-Quadrature-Decoder-I2C-Slave

http://www.lothar-miller.de/s9y/categories/46-Encoder

https://opencores.org/projects/16_qam_qadm

http://hamsterworks.co.nz/mediawiki/index.php/Better_rotary_encoder_input

http://hamsterworks.co.nz/mediawiki/index.php/Pmodenc

Pozdrawiam

Edytowano Lipiec 6, 2019 przez FlyingDutch

[FlyingDutch]

Cześć,

znalazłem chwilę, aby trochę poeksperymentować z dekoderem dla "enkodera kwadraturowego" do silnika DC. próby przeprowadzałem z miniaturowym silnikiem DC firmy "DFRobot" z enkoderem (akurat taki model miałem pod ręką) - tutaj linki do tego silnika:

https://botland.com.pl/pl/silniki-dc-z-przekladnia-i-enkoderami/6288-silnik-katowy-z-przekladnia-sj02-1201-6v-160rpm-enkoder-.html

https://wiki.dfrobot.com/Micro_DC_Motor_with_Encoder-SJ02_SKU__FIT0458

Oprócz silnika z enkoderem kwadraturowym były jeszcze potrzebne:

1) Płytka FPGA Elbert v.2 (ta z kursu FPGA na Forbocie)

2) Konwerter poziomów logicznych (5V-3.3V).

Ja użyłem takiego konwertera poziomów:

https://botland.com.pl/pl/konwertery-napiec/2523-konwerter-poziomow-logicznych-dwukierunkowy-4-kanalowy-pololu.html

Wypróbowałem kod dekodera z tego linku:

https://www.fpga4fun.com/QuadratureDecoder.html

Jest to bardzo prosty do zrozumienia kod w Verilogu (moduł: quad). Na wyjściu mamy 8-mio bitowy licznik położenia wału silniczka. Uwaga: wyjściowa liczba binarna jest traktowana jako signed integer 8-bit  (ze znakiem). Znak rozróżnia kierunek obrotów wału. Zakres wartości licznika to: -128 do 127 należy pamiętać aby wartość licznika traktować jako integer ze znakiem.

Projekt zadziałał praktycznie "od pstryknięcia palcem" jedyne co trzba było zrobić to dodać plik ucf (constraint file dla Elberta). Tutaj kod modułu "quad":

`timescale 1ns / 1ps

module quad(clk, quadA, quadB, count);
input clk, quadA, quadB;
output [7:0] count;

reg [2:0] quadA_delayed, quadB_delayed;
always @(posedge clk) quadA_delayed <= {quadA_delayed[1:0], quadA};
always @(posedge clk) quadB_delayed <= {quadB_delayed[1:0], quadB};

wire count_enable = quadA_delayed[1] ^ quadA_delayed[2] ^ quadB_delayed[1] ^ quadB_delayed[2];
wire count_direction = quadA_delayed[1] ^ quadB_delayed[2];

reg [7:0] count;
always @(posedge clk)
begin
  if(count_enable)
  begin
    if(count_direction) count<=count+1; else count<=count-1;
  end
end

A tuta jplik user constraint (ucf) dla Elberta v.2:

NET "clk"      LOC = P129  | IOSTANDARD = LVCMOS33 | PERIOD = 12MHz;

NET "quadA"     LOC = P141  | IOSTANDARD = LVCMOS33;
NET "quadB"     LOC = P143  | IOSTANDARD = LVCMOS33;

// PINY ZGODNIE Z INSTRUKCJA DO PLYTKI (ODREBNY PIN DO KAZDEGO Z WYJSC)
NET "count<7>"  LOC = "P46"; //LED8
NET "count<5>"  LOC = "P47"; //LED7
NET "count<5>"  LOC = "P48"; //LED6
NET "count<4>"  LOC = "P49"; //LED5
NET "count<3>"  LOC = "P50"; //LED4
NET "count<2>"  LOC = "P51"; //LED3
NET "count<1>"  LOC = "P54"; //LED2
NET "count<0>"  LOC = "P55"; //LED1

W archiwum zip pełny (działający) projekt dla ISE 14.1 Xilinx'a

QuadMotorEncDekoder.zip

A tutaj zdjęcie działającego układu (wyjścia 8-mio bitowego licznika zostały podłączone do diod LED na płytce FPGA Elbert). gdy kręcę wałem licznika to wskazania licznika (LEDy) się zmieniają w pełnym jego zakresie.

jedyne co teraz musisz zrobić, to obudować moduł "quad" top modułem w którym utworzysz 7 instancji dekodera (moduł quad). Pewnie jeszcze będziesz musiał zrobić multiplekser np. 1 z 8 dla 7-miu ośmiobitowych wyjść liczników z dekoderów, bo zabraknie Ci pinów wyjściowych na płytce FPGA Elbert.

Czyli będziesz miał trzy bity adresowe dla multipleksera (na tych 3 bitach podajesz numer dekodera dla którego licznik wyjściowy chcesz odczytać), oreaz osiem bitów wyjściowych licznika pozycji (dla wybranego dekodera). Ponieważ te siedem instancji dekodera będzie pracowało całkowicie równolegle, powinieneś uzyskać duże prędkości dekodowania podłączonych enkoderów. Jeśli 8-bitów (ze znakiem), to dla Ciebie za mało po prostu zwiększ rozmiar licznika wyjściowego count.

Pozdrawiam

BTW: zapomniałem dodać, że jeden dekoder po implementacji zajmuje 12 LUT (z 1480 dostepnych w Spartan3A z Elberta), czyli tyle co nic 😉

A i tego też zapomniałem, trzeba by dodać przycisk reset dla zerowania liczników pozycji w dekoderach (ustalania pozycji początkowej manipulatora).. Jest to proste, może jutro zmodyfikuję kod.

Edytowano Lipiec 7, 2019 przez FlyingDutch

[FlyingDutch]

Dnia 20.06.2019 o 13:43, Szałszanin napisał:

Cześć,

Projektuję mechaniczny skaner 3D, tj. 7 przegubowe ramię, którego zadaniem będzie podawanie pozycji (x, y, z) końca i kierunku ostatniego elementu ramienia. Niby temat nieskomplikowany, bo "wystarczy" w 7 obrotowych przegubów wbudować enkodery optyczne i policzyć zadanie proste kinematyki :-).

Cześć @Szałszanin,

pytanie z czystej ciekawości: do czego chcesz użyć tego skanera?

Jeśli przeczytasz moje dalsze posty to zobaczysz, że zrobienie dekoderów dla enkoderów kwadraturowych jest proste. Jeśli podałbyś jak z wartości 7-miu liczników pozycji w dekoderach dla każdego przegubu obliczyć pozycję x,y,z ramienia, to może udałoby się całość sterowania zrobić na układzie FPGA (bez potrzeby zatrudniania mikro-kontrolera).

Jestem dość słaby z mechaniki - jeśli podałbyś jak obliczyć to zadanie proste kinematyki, to może udałoby się to policzyć w całości  na układzie FPGA 😉

Przejrzałem trochę teorii pod tym linkiem:

https://www.robotyka.com/teoria.php/teoria.75#

Jeśli byś podał macierze w notacji Denavita-Hartenberga dla twojego manipulatora to myślę, że całość udałoby się policzyć na układzie FPGA (bez użycia soft-procesora). Funkcje trygonometryczne można stablicować i policzyć korzystając z algorytmu CORDIC, a mnożenie macierzy wykonać na sprzętowych układach mnożących i blokach DSP z układu FPGA.

Pozdrawiam

Edytowano Lipiec 7, 2019 przez FlyingDutch

[FlyingDutch]

Cześć,

znalazłem kod w VHDL'u do mnożenia macierzy (32x32:  16-bit unsigned integer):

https://www.fpga4student.com/2016/11/matrix-multiplier-core-design.html

mógłby się przydać do policzenia pozycji (x,y,z) z liczników enkoderów dla przegubów w tym manipulatorze.

A tutaj kod w Verilogu do mnożenia macierzy o wymiarze 4 :

https://www.fpga4student.com/2016/12/fixed-point-matrix-multiplication-in-Verilog.html

Jest lepszy w tym sensie, że mnoży macierze o wymiarze 4 (a nie 32 jak w poprzednim przykładzie), a właśnie takie rozmiary są nam potrzebne,

aby obliczyć zadanie proste kinematyki dla tego manipulatora.

Pozdrawiam

Edytowano Lipiec 9, 2019 przez FlyingDutch

[FlyingDutch]

Cześć,

temat mnie zainteresował na tyle, że chciałbym wykonać taki manipulator, tylko z mniejsza liczbą stopni swobody, powiedzmy 3-4. Mógłby ktoś polecić taki tańszy manipulator z encoderami i napędami (np. jako kit do złożenia)? Tylko istotne, aby do niego ułożyć te równania macierzowe w notacji  Denavita-Hartenberga.

Według mnie taki manipulator można zaprojektować z wykorzystaniem układu FPGA jako sterownika (bez konieczności użycia mikro-kontrolera).

Będę wdzięczny za propozycje.

Pozdrawiam

[Szałszanin]

Cześć,

Widzę że temat Cię bardzo zainteresował 😀. Ja chwilowo na krótkim urlopie nad pięknym polskim morzem - woda +16 stopni ,powietrze + 14 stopni 😂 - stąd cisza z mojej strony. Poza tym ,czekam na enkodery z Chin (mają być w tym tygodniu) - wtedy będę mógł wreszcie poeksperymentować. 

Koncepcję mam bardzo podobną do zaprezentowanej na początku przez Ciebie. 7 bloków dekodera + wyjście 10-bitowe (enkodery 10-bit/obrót) adresowane trzema bitami, żeby wydobyć z Elberta stan 7 liczników.

Myślałem o zaadoptowaniu rozwiązania z https://www.digikey.com/eewiki/pages/viewpage.action?pageId=62259228 bo ma tłumienie drgań przy przełączaniu, a piszą że to ważne żeby nie zliczał dodatkowych tików.

Ale twój pomysł żeby Elbert policzył proste równanie kinematyki jest jeszcze lepszy. Po niedzieli wracam do prac i będę meldował o postępach.

Pozdrawiam.

 

[Szałszanin]

P.S. Mnożenie macierzy chyba nie będzie potrzebne bo przecież macierz transformacji dla danego ramienia wyznaczymy przed zaprogramowaniem Elberta i w układzie będzie trzeba tylko obliczyć bieżącą pozycję ze wzorów z macierzy transformacji. 

Za to będą potrzebne LUT dla sinusa i cosinusa dla 1000 pozycji enkodera i mnożenie zmienno-przecinkowych...

[FlyingDutch]

Cześć,

To tym lepiej, że mnożenie macierzy nie będzie potrzebne.

Cytat

Za to będą potrzebne LUT dla sinusa i cosinusa dla 1000 pozycji enkodera i mnożenie zmienno-przecinkowych...

Za pomocą algorytmu CORDIC można zmniejszyć tablice potrzebne do obliczania funkcji trygonometrycznych - patrz linki:

https://en.wikipedia.org/wiki/CORDIC

https://www.allaboutcircuits.com/technical-articles/an-introduction-to-the-cordic-algorithm/

Na układach FPGA nie da się łatwo liczyć działań dla liczb zmienno-przecinkowych - trzeba je zastąpić obliczeniami fixed-point.

Mógłbyś podać tą macierz transformacji dla twojego manipulatora?

Pozdrawiam

 

[FlyingDutch]

Cześć @Szałszanin,

czy mógłbyś podać link do enkoderów, które zamierzasz użyć w tym projekcie?

Pozdrawiam

[Szałszanin]

Cześć @FlyingDutch,

Enkodery, których zamierzam użyć to:

OMRON E6B2-CWZ6C
Rotary Encoder Incremental
1000 p/r
5-24Vdc

Mają tak jak typowe enkodery inkrementalne 6 wyprowadzeń: VCC, GND, OUT A, OUT B, OUT Z i COMMON.

Wyjście open kolektor NPN.

Widziałem że są też w Botlandzie:

https://botland.com.pl/pl/enkodery/13057-czujnik-obrotu-enkoder-omron-e6b2-cwz6c-1000-pr-5-24v.html

Producent: http://www.ia.omron.com/product/item/2449/

Pozdrawiam

e6b2-c (1).pdf

Edytowano Lipiec 15, 2019 przez Szałszanin