[Teoria] By jeździć szybciej

[sam.podolsky]

Długo zwlekałem ze startem w turniejach. Pierwszy był Wrocław w zeszłym roku na którym zapłaciłem frycowe. Dalej był Wiedeń gdzie zająłem 6 miejsce w eliminacjach i odpadłem w ¼ finału. Potem Robo3Dvision w Gdańsku, na którym w eliminacjach uplasowałem się na pierwszym i drugim miejscu, ostatecznie kończąc na pierwszym i czwartym. Nazywam się Sławek Chełmiński, moje roboty to Etiopczyki.

Tekst podzieliłem na kilka akapitów, z których każdy porusza inne zagadnienie robota. Niektóre rzeczy wydają mi się dość oczywiste, więc piszę tylko o wybranych. Nie jest to tutorial, więc zakładam że mam pełną dowolność. Artykuł adresowany jest do osób mających już jakieś doświadczenie w lf.

Konstrukcja mechaniczna

Zwycięzca Robot Challenge 2010 R555 to bardzo lekki dwukołowiec, ze ślizgaczem zamontowanym przy czujnikach daleko z przodu, podczas gdy piekielnie szybki litewski 2fast4you o podobnej konstrukcji jest znacznie większy i bardzo ciężki. Przegubowy Wonsz, zbudowany przez chłopaków z Wrocławia nie dał nikomu szans na Robotic Arena 2009. Nasuwa się więc pytanie, co tu wybrać? Na szczęście nie ma znaczenia; nie istnieje konstrukcja, którą nazwalibyśmy złotym środkiem. Budując swoje roboty zdecydowałem się na dwa koła napędzane różnicowo oraz ślizgacz zamontowany na czujnikach wysuniętych do przodu. Wydaje mi się, że dla tej konstrukcji następujące czynniki mają duże znacznie:

• - bardzo nisko położony środek ciężkości, nieznacznie przesunięty ku przodowi względem osi przechodzącej przez środki kół; zapewni to trzymanie się robota na zakrętach oraz wyeliminuje podskoki na starcie
  
• - im szerszy rozstaw kół tym robot stabilniej będzie poruszał się na zakrętach i nie wywróci się na łączeniach płyt; z drugiej strony zwiększanie rozstawu prowadzi do spowolnienia skręcania, więc by robot był bardzo zwrotny rozstaw powinien być jak najmniejszy; trzeba to jakoś wypośrodkować
  
• - odpowiednia odległość pomiędzy osią silników a czujnikami z przodu; z mego doświadczenia wynika, że powinna ona być nieznacznie większa od rozstawu kół
  
• - robot musi przejeżdżać łączenia płyt, które czasem tworzą nierówności nawet do 3 mm; nie wziąłem tego pod uwagę w swojej pierwszej konstrukcji i niestety na Robotic Arena 2009 dwa razy utknąłem na nierównościach

Silniki

Stosowałem DC, chętnie zobaczę lf na bezszczotkowych albo korkowych. Z tymi drugimi problem polega na tym, że znacznie tracą moment przy zwiększaniu obrotów. Można to rekompensować np. przez zwiększanie średnicy kół, co za tym idzie wymagana mniejsza prędkość obrotowa wału dla tej samej prędkości robota a na wale większy moment; ten temat jeszcze przede mną.

Przy silnikach DC pojawia się problem. Opiszę go na przykładzie swoich konstrukcji. Wyobraźmy sobie, ze stawiamy naszego robota na podłogę, po czym na jeden silnik dajemy maksymalne napięcie a na drugi nic. O dziwo nienapędzane koło nie stoi w miejscu ale bardzo wolno się porusza, robot nie zatacza kół o środku przechodzącym przez punkt styku koła nienapędzanego i podłogi. Zjawisko to się potęguje przy jeździe robota, gdyż dochodzi jego bezwładność. Można temu przeciwdziałać dając np. małą wartość napięcia na ten silnik o przeciwnej wartości, na tyle małą by koło się nie obracało w stronę przeciwną ale na tyle dużą by stało w miejscu. Rozwiązanie to można zastosować do gwałtownych skrętów (gdy jedno koło ma stać w miejscu), ale do płynnej regulacji już nie. Możemy zatem zastosować enkoder i kontrolować ilość obrotów wału silnika – rozwiązanie dość skomplikowane jak na tej klasy robota, choć moim zdaniem ciekawe. Nie stosowałem. W hiszpańskim R555 przy zakrętach jedno z kół było przyspieszane na tyle mocno, że problem ten chyba nie występował. Świetne rozwiązanie Hiszpana! Zdziwił się, gdy mu powiedziałem, że ja koło hamuję, spytał się, po co tracić prędkość?

