Wątek: Kontrolery Arduino

[vito_zm]

ShopiK poruszył bardzo ciekawy problem. Faktycznie można zapytać dla kogo ten projekt i tutaj nie będzie jednoznacznej odpowiedzi, ponieważ każdy ma inne potrzeby oraz umiejętności wykorzystania takiego projektu. Może przybliżę ten problem na swoim przykładzie, ponieważ zajmuję się tym od lat.
Na początku był słynny MJoy16 oraz SVMapper. Tutaj sprawa była dosyć prosta i nie wymagała prawie żadnych umiejętności.
MJoy16 miał ograniczone możliwości dla budowania kokpitów, ale był wystarczający dla budowy paneli.
W moim przypadku pojawiła się OpenCockpit z swoim softem SIOC oraz całą rodziną hardware. Tutaj wymagana była już wiedza potrzebna do pisania skryptów oraz konfigurowania różnych płyt. Nawet teraz po kilku latach maciej z forum też ma ten system u siebie.
Następnie pojawił się na naszym forum codeking z swoją wspaniałą platformą HSC oraz SIMOUT i SimIN. Tutaj także jest potrzebna wiedza do pisania skryptów. Moim zdanie HSC jest jedna z najlepszych platform.
Zapomniałem wspomnieć , że pojawili się jeszcze inni twórcy hardware oraz soft np. Skalarki. Ten system ma u siebie w kokpicie EGHI.
Drejku zastosował gotowe rozwiązanie softu oraz hardware, ale wyspecjalizowane pod symulator.
Kolejny programista z naszego forum Damos zrobił dwa kontrolery DMKeys8 oraz DMJoy. Pierwszy emuluje klawiaturę drugi jest widziany jako joystick. Damos zrobił program konfiguracyjny w formie graficznej, gdzie konfiguracja jest trywialna. Jednocześnie możliwości przypisania klawiatury oraz tworzenia sekwencji są imponujące. Są też przewidziane zabezpieczenia programowe itp.
Tak jak kiedyś wspomniałem traktuję elektronikę jako hobby, dlatego zainteresowałem się ostatnio Arduino. Ponieważ zauważyłem, że koledzy już u siebie stosują te kontrolery to założyłem ten wątek. W ten sposób dotarłem do platformy MMJoy2, którą chciałem poznać. Mogę stwierdzić, że jest to bardzo dobre rozwiązanie dla osób nie lubiących pisać skryptów oraz wgłębiać się w "teorię". Konfigurowanie jest w formie graficznej czyli klikanie. Są dołączone programy testujące. Generalnie jest tam to co teraz zrobił 3.14ter, ale na innych rejestrach jeśli chodzi o wejścia cyfrowe. Są też analogi z możliwością połączenia czujników  czy przetworników ADC wielokanałowych. Można MMJoy2 zaprogramować na ProMicro i będzie działać. Zakończyłem moje testy z MMJoy2 z dwóch powodów. Po pierwsze problem enkoderów o czym pisałem oraz pojawienia się na forum 3.14ter.
Tutaj otworzył się nowy rozdział historii, ponieważ z tego co zauważyłem kolega 3.14ter dysponuje zarówno wiedzą jak i praktyką. Wspomnę tylko o jego uwagach na temat zakłóceń w analogach. Ja mam o tym trochę pojęcie co to znaczy zakłócenia jeśli kodujemy próbkę na poziomie mV. Po za tym zna się na programowaniu. Na ogół programiści nie są specami od  hardware i na odwrót. To co proponuje 3.14ter może być bardzo przydatne dla budowniczych paneli lub kokpitów. Pytanie na ile ma to być uniwersalne. Przykład enkodery, czy ma być opcja enkoderów jeśli jest już DMKeys8 itp. Moim zdaniem niech autor sam zdecyduje co ma szansę zrobić. Użytkownik może korzystać z tych funkcji, które potrzebuje.
Na koniec sprawa o której pisze shopiK oraz golas tzn. konfigurowanie lub plug'n'play. Myślę, że 3.14ter znajdzie sposób na rozwiązanie tego problemu. Jeszcze jedno przyszło mi na myśl. Pisaliście koledzy swoje szkice dla swoich zastosowań i wiecie, że jest to pewien wysiłek. Zauważcie jak elegancko rozwiązał ten problem 3.14ter tworząc funkcje i je w odpowiednim miejscu wywołując. Program jest bardzo czytelny. Należy tylko się cieszyć, że pojawił się na naszym forum kolega 3.14ter, który może nam ułatwić życie. Trochę się rozpisałem, ale tak myślę co nie znaczy, że mam rację.

