Wątek: Zagadnienia konstrukcji joysticka

[Sundowner]

W oderwaniu od dyskusji w temacie Shmajser Słodowy zaprasza, który to jest raczej tematem o praktycznym podejściu do tematu, chciałbym zaprosić do dyskusji nieco bardziej akademickiej. Otóż chciałbym w tym nowym temacie poruszyć zagadnienia konstrukcji joystików i tym podobnego sprzętu.

Zważywszy, że ostatnio zacząłem poświęcać więcej czasu drugiemu projektowi joysticka, który komplikacją swojej formy sprawia, że wszelkie joysticki FF stają się w moich oczach reliktem ery brązu i cyny, a klasyczne samocentrujące się dwu-trzy osiowce wyglądają na skamielinę, natknąłem się na parę nowych problemów.

Przykładowo, zakładając, że joystick w wingrozie mógłby wykorzystywać 12 bitowy zakres sygnału - precyzja jego wykonania nie pozwala na luzy na osi między chwytem, a czujnikiem obrotu większe niż 0,006° (!). Żaden problem, gdy potencjometr montujemy bezpośrednio do osi, praktycznie na stałe... no tracimy trochę na elastycznym odkształcaniu się plastikowych części, ale ogólnie problem można uznać za nieistniejący. Co się natomiast dzieje, kiedy chcemy wykorzystać pełny 270° zakres pracy czujnika - zmniejszając szumy na wyjściu ? Ano wchodzimy w wymóg wręcz kosmicznej precyzji wykonania... bądź zmyślnego sposobu kasowania luzów na przekładni.

Dodatkowo im więcej chcemy zrobić z osią - problemy rosną w funkcji kwadratowej. Jeżeli oś tylko centrujemy (klasyka), bądź tylko napędzamy (Force Feedback) problemów nie ma praktycznie żadnych - poza doborem sprężyn, czy silników o odpowiednio dużym momencie obrotowym. Co natomiast gdy chcemy zrobić obie rzeczy jednocześnie ? Ha!

Zaczynamy od problemu łożyskowaniu, już teraz złożonego układu kilku koncentrycznych komponentów. Sposób napędu, który pozwalałby jednocześnie na użycie taniego silnika i do tego był samo-hamujący (to na szczęście rozwiązuje przekładnia ślimakowa). Jak natomiast wykonać system zasprzęglający dwa obrotowe komponenty. I kilka innych, cały czas mając na uwadze wymagany stopień dokładności, ograniczoną przestrzeń i starając się jak najbardziej ograniczyć koszty !

Do osób tutaj bawiących się oprogramowaniem Mjoya i tworzeniem do niego peryferiów, mam pytanie - czy w ogóle w simach możemy realnie wykorzystać więcej niż 10bit sygnał jaki on daje, czy przypadkiem sam Microsoft Direct Input nie obcina danych do 10 bit długości ?

[Sundowner]

A podyskutuję sobie ze sobą...

Czemu osiągać więcej niż 10bit sygnał ?

Każdy, kto ma, niech weźmie do ręki suwmiarkę i zacznie się nią bawić i sprawdzi, jak precyzyjnie jesteśmy w stanie operować ręką, w zasadzie najdrobniejszym zauważalny ruch, to będzie prawdopodobnie wartość w granicach 0,05mm. Przenieśmy to na nasze joye i szybko zauważymy, że przy typowych joyach którymi machamy w zakresie blisko 40° od bandy do bandy, odpowiada to dokładności... 8bit - 512 punktów na oś w przybliżeniu. Czyżby 10bit było już overkillem ?

Niekoniecznie.
Samo wydłużenie rączki o 20cm spowoduje, że 10bit zaczyna nie wystarczać dając dwukrotnie gorszą dokładność. 11bit staje sie idealne. Więc po co 12bit ?
Ano jest taka prosta kwestia, że nie tylko obserwowalnym przesunięciem oddziałujemy, a przede wszystkim prostą zmianą siły nacisku - bez obserwowalnej zmiany pozycji. W zasadzie biorąc pod uwagę joystick już przedłużony, gdyby cały mechanizm i elektronika działały idealnie - przy 16bit sygnale nadal zapewne wielu z nas byłoby w stanie władać joyem bardziej precyzyjnie niż by na to pozwalał.

Niestety nic nie jest idealne, praktycznie żaden dostępny na rynku joy nie jest na tyle sztywny, ani jego elektronika na tyle precyzyjna, by pozwolić czerpać przyjemność z prawdziwego 10bit sygnału... jest to do uzyskania i pobicia, ale prawdopodobnie 12bit będzie tutaj fizyczna granicą nie do przeskoczenia... Święty Graal symulacyjnego hardware'u.

[codeking]

