Możliwości atmegi16??

[fixa]

Zalezy mi na dokładności 1% tylko niewiem czy uda sie taka osiągną

[grabo]

dondu, nie wprowadzaj kolegi w błąd. Nie wiem na podstawie jakiej wiedzy doradzasz ale piszesz herezje. Silnik ma pewną bezwładność i nie od razu zmienia kierunek po zmianie napięcia na wejściu. Prawidłowa pętla sprzężenia zwrotnego polega na kontroli POZYCJI, nie prędkości i odczyt kierunku jest jak najbardziej potrzebny. Regulator pracuje ze stałą częstotliwością i przy każdej iteracji ustawia odpowiednią wartość prądu lub przeciwprądu w zależności od uchybu (wartość zadana - wartość odczytana). Zaproponowana wartość 1000 razy na sekundę, czyli co 1ms, jest jak najbardziej trafna.

Ruch uzyskujemy poprzez dodawanie w pętli regulatora do wartości zadanej jakiejś wartości odpowiadającej żądanej prędkości. W takim układzie można uzyskać precyzyjny ruch z dowolną prędkością, zarówno bliską maksymalnej jak i bardzo małą, rzędu jednego impulsu na cykl.

[dondu]

dondu, nie wprowadzaj kolegi w błąd. Nie wiem na podstawie jakiej wiedzy doradzasz ale piszesz herezje. Silnik ma pewną bezwładność i nie od razu zmienia kierunek po zmianie napięcia na wejściu.

Nie czytasz dokładnie tego co napisałem, więc zanim herezje mi zarzucisz, poświęć troszkę czasu i przeanalizuj moje posty, oraz posty autora, według kolejności pojawiających się informacji, a nie tylko ostatni.

Zaproponowana wartość 1000 razy na sekundę, czyli co 1ms, jest jak najbardziej trafna.

Czy ja gdzieś napisałem, że to niewłaściwe podejście? Zadałem jedynie pytanie, na które nie otrzymałem odpowiedzi.

Dodatkowo autor nie napisał co właściwie buduje. Dostaje odpowiedzi takie jak informacje w jego postach i w dodatku po kolei wraz z jego postami. Gdyby napisał konkretnie, że robi robota kołowego RÓŻOWY FIGHTER, a nie urządzenie do śledzenia słońca, to wiedzielibyśmy więcej. W obu przypadkach porady byłyby inne nieprawdaż?

[fixa]

do kolegi "grabo":

po pierwsze to dzięki za udział w dyskusji, zgadza się nie napisałem w jakiej aplikacji będzie pracował ten silnik bo w niczym konkretnym nie będzie pracował. Zależ mi na zmianie obciążenia, zmianie Vzad i obserwowaniu jak się będzie zachowywał silnik, jak bedzie wyglądał przebieg prędkości, jednak w miarę precyzyjnej kontroli prędkości.

Idąc dalej napisałeś :

Prawidłowa pętla sprzężenia zwrotnego polega na kontroli POZYCJI, nie prędkości i odczyt kierunku jest jak najbardziej potrzebny

Mogę się mylić ale ty wspominasz o sprzężeniu położenia jeszcze wstępuje sprzężenie prędkościowe na którym mi zależy.

[grabo]

dondu, przeczytałem całość, inaczej bym się nie czepiał.

Jeśli wykorzystać ATmegę w pełni, to dlaczego nie z dwukanałowym enkoderem? Napisałem jak zrobić to w sposób najbardziej efektywny i najpowszechniej stosowany w serwonapędach, a czy ktoś na tym skorzysta, to już w jego kwestii

[dondu]

dondu, przeczytałem całość, inaczej bym się nie czepiał.

Chyba jednak nie czytałeś:

1. Bezwładność o której piszesz, opisałem wcześniej:

Z 13kHz silnik nie zatrzyma się w ciągu jednego impulsu z enkodera, czyli kierunek nie zmieni się w tym przedziale czasu. Czy się ze mną zgadzasz?

2. Sprawdzanie kierunku:

3. gdy silnik zwolni poniżej określonej granicznej prędkości ponownie włączasz sprawdzanie kierunku.

Taki sposób zapewnia wykorzystanie timerów, o których pisałem bez ograniczeń podanych prawidłowo przez kol. razos. Efekt:

- wielokrotne zwiększenie dokładności pomiaru prędkości,
- odciążenie mikrokontrolera.

przy zachowaniu określania kierunku w sposób który zacytowałem kilka linijek wyżej (nr 3).

Trzeba nieco otwartości na pomysły kol. grabo.

[grabo]

dondu, jak już pisałem fixa zrobi jak zechce a regulator położenia załatwia obie w/w sprawy. Dobrze zestrojony jest w stanie zatrzymać silnik w ciągu kilku cykli regulacji i masz cały czas informację o kierunku. Ale skoro uważasz, że lepsze jest wrogiem dobrego... To co piszę to nie moje "widzimisię" ale wiedza poparta eksperymentami i godzinami testów. Nie mam zamiaru się kłócić, po prostu przedstawiłem swoje zdanie.

Trzeba nieco pokory kol. dondu

[dondu]

