Transoptor szczelinowy - problem z fałszywymi impulsami

[rayvburn]

Cześć!

Mam problem z pomiarem drogi w moim robocie z napędem różnicowym.

Zastosowałem 2 transoptory szczelinowe z dyskami (20 impulsów / obrót) na wałach silników. Rozdzielczość enkodera 1,02 cm. Wyjścia transoptorów podpięte do Arduino Leonardo z dołączoną obsługą przerwań.

Problem jest taki, że robot często stojąc zlicza kolejne impulsy, nawet jeśli się nie poruszył nawet o 1 cm. Dzieje się to tylko, kiedy jest zatrzymany (a przynajmniej w czasie ruchu tego nie zauważyłem). Ręcznie też można czasem tak nakierować wał, że impulsy do uC lecą jak z armaty. Domyślam się, że chodzi tutaj o graniczną pozycję transoptora względem otworu na dysku.

Jest sposób ograniczenia tego w sposób software'owy ? Sprawdzałem bibliotekę debounce. Działa poprawnie dopóki nie trafi do trochę bardziej rozbudowanego programu.

Pomysły na załatwienie tego hardware'owo także mile widziane. Próbowałem już kondensator między GND a OUT transoptora, 300nF nie zmieniało niczego, 750nF omijało impulsy.

Używam transoptorów TCST1103.

Z góry dzięki za odpowiedzi

[marek1707]

Nic na to nie poradzisz. Drobne drgania tarczy w czasie postoju są dla fototranzystora nieodróżnialne od przejazdu normalnych szczelin w czasie obrotów tarczy. Żadne filtry nie pomogą, bo sygnał "zły" od "dobrego" niczym się nie różni oprócz kierunku "napływania" przesłony. A tego jeden czujnik nie wykryje. Musisz użyć tzw. detektora kwadraturowego czyli dwóch transoptorów na wspólnej tarczy przesuniętych o pół szerokości szczeliny. Wtedy możesz wykrywać kierunek (narysuj to sobie) i odróżniać drgania w zatrzymaniu od jazdy w którąś stronę. Albo wywalić w ogóle optykę i użyć detektora magnetycznego czyli scalaka z wbudowanym czujnikiem pola i wygodnym wyjściem cyfrowym.

[rayvburn]

Dzięki za te wszystkie sugestie

Myślałem o wrzuceniu kondensatora z tego powodu, że te "fałszywe" impulsy nadchodzą znacznie szybciej niż "rzeczywiste" (tego zapomniałem dopisać). Może wprowadzenie odpowiednio małej inercji załatwiłoby sprawę w takim przypadku?

[marek1707]

No ale pomyśl, przecież te zakłócenia nie biorą się z niczego. Gdy szczelina stanie na granicy detekcji poziomu wejścia cyfrowego, to każde mechaniczne drgnięcie, każdy szum od drugiego silnika itp powoduje zmianę stanu detektora. A takie zakłócenia są szerokopasmowe. Teraz zliczasz je szybko, bo możesz i myślisz, że tylko takie składowe tam są - a to nieprawda. Jeśli odfiltrujesz te szybkie, zostaną wolne i wtedy je będziesz widział i zliczał. Nie ma wyraźnego powodu, dla którego miałby być takie lub inne. Jedyną pewność daje podwójny fotodetektor i algorytm detekcji kierunku. Wtedy żadne pojedyncze wejście się nie liczy (może sobie szumieć), bo musi następować pewna skorelowana sekwencja zdarzeń (zboczy) w czasie na obu wejściach i to jest dopiero uznawane za impuls w danym kierunku. A dzięki przesunięciu o pół szerokości okienka nawet gdy jeden czujnik głupieje, drugi z definicji jest stabilny.

[rayvburn]

Faktycznie tak jak pisał marek1707 - problemem były drgania osi silników (u mnie porobiły się już spore luzy). Ale jednak udało się to wszystko rozwiązać software'owo, chociaż spędziłem nad tym 3 dni. Jeśli ktoś w przyszłości miałby ten sam problem, a niekoniecznie chciał zmieniać cokolwiek w hardware, to polecam podłączyć transoptor do wejścia analogowego i popatrzeć sobie jak zachowuje się napięcie przy obracaniu tarczy między emiterem i detektorem. Potem wystarczy włączyć Free Running Mode ADC, a w procedurze obsługi przerwania ustawić sobie 2 progi. U mnie teraz działa wszystko idealnie, bez zmieniania czegokolwiek w hardware.

Strony 290-320 w datasheet http://www.atmel.com/Images/Atmel-7766-8-bit-AVR-ATmega16U4-32U4_Datasheet.pdf

[marek1707]

Ok, czyli okazało się, że jednak znalazłeś cechę odróżniającą zakłócenia od sygnału użytecznego: tym razem była to amplituda. Drgania silników okazały się na tyle małe, że generowały niewielki sygnał na wyjściu czujnika. Sprzętowo wystarczyłaby bramka/wzmacniacz z histerezą (np. 74HC132 lub inwerter + oporniki). Ty nie mając tego w torze poradziłeś sobie mierząc po prostu poziom sygnału w ADC a histerezę robiąc programowo. Sposób zużywa trochę mocy obliczeniowej CPU + wejście + czas ADC i to pokazuje, że nie wolno robić projektów "na styk", ze 100% obłożeniem pinów CPU. Brawo.

[rayvburn]

Chyba trochę za szybko napisałem, że działa idealnie. Na płytce prototypowej tak, ale w robocie, gdy mam połączone masy 2 mikrokontrolerów i sterownika silników to napięcie odniesienia trochę pływa. Do tego stopnia, że teraz enkoder potrafi gubić impulsy, a nawet całkiem sporo. Próbowałem zmieniać odniesienia z AREF (5V+kondensator) na wbudowane 2,56V, ale też pływa (stabilizator liniowy?). Nie bardzo wiem teraz jak to rozwiązać.

Na podstawie odczytów z ADC: czasem min wartość to ~50, podczas gdy max ~500, a po 5 minutach min ~150, max ~350. Pobawię się jeszcze "zwężeniem" histerezy, ale wątpię czy do zadziała.

Robiłem też zbieranie danych z odczytów ADC i znajdowanie wartości min i max z kolejnych 5000 próbek, ale nie działa to do końca tak, jak bym chciał.

Mile widziane jakieś wskazówki.

[marek1707]

Niemożliwe, by wewnętrzne źródło odniesienia tak pływało. Coś skopałeś, pokaż schemat w okolicach AREF, AVCC oraz czujniki - może to im napięcie przysiada? Mierzyłeś rzeczywiste VCC multimetrem? Takie wahania musiałbyś zauważyć. No i wrzuć kawałek kodu obsługi ADC i napisz więcej o tym uśrednianiu czy jak to tam robisz.

[rayvburn]

Nie ciągnąłem już dalej tematu, jedyne co zmieniłem to wyregulowałem w miarę progi w tym regulatorze histerezowym - dałem szerszy zakres w razie gdyby to napięcie zaczęło pływać jednak. Nie wiem dlaczego była taka różnica względem odniesienia jak 2 posty wyżej, pojawiała się dopiero po kilku minutach. Ostatecznie błąd w zliczaniu to średnio 1 impuls ominięty na odcinku 2 m. Myślę, że z tym hardwarem ciężko byłoby z tego coś więcej wycisnąć.