🚀 go-pugleaf

W dniu 2013-04-24 18:35, Vax pisze:
> W dniu 2013-04-23 14:56, bartekltg pisze:
>> Wykres prędkości od czasu będzie albo trójkątem,
>> albo trapezem, w zależności, czy uda się rozpędzić.
>> Uda się, jeśli droga jest prędkość graniczna jest mniejsza
>> niż sqrt (a*droga)
>
> Dopiero teraz sobie zerknąłem, a tu coś ciekawego :)
> Pierwsze moje spostrzeżenie:
> mamy do czynienia z "dyskretnymi krokami/ramkami" co jeżeli dobrze
> rozumiem, oznacza jakieś taktowanie.
> Założyłem, że w każdym takcie możemy przesłać sterownikowi wartość
> przyspieszenia (lub opóźnienia) co nie wynika jednoznacznie z pobieżnego
> opisu zadania ;)


Cały problem u fira pojawia się przez to, że chce on jednocześnie
zadać jednoznaczny ruch wieżyczki, oraz sterować prędkością
i puszczać swojego eulera.

To jest podejście bez sensu. Albo budujemy prawdziwy sterownik
do wieżyczki, który pobiera pozycje (a nawet prędkość) celu
i wysyła sygnał do sterowania 'silnikiem' (wszytko jedno, czy
to będzie prędkością, czy np mocą) a cześć programu odpowiedzialna
za fizykę to symuluje,

...albo zadajemy ruch na sztywno, wtedy nie ma sensu pytać się
o prędkość w danym momencie, jeszcze uwzględniając poprawkę na
niezbyt dokłądną symulację.
Mamy pozycję (kąt) w funkcji czasu i z niego korzystamy, tyle.
W każdej 'ramce symulacji' ustawiamy wczsniej analitycznie
policzoną pozycję - jesteśmy dokładniejsi, zrobiliśmy to prościej,
do tego spowoduje to mniejsze obciążenie dla komputera.


> I tu pojawią się przypadki gdy bez osiągania prędkości maksymalnej
> trzeba będzie rozstrzygnąć, czy mniej ramek wygeneruje trapez czy trójkąt.

Tak, ale rozróżnienie jest nietrudne.

Jeśli droga to S, a -przyszpieszenie, v - predkość maksymalna,
to prędkość v osiagniemy po czasie wynikającym z v=a*t,
przebywając wtedy drogę s = 0.5 at^2
s = 0.5 v^2/a
Jeśli ta droga jest większa niż połowa trasy:
0.5 v^2/a > S/2

to nie rozpędzimy się do końca. Połowę czasu/drogi się rozpędzamy,
połowę hamujemy.


Najwygodniej policzyć sobie charakterystyczne momenty,
jak zmiana przyszpieszenia, a pomiedzy nimi ruch jest albo
jednostajnie przyszpieszony/opozniony, albo jednostajny.
czyli mamy funkcje kwadratową lub liniową, + 2ify w każdej ramce.
NO, chyba, ze zbudujemy prawdziwy sterownik i fizykę.



> Np. dla przyspieszenia 2 stopnie na takt obrót o 3 stopnie można
> zrealizować w czterech taktach (trójkąt) lub tylko trzech taktach (trapez):
> 1. rozpędzanie 0 - 1.5 -> pokonany dystans 0.75
> 2. ruch jednostajny 1.5 -> pokonany dystans 1.5
> 3. hamowanie   1.5 - 0  -> pokonany dystans 0.75
> W dwóch się nie da, maksymalne rozpędzenie i hamowanie po jednym takcie
> da tylko 2 stopnie.
>
> Analogicznie dla tegoż przyspieszenia obrót o 7 stopni wymaga minimum 4
> kroków i owe 4 kroki realizujemy przebiegiem trójkątnym, "trapezowanie"
> wymagałoby minimum 5 kroków.

Nie przejmowałbym się tą dyskretyzacją, patrz pierwsze uwago.
To, czy mamy trapez powinno wynikać wyłącznie z tego, czy osiągnelismy
predkość maksymalną

>
> Celowo pomijam tu fikuśne łamane typu "trójkąt na trapezie", gdyż można
> dobrać przyspieszenie pośrednie, by uzyskać trójkąt o tym samym polu.

Da się udowodnić, że optymalne czasowo sterowanie będzie trapezem,
albo trójkątem, zaleznie od tego, czy uzyskamy maksymalną prędkość.


> Natomiast "intuicyjne" podejście do tematu nakazuje się rozpędzać "ile
> fabryka dała" kontrolując jedynie "czy dam radę się zatrzymać" i
> dopiero, gdy dalsze rozpędzanie (bądź utrzymywanie maksymalnej
> prędkości) grozi przestrzeleniem mety, rozpocząć kalkulację jak
> rozplanować hamowanie by utrafić w punkt w ostatnim takcie.
>
> Dodatkowym "smaczkiem" jest ogranicznik prędkości maksymalnej nie będący
> wielokrotnością przyspieszenia, więc mamy sytuację niesymetryczną, gdzie
> prędkość wzrasta liniowo 0,3,6,9,10 za to maleje w sposób: 10,7,4,1,0
> (zakładając hamowanie z maksymalnej, co nie musi być regułą) - cały czas
> pamiętamy o taktowaniu.

To nie jest problem dyskretny. Na razie wszytko jest liczbami
rzeczywistymi, wyliczamy na kartce odpowiedź, a potem implementujemy
double pozycja_wiezyczki(t);  //zwróc uwagę na typ:)


> Zabawy miałem na co najmniej 3 kwadranse - dziękuję za łamigłówkę :)

:-)


> Nie wiem tylko, czy "optymalizacja" bierze pod uwagę na to, w którym
> momencie taktu nastąpi wyhamowanie do zera i czy w takim przypadku
> (wcześniej niż koniec taktu) sterownik zatrzyma mechanizm, czy np.
> rozpocznie obrót w przeciwnym kierunku, ale to już niuanse ;)

pzdr
bartekltg