[3.14ter]

Poruszyli

[3.14ter]

Poruszyliśmy dobry temat. Dokładne zaplanowanie koncepcji projektu to podstawa. Z mojego podwórka mogę dodać, że usiłowanie upakowania nieliczonych ilości opcji, skomplikowana procedura obsługi to pułapka. Dobrze rozwiązane urządzenie jest proste i wygodne w obsłudze, robi to co ma robić i nie rozprasza użytkownika.
Dlatego też o projekcie na Arduino, a właściwie Atmedze32U4 myślałem bardziej w katerogiach "Hurriego". Może nie jest najlepszy w swojej klasie i brakuje mu do czołówki, ale z drugiej strony zbudowany jest z w miarę tanich i łatwo dostępnych podzespołów, ma zestaw podstawowych opcji (ilość osi, przycisków..), wybacza wiele niezbyt jeszcze doświadczonemu kierownikowi.
Oprócz tego dodatkowe gniazda z interfejsami I2C i SPI mogą posłużyć to dalszej rozbudowy układu.

Dla kogo byłby ten projekt. Od samego początku dla mnie była to sprawa jasna: dla hobbystów budujących swoje kokpity, ulepszających joysticki. Projekt typu "open source". Konfiguracja nie musi być strasznie skomplikowana i całość można zautomatyzować do kilku prostych funkcji. Ewentualnie jeszcze prościej - zaplanować stałą mapę ustawień. Użytkownik będie musiał podłączyć się do odpowiednich wejść, jeśli chce użyć danej funkcji.

Drugi, high-endowy projekt dla bardziej wymagających użytkowników, taki "Spit" mógłby być zbudowany na szybszym procesorze PSoC5LP.

Górne ograniczenie w tym momencie to ilość danych w paczce HID. Biblioteka arduino wykorzystuje maksymalną ilość 64 bajtów. Ograniczenie ilości wejść w prostszych wersjach sprzętowych jest banalnie proste - po prostu można uch nie używać, nie podłączać nic do wejść analogowych (procesor będzie nadawał cały czas 0), nie podłączać przycisków, czy HATów. Dane będą lecieć do PC, ale skoro tam nie będą przypisane do żadnych fukncji, to chyba nie ma problemu (możliwe, że jest tu  jakiś haczyk, nie wiem).
Czego mi brakuje, to wiedzy praktycznej z budowy kokpitów, listy rzeczy, które są niezbędne, które są pożądane. Mogę zaprojektować cuda-niewidy, tylko pytanie, czy w ogóle ktoś z tego skorzysta i czy niepotrzebnie nie będziemy zwiększać ceny urządzenia.

