Wątek: Kontrolery Arduino

[vito_zm]

Chciałbym podziękować koledze 3.14ter za wspaniały projekt zrobiony w tak krótkim czasie i najważniejsze, że działający oraz dla nas dostępny . Jeśli będziesz realizował kolejny projekt ten ambitniejszy to jestem do dyspozycji jako tester.

[BOCZEK]

Także dziękuję 3.14ter

[3.14ter]

Panowie, to jeszcze nie koniec Mam już kilka nowych pomysłów jak dalej usprawnić bibliotekę.
Od strony sprzętowej myślę, że najpierw skupię się na nieco mniejszej wersji na Arduino. Ta platforma, pomimo ograniczeń, jest jednak bardzo popularna, tania i szeroko dostępna.
Mniejszej, tzn. standardowo płytka będzie zawierać zestaw do obsługi podstawowej wersji jaką obsługuje DirectX, a więc:
- 8 analogwych osi. 4 z nich będą obługiwane zewnętrznym przetwornikiem A/C 12bit, reszta będzie 10 bitowa,
- 2x MCP23017 na pokładzie do obsługi 32 przycisków,
- dodatkowe gniazda z I2C, do których będzie można podłączyć zewnętrzne moduły z kolejnymi kośćmi MCP,
- 2x HAT, wersja na przyciskach. Ilość można rozszerzyć przez użycie osi analogowych lub dodatkowych MCP23017,
- chwilowo nie będzie dedykowanej obsługi enkoderów. Myślę, że to zadanie dla oddzielnego modułu, który będzie odczytywał ileś tam enkoderów i generował zdarzenia typu "wciśnij przycisk". Dodatkowy plus - nie będzie na stałe związany z biblioteką i sprzętem. Będzie można go użyć w innych konstrukcjach, które posiadają wystarczającą ilość wejść.

Jeden z pomysłów na rozszerzenie biblioteki to swego rodzaju system "plug&play" dla modułów z MCP, każdy rozszerzający system o dodatkowe 16 przycisków.
Maksymalnie podłączyć możemy do 8 szt. MCP na jednej magistrali I2C. Na tyle pozwalają 3 wejścia adresowe. Akurat dobrze się składa - to daje 128 przycisków.
Procesor, zaraz po starcie sprawdzałby kolejne adresy (0x20 - 0x27) i automatycznie konfigurował wykryte moduły.
Generalnie chodzi o to, żeby ograniczyć programowanie do podstawowej konfiguracji sprzętowej, a resztę zautomatyzować jak tylko się da.

Obawiam się, że nie będę już w stanie działać tak szybko, jak przez ostatnie dni. Robota wzywa. Ale z czase myślę,że powstanie całkiem uniwersalny system do wielu zastosowań. Upgrade joystików, kokpity i co tam jeszcze wymyślicie

[shopiK]

A ja mam pytanko, jak sobie radzicie z zakłóceniami... Mam mały problem jeszcze ze "skaczącymi" nieco wartościami potencjometrów. Na płytce prototypowej jest ok, ale jak przewody są dłuższe, to już się zaczyna "letka wariacja". Zastosowałem proste uśrednianie wartości. Nie dałem jeszcze ekranowanych przewodów. No i nie wiem, czy nie zastosować stabilizowanej przetwornicy napięcia do zasilania potencjometrów. Może po prostu arduino nie wyrabia. Macie jakieś przemyślenia na ten temat?

[golas]

Zawsze możesz dać za potka czy innego sensora halla układ adc (np MCP320* 12bit albo MCP330* 13bit) który wynik da Ci już cyfrowy i po kablu puścisz dalej bez zakłóceń niż w przypadku gołego wyniku z sensora.

BTW:
Ja właśnie otworzyłem paczkę z TME z KMZ60 x 3 + SS495A1 + MCP3208 i teraz przeprojektowuję swój koncept joy'a wywalę z płytki głównej 3x74HC165 i dam je jako osobne płytki x5 co da 40 przycisków (32+2 haty)).

Teraz kwestia co do samego andruta naszego - czy jest sens projektowania całej płytki bazowej pod podzespoły samego arduino (robimy tj. klona) czy bardziej opłacalne będzie zrobienie serii płytek modułowych np. rejestr przesuwny po SPI/I2C (74HC165D lub MCP23017) lub sensor + przetwornik (np. KMZ60+MCP3201/MCP3301) dla pojedynczych osi lub moduł wielokanałowych przetworników ADC (2-8kanałów?), płytka pod enkodery no i oczywiście całość spinana do płytki głównej w którą wpięte było by arduino. Moim zdaniem fajnie byłoby zrobić taki 'ujednolicony' system i projekty płytek - może gotowe do zamówienia w jakiejś firmie?