Tak było do zawodów w Gdańsku. Nadeszła więc pora, by przedstawić Wam mego kolegę Tomka Blukisa, w skrócie: genialny programista, w przeciwieństwie do mnie ułożony i spokojny i co najważniejsze ma dużo świetnych pomysłów. Bez niego żaden z moich robotów nie jeździłby tak szybko. Pomaga mi głównie przy programowaniu Atmeg. Podczas Robo3Dvision wpadł na doskonały pomysł, by na oś silników, przed nałożeniem kół, ponabijać paski taśmy izolacyjnej i delikatnie szczepić oś silnika z obudową. Co to daje? Silnik pracując na maksymalnym napięciu bez trudu pokonuje opór taśmy i kręci się z maksymalną prędkością. Taśma natomiast niweluje wpływ bezwładności robota, przy zakrętach o 90 stopni nie dając żadnego napięcia na jeden z silników koło stoi w miejscu. Koła kręcą się tak, jakbyśmy tego chcieli i nie ma niepożądanych zjawisk.

Tutaj warto wspomnieć o opcji Brake, która często występuje w gotowych mostkach H. Jej działanie można zobrazować poprzez zwarcie kablem na krótko wyprowadzeń silnika. Z tego co wiem, energia zgromadzona w cewce ma przeciwdziałać obrotowi rotora. Testowałem te rozwiązanie na różnych silnikach i na każdym efekt był mizerny. Gołym okiem nie byłem w stanie zaobserwować czy robot szybciej się zatrzyma przy odłączeniu napięcia od silnika czy poprzez zwarcie jego wyprowadzeń.

Sterowanie silnikami

Nie znalazłem lepszego źródła niż Intermediate Robot Building David Cook, rozdziały 9 i 10. Nie będę przepisywał książki. Autor wyczerpał temat zarówno sterowania opartego o tranzystory bipolarne jak i MOSFET, począwszy od prostych układów z jednym tranzystorem do sterowania jednokierunkowego, skończywszy na gotowych scalakach. Jeśli ktoś byłby zainteresowany by je przeczytać pomogę na pw.

Przy kupowaniu gotowych układów należy pamiętać o sprawdzeniu dopuszczalnych prądów, niby oczywiste a spotkałem się, że osoby nie wiedziały dlaczego im się kółka nie kręcą. A mostki już dawno były spalone. Popularne silniczki z Pololu HP 30 przy zablokowanych osiach potrafią pociągnąć sporo prądu.

Koła

Najlepiej jak najlżejsze i o jak najlepszej przyczepności. Często pojawiają się głosy, że im szersze opony tym większa przyczepność. Tarcie zależy od siły nacisku i od współczynnika tarcia pomiędzy materiałami a nie od pola powierzchnia styku koła z podłożem.

• Edit 30.08, odpowiedź dla użytkownika lukix
  
• Wydaje mi się, że chodzi tu o następujące zjawisko. Gdy chcemy przykleić klocek do stołu, lepiej posmarować go klejem nie w jednym punkcie ale na całej powierzchni. Przy stosowaniu materiałów, które są lepkie i nie jako łączą się chwilowo z podłożem, pewnie powierzchnia wpływa na jakość łączenia. Moim zdaniem, w oponach do kategorii sumo takie zjawisko występuje, ale w lf kleistych opon chyba się nie stosuje; osiągi pewnie by spadły.

