Lukaszm

Ja na kablach telefonicznych też się nie znam, ale może spróbuję podrzucić jakieś tematy do przemyślenia. Pierwsze co ja zrobiłem, to sprawdziłem czas narastania sygnału na bramce drivera. W dokumentacji nie ma tej wartości podanej, ale driver jest do aplikacji z maksymalną częstotliwością 100MHz, więc pewnie krawędzie mają czas narastania 1ns albo krócej. To zgodnie z kciukowym wzorem przekłada się na pasmo BW=0.35/t_r=350MHz. Zakładam, że przewód to para skręconych przewodów i przyjmując er_eff=1.0 (powietrze, chociaż pewnie nie do końca prawda), to górna długość fali wychodzi 85cm. A kolejna reguła kciuka mówi, że efektami związanymi z odbiciami, niedopasowaniem impedancji i całą tą 'czarną magią' trzeba się przejmować, gdy długość linii transmisyjnej jest dłuższa niż 1/6 długości fali, czyli w tym przypadku to jest 85cm/6=14cm. No Twoja linia jest deczko dłuższa niż wyznaczona powyżej, co oznacza, że przy niedopasowaniu impedancji drivera, linii oraz odbiornika będziesz miał odbicia. Myślę, że ewentualny drugi efekt jaki tutaj może wchodzić, to związany z pojemnością oraz rezystancją linii, które potencjalnie mogą mocno tłumić sygnał - to już zależy od parametrów samego przewodu, które jakoś by trzeba spróbować policzyć/zmierzyć. Ale ja bym stawiał raczej na odbicia. No i generalnie tak trochę tutaj kończy się moje doświadczenie, bo takich instalacji i komunikacji jak opisujesz nie rozkminiałem. Spróbowałbym zmniejszyć stromość zboczy sygnału (inny driver albo rezystor szeregowy przy driverze) albo jakoś mniej-więcej dopasować impedancję przy odbiorniku: dokumentacja nie podaje impedancji drivera, ale stawiałbym że w okolicach 30-50R - czyli musiałbyś dać rezystor równolegle z diodą w Twoim odbiorniku. Jaka wartość rezystora? Taka, żeby impedencja zastępcza rezystora i diody była taka, jak impedancja drivera. Nie wiadomo jaka jest impedancja diody (w ogóle nie jest przecież stała, więc ciężka sprawa). Chociaż teraz się zastanawiam, czy może nie lepiej dopasować impedancję odbiornika do impedancji linii transmisyjnej, wtedy będzie tylko odbicie przy przejściu driver->linia, a już przy linia->odbiornik nie (chyba, nie jestem pewien już...). Fajnie jakby ktoś moje powyższe rozkminy skomentował, bo może herezje wypisuję. Wołam @marek1707, może on napisze jakieś mądre słowo albo dwa...

Piękny projekt. Jakiej grubości są te wkładki rozpraszające światło?

Każda rakieta to pewnego rodzaju projekt naukowy, który ma jakiś cel. Przykładowo rakieta TuCAN (wspomniana wcześniej) służy do wynoszenia kilku Can Satów na pułap 4-5km. Plan był taki, żeby rakieta zabrała CanSaty na zawodach organizowanych przez ESERO. Inna rakieta, H1, miała na celu pobicie rekordu prędkości i pułapu (i się udało, jeśli dobrze pamiętam). Jeszcze inna rakieta miała polecieć na konkretny pułap (2017 metrów). Jest też projekt rakiety sterowanej, która jest aktywnie stabilizowana.

@lukaszd82 Wiadomo, że czujnik halla byłby lepszy, ale nie znalazłem łatwo dostępnych i tanich stacji pogodowych, w których byłby taki sensor. A zależało mi na zastosowaniu gotowych modułów, żeby nie wydłużać czasu developmentu.