[3.14ter]

Rozwiązanie, które mam już przetestowane w praktyce (sprzęt estradowy) planuję zastosować również w bazowej wersji płytki.
Każde wejście analogowe będzie wyglądać tak:


1. Potencjometry podłączone kablami ekranowanymi, 3 lub 4 (łatwiej dostępne) żyły w ekranie. Ekran połączony z masą tylko z jednej strony - przy gniazdku na płytce.

2. Cała część analogowa zasilona z oddzielnego niskoszumnego stabilizatora 3.3V. To napięcie będzie użyte jako AREF w Arduino, ADC będzie mierzył napięcie z zakresu 0-3.3V. Kolejna zaleta tego rozwiązania to ochrona przed zwarciem. Zastosuję jakiś mały stabilizator na ok. 100mA, może mniej. W przypadku zwarcia VDDAF do masy (może się zdarzyć podczas okablowania) ograniczy on prąd i ochroni port USB. USB zresztą też będzie miało swój zestaw zabezpieczeń.

3. Zaraz na wejściu 1 filtr RC usuwający śmieci powyżej 1.5kHz. Dioda BAT54S + rezystor 1k zabezpieczają wejście przez przepięciami, ujemnymi napięciami itp. Standardowe zabezpieczenie.

4. Dalej mamy wtórnik napięciowy na wzmacniaczu operacyjnym. Rezystor 2M2 nie obciąża praktycznie wcale potencjometru lub czujnika Halla, ale polaryzuje wejście do masy w przypadku, gdy nic nie jest połączone. Zostawianie "wiszących w powietrzu" niespolaryzowanych wejść nie jest dobrą praktyką. Wtórnik napięciowy ma niską impedancje wyjściową, zalecaną do wysterowania wejścia ADC.

5. Na końcu jeszcze jeden filtr RC, umieszczony blisko wejścia ADC. W momencie próbkowania przetwornik generuje dość sporą szpilkę:



To jest zrzut ekranu z oscyloskopu, program MegaJoy, wejście A0, odłączony potencjometr.
Parę innych czynników ma na to wpływ, ale możemy przyjąć, że dla klasycznego podłączenia potencjometru prosto do wejścia ADC, te szpilki będą propagować po całym okablowaniu. A zwłaszcza, gdy potencjometry będą w okolicy środkowego położenia. Ważne jest, żeby te szpilki zostały wygaszone jak najbliżej wejścia ADC. M.in. z tego również wynika zalecenie, żeby na wejścia ADC podawać sygnał o niskiej impedancji. Wtórnik napięciowy to załatwia, a drugi filtr nie pozwala na to, żeby zakłócenia latały po całej płytce i kablach. Przy okazji dodatkowo tłumi szum.

6. Wtórnik ma jeszcze jedno zadanie - ochrania i separuje wejście ADC od świata zewnętrznego. Łatwiej i taniej jest wymienić tani wzmacniacz operacyjny niż cały procesor, gdyby doszło do jakiejś awaryjnej sytuacji.

Żeby choć trochę poprawić sytuację zastosowałbym po pierwsze ekranowane kable, po drugie filtr RC 1k-10k (dobrać doświadczalnie)+100n do masy umieszczony przy samym wejściu Arduino.

Jeszcze odnośnie kwestii zasilania. Najprawdopodobniej przewidziane będzie dodatkowe gniazdo MicroUSB i automatyczny przełącznik zasilania. Jest cała masa tanich zasilaczy z wyjściem MicroUSB (np. te do RaspberryPi). Układ po wykryciu zewnętrznego zasilania przełączy się na nie, a zaszumione USB zostawi w spokoju.

Zastanawiam się też na opcją dodania sterowników LED na I2C. Joystick nie odbiera danych z PC, ale co można zrobić, to np. podświetlenie przycisków. Każdy z przycisków miałby dodatkowy rejestr do konfiguracji podswietlenia, coś w rodzaju:
BtnXled = 0 ; //brak
BtnXled = 1; // toggle, wciśnij -zapala LED, następne go gasi
BtnXled = 2; //momentary, LED świeci tylko, gdy przycisk jest wciśnięty, tak jak kontrolki w windows

