Skocz do zawartości

Szałszanin

Użytkownicy
  • Zawartość

    11
  • Rejestracja

  • Ostatnio

Reputacja

11 Dobra

O Szałszanin

  • Ranga
    2/10

Informacje

  • Płeć
    Mężczyzna
  • Lokalizacja
    śląskie
  • Języki programowania
    C++, C#

Ostatnio na profilu byli

Blok z ostatnio odwiedzającymi jest wyłączony i nie jest wyświetlany innym użytkownikom.

  1. Włączę się jako pomysłodawca tematu Od pierwszego postu się zastanawiam czy lepiej procesor czy FPGA. Program na procesor mogę napisać w 2 godziny, ale czy obsługa 7 przerwań i do tego na bieżąco mnożenie 7 macierzy z sinusami i kosinusami bieżącej wartości liczników na pewno nie zajmie zbyt dużo czasu? Przyznam, że nie policzyłem czasów przetwarzania dla takich operacji. Może i tak. Może w następnym etapie spróbuję i takiego podejścia (łatwiejsze do wykonania). Ponieważ jednak moim założeniem podstawowym jest nie gubić impulsów, intuicyjnie spodobał mi się pomysł FPGA, a do tego jest to co wspomniał @FlyingDutch - aspekt edukacyjny. Jeszcze nie umiem mnożyć macierzy ani używać LUT na FPGA. Ale już zaczynam rozumieć... Mimo powyższych uwag @InspektorGadzet, uważam że przetwarzanie równoległe jest w tym przypadku korzystniejsze i w takiej wersji będę kontynuował. Pozdrawiam.
  2. Witaj @FlyingDutch, Rozumiem, że programujemy tylko 0 … 90 stopni (0..249 z 1000 imp./obrót) bo reszta jest symetryczna, a tablicę cosinusa obchodzimy ze wzoru cos x = sin (90 - x). Kod dla dekodera dla jednego kanału (wg https://www.digikey.com/eewiki/pages/viewpage.action?pageId=62259228) : library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.NUMERIC_STD.ALL; entity quadrature_decoder is generic( PULSES_PER_ROUND : integer := 1000; DEBOUNCE_TIME : integer := 12000 --ilość cykli zegara wymagana do zarejestrowania nowej pozycji 1ms @ 12MHz ); port( clk : IN STD_LOGIC; in_a : IN STD_LOGIC; in_b : IN STD_LOGIC; position : BUFFER integer range 0 to 10 := 0 ); end quadrature_decoder; architecture logic of quadrature_decoder is signal a : STD_LOGIC_VECTOR(1 downto 0); signal a_prev : STD_LOGIC; signal b : STD_LOGIC_VECTOR(1 downto 0); signal b_prev : STD_LOGIC; signal debounce_counter : integer range 0 to debounce_time; begin process(clk) begin if(rising_edge(clk)) then --zsynchronizuj i odfiltruj wejścia a/b a <= a(0) & in_a; b <= b(0) & in_b; if(((a(0) xor a(1)) or (b(0) xor b(1))) = '1') then --wejście a lub b uległo zmianie - wyzeruj licznik debounce_counter <= 0; elsif(debounce_counter = DEBOUNCE_TIME) then --licznik filtra osiągnął założoną wartość, zaktualizuj a_prev i b_prev a_prev <= a(1); b_prev <= b(1); else --nie minął debounce_time - zwiększ licznik filtra debounce_counter <= debounce_counter + 1; end if; --określ kierunek i pozycję if(debounce_counter = DEBOUNCE_TIME --licznik filtra osiągnął założoną wartość i nowa wartość jest różna od porzedniej and ((a_prev xor a(1)) or (b_prev xor b(1))) = '1') then if((b_prev xor a(1)) = '1') then --zgodnie z kierunkiem zegara if(position < PULSES_PER_ROUND) then position <= position + 1; else position <= 0; end if; else --przeciwnie do kierunku zegara if(position > 0) then position <= position - 1; else position <= PULSES_PER_ROUND - 1; end if; end if; end if; end if; end process; end logic; Zamierzam nie wykorzystywać Out Z (znacznik pełnego obrotu). Pozdrawiam. P.S. Jeszcze nie testowany...
  3. W załączeniu odręczny schemat kinematyki ramienia i macierze dla poszczególnych przekształceń. Jak się gdzieś nie pomyliłem Policzyłem też macierz transformacji... Fragment - macierz translacji wygląda tak : X: (((((c1 * c2 - s1 * s2) * c3) * c4 + ((c1 * c2 - s1 * s2) * s3) * s4) * c5 + (((c1 * s2 + s1 * c2) * -1) * -1) * s5) * s6 + ((((c1 * c2 + -s1 * s2) * c3) * -s4 + ((c1 * c2 + -s1 * s2) * s3) * c4)) * -c6) * H + (((((c1 * c2 + -s1 * s2) * c3) * c4 + ((c1 * c2 + -s1 * s2) * s3) * s4) * s5 + (((c1 * s2 + -s1 * -c2) * -1) * -1) * -c5) * G + ((((c1 * c2 + -s1 * s2) * c3) * -s4 + ((c1 * c2 + -s1 * s2) * s3) * c4) * F + (((c1 * s2 + -s1 * -c2) * -1) * E + ((c1 * c2 + -s1 * s2) * C * c3 + (c1 * s2 + -s1 * -c2) * D)))) Y: (((((s1 * c2 + c1 * s2) * c3) * c4 + ((s1 * c2 + c1 * s2) * s3) * s4) * c5 + (((s1 * s2 + c1 * -c2) * -1) * -1) * s5) * s6 + ((((s1 * c2 + c1 * s2) * c3) * -s4 + ((s1 * c2 + c1 * s2) * s3) * c4)) * -c6) * H + (((((s1 * c2 + c1 * s2) * c3) * c4 + ((s1 * c2 + c1 * s2) * s3) * s4) * s5 + (((s1 * s2 + c1 * -c2) * -1) * -1) * -c5) * G + ((((s1 * c2 + c1 * s2) * c3) * -s4 + ((s1 * c2 + c1 * s2) * s3) * c4) * F + (((s1 * s2 + c1 * -c2) * -1) * E + ((s1 * c2 + c1 * s2) * C * c3 + (s1 * s2 + c1 * -c2) * D)))) Z: (((s3 * c4 - c3 * s4) * c5) * s6 + ((- s3 * s4 - c3 * c4)) * -c6) * H + (((s3 * c4 - c3 * s4) * s5) * G + ((s3 * -s4 - c3 * c4) * F + ((C * s3 + (B + A))))) gdzie: c1 = cos teta1, s1 = sin teta1, itd. Na razie to tylko wynik mieszania wierszy i kolumn z mnożenia macierzy teraz trzeba by to po upraszczać, ale najpierw sprawdzę czy wzory zadziałają dla dwóch/trzech znanych pozycji. Macierzy obrotu (orientacji końcówki) na razie nie zamieszczam bo szkoda miejsca...
  4. 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
  5. 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...
  6. 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.
  7. 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.
  8. Ja bym podłączył 5V z przetwornicy do LEDów i do wejścia 5V Arduino. Wtedy omijasz stabilizator z płytki Arduino (który wymaga min. 7V) i masz jedno napięcie 5V w całym układzie. A tak być może masz jakiś konflikt wyjścia z dwóch różnych zasilaczy 5V. Czy miałeś połączone masy ze stablizatora i przetwornicy? Bo jak nie, to coś może się już nie podnieść... A może zadziałało zabezpieczenie termiczne przetwornicy?
  9. A nie jest problemem wielokrotne inicjowanie zmiennych fix, alt, data wewnątrz pętli while w funkcji Loop? Wydaje mi się, że arduino, za każdym razem przydzieli nową pamięć na te same zmienne i w końcu pamięć RAM Ci się kończy i pokazuje głupoty. Ja bym wyrzucił deklaracje zmiennych przed while….
  10. 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...
  11. Cześć, Udało mi się dziś powtórzyć wasz sukces i mój Elbert też wygenerował 3 pasy z białą ramką na 23" LCD-ku firmy LG. W pierwszym podejściu też bez białej linii ramki na liniach 0. Kombinowałem z czasami, przeliczałem, a na końcu wyszło, że wystarczy wcisnąć przycisk automatycznej korekty pozycji/skali monitora i ramka jest jak trzeba za wszystkich stron... :-). Da się ją wycentrować niezależnie czy czasu impulsów synchronizacji są nieco przesunięte w lewo lub w prawo. Pewnie więc u Elvisa też wystarczyło poprawić pozycję/skalowanie monitora. Pozdrawiam!
×
×
  • Utwórz nowe...