Poszukuję schematu prostego układu fail-safe, ale nie opartego na mikrokontrolerze Microchip (Atmel może być). Wszystkie programatory PIC'a które znalazłem wymagają wysokiego napięcia do zaprogramowania, a mam tylko zasilacz 5V i programator ISP dla kontrolerów Atmel'a. Może ktoś posiada taki schemat i mógłby go udostępnić?
Schemat jest bardzo prosty. Najtrudniejszy jest program (firmware) i w nim jest cała tajemnica układu.
Kończę właśnie przygotowywać taki układ do serwyjnej produkcji. Pierwsze, prototypowe układy za 2 tygodnie. Jeśli chcesz, to Ci sprzedam Ci jeden z prototypów z zainstalowanym programem. W skrócie:
- Atmel AVR ATMega32
- 8 kanałów
- rozdzielczość serwomechanizmów: 2048 kroków
- gniazdo programowania Kanda ISP
- gniazdo autopilota RS-232 TTL
Cztery tryby pracy: - "przezroczysty" - tak, jakby nic nie było pomiędzy odbiornikiem i serwami - "fail-save" - przy zaniku sygnału układ ustawia serwa w pozycji z chwili uruchomienia układu - "RS-232" - wejście z odbiornika jest odcięte, serwami steruje się przy pomocy protokołu RS-232 (pełny protokół z sumami kontrolnymi BCC, powtarzaniem ramek itd) - "Autopilot" - (właściwy tryb, dla którego ten układ był projektowany) - normalnie układ pracuje jak fail-save. Równocześnie ciągle próbkuje kanał nr 8. Gdy kanał wejdzie w "stan wysoki" (nie w rozumieniu TTL, lecz sygnałów PWM), to na gnieździe EXT autopilota podnosi się RTS, co jest sygnałem dla autopilota, że "teraz ty sterujesz". Wówczas układ pracuje jak w trybie RS-232 do czasu przełączenia kanału w "stan niski". W tryb autopilota układ przechodzi automatycznie w przypadku braku sygnału z nadajnika.
Witam pomyślałem ze możliwe ze sobie cos takiego zrobię ale inaczej
1- procesor zapamiętuje ustawienia przy starcie
2- przy impulsie z odbiornika procesor nic nie robi
3- przy braku impulsu np. 1 sek. procesor wyłącza odbiornik i wysyła na serwa sygnały zapamiętane .
4- przy ponownym pojawieniu się sygnału wraca do czuwania . Marek S
Dnia 04-02-2007 14:30, Użytkownik Marek S napisał:
Nie dość, że się napracujesz, to przy zakłóceniach rozwalisz model. Układ musi wciąż badać nie tylko czy jest sygnał, ale również czy jest on prawidłowy. Kup sobie REX MPD - nic nie będziesz musiał robić. Mariusz.
Atmega8 ma niekorzystny układ wyprowadzeń. Od biedy pewnie by wystarczyła.
16 i 32, to bardzo podobne procesory, więc w razie potrzeby można zmienić na
atmega32 mam dobrze przetestowaną i opanowaną. Różnica w cenie, to 3-5 zł. W rozmiarze, to 3mm. Powodów jest wiele, nie chce mi się przytaczac wszystkich.
To dokładnie to samo, co u mnie w trybie "fail-save".
Zawsze można kupić gotowy układ w sklepie. Ale to "damskie" zachowanie. Gdyby nie było na świecie eksperymentujących facetów, to technika zatrzymałaby się na 1 w. n.e. Zawsze istnieje ryzyko, ze kogoś zabiję modelem, ale bez ryzyka nie ma postępu.
Zgadzam się. Badanie poprawności sygnału, to zawiły temat. Cholernie się z tym namęczyłem. To samo z płynnym sterowaniem serwami. Tak, jak napisałem: cała sztuka w programie. Sam układ, to pryszcz.
Witam pewnie masz racje jakąś ten pomyśl jak wiele innych powędruje na półkę . J nie mam potrzeby się tym zajmować ale Łukasz jak już cos sensownego wymyślisz to daj znać . Może ktoś ma program do procesorów PCM futaby ? Marek S
Ok. Jak zacznie działać w komplecie :) Na razie na zestawie prototypowym na razie uruchomiłem tylko na jednym kanale. Właśnie strawiłem pierwsza płytkę docelowego układu.
A co do atmega32, to przywiązałem się do tego układu po prostu, polubiłem go.
Dnia 04.02.2007 Lukasz snipped-for-privacy@poczta.onet.WYTNIJpl> napisał/a:
witam rzeczywiscie badanie sygnalu jest strasznie upierdliwe, nie wystarczy sama kontrola prawidlowej dlugosci impulsow czy odleglosci miedzy nimi, bo odbiornik przy wylaczonym nadajniku odbieral dosc czesto jakies smieci ktore sie kwalifikowaly niby jako dobre, z tego co sie bawilem to jak sie liczylo do 3 dobrych kolejnych ramek bylo lepiej, przy 4 przez caly dzien chodzilo ok do tego dochodzi to ze przy obsudze klawiatury czy lcd 10MHz procek sie obija totalnie, to tutaj przy rozdzialce 1000 czy 2000 krokow na zakres sterowania serwa (plus minus 1mili sekunda) wychodzi 1 czy 0,5 mikro sek a to jest malutko cykli :-(
Potwierdzam. To jest własnie ten problem :) Poprawnośc impulsów sprawdzam w ten sposób, że liczę ilość cykli w ciągu sekundy. Jeśli < 25 lub > 100 popranwych, to odłączam serwa (trwa to pół sekundy).
Problemem jest jeszcze równoczesne trzymanie serw w zaprogramowanej pozycji tak, żeby nie drgały i równoczesne sprawdzanie, czy sygnał z nadajnika juz wrócił do normy. To jest dopiero sztuka. Spóźnienie, niedokładność sterowania rzędu kilkunastu taktów zegara już powoduje drganie serwa.
Przyznaję, że pierwotnie myślałem: phi! 16MHZ, toż zawrotna prędkość. A teraz liczę każdy takt zegara...:), a obliczenia wykonuję w czasie tej niecałej jednej milisekundy od podniesienia sygnału, do opuszczenia. Wtedy tylko mam "czas wolny".
Mimo, że w pracy siedze nad takimi układami, to przyznaję, że nie doceniłem problemu do końca :)
Witam, z ciekawością obserwuję Twoje postępy a to dlatego, że sam mam ochotę zająć się czymś analogicznym. Podejrzewałem, że mogą powstać takie problemy, dlatego ja myślę o zastosowaniu dwóch procesorów - jeden do łapania sygnałów z serw i do ich generowania a drugi do obliczeń, bądź też puścić całe we/wy na przerwaniach. Bo komunikacja między tymi dwoma procesorami to byłoby góra kilkanaście bajtów na cykl (czyli 50 razy na sekundę), a więc nie powinna zabijać systemu. Na Atmelach się nie znam, ale pracuję z procesorami Cypress. To dość zgrabna architektura, na razie myślę o zrobieniu na nim takiego właśnie procesora komunikacyjnego. Na Cypressach dałoby się nawet zrobić całe we/wy na przewaniach, więc sprawa obliczeń nie byłaby tak restrykcyjna. Niestety cyprysy są dość słabe - tylko kilka MIPSów i max 2 KB RAM, ale czy na początek potrzeba więcej?
Problem, jak napisał Karol, polega na tym, że np. sterując sygnałem serwa musisz opuścić zbocze sygnałowe w ściśle określonej chwili, z dokładnością do 1 mikrosekundy (przy 1024 krokach).
U mnie, przy 16MHz (16MIPSów) 1 mikrosekunda, to jest 16 taktów zegara. Robię to na przerwaniu zegarowym, więc jest dokładnie. Dopóki nie trzeba sprawdzać nadajnika - wszystko musi działać idealnie.
Jeśli np. w międzyczasie wyskoczy Ci jakiekolwiek przerwanie, to nie może być ono dłuższe, niż 16 taktów. A już samo wywołanie procedury przerwania zabiera już 6 taktów. Czyli masz max. 10 taktów wewnątrz przerwania, a to są raptem może 2 instrukcje. W praktyce moje (HS-50) serwo zaczyna drgać przy niedokładności rzędu 2-3 mikrosekund.
Tak więc przy kilku MIPS-ach może być mało czasu. Można robić inne czynności, ale tylko zaraz po podniesieniu zbocza jednego z serw. Zakładam, że mam wtedy pewny wolny czas ok. 0.5-1.0 milisekundy, kiedy wiem, że nic się nie powinno zdarzyć.
Na szczęście serwa są włączane sekwencyjnie, bo procek by nie wyrobił na zakrętach... :) I na całe szczęście protokół PWM serw przewiduje tą "przerwę" 1 msek, w której coś mozna zrobić pożytecznego. Albo uśpić procek na drzemkę, co by prądu nie marnował.
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.