128 LEDów plus cała reszta układu to już może być za dużo dla jednego portu USB. W takim wypadku zalecane będzie zasilanie zewnętrzne.

[vito_zm]

Jest tyle informacji, że nie wiem od czego rozpocząć. Rozpocznę od analogów. To co proponuje 3.14ter  jest profesjonalnym rozwiązaniem tak się to robi co nie ozn., że nie pojawią się problemy. Można szybko przeliczyć jaki będzie minimalny skok kwantyzacji dla przetwornika 10 bit dla zakresy napięć 0-3,3V. Są to przetworniki liniowe bez kompresji dla małych poziomów.

Jeszcze odnośnie kwestii zasilania. Najprawdopodobniej przewidziane będzie dodatkowe gniazdo MicroUSB i automatyczny przełącznik zasilania. Jest cała masa tanich zasilaczy z wyjściem MicroUSB (np. te do RaspberryPi). Układ po wykryciu zewnętrznego zasilania przełączy się na nie, a zaszumione USB zostawi w spokoju.

Czy mogę prosić o wyjaśnienie. Arduino może być zasilane albo z USB albo z źródła zew. 7-12V przez gniazdo Power Barrel Jack. Jeśli podamy napięcie z zew. to napięcie z USB będzie zablokowane. Nie śledziłem schematu Leonardo, ale tak przypuszczam.
Część cyfrowa tzn. MCP23017 będzie zasilana z 5V z Leonardo a część analogowa z 3.3V także z Leonardo, czy mam rację?
 

Cała część analogowa zasilona z oddzielnego niskoszumnego stabilizatora 3.3V. To napięcie będzie użyte jako AREF w Arduino, ADC będzie mierzył napięcie z zakresu 0-3.3V

Czy to napięcie 3.3V jest podawane na wejście IOREF, czy jest to zewnętrzy zasilacz 3.3V.

Co do części cyfrowej to jeśli dobrze zrozumiałem ten fragment:

.....standardowo płytka będzie zawierać zestaw do obsługi podstawowej wersji .....

Czy planujesz na bazie Leonardo zaprojektowanie schematu ideowego oraz płytę pcb realizującą wymienione założenia?
Golas wstrzymaj się z swoim  projektem, ponieważ jak zauważyłeś projekt 3.14ter dopiero się tworzy. Tempo jest niesamowite w porównaniu do innych projektów, które były tworzone przez miesiące a nawet lata.

[golas]

Projekt 3.14ter'a będzie także wykonany, spokojnie nikt nie broni przecież zrobienia kilku kontrolerów zarówno elektrycznie jak i mechanicznie nie?

Powracając do płytek - moim zdaniem jeżeli byłoby zainteresowanie jakiejś grupy osób (5-10?) wtedy można by się było pokusić o zrobienie płytek w jakiejś firmie, która zrobi to porządnie dwustronnie wraz z soldermaskami - chodzi mi oczywiście o panelizowane układy modułów + płytki centralnej wtedy koszt zakupu gotowych płytek byłby bardzo porównywalny do wytworzenia ich samemu (a jakość na pewno większa u fachowca).

[3.14ter]

Projektuję całkiem nową płytkę, opartą o ATMEGA32U4. Będzie to układ kompatybilny z Arduino. Znaczy to też, że najpierw trzeba będzie wgrać bootloader przy pomocy jakiegoś zewnętrznego programatora do AVR. Od biedy może to tego posłużyć nawet inne Arduino.
Zastanawiałem się nad użyciem gotowych modułów, ale doszedłem do wniosku, że skoro i tak trzeba będzie lutować dość sporo elektroniki naokoło Arduino, to w sumie większy sens będzie miało zaprojektowanie nowej płytki od podstaw. Zoptymalizowanej pod to do czego ma służyć, z porządną filtracją zasilania, zabezpieczeniami, wygodnymi złączami i wg ogólnych zasad projektowania urządzeń z mikrokontrolerami.

Całkiem zapomniałem o MCP3208. Używałem w ostatnim projekcie 4ro kanałowy MCP3204 i jakoś tak mi został w pamięci. Zmieniłem projekt na MCP3208 i będzie 8 12bitowych osi. Dzięki golas za "cynk"

