Wątek: Joystick USB - wersja profi

[3.14ter]

Zakładam nowy wątek odnośnie projektu joysticka, który wykluł się z rozważań w wątku "Kontrolery Arduino".
Nie będzie on oparty na Arduino, ale na nieco poważniejszym procesorze PSoC 5LP (Arm Cortex M3).

Początkowo planowałem użyć Bluetooth do bezprzewodowej transmisji, ale okazało się, że to rozwiązanie stwarza problemy, na których rozwiązanie nie wiem, czy chcę poświęcać czas, a do tego wprowadza pewne ograniczenia prędkości trasmisji i ilości danych, które można przepchnąć do PC w odpowiednio krótkim czasie.
Tak więc, po krótkiej i burzliwej przygodzie z Blue-Tooth, który często generował Blue-Screen wróciłem jednak do poczciwego USB. Płytka modelu BLE była na szczęście tak zaprojektowana, że mogę ją spokojnie użyć do prototypu na USB.

Pierwszy sukces:
wygląda na to, że udało mi się obejść problem z ograniczeniem liczby osi i przycisków w DirectX. Kluczem było stworzenie tzw. kompozytowego urządzenia USB-HID, czyli niejako kilku urządzeń w jednym (np. klawiatury z wbudowanym touch-padem są dokładnie czymś takim).
Do testów powstał podwójny joystick, każdy zawierający:

- 8 16 bitowych osi analogowych
- 32 przyciski
- 4 x HAT

Jak widać na fotce, DCS rozpoznaje go jako dwa osobne urządzenia. Przypisałem różne osie dla obydwu joysticków i byłem w stanie przejąć pełną kontrolę nad Żabą, a więc działa
Szkoda, że DCS nie bierze pod uwagę różnych nazw dla podjoysticków nadanych w programie, ale to chyba raczej wina Windowsa. Przynajmniej można je rozróżnić po numerze.


A tu prototyp, Bluetooth zastąpiony prockiem PSoC5LP z USB.


Stosując kable ekranowane, wbudowane w płytkę przedwzmacniacze i analogową kalibrację zakresów, na każdej z osi dostaję pełne 16bitów z minimalnymi szumami. W takim układzie wahania były na poziomie kilku jednostek, co przy maksymalnej wartości 65535 praktycznie jest pomijalne. Nie bez znaczenia jest też parę tricków zastosowanych na płytce, jak np. oddzielne niskoszumne zasilanie dla części analogowej oraz nie używanie zasilania USB, płytka na uniwersane wejście 7-12V DC z zabezpieczeniami przed odwrotną polaryzacją itd.

Cdn...

[Darth_Worm]

Witaj
Długo oczekiwałem tego wątku, będę z niecierpliwością czekał na następne części. Kupiłem Psoc5 z nadzieją na naprawdę precyzyjny sprzęt. To czego w arduino trudno uzyskać tu powinno (przynajmniej na papierze ) udać się. W miarę możliwości mogę służyć za testera. 

[vito_zm]

Wygląda obiecująco, powodzenia.

[shopiK]

Czekamy czekamy! Preampy działają i spełniają swoją funkcję nawet w arduino. A już zupełna rewelacja to płytki do enkoderów. Żadnych problemów.

[3.14ter]

Tymczasem modelujemy krzywe dla osi centrowanych.
Lokalne zmniejszenie czułości wokół zera bardzo poprawia precyzję i pomaga zachować centrowanie osi. W bibliotece dla Arduino użyłem funkcji kwadratowej, która jednak dość mocno zmienia charaktetystykę. Idealnie byłoby mieć niewielki "kwadratowy" obszar w okolicach zera, który potem wraca do  pierwotnej ch-ki liniowej. Chyba mi się udało
Ciemny niebieski = liniowa,
jasny niebieski = kwadratowa (jak w Arduino),
czerwony = nowa wersja.

[vito_zm]

