Skocz do zawartości

Przeszukaj forum

Pokazywanie wyników dla tagów 'STM32'.

  • Szukaj wg tagów

    Wpisz tagi, oddzielając przecinkami.
  • Szukaj wg autora

Typ zawartości


Kategorie forum

  • Elektronika i programowanie
    • Elektronika
    • Arduino, ESP
    • Mikrokontrolery
    • Raspberry Pi
    • Inne komputery jednopłytkowe
    • Układy programowalne
    • Programowanie
    • Zasilanie
  • Artykuły, projekty, DIY
    • Artykuły redakcji (blog)
    • Artykuły użytkowników
    • Projekty - DIY
    • Projekty - nasze roboty
    • Wiadomości
  • Pozostałe
    • Oprogramowanie CAD
    • Druk 3D
    • Napędy
    • Mechanika
    • Zawody/Konkursy/Wydarzenia
    • Sprzedam/Kupię/Zamienię/Praca
    • Inne
  • Ogólne
    • Ogłoszenia organizacyjne
    • Dyskusje o FORBOT.pl
    • Na luzie
    • Kosz

Szukaj wyników w...

Znajdź wyniki, które zawierają...


Data utworzenia

  • Rozpocznij

    Koniec


Ostatnia aktualizacja

  • Rozpocznij

    Koniec


Filtruj po ilości...

Data dołączenia

  • Rozpocznij

    Koniec


Grupa