Podobno najlepiej samemu wytoczyć i odlać materiał na oponę. To jeszcze przede mną. W pierwszym robocie stosowałem koła z Lego, później już Pololu 32 mm i Solarboticsa o podobnym rozmiarze (te drugie to chyba takie same jak są w Mobot dostępne). Kółka Pololu bardzo lekkie, felgi wykonane z plastiku, opona z bieżniekiem; te z Solarboticsa znacznie cięższe, felga z aluminium, troszkę szersza i opony silcki. Na kółkach z Pololu Etiopczyk osiągał czasy o 30% lepsze.

Wykrywanie linii

Temat na oddzielny artykuł. Używam transoptorów odbiciowych LTH 1650-01. Świetnie się sprawdzają. Odczyt analogowy poprzez komparatory, napięcie odniesienia ustawiane przez potencjometr w zależności od oświetlenia, w praktyce ustawiam raz po wlutowaniu potencjometru na płytkę i potem przez cały okres użytkowania nie ruszam. Wyjścia z komparatorów podpinam pod nóżki uC i odczytuję stan logiczny 0 lub 1. Nie ma sensu zajmować procesora na przetwornik ADC – odczyt cyfrowy to kupa roboty i nie wiem czemu niektórzy się na to decydują.

Edit 30.08, odpowiedź dla użytkownika Treker

Jak pokonywać zakręty proste? Jak dokonywać odczytu z czujników i w ogóle ilu czujników używać? Postaram się opisać, jak udało się nam rozwiązać te zagadnienia.

Na pierwszy rzut oka mogłoby się wydawać, że w ogóle im więcej czujników tym lepiej. A tak nie jest. Środek ciężkości tego zagadnienia położony jest zupełnie gdzie indziej. Największe znaczenie ma rozdzielczość z jaką jesteśmy w stanie odczytywać linię. Mam tu na myśli odległość między kolejnymi sąsiednimi czujnikami (co ile milimetrów mamy ułożone czujniki). Należy umieścić jak największą liczbę czujników na obszarze niewiele większym od szerokości linii której robot ma się trzymać. Chodzi o to, by robot mógł skorygować prędkości silników (tym samym położenie nad linią) możliwie najszybciej po zjechaniu z niej. Rozmieszczanie czujników np. co 2 cm nie ma sensu. Środek robota ma się ciągle znajdować nad środkiem linii, więc po co montować czujniki z dala od tego punktu? Zachęcam do tego, by na początku nie skupiać się w ogóle na kątach prostych (i ostrych), ale do testów przygotować bardzo szybką trasę (taką, na jakiej ścigamy się w Wiedniu, zdjęcia dostępne na stronie zawodów). Dopiero gdy uda się jeździć po trasie z ciasnymi zakrętami więcej niż 1m/s (średni czas przejazdu) warto przechodzić do kolejnych utrudnień.

Mając wąską linijkę czujników i zakręty proste pojawia się dość nieprzyjemne zjawisko (wystąpiło w Etiopczyk40, który nie był w stanie przejechać kątów prostych). Załóżmy, że robot jedzie prosto po czym mamy zakręt prosty w prawo. Robot zaczyna najeżdżać na zakręt i wyczuwa dużo czarnego pod prawymi czujnikami. Koryguje swój tor, po czym następuje feralny moment w którym wszystkie czujniki znajdują się nad czarną linią. Pełna para na oba silniki i Etiopczyk40 wyskakiwał z zakrętu. Nawet człon różniczkujący tutaj nie pomagał. Jak tego unikać?

Wydaje mi się, że warto mocować dodatkowe czujniki w znacznej odległości od środka (np. po dwie sztuki na każdą ze stron), które by w takim momencie były wykorzystywane. Nasuwa się chyba pewna niespójność. Najpierw piszę, by dawać czujniki gęsto w środku, a teraz że trzeba dać jeszcze na końcach? Czemu zatem nie dać szerokiej linijki czujników bez żadnych przerw? Powód jest dość prosty. Gęsto rozmieszczone czujniki przy linijce szerokości 15 cm to ponad 30 czujników. Jak to obsłużyć? - liczba komparatorów, ew. wejść ADC!, odczyt z 30 bitów a nie np. 8 itd. – niepotrzebnie i duże komplikacje, spowolnienie działania programu.