Zastosowanie 3.3V dla części analogowej praktycznie nic nie zmienia od strony cyfrowej, rozdzielczości ADC, zakresu itd. Potencjometry zamiast 0-5V będą podawać 0-3.3V. Na wejściu VREF (napięcie odniesienia, górna granica skali) przetwornika również będzie 3.3V.  Jedynie co trzeba jeszcze sprawdzić, to czy czujniki Halla z wyjściem analogowym mogą pracować z takim napięciem zasilania.
IOREF - nie mam takiego wejścia w moim Leonardo. Jest tylko AREF, jest to pin Atmegi do podawania zewnętrznego napięcia referencyjnego dla ADC lub to podłączenia kondensatora filtrującego wewnętrzne źródło. Standardowo Arduino używa VCC jako referencji dla ADC, ale można to programowo przełączyć na pin AREF.
W moim układzie nie będzie to miało znaczenia, bo pokładowy przetwornik Atmegi nie będzie używany.

Co może trochę odstraszać, to większość elementów będzie w technologii SMT. Chociaż ja uważam osobiście, ze SMT jest o wiele prostsze do lutowania od technologii przewlekanej. Wymaga jedynie odrobinę wprawy i dobrego topnika.
Płytki na 100% wykonane fabrycznie.

[golas]

Osobiście preferuję montaż powierzchniowy elementy zazwyczaj tańsze, zajmuje mniej miejsca i mimo, że kilka lat temu wyłożyłem ponad 600 złociszy na proxxona micromota 50ef wraz z zasiłką i stojakiem co by wiertło 0.5mm robiło otwór 0.5 a nie 1mm to i tak jestem za SMT ;p oprócz pinheadów! te obowiązkowo tradycyjnie przez dziurę! bo i tańsze sporo i gorzej wyrwać

3.14ter - ja się na fabryczne płytki piszę jak nic

Co do samych sensorów które nas najbardziej interesują czyli potsy i czujniki halla - magnetorezystancyjne (dzis testuję KMZ60+MCP3208 [kmz datasheet]) etc. uważam, że powinniśmy uderzać w 16bitowe rozdzielczości - różnica cenowa nie jest jakaś mega ogromna (patrząc i tak na nie małe koszta całościowe) - stosując dobrej jakości sensory można uzyskać naprawdę sensowne wyniki 12bit - 4096 | 16bit - 65536 - 16'to bitowe są choćby w warthogu którego tak wiele osób chwali za precyzję działania

Dodatkowo kwestia zakłóceń - im bliżej mamy czujnika przetwornik adc tym powinno być moim zdaniem lepiej - tutaj kwestia dyskusyjna? Ja osobiście wolałbym nawet pojedyncze/podwójne moduły z adc i czujnikiem do mocowania jako płytka i od tego do głównej płytki połączenie - cyfrowy sygnał vs. analogowy nawet w ekranowanym przewodzie powinien się lepiej zachować na korzyść cyfry (pomijam, że można na module dać dodatkowe filtry/kondensatory etc jeżeli są potrzebne)

Całość jak najbardziej modułowa w końcu nie każdy potrzebuje od razu 8osi i setki przycisków z masą enkoderów oraz hatów

[3.14ter]

Gniazda i piny jak najbardziej tradycyjnie, zgadzam się w pełni!
Przetworniki przy czujnikach - z jednej strony tak. Z drugiej dłuższe i wielokrotne połączenia np. na magistrali SPI mogą zrujnować komunikację. Przerabiałem ostatnio przy obsłudze wyświetlaczy TFT.
Muszę zamówić parę czujników halla do testów i sprawdzić to w praktyce.

[golas]

Ja właśnie testuję SS495A1 - całkiem całkiem czujnik zwłaszcza, że bipolarny - niestety moje magnesy neodymowe ze starych hdd'ków mają dziwne pola lub już bardzo słabe (dyski rozebrane w celu odzyskania magnesów mają połowę tego co ja na liczniku nabite ), niemniej jednak 10bit to widzę już, że za mało, 12 pewnie na orczyk i przepustnice wystarczy - na joy'a już może być mało zwłaszcza, jak założymy, że drąg będzie miał min 30cm od gimbala.

Właśnie trawią się płytki pod KMZ60 i MCP3208 - termotransfer wyszedł całkiem całkiem mimo, że dawno go nie robiłem - obaczym, czy trawiarka faktycznie utrzyma zadane 45 stopni, jak nie wycieczka po laminat i b327 w poniedziałek

[vito_zm]