A już zupełna rewelacja to płytki do enkoderów. Żadnych problemów

Potwierdzam. 

[shopiK]

Piter. A te krzywe to planujesz już w firmwarze zakodować? Bo nowe symulatory już to mają i np. w dcs wolałbym mieć charakterystykę liniową, a krzywe ustawiałbym sobie w dcs. No chyba, że piszesz o zewnętrznym oprogramowaniu do twojej elektroniki.

[3.14ter]

Planuję w firmware, ale w razie czego będzie opcja ich wyłączenia, albo nawet domyślnie ustawiona będzie ch-ka liniowa. Jestem jak najbardziej otwarty na sugestie.

Zastanawiałem się sporo na koncepcją całości systemu i doszedłem do wniosku, że pakowanie n joysticków w jeden w praktyce nie ma sensu.
Głównym atutem obecnego projektu elektroniki jest procesor z porządnym przetwornikiem A/C. Jego wersje i tak mają wbudowane USB. Rozbijanie systemu na kilka modułów gadających do siebie przez I2C, podczas gdy w każdym i tak byłby natywny USB traci sens. USB jest szybsze i odporniejsze na zakłócenia nawet przy dłuższych kablach.

Dlatego myślę, że końcowa wersja systemu będzie wyglądać tak:

- jeden moduł baza, zawierający 6 wejść analogowych 16bit z przedwzmacniaczami, 16 przycisków i 2x HAT. Wejścia dla enkoderów - jeszcze nie wiem. I tak muszą symulować naciskanie przycisków, więc może bardziej uniwersalnie będzie przewidzieć wejścia tylko dla przycisków. Jak ktoś będzie chciał podłączyć enkodery, to można użyć tych małych adapterów, które jak czytałem, sprawują się w porządku.

- mniejszy moduł zewnętrzny, 16 przycisków, dwa kolejne HATy i dwie osie analogowe 11/12bit. Komunikacja przez I2C z bazą. Ten moduł przeznaczony byłby do umieszczenia w uchwycie, podobnie jak to ma miejsce w Warthogu.

Całość przedstawia się Windowsie jako jeden joystick. Jakąś zworką będzie można przestawić nazwę, tak, żeby identyfikacja kilku zestawów baza+zewnętrzny moduł była bezproblemowa.
Takie zestawy można podłączyć do jakiegoś małego Huba i jednym kablem puścić do PC.

Czego nie chciałbym robić, to tworzyć jakiegoś osobnego softu do ustawiania tryliona opcji. Ma to być w podstawowej wersji urządzenie plug&play. Jeśli trzeba będzie wprowadzić jakieś dodatkowe niewielkie zmiany w firmware, jak np. zmiana krzywej, czy rodzaj przycisku, to będzie można to zrobić przy pomocy małego programu, który, mam nadzieję, uda mi się napisać.
Kalibracja i dopasowanie osi wykonywane będzie ręcznie, śrubokrętem. Windows raczej nie zgubi tych ustawień

[vito_zm]

- mniejszy moduł zewnętrzny, 16 przycisków, dwa kolejne HATy i dwie osie analogowe 11/12bit. Komunikacja przez I2C z bazą. Ten moduł przeznaczony byłby do umieszczenia w uchwycie, podobnie jak to ma miejsce w Warthogu.

Trochę to przypomina koncepcję, którą chcieliśmy zrobić w modzie dla Cougara. W rozwiązaniu elektroniki w drążku Cougara są rejestry równoległo-szeregowe i proste sterowanie zegar oraz sygnał zapis i szeregowy odczyt. I2C to już jest postęp. Enkodery w drążku raczej nie wystąpią, ale HAT-y jak najbardziej.
Chwyt Warthoga na pewno się różni od Cougara mam na myśli tensometry tutaj nie mam wiedzy, może inni się wypowiedzą.

[Freeman13]

Chwyt Warthoga na pewno się różni od Cougara mam na myśli tensometry tutaj nie mam wiedzy, może inni się wypowiedzą.