W Etiopczyku zakręty proste pokonywane są na PD. Jest to możliwe przy zastosowaniu patentu z taśmą na oś silników, by negatywne zjawiska o których pisałem w artykule nie wystąpiły. Wtedy gdy skrajne czujniki mają pod sobą czarną linię, odpowiednie koło staje w miejscu, drugie się kręci i robot obraca się prawie w miejscu. We wcześniejszych wersjach algorytmu (przed odkryciem taśmy), gdy skrajne czujniki się zapalały, program ustawiał powiedzmy flagę, która sygnalizowała ciasny obrót i by jedno z kół stało w miejscu, dawaliśmy na nie napięcie o przeciwnej polaryzacji – pisałem o tym wcześniej. W Etiopczyku zamieściliśmy 7 czujników. Początkowo rozmieszczone były w myśl zasady, ze im bliżej środka tym gęściej. Nie było to chyba takie głupie, ale czujniki ulokowaliśmy zdecydowanie za rzadko – w związku z tym w Wiedniu przelutowywałem te skrajne by znalazły się bliżej środka. Otrzymaliśmy linijkę 5 czujników szerokości 42 mm, i korzystaliśmy tylko z pięciu czujników umieszczonych blisko siebie – w Wiedniu w zwykłym lf nie ma kątów prostych.

Jak odbywa się odczyt czujników? Mamy bajt składający się z ośmiu bitów. Każdy bit odpowiada jednemu czujnikowi. Bit przyjmuje wartość logiczną 0 lub 1 w zależności od tego, czy pod nim czarno czy biało. Do tego mamy tablicę czujników z nazwijmy to punktami (każdy czujnik ma przypisane punkty np. dla pięciu czujników 0 10 20 30 40, przy czym 20 to środek). Sumujemy liczbę punktów z danego odczytu (tak jakbyśmy maskowali te czujniki które się nie świecą) i liczymy średnią. Znając wartość średnią wszystkich punktów wiemy gdzie znajduje się robot. Naprawdę zachęcam do lektury manuala Pololu 3pi – tam jest wszystko opisane.

Zasilanie

Podobnie jak przy sterowaniu silnikami temat dobrze znany. Wydaje mi się, że nie warto stosować przetwornic, gdyż elementy liniowe są tańsze i lżejsze a energię w lf można tracić. Przejazd z reguły trwa kilkanaście sekund. Jako baterie sugeruję pakiety Li-Pol, duża wydajność prądowa, szeroki wybór, można znacznie ograniczyć wagę poprzez zmniejszanie pojemności.

W ostatniej konstrukcji nie dałem kondensatora między Vcc i Gnd Atmegi32. Robot jeździł i czasem się zawieszał, stawał i musiałem mu odłączyć zasilanie – dopiero to pomagało. Za nim zrozumiałem, iż jest to spowodowane brakiem tego kondensatora, wylutowałem większą część elementów i straciłem ze dwa dni pracy. Na studiach starszy pan w laboratorium z układów cyfrowych mówił, że kondensatory muszą być dawane przy każdym scalaku. Szkoda, że nie doceniłem jego słów. Miał rację.

PID?

To słowo bardzo często pada z ust początkujących w lf. A PID zbawieniem nie jest. Ze względu na krótkie przejazdy stosowaliśmy z Tomkiem tylko człon proporcjonalny i różniczkujący. Nie będę omawiał idei sterowania PID gdyż jest doskonale omówiona w manualu do robota 3pi Pololu. Krok po korku wraz z implementacją. Wystarczy skopiować. Wartości wzmocnienia członu proporcjonalnego i stała czasowa członu różniczkującego przysparzają o zawrót głowy. Nie spotkałem by ktoś w lf ustawiał te parametry metodą inną niż „prób i błędów”. Tutaj narasta jeszcze inny problem. W miarę upływu czasu spada wartość napięcia na akumulatorach i zarazem PD/PID się rozregulowuje. Ten problem też trzeba rozwiązać. Należy także pamiętać by człon różniczkujący wyliczać nie z każdym obiegiem pętli, ale tylko co jakiś czas. Bazuje on na zmianie wartości odczytanej z czujników. Narasta więc pytanie jak sterować naszym robotem? Mam tutaj pewne pomysły, ale to zostawmy na inną okazję.