No cóż, klepanie ciągle tych samych algorytmów, bez zastanowienia się, czy można zrobić to lepiej i taniej (mniejszy procesor, mniejszy pobór prądu z aku), nazywa się staniem w miejscu. Chcesz stać, to stój

[grabo]

Najwidoczniej szybciej stoję niż Ty idziesz naprzód...

[dondu]

Bardzo ładny projekcik. I jak każdy można zrealizować na wiele sposobów. Tylko po co męczyć procesor sprawdzaniem kierunku, skoro jadę z maksymalną prędkością kręcąc silnikami w wiadomą mi stronę? To zbytek luksusu.

[KD93]

dondu, czekam na publikację Twojego robota. Ja nie jestem na takim etapie zaawansowania jak grabo, ale widzę że zajmuje się jakiś czas programowaniem robotów pod kątem dokładności i wiem, że zdobył w tej dziedzinie doświadczenie praktyczne, więc na logikę wybrałbym jego rozwiązania jako sprawdzone. Póki nie pokażesz swoich przekonań w praktyce, to jest to dla mnie teoretyzowanie, nie mówię że błędne, ale nie sprawdzone.

[dondu]

dondu, czekam na publikację Twojego robota. Ja nie jestem na takim etapie zaawansowania jak grabo, ale widzę że zajmuje się jakiś czas programowaniem robotów pod kątem dokładności i wiem, że zdobył w tej dziedzinie doświadczenie praktyczne, więc na logikę wybrałbym jego rozwiązania jako sprawdzone. Póki nie pokażesz swoich przekonań w praktyce, to jest to dla mnie teoretyzowanie, nie mówię że błędne, ale nie sprawdzone.

Nie twierdzę, że jestem guru robotów. Wręcz przeciwnie. I z podziwem patrzę na osiągnięcia kol. grabo.

Pokazałem jedynie, że ograniczenie (poprawnie wyliczone) w poście kol. razors można spokojnie zastąpić innym rozwiązaniem, które dodatkowo daje zysk w postaci:

Taki sposób zapewnia wykorzystanie timerów, o których pisałem bez ograniczeń podanych prawidłowo przez kol. razos. Efekt:

- wielokrotne zwiększenie dokładności pomiaru prędkości,

- odciążenie mikrokontrolera.

Nie ma jednej jedynie słusznej drogi rozwiązywania zadań. Każde z nich można rozwiązać na wiele sposobów. A ponieważ kol. grabo zarzuca mi herezje, stąd mam nadzieję, że odpowie na moje pytanie zadane wcześniej:

Po co męczyć procesor sprawdzaniem kierunku, skoro jadę z maksymalną prędkością kręcąc silnikami w wiadomą mi stronę?

biorąc pod uwagę, uwzględnienie bezwładności w taki sposób:

3. gdy silnik zwolni poniżej określonej granicznej prędkości ponownie włączasz sprawdzanie kierunku.

przy 1000 pomiarach na sekundę.

Może czegoś nie wiem, to się nauczę.

Niedawno miałem za zadanie poprawić projekt pewnego elektronika, zasilany z baterii, działał niecałe 2 lata. Po spędzeniu nad projektem kilku ładnych dni i zaimplementowaniu wielu rozwiązań (podobnych do tego które tutaj proponuję), z miesięcznego testu wynika, że układ pracować będzie na takiej samej baterii 5 razy dłużej - 10 lat.

Da się, tylko trzeba się nad tym nieco pochylić. Nie twierdzę, że gość odwalił manianę. Może miał mało czasu, może mało mu płacili, może wytyczne były inne, może ...

Podobnie jest w przypadku tego tematu. Otwartość polega na próbie zrozumienia idei i pozytywnej dyskusji, a nie:

dondu, nie wprowadzaj kolegi w błąd. Nie wiem na podstawie jakiej wiedzy doradzasz ale piszesz herezje.

[grabo]

Może herezja to za duże słowo, ale:

Czy ten mikrokontroler będzie także sterował tym silnikiem?

Jeżeli tak, to:

1. po co wykrywać kierunek, skoro dokładnie będziesz wiedział, w którą stronę się kręci.

- badanie kierunku nie jest Ci potrzebne, bo Ty decydować będziesz, w którą stronę ma się silnik kręcić. No chyba, że silnik może być poruszany przez zewnętrzne siły, np. pojazd jest "na luzie" i ktoś go popchnie.

Hamując przeciwprądem nie masz pewności w którą stronę kręci się silnik, ponieważ może jeszcze zwalniać, a może rozpędzać się w drugą stronę. Nie ująłeś tego przypadku w rozważaniach.

im większa częstotliwość pomiarów, tym mniejsza ich dokładność

Tu się zgodzę, bo wtedy operujemy na mniejszych liczbach i pojedynczy bit ma większą wartość procentową, ale potem piszesz:

timer do zliczania pozwoli Ci na osiągnięcie dużej dokładności

Nie ma różnicy czy będzie zliczał to timerem, czy inkrementując rejestr w przerwaniu, dokładność będzie taka sama, oczywiście zakładając, że przerwanie zdąży się wykonać za każdym razem.

