ATNEL tech-forum

Re: Sterowanie serwem - dziwny problem

2014-03-12T18:51:37+01:00

Dzięki w pomoc. Troche poczytałem, ale jeszcze sporo przede mną. Teraz trochę czasu brakuje, ale jak już się znowu wezmę na ten temat pewnie jeszcze nie jedno pytanie tu padnie.

Statystyki: Napisane przez frickle — 12 mar 2014, o 18:51

Re: Sterowanie serwem - dziwny problem

2014-03-02T00:33:26+01:00

http://hobby.abxyz.bplaced.net/index.php?pid=3&aid=20
http://www.rcclub.eu/viewtopic.php?f=7&t=4421
http://www.robotyka.net.pl/sterowanie-serwomechanizmem/
https://ccrma.stanford.edu/courses/250a ... ource.html
http://omegav.ed.ntnu.no/wiki/index.php ... urce/Servo
http://www.ermicro.com/blog/?p=771
http://letsmakerobots.com/node/36528

Witam .
Powyżej wkleiłem kilka linków do stron o tematyce serv.
Poczytaj uważnie a wiele rzeczy się wyjaśni .
Absolutnie nie mam zamiaru Ciebie krytykować , ale Twoje podejście z delayami jest niestety troszkę nie w tą stronę .

Zachęcam do lektury powyższych stron a naprawdę zobaczysz , że obsługa kilku serv nie stanowi problemu , jeżeli odpowiednio podejdziesz do ich obsługi.

Pozdrawiam .

Statystyki: Napisane przez pagosa747 — 2 mar 2014, o 00:33

Re: Sterowanie serwem - dziwny problem

2014-03-02T00:19:04+01:00

Z serwami bawiliśmy się dawno temu, myślę że trochę może pomóc wątek:

topic1095.html

Statystyki: Napisane przez Sonix — 2 mar 2014, o 00:19

Re: Sterowanie serwem - dziwny problem

2014-03-01T15:33:25+01:00

o delay-ach do tego zastosowania zapomnij, w szczególności w przerwaniach i to jeszcze dla kilku serw - wtedy to już wogóle nie wiedziałbyś co robi program, który napisałeś ;p Ja swego czasu robiłem program dla dwóch serw, zaś zadajnikiem były sygnał step/dir. Wszystko uruchomione zostało na przerwaniach.
Algorytm wygląda następująco:
1. timer pierwszy odlicz i uruchamia przerwanie co 20ms które załacza serwo /serwa (daje 1) i startuje timer drugi (drugi logicznie a nie że Tmiere2 z procka)
2. drugi timer odlicza czas do zadanego mu czasu i wywołuje przerwanie w którym na wyjście serwa daje stan 0.

Dla dwóch serw wykorzystałem timer 1 (16 bitów zapewniło precyzję czasu oraz pokrycie pełnego zakresu wyzwalania) i jego przerwania od OCRxA oraz B do dwóch serw, jeśli Ty potrzebujesz więcej to musisz to obsłużyć programowo w przerwaniu.
Żeby któreś z serw nie opóźniało załączenia/wyłączenia kolejnego można zrealizować to jak w punktach 1 i 2 z tym, że najpierw startuje 1 serwo i jest gaszone i następne przerwanie od timera nie następuje po 20ms a po 10ms i wtedy załączane jest serwo 2 (a w przypadku 4 serw po 5 ms). dzięki czemu obsługa serw nie nachodzi na siebie a procek się nie nudzić ~18ms.
W moim programie dodatkowo, timery sprzętowe liczyły tiki sygnału step, zaś przerwania zew INTx określały kierunek dir.

Statystyki: Napisane przez Lukasz89 — 1 mar 2014, o 15:33

Re: Sterowanie serwem - dziwny problem

2014-03-01T13:45:38+01:00

Pomogło faktycznie. Dzięki.

xor napisał(a):

Oczywiście delaye w przerwaniu to zły pomysł, ale powiedzmy, w tym przypadku, w celach naukowych, niech będzie

Hmm, no niby tak. Ale docelowo chciałbym wysterować kilka/kilkanaście serw z jednego układu ATMEGA, w którym będą tylko przerwania natomiast program główny będzie pusty. Czy to też wtedy jest tak bardzo niezalecane?

Jaka jest alternatywa? PWM?
Czy dam radę wysterować kilkanaście serw korzystając z PWM?

Statystyki: Napisane przez frickle — 1 mar 2014, o 13:45

Re: Sterowanie serwem - dziwny problem

2014-03-01T12:35:06+01:00