Myślę, że dobrą koncepcją będzie budowa "Hurrie-Joya" jako pierwszego, prostszego i tańszego w budowie, łatwego w obsłudze uniwersalnego joysticka. Na bazie zdobytych doświadczeń, później można zabrać się za "Spit-Joya" (podoba mi się ta analogia

Jeszcze mam takie pytanie natury technicznej. Jakiego rzędu odległości czujnik - płytka bazowa trzeba założyć w projekcie?

Już wiem skąd te podwójne posty. Przełączanie języka klawiuatury w win jest pod alt-shift. Przy szybkim pisaniu chyba wcisnąłem do tego "s" i post się wysłał.
Uprzejmie proszę o usunięcie poprzedniego posta.

[3.14ter]

Rozmyślań technicznych ciąg dalszy.
Spójrzcie co uzyskałem po dodaniu prostego filtru (średnia krocząca z 8 wartości) do zwykłych 10bitowych wejść 32U4 (zrzuty ekranu z VKB joytester):


Dla porównania tak wygląda wyjście Saiteka St290 Pro:


A tu porównanie, Saitek vs wejście A0 32U4 (suwak ma podłączony 100n do masy) i ten sam sygnał po filtrze cyfrowym. Skala identyczna dla wszytkich przebiegów, rozciągnąłem ją tylko w pionie:

[shopiK]

!!! A taki filtr cyfrowy to zaimplementowałeś w bibliotece? Gdzie można znaleźć taki kod?

[3.14ter]

Nie ma go w bibliotece, będzie częścią nowego programu na którym testuję inne pomysły.
Zasada jest taka:

Kod: [Zaznacz]

void ADCLowPassFilter(void)
{
   
static volatile uint32_t filt[FILTER_ARRAY_SIZE];

    uint16_t temp16;
    uint8_t i;

for (i = 0; i <FILTER_ARRAY_SIZE; i++)
{
adcRawData[i] = scanner.getValue(scanOrder[i]);//tu możda dać analogRead(i), jeśli wejścia podłączone są do A0-A5

temp16 = adcRawData[i];

if ((temp16 >(filt[i] + k_LPfltFeedforward)) ||
((filt[i]>k_LPfltFeedforward)&&(temp16 < (filt[i] - k_LPfltFeedforward))))
{
filt[i] = temp16;
}
else
{
filt[i] *= k_Ravg_size;
filt[i] += temp16;
filt[i] /= (k_Ravg_size+1);
}
adcFilteredData[i] = filt[i];
}
}

Zabierałem się już do napisania obsługi ADC poprzez przerwania, tak, żeby nie blokował programu, ale jak zwykle w przypadku Arduino, już ktoś to zrobił.
Do automatycznego skanowania kilku wejść ADC użyłem biblioteki:
https://github.com/merose/AnalogScanner

Na zewnątrz mam zadeklarowane kilka tablic:

#define FILTER_ARRAY_SIZE 6 // skanujemy 6 wejsc analogowych
uint16_t adcRawData[FILTER_ARRAY_SIZE]; // to czyste wejścia ADC, w zasadzie ta tablia nie będzie potrzebna, ale chciałem mieć te wartości dla porównania
uint16_t adcFilteredData[FILTER_ARRAY_SIZE]; // tu zbierane są przefiltrowane wartości wejść ADC

Stałe:
const int k_Ravg_size = 7;            //rozmiar średniej. (n^2 - 1)
const uint16_t k_LPfltFeedforward=10; //a to sprytny trick. Jeśli wartość wejścia ADC przekroczy ustaloną tu wartość, to filtr się wyłączy. Zapewnia to lepszą dynamikę przy szybkich zmianach i podążanie za sygnałem źródłowym. Bez tego filtr wprowadzałby opóźnienia np. przy szybkim ruchu drągiem.

A dalej w programie dostęp do przefiltrowanych parametrów mamy po prostu przez tablicę adcFilteredData[numer wejscia ADC];

Kod funkcji nie jest jeszcze do końca zoptymalizowany. Testowałem właśnie jego działania i czasem dobrze jest mieć trochę nadmiarowych zmiennych do obserwacji działania.

[shopiK]

No muszę przyznać, że fajnie to działa. Trochę za długo trzyma jeśli się ruszy drąga po chwili bez ruchu. Ale kod fajny - dużo lepiej stabilizuje niż moja średnia arytmetyczna  Bardzo dziękuję

[vito_zm]

Z mojego podwórka mogę dodać, że usiłowanie upakowania nieliczonych ilości opcji, skomplikowana procedura obsługi to pułapka.

Całkowicie zgadzam się z tym poglądem. I znowu wrócę do projektu MMJoy2. Twórca chciał zrobić uniwersalny sterownik (joystick), który ma realizować bardzo dużo funkcji nawet sterowanie LED. Moje testy z enkoderami wypadły negatywnie. Mógłbym na forum pytać o przyczyny, ale doszedłem do wniosku, że MMJoy2 można stosować tylko w ograniczonym zakresie.
To co proponuje 3.14ter ma sens tzn. realizacja kontrolera typu joystick na bazie Atmedze32U4 a później po doświadczeniach realizacja bardziej zaawansowanego na bazie szybszego procesora PSoC5LP.

[shopiK]

Ograniczenie ilości wejść w prostszych wersjach sprzętowych jest banalnie proste - po prostu można uch nie używać, nie podłączać nic do wejść analogowych (procesor będzie nadawał cały czas 0)

Jak w arduino nic nie podłączę (a nie zepnę do masy) to na wejściach pojawiają się losowe wartości.

[vito_zm]

Jak w arduino nic nie podłączę (a nie zepnę do masy) to na wejściach pojawiają się losowe wartości.

ShopiK ma rację, jeśli dla analogów program jest przygotowany na odbiór wszystkich wejść to na wejściu nie połączonym do źródła będzie szum. Można to rozwiązać na dwa sposoby, albo program rozezna tę sytuację np. uśredniając w jakimś odcinku czasu lub coś podobnego, albo tak jak w MJoy16 zworka na wejściu nieaktywnym do masy.

[shopiK]

I jeszcze zauważyłem u siebie (a także gdzieś czytałem o tym problemie), że nie umasione, wiszące w powietrzu wejścia zakłócają te podpięte... Faktycznie tak jest.

[moders]

Bardzo dobrą robotę tu robicie. Coraz bardziej podoba mi się Arduino. Prawdopodobnie też zdecyduję się na wykorzystanie tej platformy w zakresie eksportu danych z DCS. Planowałem samodzielnie grzebać w export.lua ale teraz myślę że szkoda na to tracić czas – na Arduino osiągnę pożądany efekt szybciej.
W każdym razie to co robicie pozwala mi (pomimo tego że nie mam jeszcze Arduino) wstępnie poznać i pozytywnie ocenić to rozwiązanie - i za to właśnie dzięki  .

[3.14ter]

I jeszcze zauważyłem u siebie (a także gdzieś czytałem o tym problemie), że nie umasione, wiszące w powietrzu wejścia zakłócają te podpięte... Faktycznie tak jest.

Dlatego docelowo w układzie wejściowym wtórnik na wzmacniaczu operacyjnym ma dodatkowy rezystor 2M2 do masy na wejściu +. 2M2 równolegle do potencjometu 10k-50k nie robi praktycznie żadnej różnicy. A jeśli źródło zostanie odłączone, trzyma wejście na potencjale masy. Przetestowałem to właśnie w praktyce: szum, gdy wejście wisi w powietrzu i po podłączeniu rezystora.


Czas na kolejną funkcję. Porównywałem Saiteka z naszym układem i Saitek pomino nędznej elektroniki o wiele ładniej wracał do pozycji środkowej. Na 100% charaktrerystyka nie jest liniowa, raczej logarytmiczna w celu zapewnienia większej precyzji w okolicy zera. Na szczęście ATMEGA posiada sprzętowy mnożnik i możemy użyć y=x^2 na obu połówkach zakresu.
Po użyciu filtrów z poprzedniego posta  wartość zmiennej  przepuścić można przez  poniższą funkcję:

Kod: [Zaznacz]

uint16_t applyResponse16(uint16_t data)
{
uint16_t output;
uint32_t t32;

if (data &_BV(15))
{
data = data - 0x7FFF;
t32 = ((uint32_t)data) * data;
output = (t32>>15) + 0x7FFF;
}
else
{
t32 = ((uint32_t)data) * data;
output = (data<<1) - (t32>>15); //2*data - (data^2)
}
return output;
}

otrzymując coś takiego (czerwony= ch-ka liniowa, czarny=semi log)

[vito_zm]

Na 100% charaktrerystyka nie jest liniowa, raczej logarytmiczna w celu zapewnienia większej precyzji w okolicy zera.

Z tego co pamiętam gdy 20 lat wstecz zajmowałem się pośrednio projektowaniem koderów i dekoderów dla kanałów stereo w radiofonii to przechodziliśmy z charakterystyki liniowej przetworników na nieliniową dla małych sygnałów po to aby uzyskać lepszy stosunek sygnał/ szum kwantyzacji. W praktyce była to charakterystyka logarytmiczna.

[shopiK]

Nie no... Patrząc na te funkcje - stopuję z pisaniem swojego programu Czekam na efekt i montuję u siebie