Do osób tutaj bawiących się oprogramowaniem Mjoya i tworzeniem do niego peryferiów, mam pytanie - czy w ogóle w simach możemy realnie wykorzystać więcej niż 10bit sygnał jaki on daje, czy przypadkiem sam Microsoft Direct Input nie obcina danych do 10 bit długości ?

Przeglądając SDK DirectInput (jakiś czas temu "klepałem" obsługę joystick'a) nie znalazłem żadnej zmianki odnośnie ograniczeń programowych DirectInput co do rozdzielczości osi joystick'a. Jeśli MJoy ma rozdzielczość 10 bit to można sprawdzić jaką rozdzielczość daje nam Windows (trzeba napisać mały programik i pomachać wajchą). Nigdy tego nie sprawdzałem, ale wydaje mi się, że Windows nie ogranicza rozdzielczości - bo po co (ale MS ma czasem dziwne pomysły więc who knows?). Nasuwa się pytanie czy np. FSX ustawia sobie odpowiednią rozdzielczość logiczną (w DirectInput) do obsługi joystick'a. Bo jeśli chłopaki i dziewczyny z MS machnęli ręką i ograniczyli sobie dla ułatwienia rozdzielczość do 8 bitów to możemy sobie robić nawet 32 bity i tak nam to nic nie da. Ale z kolei SimConnect SDK sugeruje, że np.

ELEVATOR POSITION

Percent elevator input deflection

Position (-16K to 0) -16K = full down

to jest zastanawiające. Ale tutaj również trzeba sprawdzić jakie wartości (a w rezultacie rozdzielczość) zwraca nam FSX.

Jeśli tworząc nowy kontroler masz na myśli tylko konkretny sim, który można tak jak FSX oprogramować to można zrobić dużą rozdzielczość i samemu ją oprogramować po stronie PC (kontroler nie jako kontroler ale jako zwykły HID z którym można programowo pogadać i odczytać dokładne położenie wajchy i ustawić programowo w simie).

Dla dużych rozdzielczości to joystick musi być bardzo precyzyjnie zmontowany nie wspominając o jakości samego układu elektronicznego. Wyzwanie duże, ale czy nagroda równie duża ? No chyba, że szykuje się jakaś grubsza produkcja dla wirtualnych pilotów z grubym portfelem

[Sundowner]

Projektuję Joya z trymem ("force trim" i "beep trim"), ogólnie pod simy śmigłowców, więc nagroda będzie duża (nikt tego jeszcze nie robił). Co do produkcji - wiesz jak to jest, będzie możliwość i będzie potrzeba, to się pomyśli. Na razie problemy są akademickie i kombinuje od kilku dni nad różnymi rozwiązaniami technicznymi i myślę, że zasadę działania podstawowych komponentów już rozgryzłem, teraz kwestia zaprojektowania tego żeby się kupy trzymało i nie kosztowało fortuny w wytworzeniu prototypów.

Kwestia dokładności elementów mechanicznych jest do zrobienia, natomiast elektronika może być równie interesującym zagadnieniem. Przykładowo błąd obecnych kontrolerów wynosi w najlepszym przypadku ile ?  2%? A trzeba zejść do 0,01% lub mniej. Jakaś filtracja sygnału ? Czy w ogóle potencjometrów można jeszcze tutaj używać, czy trzeba w czujniki halla już iść bezapelacyjnie ?

[codeking]

Co do sprawdzania rozdzielczości joystick'a w Windows'ie, some1 napisał kiedyś programik do tego -> http://www.il2forum.pl/index.php?topic=11825.0 W tym wątku zobaczyć można, że Thrustmaster HOTAS Cougar ma rozdzielczość 15 bitów Więc widać, że można to osiągnąć. Jeśli sim to wykorzysta to chyba jest sens gonić królika Ale sim musi to wykorzystać. Moja posiadana wiedza nie pozwala na pomoc w takim projekcie ale kibicuje. Wiele osób na tym forum posiada odpowiednią wiedzę aby pomóc, poradzić itd.

[Sundowner]

Taka mała ciekawostka - w latach 80'tych US Army zleciła firmie Boeing badania nad cyfrowym, optycznym systemem sterowania (ADOCS) dla śmigłowców, tutaj zdjęcie ewolucji kontrolerów lotu tego programu:



Kontrolery są 4 osiowe

[some1]

Co do sprawdzania rozdzielczości joystick'a w Windows'ie, some1 napisał kiedyś programik do tego -> http://www.il2forum.pl/index.php?topic=11825.0 W tym wątku zobaczyć można, że Thrustmaster HOTAS Cougar ma rozdzielczość 15 bitów Więc widać, że można to osiągnąć. Jeśli sim to wykorzysta to chyba jest sens gonić królika Ale sim musi to wykorzystać. Moja posiadana wiedza nie pozwala na pomoc w takim projekcie ale kibicuje. Wiele osób na tym forum posiada odpowiednią wiedzę aby pomóc, poradzić itd.

Standardowo poprzez Direct Input otrzymujesz pozycję osi w przedziale 0-65535 (16 bitowa precyzja). Jakoś nie mogę nigdzie znaleźć informacji że jest to wymagane, ale nie zdarzyło mi się aby któraś z osi przyjmowała inne wartości. W SDK do FSX większość osi posiada taki zakres ruchu (albo -32767 do 32768). Nie zawsze pokrywa się to z tym co piszą w SDK.

Oczywiście to nie znaczy że joystick ma taką precyzję, ale tak to wygląda z poziomu gier używających directX'a.

Co do tego że Cougar ma taką precyzję, to nie do końca musi być tak. To jest tylko oszacowanie na podstawie najmniejszej różnicy pomiędzy wartościami zwracanymi z joysticka. Więc na przykład joy w pewnym punkcie jest bardziej precyzyjny, ale niekoniecznie w pełnym zakresie ruchu. Dla przykładu na osiach które teoretycznie mają 256 punktów, uzyskuję tylko około 240 unikalnych wartości.

BTW, z SDK FSX'a wynika w pewnym miejscu że położenie joysticka jest próbkowane 10 razy na sekundę.

[codeking]

Co do tego że Cougar ma taką precyzję, to nie do końca musi być tak. To jest tylko oszacowanie na podstawie najmniejszej różnicy pomiędzy wartościami zwracanymi z joysticka. Więc na przykład joy w pewnym punkcie jest bardziej precyzyjny, ale niekoniecznie w pełnym zakresie ruchu. Dla przykładu na osiach które teoretycznie mają 256 punktów, uzyskuję tylko około 240 unikalnych wartości.

Zastanawiałem się właśnie nad tym, czy może lepiej zbierać próbki (kolejne położenia) a później obliczyć średnią różnicę pomiędzy kolejnymi położeniami (to wymaga jednak wolnego i równomiernego ruchu wajchą), później "rozpiętość" pozycji (obliczona na podstawie minimalnej zgłoszonej pozycji i maksymalnej) podzielić przez tą średnią. Wyjdzie mniej więcej rozdzielczość joystick'a - chyba że w moim rozumowaniu jest jakiś błąd.

[some1]

Jest ok, tylko że jeśli joystick ma dużą precyzję, to musisz się solidnie namachać żeby zebrać dostatecznie dużo wartości.

[Sundowner]

Pobawiłem się właśnie Resolution Testerem, pod kątem precyzji kontrolerów. Zważywszy, że w moim zestawie mam 3 różne typy potencjometrów do tego różniące się zakresem pracy to mam pewien obraz możliwości Mjoya16.

Jako, że wszystkie osie wykazały rozdzielczość dokładnie, lub w okolicach 1024, więc próbowałem osiągać precyzyjne wartości Raw - czyli zmiany co 64 jednostki. Jedyne gdzie było to możliwe, to przy trymie, który obsługuję potencjometrem obrotowym 10kOhm w pełnym zakresie obrotu. Inne potencjometry, albo maja inne wartości, albo nie działają w pełnym zakresie.

Wyciągam wniosek, że Mjoy16 jest bardzo wrażliwy na wykorzystywanie innego typu potencjometrów niż zalecane, ale przy właściwych, jest spokojnie w stanie oferować idealną 10bit precyzję.

Stąd wychodzą dwie kwestie:
1. Czy można zwiększyć ilość bitów na oś w Mjoy'u poprzez zmianę oprogramowania i dodatkowy układ - przetwornik A/D ?
2. Czy można Mjoya zmusić do równie dobrej pracy z potencjometrami innymi niż 10kOhm, czy jest to problem jego wewnętrznego przetwornika A/D ?

[vito_zm]

Damos analizował problem dokładności kodowania sygnałów analogowych w MJoy.Nie mogę znaleźć tego wątku.Może Damos pamięta gdzie to jest opisane.
Z mojego doświadczenia mogę stwierdzić,że dla kodowania mowy wystarczy przetwornik 8 bit oraz częstotliwość próbkowania 8 KHz.Dla przesłania muzyki 10 bit oraz próbkowania 32 KHz dla jednego kanału stereo.Można kupić przetworniki 16 bit o ile mnie pamięć nie myli (kiedyś zajmowałem się tym tematem).Jeśli chcemy zwiększyć odstęp sygnał szum to stosujemy kodowanie nieliniowe czyli wzmacniamy sygnały o małej wartości.
Podstawowe parametry decydujące o dokładności kodowania to częstotliwość próbkowania,kwantyzacja czyli liczba bitów zamieniająca próbkę na sygnał cyfrowy oraz rodzaj kodowania (liniowy lub logarytmiczny).
Z tego co pisał Damos w MJoy więcej nie da się zrobić,mam na myśli program.
Nie widzę problemy napisania programu tylko dla przetwornika dobrej klasy A/C.Tutaj mogą wypowiedzieć się programiści.

[Sundowner]

Wiele osób na tym forum posiada odpowiednią wiedzę aby pomóc, poradzić itd.

Hihi, tylko jakoś nie widzę tutaj żadnego praktykującego inżyniera mechaniki i budowy maszyn... a np przydałby się ktoś kto wie jak wyliczyć przekładnię planetarną w tak ograniczonej przestrzeni

[BigMac]

A jaka jest precyzja rzeczywistych urządzeń? Pomijając FBW, czy spasowanie linek i popychaczy, tudzież układu hydraulicznego jest tak dobre?

[Sundowner]

Co ciekawe - jest. Właściwie jedyne "błędy" są wynikiem odkształceń popychaczy, linek i ich montaży - od temperatury, czy obciążeń. To chyba głównie dzięki temu, że siły są przenoszone tylko w jednym kierunku, tzn albo sie dodaje obciążenie, albo je zdejmuje. Nie ma prawdziwego punktu zerowego dla sterów - w wypadku naszych joysticków albo dodajemy siłę w jednym kierunku, albo w drugim, zmiana kierunku oddziaływania siły jest miejscem w którym mamy do czynienia z luzami (choć można się i tego częściowo pozbyć, co np zrobiłem w swoim orczyku).

W wypadku maszyn latających - weźmy tutaj przykład Bella 206, który ma wspomaganie hydrauliczne sterów, lecz brak systemu sprzężenia zwrotnego (po naszemu - force feedbacku).

Siły oddziałujące od jednego końca układu (popychacza zaworu systemu wspomagania hydraulicznego, czy bezpośredniego śmigła ogonowego) są anulowane poprzez niewielkie siły przeciwne przy sterach, co powoduje, że nic nie klekocze (nie ma luzów)- mimo iż np budowa orczyka w tym konkretnym typie jest dosyć luźna.

Natomiast w maszynach ze sprzężeniem zwrotnym, cały system jest "napinany" przez ten właśnie układ.

W naszym wypadku, aby pozbyć się luzów na drążku, należy na samej osi oddziaływać dwoma przeciwnymi momentami obrotowymi. Tak robił InterAct, Suncom i obecnie Thrustmaster, CH i Logitech. Problemem niestety jest dalsza część - tj ciasne spasowanie reszty komponentów miedzy naszą ręką, a samą osią - tutaj leżą wszyscy producenci... prócz być może Thrustmastera, jeżeli ich Cougara rozpatrujemy z modyfikacjami "Über".

Problem leży w tym, że to wszystko jest wytwarzane masowo z małej ilości tanich materiałów. Saitek z kolei całkowicie minął się z założeniami i o dziwo wykonując joysticki zwykle o małych luzach - ich system centrowania jest kompletnie chybiony - siły oddziałują w złych kierunkach, a układ cierpi z powodu dużego tarcia. Suncom również wykorzystał podobną zasadę pojedynczej sprężyny i talerza oporowego - jednakże ich sprężyna jest znacznie niżej, a talerz oporowy jest na wysokości osi poprzecznych joya, przez co bardzo ładnie centruje, choć te joye są wiekowe i już niestety mocno wyrobione (mój zmodyfikowany i wydłużony Suncom ma już 0,34° luzu w centrum).

[Sundowner]

Na razie problemy są akademickie i kombinuje od kilku dni nad różnymi rozwiązaniami technicznymi i myślę, że zasadę działania podstawowych komponentów już rozgryzłem, teraz kwestia zaprojektowania tego żeby się kupy trzymało i nie kosztowało fortuny w wytworzeniu prototypów.

Projekt zaczął rosnąć i rosnąć i rosnąć... aż zaczął ważyć 15kg. Od weekendu siedzę jak Tony Stark zaczynający nowy projekt pancerza - wyrzucając wszystko co jest zbędne ze starego


Po drodze niestety doszedł jeszcze jeden wymóg mechaniki kontrolera, który zrujnował cały misterny plan - konkretnie bezstopniowa zmiana obciążenia. Mechanika ma być modułowa, wiec i dla ludzi latających na odrzutowcach też coś musi być No i w efekcie cały misterny plan opierania się na planach konstrukcji przegubu drążka z MD900 (przechył i obrót, zamiast dwóch przechyłów) legł w gruzach.


Mam nowe pomysły, nowe zabawki... tylko QRA czasu za mało.