Skocz do zawartości

Alvedro

Użytkownicy
  • Zawartość

    139
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    3

Alvedro wygrał w ostatnim dniu 16 listopada 2017

Alvedro ma najbardziej lubianą zawartość!

Reputacja

35 Bardzo dobra

1 obserwujący

O Alvedro

  • Ranga
    5/10
  • Urodziny 16.08.1996

Informacje

  • Płeć
    Mężczyzna
  • Lokalizacja
    Warszawa
  • Języki programowania
    C/C++
  • Zawód
    Embedded Developer

Ostatnio na profilu byli

658 wyświetleń profilu
  1. W jaki sposób wyznaczasz prędkość do trybu stałej prędkości obrotowej? Czy na obliczoną prędkość nakładasz jeszcze jakieś filtry? Twoim wejściem do pid'a jak rozumiem jest różnica między aktualną prędkością, a docelową, co jest wyjściem regulatora, czy to jest parametr vq, który podajesz później do algorytmu foc'a? Słyszałeś o cogging torque (nie wiem jaki jest polski odpowiednik), jeśli tak to czy planujesz rozwinąć algorytm, który by ten efekt minimalizował?
  2. Czy planujesz do FOC'a (oprócz enkodera) wrzucać również prądy?
  3. Bardzo ciekawy projekt, szczególnie, że planujesz wykorzystać silniki BLDC i sterowanie FOC, będę śledził. Zastanowiłbym się nad mikrokontrolerem, rodzina F1 jest już stosunkowo stara. Jak rozumiem jest to projekt rozwojowy, więc nie musisz jakoś specjalnie optymalizować sprzętu, żeby kosztował jak najmniej, a jednocześnie spełniał wszystkie założenia jak najoptymalniej. Polecałbym coś z FPU, już chociażby coś z rodziny F3 może być lepszym wyborem, ze względu na to, że będziesz wykorzystywał filtry do fuzji danych z IMU, może Kalman, Madgwick/Mahony, na pewno zauważysz różnice w czasach wykonywania się filtrów z FPU i bez niego, może warto jeszcze to przemyśleć. Dodatkowo, na przykładowo takim F303xx z zewnętrznym kwarcem będziesz mógł taktować timer z dwukrotnie większą częstotliwością niż sam rdzeń, czyli np. 144 MHz, więc będziesz mógł mieć jednocześnie większą rozdzielczość PWM, czy zauważysz różnicę, nie wiem, ale dlaczego kosztem paru złoty by się nie przekonać i nie potestować.
  4. Aż głupio się przyznać, ale przy zamawianiu wkradł mi się błąd i zamiast układu MMC5983MA zamówiłem MMC5883MA, a ten układ komunikuje się jedynie po I2C. Zamawiam teraz już ten właściwy i jak przyjdzie to dam znać czy konfiguracja była poprawna.
  5. Cześć, to już któryś wieczór, kiedy siedzę i próbuję zrozumieć dlaczego nie mogę połączyć się z magnetometrem MMC5983MA po SPI, więc postanowiłem się podzielić problemem. Na własnej płytce mam STM32F4, kilka układów na SPI1, SPI5, które działają i nieszczęsny magnetometr MMC5983MA na SPI2, który korzysta z tych samych funkcji, lecz nie chce rozmawiać. Odbiór danych w kodzie wygląda tak: uint8_t bufferSize = 2U; uint8_t readWriteBit = 0x80; uint8_t timeout = 10U; uint8_t productIdAddress = 0x2F; uint8_t txBuffer[2] = { productIdAddress | readWriteBit, 0x00 }; uint8_t rxBuffer[2] = { 0 }; HAL_GPIO_WritePin(MMC5983MA_SPI2_CS_GPIO_Port, MMC5983MA_SPI2_CS_Pin, GPIO_PIN_RESET); HAL_SPI_TransmitReceive(&hspi2, txBuffer, rxBuffer, bufferSize, timeout); HAL_GPIO_WritePin(MMC5983MA_SPI2_CS_GPIO_Port, MMC5983MA_SPI2_CS_Pin, GPIO_PIN_SET); Na analizatorze wygląda to tak, układ w ogóle nie macha linią MISO: Konfiguracja SPI2 z CubeMX: Schemat: Sekwencja zapisu/odczytu SPI: Przykład połączenia: Rejestr, który próbuję odczytać: Mam polutowane 4 płytki i na żadnej z nich nie udało mi się nawiązać połączenia, nie jest to dowód na to, że z pcb na pewno jest wszystko w porządku, ale chciałbym najpierw potwierdzić, że sposób odczytu danych od strony programowej jest poprawny. W erracie używanego procka nie ma żadnej wzmianki, która mogłaby mieć bezpośredni związek z moim problemem. Czy ktoś ma jakiś pomysł co mogę jeszcze sprawdzić? Edit: Płytki wypiekam w piecu IR, rampa jest bardzo zbliżona do tej z dokumentacji układu magnetometru, do tej pory nie udało mi się upalić pozostałych układów, więc obstawiałbym, że proces lutowania ich nie zabija.
  6. Posiadam kamerę Sony FCB-EV7520 (dokumentacja w załączniku), której wyjściem wideo jest sygnał w postaci YPbPr 4:2:2 wysyłany za pomocą interfejsu LVDS. To czego potrzebuje to napisanie programu na układ FPGA, który odbierze sygnał LVDS, przekształci go i wypuści sygnał zgodny ze standardem HDMI lub USB. Nie jest to coś nowego, bo tego typu urządzenia są w sprzedaży, lecz są drogie 350€ i mają już konkretny kształt, a w przyszłości chciałbym móc to zamknąć na swojej PCB. Jeżeli masz doświadczenie z FPGA, szczególnie z przetwarzaniem wyżej wymienionych sygnałów wideo to zapraszam do kontaktu. Jestem zainteresowany kompleksowym rozwiązaniem, ale również jestem otwarty na współpracę na zasadzie wskazania kierunku, zasugerowania możliwego rozwiązania i pomocy w wyborze odpowiedniego sprzętu. FCB-EV7520_Manual.pdf 22_FCB-EV7520A_S.pdf
  7. Właśnie ja jestem zdania, że albo koszulka jest czysta i zawiera jedynie logotypy samych zawodów i wtedy za nią płacę lub zawiera dodatkowo logotypy sponsorów, jest jednocześnie reklamą i wtedy zawodnicy dostają ją gratis. Tutaj było tak pomiędzy, bo był chyba tylko jeden logotyp sponsora, ale jednak.
  8. Bardzo fajna konstrukcja. Kilka pytań: 1. Dlaczego przełożenie w silniku 10:1, odcinki proste często są krótkie, więc chyba rzadko jesteś w stanie rozpędzić go do maksymalnej prędkości, nie lepiej mieć większe przyspieszenie kosztem niższej maksymalnej prędkości? 2. I2C nie lubi za bardzo zmiennego pola magnetycznego, możliwe, że to powodowało problemy z VL53L1X. Jak przez BLDC przepuszczałem sygnały I2C to przewody zasilające silnik przepuszczałem kilkukrotnie przez koralik ferrytowy. 3. Gdzie dorwałeś enkodery AS5047P? Ostatnio miałem problem, żeby dostać coś z enkoderów mangetycznych od AMS. 4. Jak omijasz przeszkodę? Na sztywno, metodą prób i błędów w przypadku niepowodzenia, czy coś bardziej zaawansowanego? 5. Wykorzystujesz zapamiętaną trasę? Co dokładnie zapisujesz? Obliczasz np. maksymalne prędkości, które pozwolą nie pokonanie zakrętu bez uślizgu itp.? 6. Myślałeś o czujniku optycznym z myszki? Może to zniwelować ewentualne poślizgi kół, tylko pytanie czy aż taka dokładność jest potrzebna. 7. Dlaczego nie ułożyłeś KTIR'ów jeszcze bliżej, tak by stykały się nawet obudowami obracając je o 90 stopni.
  9. Może jednak ktoś jeszcze dołączy do dyskusji, może któryś z organizatorów zawodów?
  10. Mikro streszczenie: Piszę to z perspektywy zawodnika Minisumo, więc weźcie to też pod uwagę. Pojawiło się dużo nowych zawodników, co bardzo cieszy, organizacyjnie bardzo słabo, duże opóźnienia, nagrodą za 2 miejsce w Minisumo były płytki od ST, bon na zakupy w Igusie i sporo różnych, ciekawych gadżetów, razem ok. 500 zł, więc całkiem dobrze. Już po zawodach, więc czas na podsumowanie. Na Robomaticonie prawie nieprzerwanie pojawiałem się od 2014 roku, więc mam pewną ciągłość i pogląd na to, w którą stronę organizacja zawodów się rozwijała. W tym roku starowałem w kategorii Minisumo i głównie na niej się skupiłem, więc dalsze podsumowanie będę pisał z tej właśnie perspektywy, więc należy to mieć na uwadze, że przebieg innych kategorii mógł być całkowicie odmienny. Zacznijmy więc od początku! Rejestracja przebiegła szybko, obsługiwało ją kilka osób, na plus to, że nie trzeba od razu wyciągać robota, ważyć go itd., tylko jest to robione przed walką, więc na spokojnie można się rozpakować w sali dla zawodników, ale to już raczej standard. Po wejściu na salę dla zawodników chwilę mi zajęło, żeby znaleźć wolne miejsce, raczej kilku stolików brakowało, bo osób na sali było dużo. Spędziłem tu nie wiele czasu, ale z tego co zdążyłem zauważyć to poinformowano nas o braku internetu, ze względu na to, że sieć tego nie wytrzyma i druga sprawa to, że nie słyszałem wywoływania zawodników do walk. Na sali był ring, więc nie było konieczności schodzenia i testowania robota na dole. O godzinie 10:15 wg harmonogramu miały wystartować konkurencje xSumo. Tak niestety się nie stało i zauważyłem, że ten problem pojawia się z roku na rok. Złożyło się na to wiele różnych czynników. Był problem z modułami startowymi, któregoś roku taki problem już wystąpił, nie wiem dlaczego, jest to już jakiś standard i wydawałoby się, że nic nie może pójść źle, a jednak. Również był problem z utworzeniem drabinek walk, dla Minisumo zajęło to najwięcej czasu, nie było jasne kto z kim, kiedy, drabinki były na bieżąco drukowane, później poprawiane, przekreślane, ale ostatecznie się udało. Dlaczego by nie skorzystać z jednego telewizora i na nim wyświetlać drabinki walk, czy wyświetlać kto teraz walczy, kto powinien się stawić przy ringu i też oznaczyć te ringi A, B, C, D itd., żeby nie było plątania się i szukania swojego ringu. Dodatkowo informacje to mogłyby być wyświetlane na stronie, każdy z zawodników byłby poinformowany pod jakim adresem może się z tymi informacjami zapoznać. Kolejny problem to rozpoczęcie xSumo od kategorii Legosumo. Jak wszyscy wiemy walki te są mało dynamiczne i trwają najczęściej najdłużej i dlatego są puszczane równolegle do walk z innych kategorii, by nie robić między nimi zależności czasowych. Tak mogłoby to być zorganizowane tutaj, ale za duża uwaga została poświęcona tej kategorii i wydaję mi się, że zabrakło osób, które zajęły by się przykładowo Minisumo, bo ringów było dużo i stały niewykorzystane. Nie trzymając dłużej w niepewności, pierwsza walka w Minisumo została przeprowadzona ok. 13:30(!) (słowo klucz: pierwsza walka). Tak duże opóźnienie było przyczyną innych sytuacji, które to opóźnienie jeszcze bardziej wydłużyło. Miało się zacząć o 10:15, lecz się nie zaczęło, więc co robić w czasie czekania. Można obejść stanowiska, porozmawiać, popatrzeć co się dzieje itd., ale ostatecznie zawodnicy powracali do sali dla nich przygotowanej, naturalna sprawa, każdy zazwyczaj ma coś jeszcze do zrobienia, więc mało kto bezczynnie czekał na dole. I to był błąd, ponieważ na początku sędziowie nie wywoływali zawodników z sali, nie było komunikacji(!) między miejscem rozgrywania walk a salą dla zawodników, więc niektórzy z miejsca byli dyskwalifikowani, nie wiem jak to się skończyło, czy dostali szansę na rozegranie walki. Początkowo swój głos zdzierała dziewczyna, której po pewnym czasie zrobiło mi się szkoda, bo przecież było nagłośnienie, były mikrofony, więc dlaczego by z nich nie skorzystać i oszczędzić swój głos. Później zaczęto wołać przez mikrofon, ale to dalej, zawodnicy w swojej sali nie byli w stanie tego usłyszeć, bo i jakim cudem. Rozumiem, że nie było bezpośredniego połączenia między salą dla zawodników a miejscem rozgrywki, lecz widziałem, że organizatorzy mieli miedzy sobą kontakt, więc to kwestia jednej osoby w sali dla zawodników z mikrofonem, każdy wtedy by wiedział, że jest wołany. Szczególnie powinno się o to zadbać kiedy jest tak duże opóźnienie, wiadomo, że nikt nie będzie przez 3 godziny czekał pod ringami, a chyba tego oczekiwali organizatorzy. Co do samych walk to jak to często bywa ringi nie są czyszczone. Kompletnie nie rozumiem sensu wyznaczania ćwiartek długopisem, dlaczego nie wydrukować krzyżyka tak jak to jest np. na ROBO~motion. Rzucanie długopisu, który potem i tak nie leży centralnie i trzeba go przesunąć, zmienia kilkukrotnie swój zwrot, nie jest na środku, w ogóle bez sensu. Wystarczyłby krzyżyk i zaznaczony jakimś odcieniem malutka kropka na środku i wtedy sędzia przykłada krzyżyk i wiemy gdzie dokładnie ustawić robota, jak się rozkładają ćwiartki z dużą dokładnością i mamy powtarzalność tego, co jest mimo wszystko też istotne. Z takich spraw ogólnych jeszcze to np. jako zawodnik Minisumo nie wiedziałem, że konkurencja Line Follower rozgrywana jest w innym miejscu, nie tam gdzie pozostałe kategorie, nie widziałem takiej informacji, ale mogę się mylić, może to moje przeoczenie. Nie wiedziałem też, że głosowanie w kategorii Freestyle odbywa się na Facebooku, dowiedziałem się przypadkiem już po fakcie, też nie wiem czy była gdzieś taka informacja widoczna. Sprawa dyskusyjna czy FB to dobre miejsce, czy nie oceniamy oprócz wyglądu i opisu też sposobu prezentacji, działania na żywo itd. Jeszcze co do samego wywoływania zawodników to była taka sytuacja, kiedy nie mogliśmy odnaleźć dużej części zawodników do Minisumo, chociaż pojawili się przy rejestracji, okazało się, że byli w okolicy 15m od samych ringów i właśnie będąc tam już nie słyszeli, że odbywają się walki. To co opisałem wpłynęło negatywnie na odbiór zawodów, a przecież nie potrzeba wiele, żeby to poprawić. Drabinka rozgrywek, przecież Wy już macie listę zawodników w bazie danych, wystarczy ją teraz przetworzyć, w sposób automatyczny oczywiście. Zaobserwowałem, że to wszystko odbywało się w excelu, przydałby się jakiś prosty system, który by Wam to zautomatyzował. Po zamknięciu rejestracji mogli byście kliknąć Wygeneruj i wszystko byłoby dostępne online dla zawodników. Również ważne, żeby obok drabinek była też informacja, kto aktualnie walczy, przy którym ringu, o czym już wyżej wspominałem. To by rozwiązało większość problemów z opóźnieniem i wtedy z czystym sumieniem moglibyście egzekwować 2 minutowy czas oczekiwania na zawodnika, może trochę dłuższy, bo trochę tych schodów ze strefy zawodnika do miejsca rozgrywek jest do pokonania. Nie chcę, żeby mój post wpłynął negatywnie na odbiór zawodów, bo oczywiście nie o to chodzi, starałem się pisać konstruktywnie i zależy mi na tym, żeby z roku na rok organizacja zawodów była na jak najwyższym poziomie. Jak najbardziej rozumiem też to, że poświęcacie swój prywatny czas i działacie non-profit, za to należy się jak najbardziej szacunek. Pewnie nie o wszystkim co chciałem wspomniałem, ale będę obserwował ten temat i w razie czego dopowiadał. Mam też wiele pomysłów jak można byłoby pewne kwestie poprawić i też wiedzę techniczną, która myślę, że mogłaby pomóc i się przydać, bo od wielu lat obserwuję te zawody z tej drugiej strony niż często Wy, więc z chęcią mogę pomóc przy organizacji zawodów w przyszłym roku, więc jak coś to dawajcie znać! Dzięki za Robomaticon 2019! Wierzę, że za rok będzie jeszcze lepiej. Jeszcze Was zawołam @Robomaticon Należą się też podziękowania dla Kornelii (nie wiem czy masz tu konto, albo jaki masz nick :P), która Wam bardzo pomogła kilka rzeczy ogarnąć, przez co wszystko potoczyło się na pewno sprawniej.
  11. Cześć, jestem na etapie projektowania line followera i naszła mnie taka refleksja dotycząca jednego z podpunktów regulaminu dla kategorii Line Follower Enhanced. Niedługo jest Robomaticon, więc za przykład dam podpunkt z ich regulaminu, ale wydaję mi się, że regulamin w tej kwestii jest spójny dla większości turniejów. Przechodząc do meritum, jest w regulaminie taki zapis: Co sądzicie o podawaniu wcześniej wymiarów przeszkody? Równie dobrze mogłyby zostać podane dokładne długości odcinków trasy, kąty pomiędzy nimi itd. Tylko czy o to w tym chodzi. Zapis ten powoduje to, że większość (generalizuję, piszę to jedynie na podstawie moich obserwacji przejazdów robotów w tej kategorii podczas różnych zawodów) uczestnik ma przygotowany kod, który można uprościć do wykonania pewnej sekwencji ominięcia przeszkody, na sztywno zapisanej w pamięci, w przypadku wykrycia przez czujnik odległości przeszkody. Gdyby chociażby przesunąć tę przeszkodę kilka centymetrów w jedną, bądź w drugą stronę względem środka linii to jestem pewien, że podczas pierwszego przejazdu roboty by sobie nie poradziły z nią, a przed kolejnym przejazdem zostałaby dodana sztywna poprawka uwzględniająca sztywne położenie przeszkody. Działa to, roboty sobie radzą z ominięciem przeszkody, czasem można się uśmiechnąć jak robot wykryje przeszkodę, która nie jest tą właściwą przeszkodą i wtedy wykonuje swoją sekwencję ominięcia przeszkody. Nie ma nic w tym złego, tylko jeżeli mówimy o autonomicznym robocie, który potrafi zareagować na różne konfiguracje trasy, to czy nie powinien również móc zareagować na niezdefiniowaną wcześniej przeszkodę? Zapraszam do dyskusji.
×
×
  • Utwórz nowe...