Chwyty Warthoga i Cougara są identyczne pod względem elektronicznym, dzięki czemu są w pełni kompatybilne pomiędzy obydwoma kontrolerami. Jedyne różnice to bardziej realistyczne wykonanie w Warthogu, inne materiały (HAT-y i reszta nakładek na switche jest wykonana z tworzywa). Dlatego ludzie z viperpits.org wymieniali drążki na te z Warthoga bo są po prostu bardziej wierne oryginałowi (z wyglądu). 



Vito TM Warthog nie jest wyposażony w tensometry tylko w sensor Hall'a, to jest ruchomy drążek.

[vito_zm]

Dzięki za sprostowanie Freeman 13. Chciałbym nawiązać do Twojej wypowiedzi #97 http://il2forum.pl/index.php/topic,15612.90.html
Faktycznie jest problem z kontrolerami do Cougarów. Różnie sobie ludzie z tym radzą nawet u nas na forum mam na myśli przykład macieja. To co proponuje 3.14ter pomoże rozwiązać problem kontrolera, ale nie do końca, ponieważ joysticki się różnią a kontroler ma być uniwersalny. Przykład to Cougar gdzie połączenie kontroler drążek oraz kontroler przepustnica to już rozwiązanie archaiczne. Interfejs I2C rozwiązuje problem, ale wymaga zmian w elektronice drążka oraz przepustnicy. Mając do dyspozycji kontroler Piotra można zaprojektować układy wykonawcze w drążku oraz przepustnicy. Kiedyś Damos próbował zrobić odwrotnie tzn. zaprojektować kontroler do Cougara, ale projekt nie doczekał się realizacji.
Policzyłem ile jest elementów wykonawczych w moim Cougarze. Drążek : 4 hat, 4 przełączniki i 2 trigger (przyciski). Przepustnica 10 przycisków oraz całość ma 7 analogowych osi bez ruddera.
Zaletą projektu Piotra jest jego prostota w porównaniu do projektu MMJoy2, który jest bardzo rozbudowany i za bardzo uniwersalny. Ceną prostoty jest to, że ma ograniczenia np. liczba przycisków. Jeśli wprowadzimy dodatkowe interfejs I2C do podłączenia modułu z rejestrami (przyciski lub enkodery) to mamy problem z konfiguracją.
Reasumując, podoba mnie się koncepcja Piotra, ponieważ jest plug&play i nie potrzeba konfigurować, ale musimy pogodzić się z pewnymi ograniczeniami (liczba przycisków). 

[shopiK]

Dlatego myślę, że końcowa wersja systemu będzie wyglądać tak:

- jeden moduł baza, zawierający 6 wejść analogowych 16bit z przedwzmacniaczami, 16 przycisków i 2x HAT. Wejścia dla enkoderów - jeszcze nie wiem....

- mniejszy moduł zewnętrzny, 16 przycisków, dwa kolejne HATy i dwie osie analogowe 11/12bit....

Czego nie chciałbym robić, to tworzyć jakiegoś osobnego softu do ustawiania tryliona opcji...

Odnośnie ogólnego zarysu systemu: ten przedstawiony bardzo mi odpowiada.
Trochę głupio mi, gdyż marudziłem by w module rozszerzeń znalazły się te dwie osie analogowe. Ponieważ równolegle testuję te pomysły na swoim projekcie to teraz przyznaję że te dodatkowe osie analogowe chyba nie są konieczne, za to ważna jest miniaturyzacja płytki.

Dalej: w modułach absolutnie nie trzeba wejść do enkoderów.  Mamy już płytki wielkości enkodera więc to w zupełności wystarczy.