Nasza dyskusja to w jakimś sensie dyskusja o założeniach do projektu. Jeśli założymy, że będzie płyta główna z uP 32u4 z interfejsami oraz innymi dodatkami to będą płyty satelity dla interfejsów np. I2C oraz SPI.
Jeśli  planujemy zastosować MCP3204/8 na płycie satelicie komunikujący się po I2C to nie ma chyba sensu korzystać z przetwornika ADC w 32u4 (Ao-A5). Natomiast trzeba zrobić zabezpieczenia przed zakłóceniami o których wspomniał 3.14ter właśnie na płycie satelicie. Drugi problem to zasilanie  płyty głównej oraz płyt pomocniczych. Ja mam u siebie 2 zasilacze od pc, które zasilają niezależnie lewą oraz prawą burtę w kokpicie.
I ostatnia sprawa, która mi się nasuwa to programowanie. Trzeba założyć maksymalną konfigurację np. 8 MCP23017 oraz wspomniany  MCP3204/8 oraz inne czujniki.
3.14ter już o tym wspomniał, że pewne sprawy program rozpozna tzn. wyposażenie hardware, ale być może każdy użytkownik będzie musiał w programie Arduino zrobić małą korekcję pod swoje potrzeby. To zależy od możliwości programowych 3.14ter. Nie ma sensu robić coś na wzór MMJoy2, ponieważ jest to przerost formy nad treścią. Wystarczy funkcjonalny program z opisem jak zmieniać parametry w programie jeśli będzie taka potrzeba. To takie moje przemyślenia na gorąco.

[shopiK]

Skoro o założeniach projektu.
Czytam trochę ten wątek. Pisałem też na privie do Vito z prośbą o wyjaśnienie dlaczego korzystając z platformy arduino zajmujecie się takimi systemami jak mmjoy. Przyznam że nie do końca to jeszcze rozumiem. A wynika to chyba z dwóch różnych podejść do tematu. I żeby nie było. Nie krytykuję, nie oceniam, co lepsze itp. Zajmuję się ostatnio stworzeniem nowej wersji kontrolera lotu (kopii znanego urządzenia - zdjęcie poniżej). Już są chętni na takie coś, więc tworzę sobie też dokumentację, obliczam koszty itp. Tworzę też jakąś elektronikę opartą o arduino. Ale właśnie. Padła tu propozycja pytanie - czy byliby chętni do wyprodukowania takich modułów elektroniki. Ja pewnie na ten rok potrzebowałbym kilku. Ale:

Tak sobie myślę jako klient "mojego produktu". Powinno to urządzenie działać jak każdy joystick. Czyli - plug'n'play. Na pewno nie chciałbym kupować urządzenia do którego uruchomienia potrzebna znajomość mmjoya, czy innych dodatkowych programów. W ten sposób piszę swoją wersję oprogramowania. Ale zdaję sobie sprawę, że to wyważanie otwartych drzwi, bo koledzy mają stosowną wiedzę i zwyczajnie zrobią to lepiej.

I teraz jakby wracając - te dwa podejścia:
1. Robimy moduł elektroniki dla końcowego odbiorcy - gracza, który buduje sobie joya, albo producenta joysticków - moduł, który ma określoną ilość osi i przycisków - klient do gniazdka na kablu podpina potencjometr i działa.
2. robimy moduł dla świadomego budowniczego kokpitów - z masą opcji konfiguracyjnych, z dużą ilością podmodułów wykonawczych itp.

Czego ja bym chciał, czytając ten wątek. Chciałbym mieć dostęp do pierwszej opcji. Buduję mechaniczny joy podpinam wyprodukowany moduł, który kupujący podpina do komputera i działa. W takim przypadku całość oprogramowania musi być po stronie modułu elektroniki ( a nie że musiałby klient sobie konfigurować coś w mmjoyu)
Moduł musi być jeden a nie kilka różnych. - żeby łatwo to było zainstalować - ewentualny nadmiar wejść, np. zbędne osie wyłączać albo automatycznie, albo zworką.
Czyli taki ograniczony (brak możliwości rozbudowy) moduł, ale gotowy jako całość i bezproblemowy.

Jeszcze raz, żeby nie było. Naprawdę nie krytykuję, tylko piszę, co by mi się przydało. Takich modułów kilka bym zakupił (dołożyłbym się do produkcji). Ten przydługi post można by chyba streścić do pytania: dla kogo taką elektronikę budujemy? Co jest nam potrzebne?

[golas]

Ja obojętnie czy bardzo rozbudowane konfigurowalne czy gotowe do działania i tak chcę zakupić Poza tym, jeżeli nawet ustawisz zawczasu pod klienta wersję 'advanced' to może on dostać właśnie urządzenie plug'n'play