Generator trajektorii / planer ruchu - parametry ramp

Witam,

skrobie sobie cos tam w temacie generatora trajektorii - na poczatek potrzebuje planera ruchu i zastanawiam sie nad sensowna / optymalna metoda generowania ramp.
jako parametr pojedynczego segmentu ruchu zalozylem pozycje do osiagniecia, czas rozpedzania, czas hamowania oraz predkosc zadana. Jezeli chodzi o fragmentu ruchu ze stala predkoscia nie ma problemu - wyliczona ilosc impulsow podawana z okreslona czestotliwoscia (silnik krokowy) - czestotliwosc z timera. Co jednak z przyspieszaniem? Policzyc parametry krzywej i w czasie rozpedzania co pare krokow przeladowywac rejestr timera z wartoscia do ktorej zlicza? Czy optymalniejsze bedzie przygotowanie tablicy z wartosciami tego rejestru i przeladowywanie go co pare krokow czy tez moze wyliczyc tylko jakies wspolczynniki wstepnie (np. ze co 5 krokow trzeba zwiekszyc rejestr timera o 10). Ma ktos za soba podobna aplikacje i podzielilby sie praktycznymi radami? Calosc tworze tylko na potrzeby hobbystyczne i dla satysfakcji ze potrafie

realizacja tego na podstawie ilosci krokow silnika nie ma sensu. Musisz liczyc sie z czyms takim jak gubienie krokow, a to bedzie powodowac ze wszelkie wyliczenia ida w krzaki. Jak juz to dane trzeba brac z jakiegos innego czujnika...

jak wspomnialem - calosc robie hobbystycznie i dla satysfakcji - silnik nie bedzie napedzal niczego wiec w zwiazku z brakiem obciazenia kroki nie powinny byc gubione. Poza tym wlasnie sens stosowania krokowca jest taki zeby zrezygnowac z petli sprzezenia zwrotnego.
W kazdym razie po napisaniu posta zdecydowalem sie na rozwiazanie gdzie co co iles tam krokow zwiekszam predkosc o pewien znany wspolczynnik - uniknalem tablicowania i zuzycia pamieci.
Ale pytanie o praktycznie wskazowki aplikacyjne podtrzymuje

Po pierwsze polecam ściągnąć źródła EMC2 i przejrzeć źródła od planowania ruchu.

Teraz pominę aspekt generowania impulsów ale skupię się na planowaniu. Najprościej to zrobić na ruchu jednostajnie przyspieszonym/opóźnionym. Tak jak się słusznie domyśliłeś możesz zrobić przerwanie cykliczne przykładowo 1ms i prędkość zwiększasz w tym przerwaniu i 1/1000 wartości przyspieszenia. I teraz najważniejsze. Cały ruch można oprzeć na jednym warunku: liczenie drogi hamowania z obecnej prędkości do zera i sprawdzanie czy ta droga nie jest dłuższa niż zadany odcinek. Nie będę gotowych wzorów podawał bo raz że nie mogę a dwa to że nie ma sensu zabierania frajdy z uruchomienia tych algorytmów.

Cytat:

realizacja tego na podstawie ilosci krokow silnika nie ma sensu. Musisz liczyc sie z czyms takim jak gubienie krokow, a to bedzie powodowac ze wszelkie wyliczenia ida w krzaki. Jak juz to dane trzeba brac z jakiegos innego czujnika...

Plannerowi nic do tego czy driver silników będzie gubił kroki. Co nie zmienia faktu że o ile parametry przyspieszenia i maks prędkości są dobrane optymalnie dla danego silnika krokowego to nie ma co się martwić o gubienie kroków. Choć osobiście jestem gorącym zwolennikiem silników ze sprzężeniem enkoderowym.

Generalnie mozna, ale przykladowo bez enkodera nie ma szans uzyskania sensownej dynamiki Ale jak to ma byc taki sobie test to ok

