Robot klasy LineFollower - Lajt

Ogromne gratulacje Kolego za świetnego robota

A teraz pytania:
- zaciekawił mnie nietypowy kształt płytki vs. zamówienia w Satlandzie (sam u nich zamawiam). Czy tego typu kształt wraz z wewnętrznymi wycięciami to po prostu obrys na warstwie keep out czy musiałeś im dawać jakieś dodatkowe wytyczne co do wyfrezowania tych wewnętrznych prostokątnych otworów?

- regulatory PD i PID: dobierałeś parametry eksperymentalnie, na podstawie wyliczeń teoretycznych (metoda zieglera-nicholsa) czy zaimplementowałeś jakiś algorytm samouczenia?

- interesuje mnie też samo " programowe rozdzielenie mocy" na poszczególne koła. Regulator PD dąży do tego, aby robot jechał prosto (wg lini), regulatory PID utrzymują odpowiednią prędkość obrotową na każdym z kół. Jak natomiast generowany jest sygnał wartości zadanej dla regulatorów PID współpracujących z głównym PD ?

Dziękuję

Kształt płytki to warstwa obrysu (Dimensions w Eaglu). Nic więcej nie trzeba robić, tylko wybrać "nietypowy kształt płytki" i wyliczyć ile będzie frezowania.

Nastawy dopierałem eksperymentalnie, mając przed oczami uproszczoną "odpowiedź skokową", takie moje debugowanie. Miałem trochę szczęście, bo szybko wstrzeliłem się w dobre nastawy. Mimo długich prób nie udało mi się później uzyskać nic lepszego. Mam jednak w planach za jakiś czas zrobić to od nowa, teoretycznie.

Regulator PD dąży do bycia na linii i na tej podstawie podaje wartość zmiany jaką należy przekazać na napęd. Wartość ta zostaje (przykładowo) odjęta od prędkości docelowej robota i podawana na regulator lewego silnika, a do regulatora prawego silnika podawana jest wartość po dodaniu zmiany do prędkości docelowej robota. Trochę zagmatwałem, ale mam nadzieje, że zrozumiesz Inny podejściem, byłby osobny regulator dla translacji i osobny dla rotacji, ale to są również plany na przyszłość.

treker wrote:

Nie rozumiem zbytnio Twoich sugestii, a cała moja konstrukcja niby czym jest, jak nie samoróbką?

Sponsorzy prawdopodobnie oczekują, że zrobisz z ich podzespołów a nie konkurencji, chyba że liczy się tylko logo wrzucone później na obudowie.
Tak czy inaczej w TME nie mieli MPU6050 i sciągałem z innych firm

Quote:

Phrase "mpu6050" given by you has not been found.

treker wrote:

Swego czasu ktoś próbował uruchomić robota na BLDC, jednak projekt utknął właśnie na sterowaniu silnikami przy małych prędkościach.

No bo może próbował sterować silniki BLDC ale w trybie BackEMF bez halotronów, czy enkoderów optycznych, wtedy być może ich charakterystyka nie byłaby optymalna do wygrywania z innymi przy takich zabawach, podczas gdy w RC przy kręceniu śmigła na kilka tysięcy RPM spokojnie dadzą radę i to nie ma znaczenia.

To że ktoś próbował i mu się nie udało, nie znaczy że się nie da, tyle że tutaj trzeba optymalizować pod względem masy i niezawodności jak chce się w turnieju wygrywać, więc czasami lepiej nie zmieniać za bardzo tzw. "winning game" jak to wystarcza do pokonania konkurencji

treker wrote:

Regulator PD dąży do bycia na linii i na tej podstawie podaje wartość zmiany jaką należy przekazać na napęd. Wartość ta zostaje (przykładowo) odjęta od prędkości docelowej robota i podawana na regulator lewego silnika, a do regulatora prawego silnika podawana jest wartość po dodaniu zmiany do prędkości docelowej robota. Trochę zagmatwałem, ale mam nadzieje, że zrozumiesz Inny podejściem, byłby osobny regulator dla translacji i osobny dla rotacji, ale to są również plany na przyszłość.

Czy dobrze rozumiem, że wartość podawana na PIDy to po prostu domyślna wartość prędkości robota (jaką sobie wybierasz np pilotem) + uchyb PD ze znakiem? Czy też prędkość jest kontrolowana w jakiś sposób adaptacyjny do aktualnego przebiegu trasy? Np. "nie było zakrętów od 0,5s więc można zacząć przyspieszać".

I jeszcze jedno: ze względu na zastosowanie mostków H rozumiem, że w jakichś ekstremalnie ostrych zakrętach jeden z silników może na chwilę zacząć obracać się w drugim kierunku?

