Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

ATMega328p - Niedokladne zrodlo taktowania

01 Cze 2016 15:01 870 7
  • Poziom 7  
    Witam,

    Aktualnie kończę budowę samorobnego drona i mam zagwostkę odnośnie całkowania.
    Mianowicie: calkuje przyspieszenie katowe zyroskopu aby otrzymac kat, uzywam do tego metody trapezow, kod tego obliczenia jest banalny:

    angle_gain=pr_gyro*dt+(akt_gyro-pr_gyro)*dt*0.5
    gdzie dt jak wiadomo to stala ktora wyznacza odstepy czasu miedzy kolejnymi pomiarami.

    Oczywiscie odczyt kata tylko z samego zyroskopu to o wiele za malo, jest on pozniej filtrowany filtrem komplementarnym i poddawany fuzji z katem z akcelerometru. Ogolnie takie polaczenie sprawdza sie bardzo dobrze, i w zupelnosci wystarczy do lotu malo akrobatycznym dronom. Dopiero przy bardzo gwaltownych ruchach (np pelny obrot w sekunde) widac ze blad zyroskopu jest na tyle duzy ze filtr sobie przez ulamek sekundy nie radzi i widac chwilowe przeklamanie, jednak zostaje ono skompensowane w ciagu kilku iteracji do wlasciwego poziomu.

    Blad ten moim zdaniem jest spowodowany glownie rozbieznoscia pomiedzy wartoscia dt a rzeczywistym czasem jaki uplywa pomiedzy pomiarami.
    Zrodlem tego bledu z pewnoscia jest niedokladnosc zrodla sygnalu taktujacego(w tym przypadku rezonator kwarcowy). Oczywiscie wplyw na to maja napewno bledy nieliniowosci, blad dryfu, jednak watpie by byly one az tak znaczace.

    Pytaniem wiec jest, czy znacie jakies sposoby na kalibracje/kompensacje programowa tej niedokladnosci?

    (poza pomiarem czestotliwosci taktowania za pomoca oscyloskopu)
    Darmowe szkolenie: Ethernet w przemyśle dziś i jutro. Zarejestruj się za darmo.
  • Poziom 37  
    Nie wierzę w nierówność kwarcu, raczej różne sprzętowe moduły cyfrowe "zjadają" zmienne ilości taktów w różnych sytuacjach, albo jeszcze bardziej różne fragmenty algorytmu.

    Czas albo inne zdarzenia z czujników pobierasz w jakimś przerwaniu czy w algorytmie sekwencyjnym? Jak masz ogólną koncepcję oprogramowania?

    Na poziomie teoretycznym mówi się że odpowiedź jest z czasie deterministycznym (i to są systemy czasu rzeczywistego - nie musi to być zabójczo mały odstęp czasu, tylko stabilny i kontrolowalny) lub nie (nasze windows które mino 8 rdzeni i fury ram nie zagwarantuje zawsze odpowiedzi na bodziec w stabilnym czasie)
  • Poziom 7  
    oczywiscie, ze petla z filtrami i obliczeniami jest wywolywana w przerwaniu dokladnie co te 4ms (tryb CTC i wartosc porownania licznika nastawiona na 250).

    Wydaje mi sie ze nawet minimalna rozbieznosc w kwarcu (chocby ze wzgledu na temperature) przy tej ilosci probek moze miec znaczenie.


    Co do koncepcji: najwazniejsze przerwanie, czyli to o ktorym mowa wykonuje odczyt z mpu6050, filtruje odczytane wartosci, przelicza na katy, wrzuca to do filtru komplementarnego.
    Komunikacja i sterowanie silnikami dzieje sie w osobnych przerwaniach, raczej nie zaklocaja tego procesu(nic skomplikowanego, komunikacja przez UART, 2 regulatory PID po 1 na kazda os (bez regulacji obrotu wokol osi Z) 4 wspolczynniki wypelnienia po jednym na kazdy silnik
  • Użytkownik usunął konto  
  • Pomocny post
    Moderator Mikrokontrolery Projektowanie
    Piotrus_999 napisał:
    Obawiam sie że atmego bez naprawde sprytnie napisanego softu jest po prostu za słaba do tego celu.

    Wez po uwagę że float mnożenie to ok 2980 taktów zegara przy zmniennych typu volatile.
    Dla porównania. Dzielenie na pewno więcej.

    Dane dla innych typów danych:
    uint8 => 19 cycles
    uint16 => 24 cycles
    uint32 => 103 cycles
    int8 => 37 cycles
    int16 => 33 cycles
    int32 => 120 cycles
    float => 2980 cycles

    Nie robiłem tych testów sam ale człowiek, do którego wiedzy i doświadczenia programistycznego mam wiele zaufania.


    Ufać to nie należy nawet sobie, a co dopiero innym. Mnożenie float na AVR to ok. 155 taktów - około, bo to +/-2-3 takty w zależności, czy operandy są w rejestrach, czy trzeba je dopiero załadować. A więc skoro ma przerwania co 4ms, a taktowanie być może 16 MHz, to wychodzi 64k taktów pomiędzy przerwaniami, więc 412 mnożeń. Więc obawiam się, że zanim się coś napisze, to warto to najpierw sprawdzić.

    Dodano po 3 [minuty]:

    @klimek476 Przesymuluj sobie odpowiedź twoich filtrów. Zapewne jest tak, że przy drobnych zmianach, różnice są szybko niwelowane. Natomiast przy dużych zmianach kąta/przyśpieszenia po prostu masz za mało próbek w czasie zmiany i filtr "nie nadąża". Np. zmieniasz położenie o 10 stopni na sekundę, to masz 25 próbek/stopień, zmienasz o 100 stopni na sekundę to masz już tylko 2,5 próbki/stopień i tu jak sądzę czai się problem.
  • Poziom 7  
    Dziekuje za odpowiedzi, mnie rowniez sie wydawalo ze kolega przesadzil z tymi taktami dla floatow.

    Jestem zaszczycony otrzymaniem odpowiedzi od autora mojej pierwszej ksiazki o AVRach :D

    Co do propozycji czestotliwosci probkowania to faktycznie jest to chyba najbardziej prawdopodobny powod, ATMega jest taktowana 16 Mhz, w tym samym przerwaniu jest zaprogramowane kolejno: odczyt przez i2c z mpu6050 3 osi zyroskopu i akcelerometru, filtr dolnoprzepustowy dla akcelerometru, filtr gornoprzepustowy dla zyroskopu, calkowanie zyroskopu(2 osie), obliczenia funkcji trygonometrycznych dla 3 osi akcelerometru i na koniec to wszystko do filtru komplementarnego, program faktycznie moze nie nadazac ze wszystkim w 4 ms.

    Chyba to jest dobry moment na przerzucenie sie na STM32 :p

    Dzieki za wszystkie odpowiedzi, wrzuce filmik jak juz dron bedzie w pelni sprawny w powietrzu
  • Pomocny post
    Moderator Mikrokontrolery Projektowanie
    Dzięki za miłe słowa. Ale wracając do tematu - to czy w 4ms się wyrobisz zależy od tego jak ta część kodu jest napisana. Zauważ, że I2C jest wolne, powiedzmy, że je taktujesz 100 kHz, a więc wysłanie/odbiór jednego bita trwa 10us. Powiedzmy, że odczytujesz około 20 bajtów, to daje nam 20*9*10us=1,8ms na samą transmisję I2C. Co gorsze, zmiana procka nic nie zmieni, jeśli kod jest niezbyt optymalny, bo na procku taktowanym nawet 1 GHz i tak zajmie to dokładnie tyle samo czasu. Rozwiązaniem jest skorzystanie z możliwości jakie daje procek, czyli realizacja I2C w oparciu o przerwania z tego interfejsu. Wtedy robisz sobie obliczenia, ale procek nie jest blokowany na czas wolnej transmisji I2C, w efekcie masz pełne 4 ms na obliczenia. Jak już wyliczyłem, w tym czasie możesz zrobić ponad 400 mnożeń, nie sądzę abyś potrzebował więcej :) Poza tym zawsze można skorzystać z fixed point math, co nie tylko dodatkowo przyśpieszy obliczenia, ale być może zapewni ci lepszą precyzję i to niezależnie od użyteog MCU.
  • Poziom 7  
    Racja, i2c w przerwaniach napewno bedzie bardziej efektywna(aktualnie korzystam z predkosci 400Khz) i nie bedzie blokowac obliczen, co do obliczen na staloprzecinkach zamiast na floatach - to rowniez jest moj kolejny cel do realizacji po doprowadzeniu projektu do podstawowej funkcjonalnosci. Przy opisie oprogramowania napewno wspomne o tych poradach i jak sie sprawdzily w praktyce.

    Jeszcze raz dzieki za wszystkie rady.