Jaki ma okres sygnał podawany na serwa?

[EasyPeasy_]

Moglibyście mi powiedzieć, bo do oscyloskopu na uczelni będę miał dostęp dopiero we wtorek.

Bo sytuacja wygląda tak, jak kiedyś pisałem: GPS powoduje regularne drżenie serwomechanizmu.

A więc w skrócie na sprzętowym Serialu Arduino mam moduł Bluetooth, GPS korzysta z Software Serial z uwagi na to, że obie z bibliotek wykorzystują przerwania w momencie wysyłania danych z GPS'a przez Bluetooth serwo przestaje dostawać PWM'a i opada, co wygląda jak drżenie.

Dlatego też zapragnąłem napisać własną bibliotekę właściwie w toku pracy wyszło po prostu, że to będzie prosta funkcja. Żeby dowiedzieć się jakie czasy ON są zdefiniowane dla poszczególnych kątów serwa skorzystałem z funkcji z biblioteki Servo.h -> readMicroseconds() zrobiłem for'a od 0 - 180 i otrzymałem czasy ON sygnału.

Następnie zrobiłem z tego wykres, co się okazało, czasy prezentowały się w praktycznie liniowo:

Potem wstawiłem linię trendu (liniową) żeby otrzymać postać funkcji, która wygląda tak: czas_ON=10.311173*kąt+543.50823 i praktycznie pokrywa się dokładnie z wykresem stworzonym z otrzymanych czasów:

I teraz cała biblioteka do serwa zawiera się w prostej funkcji postaci:

int timeServo(int angle){
 int time=543.50823+10.311173*angle;
 return time;
}

Oczywiście mógłbym zrobić tablicę intów i funkcja zwracała by czasy, które podałem, ale musiałbym mieć tablicę 181 intów i Arduino nie ma raczej tyle pamięci dynamicznej, żeby to pomieścić, poza tym ja mam tyle kodu do obsługi wszystkich modułów, że muszę ją bardzo oszczędzać.

A samo wysterowanie serwa będzie wyglądało po prostu tak, że w void loop() na końcu dam:

 
   time=timeServo(angle);
   digitalWrite(9,HIGH);
   delayMicroseconds(time);
   digitalWrite(9,LOW);
   delayMicroseconds(okres_sygnalu_PWM-time);

Jak widzicie przeszliśmy do sedna sprawy, czyli tego, że muszę jeszcze tylko wiedzieć jaki okres ma sygnał PWM podawany normalnie na serwa, czy ktoś z Was to wie?

[marek1707]

Pomiary, wykresy... To jest po prostu niewiarygodne jak lubisz robić głupią robotę. Pierwsza odpowiedź wyszukiwarki na hasło "Servo control":

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

[EasyPeasy_]

Pomiary, wykresy... To jest po prostu niewiarygodne jak lubisz robić głupią robotę.

O co Panu chodzi?

Chodzi Panu o to, że sam nie wyszukałem informacji o tym, że okres wynosi 20 ms ?

Czy, że jakoś mój sposób na sterowanie serwem jest błędny (jeśli tak gdzie), to te moje serwo w końcu steruje się tak, że zmienia się czas załączenia, a okres jest stały i wynosi 20 ms (a te czasy załączenia mam z readMicroseconds()), czy, że liczy się tylko puls_width, a okres jest zmienny -> bo ten link co mi Pan podał jest tak niejasny dla mnie, że nie wiem w końcu jak, i jeśli ta druga opcja jest poprawna to skąd mam wiedzieć dla jakiego kąta jaki jest puls_width i okres sygnału?

[marek1707]

Typowe serwo modelarskie ma gdzieś Twoje wyliczenia kątów. Czego na rysunku z Wiki nie rozumiesz? Pokazano tam okres powtarzania (czyli czas między początkami impulsów) 20ms i długość impulsu od 1 do 2ms.

"Modern RC servo position is not defined by the PWM duty cycle (i.e., ON vs OFF time) but only by the width of the pulse"

Mam Ci to przetłumaczyć na nasz?

"..the neutral position is always around 1.5 milliseconds (ms) pulse width"

Albo to?