Znaleziono 30 wyników

  1. Czołem, mam pewien problem. Czytając reference manuala STM'a nie do końca rozumiem jak uruchomić przetwornik analogowo-cyfrowy pisząc na poziomie Low Layer ( założeniem projektu jest nie korzystać z bibliotek HAL'a). Jestem początkujący w programowaniu "bez HAL", dlatego proszę o wyrozumiałość i o pomoc/rady. Ustawienia ADC jakie wygenerowałem przy użyciu Cube'a wyglądają następująco: static void MX_ADC1_Init(void) { LL_ADC_InitTypeDef ADC_InitStruct; LL_ADC_REG_InitTypeDef ADC_REG_InitStruct; LL_ADC_CommonInitTypeDef ADC_CommonInitStruct; LL_GPIO_InitTypeDef GPIO_InitStruct; /* Peripheral clock enable */ LL_AHB2_GRP1_EnableClock(LL_AHB2_GRP1_PERIPH_ADC); /**ADC1 GPIO Configuration PC0 ------> ADC1_IN1 PC4 ------> ADC1_IN13 */ GPIO_InitStruct.Pin = LL_GPIO_PIN_0|LL_GPIO_PIN_4; GPIO_InitStruct.Mode = LL_GPIO_MODE_ANALOG; GPIO_InitStruct.Pull = LL_GPIO_PULL_NO; LL_GPIO_Init(GPIOC, &GPIO_InitStruct); /* ADC1 interrupt Init */ NVIC_SetPriority(ADC1_IRQn, NVIC_EncodePriority(NVIC_GetPriorityGrouping(),0, 0)); NVIC_EnableIRQ(ADC1_IRQn); /**Common config */ ADC_InitStruct.Resolution = LL_ADC_RESOLUTION_12B; ADC_InitStruct.DataAlignment = LL_ADC_DATA_ALIGN_RIGHT; ADC_InitStruct.LowPowerMode = LL_ADC_LP_MODE_NONE; LL_ADC_Init(ADC1, &ADC_InitStruct); ADC_REG_InitStruct.TriggerSource = LL_ADC_REG_TRIG_SOFTWARE; ADC_REG_InitStruct.SequencerLength = LL_ADC_REG_SEQ_SCAN_DISABLE; ADC_REG_InitStruct.SequencerDiscont = LL_ADC_REG_SEQ_DISCONT_DISABLE; ADC_REG_InitStruct.ContinuousMode = LL_ADC_REG_CONV_SINGLE; ADC_REG_InitStruct.DMATransfer = LL_ADC_REG_DMA_TRANSFER_LIMITED; ADC_REG_InitStruct.Overrun = LL_ADC_REG_OVR_DATA_PRESERVED; LL_ADC_REG_Init(ADC1, &ADC_REG_InitStruct); LL_ADC_SetOverSamplingScope(ADC1, LL_ADC_OVS_DISABLE); ADC_CommonInitStruct.CommonClock = LL_ADC_CLOCK_ASYNC_DIV1; LL_ADC_CommonInit(__LL_ADC_COMMON_INSTANCE(ADC1), &ADC_CommonInitStruct); LL_ADC_EnableIT_EOC(ADC1); LL_ADC_DisableIT_EOS(ADC1); /**Configure Regular Channel */ LL_ADC_REG_SetSequencerRanks(ADC1, LL_ADC_REG_RANK_1, LL_ADC_CHANNEL_1); LL_ADC_SetChannelSamplingTime(ADC1, LL_ADC_CHANNEL_1, LL_ADC_SAMPLINGTIME_2CYCLES_5); LL_ADC_SetChannelSingleDiff(ADC1, LL_ADC_CHANNEL_1, LL_ADC_SINGLE_ENDED); } A ciało przerwania ADC tak: void ADC1_IRQHandler(void) { /* USER CODE BEGIN ADC1_IRQn 0 */ /* USER CODE END ADC1_IRQn 0 */ /* USER CODE BEGIN ADC1_IRQn 1 */ /* USER CODE END ADC1_IRQn 1 */ } Wstawiłem tylko wygenerowane fragmenty kodu, gdyż stwierdziłem że nie ma sensu wstawiać tu kodów wszystkich moich prób. Bardzo proszę o wskazanie mi, co mam gdzie wpisać, bądź jakich funkcji użyć, lub jeśli to nie problem napisać fragmenty uzupełniając powyższy kod, bo już sam nie wiem jak to mam zrobić. Za wszystkie odpowiedzi i pomoc bardzo dziękuję.
  2. Czołem koledzy, mam problem z Eclipse Version: Mars.2 Release (4.5.2) przygotowanego pod kurs STM32 F3 CUBE & HAL. Do programu wygenerowanego przez STM32CubeMX próbuję dołączyć własne pliki *.c i *.h source i header. Dodam, że robiłem takie rzeczy z powodzeniem dla Eclipse i AVR, nie przypominam sobie żadnych problemów. W tym wypadku ciągle dostaje błędy kompilacji m.in "no such file or directory" lub niewłaściwa liczba argumentów dla funkcji . Walczę z tym od kilku dni i mam wrażeniem, że nie będę potrafił prosto opisać moich problemów. Dlatego po prostu proszę was o wskazówkę. Jak właściwi załączyć do projektu CUBEMX w Eclipse pliki source i header *.c *.h zawierające moje własne funkcje. Dzięki za pomoc Zagadnienie rozwiązane, internety pomogły. http://www.openstm32.org/forumthread3284
  3. Witam, są to dopiero moje początki z STM32 Nucleo więc na wstępie proszę o wyrozumiałość. Posiadam model Nucleo 32 F042K6 oraz mostek L298n. Na mostku znajduje się 6 pinów ( ENA, In1, In2, In3, In4, ENB). Powiem na przykładzie arduino, gdy na ENA i ENB jest zworka prędkość jest albo 100% albo 0% w zależności od stanów. Gdy wyjmę zworki podłączałem te 2 piny do analogowych ( ENA, ENB), In'y do cyfrowych i wywoływałem funkcje w arduino: void forward(){ digitalWrite(in1, HIGH); digitalWrite(in2, LOW); analogWrite(ENA, 200); //wartosc od 100 do 255 digitalWrite(in3, HIGH); digitalWrite(in4, LOW); analogWrite(ENB, 200); } Było wszystko w porządku i właśnie o takie coś mi chodzi. Gdy znów wpiąłem zworki, podłączyłem 4 piny operujące stanami do Nucleo napisałem w STM Workbench, że silniki mają się kręcić do przodu oba też było dobrze: int main(void) { HAL_Init(); __HAL_RCC_GPIOB_CLK_ENABLE(); GPIO_InitTypeDef gpio; gpio.Pin = (GPIO_PIN_0 | GPIO_PIN_7 | GPIO_PIN_6 | GPIO_PIN_1); gpio.Mode = GPIO_MODE_OUTPUT_PP; gpio.Pull = GPIO_NOPULL; gpio.Speed = GPIO_SPEED_FREQ_LOW; HAL_GPIO_Init(GPIOB, &gpio); while (1) { HAL_GPIO_WritePin(GPIOB, GPIO_PIN_0, GPIO_PIN_SET); HAL_GPIO_WritePin(GPIOB, GPIO_PIN_7, GPIO_PIN_RESET); HAL_GPIO_WritePin(GPIOB, GPIO_PIN_6, GPIO_PIN_SET); HAL_GPIO_WritePin(GPIOB, GPIO_PIN_1, GPIO_PIN_RESET); } } Problem jest taki że nie mogę poradzić sobie z ustawieniem prędkości obrotowej w nucleo na tych dwóch pinach. Dodam że TIM2 Kanał 1 jest na pinie PA0 natomiast TIM2 kanał 1 jest na pinie PA6. Korzystałem z wielu poradników jednak w internecie nic konkretnego ( co byłoby dla mnie zrozumiałe ) nie znalazłem. Proszę o jakieś konkretne rozwiązania. Chciałbym sterować w zakresie mniej więcej takim jak arduino, albo najlepiej od 0 do 100.
  4. Mam pytanie dot. definicji(stm32h7xx_hal_gpio.h): #define GPIO_SPEED_FREQ_LOW ((uint32_t)0x00000000U) /*!< Low speed */ #define GPIO_SPEED_FREQ_MEDIUM ((uint32_t)0x00000001U) /*!< Medium speed */ #define GPIO_SPEED_FREQ_HIGH ((uint32_t)0x00000002U) /*!< Fast speed */ #define GPIO_SPEED_FREQ_VERY_HIGH ((uint32_t)0x00000003U) /*!< High speed */ Jakie one oznaczają wartości częstotliwości pracy portu GPIO dla płytki Nucleo-H743ZI?
  5. Warto może dodać odcinek o sygnałach zegarowych i procedurze uruchamiania mikrokontrolera. Treker // Posty zostały wydzielone z poniższego tematu:
  6. Witam serdecznie. Jestem początkującym w STM. Właśnie przechodzę z AVR. Chcę wysłać przez UART liczbę a dokładnie przekonwertować ją na stringa poleceniem itoa. Rok temu już to zrobiłem, ale w między czasie padł mi dysk i wszystko straciłem. Zrobiłem funkcję: void send_integer(uint8_t n){ char *s; itoa ( n, s, 10 ); send_string(s); } ale podczas kompilacji wywala mi błąd ..\Src\main.c:308:12: warning: 's' is used uninitialized in this function [-Wuninitialized] itoa ( n, *s, 10 );
  7. Witam. Jestem początkujący więc z góry proszę o łagodne potraktowanie. Mam gotowy układ sterownika do z STM32 pracującym w sterowniku do drona Walkera Runner 250 Advance F3 SP Racing. Po zmianie konfiguracji w Betaflight Configurator układ zawiesił się i stracił komunikację z kompem. Proszę o informację w jaki sposób zresetować układ żeby wgrać firmware jeszcze raz. Próbowałem zewrzeć styk nRST do masy i na zwartym podłączyć ale nie przyniosło skutków. Czy macie jakieś pomysły? Proszę też o informację czy do aktualnego sterownika CP210x... jest konieczne wykonanie jeszcze jakiś operacji żeby chip STM32 stał się widoczny dla programu programującego. Próbowałem DfuSeDemo oraz UsbUpgradeTool. dzięki [ Dodano: 06-07-2018, 14:56 ] dodaje zdjęcie układu:
  8. Witam serdecznie, jestem kompletnie nowy w temacie elektroniki i dopiero zaczynam z tym przygodę. Od jakiegoś czasu myślę nad tematem jakiejś prostej elektroniki, którą mógłbym zrobić na podanej w temacie płytce(narzucona odgórnie), ale nic nie przychodzi mi do głowy stąd mój post tutaj. Czy mógłby ktoś zasugerować mi jakiś pomysł na niezbyt zaawansowaną, acz też nie za prostą elektronikę którą mógłbym zrealizować na tej płytce? Do tej pory do głowy przyszedł mi tylko termometr, alkomat, zamek magnetyczny i to w sumie tyle. Czekam na jakiś odzew i z góry dziękuję
  9. Witam! Jestem początkujący, jeśli chodzi o zabawę z płytkami Nucleo, a można powiedzieć, że zostałem już rzucony na głęboką wodę. W tym semestrze na uczelni mam projekt z Układów Cyfrowych i Mikroprocesorów na takiej właśnie płytce. Razem z większością osób grupy zakupiliśmy płytkę F103RB, widziałem, że na stronie są kursy i poradniki krok po kroku związane z tą płytką, więc na pewno będzie to przydatne, jednak szukam pomysłu na coś bardziej rozbudowanego, niż zapalająca się dioda po naciśnięciu przycisku. Termometr (w jakiejkolwiek postaci) raczej odpada, bo moi znajomi już się na to rzucili. Myślałem o barometrze, wilgotnościomierzu lub nawet zegarze cyfrowym, tylko nie znam stopnia trudności tych rzeczy, ani też nie wiem za bardzo jak się za coś takiego zabrać, bo tak jak mówiłem, jestem zupełnie zielony. Prosiłbym o jakąś podpowiedź w sprawie pomysłów na powyższe projekty, albo nawet propozycje jakiś nowych przeze mnie nieopisanych. Z góry dziękuję za pomoc, będę bardzo wdzięczny!
  10. Witam serdecznie. Czy jest możliwość w Atolic TrueStudio utworzenia nowego projektu z całą biblioteką HAL bez użycia kreatora CubeMX? Wybierając File -> New -> C project, mam możliwość utworzenia projektu tylko z biblioteką StdLib, a chciałbym mieć pełen pakiet driverów HAL.
  11. Chce wykorzystać kod z artykułu wraz z przerwaniem TIM_IT_Update, problem w tym, że gdy mam zsetupowany kontroler przerwań NVIC, to program nie może wyjść z TIM2_IRQHandler() pomimo tego, że czyszcze flage przez IM_ClearITPendingBit(TIM2, TIM_IT_Update); Sam TIM2 działa bez zarzutu, i jestem w stanie migać diodą w pętli głównej programu, ale tylko gdy pominę setup NVIC w kodzie. Co może być powodem tego problemu? Kompilator? Program pisze pod STM32f103C8 na eclipsowym OpenSTM. /** ****************************************************************************** * @file main.c * @author Ac6 * @version V1.0 * @date 01-December-2013 * @brief Default main function. ****************************************************************************** */ #include "stm32f10x.h" void TIM2_IRQHandler() { if (TIM_GetITStatus(TIM2, TIM_IT_Update) == SET){ TIM_ClearITPendingBit(TIM2, TIM_IT_Update); if (GPIO_ReadOutputDataBit(GPIOC, GPIO_Pin_13)) GPIO_ResetBits(GPIOC, GPIO_Pin_13); else GPIO_SetBits(GPIOC, GPIO_Pin_13); } } int main(void){ GPIO_InitTypeDef gpio; TIM_TimeBaseInitTypeDef tim; NVIC_InitTypeDef nvic; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_GPIOB | RCC_APB2Periph_GPIOC | RCC_APB2Periph_GPIOD, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM2, ENABLE); GPIO_StructInit(&gpio); gpio.GPIO_Pin = GPIO_Pin_13; gpio.GPIO_Mode = GPIO_Mode_Out_PP; GPIO_Init(GPIOC, &gpio); TIM_TimeBaseStructInit(&tim); tim.TIM_CounterMode = TIM_CounterMode_Up; tim.TIM_Prescaler = 7200 - 1; tim.TIM_Period = 10000 - 1; TIM_TimeBaseInit(TIM2, &tim); TIM_ITConfig(TIM2, TIM_IT_Update, ENABLE); TIM_Cmd(TIM2, ENABLE); // nvic.NVIC_IRQChannel = TIM2_IRQn; // nvic.NVIC_IRQChannelPreemptionPriority = 0; // nvic.NVIC_IRQChannelSubPriority = 0; // nvic.NVIC_IRQChannelCmd = ENABLE; // NVIC_Init(&nvic); while (1) { int timerValue = TIM_GetCounter(TIM2); if (timerValue > 1000) GPIO_WriteBit(GPIOC, GPIO_Pin_13, Bit_SET); else GPIO_WriteBit(GPIOC, GPIO_Pin_13, Bit_RESET); } }
  12. Witam. Mam problem, ponieważ napięcie na pinach ma tylko około 1V. Tak samo nie da się zaświecić diody wbudowanej LD2. Zmierzyłem napięcie i np. na pinach GPIOC napięcie ma około 1V. Dodam, że wcześniej było normalnie i mogłem z nich zasilić zwykłego LEDa. Czy coś się usmażyło?
  13. Cześć Chciałbym dowiedzieć się jak programować stm32 w LL. Jak do tego podejść?
  14. Od niedawna eksperymentuję z układami STM32 przy wykorzystaniu bibliotek HAL, narzędzia STM32CubeMX oraz środowiska AtollicSTUDIO. Nie znaczy to jednak, że nie mam doświadczenia z mikrokontrolerami - od kilku lat hobbystycznie programuję AVR-y i PIC32, zdarzało mi się także zajmować m.in. starszymi układami z rodziny 8051. Przejście na rodzinę STM32 wydawało mi się początkowo łatwe i bezbolesne, jednak teraz natknąłem się na dziwnego i mocno specyficznego buga, którego przyczyny nie jestem w stanie namierzyć. Przechodząc do meritum: Przeportowałem arduinową bibliotekę do obsługi modułów DCF77. Przepisałem ją w C, usunąłem nawiązania do bibliotek Arduino, zastępując je funkcjami standardowej biblioteki C, usunąłem też kilka błędów. Wygląda na to, że biblioteka działa - to znaczy przy dobrych warunkach propagacyjnych (szczególnie wieczorem) odbiera wiarygodnie wyglądające timestampy. Ponieważ bity parzystości używane przez DCF77 nie są dostatecznym zabezpieczeniem, biblioteka używa kilka sposobów sprawdzania poprawności odebranego czasu. Między innymi porównuje go z czasem systemowym. W oryginale była do tego używana jakaś biblioteka Arduino, ja użyłem time.h. Wiązało się to z koniecznością zdefiniowania własnej wersji funkcji time(), zwracającej czas systemowy z RTC w formie timestampa: time_t time (time_t * timer) { RTC_TimeTypeDef timeStruct; RTC_DateTypeDef dateStruct; struct tm dstTime; HAL_RTC_GetTime(&hrtc, &timeStruct, RTC_FORMAT_BIN); HAL_RTC_GetDate(&hrtc, &dateStruct, RTC_FORMAT_BIN); dstTime.tm_hour = timeStruct.Hours; dstTime.tm_min = timeStruct.Minutes; dstTime.tm_sec = timeStruct.Seconds; dstTime.tm_year = dateStruct.Year + 100; dstTime.tm_mon = dateStruct.Month - 1; dstTime.tm_mday = dateStruct.Date; return mktime(&dstTime); } W pętli głównej programu znajduje się następujący fragment, odpowiedzialny z synchronizację czasu i jego wyświetlanie na LCD: if ( (tmptime = DCF77_getUTCTime()) ) { printf("Time updated: %lu\r\n", tmptime); setRealTimeClock(tmptime); lastupdate = tmptime; } if (rtcTickFlag) { tmptime = time(NULL); tmupd = gmtime((const time_t*)&tmptime); snprintf(buffer, sizeof(buffer)-1, "%02d:%02d:%02d", tmupd->tm_hour, tmupd->tm_min, tmupd->tm_sec); PCD_GotoXYFont(1,1); PCD_Str(FONT_1X, (uint8_t*)buffer); snprintf(buffer, sizeof(buffer)-1, "%02d-%02d-%02d", tmupd->tm_mday, (tmupd->tm_mon)+1, (tmupd->tm_year)-100); PCD_GotoXYFont(1,2); PCD_Str(FONT_1X, (uint8_t*)buffer); if (lastupdate != 0) { tmupd = gmtime((const time_t*)&lastupdate); PCD_GotoXYFont(1,4); PCD_Str(FONT_1X, (uint8_t*)"Updated:"); snprintf(buffer, sizeof(buffer)-1, "%02d:%02d:%02d", tmupd->tm_hour, tmupd->tm_min, tmupd->tm_sec); PCD_GotoXYFont(1,5); PCD_Str(FONT_1X, (uint8_t*)buffer); snprintf(buffer, sizeof(buffer)-1, "%02d-%02d-%02d", tmupd->tm_mday, (tmupd->tm_mon)+1, (tmupd->tm_year)-100); PCD_GotoXYFont(1,6); PCD_Str(FONT_1X, (uint8_t*)buffer); } PCD_Upd(); rtcTickFlag = 0; } Funkcja setRealTimeClock() wygląda następująco: void setRealTimeClock (time_t tm) { RTC_TimeTypeDef timeStruct; RTC_DateTypeDef dateStruct; struct tm *dstTime; dstTime = gmtime(&tm); timeStruct.Hours = dstTime->tm_hour; timeStruct.Minutes = dstTime->tm_min; timeStruct.Seconds = dstTime->tm_sec; dateStruct.Year = (dstTime->tm_year)-100; dateStruct.Month = (dstTime->tm_mon)+1; dateStruct.Date = dstTime->tm_mday; HAL_RTC_SetTime(&hrtc, &timeStruct, RTC_FORMAT_BIN); HAL_RTC_SetDate(&hrtc, &dateStruct, RTC_FORMAT_BIN); } Na początku wszystko zdaje się działać prawidłowo. Układ startuje, RTC odlicza czas. Gdy pojawiają się odpowiednie warunki, moduł DCF77 zaczyna odbierać ramki i ustawia zegar. Na wyświetlaczu pojawia się właściwy czas UTC, jak również informacja o momencie ostatniej synchronizacji. Przez jakiś czas wszystko gra. Jednak w pewnym momencie dzieje się coś dziwnego. Aktualnie wyświetlany czas rozjeżdża się o jakieś osiem godzin do przodu. Na przykład wczoraj o 20.00 UTC pokazywał godziną 4.00 UTC dnia następnego. Żeby było jeszcze dziwniej informacja o ostatnio odebranej ramce wciąż pokazuje właściwy czas. Nie wiem na którym etapie pojawia się przekłamanie. Do konwersji czasu na formę tekstową używam przecież tych samych funkcji, Gdyby problem związany był z RTC albo moja funkcją time(), to przecież kolejne synchronizacje nie byłyby możliwe - biblioteka DCF77 wychwytywałaby sporą różnicę pomiędzy czasem systemowym i odebranym. W takim wypadku po odebraniu dwóch kolejnych prawidłowych ramek uznałaby, że czas systemowy jets zły i tak czy inaczej ustawiła RTC. Tymczasem na wyświetlaczu pojawiają się informacje o kolejnej udanej synchronizacji, a aktualny czas i tak jest wyświetlany błędnie... Ktoś ma pojęcie o co może chodzić? W załączniku przesyłam kompletny projekt, w razie gdyby przytoczone powyżej fragmenty kodu źródłowego okazały się niewystarczające. DCF77_LCD.zip
  15. Przedstawiam mojego najnowszego robota klasy LineFollower Standard "Fuzzy". Z opisywaną konstrukcją pojawiam się na większości zawodów jakie organizowane są w ostatnim czasie. W porównaniu do moich poprzednich robotów Fuzzy nie został wyposażony w napęd tunelowy. Powodem tej decyzji była chęć testowania nowych algorytmów. Efekty mojej pracy łatwiej zauważyć na robocie bez docisku, ponieważ jest on trudniejszy to wysterowania przy większych prędkościach. Konstrukcja mechaniczna Robot standardowo wyposażony został w dwa silniki Pololu 10:1 HP z obustronnym wałem, na którym zamocowane zostały magnesy od enkoderów. Podwozie stanowi płytka PCB wykonana w Satlandzie. Czujniki wysunięte zostały do przodu na węglowej listewce. Koła wytoczone zostały na zamówienie. Całość, zależnie od dobranego akumulatora waży 70-100g. Elektronika Prezentowana konstrukcja to czwarty prototyp robota. Głównymi elementami części elektronicznej są: mikrokontroler STMF103RBT6, enkodery AS5040 oraz mostek TB6612. Konstrukcja może obsługiwać do 16 czujników KTIR. Po przeprowadzonych testach pozostałem jednak przy 8 transoptorach. Pozostałe połączenia z czujnikami pozwalają na wizualizację ich stanów poprzez diody LED. Schemat prototypu Prototyp W poprzedniej konstrukcji do komunikacji z otoczeniem wykorzystywałem złącza typu Goldpin o rastrze 0.5mm. Częste podpinanie i odpinanie dodatkowego osprzętu sprawiło, że złącza te szybko uległy uszkodzeniu wprowadzałem spore problemów. Dlatego w nowej wersji zastosowałem złącza firmy HARTING Flexicon, które rozwiązały mój problem. Szczerze mogę je polecić, nie miałem żadnych problemów od kiedy je stosuję. Ostateczna wersja elektroniki ze złączami HARTING Flexicon Oprogramowanie Program napisany został w języku C z wykorzystaniem biblioteki dostarczanej przed producenta STMów. Kod w głównej mierze składa się z dwóch części. Pierwsza odpowiedzialna jest za komunikację z otoczeniem, druga za podążanie za linią. Kontroler robota Robot może komunikować się z komputerem lub specjalnym kontrolerem za pomocą interfejsu USART. Możliwa jest również komunikacja przez moduły Bleutooth. Całość obsługiwana jest przez własny, prosty protokół do komunikacji. Algorytm pakuje wszystkie dane w ramki oraz oblicza sumę kontrolną. Rozwiązanie takie pozwoliło na bezbłędne przesyłanie wymaganych danych. Prototyp z modułem BlueTooth Podążanie za linią wykonane zostało w oparciu o 3 regulatory: PD - podążanie za linią, sprzężenie zwrotne od czujników 2x PID - sterowanie faktyczną prędkością silników, sprzężenie zwrotne od enkoderów magnetycznych Efekty Szczególną wagę przykładałem do precyzji przejazdu, która moim zdaniem jest zadowalająca - szczególnie na kątach prostych. Robot wygrał wszystkie zawody w kategorii LineFollower Standard w jakich brał udział. Zdarzyło mu się przegonić również niejednego robota z turbiną. W optymalnych, domowych warunkach średnia prędkość robota, to ponad 2m/s. Poniżej filmik z zawodów RoboMotion z prędkością około 1,4 m/s - nie był to najszybszy przejazd. Ostateczny wygląd robota W chwili obecnej konstrukcja różni się od powyższej jedynie kolorem opon i długością listewki od czujników. Później postaram dodać więcej zdjęć - szczególnie jeśli będzie z Waszej strony zainteresowanie czymś konkretnym. Podziękowania W tym momencie chciałbym podziękować firmom HARTING oraz TME, które wspierały pracy przy tym projekcie. Szczegóły z budowy robota można znaleźć na moim blogu: http://treker.eu/ Zachęcam do zadawania pytań, odpowiem praktycznie na każde
  16. Rapid jest moją drugą konstrukcją micromouse. Zawiera ona kilka poprawek względem pierwszej (robot Wariat), z których najważniejszą jest użycie żyroskopu. Konstrukcja mechaniczna i zasilanie Robot zbudowany jest na płytce PCB, która stanowi jego podwozie. Założeniem projektu było uzyskanie nisko położonego środka cieżkości oraz jak najmniejszej masy. Dodatkowym atutem robota miała być jego mała szerokość, która pozwalałaby na poruszanie się po "skosie". Napędem robota są silniki Pololu 10:1 sterowane przez dwa mostki TB6612. Jako zasilanie wykorzystywane są akumulatory litowo-polimerowe o jak najmniejszym rozmiarze i niewielkiej masie. Z powodu małych pojemności konieczna jest częsta wymiana i ładowanie pakietów. W robocie używane są różne pakiety, różnych producentów. Mikrokontroler Sercem robota jest mikrokontroler STM32F405RGT6. O wyborze zdecydowała chęć nauki programowania mikrokontrolerów STM32 z najpotężniejszym rdzeniem Cortex-M4F oraz najmniejsza obudowa spośród wszystich procesorów rodziny STM32F4. Najważniejszymi cechami mikrokontrolera są: taktowanie 168MHz, 192kB RAM, 1MB flash, bardzo duża liczba timerów (m.in. ze sprzętową obsługą PWM oraz wyjść kwadraturowych enkoderów), wiele kanałów przetwornika ADC, DMA, sprzętowa obsługa liczb zmiennoprzecinkowych, wiele dostępnych interfejsów komunikacyjnych. Czujniki W robocie wykorzystano trzy rodzaje czujników: dalmierze optyczne, enkodery oraz żyroskop. Jako czujniki odległości wykorzystano diody SFH4511 oraz fototranzystory TEFT4300 (podłączenie takie samo jak w przypadku robota MIN7 autorstwa Ng Beng Kiat). Diody są sterowane impulsowo, każda z osobna. Wybranym żyroskopem jest analogowy czujnik ISZ-650 firmy Invensense. Jego zakres pomiarowy to +-2000st/s. O jego wyborze zdecydowała głównie dostępność i cena podczas zakupu. Podczas testów robota uszkodzono sensor, dlatego konieczna była wymiana. Zdecydowano się na moduł z żyroskopem L3GD20. Do podłączenia wykorzystano miejsce na wyświetlacz N3310 wraz z wyprowadzonym interfejsem SPI. Zamontowanie enkoderów obrotowych z magnesami na osiach silników powodowałoby poszerzenie całej konstrucji, więc zdecydowano się na użycie enkoderów liniowych wraz z odpowiednimi magnesami. Wykorzystane enkodery AS5304 oraz zamocowane magnesy na kołach robota przedstawiono na rysunkach poniżej. Użyte enkodery pozwalają uzyskać rozdzielczość 3520 impulsów na obrót koła, co daje w wyniku 0.028 mm/impuls. Interfejs użytkownika Założeniem projektu było wykorzystanie joysticka oraz wyświetlacza z telefonu Nokia 3310. Obecnie oprogramowanie nie zawiera obsługi wyświetlacza, dlatego nie jest on zamontowany. Do wyboru prostych komend służy joystick oraz zamontowany buzzer. Buzzer służy także jako powiadomienie o charakterystycznych sytuacjach w labiryncie, np. wykrycie ścianki, dojechanie do środka labiryntu. Oprogramowanie Program opiera się o cykliczne wywoływanie funkcji z częstotliwością 1kHz. W funkcji tej wykonywane są pomiary czujników, aktualizowana jest pozycja robota oraz wyliczane są wartości współczynnika wypełnienia PWM na silniki. Robot posiada trapezoidalny profil sterowania prędkością. Implementacja i zasada działania jest bardzo podobna jak w artykule [Programowanie] Sterowanie robotem mobilnym klasy (2,0). Przeszukiwanie robota odbywa się z użyciem algorytmu floodfill. Po znalezieniu środka labiryntu, robot rozpoczyna wyznaczanie najszybszej ścieżki. Do tego celu użyto zmodyfikowanego algorytmu floodfill, którego wagami jest czas przejazdu. Podsumowanie Robot Rapid zachowuje się w labiryncie dosyć stabilnie i przewidywalnie. Jest to bardzo ważna cecha, ponieważ pozwala na dalszą pracę nad konstrukcją oraz rozwijanie oprogramowania. Pomysłów na poprawienie działania robota jest wiele. Ograniczeniem jest jedynie poświęcony temu czas. Galeria Osiągnięcia I miejsce w kategorii Micromouse na zawodach Robotic Arena 2012 II miejsce w kategorii Micromouse na zawodach Robomaticon 2013 I miejsce w kategorii Micromouse na zawodach Trójmiejski Turniej Robotów 2013 I miejsce w kategorii Micromouse na zawodach ROBO~motion 2013
  17. Witam. Po pierwszej konstrukcji jaką był linefollower postanowiłem zrobić coś ambitniejszego. Wybór padł na robota typu micromouse. Praktycznie wszystkie części zostały zasponsorowane prze moją szkołę. Elektronika Robotem steruje mikrokontroler z rodziny stm32f103 taktowany kwarcem 8Mhz i z włączoną wewnętrzną pętlą PLL, która mnoży zegar x9, taktując ostatecznie procesor 72MHz. Jako mostki do silników zostały użyte 2x tb6612, po jednym na silnik. Jako czujniki początkowo używane były sharpy 5 i 10 cm a od niedawna są to analogowe dalmierze zbudowane z diody ir i fototranzystora. Do zasilania używam akumulatora modelarskiego typy li-pol 2 celowego o pojemności 500mAh. Silniki są zasilane bezpośrednio z akumulatora przez diodę zapobiegająca uszkodzeniu mostków na skutek błędnego podłączenia akumulatora. Elektronika również jest zasilana przez połączone kaskadowo stabilizatory 5V i 3.3V które też są zabezpieczone osobną diodą. Mechanika Podstawą jest płytka drukowana wykonana z laminatu 1.5mm wykonana w firmie Satland Prototype . Silniki to Pololu HP 30:1 z przedłużona osią. Jako enkodery początkowo służyły wydrukowane tarcze 5 czarnych pół i po dwa czujniki TCRT1000 dając 20 impulsów na obrót wału silnika. Obecnie są to enkodery wymontowane z myszki kulkowej. Oprogramowanie Cały program został napisany w języku C w środowisku Atollic TrueSTUDIO. Mysz posiada algorytm mapowania oraz rozwiązywania labiryntu, jednak wykonywanie korekcji wobec ścian nie jest tak skuteczne aby przejechanie dużego labiryntu obyło się bez dotknięcia ściany. Obsługa enkoderów jest wykonana sprzętowo przy użyciu jednego timera na każdy enkoder w specjalnym trybie przeznaczonym do obsługi enkoderów kwadraturowych. Filmy i zdjęcia wersji z sharpami i enkoderami wydrukowanymi na papierze - stan na Robotic Arena 2011 https://www.youtube.com/watch?v=kMqzrvSACqc Aktualny stan - dalmierze i enkodery z myszki - Robotic Tournament 2012 https://www.youtube.com/watch?v=Kcb8uWGm-as Podziękowania dla użytkownika Matmaniak za filmik z zawodów Istrobot 2012: https://www.youtube.com/watch?v=FSQFybaACO0https://www.youtube.com/watch?v=qSlVX2fVSts Płynne skręty, nowy labirynt i parę innych rzeczy. https://www.youtube.com/watch?v=rufoc3rPTvI Udział w zawodach: Robotic Arena 2011 - 4. miejsce. Robotic Tournament 2012 - 4. miejsce. Istrobot 2012 - 1. miejsce. Roboxy 2012 - 2. miejsce. Pozdrawiam
  18. Krzema

    Enova

    Cześć, przedstawiamy Wam naszego pierwszego robota zbudowanego w ramach drużyny Magnat Cyber Forge Team. W skład drużyny wchodzą: mechanik Mateusz Piotrzkowski, elektronik Szymon Zagórnik oraz programista Piotr Krzemiński. Konstrukcja powstawała przez prawie 2 lata - od pierwszej burzy mózgów i szkiców na komputerze, przez zbieranie funduszy, wykonanie elementów, montaż, programowanie, aż do pierwszego startu w konkursie. Robot ma już swoje lata, lecz mimo to postanowiliśmy go tu opisać. Koncepcja i napęd robota Panujący obecnie w robotach sumo trend skłania do wyboru konstrukcji z dwoma kołami napędowymi. Roboty o takiej strukturze napędu są tanie w budowie, a przy tym zapewniają dobre przyleganie krawędzi tnącej ostrza do podłoża. Problemem w ich przypadku jest nieoptymalne przeniesienie ciężaru robota na podłoże oraz duży moment bezwładności robota. Konstrukcja z czterema kołami napędowymi jest mało popularna lecz rozwiązuje wiele problemów robotów wyposażonych tylko w dwa koła. Pierwszą zaletą jest możliwość zapewnienia przeniesienia prawie całego ciężaru robota przez opony. Kolejną zaletą jest przesunięcie środka obrotu robota do przodu oraz łatwość wpadania w poślizg robotem. Zalety te są nieznaczące w obliczu problemów z zamocowanym nieruchomo ostrzem. W przypadku gdy koła stanowią trzy niezbędne punkty podparcia bardzo trudno jest zamocować ostrze z taką dokładnością aby przylegało do podłoża. Zdecydowaliśmy się zaryzykować. Wybór padł na konstrukcję z czterema kołami oraz ruchome mocowanie ostrza - tak aby połączyć zalety struktur napędu z dwoma i czterema kołami. Szukając silników napędu kół robota wybór ograniczyliśmy do 3 firm oferujących jakościowo najlepsze mikrosilniki elektryczne na świecie - firm Maxon, Faulhaber i Portescap. Głównym ograniczeniem determinującym wybór silników do robota minisumo jest ich maksymalna długość. Zdecydowaliśmy że każde z kół będzie napędzane niezależnie, więc długość silnika wraz z przekładnią i enkoderem nie mogła przekroczyć 50 mm. Po przejrzeniu ofert wymienionych firm okazało się że najmocniejszą konfiguracją o wymaganych wymiarach są silniki Faulhaber 1717 006 SR wraz z przekładnią 16/7 14:1 oraz enkoderami IE2. Silniki te są marginalnie mocniejsze od popularnie stosowanych mikrosilników firmy pololu, lecz mają wielokrotnie większą żywotność. Zdarzały nam się sytuacje całkowitego zatrzymania wszystkich 4 silników na regulaminowe 3 minuty walki a silniki dalej pracują jak nowe. Mechanika Konstrukcja robota składa się z 11 elementów. Siedem z nich zostało zoptymalizowanych pod kątem wykonania metodami skrawania z aluminium, stali oraz węglika wolframu. Pozostałe 4 elementy zostały wydrukowane w technologii PolyJet. Głównym elementem konstrukcyjnym jest płyta centralna. Przykręcone do niej są: tulejki mocujące silniki, element mocujący ostrze, mocowania czujników robota przeciwnika oraz płytka drukowana sterująca robotem. Poniżej znajduje się jeden z siedmiu rysunków wykonawczych tego elementu. Element mocujący ostrze wykonano ze stali 40 HM utwardzonej do wartości 50 HRC. Dzięki temu wypolerowana powierzchnia trudno się rysuje, a przeciwnicy gładko prześlizgują się na zamocowane wyżej rogi. Element ten posiada oś obrotu oraz jest dociskany dwoma sprężynami - niezależnie z każdej strony. Sprawia to że ostrze dociśnięte jest równomiernie do podłoża. Ostrza które stosujemy są wykonane dla nas na zamówienie z węglika wolframu. Poniżej zdjęcie porównawcze tego ostrza ze starą wersją zintegrowaną z mocowaniem do płyty centralnej. Felgi robota mają średnicę 24 mm. Posiadamy kilka kompletów z poliamidu i kilka z aluminium. Nie zauważyliśmy większej różnicy w działaniu robota na różnych kompletach. Opony mają zewnętrzną średnicę 30 mm co daje grubość opon równą 3mm. Przetestowaliśmy wiele materiałów na opony od firmy Smooth-On: Mold Star 15, Mold Star 30, Mold Max 20, Vyta Flex 10, Vyta Flex 30, Vyta Flex 20. Ten ostatni wykazał najlepsze własności mechaniczne i jest przez nas aktualnie stosowany. Do mieszanki dodajemy czarny barwnik, co zwiększa nieco nieco lepkość opon. Waga robota waha się w zależności od zastosowanych felg i baterii od 460 do 495 gramów. Elektronika Płyta sterowania robota to laminat FR4 o grubości 0.8mm. By spełnić wymagania związane z fizycznym rozmieszczeniem układów na płytce, wykorzystaliśmy technologię produkcyjną umożliwiającą nam użycie ścieżek o szerokości 0.2mm oraz rastrze podobnej szerokości. Znajdujące się na płytce układy zapewniają prawidłową pracę robota w trybie domyślnym tj. walka na ringu (bez opcji wybierania taktyki i różnych trybów). Program robota wykonywany jest przez wcześniej wspomniany 32-bitowy mikrokontroler ST32F107R8T6. Został on wybrany ze względu na aż cztery dostępne timery, które są niezbędne do obsługi sygnałów z enkoderów silników. Na płycie sterowania znajdują sie również cztery mostki H, złącza od czujników przeciwnika sześć transoptorów i dwa stabilizatory napięcia na 3.3V i 5V. Moduł interakcji użytkownika z robotem stanowi płytka drukowana umieszczona pod górną pokrywą robota. Jest ona w znacznym stopniu mniej skomplikowana od płytki sterującej, niemiej jednak zawiera ona oddzielny mikroprocesor STM32F103CVT. Obsługuje on wyświetlacz OLED o rozdzielczości 128x64 piksele poprzez interfejs SPI. Wykrywa on również sygnał z zmieszczonego na płytce odbiornika podczerwieni oraz czterech przycisków stykowych. Dzięki przyciskom lub bezprzewodowo z pomocą pilota RC5 użytkownik jest w stanie włączyć robota i wybrać algorytm pracy robota wyświetlany na wyświetlaczu OLED. Komunikacja między górnym i dolnym mikroprocesorem odbywa się za pomocą interfejsu UART. Obie płytki drukowane są połączone ze sobą taśmą FFC. Zasilanie Zastosowaliśmy dwukomorową baterię litowo-polimerową, która przy maksymalnym naładowaniu daje 8.4V. Nie wyróżnia się ona niczym szczególnym poza rozmiarem i kształtem, który jest idealnie dopasowany do konstrukcji robota i wewnętrznego rozmieszczenia elementów. Pojemność baterii to 900 mAh Czujniki Sensorami umożliwiającymi wykrywanie przeciwnika są popularne Sharpy GP2Y0D340K. Są to czujniki IR o zasięgu do 40 cm. Są cyfrowe, tj. wskazują pojawienie się obiektu lub jego brak. W środku sensora umieszczony jest układ cyfrowy kondycjonujący otrzymaną wiązkę podczerwieni oraz emitujący cyfrowy sygnał wykrycia do mikrokontrolera. Zasilany jest wyłącznie 5V więc sygnał Vout również jest na tym poziomie. Fakt ten nie komplikuje układu, gdyż użyty mikrokontroler ma wejścia kompatybilne z 5V mimo, że sam jest zasilany na 3.3V. W celu skutecznego wykrywania przeciwnika umieszczono aż 6 sensorów ułożonych w konfiguracji: 2 patrzące do przodu, 2 pod skosem 45 stopni oraz 2 patrzące na boki robota. Jednostki obliczeniowe Dolna płytka zawiera główny procesor STM32F107 taktowany zegarem o częstotliwości 72 MHz. Zajmuje się przetwarzaniem informacji z czujników linii oraz przeciwnika, a także wysterowuje silniki korzystając z wbudowanych fabrycznie enkoderów magnetycznych i regulatora PID. Na górnej płytce znajduje się drugi procesor STM32F103 (również 72 MHz) zajmujący się obsługą wejścia/wyjścia czyli przycisków, wyświetlacza i wbudowanego odbiornika podczerwieni. Taki podział zadań pomiędzy dwa procesory wydaje się zbędny/przesadzony, lecz jest to pozostałość z pierwszych wersji robota.. Programowanie Do komunikacji z robotem użyto dwóch interfejsów: SWD (Serial Wire Debug) – szeregowa odmiana popularnego interfejsu JTAG. Umożliwia on programowanie oraz debugowanie mikrokontrolera sterującego. Do komunikacji między dwoma modułami (mikroprocesorami) oraz komunikacji komputer – mikroprocesor użyto interfejsu UART. Fizyczne połączenie robota z komputerem stanowi złącze MicroHDMI. Zostało ono wybrane ze względu na liczbę dostępnych pinów oferowane przez standard HDMI, trwałość mechaniczną i dostępność. Medium łączące wymienione interfejsy i komputer jest przejściowa płytka drukowana z standardowymi złączami dla programatorów. Rysunek poniżej przedstawia omawianą „przejściówkę”. Oprogramowanie Program dla robota pisany jest w języku C, z użyciem Standard Peripheral Library. W newralgicznych miejscach, aby przyśpieszyć kod, wykonywane są operacje bezpośrednio na rejestrach - dzięki temu został zachowany balans między czytelnością a wydajnością kodu. Jeśli chodzi o IDE, początkowo wykorzystywane było TrueSTUDIO Lite, lecz ze względu na swój limit wielkości programu wynikowego (32 kB?) byliśmy zmuszeni do przejścia na CoIDE. Silniki wysterowywane są regulatorem PID, lecz tak naprawdę tylko człon P jest aktywny. Zaimplementowany został pełny regulator PID, lecz okazało się, że na członie P robot zachowuje się dobrze i nie ma potrzby uaktywniać pozostałych współczynników. Magnetyczne enkodery wbudowane w silnik dostarczają aż 7168 impulsów na obrót, co zapewnia wysoką dokładność. Został wykorzystany wbudowany w STM32F107 interfejs dla enkoderów, dzięki czemu zliczanie impulsów sygnału kwadraturowego odbywa się niejako "w osobnym wątku" - nie są potrzebne przerwania, wystarczy odczytywać położenie koła ze wskazanego rejestru. Dzięki czterem czujnikom linii z przodu, możemy obliczyć w przybliżeniu kąt pod jakim podjeżdżamy do linii. Wystarczy prosta trygonometria - znamy odległość między czujnikami, znamy też dystans jaki robot przejechał od momentu zobaczenia linii zewnętrznymi czujnikami do momentu zauważenia jej czujnikami wewnętrznymi. Znając kąt pomiędzy osią robota a linią, możemy odpowiednio wykonać manewr wycofania się ku środkowi planszy. Odbiornik podczerwieni na górnej płytce służy nam głównie do odbierania sygnałów z pilotów sędziowskich. Zastosowaliśmy własny odbiornik przede wszystkim aby zaoszczędzić na miejscu, lecz również aby móc odbierać niestandardowe komendy dla robota, np. wskazówki dotyczące taktyki. Dzięki "deweloperskiej" wersji aplikacji Sumo Remote możemy wysyłać w zasadzie dowolny kod do robota - po dopracowaniu funkcja ta będzie dostępna publicznie. Monochromatyczny wyświetlacz OLED o rozdzielczości 128x64 umieszczony na górnej płytce umożliwia wybór taktyk, a także wyświetlanie informacji testowych. Nie posiada on wbudowanej czcionki, więc konieczna była implementacja wyświetlania własnych czcionek/obrazków. Aby zaoszczędzić miejsce w pamięci Flash procesora, obrazy kompresowane są algorytmem RLE za pomocą konwertera w postaci aplikacji na PC, po czym na robocie dekompresowane są w locie. Dzięki temu możemy użyć dużych i czytelnych czcionek, czy też schematycznych ikon obrazujących manewry robota. Krótkie demo działania wyświetlacza: (muzyka niestety nie jest odtwarzana z robota ). Po więcej szczegółów zapraszamy na naszą stronę: http://mcft.eu/_portal/page/knowledge_base/cat/6/Enova_MiniSumo#art_Enova_MiniSumo. Osiągnięcia Sezon 2013/2014: [*]1. miejsce na Roboxy 2014 w kategorii Minisumo [*]1. miejsce na Trójmiejskim Turnieju Robotów 2014 w kategorii Minisumo Deathmatch [*]3. miejsce na Trójmiejskim Turnieju Robotów 2014 w kategorii Minisumo [*]1. miejsce na Cyberbot 2014 w kategorii Minisumo Deathmatch [*]2. miejsce na Cyberbot 2014 w kategorii Minisumo [*]1. miejsce na Robot-SM 2014 w Göteborgu w kategorii Minisumo [*]1. miejsce na Ogólnopolskich Zawodach Robotów ROBOmotion 2014 w kategorii Minisumo [*]1. miejsce na Ogólnopolskich Zawodach Robotów ROBOmotion 2014 w kategorii Minisumo Deathmatch [*]1. miejsce na Robotic Tournament 2014 w kategorii Minisumo [*]1. miejsce na Robotic Tournament 2014 w kategorii Minisumo Deathmatch [*]1. miejsce na Copernicus Robots' Tournament 2014 w kategorii Minisumo [*]1. miejsce na Copernicus Robots' Tournament 2014 w kategorii Minisumo Deathmatch [*]1. miejsce na Robotic Arena 2013 w kategorii Minisumo Debel (z robotem Mirror Mateusza Paczyńskiego) [*]2. miejsce na Robotic Arena 2013 w kategorii Minisumo Enhanced [*]2. miejsce na Robotic Arena 2013 w kategorii Minisumo Classic [*]2. miejsce na Sumo Challenge 2013 w kategorii Minisumo+ [*]1. miejsce na Sumo Challenge 2013 w kategorii Minisumo [*]1. miejsce w konkursie robotów Gdańskich Dni Elektryki Młodych 2013 w kategorii Minisumo Sezon 2012/2013: [*]1. miejsce na Leś-Tech 2013 w kategorii Minisumo [*]1. miejsce na Roboxy 2013 w kategorii Minisumo [*]1. miejsce na CybAiRBot 2013 w kategorii Minisumo [*]1. miejsce na Robocomp 2013 w kategorii Minisumo [*]1. miejsce na ROBOmotion 2013 w kategorii Minisumo Deathmatch [*]1. miejsce na ROBOmotion 2013 w kategorii Minisumo [*]1. miejsce na Copernicus Robots Tournament 2013 w kategorii Minisumo Deathmatch [*]1. miejsce na Copernicus Robots Tournament 2013 w kategorii Minisumo [*]3. miejsce na Trójmiejskim Turnieju Robotów 2013 w kategorii Sumo² [*]1. miejsce na Trójmiejskim Turnieju Robotów 2013 w kategorii Minisumo [*]1. miejsce na Robotic Tournament 2013 w kategorii Minisumo [*]1. miejsce na RobotChallenge 2013 w Wiedniu w kategorii Minisumo [*]1. miejsce na Robomaticon 2013 w kategorii Minisumo [*]1. miejsce na T-BOT 2013 w kategorii Minisumo [*]1. miejsce na Robotic Arena 2012 w kategorii Minisumo Enhanced [*]2. miejsce na Robotic Arena 2012 w kategorii Minisumo Poniższy film prezentuje walki Enovy na konkursie RobotChallenge 2013 w Wiedniu: A tutaj kompilacja walk Enovy z konkursu Robocomp 2013 w Krakowie:
  19. Cześć! Jako że już po sezonie to postanowiłem opisać tu moją i mateuszm konstrukcję. Robot powstał w ramach rekrutacji do koła naukowego robotyków KoNaR i debiutował na Robotic Arenie 2015. Był to nasz debiut w konstruowaniu robotów, ponieważ wcześniej żaden z nas tego nie robił. Mechanika Głównym założeniem mechaniki robota było wykorzystanie w pełni maksymalnej dopuszczalnej masy oraz skupienie jej w podstawie. W osiągnięciu tego celu pomógł nam projekt Autodesk Inventor, w którym to został wykonany szczegółowy projekt robota uwzględniający wszystkie drobne elementy mechaniczne. Podstawa robota została wykonana z trzech elementów: - ostrze z węglika spiekanego - płytka stalowa 3mm - płytka górna, 2mm, która łączyła dwa elementy wymienione wyżej W płytkach zostały wycięte otwory, w których następnie umieszczone były małe, okrągłe płytki z czujnikami białej linii. Stal była cięta laserowo oraz później frezowana. Napęd robota stanowiły znane i lubiane silniczki Pololu HP z przekładnią 50:1 przykręcone bezpośrednio do podstawy za pomocą dedykowanych mocowań. Podpięte do elektroniki były przy pomocy złączy ARK co umożliwiło ich łatwy demontaż w celach serwisowych. Obudowa robota została wykonana z laminatu 1mm. Na obudowie znajduje się nazwa robota oraz nasze imiona i nazwiska. Obudowa mocowana jest do podstawy za pomocą śrub, a jej elementy są do siebie lutowane. Dach robota wykonaliśmy z 2 mm przeźroczystego szkła akrylowego. Finalnie robot mierzy w najwyzszym miejscu 33,7 milimetra od podstawy do dachu, a od podłoza do dachu 37,2. Jego podstawa ma wymiary 98,9 mm na 99,6 mm. Masa waha się od 490 do 499g w zależności jak bardzo nakarmimy robota przed zawodami Elektronika Priorytetem projektu robota była jego dobra konstrukcja mechaniczna, w wyniku czego wymiary płytki z elektroniką były z góry narzucone. Elektronika została zaprojektowana w programie KiCad po zaimportowaniu wymiarów przeznaczonych na nią z programu Inventor. Elektronika robota dzieli się na dwie płytki: główną, która znajduje się tuż nad podstawą robota oraz dodatkowej, na której umieściliśmy włącznik zasilania, interfejs komunikacyjny oraz złącze na moduł startowy. Płytki połączone zostały ze sobą taśmą FFC. Mała płytka widoczna na zdjęciu nad płytką główną służy nam jako podstawka pod akumulator LiPo 7.4V, którym zasilamy robota. Sercem naszego robota został mikroprocesor STM32F1. Wybór tej rodziny wynikał z łatwości ich programowania przez początkujących. Czujniki odległości wykorzystane w robocie to znane i lubiane cyfrowe Sharpy 40cm. Umieściliśmy je 4, dwa z przodu oraz po jednym na bokach. Na czujniki białej linii użyliśmy dwa KTIRy 0711S. Jak wcześniej wspomniałem zostały one umieszczone na małych płytkach, które umieściliśmy w wycięciach w podstawie. Na sterowniki silników wybraliśmy dwa, podwójne mostki H TB6612. Zostały one dobrane ze względu na ich dobrą wydajność prądową, co umożliwiło nam skuteczne wysterowanie silników Pololu bez obawy o to, że przy pełnym zwarciu mostki ulegną uszkodzeniu. Płytki zostały wykonane metodą termotransferu oraz wyfrezowane za pomocą Dremela i pilników ręcznych. Software Kod robota został napisany w środowisku System Workbench for STM32 (SW4STM32) z użyciem generatora kodu konfiguracyjnego STM32CubeMX. Program podzielony był na dwie sekwencje: startową i walki. W pierwszej ustawiana była konfiguracja algorytmu robota oraz dostępne były funkcje testu czujników (widoczny na zdjęciu poniżej - cztery czerwone diody, które odpowiadały za pokazanie aktualnego stanu czujników) oraz czyszczenia kół (drobna funkcja pomocnicza ustawiająca małą prędkość na kołach). Sekwencja walki załączała się po otrzymaniu przez robota sygnału startowego z modułu. Większa część algorytmu walki opierała się na prostych if-ach z odpowiednio dobranymi nastawami silników w każdym przypadku, co okazało się wystarczające w większości starć. Następnie zostały dodane pewne udoskonalenia, o których już rozpisywać się nie będę Osiągnięcia - II miejsce Robomaticon 2016 - I miejsce Robotic Tournament 2016 - III miejsce Festiwal Robotyki Cyberbot 2016 - II miejsce [Minisumo] oraz I miejsce [Minisumo Deathmatch] Trójmiejski Turniej Robotów 2016 - II miejsce Opolski Festiwal Robotów 2016 - I miejsce Robotic Day 2016 [Praga] A poniżej kilka filmów z udziałem robota: 2Weak4U vs Hellfire 2Weak4U w Wiedniu 2Weak4U vs Dzik 2Weak4U vs Shevron (chyba) 2Weak4U w Deatmatchu [Rzeszów] 2Weak4U vs Szwagier Pozdrawiam i do zobaczenia w następnym sezonie, Aleksander
  20. Witajcie! Bolt to robot klasy Linefollower Standard. Został zaprojektowany, zbudowany oraz zaprogramowany przez kolegę Hubert.M oraz mnie. Jest on naszą najnowszą konstrukcją. Konstrukcja mechaniczna. Robot składa się z 2 płytek PCB, wykonanych przez firmę SATLAND Prototype. Płytki połączone są dwiema węglowymi listewkami, a z tyłu robota znajduje się aluminiowa podpórka zabezpieczająca przed przewróceniem się robota. Podpórkami listwy czujników są tranzystory w obudowie TO92. Silniki użyte w robocie to popularne Pololu HP 10:1. Koła wykonał dla nas hungrydevil. Masa robota z baterią wynosi 69 gramów. Elektronika. Zdecydowaliśmy się na mikrokontroler STM32F103C8T6. Silniki sterowane są układem TB6612. Zastosowane czujniki linii to KTIR0711. Czujników na chwilę obecną jest 9. Zastosowaliśmy moduł bluetooth HC-05. Zastosowanie modułu znacznie ułatwiło strojenie robota. Ponadto stan każdego czujnika jest odzwierciedlony diodą LED. Robot zasilany jest pakietem Li-pol o pojemności 150mAh. Część logiczna robota zasilana jest napięciem 3.3V. Program. Algorytm robota jest napisany w języku C. Zastosowano regulator PD. Dzięki modułowi BT wszystkie nastawy regulatora mogą być ustawiane bez ponownego programowania robota. Ponadto, program pozwala na np. zdalne sterowanie robota po połączeniu z komputerem. Do zażądania robotem napisaliśmy 2 aplikacje – na telefony z systemem android, aplikacja pozwala na wystartowanie robota, a także na jego zatrzymanie. Z Kolei aplikacja na PC oprócz podstawowej funkcjonalności pozwala na dobieranie nastaw robota. Ponadto można za jej pomocą rysować wykresy uchybu i pochodnej z uchybu. Bolt ma brata bliźniaka, o nazwie Bez Nazwy. Jest on nieco szybszy od Bolta (bo czerwony). Osiągnięcia i plany na przyszłość. - 2 miejsce na Konkursie robotów SEP Gdańsk 2015 - 4 miejsce na SUMO Challenge 2015 W robocie planujemy jeszcze bardziej poprawić jakość sterowania, oraz rozważamy wykonanie węższej listwy czujników z czujnikiem odległości, aby móc startować w kategorii LF Enhanced. Film z przejazdu:
  21. Idąc za ciosem, tym razem chciałem przedstawić (najprawdopodobniej) pierwszego na tym forum robota klasy Ketchup House. W pracach nad jego stworzeniem brało udział 5 członków Koła Naukowego Robotyków. Nazwa Nazwa Pomidor wydaje się być dość zrozumiała z uwagi na nazwę konkurencji w której startuje, jednak numeracja już niekoniecznie Otóż bezpośrednim protoplastą tego robota jest robot Pomidor (1). Robot miał parę błędów konstrukcyjnych, które powodowały, że nie spisywał się najlepiej. W związku z tym podjęliśmy decyzję o zrobieniu dużo bardziej zaawansowanego robota – Pomidora 2. Jednak na jakiś czas przed zawodami stwierdziliśmy, że nie zdążymy wykonać go w wymarzonej przez nas formie, więc powstał robot będący hybrydą tych dwóch podejść – Pomidor 1.5. Konstrukcja okazała się na tyle udana, że na jej podstawie powstała kolejna generacja robota – Pomidor 1.6 (o której będzie zapewne w kolejnym poście). Zawody Ketchup House Ponieważ jest to dość egzotyczna kategoria (przynajmniej w Polsce), pozwolę sobie ją najpierw krótko opisać. Moim zdaniem, Ketchup House jest zdecydowanie najbardziej nieprzewidywalną i widowiskową konkurencją odbywającą się na zawodach konstruktorskich. W każdej, trwającej 3 minuty rozgrywce udział biorą 2 roboty. Polem ich zmagań jest biała, kwadratowa plansza o wymiarach min. 1,8x1,8m. Na planszy znajduje się 10 czarnych linii (5 poziomych i 5 pionowych) o szerokości 12mm, tworząc kwadrat o wymiarach 1,2x1,2m, podzielony na 16 mniejszych kwadratów o wymiarach 0,3x0,3m. Na skrzyżowaniach umieszczane są puszki z tytułowym keczupem. Są to typowe stalowe puszki o średnicy 53 mm, wysokości 74 mm i masie ok. 163 g. W każdej, trwającej 3 minuty potyczce biorą udział 2 roboty. Ich zadaniem jest przemieszczenie puszek na swoją linię „domową”. Na początku rozgrywki na planszy znajduje się 5 puszek. 2 z nich, zaznaczone na zielono, znajdują się w ustalonych pozycjach (skrzyżowania C2 oraz C4). Położenie 3 pozostałych puszek jest losowane tuż przed rozpoczęciem pojedynku. Aby zrównoważyć szanse robotów na zwycięstwo, każda z dolosowywanych puszek musi się znaleźć na innej z linii B, C, D. Na początku pojedynku roboty są umieszczane w pozycjach A3 oraz E3. Na znak sędziego roboty są uruchamiane. Od tej pory, aż do zakończenia pojedynku nie ma możliwości ingerencji w ich działanie. Jeżeli podczas rozgrywki robot poruszy jedną z puszek w wylosowanej pozycji, to na jej miejsce dostawiana jest kolejna. Dostawienie następuje po przejechaniu przez robota do następnego skrzyżowania. W trakcie jednego pojedynku na planszy może się pojawić łącznie do 12 puszek. Istnieje zupełna dowolność w sposobie przemieszczania i odstawiania puszek. Nie ma także ograniczeń co do sposobu poruszania się po planszy – roboty mogą poruszać się po wyznaczonych liniach, ale nie muszą. Przypadkowe zderzenia na ogół nie są karane, jednak niezgodne z zasadami jest zamierzone „dążenie do zderzenia” (np. wypychanie poza planszę). Roboty powinny wykrywać i omijać przeciwnika. Po upływie 3 minut następuje zakończenie potyczki. Roboty (jeżeli zachodzi taka potrzeba) są zatrzymywane. Za każdą puszkę dotykającą linii bazowej przyznawany jest 1 punkt. (Na rysunku poniżej przykładowa sytuacja na koniec pojedynku, zakończona wynikiem 5-4 na korzyść robota 2 (niebieskiego)). Mechanika Po tym dość przydługim wstępie, teraz parę słów o samej konstrukcji. Bazę robota stanowią dwie płyty laminatu szklano-epoksydowego. Obie płytki stanowią dwojaką rolę - po pierwsze są to bazowe komponenty, do których montowane są wszystkie pozostałe części, po drugie zaś - rozmieszczone są na nich wszystkie połączenia elektryczne. Obie płyty mają kształt prostokąta o wymiarach 200x190 mm, w którym wycięto V-kształtne wycięcie. Płyty są ze sobą skręcone za pomocą mosiężnych dystansów. Układ napędowy stanowią dwa silniki POLOLU z przekładnią 298:1. Wcześniej stosowaliśmy silniki o dużo mniejszym przełożeniu, jednak podczas naszych pierwszych zawodów okazało się, że jazda ze zbyt dużą prędkością jest nieopłacalna – podczas zderzeń sędzia zawsze uznawał, że to nasza wina, gdyż jechaliśmy z dużo wyższą prędkością (poza tym zastosowanie tak dużego przełożenia pozwoliło nam na uzyskanie większej dokładności enkoderów). Koła podporowe (Kastora) oraz koła napędowe także pochodzą od POLOLU – zostały wybrane głównie ze względu na odpowiedni rozmiar. Do unieruchamiania puszki wykorzystujemy ramkę napędzaną serwomechanizmem. Aby mieć możliwość dokładnego sterowania oraz monitoringu siły, zdecydowaliśmy się na Dynamixela AX-12A (duży wpływ na to miał także fakt, że akurat taki posiadaliśmy w schedzie po starszym projekcie ) Na zawodach zaobserwowaliśmy, że ze względu na wystające kółka czasami robotowi zdarza się zakleszczyć (np. o puszkę) aby uniknąć takich sytuacji wydrukowaliśmy osłonę okalającą całego robota. Elektronika Schemat ideowy całego układu elektronicznego można zobaczyć na rysunku poniżej: Mózgiem robota jest STM32F100RB, będący częścią zestawu STM32 Discovery VL. Zdecydowaliśmy się na takie rozwiązanie, aby móc podczas zawodów zmieniać szybko algorytm pomiędzy potyczkami i mieć możliwość jego szybkiego wymienienia w razie awarii. Jak można zaobserwować na rysunku robot jest wyposażony w dużą ilość czujników. Zdecydowanie najważniejszymi z punktu widzenia algorytmu sterowania są czujniki odbiciowe. Jest ich aż 17 (na dolnej płytce) ich rozmieszczenie można zaobserwować na rys. poniżej. Aby móc dopasowywać się do różnych plansz, układ wyposażono w komparatory oraz potencjometr, które pozwalają na ustawienie poziomu, od którego wykrywana jest czerń. KTiRy można przyporządkować do 3 grup. Czujniki oznaczone numerami 4-11, znajdujące się w przedniej części robota, są wykorzystywane w algorytmie jako źródło danych regulatora sterującego jazdą po prostych, a także (w mniejszym stopniu) do wspomagania obrotu. Czujniki w przednich rogach płytki (odpowiednio 11 i 12 oraz 13 i 14) były wykorzystywane przy dowożeniu puszek - do dokładnego pozycjonowania puszek na linii oraz jako czujniki awaryjne podczas jazdy po prostej. Transoptory po bokach (15, 16 i 17 oraz 18, 19 i 20) umożliwiają wykrycie dojazdu do skrzyżowania oraz są głównymi sensorami wykorzystywanymi w algorytmie obrotu. W toku testowania okazało się, że bardzo przydatne byłyby dodatkowe czujniki, które umożliwiłyby jazdę po linii do tyłu. Aby nie wytrawiać całej płytki od nowa, wykonano dodatkową tylną płytkę, na której znajdują się 3 czujniki (o numerach 1-3) Kolejnymi ważnymi czujnikami były enkodery. Na początku stosowaliśmy enkodery optoelektryczne, które do poprawnego działania wymagały zastosowania komparatorów oraz przejścia żmudnego procesu kalibracji (dla każdego z KTiRów z osobna dobieraliśmy nastawy potencjometru). Jednak gdy tylko pojawiły się enkodery magnetyczne dla silników POLOLU, nasze problemy odeszły do lamusa. (Dla porównania – sygnał z enkoderów optoelektrycznych oraz z magnetycznych) Poza tym stosowaliśmy czujniki odległości – do wykrywania puszki oraz do wykrywania przeciwników na planszy. Aby uniknąć cross-talku do jednego zadania wykorzystaliśmy analogowe czujniki SHARP (4-30) a do drugiego czujniki ultradźwiękowe. Aby ustawić odpowiedni kąt czujników ultradźwiękowych – tak, aby wykrywały jedynie przeciwnika, a nie puszkę, zaprojektowaliśmy specjalne mocowanie, umożliwiające modyfikację ich kąta nachylenia. Dla ciekawskich, poniżej są schematy: Na koniec, tradycyjnie, krótki filmik pokazujący działanie robota: [ Dodano: 28-03-2016, 22:01 ] Nie chcąc przedłużać i tak przydługiego już posta, o algorytmie będzie nieco więcej przy okazji opisu robota Pomidor 1.6.
  22. Witam wszystkich! =) Od dłuższego czasu zbieram się do opisu mojej pierwszej "poważniejszej" konstrukcji. Jako że semestr się dopiero zaczyna i jeszcze jest czas na cokolwiek, a na dodatek w ciągu ostatnich dni została otworzona kolejna edycja konkursu z Proxxonem, przyszedł czas na zrealizowanie tego planu. Tym samym z wielką przyjemnością prezentuję robota mobilnego klasy micromouse: Let Me Out 1. Pomysł Podczas zeszłorocznych wakacji moje zainteresowanie zostało skierowane w kierunku dwóch zagadnień: roboty klasy micromouse oraz silniki krokowe. Z tego pierwszego bardzo szybko podjąłem decyzję o budowie takiego robota. Interesując się zaganieniem drugim (silników krokowych), dowiadując się o ich możliwościach i ograniczeniach zacząłem się zastanawiać nad ich wykorzystaniem w robocie klasy micromouse. Niestety, przewalając internet dniami i nocami nie znalazłem żadnego sensownego opisu zrealizowanej i zbadanej konstrukcji napędu robota mobilnego opartego na silnikach krokowych. W ten sposób narodził się pomysł o zaprojektowaniu, zbudowaniu i przetestowaniu takiego rozwiązania. 2. Założenia projektowe • Spełnienie podstawowych warunków konstrukcyjnych oraz programowych zawartych w regulaminie konkurencji micromouse. Robot projektowany był tak, żeby mógł wziąć udział w zawodach w Polsce. • Oparcie projektu o procesor z rodziny AVR W tamtym momencie STM-y dopiero wynurzały mi się zza horyzontu, więc zdecydowałem się na popularnego AVR-a, którego już dobrze znałem i umiałem go programować. • Konstrukcja umożliwiająca poruszanie się po skosie labiryntu Aby móc zastosować bardziej złożone algorytmy przemierzania labiryntu. • Zastosowanie silników krokowych jako napęd główny robota • Umożliwienie bezprzewodowej komunikacji z robotem Głównie w celu odbierania danych o aktualnym stanie zmapowania labiryntu przez robota i możliwości wizualizacji aktualnej sytuacji na komputerze. • Zaprojektowanie płytki PCB w sposób umożliwiający wykonanie jej metodą fototransferu Oczywiście w celu zaoszczędzenia na czasie i funduszach, zdecydowałem się na warsztatową metodę wykonywania płytki. • Implementacja algorytmu pozwalającego na rozwiązywanie algorytmu metodą "floodfill" 3. Konstrukcja Mechaniczna 3.1 Napęd 3.1.1 Silniki Jako napęd zdecydowałem się na użycie silników krokowych. Zalety silników krokowych (+) Sterowanie pozycją - dokładne sterowanie w otwartej pętli sterowania (+) Silnik pracuje z pełnym momentem w stanie spoczynku (+) Żywotność silnika wyznaczona wytrzymałością łożysk i cewek - brak szczotek Wady silników krokowych (-) Przeznaczone do pracy z małymi prędkościami (-) Możliwość wystąpienia zjawiska "gubienia kroków" (-) Duża emisja ciepła (-) Duża masa i rozmiary (-) Skomplikowany sposób sterowania Ze wszystkich silników krokowych dostępnych na polskim rynku, silniki o kodzie producenta S20STH30-0604A firmy Pololu najbardziej nadawały się do projektowanej konstrukcji. Porównanie parametrów wybranych silników krokowych z popularnymi mikrosilnikami Pololu Parametr • Silnik krokowy • Mikrosilnik Pololu 30:1 Waga • 60g • 10g Wymiary • 20 x 20 x 30 mm • 10 x 12 x 24 mm Napięcie zasilania • 3.9 V • 3-9 V Pobór prądu • 600 mA • 120-1600 mA Moment obrotowy • 140 g*cm (0.017 Nm) • 600 g*cm (0.059 Nm) Średnica wału • 4 mm • 3 mm Cena • 100 zł • 70zł Sterowanie • Trudne • Proste Problemy do rozwiązania w projektowaniu napędu opartego o silniki krokowe: Problem: Silniki krokowe przeznaczone są do pracy przy niewielkich prędkościach obrotowych (zazwyczaj 4-10 RPS to ich maksymalne osiągi). Rozwiązanie: Zasilanie silników z dużo wyższego napięcia (w tym wypadku 24 V). Pozwala to na skrócenie czasu narastania prądu na cewkach, prez co można je przełączać częściej, w efekcie uzyskując wyższą prędkość obrotową. (Udało mi się rozkręcić te silniki do 45 RPS - w powietrzu, nie na jadącym robocie) Problem: W robocie potrzebne jest napięcie 24 V Rozwiązanie: Zasilanie silników z przetwornicy step-up, generującej 24 V z napięcia zasilania (7.4 V bądź 15.8 V) Problem: Zasilając silnik z wyższego napięcia, prąd na cewkach będzie proporcjonalnie większy, co po przekroczeniu wartości nominalnej (600 mA) prowadzić będzie do ich spalenia Rozwiązanie: Zastosowanie gotowego modułu sterownika silnika krokowego z ogranicznikiem prądu (funkcja Chopper) 3.1.2 Koła Jako koła wybrano gumowe koła firmy Solarbotics o średnicy 2.8 mm i szerokości 13 mm. Koła mają świetną przyczepność i doskonale nadają się do tego zastosowania. Jedyną jak dotąd zaobserwowaną wadą jest bardzo duża zdolność do zbierania kurzu i drobnych odpadów, przez co jazda po zabrudzonej powierzchni bardzo szybko doprowadza do zmniejszenia przyczepności kół. 3.1.3 Mocowania silników Niestety na rynku nie istnieją mocowania do silników krokowych w tym rozmiarze (Nema 8), więc musiałem takie mocowania wyprodukować sam. Mocowania silników zostały zaprojektowane w programie TinkerCad dostępnym w wersji przeglądarkowej. Zamówienie przyjęło i wykonało techniką druku 3D koło naukowe działające przy Politechnice Wrocławskiej "Rapid Troopers". Mocowania zawierają 4 otwory na śruby mocujące silnik do elementu, oraz 4 otwory na śruby służące do przytwierdzenia silnika wraz z mocowaniem do platformy. 3.1.4 Podwozie Jako podwozie wykorzystałem płytkę PCB z elektroniką, przedstawioną w dalszej części artykułu 4 Elektronika Schemat elektroniczny jak i płytka PCB zostały zaprojektowane w programie CadSoft Eagle. 4.1 Zasilanie Robot może być zasilany z jednego bądź dwóch (połączonych szeregowo) akumulatorów Li-Po 7.4 V o pojemności 250 mAh. Dwa akumulatory stosowane są w celu podwyższenia napięcia na wejściu przetwornicy, co skutkuje obniżeniem poboru prądu z akumulatora i wydłużeniem możliwego czasu działania robota. 4.1.1 Zasilanie silników Silniki zasilane są napięciem 24 V podawanym z przetwornicy step-up opartej o układ XL60098. Przy pracy pobierają 1 - 1.2 A. 4.1.2 Zasilanie logiki Wszystkie układy logiczne zasilane są napięciem 5 V uzyskiwanym z przetwornicy step-down D24V6F5. Powodem zastosowania przetwornicy zamiast stabilizatora liniowego jest różnica napięć na wejściu i wyjściu układu. Występuje tu obniżenie napięcia z ~16 V do 5 V, co przy stabilizatorze liniowym generowałoby bardzo duże ilości ciepła i mogłoby prowadzić do jego uszkodzenia lub poparzenia użytkownika podczas obsługi robota. 4.2 Procesor Jednostką sterująca całego robota jest ośmiobitowy procesor AVR Atmega 128 firmy Atmel, taktowany zewnętrznym kwarcem 16 Mhz. Procesor zasilany jest napięciem 5 V. W celu zmniejszenia rozmiarów robota, zastosowano procesor w obudowie TQFP64. 4.3 Czujniki odległości Jako czujniki odległości zastosowano diodę LED SFH4550 działającą w paśmie podczerwieni. W robocie umieszczono 6 takich zestawów. Dwa skierowane w przód, dwa na boki oraz dwa odchylone od diametralnej robota o 45°. Prąd płynący przez diody IR to 95 mA, co daje wystarczające natężenie światła do dokładnego odczytywania odległości przy jednoczesnym braku konieczności uważania na przepalenie się diody spowodowane długim świeceniem przy zbyt dużym prądzie. 4.4 Sterowniki silników Zastosowano sterowniki firmy Pololu oparte na modula A4988. Sterowniki pozwalają na pracę w trybach: pełnokrokowym, półkrokowym, ćwierćkrokowym, 1/8 oraz 1/16 kroku. Funkcja ograniczania prądu (chopper) pozwala sterować silniki wyższym napięciem bez ryzyka uszkodzenia cewek silnika. Kolejną zaletą zastosowania sterowników silników krokowych jest możliwość sterowania silnika za pomocą tylko jednego pinu (tylko jeden pin mikrokontrolera podaje sygnał częstotliwościowy odpowiedzialny za taktowanie silnika). W celu umożliwienia generowania sygnałów o różnej częstotliwości, każdy ze sterowników obsługiwany jest przez inny timer. Obydwa szesnastobitowe timery sterujące działają w sprzętowym trybie Clear on Compare Match. Pozwala to na automatyczne generowanie sygnału o zadanej częstotliwości bez udziału samej jednostki obliczeniowej. 4.5 Interfejs komunikacyjny Jako interfejs komunikacyjny robota służą dwie diody LED, buzzer, interfejs UART wraz z modułem bluetooth HC-05 oraz dwa przyciski. Programowanie robota realizowane jest poprzez interfejs SPI. 4.6 Płytka PCB Płytka PCB na której zostały umieszczone wszystkie elementy robota została zaprojektowana za pomocą programuy CadSoft Eagle. Długość: 101 mm Szerokość: 94 mm Płytka pełni jednocześnie funkcję podwozia robota. Takie wymiary pozwalają na swobodny obrót robota w miejscu między ścianami, oraz jazdę po skosie w labiryncie. Płytka w swoim kształcie jest symetryczna, lecz główna masa elementów skupiona została przy tylnej części. Powoduje to brak efektu kołysania się robota ze względu na dociśnięcie tyłu do podłoża. Płytka została stworzona metodą fototransferu oraz wytrawiona w warunkach domowych. Otwory wykonano na wiertarce stołowej. Prostokątny otwór na środku płytki jest miejscem na wystające elementy silników, w których znajdują się gniazda przewodów zasilających. Warstwa Top zawiera wszystkie układy scalone, czujniki, silniki, akumulatory i złącza. W przedniej części robota znajdują się czujniki, mikrokontroler, układ ULN2003 (sterowanie diodami LED) oraz jeden z akumulatorów. Z tyłu umieszczono sterowniki silników krokowych, obydwie przetwornice, moduł bluetooth, drugi akumulator oraz buzzer. Silniki znajdują się w osi symetrii robota Na dolnej stronie płytki umieszczono jedynie kilka rezystorów oraz slizgacz, znajdujący się w diametralnej robota, w jego tylnej części. Zdjęcie poniżej pokazuje stopień upakowania elementów i modułów w robocie. 5 Oprogramowanie Główną częścią projektu było rozwinięcie oprogramowania związanego z obsługą peryferii oraz algorytmem rozwiązującym labirynt. Program napisany został w języku C. 5.1 Pomiary odległości Pomiar z każdego z czujników dokonywany jest z częstotliwością 200 Hz. Zastosowano pomiar różnicowy z uśrednianiem wyników. 5.2 Sterowanie prędkością robota Prędkość robota sterowana jest częstotliwością sygnału podawanego na sterowniki silników. 5.3 Algorytm Zaimplementowany algorytm opiera się na algorytmie Dijkstry, służącym do znajdywania najkrótszej drogi w grafie. 6 Podsumowanie Projektowanie, budowa oraz zaprogramowanie robota zostały zrealizowane zgodnie z założeniami. Robot dobrze radzi sobie w labiryncie. 6.1 Sprawność silników krokowych w robocie mobilnym Podczas jazdy kroki są gubione dość rzadko, co pozwala na wystarczająco dokładne wysterowanie robota w otwartej pętli sterowania z kompensacją pozycji od czujników odbiciowych. Osiągane maksymalne prędkości podczas testów (oczywiście poza labiryntem i po prostej) sięgają 2 m/s. Głównymi wadami tych silników w robocie są ich masa, wielkość, konieczność stosowania sterowników silników krokowych oraz wyższego napięcia. Kolejną wadą jest konieczność ograniczania przyspieczeń, w celu zminimalizowania gubionych kroków. Zaletą stosowania silników krokowych jest brak konieczności stosowania sprzężenia zwrotnego w postaci enkoderów obrotowych. Sterowanie robotem klasy (2.0) w otwartej pętli regulacji Sterowanie w otwartej pętli regulacji z wykorzystaniem silników krokowych jest możliwe. Rozwiązanie to jest wygodniejsze i prostsze do zrealizowania, aczkolwiek posiada bardzo dużą wadę, w postaci braku informacji o gubionych ktokach. Cała kalibracja pozycji opierać musi się na odczytach z czujników odbiciowych. Budowa tego robota z pewnością przyczyniła się do znacznego poszerzenia mojej wiedzy na temat budowy robotów mobilnych, projektowaniu schematów elektronicznych oraz płytek PCB, kategorii micromouse oraz silników krokowych. Niestety nie miałem dostępu do pełnowymiarowego labiryntu, dlatego filmiki z testów są tylko na ćwiartce labiryntu. Robot jeździ wolno, bo w momencie kiedy zaczął działać i poprawnie rozwiązywać labirynt, semestr zaczął być tak gorący że musiałem porzucić prace nad jego rozwojem i zająć się studiami. Na pewno może jeździć o wiele szybciej - pozostaje tylko kwestia gubienia kroków. Zeby pokazać w sumie clue sprawy związanej z zastosowaniem silników krokowych, poniżej filmik na którym robot jedzie z wyłączonymi czujnikami, z wgraną na stałe sekwencją (prosto, prawo, lewo, prosto itp.) Widać jak dokładne może być pozycjonowanie się na silnikach krokowych (które i tak dobierane było "na oko"). Jazda bez sprzężenia od czujników A tutaj testy na labiryncie. Robot rozwiązujący labirynt Nie chcę się już bardziej szczegółowo rozpisywać na poszczególne tematy, żeby artykuł nie rozrósł się do rozmiarów nieczytelnych. Jeśli kogoś interesują detale budowy tego robota i używania tego napędu, zapraszam do dołączonej w załącznikach prezentacji oraz raportu z budowy robota. Jeśli jesteś zainteresowany schematami elektronicznymi tego robota - napisz w komentarzu. KoNaR - Bartlomiej Kurosz - Micromouse Let Me Out.pdf Zastosowanie silnikow krokowych w robotach mobilnych.pdf
  23. zandarmerio

    A

    Przedstawiam robota typu linefollower, którego razem z kolegą wykonaliśmy w ramach projektu "Roboty mobilne" na PWr. Cechą odróżniającą go od innych konstrukcji tego typu jest możliwość zapamiętywania trasy. Robot wykonuje pierwszy przejazd ze stosunkowo wolną prędkością i dla każdego punktu trasy oblicza maksymalną możliwą prędkość, która pozwoli na przejazd bez poślizgu. Wiedza ta jest używana w celu zoptymalizowania czasu przejazdu podczas drugiego pokonywania trasy. Sercem robota jest mikrokontroler STM32F103RBT6. Do napędu służą silniki Pololu 10:1 HP (przy okazji - są beznadziejne) wspomagane enkoderami AS5040. Do wykrywania linii przewidziano 12 czujników KTIR, przy czym aktualnie używanych jest 8 (resztę przyjarałem hotem podczas lutowania i nie działają ). Napięcie 3,3V dla logiki pochodzi z przetwornicy MCP16301, natomiast silniki są zasilane bezpośrednio z akumulatora poprzez mostek MC33932. Oprócz tego na płytce zainstalowany jest akcelerometr/żyroskop MPU6050 (aktualnie niewykorzystany), 4 ledy, 3 przyciski oraz wyprowadzone złącza UART i SPI (dla modułu radiowego NRF24L01). Algorytm sterowana obejmuje regulatory PID dla prawego i lewego koła oraz regulator PID dla rotacji. Wartość translacji jest ustalana na sztywno lub jest uzależniona od aktualnego położenia robota na trasie (w przypadku drugiego przejazdu). Jazda ze sztywno zadaną prędkością, zdaje się 1,8m/s Zapamiętywanie trasy (film zawiera lokowanie produktu) Jeśli chodzi o robota to jestem bardzo pozytywnie zaskoczony działaniem zapamiętywania trasy. Do zrobienia pozostało uwzględnianie przyspieszeń liniowych przy wyznaczaniu profilu przejazdu, gdyż aktualnie obliczane jest tylko przyspieszenie dośrodkowe. Głównym problemem przy konstrukcji robota były notorycznie palące się silniki. Dwa spaliły się całkowicie, w jednym wytarła się zębatka, a szczotki były wymieniane chyba z pięć razy. W następnych konstrukcjach mam zamiar używać tylko silników BLDC. edit: Schemat Layout płytki głownej bom.txt
  24. Vampire2 to moja druga konstrukcja micromouse. W porównaniu z pierwszą konstrukcją (Vampire) wprowadzono pewne zmiany mechaniczne jak dodanie żyroskopu, zmiana enkoderów oraz zmniejszenie wymiarów płyty PCB. Konstrukcja mechaniczna i zasilanie Podwoziem robota jest płyta PCB wykonana w firmie Satland Prototype. Napędem są silniki Pololu 30:1 sterowane za pośrednictwem mostka TB6612. Koła standardowe Pololu. Ostatecznie udało się uzyskać myszkę o wymiarach maksymalnych 95x75mm, co pozwala poruszanie się po skosie. Prześwit robota został ustawiony dla bezpieczeństwa na 4mm. Maksymalna prędkość jaką udało mi się uzyskać na tych silnikach to 1.6m/s. Robot zasilany jest z akumulatora litowo-polimerowego. W tej chwili jest to Pakiet LiPol Dualsky 150mAh 7.4V. Pakiet spokojnie wystarcza na wykonanie przejazdów podczas zawodów. Elektronika Mózgiem robota jest mikrokontroler STM32F407VGT6. Głównymi cechami są: taktowanie 168 MHz, 192kB RAM, 1MB flash, duża liczba peryferii z czego wiele ze wsparciem DMA, sprzętowa obsługa wejść kwadraturowych, wiele dostępnych interfejsów komunikacyjnych. Model ten stosowany jest w płytce ewaluacyjnej Discovery, dzięki czemu po testach z płytką ewaluacyjną kod nie wymagał żadnych zmian aby przenieść go na robota. W konstrukcji użyto enkodery magnetyczne AS5306 oraz magnesy zamocowane na obręcze kół z 72 polami magnetycznymi. W rezultacie z enkoderów otrzymujemy 5700 imp/obrót co daje dokładność 0,017 mm/imp. Jako dalmierzy użyto diod podczerwieni SFH4511 w parze z fototranzystorami TEFT4300. Diody sterowane są poprzez układ ULN2003, każda osobno. Dalmierze zapewniają dość dobrą charakterystykę w zakresie 0-20 cm. Robot wyposażony jest w żyroskop cyfrowy L3GD20. Posiada on bardzo mały dryf, zakres do +-2000st/s oraz interfejs SPI. Interfejs użytkownika Do wybierania trybów pracy wykorzystano 4 przyciski. Na płycie są również 4 diody. Płyta posiada wyprowadzenie dla wyświetlacza z telefonu Nokia 3310, który obecnie nie jest zamontowany. Wyprowadzony został również interfejs UART do komunikacji z PC. Oprogramowanie Oprogramowanie w dalszym ciągu jest rozwijane. W aktualnej wersji uzyskano stabilną jazdę w labiryncie. Algorytm pozwala na przeszukiwanie labiryntu pole po polu z zatrzymywaniem się na każdym polu. Wyszukiwanie trasy przy użyciu algorytmu floodfill z dodanymi różnymi wagami dla prostych i zakrętów, odpowiednio 1 i 3. Sterowanie dynamiką bazuje na pomyśle opisanym w [Programowanie] Sterowanie robotem mobilnym klasy (2,0) . Podsumowanie Robot spełnił moje oczekiwania. Pierwszy cel, czyli stabilne i przewidywalne zachowanie w labiryncie, został osiągnięty. Trwają prace nad rozwojem algorytmu przeszukiwania aby możliwe było przeszukiwanie bez zatrzymywania się, a w przyszłości również wymiana i przystosowanie robota do silników z przekładnią 10:1. Galeria Osiągnięcia I miejsce w kategorii MicroMouse na zawodach Robomaticon 2013 w Warszawie Pozdrawiam
  25. Przedstawiamy robota klasy Line Follower o nazwie Impact. Jest to ulepszona wersja poprzedniej konstrukcji opisanej na największym forum polskiej robotyki amatorskiej . Robot powstał w 2011 roku, do tej pory był zwycięzcą wszystkich zawodów, w jakich brał udział. Największym sukcesem jest niewątpliwie pierwsze miejsce w międzynarodowym turnieju robotów w Wiedniu, nazywanych przez wielu nieoficjalnymi mistrzostwami Europy. Robot składa się z dwóch modułów: płytki głównej oraz płytki z czujnikami, połączonych ze sobą za pomocą lekkich listew węglowych. Masa całości z akumulatorem to 105 g. Moduł z czujnikami Jest to element najdalej wysunięty od środka obrotu. Moment bezwładności jest stosunkowo duży (masa pomnożona przez kwadrat odległości od środka obrotu), dlatego też aby móc wysunąć daleko czujniki, masa płytki powinna być możliwie najmniejsza. W poprzedniej wersji zastosowaliśmy 19 czujników, z czego 16 ułożonych w łuk, 4 wysunięte odpowiednio do przodu oraz do tyłu. Na płytce znajdowały się także komparatory i potencjometr do ustawiania wartości progowej (Rys. 1). Rys. 1 Układ czujników w poprzedniej konstrukcji. W nowym module zastosowaliśmy 14 sensorów, umieszczonych w większych odległościach od siebie. Dzięki temu rozpiętość skrajnych czujników pozostała bez zmian. Zlikwidowane zostały czujniki wysunięte do przodu. Okazało się, że przy dużych prędkościach, biorąc pod uwagę bezwładność napędu, robot nie był w stanie efektywnie zareagować na sygnał z nich pochodzący. Dzięki zmniejszeniu liczby czujników, pojawiła się możliwość skorzystania z wbudowanego w mikrokontroler przetwornika analogowo-cyfrowego (16 multipleksowanych wejść), pozwoliło to zrezygnować z komparatorów. Bez tych dodatkowych układów, rozmiary płytki uległy zmniejszeniu. Zmieniliśmy także grubość laminatu 1,5mm na 0,8mm. Zabiegi te doprowadziły do dwukrotnego obniżenia masy płytki z 8 do 4g. Wygląd modułu przedstawiony na rysunku 2. Rys.2 Widok płytki z czujnikami w aktualnej, nowej wersji robota. Do wykrywania linii użyte zostały transoptory odbiciowe KTIR0711S . Podłączone w grupach: szeregowo po 3 czujniki z rezystorem. Na płytce zostały umieszczone pady dla cyfrowego czujnika odległości Sharp 40cm. Moduł główny Płytka jest zarówno obwodem drukowanym jak i podwoziem konstrukcji. Oprócz układów elektronicznych umieściliśmy na niej silniki napędowe oraz napęd tunelowy. Udało się znacznie zmniejszyć moduł w stosunku do poprzedniej wersją. Wymiary wynoszą: 140 mm x 60mm. Elektronika Sercem robota jest mikrokontroler z rodzimy STM32. Silnikami sterują mostki H TB6612. Tor zasilania składa się z przetwornicy impulsowej 5V oraz stabilizatora liniowego 3,3V. Mikrokontroler - 32-bitowy STM32F103RBT6 z rdzeniem firmy ARM Cortex-M3 posiadający miedzy innymi: 128kB Flash, 20kB RAM, USB, CAN, UART, I2C,SPI, ADC, DAC w obudowie LQFP64, spełnia następujące zadania: odczyt stanów portów wejściowych, przetwarzanie sygnału analogowego na postać cyfrową, generowanie sygnału PWM, sterowanie mostkami H – generowanie odpowiednich sygnałów, realizacja algorytmu sterownia, komunikacja z modułem LCD, sterowanie diodami LED. Sterowniki silników - dwa dwukanałowe mostki H Toshiba TB6612, umożliwiające: kontrolę prędkości obrotowej za pomocą sygnału PWM, zmianę kierunku obrotów silnika przy pomocy zmiany stanów dwóch wyprowadzeń, szybkie hamowanie. Aby zabezpieczyć się przed uszkodzeniem układu przy poborze maksymalnego prądu przez silniki (1600mA) kanały A i B mostków zostały połączone (wydajność prądowa wzrosła do 2A). Mostki zostały podłączone w sposób pokazany na rysunku 3. Rys. 3 Schemat podłączenia sterownika silników. Kontrola zdalna Ze względu na osiągane wysokie prędkości podczas przejazdu utrudnieniem staje się zatrzymywanie robota w sposób ręczny. Uruchamianie i zatrzymywanie odbywa się w sposób bezprzewodowy, z wykorzystaniem podczerwień. Zastosowany układ ATtiny13 odpowiedzialny jest za dekodowanie sygnału z pilota, który nadaje sygnał w standardzie RC5. Rozwiązanie opracowane przez firmę Philips zwiększa odporność na zakłócenia z otoczenia oraz stwarza możliwość użycia uniwersalnych i ogólnodostępnych pilotów. Kolejnym atutem jest łatwość wykorzystania dodatkowych przycisków znajdujących się na pilocie. Dodatkowy procesor został użyty ze względu na wysokie wymagania co do niezawodności działania zdalnego zatrzymywania, np. w sytuacjach awaryjnych. Napęd Napęd stanowią dwa silniki Pololu HP z przekładnią 10:1 o następujących parametrach technicznych: Obroty na biegu jałowym przy zasilaniu 6V: 3000 obr./min, Prąd biegu jałowego (6V): 120mA, Prąd szczytowy: 1600mA, Moment obrotowy: 0,3 kg*cm (29 mNm), Wymiary: 24 x 10 x 12 mm, Masa: 10g. Koła składają się z felg wytoczonych z tworzywa sztucznego poliamid oraz specjalnie dobranych opon. Felga jest ciasno pasowana na wał silnika oraz zabezpieczona klejem cyjanoakrylowym (Rys. 4) Rys. 4 Koła wytoczone z poliamidu wraz z oponami Mini-Z. Przetestowane zostały rożne rodzaje ogumienia. Najlepszym wyborem okazały się opony stosowane w modelach samochodów Mini-Z. Są to opony o szerokości 12mm i grubości 3 mm. Kolejnym parametrem jest twardość, która wynosi 20° (w skali 10°-60°). Opony o mniejszej twardości charakteryzują się większą przyczepnością, jednak szybciej się zużywają. Średnica felgi z oponą to 27mm. Bardzo ważną kwestią jest również czystość opon. Przed każdym przejazdem są one czyszczone w celu usunięcia drobinek kurzu, które powodują utraty przyczepności i mają negatywny wpływ na osiągi. Teoretyczna maksymalna prędkość liniowa robota w granicy 3m/s. W zależności od trasy, uzyskiwane średnie prędkości wynoszą 2,3-2,5 m/s. Napęd tunelowy Ważnym elementem jest napęd tunelowy EDF. Jest to turbina, taka jaką stosuje się w modelach latających, jednak zamontowana odwrotnie. Element ma za zadanie wytworzyć dodatkową siłę docisku, która pomaga robotowi utrzymać się na trasie w zakrętach przy dużych prędkościach (powyżej 2m/s). Turbina wyposażona jest w silnik bezszczotkowy ( 11000 obr./min. pobór prądu około 4A), którym steruje kontroler firmy Dualsky. Rys. 5 Napęd tunelowy EDF27 z sterownikiem silnika. Zasilanie Do zasilania robota użyty został pakiet Litowo-Polimerowy Dualsky 220mAh 25C 7,4V (Rys. 6). Prąd ciągły jaki jest w stanie zapewnić pakiet to 5,5A, natomiast szczytowy to 11A co w zupełności wystarcza do poprawnego zasilania. Akumulator pozwala na ok. 30 sekund optymalnej jazdy, po tym czasie napięcie zasilania spada co negatywnie wpływa na dynamikę i prędkość maksymalną robota. W trakcie zawodów wymiana akumulatorów następuje z reguły co 2 przejazdy co pozwala na wykorzystanie pełnej mocy silników. Duży wpływ na zastosowanie tak małego pakietu miała masa, która wynosi ok. 16 gram. Rys. 6 Zastosowany akumulator Dualsky 220mAh . Bezpośrednio z akumulatora zasilane są silniki oraz napęd tunelowy. Elementy elektroniczne wymagające napięcia 5V zasilane są napięciem stabilizowanym przy pomocy regulowanej przetwornicy ST1S10PHR o wydajności prądowej do 3A. Zasilanie procesora czyli 3,3V pochodzi z liniowego układu LDO (low-dropout) LF33CT, którego napięciem wejściowym jest pochodzące z przetwornicy 5V. Schemat zasilania przedstawiony na rysunku 7. Rys. 7 Schemat blokowy toru zasilania. Interfejs użytkownika Ustawianie regulatora wymaga częstych zmian parametrów takich jak: maksymalna prędkość obrotowa silników napędzających, prędkości wirnika turbiny czy wzmocnień regulatora PID. Podłączanie robota do komputera po każdym przejeździe, szczególnie na zawodach gdzie stanowiska serwisowe znajdują się w pewnych odległościach od trasy było bardzo uciążliwe. Powstał moduł z wyświetlaczem LCD do podglądu ustawień oraz przyciskami do ich regulacji. Jak wspomniano wcześniej masa jest parametrem kluczowym dlatego układ jest osobnym modułem, łączącym się z robotem za pomocą interfejsu UART. Głównymi funkcjami modułu są: wybór nastaw regulatora, wybór prędkości maksymalnej, wybór prędkości obrotowej wirnika turbiny napędu tunelowego, sprawdzenie poprawności działania czujników, podgląd danych wyjściowych regulatora PID, ustawienie wartości napięcia progowego dla czujników odbiciowych. Rys 8. Moduł z wyświetlaczem LCD. Oprogramowanie Oprogramowanie zostało napisane w języku C przy użyciu bibliotek udostępnionych przez firmę STM: STM32F10x_StdPeriph_Lib_V3.5.0 . Algorytm sterowania to PID z pewnymi modyfikacjami. Dotychczasowe osiągnięcia: 1. miejsce T-BOT – Wałbrzych - 2012 1. miejsce Robomaticon – Warszawa - 2012 1. miejce Robot Challenge – Wiedeń - 2012 1. miejsce Trójmiejski Turniej Robotów - Gdańsk - 2012 1. miejsce CybAirBot - Poznań - 2012 Zdjęcia Filmy Autorzy: Bartosz Derkacz Szymon Mońka KNIM - Politechnika Wrocławska
×