Oprogramowanie: podstawowe się przydaje. I tak sobie pomyślałem że dobrze by było gdyby możliwa była opcja mapowania. Sam muszę u siebie zrobić. Wiadomo że w symulatorze sobie można. Ale po moich testach wiem, że bardziej intuicyjnie jest to zrobić już wcześniej.  Bo np mam taką sytuację, że w module głównym podpinam fizycznie np. 11 przycisków drążka, kolejne podpinam do modułu rozszerzeń i w windowsie mam w efekcie: przyciski od 1-11 potem od 17-ileśtam. Czyli taka dziura, bo pozostały niepodpięte wejścia. Tak to jest u mnie - więc ja powinienem zrobić mapowanie programowe. Jak u Pitera?

[vito_zm]

Domyślam się shopik, że masz już u siebie prototyp do testowania modelu to bardzo dobrze. Masz idealną sytuację, ponieważ nie masz ograniczeń  związanych z elektroniką  w joysticku Ty ją tworzysz projektując od podstaw całość. W trudniejszej sytuacji będą posiadacze starego sprzętu, ale to można rozwiązać.
Jeśli dobrze zrozumiałem to jest płyta główna oraz moduł rozszerzeń komunikujący się po I2C. W rozpatrywanej kiedyś koncepcji modu lub zastąpienia starego kontrolera do Cougara zakładaliśmy, że powstanie płyta główna oraz 2 moduły komunikujące się po I2C. Jeden moduł w drążku (3 rejestry równoległo-szeregowe) oraz moduł w przepustnicy, która w praktyce (F16) jest w odległości 1.5 do 2 m (długość kabla) od drążka (w praktyce od kontrolera). Można także założyć, że mamy 2 niezależne joysticki jeden do obsługi drążka drugi przepustnicy.
Przepraszam, że trochę mieszam, ale patrzę na ten projekt pod kątem jego praktycznego zastosowania. Może Freeman 13 wyrazi swoją opinię, ma dużą wiedzę na ten temat.

[Freeman13]

Cóż, osobiście nie chcę narzucać swojej koncepcji tego typu rozwiązania. Tym bardziej że @3.14ter nie projektuje kontrolera pod konkretny sprzęt, tylko do budowy całego urządzenia od podstaw, choć jedno tak naprawdę nie wyklucza drugiego. Było by idealnie gdyby główny moduł mógł komunikować się po I2C z drążkami Cougara/Warthoga. To dawało by świetną bazę wyjściową do modyfikowania czy budowania od podstaw całej mechaniki drążka z możliwością współpracy z chwytami od w/w kontrolerów. Jeszcze lepiej było by gdyby udało się zostawić oryginalne płytki z rejestrami w tych rękojeściach. Domyślam się że dla wielu ludzi było by problematyczne montowanie nowej płytki wewnątrz chwytu drążka. Więc gdyby kontroler projektowany przez  @3.4ter mógł się bez problemu komunikować z rękojeścią Cougara/Warthoga, to wielu z nas tutaj miało by banana na twarzy Na razie to tylko marzenia ale wyobrażam sobie taką sytuację że posiadając dla przykładu cały joy Warthoga, używam go w konfiguracji fabrycznej z większością symulatorów. Ale gdy chce polatać tylko F-16 w BMS, odkręcam rękojeść, montuję ją na modzie z tensometrami podłączonym do kontrolera który od razu widzi chwyt drążka i można zacząć zabawę.   
Przepustnica to już inna bajka, chociaż też był bym za rozwiązaniem aby była w pełni niezależnym urządzeniem, z własnym kontrolerem.

[shopiK]

Jeśli dobrze zrozumiałem to jest płyta główna oraz moduł rozszerzeń komunikujący się po I2C.
Przepraszam, że trochę mieszam, ale patrzę na ten projekt pod kątem jego praktycznego zastosowania.

@vito

Co do pierwszego, to tak mam płytkę arduino i ekspandery pinów cyfrowych komunikujących się po I2C.

Co do drugiego: to nie ty mieszasz, tylko ja za dużo napisałem i może nieczytelnie - zgadzam się zupełnie z zaproponowaną przez 3.14ter'a koncepcją systemu.