Dostavel jsem si novy joy do experimentalni podoby a prestoze mi prijde, ze doba zlatych ceskych rucicek uz minula, napisu zde par postrehu ohledne designu, konstrukce a pouzivani. Pedaly resit nebudu, ty mam dlouho a urcite jsem je tu uz popisoval.
Vypada to takto:
coz vam asi moc nereklo :-). Z boku:
U vseho jsou kompromisy, ja jsem bezpodminecne vyzadoval nasledujici:
-velky rozsah pohybu rukojeti, srovnatelny se skutecnym letadlem
-hladky chod bez nejakeho zubu ve stredove poloze
-zadny force feedback ve smyslu tahani paky nejakym smerem, ale pritomnost vibraci
-rozumna rukojet
duvody volby vyse uvedeneho jsou asi jasne. Klasicky plny force feedback neni imho v soucasne dobe realisticke udelat bez zprevodovani a zprevodovani znamena, ze paka nechodi hladce, ale tahate ji pres zuby. Nahrazeni zprevodovaneho motorku FFB nejakym velkym motorem pouzivanym v gimbalech by mozna teoreticky slo, ale je tam desiva cena i spotreba. Jedine dalsi zlepseni by tedy byla realtime zmena sily pruzin, coz by prineslo moznost posunovani stredu a nejspis vetsi cit pro rychlost. Vyzadovalo by si to ale vyprogramovani windowsiho driveru, coz je nad moje momentalni moznosti.
Z podminky na rozsah pohybu je jasne, ze paka musi behat pod stolem. Zaroven jsem pokud mozno chtel, aby kdyz na paku polozim ruku, nebude mit paka tendenci menit polohu (ruka provesena mezi vasim ramenem a rukojeti taha prirozene rukojet dozadu). Proto jezdi rukojet dopredu dolu a k sobe nahoru, cimz se hmotnost ruky kompenzuje. Zda se to velmi neprirozeny pohyb a byla to jedna z neznamych, ale vlastne je ten pohyb uplne prirozeny, od ramen tlacit a tahnout zpet k ramenum je vlastne prirozenejsi nez pohyb vodorovny.
Tvar pohybu a kontrukce prepakovani je nasledujici (je to z linkage, krasny program na tyto veci):
Je to z boku, uzivatel sedi vpravo, zelena a oranzova maji dole i nahore kloub, delaji spolecne vyskovku, a velky ctyruhelnik, ktery ma v pravem hornim rohu rukojet, se da naklapet doprava doleva podle skoro vodorovne osy uprostred (y1-B2). Spravna volba vzdalenosti a velikosti meni otacive pohyby vseho na temer primku (cerna cara vpravo nahore). Centrovani je gumou mezi L3 a C2 (pruziny delaji hluk), vyskou C2 a poctem gum se da regulovat sila a jeji prubeh s vychylkou. Cili mate vyskovku jako posun na primce asi o 30cm a kridelka jako rotaci s osou nekde ve vasich, ehm, tvorici ctvrtkruh+ s drahou take kolem 30cm.
Kalibrace: ve hre nastavite vsechna soupatka na sto ci na nulu, abyste meli linearni pohyb a zadne krivky, pak skocite do letadla a kdyz se knipl na obrazovce hybe stejne rychle jako ten vas, tak to je ono :-)
Vzhledem k experimentalnimu charakteru se pocitalo s tim, ze se to napoprve nenastreli spravne, a take bylo treba setrit hmotnosti, takze zatimco pedaly pod tim jsou svarene z velkych jeklu, tady je kombinace hlinik - drevo. Do tvrdeho dreva vyvrtate spravny prumer pro lozisko a to tam zasadite, tecka, s trochou sikovnosti nepotrebujete ani stojanovou vrtacku a udelate to na zemi. Nevyhoda - zatimco pedaly maji standardni lozisko typu "brusle" za par korun, tady je to neco mensiho a znatelne drazsiho. Mel jsem velke obavy o hmotnost a tuhost, nakonec v tom neni vubec zadny problem - kdyz povesite ruku prirozene na rukojet a davate pritom pozor, zachytite, ze se trubka poohne a provesi tak o pul centimetru, coz v provozu vubec nevadi. Rukojet je pridelana kouskem vodovodni trubky a to, jak je to pitome houzevnaty a odolny material, bylo jednim nejvetsich z prekvapeni cele stavby.
Cimz se dostavame k nejvetsimu problemu podobnych konstrukci, rukojeti. Pres vsechnu slavu s 3D tiskem je stav takovy, ze tvar nestahnete a mnozstvi materialu je takove, ze se to ani nevyplati. Takze jsem vzal za zaklad stary joy, pricemz se ukazalo, ze mnohe je treba vylepsit a take je treba nekam umistit vibracni motor. Takze vicemene vykuchani vnitrku, nahrazeni mnoha spinacu lepsimi atd. To byl velky problem a spousta casu a vlastne to ani ted neni ok, natoz zfinalizovane. Ukazalo se totiz, ze se rukojet dost krouti a ovlivnuje to funkci nekterych spinacu uvnitr.
K elektronice, joystick se tvari jako ovladac od XBOX360 a bezi na teensy LC, protoze:
-pouzit elektroniku nejakeho existujiciho joye by znamenalo spokojit se s jeho HW schopnostmi a omezenimi a spolehnout se na podporu firmy v novejsich windows (ta druha cast plati i pro ovladac xboxu, prirozene)
-postaveni si vseho vcetne elektroniky znamena moznost individualizace jinak nedosazitelne
V zasade na vsechny slozite veci existuji knihovny a cele to date dohromady v arduino ekosystemu. Ovladac umi nasledujici: ctyri osy se setnactibitovym rozlisenim, dve s mensim, deset tlacitek, dva mody vibraci (dva motorky, s malym a velkym zavazickem). Jenze MS, takze ovladac bezi na xinputu misto na directX, windows to sice nativne premosti, ale protoze to delali trupici, zkombinuji vam ty dve osy s mensim rozlisenim do jedne a vibrace jsou take jen jedny.
Sestava je tedy nasledujici, v rukojeti je motor s velkym excentrem (zdroj: cinan, eshop, nahradni dil do kontroleru xboxu), predelal jsem jeden kloboucek na analogovy (zdroj: cinan, eshop, nahradni dil do kontroleru xboxu) - to jsou dve z os s velkym rozlisenim plus tlacitko. K tomu tam jsou nejaka tlacitka a tak. Draty vedou dozadu ke druhemu konci hlavni trubky a tam je teensy, lowpass filtry pro snimani hlavnich os, mosfet spinajici motor. Hlavni osy maji magneticky senzor mezi magnety, pripojeni je celkem primocare - plus, minus a vystup skrz ten filtr na pin teensyho. Poctem magnetu a jejich vzdalenosti se docili toho, ze je vyuzita vetsina teoretickeho rozsahu (na jedne ose kolem 60000, na druhe myslim 45000+). V praxi hodnota zobrazena ve win osciluje tak o tri jednotky, takze skutecne tech bratru sto tisic moznych pozic paky mate :-). Tu posledni zkombinovanou osu nevyuzivam a par tlacitek je volnych, alespon zatim. Casem tam snad pribyde brzda.
Ted to bude vice technicke, takze klidne tenhle odstavec preskocte. Data se posilaji do pocitace skoro tak rychle, jak jen to jde, coz by znamenalo minimalni odstup 11ms mezi jednotlivymi pakety. Je to do pocitace fyzicky zapojene naprimo, vliv pripadneho usb switche jsem nezkoumal (on v zasade je switch na desce, takze i jeho zatizeni muze zhorsit situaci. Myslim). V praxi jsem tam nasadil 15 milisekund ze dvou duvodu - nechci, aby se mi pripadne plnila fronta v teensy neodeslanymi pakety, protoze kdyz neco neodejde hned, prestane to byt aktualni, a take proto, ze mam algoritmus vytvoreny tak, ze tech 15ms je standard kvuli osam, ale pokud uzivatel zmackne tlacitko, vytvori se a odesle paket hned (v praxi je pravdepodobne, ze se trefi do tech 10ms po odeslani paketu a par ms se tedy jeste bude cekat, nez skutecne odejde). Cilem bylo snizit latenci tlacitek. Cteni os je na pozadi, nepretrzite, interrupt vyzvedne vysledek a ihned spusti cteni dalsi osy, stale dokola. Odesilaci rutina zprumeruje vysledky, at uz je jich mene ci vice. Za tech 15 ms dokaze teensy nakonfigurovane na nejvetsi presnost AD prevodniku precist kazdou ze ctyr os zhruba sestkrat. Debounce tlacitek je v SW, metoda akumulator.
Vibrace: spinaci mosfet umi sepnout uz od dvou a neco voltu, takze je tam naprimo (cti: pres odpor, s dalsim proti zemi). Jednim z problemu ostatnich testovanych reseni bylo, ze kdyz to zapnete, tak pulvterina, nez teensy nabootuje a uzemni pin, co ridi mosfet, staci na to, aby se motorek na chvilku rozebehl a to pak delalo problemy pri enumeraci zarizeni. Regulace je klasicka PWM s tim, ze byly otestovany minima vykonu, kdy se motor jeste udrzi v behu a kdy se z klidu nerozbehne. Takze prikaz z pocitace k vibracim o male intenzite se muze docasne ci trvale zmenit (strucne, musite dat 70 vykonu z 255 po dobu 60ms pro rozbeh, potom nechat minimalne 20, aby se nezastavil). Motor je dost vykonny, maximum mam kolem 150/255 a staci to v pohode.
Vysledkem je joy, ktery je nejlepsi, co jsem kdy zkusil, i kdyz zatim trochu nedotazeny a nespolehlivy. Podle mych subjektivnich meritek, samozrejme, viz nahore o kompromisech a prioritach.
Problemy a hacky, co bych udelal jinak nebo co mozna jeste udelam jinak:
-kdyz bezi motorek vibraci delsi dobu na vetsi vykon, obcas joy odpadne od portu. Mozna to zere moc elektriky. Musim bud neco vykutit s prubehem proudu, jestli to neni nejakym rusenim, nebo spojit dva usb konektory, jako to maji treba prenosne disky.
-Mam osy ze sroubu, coz znamena, ze senzory jsou nasroubovane na kraj osy. Funguje to bez problemu, ale trochu si to rika o to, ze senzor vyskovky nekdo urazi, kdyz vycniva do strany (senzor kridelek je schovan uprostred, ten je v pohode). Kdybych to delal nyni (a vedel, ze to cele dopadne :-)), asi bych zkusil sehnat nerezovou nebo jinou nemagnetickou trubku vnejsiho prumeru rovneho vnitrnimu prumeru loziska, senzor dat dovnitr, klidne ho necim zalit a to pouzit jako osicku.
-nevyhoda konstrukce umistene na zemi je, ze to navrhujete pro urcitou vysku stolu a zidle. Na to je treba myslet, nez zacnete vyrabet. Vzhledem k nutnosti spravne kombinace vzdalenosti a pak neni zmena vysky trivialni jako prodluzovani nebo zkracovani tyce vedouci kolmo od podlahy nahoru, tady kdyz ohnete tyc dolu, tak sice pohyb zustane hezky primocary, ale priblizite rukojet k ose kridelek. Samozrejme lze podlozit ci naklopit pedaly, na kterych je to usazeno, a tim posunout ci pootocit i cely joy.
-rukojet je problem. Velky. Protoze je ve spravne pozici na drzeni, tj. dost naplocho, a asi je udelana podle skutecne velikosti, ktera ale pocitala s rukavici, je proste moc velka. Taky je moc mekka, protoze je ze trech plastovych dilu a jen jeden z nich jde prubezne shora dolu a jeste ma vyrezy na tlacitka.
-pokud chcet dotahnout myslenku, ze se joy pri polozeni ruky nehne, musite pocitat i kridelky - podle toho, jestli je to pro pravaka nebo pro levaka. Vliv je maly, ale tim, ze vsechno chodi extremne hladce, se vysledovat da
-vibracni motor bych necpal do rukojeti, ale dal bych ho dozadu. Do rukojeti by se sice daly narovnat dva, misto tam je ale ve vysledku tam vlastne nejsou potreba. Motor bych dal dozadu k elektronice - vibrace do kridelek, ktere by tlumila pruznost trubky, vlastne nepotrebujeme, vibrace z vyskovky by byly trubkou prenaseny tahem a tlakem, takze to je ok, jedina neznama je pruznost rukojeti. Ten motorek by mohl byt klidne osickou vodorovne, kdyz vibrace v kridelkach nepotrebujeme. Ty vibrace mi tak moc k letadlu nesedi a mozna je to tim, ze vibruji i kridelka.
-xinput knihovny, zda se dle popisu, nyni uz existuji i pro arduino pro a podobne mene vykonne jednocipy. Netestoval jsem to. Pokud by to fungovalo, usetrila by se cena, mam ale podezreni, ze AD prevodniky budou znatelne horsi a kdyz uz budete delat tak velky projekt, nemusi to byt dobry kompromis.
-kdyz je usb port pod proudem, tak to bezi. Ano, je to elektronika, presto me predstava, ze to bezi 365/24, nenaplnuje nadsenim. Uz jen proto, ze bych musel resit preteceni ruznych timestampu treba po padesati dnech, takove veci se spatne ladi. Zatim jsem se nerozhodl, jestli to budu resit vypnutim napajeni portu, kdyz pocitac nebezi (lze nastavit v biosu), nebo nejakym spinacem.
X360 pad, tedy i ovladače umí 6 os. 2x X, Y osy + L, R osy na ukazováčcích.
LesniHU napsal:
Jenze MS, takze ovladac bezi na xinputu misto na directX, windows to sice nativne premosti, ale protoze to delali trupici, zkombinuji vam ty dve osy s mensim rozlisenim do jedne a vibrace jsou take jen jedny.
X360 pad, tedy i ovladače umí 6 os. 2x X, Y osy + L, R osy na ukazováčcích.
LesniHU napsal:
Jenze MS, takze ovladac bezi na xinputu misto na directX, windows to sice nativne premosti, ale protoze to delali trupici, zkombinuji vam ty dve osy s mensim rozlisenim do jedne a vibrace jsou take jen jedny.
Prostě máš blbej gamepad. Já mám Logitech F710, ten je přepínatelný mezi Xinput a DirectInput
No, předělávám trochu pedály od Josky a vytvářím tam něco podobného Crosswind. Doteď jsem si myslel, že jsem uplnej magor.
Ale držím palec a obdiv nemyslím ve zlým.
Další kreativní tvor, nápad a konstrukce je tvůj, nebo jsi čerpal z nějakého zdroje?
Jak se zmiňuješ o ffb motorech, že slábnou (nejspíš USB omezení 500mA) mohl vyřešit USB-hub s pomocným napájením.
Teoreticky při takovém přepákování, není třeba protizávaží, když v tom máš váhu ruky plus vynaloženou sílu na změnu pohybu?
Jsem rád že se nebojíš složité konstrukce, docela rad bych viděl video, jak mechanika funguje v praxi, dík za sdílení výjimečného joye.
Upravil/a petsild dne 23-03-2020 08:21
Úžasné. Ne, nečetl jsem to celé. Nemám na to morálku. Mám moc práce a tak. Ale stran ovladačů a FFB, nepřemýšlel jsi o použití vJoy? vJoy je programovatelný driver (např. v C#), který má i podporu FFB. Přemostění z USB do vJoy se dá vytvořit celkem snadno. Pro .NET najdeš sbírku knihoven, který umějí pracovat přímo s USB a do vJoy to narveš už jako svoje čísla na tolik os a čudlíků a HATů, kolik jich jen Windows podporují.
Zrovna nějak v únoru jsem si s tím hrál a napsal jsem si takový prototyp přemostění mezi USB HID a vJoy. Někde jsem to ale dokázal potratit.
@petsild, SW ve smyslu knihoven na komunikaci pres USB jako ten gamepad udelali jini, celou mechaniku i zbytek SW jsem delal ja sam, jak jsem chtel.
To s tim USB hubem me take napadlo, ono je to trochu slozitejsi - 500mA neni garantovanych, o to si zarizeni musi pozadat a muze mu to byt zamitnuto. Nemohu vyloucit, ze zatimco skutecny xbox kontroler to dela, tak ty knihovny, nad kterymi sjem to postavil, to nedelaji. I kdyz bych se divil, kdyby v dnesni dobe kazdy port neumel tech 500 fyzicky dat, cili tenhle protokol je bezpredmetny. Mam jeden hub v monitoru, kde bych to mohl vyzkouset, ale ne dost dlouhy usb kabel :-).
Spis to musim nejak promerit na osciloskopu, jestli motore nedela nejake pulzy a kolik energie v tom je. USB port na tomto motherboardu jsem u z jednou zkratoval a nejspis ma polovodicova pojistky, prislo mi, ze ted fungoval dal hned, tehdy potreboval trochu casu, aby pojistka odkrystalizovala. Takze nevim, cim to je. Taky to muze byt na strane jednocipu, motorek udela nejaky brownout, ktery vyradi teensy az do rebootu - skoro je to pravdepodobnejsi varianta. Teensy sice bezi na 3.3V (ma svuj stabilizator) a motor primo na peti z usb, ale dovedu si predstavit, ze nejaka vykonova spicka prohne usb napeti az pod 3V3.
Protizavazi tam zadne neni, zavazi=setrvacnost. Tim, ze je draha k sobe nahoru a od sebe dolu, tahne gravitace hmotnost polozene ruky dopredu (jak na klouzacce), zatimco ohnuty kloub lokte dozadu. Ten uhel se da vychytat tim, ze privazete provazek na strop, chytite jeho konec a budete posouvat svou zidli po podlaze tak dlouho, az vam bude ruka viset jak chcete, aniz byste vydavali jakoukoliv silu. Uhel provazku ke stropu je pak dopredu nahoru, kolmo na primocary pohyb, jaky potrebujete.
To je stredni, neutralni poloha, at pak tahnes kamkoliv, pridava se guma jako sila snazici se vratit rukojet do stredu. Hmotnost se projevuje, samozrejme, je to videt na fotce, trochu to visi dopredu, protoze ty "acka" dolu ka zemi musi byt vicemene kolme na smer pohybu, to jest naklonene dopredu. Gravitace pak pridava sily do vyskovky a diky draze uchytu se guma take nenatahuje stoprocentne linearne, takze by se dalo teoretizovat, ze se sily nechovaji spravne a ze se tam pridava "spatne" i hmotnost ruky, mohlo by to byt i meritelne, ale v praxi si niceho takovemo nevsimnete.
@Rumcajs: kdyz jsem to zacinal stavet, coz uz je fakt dlouho, tak myslim vjoy existoval, ale nedisponoval nicim pro me vhodnym. Ani ted jsem tam nevidel, ze by umel smerem ke hre publikovat nejake standardni FFB(*), ale mohu se mylit, jen jsem to kratce prekouknul. Ja jsem pres arduino uz delal vic veci, takze to pro me bylo jednoduche a primocare.
(*)protoze to je ten bod, ktery je nejvice podstatny a nejvetsi kamen urazu. Vsechno ostatni se da vykutit, lepe ci hure.
FFB bylo do vJoy přidáváno ... nevím asi 2 roky to je. Podle mě je vJoy aktuálně asi nejsnazší cesta, jak krmit Windows daty pro Joystick, aniž by člověk musel programovat driver, platit certifikát pro podpis driveru a vůbec absolvovat to kolečko low level programování. Pro mě byl vJoy taky byla spása, nenašel bych dost nadšení, abych si to celé absolvoval. V C++ jsem toho moc nenapsal, byl by to boj. Tohle se ovládá z .NETu, což je v pohodě. Strana čtení USB má dnes již vlastně sbírku alternativ, i když ne úplně triviálních. Já jsem to před časem řešil přes SlimDX, které ja takové ... no jako jo, je to C# objektově orientované, ale už bych to nedoporučil. Dnes je k dispozici celá řada knihoven, které čtou přímo USB s nějakou mírou komfortu. Tedy jdou mnohem níž než umožňovalo SlimDX. Lze tak číst přímo stream z toho USB zařízení. Nebo lze do toho zařízení posílat data.
Takže ta cesta jak číst z USB HID zařízení, něco s tím dělat a poslat to do Windows ve formě Joysticku, je relativně snadná. Obdobně pak FFB. vJoy FFB podporuje, tedy ze hry dostaneš data komfortně ve formě C# objektů/čísel. Můžeš s tím cokoli udělat a poslat nějak do USB zařízení.
No kdybys náhodou o něčem takovém uvažoval, asi bych našel čas na to vyrobit takový bridge, aby bylo čtení/zápis z/do USB nějak smysluplně objektivizováno v .NETtovém smyslu a ne ve formě surových dat. Ono mít jen surová data z USB a vyrábět z toho smysluplné objekty, je přeci jen kus práce. Jak jsem psal, už jsem si vlastně něco takového psal (jen tak pro radost), ale ztratil jsem to. Asi pod dojmem návalu práce.
Pěkný Nechceš postnout video, jak s tím hejbeš pro ukázku?
Pro mě by byl třeba zas FFB důležitý, tak jen pro zajímaost:
Co se týče zpřevodování motorů pro FFB, ozubená kola nejsou jediným možným řešením, nabízí se zpřevodování pomocí lanka navíjejícího se a odvíjejícího se na nějaké kulatině, čímž sice dosáhneš plynulosti při pohybu z hlediska toho, že to nebude přeskakovat po zubech na převodech, ale! furt tam budeš cejtit jak se komutátor na rotoru motoru hejbe mezi jednotlivýma magnetama, čím silnější motor, tím vlastně asi horší, protože u slabého motoru se ti ta nestabiita v síle daná aktuální polohou cívky a magnetu (případně uhlíků) ztratí v mnoha otáčkách (díky vyššímu zpřevodování) při malém pohybu...
PS: a pak se taky dělaj mini motorky s planetovou převodovkou na výstupu, což by myslím taky vyřešilo problém s plynulým zpřevodováním...
Upravil/a Hot_Dog dne 23-03-2020 21:55
Na vJoy jsem se znovu podival a skutecne tam jsou nejake funkce pro FFB, takze musim revidovat sve tvrzeni, ze jsem tam nic takoveho nevidel. Nicmene je to opet pripad, ze bych byl zavisly na nejakem dalsim komplikovanem systemu s malou podporou. Nemyslim, ze je to nejsnazsi cesta, podivej: nainstalujes arduino (jeden exe), spustis, zvolis file->examples->joystick->[priklad, co ti prijde nejvhodnejsi], pripojis arduino usb kabelem, zvolis jeho typ v tools->board a zmacnes upload. No a mas USB HID joystick, co ti posila data do jakekoliv hry, trumfni to :-). Az budes mit pripojene tlacitka a potenciometry, napises necelou stranku kodu a zmacknes upload. Samozrejme pokud budes chtit nejakou specialitu jako ja, tak bude tech kroku i stranek znatelne vice.
FFB: v principu si nemyslim, ze letecky simulator potrebuje force feedback ve smyslu komplikovanych efektu na pace. Potrebuje otresy a potrebuje posunovat stredovou polohu a menit centrovaci sily. To je vse. Nepotrebuje, aby vam simulator tahal za paku (ano, u letadel jako F-104 by se to vyuzilo, ale to jsou vyjimky). Proto bych za rozumne reseni nepovazoval, ze centrovaci silu bude vyvijet motor. Na to jsou pruziny. S delkou pohybu paky se zvysuji problemy s motorem, ano, da se zprevodovat, ale kdyz ma byt sila na rukojeti stejna jako u kratkeho joye, musi byt zprevodovan stejne (ve smyslu otacek na posun rukojeti, ne na nakloneni paky) a to znamena, ze pohyb, ktery uzivatel udela, ho bude typicky roztacet do vyssich otacek. A tim se nam vsechno komplikuje, sily, setrvacnosti, pocit z pohybu.
Dokonaly joystick? Mozna pneumaticke mechy misto pruzin, kazdy napojeny na valec s pistem, ktery bude posunovan elektromotorem. Zmena tlaku plynu bude menit sily, rozdil ve vzajemne poloze pistu zmeni pozici stredu, mechy nebudou mit zadne treni, ktere by nam kazilo dojem z pohybu paky.
Tak ten vJoy je fajn v tom, že to umí ze hry přijímat ty FFB data. Nemusíš vyrábět cukání za páku, ale pokud chceš posun středu, tak to jsou přesně ty čísla, který někde potřebuješ získat. Pokud umí FFB číst to arduino, pak to můžeš udělat přes to arduino. Nakonec i arduino se dá programovat v kdečem rozumném.
Problem s odpadavanim od portu jsem vyresil, kdyz bezel motorek, tak napeti skakalo o pul voltu. Zvedl jsem frekvenci pwm a pridal nejake elyty vytazene ze spinaneho zdroje a je to v pohode. Takova kapacita se samozrejme neda pridat naprimo, omezeni usb je tusim 10uF, takze se nabijeji pres proud omezujici diodu a teprve az se napeti vyrovna, tak je procesor pripoji naprimo (na to jsem pouzil druhy mosfet, ktery tam mam jeste z doby, kdy jsem cekal vyuziti dvou vibracnich motorku).
Jeste jedna zkusenost typu "kdybych neco takoveho delal znova": pridal bych tam jednoduchy displej, i kdyby tam mel byt ciste jen na ladeni a vyvoj. Nejaky oled na I2C stoji dolar nebo kolik a potrebuje jen dva piny procesoru. Uzitecnost zobrazeni, co vlastne prichazi z pocitace za presnou hodnotu, je obcas nevycislitelna.
Docela velké mechanické výchylky na rukojeti, nejsi pak vyčerpaný po letecké akci.
Ještě se musím zeptat, na co všechno vibrační motorek v simech reaguje?
Ne, unavny to neni, chodi to zlehka a nejsou tam moc velke sily. Kdyby byly, muselo by se to prisroubovat k podlaze.
Motorek reaguje na to, co mu prijde ze simu. Udelal jsem takovy vyzkum (nakonec doslo i na ten displej, abych videl, jaka hodnota tam z pocitace leze):
BoX vrci vzdy pri pohybu na zemi, pred padovkou, pri velke rychlosti a myslim pri strelbe. S poskozenym letadlem behem letu se to cas od casu zatrepe bez viditelneho duvodu. Kdyz te nekdo trefi, tak nic.
DCS: tam jsem zbrane nezkoumal, ani z jedne ani z druhe strany. Ve Viggenu trepe stick shaker a pri prekroceni rychlosti zvuku/nadzvuku (nekdo si s tim vyhral, kolem nula devet neco to zacne trepat, pak pri nula devet neco vic prestane a pak zase zacne).
TF51 je dle ocekavani a tak, jak bych si predstavoval implementaci v BoX - kdyz dojizdis po pristani, tak je citit, jak se pri zpomalovani proud vzduchu prestava opirat do kormidel, v BoX je jen prepinatko pohyb/nepohyb (nicmene BoX alespon respektuje ruzny povrch)
F-14 trepe klackem vzdycky, kdyz se zvedne vykon motoru z volnobehu, takze vlastne furt, ale fakt malinko. Pri dojezdu vic.
Sily trepani jeste nemam vyladeny, resp. mam vyladene minimum, ale ne maximum, celkovy pocit pak muze byt o hodne jiny. To nahore urcite neni kompletni seznam vsechn efektu.
Vykání je následek nepochopení formy vlády pozdních římských císařů. Koncem Římského císařství spoluvládli čtyři vládci. Proto byli oslovován jako celek. Tykání je správné.
IL-2 Sturmovik™, Cliffs of Dover™, Pacific Fighters™ are trademarks or registered trademarks of 1C EUROPE, 1C-Multimedia, 1C ONLINE GAMES.
Other marks used herein are those of their respective owners.
kreativní tvor, nápad a konstrukce je tvůj, nebo jsi čerpal z nějakého zdroje?
Nechceš postnout video, jak s tím hejbeš pro ukázku? 