Przyczyną jest być może to że (za http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html#gab20bfffeacc678cb960944f5519c0c4f):

Quote:

The maximal possible delay is 768 us / F_CPU in MHz.

If the user requests a delay greater than the maximal possible one, _delay_us() will automatically call _delay_ms() instead. The user will not be informed about this case.

Poza tym:

Quote:

In order for these functions to work as intended, compiler optimizations must be enabled, and the delay time must be an expression that is a known constant at compile-time. If these requirements are not met, the resulting delay will be much longer (and basically unpredictable), and applications that otherwise do not use floating-point calculations will experience severe code bloat by the floating-point library routines linked into the application.

Spróbuj może zrealizować opóźnienie w ten sposób:
[syntax=c]for(int us = pozycja;us;us--)
_delay_us(1);[/syntax]

Oczywiście delaye w przerwaniu to zły pomysł, ale powiedzmy, w tym przypadku, w celach naukowych, niech będzie

Statystyki: Napisane przez xor — 1 mar 2014, o 12:35

Re: Sterowanie serwem - dziwny problem

2014-03-01T12:29:13+01:00

Serwem się nigdy nie bawiłem, ale z tego co na tym forum wyczytałem to używanie "delaya" w przerwaniu jest ogólnie nie zalecane.
Druga rzecz jaka mi się akurat rzuca w oczy, to użycie w pętli głównej _delay_ms(); natomiast w przerwaniu _delay_us(); Dlaczego?

Statystyki: Napisane przez Marcin_G — 1 mar 2014, o 12:29

Re: Sterowanie serwem - dziwny problem

2014-03-01T10:57:35+01:00

REDOX S90

Statystyki: Napisane przez frickle — 1 mar 2014, o 10:57

Re: Sterowanie serwem - dziwny problem

2014-03-01T10:52:44+01:00

napisz może jakie to serwo konkretnie?

Statystyki: Napisane przez rayden — 1 mar 2014, o 10:52

Sterowanie serwem - dziwny problem

2014-03-01T10:31:06+01:00

Zaczynam zabawę z serwami. Zakupiłem tanie serwo modelarskie i zacząłem bawić się w sterowanie tym dziwadłem. Pierwszy program służący do tego wyglądał mniej więcej tak, że w głównym programie, w pętli załączałem na konkretny czas sygnał na wybrany pin a potem czekałem określony czas, tak aby łącznie czasy sygnału H i L na pinie wynosiły ca. 20ms.
[syntax=c]for(int8_t i=0; i<100; i++){
PORTA |= (1< _delay_us(500);
PORTA &= ~(1< _delay_us(19500);
}

for(int8_t i=0; i<100; i++){
PORTA |= (1< _delay_us(3500);
PORTA &= ~(1< _delay_us(16500);
}[/syntax]

Sposób siermiężny, ale chodziło o sprawdzenie czy będzie działało. Dodam że wartości opóźnień zostały dobrane doświadczalnie, i cały program miał machać orczykiem z lewa do prawa i z powrotem, co też się udało. Przy tej konfiguracji, serwo zachowało się zgodnie z oczekiwaniami, i kąt obrotu od pozycji minimalnego wychylenia do maksymalnego wynosił z grubsza 180 stopni (tak na prawdę troszeczkę więcej).

Aby troszeczkę ładniej to wyglądało, stwierdziłem że trzeba zaprząc do tego przerwania. Pomysł był taki, że będę wykonywał przerwanie co ca. 20 ms a wewnątrz będę generował sygnał o określonej długości (na zasadzie podobnej jak powyżej, z tym że sama częstotliwość wykonywania przerwania, powoduje że wystarczy ustawić stan H na wybranym pinie, odczekać określony czas, np 1500 us, i ustawić na pinie znowu stan L). Kod wygląda z grubsza tak:
[syntax=c]volatile int16_t pozycja = 0;
volatile int8_t st = 0;

int main(void){
MCUCR |= (1<MCUCR &= ~(1<GICR |= (1<
DDRC = (1<
TCCR0 |= (1<TCCR0 |= (1<TCCR0 |= (1<OCR0 = 156; //ustawienie rejestru do porównań dla przerwania na timerze 0
TIMSK |= (1<
sei(); //globalne zezwolenie na przerwania

while(1){
pozycja = 500;
_delay_ms(500);
pozycja = 1000;
_delay_ms(500);
pozycja = 1500;
_delay_ms(500);
}

}

//procedura obsługi przerwania
ISR(TIMER0_COMP_vect) {
PORTC |= (1<_delay_us(pozycja);
PORTC &= ~(1<}[/syntax]

Wszystko wydaję się być OK, natomiast przy takim podejściu, serwo wykonuje ruch w zakresie 90 stopni a nie 180. Sprawdziłem wartości rejestrów, wyliczyłem że okres dla przerwania to 20 ms, niby wszystko OK a jednak coś nie bardzo.

Być może ktoś z Was miał podobny problem, może po prostu nie zauważam jakiegoś błędu i powielam go za każdym razem, nie mam pojęcia. Proszę o ewentualne naprowadzenie na właściwy tor jeśli gdzieś dałem ciała.

Dodam że pracuję na mikrokontrolerze ATMEGA16A.
edit: częstotliwość taktowania: 8 MHz na wewnętrznym oscylatorze.

Z góry dzięki za pomoc.

Statystyki: Napisane przez frickle — 1 mar 2014, o 10:31