Synchronizacja silników DC

[gomoter12]

Witam , pracuje nad platformą mobilną i mam problem ze synchronizacją silników DC. Chcę użyć transoptora do zliczenia długości impulsów funkcją pulseIn() ale nie mam pojęcia jak to napisać w programie.

[marek1707]

Zanim zaczniesz myśleć o programie oszacuj problem teoretycznie. Może nie ma sensu być w ogóle rozpatrywał ten sposób pomiaru. Odpowiedz sobie i nam:

1. Skąd będą pochodziły impulsy, znaczy z enkodera, ale gdzie zamontowanego i jakie będą one miały parametry np. długość? W jakich granicach będą się zmieniać?

2. Funkcja pulsein blokuje procesor na czas pomiaru. Czy możesz sobie pozwolić na zamrożenie procesora na czas najdłuższego impulsu? W tym czasie nie zrobisz ani nie zmierzysz niczego innego.

3. Jaką rozdzielczość ma wynik tej funkcji i czy jest ona dla Ciebie wystarczająca? Co funkcja robi gdy impuls jest długi?

4. Za pomocą metody pulsein() nie będziesz mógł mierzyć dwóch wejść na raz, to znaczy będziesz musiał pomijać niektóre impulsy a to znaczy, że nie będziesz znał położenia każdego silnika tylko jego prędkość chwilową w niektórych odcinkach czasu.

5. Co chcesz synchronizować? Położenie wału? Prędkość obrotową? A może tak naprawdę jakąś inną wielkość z tego wynikającą, np. chcesz sterować położeniem robota, promieniem jego skrętu?

6. W zależności od pkt 5 być może warto zastanowić się nad zmianą typu silników? Np. synchronizacja położenia będzie bardzo trudna w silnikach DC, gdzie możesz myśleć o co najwyżej próbach wyrównywania prędkości chwilowej  lub liczby obrotów czyli przejechanej drogi po czasie.

 

[gomoter12]

problem polega na tym, że jak robot jedzie prosto przez dłuższą chwilę to lewy silnik kręci się szybciej od prawego. Chcę ,żeby silniki miały równą prędkość obrotową , mógłbym zastosować przekładnie ale chcę to rozwiązać programowo. 

[marek1707]

To jest odpowiedź tylko na pyt. 5 i pośrednio na 6, choć nie do końca. Wciąż nie wiemy do czego ten robot ma być: czy jazda po prostej jest jego celem życiowym (jakiś wyścig) czy jest to tylko jeden z przypadków trasy a będzie np. używany do kreślenia zawiłych obrazków na kartonie. Wtedy silniki krokowe są dużo lepszym rozwiązaniem. Musisz się bardziej postarać, przemyśleć pkt. 1-4 i napisać więcej.. Jak rozumiem konstrukcję już masz, skoro wiesz jak się zachowuje. Tym łatwiej będzie Ci odpowiedzieć na moje pytania, bo znasz już typy silników, ich prędkości obrotowe i możliwe sposoby montażu enkoderów.

Problem jazdy prosto to nie jest tylko zadanie utrzymania równej prędkości chwilowej. Pomyśl, zawsze będą jakieś błędy regulacji więc silniki nigdy nie będą kręcić się równo. A procedura wygląda tak: pomiar, wyznaczenie błędów, zmiana wysterowania PWM silników, odczekanie chwili, znów pomiar itd. To będzie ciągła próba zerowania różnic, ale one wciąż będą. Takie drobne odchyłki prędkości obrotowych w robocie dwukołowym wyglądają jak delikatne myszkowanie na boki. Po każdym takim mikroodchyleniu wcale nie masz pewności, że robot wróci do pierwotnego kierunku więc musisz robić coś więcej. Potrzebujesz wyrównywania liczby obrotów kół w dłuższym czasie po to, by każde koło pokonało tę samą drogę - wtedy przynajmniej robot będzie miał przód skierowany w tę samą stronę co na starcie. I niestety to też nie jest wystarczające do osiągnięcia celu na prostej, bo poruszanie się w ten sposób ma niemiłą cechę kolejności wykonywanych operacji. Narysuj sobie drogę robota w której np. jedziesz chwilę dobrze, skręcasz delikatnie w prawo a potem przez długi czas znów jedziesz idealnie prosto. A teraz odwrotnie, zamień odcinki proste: przez długi czas od startu jedziesz idealnie prosto, skręcasz znów tak samo w prawo a potem przez chwilę znów prosto. W każdym z przypadków robot zatrzymasz się w innym miejscu mimo, że droga kół była taka sama. Smutne prawda? I dlatego tak ważne jest byśmy wiedzieli do czego ten pojazd ma służyć, po co chcesz jechać prosto (bo tak, czy chcesz trafić w  jakiś cel, czy jechać wzdłuż ściany itp), bo w niektórych aplikacjach można wspomagać się dodatkowymi danymi, np. odległością od ścianek labiryntu (myszy) czy pokoju, pozycją GPS lub wyznaczaną jakoś inaczej, a czasem to w ogóle nie jest potrzebne, bo robisz zabawkę zdalnie sterowaną bez żadnej autonomii.

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[Treker (Damian Szymański)]

@gomoter12, witam na forum 😉 Widzę, że to Twoje pierwsze kroki na Forbocie, oto najważniejsze informacje na start:

• Chcesz przywitać się z innymi członkami naszej społeczności? Skorzystaj z tematu powitania użytkowników.
• Opis najciekawszych funkcji, które ułatwiają korzystanie z forum znajdziesz w temacie instrukcja korzystania z forum - co warto wiedzieć?
• Poszczególne posty możesz oceniać (pozytywnie i negatywnie) za pomocą reakcji - ikona serca w prawym dolnym rogu każdej wiadomości.

Dnia 22.11.2018 o 18:10, gomoter12 napisał:

problem polega na tym, że jak robot jedzie prosto przez dłuższą chwilę to lewy silnik kręci się szybciej od prawego. Chcę ,żeby silniki miały równą prędkość obrotową , mógłbym zastosować przekładnie ale chcę to rozwiązać programowo. 

Akurat idealna jazda prosto jest (wbrew pozorom) dość trudna. Dlatego musisz odpowiedzieć dokładniej na pytania Marka - wtedy na pewno łatwiej będzie Ci pomóc.

Dnia 22.11.2018 o 17:23, gomoter12 napisał:

Chcę użyć transoptora do zliczenia długości impulsów funkcją pulseIn() ale nie mam pojęcia jak to napisać w programie.

Zakładając jednak najbardziej prawdopodobny scenariusz (zwykły robot, który ma jechać prosto, ale nie jakoś ekstremalnie dokładnie) to skąd pomysł na funkcję pulseIn()? Jak dokładnie chcesz ją wykorzystać - chodzi mi o zasadę działania programu, a nie o konkretną implementację w kodzie. Ile dokładnie impulsów z tego transoptora będziesz zliczał na jeden obrót wału silnika?