Zaproponowana wartość 1000 razy na sekundę, czyli co 1ms, jest jak najbardziej trafna.

Czy ja gdzieś napisałem, że to niewłaściwe podejście? Zadałem jedynie pytanie, na które nie otrzymałem odpowiedzi.

Nie czepiałem się Ciebie, po prostu potwierdziłem, że zgadzam się z tym założeniem

I na koniec odpowiedź na pytanie:

Po co męczyć procesor sprawdzaniem kierunku, skoro jadę z maksymalną prędkością kręcąc silnikami w wiadomą mi stronę?

Nie czytając kierunku możesz jedynie założyć, że wiesz w którą stronę jedziesz, ale o tym pisałem już na początku. Rozumiem, że bronisz swojej pozycji, ale w zaproponowanym przez Ciebie rozwiązaniu i przy wspomnianych wyżej założeniach i tak musisz sprawdzać jakąś wartość (w Twoim przypadku prędkość). Jako programista, na pewno wiesz, że obliczenie prędkości i porównanie jej z jakimś progiem trwa więcej cykli niż sprawdzenie pojedynczego pinu/bitu, tym bardziej gdy są to liczby większe niż szerokość szyny danych. Dodatkowo dochodzi przełączanie się pomiędzy regulatorami i ustalenie jakiegoś progu, więc gdzie tu zysk?

Co więcej, czytając oba kanały i reagując na oba zbocza (narastające i opadające) można uzyskać 4-krotnie większą rozdzielczość enkodera niż w przypadku licznika reagującego na pojedyncze zbocze, a to przekłada się bezpośrednio na dokładność pomiarów. Według mnie jest to silny argument.

[fixa]

dziekuje wszystkim za cenne uwagi postaram sie calosc mojej pracy zamiescic pod koniec nastepnego m-c, niestety nie ma wolnego czasu zeby teraz to skonczyc

[dondu]

@grabo

No, teraz to rzeczowa dyskusja

-------------------------------------------------------------

Dla uporządkowania dyskusji

Aby ułatwić zrozumienie dlaczego zaprezentowane rozwiązanie daje same zyski rozbiję ten problem na punkty:

1. Prędkość Vmin

Ustalam minimalną prędkość, przy której mój pojazd będzie sprawdzał kierunek w którym jedzie. Prędkość tę nazwijmy Vmin. Przyjmijmy, że jest to np. 1/4 jego maksymalnej prędkości. Czyli od 0 do Vmin kontrola kierunku będzie ZAWSZE WŁĄCZONA.

2. Częstotliwość pomiarów prędkości

Autor tematu chce mierzyć prędkość 1000 razy na sekundę - OK, tak przyjmujemy.

3. Dlaczego można wyłączać sprawdzanie kierunku powyżej Vmin?

Pojazd, a nawet sam silnik fizycznie nie jest w stanie zmienić kierunku jazdy gwałtownie w czasie 1/1000 sekundy.

Innymi słowy jadąc z prędkością większą od Vmin (gdy kontrola kierunku jest wyłączona), nie jest w stanie zmienić jej na przeciwną w czasie krótszym niż 1/1000 sekundy. Proces zmiany kierunku spowodowany bezwładnością całego urządzenia, spowoduje systematyczne zmniejszanie się prędkości, co przy 1000 pomiarach na sekundę zostanie wykryte i włączona zostanie kontrola kierunku.

Czy ktoś uważa, że pojazd jest w stanie przy prędkości, co najmniej Vmin zmienić kierunek w czasie krótszym niż 1/1000 sekundy?

4. Algorytm:

a1. pojazd stoi.

a2. pojazd rusza w określonym kierunku więc nie muszę sprawdzać kierunku, ale dla świętego spokoju i uproszczenia algorytmu, sprawdzanie kierunku jest włączone.

a3. pojazd przyspiesza ale nie osiągnął jeszcze prędkości Vmin (sprawdzanie kierunku nadal włączone)

a4. pojazd przekracza Vmin:

- do tego momentu kierunek był sprawdzany cały czas

- od tego momentu kierunek przestaje być sprawdzany.

a5. pojazd jedzie zmieniają swoją prędkość, ale zawsze powyżej Vmin, więc nie ma potrzeby sprawdzania kierunku,

a6. pojazd zwolnił poniżej Vmin - włącza się sprawdzanie kierunku.

a7. pojazd ponownie przyspieszył powyżej Vmin znowy nie sprawdzamy kierunku

a8. zwolnił poniżej Vmin - włączamy sprawdzanie kierunku

a9. pojazd się zatrzymał lub zmienił kierunek wróć do pkt 2.

Czy algorytm jest zrozumiały?

-------------------------------------------------------

Przykład:

Załóżmy, że pojazd jest w stanie zmienić kierunek jazdy z Vmin na przeciwny w 1/10 sekundy.

Program w tym czasie dokona 100 pomiarów prędkości - więc wykryje fakt zmniejszenia się prędkości poniżej Vmin i włączy sprawdzanie kierunku.

Czy ktoś ma inne zdanie?

-------------------------------------------------------

Do reszty argumentów kol. grabo odniosę się po kolei w następnych postach.