Cześć W ramach organizowanej akcji postanowiłem opisać projekt, który wykonałem już jakiś czas temu. WPROWADZENIE Projekt to stacja meteorologiczna montowana na wyrzutni rakiet zaprojektowana i wykonana przeze mnie w ramach rekrutacji do Sekcji Rakietowej Studenckiego Koła Astronautycznego (działającego na Politechnice Warszawskiej). Wymagania wobec stacji: pomiar prędkości i kierunku wiatru, pomiar temperatury i ciśnienia, pomiar położenia oraz orientacji wyrzutni i kąta nachylenia ramienia, komunikacja bezprzewodowa z bazą, zasięg 500-700m, aplikacja na PC wyświetlająca i rejestrująca odbierane dane. ELEKTRONIKA Ogólny diagram sprzętowy wygląda następująco: Do realizacji 'mózgu' stacji wykorzystałem Arduino Pro Mini (zarówno w nadajniku, jak i odbiorniku). Komunikacja bezprzewodowa zrealizowana jest poprzez moduły NRF24L01+ ze wzmacniaczem mocy (w przeprowadzonych na poligonie testach bez problemu uzyskiwały zasięg 700m). Do pomiaru ciśnienia i temperatury zastosowałem moduł z układem BMP180. Pomiar prędkości i kierunku wiatru jest wykonywany przez zestaw stacji pogodowej. Do pomiaru kąta nachylenia wyrzutni zastosowałem moduł z układem MPU-6050. Położenie wyrzutni jest mierzone poprzez standardowy moduł GPS (NEO-7M-C firmy Waveshare). Urządzenie montowane na wyrzutni zasilane jest dwoma ogniwami litowo-jonowymi, a odbiornik jest zasilany przez komputer za pośrednictwem USB. Do generacji napięcia 5V w nadajniku wykorzystałem moduł przetwornicy D24V6F5 z Pololu. Z przeprowadzonych pomiarów wynika, że jedno ładowanie baterii pozwala działać stacji przez około 30 godzin. Schemat jednostki głównej: Ciekawą sprawą jest pomiar prędkości wiatru. Anemometr raz na obrót zwiera styk, a prędkość obrotowa jest proporcjonalna do prędkości wiatru (1Hz przekłada się na 2.4km/h). Mierząc więc okres pomiędzy kolejnymi krawędziami, można określić prędkość wiatru. Aby pomiar był możliwie dokładny, wykorzystałem przerwania. Jednak jak to z mechanicznymi stykami bywa, pojawiały się drgania styków: Aby zniwelować ten efekt zastosowałem dwie bramki NOT z przerzutnikami Schmitta i filtrem RC (o stałej czasowej około 1ms). Układ sprawia, że na pinie mikrokontrolera pojawiają się ładne, pojedyncze zbocza (czerwony to wyjście anemometru, a niebieski przebieg to sygnał podłączony do pinu mikrokontrolera): Na pokładzie zamontowany jest również magnetometr (znajdujący się poza główną obudową, w oddzielnej obudowie), który miał służyć do pomiaru azymutu wyrzutni (przy startach rakiet bardzo istotne są dwa kąty: azymut oraz nachylenie ramienia wyrzutni). Ostatecznie jednak nie został wykorzystany ze względu na problemy z kalibracją (magnetometr musiałby być za każdym razem montowany dokładnie tak samo na wyrzutni, co nie jest wykonalne). Odbiornik jest stosunkowo prostym urządzeniem: Zawiera tylko mikrokontroler (na module Arduino Pro Mini) oraz moduł radiowy. Komunikacja z PC wykonywana jest przez konwerter USB-UART. Odbiornik wyposażony jest też w diodę, która jest zapalana na chwilę w momencie odebrania pakietu. Bardzo to pomaga przy rozstawianiu stacji. Oba układy zmontowałem na płytkach prototypowych. OPROGRAMOWANIE Oprogramowanie projektu jest dość rozbudowane, gdyż składa się z dwóch projektów na systemy wbudowane (nadajnik i odbiornik) oraz oprogramowania na PC. Oprogramowanie nadajnika Kod napisany oczywiście z wykorzystaniem środowiska i bibliotek Arduino dla przyspieszenia developmentu Wykorzystałem dodatkowe biblioteki: MPU6050 (konfiguracja i odczytywanie danych z akcelerometru) HMC5883L (konfiguracja i odczytywanie danych z magnetometru) I2Cdev (wykorzystywane przez bibliotekę MPU6050) TinyGPS (parsowanie danych z GPS) RF24 (komunikacja z modułem radiowym) Adafruit_BMP085 (konfiguracja i odczytywanie danych z barometru) Oprogramowanie odbiornika Zadaniem programu uruchomionego na odbiorniku jest odczytanie danych z modułu radiowego i przerzucenie ich od razu na port szeregowy. Nic skomplikowanego. Kod na systemy wbudowane jest w repozytorium: https://github.com/Lukaszm94/rocketLauncherDAQ_embedded Oprogramowanie na PC Program do uruchamiany na PC służy do odbierania danych z odbiornika, wyświetlania ich i zapisywania do pliku CSV. Do zrealizowania powyższych zadań wykorzystałem język C++, framework Qt i bibliotekę Qwt. Kod znajduje się w repozytorium: https://github.com/Lukaszm94/RocketLauncherDataAcquisitionApp Na temat samej implementacji nie będę się rozpisywał. Kilka ciekawszych funkcji programu to wyznaczanie wartości średniej prędkości wiatru (z możliwością ustalenia z jakiego okresu ma być wyliczana średnia) oraz podmuchu (chwilowa maksymalna prędkość wiatru). Dodatkowo, jeżeli któryś sensor działa niepoprawnie (np. akcelerometr jest niepodłączony albo GPS nie ma fixa), to wartość z tego sensora jest wyświetlana w kolorze czerwonym. Widok okna programu: MECHANIKA Wszystkie obudowy i elementy mocujące zaprojektowałem w Autodesk Inventor i wykonałem z wykorzystaniem drukarki 3D. Na wyrzutni montowane są trzy urządzenia: jednostka główna, moduł kompasu i moduł akcelerometru. W czasie projektowania kierowałem się łatwością montażu w warunkach polowych (stąd np. zastosowanie nakrętek motylkowych do mocowania obejm) oraz zapewnienie możliwie wysokiej odporności na wodę. Render głównej obudowy: Render odbiornika: Nadajnik: Wnętrze nadajnika: Wnętrze odbiornika: Ciekawy patent, jaki mogę pokazać, to wykonanie złącz do świata zewnętrznego. Wykorzystałem złącza męskie KK254, które przylutowane są do odpowiednio wyciętej płytki prototypowej. W płytce są dwa otwory pod śruby M3, analogiczne otwory są w obudowie. Płytka jest mocowana od wewnątrz do ścianki urządzenia z wykorzystaniem dwóch śrub. Całość od zewnątrz wygląda elegancko i jest wytrzymała. Cała jednostka główna zmontowana: WNIOSKI I PODSUMOWANIE Projekt spełnia większość założeń i uważam, że został zrealizowany z sukcesem. Wykorzystany został już wielokrotnie na poligonie i w zasadzie za każdym razem system działał poprawnie. Jeśli chodzi o wady, to główny problem jaki zaobserwowałem, to uszkadzanie się modułów radiowych (konkretniej to wzmacniaczy mocy) w momencie włączenia urządzenia bez podłączonej anteny - co niestety zdarzyło się kilkukrotnie (przypadkowe włączenie). Drugi problem to brak pomiaru orientacji wyrzutni, związany z opisaną wcześniej kłopotliwą kalibracją. Przykładowy wykres uzyskany z wykorzystaniem stacji (na zawodach CanSatów w 2016 jeśli dobrze pamiętam): Krótki opis projektu jest też na mojej stronie internetowej: http://lukemeyer.me/rldaq.php Na koniec mogę pokazać ładne zdjęcie ze startu rakiety TuCAN (jak się dokładnie przyjrzycie, to widać stację zamontowaną na wyrzutni ). W projekcie TuCAN również brałem udział, zajmowałem się całością systemów elektronicznych w rakiecie. Jakby ktoś był zainteresowany, to mam mały opis na mojej stronie: http://lukemeyer.me/tucan.php

