Wątek: Następca Mjoy (Założenia konstrukcyjne)

[EGHI]

  Jeszcze hamulce - ponoć z klawiatury łapią na ustalonym prawie na max poziomie ale gdzieś czytałem że można to przenieść na potencjometr (zabij, nie pamiętam gdzie o tym było).

W Setup/controllers/advanced options/ Flight control, masz wszystkie osie analogowe i są też hamulce, o trymach nie  wspomnę .

[vito_zm]

Zapomniałem o panelu z trymerami, ponieważ nie mam go u siebie z braku miejsca. U mnie trymery są w HAT1 i są dostępne po wciśnięciu pinky.

[yano]

Napisałem że trymer na osiach może być problem w kokpicie. Skłoniły mnie do tego pewne przemyślenia "teoretyczne" (nie dysponuję kokpitem więc nie mam jak sprawdzić). Problem wygląda mniej więcej tak:

Trymować można za pomocą panelu oraz za pomocą sidestika. Jeżeli w panelu umieścimy potencjometry i zaczniemy trymować przełącznikiem na sidestiku, to w efekcie rozjadą nam się wartości. Potencjometry fizycznie będą w położeniu neutralnym, ale trymowanie już nie. Przykładowo trymujemy sidestickiem tak, aby samolot maksymalnie przechylić w lewo. Potencjometry pozostały w pozycji zerowej. Spróbujmy teraz za pomocą panelu uzyskać maksymalny trym w prawo. Okazuje się że możemy dojechać do środka i dalej kończy się potek.

[Sundowner]

Enkodery.

[damos]

Panowie, proszę nie kraść wątku temat o detalach kokpitu piętro niżej
Mały update:
za pomocą 32-krotnego oversamplingu udało mi się zwiększyć rozdzielczość osi analogowych do 12 bitów (skuteczna rozdzielczość ponad 11 bitów: ok 4000 różnych wartości)  z zachowaniem akceptowalnej szybkości i stabilności odczytu rzędu 0,09%. Więc czułość jest między 4.8mV a 1,5mV (zakres 5V podzielony na 4096 różnych wartości daje najmniejszą rozdzielczość na poziomie 1,2mV). Przy tak obiecujących efektach można pomyśleć o 13-to lub 14-to bitowej osi, ale to będzie już ryzykowne - zwiększanie rozdzielczości o 50% ma już więcej wspólnego ze statystyką niż pomiarami

@Yano - jeśli trymer będzie mógł "spowodować" maksymalne wychylenie steru - to nic na to nie poradzisz nawet w prawdziwym samolocie. Trymery muszą być "słabsze" od osi trymowanej. Na przykład - maksymalne wychylenie trymera to max 25% wartości osi.

[vito_zm]

 

z zachowaniem akceptowalnej szybkości i stabilności odczytu rzędu 0,09%.

Sun mam do Ciebie pytanie. Jak u Ciebie z stabilnością odczytu. U mnie w programie DIView jest niestabilnie na pozycjach 0,xx% względem wartości maxymalnej. Jest to trochę więcej od 0,09%.

[Sundowner]

Jeszcze nie mam podpiętych potencjometrów. W tej chwili wskrzeszam Suncoma by spełniał zadania platformy testowej, jest z tym trochę roboty.

[damos]

Sun mam do Ciebie pytanie. Jak u Ciebie z stabilnością odczytu. U mnie w programie DIView jest niestabilnie na pozycjach 0,xx% względem wartości maxymalnej. Jest to trochę więcej od 0,09%.

Vito, zewrzyj wszystkie osie do masy, za wyjątkiem osi X.
W programie DIView jest log, on u mnie pokazuje to:
w pozycji lewej:



na środku:

w pozycji prawej:


jak widać na przykładzie - różnice są na poziomie +/- 16 (26511-26495), cały zakres to 65536 więc 16 to 0,02% wartości maksymalnej.
Oczywiście - każdy układ będzie inny ze względu na zakłócenia, parametry indywidualne każdego ADC itd.

[vito_zm]

To są moje wyniki dla 3 zakresów położenia suwaka.


Uploaded with ImageShack.us



Uploaded with ImageShack.us



Uploaded with ImageShack.us
Z analizy wyników wynika, że różnica pomiędzy sąsiednimi pozycjami wynosi 16. Z czego to wynika?

[damos]

To są moje wyniki dla 3 zakresów położenia suwaka.
Z analizy wyników wynika, że różnica pomiędzy sąsiednimi pozycjami wynosi 16. Z czego to wynika?

Oryginalnie wyniki mają 4097 różnych wartości. Są z zakresu 0-4096 (powinno być 0-4095 - poprawię to ). Zobaczysz to klikając prawym przyciskiem na oknie danej osi i wybierając opcję "View Raw Data". Wtedy na czerwono będą pokazywane dane źródłowe (wysyłane przez kontroler).:


  Software na PC ekstrapoluje je do zakresu 0-65535. To wymaga pomnożenia przez 16. Z tego wynika, że zmiana o 1 w danych "surowych" z urządzenia powoduje zmianę o 16 dla zakresu podawanego na osi.
Najmniejszy skok ekstrapolowanej osi to 16 - bo zmiana o 1 z 12-to bitowego zakresu (0-4095 na 0-65535) wynosi właśnie tyle.

[vito_zm]

Masz rację, sprawdziłem. Wynika z tego, że te "niestabilności" wynikają z zasady kodowania 12-bitowego zakresu.

[KubaMiszcz]

Jesli dobrze rozumiem DMjoy8 jest jeszcze w trakcie testow i dopracowywania?

Mialem zrobic sobie Mjoya ale postanowilem poczekac na DMjoya:]

[damos]

Tak - DMJoy jest w fazie developmentu.
Jednak brakuje mu naprawdę niewiele.
Powinien okazać się dużo bardziej stabilny niż zwykły MJoy. I koszt części + płytka jest mniejszy

[kosiu]

Damos,

A jak zamierzacie rozpowszechniać płytkę i ewentualnie zaprogramowany m-procesor DMKeys8 i DMjoy8? Macie na oku jakąś stronę, gdzie można by to zamawiać?
Czy ewentualnie będzie cały opis na Twojej stronie ze wzorami płytek, tak aby można było sobie samemu przygotować płytki jak również plik binarny (wsad) do m-procesora?

Pozdrawiam, jeszcze raz, gratuluję Wam (Tobie i osobom testującym) uporu i determinacji i niecierpliwie czekam na zakończenie prac  :banan

[damos]

Planuję udostępnić schemat płytki i wsad tak, aby każdy mógł samodzielnie zbudować sobie układ.
Problemem dla niektórych może być kwestia montażu, który wymaga dokładności, cierpliwości i ... lupy




Więc dla tych, którzy nie będą chcieli robić tego samodzielnie wymyślę jakąś formę pomocy w postaci możliwości zamówienia zmontowanej i uruchomionej płytki..
Płytka jest mała, uniwersalna i może służyć do wielu rzeczy (Joy, Keyboard, sterowanie LED, 7SEG, LCD, przekaźniki ) - więc pod tym względem projekt jest interesujący.