Zdradź jeszcze na jakiej częstotliwości pracuje oscylator w tym STMku? I jak użycie 3 regulatorów + pozostała część kodu go obciąża? Pisałeś "goły" kod obsługi w reżimie RealTime czy użyłeś jakiegoś OS'a np. FreeRTOS?

mirek_zaf wrote:

Sponsorzy prawdopodobnie oczekują, że zrobisz z ich podzespołów a nie konkurencji, chyba że liczy się tylko logo wrzucone później na obudowie.
Tak czy inaczej w TME nie mieli MPU6050 i sciągałem z innych firm

Akurat układy z firmami, które mi pomagały mam bardzo partnerskie. Nie miałem nacisków na stosowanie konkretnych rozwiązań. Miałem wybierać to, co pozwoli mi na dobre osiągnięcia.

Dzięki ogólnie za podsunięcie tego tematu. Pewnie za jakiś czas zagłębię się bardziej w BLDC.

tehaceole wrote:

Czy dobrze rozumiem, że wartość podawana na PIDy to po prostu domyślna wartość prędkości robota (jaką sobie wybierasz np pilotem) + uchyb PD ze znakiem?

Tak, dokładnie.

tehaceole wrote:

Np. "nie było zakrętów od 0,5s więc można zacząć przyspieszać".

To, że nie było zakrętów od 0.5s nie oznacza, że będzie teraz prosta. Pracuje nad takimi rozwiązaniami, jednak wymagają one zdecydowanie bardziej rozbudowanych algorytmów, niż proponowany.

tehaceole wrote:

ze względu na zastosowanie mostków H rozumiem, że w jakichś ekstremalnie ostrych zakrętach jeden z silników może na chwilę zacząć obracać się w drugim kierunku?

Tak, oczywiście. Szczególnie przy zakrętach pod kątem prostym.

tehaceole wrote:

Zdradź jeszcze na jakiej częstotliwości pracuje oscylator w tym STMku? I jak użycie 3 regulatorów + pozostała część kodu go obciąża? Pisałeś "goły" kod obsługi w reżimie RealTime czy użyłeś jakiegoś OS'a np. FreeRTOS?

Nie jest to urządzenie do produkcji masowej, więc mogłem sobie pozwalać na dużo. STM pracuje po prostu z maksymalną prędkością tj. 72MHz. Nie mierzyłem obciążenia procesora, ale dodawałem na próby jeszcze sporo do tego (typu równoległe wysyłanie ramek danych) i nadal nie było problemów. Główne regulatory wywoływane są co 1,5-2ms. W planach mam użycie OS'a, jednak w chwili obecnej nie ma tam zaimplementowanego żadnego systemu.

Interesuje mnie jeszcze jedna kwestia: czujniki umieszczone są na przedniej płytce, tylna to "przedział mocy". Czy jest jakaś krytyczna odległość pomiędzy płytkami której niezachowanie doprowadziłoby do dziwnego zachowania robota? Nie wiem czy rozumiesz co mam na myśli... Generalnie im krótsze "ramię" tym delikatniejsza reakcja konstrukcji na zmianę prędkości obrotowej kół. Wiem, że teoretycznie po to są regulatory pid żeby same zadbały o wszystko (przy odpowiednich nastawach). Jednak ciekawi mnie to czy robiłeś tego typu eksperymenty i jak one wpływają na pracę całego urządzenia.

Krytycznych raczej nie ma. Każdy konstruktor trzyma się swoich racji. Dłuższe ramie daje "więcej czasu" dla napędu do wyrównania położenia przy mocnych zakrętach. Ma to swoje wady i zalety (w końcu machamy pewną masą na ramieniu - spora bezwładność).

Jednak nie wiedziałem jeszcze nigdy szybkiego lf'a z czujnikami blisko silników. Bardzo ciężko wysterować takiego robota. Wiem, bo testowałem - jak widzisz w mojej konstrukcji taka zmiana to moment

tehaceole wrote:

Wiem, że teoretycznie po to są regulatory pid żeby same zadbały o wszystko (przy odpowiednich nastawach).

Przecież nie tylko PID są używane do sterowania, bo stosuje się jeszcze logikę rozmytą, czasami nawet sieci neuronowe zaimplementowane w FPGA.
Nie przeceniałbym możliwości PID'ów, bo często trzeba po prostu bardziej skomplikowany algorytm zastosować jak np.z fuzją sensorów, żeby taki niesamowity efekt uzyskać jak tutaj

Jadza po namalowanej prostej po ziemi przy tym to dziecinada.

mirek_zaf to już prawie jak Terminator =D Oooostra zabawa

treker wrote:

Jednak nie wiedziałem jeszcze nigdy szybkiego lf'a z czujnikami blisko silników. Bardzo ciężko wysterować takiego robota. Wiem, bo testowałem - jak widzisz w mojej konstrukcji taka zmiana to moment

Zaskoczyłeś mnie. Wydawało mi się, że ze względu na bezwładność całego układu prościej jest dać czujnik bliżej osi silników. Jednak z drugiej strony (jak się dłużej zastanowić) tak jak mówisz - więcej czasu na zjechanie z uchybem do zera. Człowiek codziennie uczy się czegoś nowego

Krokiem dalej byłoby długie ramie z 2-4 czujnikami, które ma własny napęd i samo śledzi linie (obracając się w lewo/prawo) dopiero, gdy ramie znajdzie linie cała reszta robota próbuje mu dorównać.

Świetny projekt!
Zdradzi kolega gdzie kupił poliuretan na odlanie oponek?

Dziękuję

struzyn_19 wrote:

Zdradzi kolega gdzie kupił poliuretan na odlanie oponek?

Niestety, ale to jest chyba jedyna "tajemnica", której na chwilę obecną jeszcze nie chcę zdradzać. Dużo czasu poświęciłem na testy i wybranie najlepszego materiału oraz odpowiednich jego propotcji

LineFollower to nie moja kategoria. Ja narazie bawie się w minisumo. Aktualnie mam oponki odlane z silikonu formierskiego (chyba 19 w skali Shore'a) przyczepnośc jest zadowalająca ale zgodnie z przeznaczeniem silikonu formierskiego zupełnie nie chce przylegać do felgi ani wejść w kontakt z klejami które sprawdzałem. Wydaje mi sie, że na polskich stronach nie znalazłem poliuretanów ;/
A Roboxy juz lada moment

Tak, to prawda silikony nie chcą przywierać do felg. Dzień przed Roboxy jest jeszcze TTR

A czy w regulaminie jest wymagana stała prędkość ?

Bo może udałoby Ci się wykombinować takie coś że :
Jazda po prostej jest z prędkością bardzo szybką, a kiedy robot wyczuje nawet lekkie zakrzywienie linii (zakręt) szybko zwalnia do danej prędkości. Potem znów przy prostej linii przyśpiesza. Sądzę że dałoby to dużą przewagę

Nie jest wymagana stała prędkość. Twój pomysł jest dobry i taki efekt da właśnie mapowanie. Niestety nie jest możliwe tak proste rozwiązanie jakie proponujesz. Jazda po prostej, wcale nie jest "jazdą po prostej" natomiast zwalnianie na zakrętach (jeśli nie będzie gwałtowne) nie da efektów - zwolnimy praktycznie dopiero za zakrętem (kwestia pędu).

Rozwiązanie takie powodowałoby dziwne zrywy i przyhamowania w miejscach, w których byśmy się tego nie spodziewali.

A czy za hamulec nie mógło by robić "puszczenie" odwrotnego napięcia tj. zamiana biegunow na silniku ?

Dodano po 2 [minuty]:

Pytam bo sam chętnie zaczął bym na zimę robić takie roboty chociażby dla frajdy bo atmege mam, programator wiec dużych kosztów nie poniose

Mógł i robi tylko częste manewry tego typu są szkodliwe dla silników oraz sprawiałyby, że jazda nie będzie płynna. Twój mechanizm hamował by również robota w miejscach, w których byś się tego nie spodziewał. Wiadomo jak bywa z teorią w praktyce

Zachęcam do budowy robotów, w Internecie można znaleźć ogrom informacji na ten temat, również w języku polskim.

A ta "antenka" to od czego ?

Od modułu Bluetooth, który był tam podczas pierwszych testów i debugowania.

Wszystko na ten temat znajdziesz w dokumentacji AS5040, są tam również podane dedykowane magnesy o odpowiednim rozłożeniu biegunów. W standardowej aplikacji uzyskujesz rozdzielczość, z tego co pamiętam, 0.35 stopnia. Czyli 1024 impulsy na jeden obrót magnesu.

Radzio M. wrote:

treker wrote:

Wszystko na ten temat znajdziesz w dokumentacji AS5040, są tam również podane dedykowane magnesy o odpowiednim rozłożeniu biegunów. W standardowej aplikacji uzyskujesz rozdzielczość, z tego co pamiętam, 0.35 stopnia. Czyli 1024 impulsy na jeden obrót magnesu.

Czyli dla byle jakiego magnesu, załóżmy neodymowy mam gwarantowane 1024 impulsy?

Nie kolego, przeczytaj kartę katalogową i dokładnie czytaj posty. Są do tego specjalne magnesy.