Mózg

Jaki uC stosujesz nie ma większego znaczenia. Zachęcam do przeanalizowania algorytmu pod względem czasu wykonywania i jego maksymalnym uproszczeniu. Tomek wykonał kawał dobrej roboty. W pierwszym robocie cały program wykonywał się w 20ms, obecnie mamy z odczytem z ośmiu czujników, wyliczeniem PD, wysterowaniem mostka na silniki poniżej 0.2ms. Jakie to ma znacznie? Jadąc 1m/s dostajemy 1mm/ms. Czyli całkiem spore. W pierwszym przypadku robot podejmuje decyzje co 2 cm, w drugim co 0.2 mm. Jeśli w Wiedniu różnica między dwoma najwyższymi miejscami liczona jest w setnych częściach sekundy, takie rachunki chyba mają sens. To co spowalnia, to cyfrowy odczyt przez ADC, PD liczone na floatach (w szczególności na Atmegach!, trzeba się przesiąść na chary i inty) oraz częstotliwość taktowania uC.

Prostota

Nie wiem czemu w Polsce, w szczególności w środowiskach akademickich panuje przekonanie, iż im bardziej skomplikowane rozwiązanie danego problemu tym ciekawiej. Im mniej ludzi jest je w stanie zrozumieć/zaimplementować tym ma wyższą rangę. A najlepsze pomysły to te najprostsze, które wymagają najmniej pracy i dają najlepsze efekty. Zachęcam do prostoty!

Chciałbym bardzo podziękować firmie Satland Prototype za wsparcie. Wszystkie moje płytki to ich dzieło. Nawet nie gniewają się na moje strasznie szybkie terminy – z reguły przed turniejami jestem w niedoczasie.

Ten artykuł nie ma praw autorskich. Możecie kopiować bez mojej zgody co chcecie.

Opis moich konstrukcji postaram się zamieścić na dniach.

[KD93]

Super, że zechciałeś się podzielić swoimi doświadczeniami, pewnie ciężko zdobytymi. Pomimo, że nie ma tu grafik, wzorów i obliczeń uważam że jest to jeden z najlepszych artykułów w tym konkursie. Szczególnie moją uwagę zwrócił fragment o problemie w sterowaniu silnikami DC, myślałem że u mnie wynika to z jakiejś wady konstrukcyjnej a okazało się że więcej osób ma taki problem.

[Treker (Damian Szymański)]

Pamiętam, że w Gdańsku była też prowadzona krótka dyskusja na temat pokonywanie zakrętów pod kątem prostym, z tego co pamiętam to Twoje robot pokonują je również tylko na PD, tak? Nie macie do tego żadnych podprogramów?

Na jakiej zasadzie ustalacie aktualną pozycję jaką podajecie do PD? Macie na sztywno wypisane możliwe stany czujników i w case'ach ustalacie z tego pozycje, jeśli tak to jak macie rozpisane tutaj kąty proste?

Jak gęsto masz ułożone czujniki? Planujesz używanie większej ilości niż 8?

No to by było na tyle 😅

Mam jeszcze masę pytań (i pewnie nie tylko ja), ale zostawię je na później.

[lukix]

Często pojawiają się głosy, że im szersze opony tym większa przyczepność. Tarcie zależy od siły nacisku i od współczynnika tarcia pomiędzy materiałami a nie od pola powierzchnia styku koła z podłożem.

Rok temu się właśnie nad tym zastanawiałem i znalazłem w książce z fizyki że w przypadku

materiałów elastycznych(np. guma) powierzchnia ma znaczenie. 💡