Tak jak napisał Marek, sterowniki i sterowanie BLDC to niełatwa sprawa. Ja dwa lata temu zbudowałem deskorolkę elektryczną (opis: http://lukemeyer.me/electricMountainboard.php) i wykorzystałem gotowe sterowniki open source o nazwie VESC (autorem jest Benjamin Vedder): http://vedder.se/2015/01/vesc-open-source-esc/ . Według mnie z samym projektem deskorolki będziesz miał dość problemów, a dorzucanie jeszcze robienia własnego sterownika do tego to przesada (szczególnie, jeśli nie robiłeś tego typu projektu wcześniej).

Bardzo fajna konstrukcja czy możesz podać dodatkowe informacje na temat bazy pojazdu? Wykorzystałeś jakieś gotowe auto RC?

1) MinIMU-9 v5 to nie akcelerometr, tylko płytka, na której są układy scalone, przy czym jeden z nich zawiera akcelerometr (LSM6DS33). 2) Ja używałem tej płytki, problemów nie miałem.

No to ostatnia rzecz, jaka przychodzi mi do głowy, to wgranie jakiegoś wcześniejszego firmware'u (albo jakiegoś kodu z miganiem diodą). Ale to jest bez sensu, bo problem jest z samym wgrywaniem softu, a nie z jego uruchomieniem Dziwne, żeby procek tak sobie umarł. Słaba sprawa. Ale jak procesor jest w jakiejś ludzkiej obudowie (np. TQFP), to bez problemu powinieneś wymienić