Tak naprawdę producenci serwomechanizmów gwarantują jedynie to, że w okolicach impulsu 1.5ms serwo będzie stało mniej więcej w połowie swojego zakresu ruchów. I że odbierając dłuższe impulsy (do 2ms) będzie podążało w jedną a krótsze (do 1ms) - w drugą. Wszystko co wyślesz poza tym zakresem jest jazdą po bandzie. Tak, Arduino tak robi, nie pytaj mnie dlaczego. Nie są gwarantowane żadne konkretne kąty wychyleń w funkcji długości impulsu, no może poza tym, że raczej każde serwo będzie umiało się obrócić o ±60°. Nawet te 180° nie jest gwarantowane, choć nie zdarzyło mi się spotkać takiego, które by tyle nie umiało.

"Chodzi Panu o to, że sam nie wyszukałem informacji o tym, że okres wynosi 20 ms ?"

Tak, właśnie o to. Robisz pomiary jakbyś odkrywał Amerykę, pytasz o rzeczy które leżą na każdej stronie traktującej o serwach. Naprawdę łatwiej Ci napisać post na Forum niż wrzucić dwa słowa do Google'a?

A poza tym: Twój pomysł potwornie zamula procesor. Przecież co jeden obrót pętli będziesz zamrażał program na 20ms. Użyj wyjścia ze sprzętowym PWM i serwo będzie dostawało idealny sygnał praktycznie za darmo. Mając pod ręką bibliotekę servo (i parę innych podobnych) robienie generacji PWM na delay'ach to jeden z głupszych pomysłów o jakich słyszałem.

I jeszcze: zadałem sobie trud skopiowania tytułu tego wątku do wyszukiwarki. W ciągu ułamka sekundy (a więc szybciej niż Ty napisałeś pierwsze zdanie postu) dostałem tysiąc obrazków tłumaczących szczegóły sygnału PWM dla serwa i kilka fajnych artykułów robiących to samo słowami. Zero myślenia czy próba robienia czegoś szybko, zanim się okaże że to bez sensu? O to mi chodzi.

[EasyPeasy_]

Typowe serwo modelarskie ma gdzieś Twoje wyliczenia kątów. Czego na rysunku z Wiki nie rozumiesz? Pokazano tam okres powtarzania (czyli czas między początkami impulsów) 20ms i długość impulsu od 1 do 2ms.

"Modern RC servo position is not defined by the PWM duty cycle (i.e., ON vs OFF time) but only by the width of the pulse"

Mam Ci to przetłumaczyć na nasz?

"..the neutral position is always around 1.5 milliseconds (ms) pulse width"

Albo to?

Tego, że napisali, że niby typowe serwa mają okres sygnału 20 ms, a niby niektóre lub współczesne nie są sterowane na zasadzie zmiany wypełnenia tylko zmiany długości impulsu i okresu.

Tak naprawdę producenci serwomechanizmów gwarantują jedynie to, że w okolicach impulsu 1.5ms serwo będzie stało mniej więcej w połowie swojego zakresu ruchów. I że odbierając dłuższe impulsy (do 2ms) będzie podążało w jedną a krótsze (do 1ms) - w drugą. Wszystko co wyślesz poza tym zakresem jest jazdą po bandzie. Tak, Arduino tak robi, nie pytaj mnie dlaczego. Nie są gwarantowane żadne konkretne kąty wychyleń w funkcji długości impulsu, no może poza tym, że raczej każde serwo będzie umiało się obrócić o ±60°. Nawet te 180° nie jest gwarantowane, choć nie zdarzyło mi się spotkać takiego, które by tyle nie umiało.

To skąd poznać te dokładne czasy dla poszczególnych kątów z dokumentacji?

"Chodzi Panu o to, że sam nie wyszukałem informacji o tym, że okres wynosi 20 ms ?"

Tak, właśnie o to. Robisz pomiary jakbyś odkrywał Amerykę, pytasz o rzeczy które leżą na każdej stronie traktującej o serwach. Naprawdę łatwiej Ci napisać post na Forum niż wrzucić dwa słowa do Google'a?

Bo odkrywam I nie leżą każde rzeczy na każdej stronie. Zresztą jak sam Pan widzi niektóre informacje na stronach tylko wprawiają w zakłopotanie, a nie dostarczają jasnych informacji, np. to na angielskiej wiki i i tak czy siak musiałbym tu stworzyć temat, bo bym nie był pewny swego.