A zajrzyj tu:
http://www.google.pl/url?sa=t&rct=j&q=avr446%...sg=AFQjCNHMw5d4BFHc33s-oaowHpBPR61c1g&cad=rja
P.S.
Kod na stronie Atmela też jest- ale jeszcze nie ogladałem.

1. Nie wiem skąd pomysły, że silniki krokowe będą NA PEWNO gubić kroki... No jak się im zada prędkość/przyspieszenie których nie są w stanie osiągnąć z danym obciążeniem to na pewno, ale generalnie nic nie będzie gubione - sprawdzone na bardzo precyzyjnej aplikacji (silnik krokowy z przekładnią 70:1).

2. Ja to zrobiłem tak, że w ogóle nie ma fazy ruchu jednostajnego - silnik przez pół drogi rozpędza się, a potem przez pół hamuje - obliczenia są bardzo proste.

3. Zmiana nastaw timera następuje w przerwaniu od innego timera co 1ms.

4. Obliczenia są buforowane, tzn. że w każdej chwili są gotowe ustawienia timera do załadowania "od razu".

4\/3!!

Jak to nie ma fazy ruchu jednostajnego?
Przecież nie może się przez godzinę rozpędzać bo osiągnie jakieś kosmiczne obroty.
Tzn.- osiągnął by gdyby to było fizycznie wykonalne.

Ale dlaczego zakładasz, że przyspieszenie musi być stałe? Przyspieszenie wyliczasz do każdego "ruchu" osobno, tak żeby się zgadzało. Wykres prędkości nie jest trapezem, tylko trójkątem. Przy okazji i tak masz mniejsze przyspieszenie niż przy trapezie, więc dużo mniejsza szansa na gubienie kroków. Nie wiem w ogóle po co komu trajektoria typu trapez w ruchu który jest z góry ustalony...

4\/3!!

Dzieki za praktyczne porady
Freddie - odnosnie Twoich porad:

3. Przeladowanie timera rozumiem robisz przy hego doliczeniu? w jego przerwaniu? zeby uniknac sytuacji gdy zmiejszasz mu wartosc do jakiej ma doliczyc juz po jej przekroczeniu - musialby wtedy liczyc az do przekrecenia? Kwestia generowania impulsow - chwile juz na STM32 nie pisalem i nie wiem czy dobrze kojarze ze timer ma swoj pin na ktorym generuje impuls na czas jednego taktu zegara po doliczeniu?
4. obliczenia calosciowo przed rozpoczeciem ruchu?

Freddie Chopin napisał:

2. Ja to zrobiłem tak, że w ogóle nie ma fazy ruchu jednostajnego - silnik przez pół drogi rozpędza się, a potem przez pół hamuje - obliczenia są bardzo proste.

Przecież to nadal ruch jednostajny. Tylko że z mniejszym przyspieszeniem niż pozwala sprzęt.

Freddie Chopin napisał:

Nie wiem w ogóle po co komu trajektoria typu trapez w ruchu który jest z góry ustalony...

Jedziesz sobie autostradą 60km/h. Po co masz jechać 140 skorą jadąc 60 przejedziesz tą samą drogę?

No, rozumiem.
Ale tracisz czas.
W takim ploterze frezującym jak oszczędzisz 1min na programie to po 60 programach masz godzinę wolnego.

lukpep napisał:

3. Przeladowanie timera rozumiem robisz przy hego doliczeniu? w jego przerwaniu? zeby uniknac sytuacji gdy zmiejszasz mu wartosc do jakiej ma doliczyc juz po jej przekroczeniu - musialby wtedy liczyc az do przekrecenia? Kwestia generowania impulsow - chwile juz na STM32 nie pisalem i nie wiem czy dobrze kojarze ze timer ma swoj pin na ktorym generuje impuls na czas jednego taktu zegara po doliczeniu?

W STM32 możesz właczyć buforowanie ustawień timera, tak że on się sam przeładuje przy przekręceniu tym co mu wpisałeś do rejestrów.

lukpep napisał:

4. obliczenia calosciowo przed rozpoczeciem ruchu?

Nie, tylko że zawsze jest gotowe jedno "wyliczenie" - pakuję do timera jedno, od razu obliczam następne, żeby było gotowe za tą 1ms. Ale to już zależy od aplikacji - czasem lepiej tak, czasem lepiej inaczej.

nibbit napisał:

Przecież to nadal ruch jednostajny. Tylko że z mniejszym przyspieszeniem niż pozwala sprzęt.

Ruch jednostajny z małym przyspieszeniem?

nibbit napisał:

Jedziesz sobie autostradą 60km/h. Po co masz jechać 140 skorą jadąc 60 przejedziesz tą samą drogę?

Pudło. Po co mam się rozpędzać do setki w 2 sekundy i potem jechać tą setką przez minutę, żeby potem 2s hamować, skoro mogę przez 30 sekund rozpędzać się do jakiejśtam prędkości (nie chce mi się liczyć jakiej...) spokojnie i potem 30s hamować?

janbernat napisał:

Ale tracisz czas.
W takim ploterze frezującym jak oszczędzisz 1min na programie to po 60 programach masz godzinę wolnego.

Niczego nie tracę - w mojej aplikacji ruch był ustalony - zarówno to ile trzeba przejechać jak i to w jakim czasie (i nie ma być szybciej, tylko dokładnie tyle).

4\/3!!

No jak czas był ustalony to nie ma sprawy.
Normalnie optymalizuje się czas- czyli maksymalne dopuszczalne przyspieszenie/ hamowanie.
A w górnej części wykresu stała prędkość.
A nibbit pewnie chciał napisać "ruch jednostajnie przyspieszony".
Co też takie oczywiste nie jest jeśli chce się zminimalizować czas.

Freddie Chopin napisał:

Ruch jednostajny z małym przyspieszeniem?

Czy gdy a=const ma znaczenie wartość a?
EDIT:
tak miałem na myśli jednostajnie przyspieszony ;> sry za błąd

Freddie Chopin napisał:

Pudło. Po co mam się rozpędzać do setki w 2 sekundy i potem jechać tą setką przez minutę, żeby potem 2s hamować, skoro mogę przez 30 sekund rozpędzać się do jakiejśtam prędkości (nie chce mi się liczyć jakiej...) spokojnie i potem 30s hamować?

Pudło. Masz z góry błędne założenia. Dlaczego zakładasz że ten ruch masz wykonać w jakimś czasie? Mnie ogranicza przyspieszenie i prędkość maksymalna - wtedy przejadę dany odcinek w najmniejszym możliwym czasie. Tak jak janbernat powiedział, jeśli mamy ruchy przestawcze przykładowej maszyny to jest to wymierny czas pracy.
Ale z drugiej strony można oczywiście prędkość opierać na trójkącie co dla zastosowań hobbystycznych będzie jak najbardziej ok, ale będzie równocześnie nieoptymalne.

W każdym wypadku trzeba niestety mieć całą trajektorię ruchu obliczoną od początku do końca.

janbernat napisał:

W każdym wypadku trzeba niestety mieć całą trajektorię ruchu obliczoną od początku do końca.

Nieprawda. W podanej przeze mnie metodzie można zmieniać odległość w dowolnym momencie.

No jak to?
Możesz wyhamować dowolnie szybko?
Znieniasz długość drogi przy maksymalnej prędkości do zera.
No przecież się tak nie da- silnik krokowy się pogubi- zresztą każdy silnik.

janbernat napisał:

No jak to?
Możesz wyhamować dowolnie szybko?
Znieniasz długość drogi przy maksymalnej prędkości do zera.
No przecież się tak nie da- silnik krokowy się pogubi- zresztą każdy silnik.

Nie, ograniczam maksymalną prędkość tak by przy danym przyspieszeniu zdążyć zwolnić do zera w punkcie końcowym.

No ale w takim razie musisz znać położenie punktu końcowego trajektorii od poczatku.