Z konsoli wynika, że są problemy z weryfikacją zawartości pamięci po wgraniu firmware. Dziwne. Ja na Twoim miejscu spróbowałbym wgrać plik bin przez program ST-LINK Utility (https://www.st.com/en/development-tools/stsw-link004.html). Druga rzecz, która przychodzi mi do głowy, to uszkodzone przewody (ale to raczej mało prawdopodobne, bo programator wykrywa procka poprawnie). Jak masz podłączony programator do płytki?

Koła w momencie testów i podczas strojenia regulatora powinny być cały czas na podłożu, bez obciążenia bardzo mocno zmienia się charakter sterowanego obiektu (głównie przez masę samego robota i opory ruchu). Częstotliwość próbkowania trzeba dobrać do dynamiki obiektu. Chodzi o to, że na przebiegu przejściowym ma być co najmniej kilka próbek (ma być widoczne narastanie sygnału). U Ciebie jednej chwili czasowej jest 0rad/s, a już w następnej chwili czasowej jest 100rad/s. Tak nie może być. Ale zanim zaczniesz kombinować z częstotliwością próbkowania, to zrób test z robotem na kołach, przebieg będzie dużo wolniejszy (zależy od masy robota i silników, ale spodziewałbym się, że zbocze będzie trwało kilkaset ms). Aaaaa, nie zauważyłem, że omega masz w stopniach/s, a nie rad/s. IMO za mała prędkość jest uzyskiwana. Generalnie tutaj pierwszym krokiem jest ustalenie, jaka ma być amplituda wartości wejściowej. Teraz wybrałeś 9%. Jakiś konkretny powód takiego wyboru? Ta amplituda powinna być dobrana do docelowego punktu pracy regulatora, to znaczy określasz sobie, jaka mniej więcej jest Twoja przewidywana prędkość jazdy robota (np. v=0.5m/s). Z kinematyki odwrotnej przeliczasz to na prędkości kół robota. I wtedy na podstawie charakterystyki statycznej (albo metodą prób i błędów) wyznaczasz, jaki PWM powinien być (tzn. taka przybliżona wartość amplitudy skoku). I zbierasz sobie dane dla takiego skoku PWM. EDIT: zakres 0-100 dla PWM na razie może być, chociaż z moich doświadczeń wynika, że w czasie jazdy, PWM zmienia się w zakresie od około 15% do 25%, więc na dalszym etapie możesz zwiększyć zakres PWM na 0-1000, żeby mieć więcej wartości w tym zakresie 15% do 25% (ten zakres zależy od wielu parametrów: silników, napięcia zasilania, masy robota itd.)

Podstawowe pytanie to takie, czy zbieranie danych do modelowania silnika robiłeś, gdy robot stał na podłożu? Czy raczej koła kręciły się w powietrzu? Druga sprawa to ta odpowiedź skokowa mocno mi się nie podoba: 1) Zbyt mała częstotliwość próbkowania (w jeden okres próbkowania jest przejście od 0rad/s do praktycznie prędkości ustalonej, bez sensu) 2) Czemu najmniejsza zmiana mierzonej prędkości kątowej (rozdzielczość) to aż 20rad/s?

Masz możliwość sprawdzenia przez debugger jak zmienia się wartość zmiennej sc? Jeszcze znalazłem taki problem z RTC: https://sysprogs.com/w/forums/topic/rtc-problem/ . Dotyczy F4, ale może na F0 też taki problem występuje.

Cześć, a co masz konkretnie zrobić w tym projekcie? Rozwiązać zadanie kinematyki odwrotnej? Masz wykorzystać jakąś konkretną metodę (np. D-H), czy dowolnie? Ogólnie to polecam zacząć od oznaczenia sobie na rysunku układów odniesienia poszczególnych członów

To ja mogę jeszcze dorzucić jedną ekstremalną historię, którą niedawno usłyszałem. Dotyczy człowieka, który zabił się multimetrem. Multimetr był ustawiony na pomiar rezystancji i miał zamontowane bardzo ostre końcówki pomiarowe (coś jak tutaj https://www.sparkfun.com/products/12078). Facet wbił sobie (zakładam, że przypadkowo) jedną sondę w palec lewej ręki, a drugą w palec prawej ręki. Prąd pomiarowy miernika (rzekomo) wystarczył, żeby zatrzymać/zakłócić akcję serca