A poza tym: Twój pomysł potwornie zamula procesor. Przecież co jeden obrót pętli będziesz zamrażał program na 20ms. Użyj wyjścia ze sprzętowym PWM i serwo będzie dostawało idealny sygnał praktycznie za darmo. Mając pod ręką bibliotekę servo (i parę innych podobnych) robienie generacji PWM na delay'ach to jeden z głupszych pomysłów o jakich słyszałem.

Mój pomysł nie zadziała, ponieważ w ten sposób wygeneruje tylko sygnał PWM'a przez te chwili kiedy te instrukcje będą się wykonywały i jak dam jakiegokolwiek delay'a to przez ten delay serwa też nie będą miały sygnału, musiałbym w ogóle delaya nie dawać, a ze względu, że ja mam sporo kodu jeszcze filtr kalmana to zachowanie stałego czasu wykonywania się instrukcji jest trudne. Np. gdy nie dałem delaya w pętli to sam filtr kalmana do estymacji Pitch/Roll próbkował się sam niekontrolowany delayem z minimalnym czasem 60 ms.

Biblioteki servo nie mogę wykorzystać już mówiłem. A co ma Pan na myśli mówiąc sprzętowy PWM. Są jakieś piny w Arduino nie będące tylko programowym PWM'em tylko prawdziwym sprzetowym? Więc jak powinienem zrealizować ten PWM?

I jeszcze: zadałem sobie trud skopiowania tytułu tego wątku do wyszukiwarki. W ciągu ułamka sekundy (a więc szybciej niż Ty napisałeś pierwsze zdanie postu) dostałem tysiąc obrazków tłumaczących szczegóły sygnału PWM dla serwa i kilka fajnych artykułów robiących to samo słowami. Zero myślenia czy próba robienia czegoś szybko, zanim się okaże że to bez sensu? O to mi chodzi.

To nie bez sensu, bo jakby nie było dostałem czasy, które musiałbym i tak odkryć i mam funkcję, która określa te czasy.

[marek1707]

Bzdura, nie masz żadnej funkcji. Zrobiłeś reverse engeneering jakiejś funkcji bibliotecznej zamieniającej mityczne kąty na mikrosekundy impulsów. To nie ma odniesienia do jakiegokolwiek rzeczywistego serwa bo polega na pomyśle anonimowego programisty. W każdym konkretnym przypadku i tak musisz stroić to ręcznie do serwa, które posiadasz. Co więcej, używanie przez inżyniera w takich obliczeniach 8 cyfr znaczących jest po prostu śmieszne (dla mnie osobiście - kompromitujące). Żeby takie precyzje miały sens musiałbyś przewidywać orbity planetoid lub generować impulsy serwa z rozdzielczością 10 pikosekund. Bezmyślnie przepisując liczby z Excela otwarcie pokazujesz, jak bardzo nie czujesz tego co robisz. Aż przykro patrzeć.

"..współczesne nie są sterowane na zasadzie zmiany wypełnenia tylko zmiany długości impulsu i okresu"

No właśnie nie. Nie okresu. Tam napisali, że obecne serwa sterowane są wyłącznie długością impulsu. To tylko zrozumienie jednego prostego zdania..

"Biblioteki servo nie mogę wykorzystać już mówiłem"

To Ty mówiłeś a znając Twoje osiągnięcia w temacie, to stwierdzenie jest nic nie warte. Moim zdaniem wyciągasz błędne wnioski po prostu nie rozumiejąc działania swojego systemu.

"Mój pomysł nie zadziała.."

Założyłem milcząco, że jesteś na tyle rozsądny by timing reszty kodu dopasować do programowej generacji impulsu dla serwa. Przecież po coś tę propozycję napisałeś. Cóż, nie pierwszy raz pomyliłem się.

"Są jakieś piny w Arduino.."

Pierwsza odpowiedź wyszukiwarki na pytanie "arduino hardware pwm":

https://www.arduino.cc/en/Tutorial/SecretsOfArduinoPWM

Pac, pac, pac.. Słyszysz? To groch wali o ścianę..

[EasyPeasy_]