[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

[Sabre]

Tak prawdę mówiąc spodziewałem się czegoś innego po twoim artykule. Wszystkie zawarte w nim informacje to są tak naprawdę podstawy, do których albo dochodzi się osobiście przy budowie kolejnego lfr'a, albo wyczytuje się je z innych tematów. Dla kogoś kto buduje pierwszego lfr'a tak naprawdę te informacje nie są do końca przydatne, nie sądzę, że pierwsza konstrukcja osiągnie prędkości, przy których wszystko to co napisałeś jest ważne. Nie mniej warto wyrabiać sobie pewne nawyki projektując każdego robota.

[sam.podolsky]

Odpowiedzi na Wasze pytania będę zamieszczał w artykule. Wydaje mi się, że warto mieć wiedzę w jednym miejscu.

[TIMONek]

Odpowiedzi w artykule to nie jest dobry pomysł. Dla mnie powoduje to nie mały chaos.

Napisałeś, że nie rozumiesz po co stosować przetwornik ADC do wykrywania linii. Wiele osób przyjmuje zasadę - prosta elektronika, bardziej skomplikowany program. Sam pisałeś o optymalnym pisaniu kodów, a na prawdę przy dobrym kodzie czas potrzebny na odczyt z przetwornika potrafi być prawie pomijalny. W ten sposób nie potrzebujemy dokładać nowy elementów, następnie kalibrować. Ba, nie odczytując linii na zasadzie 0/1 możemy dokładniej ustalać położenie linii, a wtedy działanie algorytmu może być płynniejsze. Ponadto przy ADC istnieje możliwość automatycznej kalibracji czujników - a także kalibracja już w czasie trwania przejazdu.

Gołym okiem nie byłem w stanie zaobserwować czy robot szybciej się zatrzyma przy odłączeniu napięcia od silnika czy poprzez zwarcie jego wyprowadzeń.

Tu mnie zdziwiłeś. Ja widziałem wyraźny wpływ zwarcia wyprowadzeń silnika przy zwarciu wyprowadzeń - szczególnie w opisanej na forum konstrukcji sumo. Być może w przypadku tak mały silników jak używane są w lf to nie jest widoczne.

Zdziwiłeś mnie też, że osiągałeś lepsze czasy na kółkach z pololu - one się masakrycznie ślizgają hmm.. chyba, że wykorzystujesz jakoś to zjawisko.

Silnik pracując na maksymalnym napięciu bez trudu pokonuje opór taśmy i kręci się z maksymalną prędkością.

Nie zdziera Ci się taka taśma? Jednak taki silnik ma swoją prędkość.

Szkoda, że nie wkleiłeś zdjęć swojego robota dla podparcia swoich przykładów. Tak artykuł jest co najwyżej przeciętnych. Porusza kwestie o których mnóstwo osób raczej już wie. Zero rewolucji 🙂

[KD93]

Tak artykuł jest co najwyżej przeciętnych. Porusza kwestie o których mnóstwo osób raczej już wie.

A nie zostały dotychczas zebrane w jedną w miarę spójną całość. Poza tym ciekawe ile osób byłoby skłonnych napisać dla ogółu wiedzę zdobytą samemu podczas budowy robotów. Gdzieś pojawiają się jakieś szczątki takiej wiedzy, ale nie zaobserwowałem żeby ktoś wyłożył taką ilość własnego doświadczenia.

W tym artykule także rewolucji nie widać, a jakoś nikt nie zwrócił uwagi że jest przeciętny.

[prokto]

Hej,
miałem tutaj napisać spory wywód na temat tarcia i przyczepności, ale darowałem sobie jak zacząłem czytać to co napisałem... szersze opony zwiększają przyczepność poprzez poprawę kontaktu powierzchni, przy wąskiej oponie, jeżeli trafi się mała nierówność przyczepność się gwałtownie zmienia (z moich doświadczeń i przemyśleń).

Artykuł uważam za ciekawy, z jednej strony ogólny, a z drugiej porusza wiele tematów. Plus za autora, za podzielenie się własnymi spostrzeżeniami i bagażem doświadczeń.

Dla tych co uważają artykuł za przeciętny, zauważcie, że jak dotąd roboty Sławka są lepsze (szybsze) od Waszych. Sam uważam go za głównego i motywującego przeciwnika 🙂. Większość robotów które widziałem nazwałbym przeciętnymi, Sławek mocno mnie zaskoczył swoim mocnym entree w Wiedniu 😃.

Pozdrawiam serdecznie, konstruktor "szuflady".

Będziesz we Wrocławiu?

[sam.podolsky]

Postaram się przygotować jakąś niespodziankę 😃 A propo tego co napisałem w artykule. Szuflada jest rozmiarami dość wielka, ciężka, ma dużo czujników i jest jednym z najszybszych lf w Polsce. Nie ma jedynego słusznego przepisu na lf.

[Treker (Damian Szymański)]

Należy także pamiętać by człon różniczkujący wyliczać nie z każdym obiegiem pętli, ale tylko co jakiś czas.

Dobierasz jakoś co ile pętli pobierasz człon różniczkujący, czy ustawiasz jakąś liczbę i dostosowujesz do niej współczynniki?

Dzięki za poprzednie odpowiedzi.

[sam.podolsky]

Człon można wyliczać na przerwaniu co precyzyjnie odmierzony przedział czasu. Z mojej praktyki wynika czas od kilku do kilkunastu milisekund w zależności od tego jak szybko jeździ Twój robot. Człon różniczkujący bada różnicę pomiędzy kolejnymi odczytami - jeśli będziesz go wyliczał ze zbyt mały odstępem czasu nie będzie niczego wnosił, gdyż on coś wnosi gdy zmienia się sygnał z czujników - trzeba dać czas robocikowi by ta zmiana nastąpiła.

[Skipper]

Witam serdecznie, bardzo podoba mi się artykuł. Fajnie by było jakbyś zaprezentował pozostałe swoje konstrukcje w odpowiednim dziale, chyba że to jakaś tajemnica 🙂

Co do artykułu to:

Sumujemy liczbę punktów z danego odczytu (tak jakbyśmy maskowali te czujniki które się nie świecą) i liczymy średnią. Znając wartość średnią wszystkich punktów wiemy gdzie znajduje się robot. Naprawdę zachęcam do lektury manuala Pololu 3pi – tam jest wszystko opisane.

Od dwóch dni wertuje manuala, ba nawet ściągnąłem bibliotekę i przejrzałem ich podprogramy do odczytu linii i niestety za cholerę nie umiem tego zrozumieć, jeśli byłaby szansa nieco rozwinąć tą myśl to bardzo bym prosił 🙂

Gratuluje sukcesów 🙂

[sam.podolsky]

int poz_czujnikow[7] = {0, 20, 40, 60, 80, 100, 120};

unsigned int czytaj_czujniki(){
//bity port PA(x)=1 gdy czujnik widzi biała linię
unsigned int wynik = 0;
wynik |= PA(0) ? _BV(0) : 0;		
//ustawia _BV(0) gdy PA(0)=1, gdy PA(0)=0 to _BV(0)=0
wynik |= PA(1) ? _BV(1) : 0;
wynik |= PA(2) ? _BV(2) : 0;
wynik |= PA(3) ? _BV(3) : 0;
wynik |= PA(4) ? _BV(4) : 0;
wynik |= PA(5) ? _BV(5) : 0;
wynik |= PA(6) ? _BV(6) : 0;
wynik ^= 0x7F;		//odwraca bity nr 0..6
return wynik;
}

int licz_odchylke(int czujniki){	
int wynik;
int ilosc_zapalonych = 0;
int i;	
int suma = 0;	
for(i = 6; i >= 0; i--){
	int bit_czujnika = 1 << i;
	if(czujniki & bit_czujnika){
		suma += poz_czujnikow[i];	
		ilosc_zapalonych++;


	}			
}
wynik = suma / ilosc_zapalonych - poz_czujnikow[3];
return wynik;
}