Bzdura, nie masz żadnej funkcji. Zrobiłeś reverse engeneering jakiejś funkcji bibliotecznej zamieniającej mityczne kąty na mikrosekundy impulsów. To nie ma odniesienia do jakiegokolwiek rzeczywistego serwa bo polega na pomyśle anonimowego programisty. W każdym konkretnym przypadku i tak musisz stroić to ręcznie do serwa, które posiadasz. Co więcej, używanie przez inżyniera w takich obliczeniach 8 cyfr znaczących jest po prostu śmieszne (dla mnie osobiście - kompromitujące). Żeby takie precyzje miały sens musiałbyś przewidywać orbity planetoid lub generować impulsy serwa z rozdzielczością 10 pikosekund. Bezmyślnie przepisując liczby z Excela otwarcie pokazujesz, jak bardzo nie czujesz tego co robisz. Aż przykro patrzeć.

Nie ma to odniesienia do żadnego rzeczywistego serwa, a jednak biblioteka Servo.h udostępniana dla Arduino działa z każdym serwem tak samo. Gadasz bzdury, poza tym zrobiłem sobie w pętli

digitalWrite PWM dla poszczególnych czasów z stałym okresem 20 ms i jakoś serwo idealnie przesuwa się tak jakbym wykorzystał tą bibliotekę, więc jednak raczej te czasy są dobre i rzeczywiste

"..współczesne nie są sterowane na zasadzie zmiany wypełnenia tylko zmiany długości impulsu i okresu"

No właśnie nie. Nie okresu. Tam napisali, że obecne serwa sterowane są wyłącznie długością impulsu. To tylko zrozumienie jednego prostego zdania..

Nie, bo kto może wiedzieć co miał na myśli autor pisząc "współczesne serwa", mam sobie wywróżyć czy te serwa z linku są to "współczesne serwa" jak i czasy impulsów dla kątów -> https://www.servocity.com/s3003-servo

"Biblioteki servo nie mogę wykorzystać już mówiłem"

To Ty mówiłeś a znając Twoje osiągnięcia w temacie, to stwierdzenie jest nic nie warte. Moim zdaniem wyciągasz błędne wnioski po prostu nie rozumiejąc działania swojego systemu.

A moim zdaniem nawet nie zajrzałeś do tamtego tematu o drżenia serwa, bo to nie ja wyciągnąłem taki wniosek, a ktoś inny. Poza tym wniosek jest prosty zarówno biblioteka Servo.h jak i SoftwareSerial.h korzysta z przerwań mikrokontrolera przez co nie mogą być obie naraz wykorzystane.

"Mój pomysł nie zadziała.."

Założyłem milcząco, że jesteś na tyle rozsądny by timing reszty kodu dopasować do programowej generacji impulsu dla serwa. Przecież po coś tę propozycję napisałeś. Cóż, nie pierwszy raz pomyliłem się.

Napisałem Pan w taki zagadkowy i niezrozumiały sposób te zdanie, że nic z niego nie rozumiem "by timing reszty kodu dopasować do programowej generacji impulsu dla serwa" -> przecież wyraźnie Pan pisał, żeby nie robić tego digitalWrite(), więc co niby miałbym dopasowywać.

Poza tym nie mam jeszcze całego kodu, gdzie bym miał obsługę GPS'a, filtr kalmana z IMU i wszystko inne. Bo Filtr Kalmana z IMU testowałem i jest osobno, teraz rozwiązuję konflikt GPS'a z serwami i dopiero pod koniec złącze wszystko w jedność.

Poza tym nie skrócę czasu wykonywania się wszystkich funkcji, więc niby jakbym miał timing dopasować do generacji impulsu dla serwa, skoro nie mogę zejść do <50 ms ?

"Są jakieś piny w Arduino.."

.

Pierwsza odpowiedź wyszukiwarki na pytanie "arduino hardware pwm":

https://www.arduino.cc/en/Tutorial/SecretsOfArduinoPWM

Pac, pac, pac.. Słyszysz? To groch wali o ścianę..

Nadal nie odpowiedział Pan co to znaczy sprzętowy PWM i jak miałbym to zrealizować.

Ale domyślam się, że powinienem wykorzystać timery z Atmegi do zrobienia PWM'a co będzie wymagało zaglądnięcia do dokumentacji, ustawienia odpowiednich rejestrów i przypomnienia sobie trochę z programowania AVR'ów

No będę musiał jeśli wykorzystam timery bardzo rozbudować tą funkcję co dostaje na wejście kąt i wypluwa czas impulsu, no ale cóż coś kosztem czegoś

Dobra to biorę się do pisania kodu.