Kontrolery gier

[0x8000ffff]

1 godzinę temu, error723 napisał(a):

Wiem, chciałeś swoje zdanie dołożyć, dołożyłeś - tak w kwestii emocjonalnych uniesień, do których się odwołujesz.

No chciałem, zaspokoiłem też swoją potrzebę przekazania z własnego doświadczenia, że można to zrobić prosto, bez przerostu formy nad treścią, przynajmniej w Maszynie to moim zdaniem wystarcza. Automatyka czy elektronika to moje hobby, nie usiłuję udawać że wiem czegoś, czego nie wiem. Nie lubię też gdy inni usiłują w dyskusji wywierać wrażenie ekspertów, bo nikt nikomu dyplomu czy świadectw kwalifikacyjnych nie przedstawiał. Może za MQTT przemawiają jakieś argumenty, jeśli projekt o który toczy się dyskusja miałby pełnić szersze funkcje niż fizycznego pulpitu zastępującego klawiaturę i przyrządy na ekranie, ale odniosłem wrażenie, że dyskusja jest o owym pulpicie z kontrolkami i wskaźnikami.

[error723]

Rozszerzę i może się to komuś przyda przy własnej przygodzie z budową panelu pod proponowane rozwiązanie z MQTT.
Broker będzie uruchomiony na Twoim hoście, będąc wpięty do silnika gry, czyli jego latencja to 1-5ms(?) - wiadomości możesz odbierać już na swoim PC czyli nadal możesz stworzyć adapter, którym obsłużysz MIDI (jest to narzut, ale można jak ktoś chce - można także podpiąć RPi0 jako HID, a można spiąć małe ESP32 bezpośrednio z brokerem).
I tutaj masz dowolność, czy podepniesz panel po lan, wi-fi, czy rs... każde medium to obsłuży bo jest jedynie pośrednikiem. 
Czyli model wygląda tak: panel -> wi-fi/lan -> localhost broker (wbudowany w SR) -> silnik gry. W takim ujęciu zapchanie kolejki brokera może być spowodowane złą implementacją własną, notify wywoływane jest jedynie przy zmianie stanu, a nie odpytywanie o każdy element kilka razy na sekundę. Działasz na zasadzie "słucham i reaguje na subskrybowane zdarzenia", nie mnie, nie więcej. Nie, nie ma mowy, że w takim ujęciu zapchasz kolejkę brokera i przez to hamulec zacznie działać po 100ms czy więcej. Tutaj trzeba dodać, jeden broker może obsługiwać wiele kolejek, a to pozwala na to, że notify=hamulec będzie mieć priorytet nad notify=ustawŚwiatłoReflektoraGórnegoStanWłączone.
Oczywiście, że nie zaprojektowałbym takiego rozwiązania w urządzeniach typu hard real-time, ale to jest symulator, gra i tutaj przede wszystkim ważne jest to, by jak najwięcej osób było w stanie samodzielnie wykonać zewnętrzne urządzenia bo to pozwoli na rozwój samego produktu - jasne, że chciałbym by było to jak najbardziej skomplikowane, mógłbym zarobić na budowie takich paneli, ale z perspektywy wydawcy, lepiej by chodziły w sieci samouczki z przykładami lub gotowymi rozwiązaniami. 
MQTT to inny poziom abstrakcji w ujęciu "komunikacja" i to jest kluczem w tej propozycji - niezwykle łatwo to rozszerzyć o kolejne pojazdy, nawet jeśli miałyby nowe elementy do obsługi. Ba, właściwie można przygotować API do każdego elementu w grze oddzielnie, przez co każda lokomotywa byłaby obsługiwana przez dedykowane wiadomości dzięki czemu unikamy konfliktów.
Uniwersalność i prostota, a zarazem rozszerzalność - i podkreślam, to jest symulator, tutaj nikt nie zginie jeśli hamulec awaryjny zacznie działać z opóźnieniem 10, 50 czy nawet 100ms!

[Mywasher]

Bardzo lubię teoretyków z maniakalnym zacietrzewieniem w stronę rozwiązań, które z nieoczywistych dla ludzi spoza branży automatyki przemysłowej, wyglądają ładnie w teorii. To co dla Ciebie jest namiarowością i jakimś dziwnym utrudnieniem dla mnie jest bezpieczeństwem i stabilnością. 
Odwróćmy więc role: ile zaawansowanych technicznie projektów o wysokim poziomie niezawodności wdrożyłeś w oparciu o MQTT? Pytam z czystej ciekawości bo jednak Modbus RTU, pętle prądowe czy magistrale szeregowe są stosowane powszechnie w automatyce, a MQTT to raczej w smart home'ach. W zakresie sterowania urządzeń/maszyn chyba nikt normalny by tego nie zastosował bo szkoda oglądać słońce przez kraty. 
Implikujesz nam, a w zasadzie próbujesz zrealizować incepcję, że MQTT to panaceum na całe zło świata i tylko idioci korzystają z klasyki typu DMX, Modbus RTU, MIDI, a to całkiem zabawne bo jakoś Vectrny, Gammy, Elfy, pojazdy z dwiema kabinami to idealne pole do wdrożenia brokera... a nie, wróć, hahaha 🙂 

Jeszcze dla udowodnienia drobnego szczegółu bo chyba coś komuś umknęło: MIDI od zarania dziejów obsługuje komunikaty SysEx... i one mogą mieć dowolną długość... w MIDI 2.0 masz w prezencie natywność systemową, 32 bitową rozdzielczość i pełną dwukierunkowość.  MIDI to protokół binarny z minimalnym narzutem, w stosunku do MQTT praktycznie zerowym. 
Nie dalej jak wczoraj wieczorem czytałem, że wszystko na multi laguje, że nawet na singlu są jakieś kłopoty z optymalizacją... i w ten caly średnio wydajny grajdołek, chcemy wstawić broker czekający aż silnik wypluje z siebie dane lub ewentualnie je przyjmie? 

Ile symulatorów w których liczy się imersja korzysta z MQTT do obsługi peryferiów? Może coś z F1? Flightsimulator? 

Czy sobie przepiszę wypowiedź z Geminii żeby była bardziej spójna i logiczna, czy napiszę z palca to nie ma znaczenia bo liczy się merytoryka podparta zrealizowanymi projektami. 

BTW, szybciej na Ardu odpalę precyzyjny kontroler midi niż Ty zapewnisz mi że ostatni payload jest w aktualnym stanem, a nie tylko ostatnim zapamiętanym stanem (retain flag).

[error723]

18 minut temu, Mywasher napisał(a):

Bardzo lubię teoretyków z maniakalnym zacietrzewieniem w stronę rozwiązań, które z nieoczywistych dla ludzi spoza branży automatyki przemysłowej, wyglądają ładnie w teorii. To co dla Ciebie jest namiarowością i jakimś dziwnym utrudnieniem dla mnie jest bezpieczeństwem i stabilnością. 
Odwróćmy więc role: ile zaawansowanych technicznie projektów o wysokim poziomie niezawodności wdrożyłeś w oparciu o MQTT? Pytam z czystej ciekawości bo jednak Modbus RTU, pętle prądowe czy magistrale szeregowe są stosowane powszechnie w automatyce, a MQTT to raczej w smart home'ach. W zakresie sterowania urządzeń/maszyn chyba nikt normalny by tego nie zastosował bo szkoda oglądać słońce przez kraty. 
Implikujesz nam, a w zasadzie próbujesz zrealizować incepcję, że MQTT to panaceum na całe zło świata i tylko idioci korzystają z klasyki typu DMX, Modbus RTU, MIDI, a to całkiem zabawne bo jakoś Vectrny, Gammy, Elfy, pojazdy z dwiema kabinami to idealne pole do wdrożenia brokera... a nie, wróć, hahaha 🙂 

Jeszcze dla udowodnienia drobnego szczegółu bo chyba coś komuś umknęło: MIDI od zarania dziejów obsługuje komunikaty SysEx... i one mogą mieć dowolną długość... w MIDI 2.0 masz w prezencie natywność systemową, 32 bitową rozdzielczość i pełną dwukierunkowość.  MIDI to protokół binarny z minimalnym narzutem, w stosunku do MQTT praktycznie zerowym. 
Nie dalej jak wczoraj wieczorem czytałem, że wszystko na multi laguje, że nawet na singlu są jakieś kłopoty z optymalizacją... i w ten caly średnio wydajny grajdołek, chcemy wstawić broker czekający aż silnik wypluje z siebie dane lub ewentualnie je przyjmie? 

Ile symulatorów w których liczy się imersja korzysta z MQTT do obsługi peryferiów? Może coś z F1? Flightsimulator? 

Czy sobie przepiszę wypowiedź z Geminii żeby była bardziej spójna i logiczna, czy napiszę z palca to nie ma znaczenia bo liczy się merytoryka podparta zrealizowanymi projektami. 

BTW, szybciej na Ardu odpalę precyzyjny kontroler midi niż Ty zapewnisz mi że ostatni payload jest w aktualnym stanem, a nie tylko ostatnim zapamiętanym stanem (retain flag).

Jakim cudem zajmujesz się automatyką skoro zdań prostych nie potrafisz przeczytać ze zrozumieniem? Jak chcesz na lekcje, to zapraszam. W przeciwnym razie, odrób lekcje samodzielnie - wiele napisano o projektach.
I przelicz w taktach, ile procesorowi, który jest wymagany jako minimalny dla gry zejdzie na "obrobienie ramek" skoro tak straszysz narzutem.

BTW, decyzja podjęta, pozostaje Ci marudzenie, że ktoś podjął decyzję inną niż byś chciał.

Edited Tuesday at 10:07 PM by error723

[Mywasher]

Tobie to nic nie muszę udowadniać, swoją niekompetencję już uwiarygodniłeś więc nie baw się w emocjonalne przebłyski, że ktoś tu czegoś nie zrozumiał. Jedyną osobą, która nie rozumie złożoności sytuacji jesteś Ty sam i jest to na swój sposób smutne bo nawet nie masz cienia wątpliwości, że MQTT to najgorsze możliwe rozwiązanie w tym zakresie.

[error723]

12 minut temu, Mywasher napisał(a):

Tobie to nic nie muszę udowadniać, swoją niekompetencję już uwiarygodniłeś więc nie baw się w emocjonalne przebłyski, że ktoś tu czegoś nie zrozumiał. Jedyną osobą, która nie rozumie złożoności sytuacji jesteś Ty sam i jest to na swój sposób smutne bo nawet nie masz cienia wątpliwości, że MQTT to najgorsze możliwe rozwiązanie w tym zakresie.

Kompetencja forumowa? Widzę członek elektrody 🙂 Pozdrawiam serdecznie 🙂

[stary_ortalion]

To może

protokół MQTT poprzez sprzętowy interfejs MIDI 😉

będzie wilk syty i owca cała 😉

 

 

 

 

 

BP,MSPANC

Edited 20 hours ago by stary_ortalion

[0x8000ffff]

12 godzin temu, stary_ortalion napisał(a):

protokół MQTT poprzez sprzętowy interfejs MIDI

Dobre... 🙂

Ja tam się nie znam, ale czytałem, że to rozwiązanie MQTT to jest do inteligentnych domów i IoT. W motoryzacji np. są różne bardzo nowoczesne rozwiązania, ale jednak sterowanie jest przez "staroświecką" magistralę CAN. To skąd ten upór żeby to stosować do sterowania lokomotywami w symulatorze? W dyskusji tylko same docinki i zgryźliwości jednych wobec drugich, merytorycznej argumentacji jak na lekarstwo. Tylko słyszę że tak, bo to jest nowoczesne.

Tak, to będzie sarkazm, nie próba dowalenia komukolwiek, ale czy naprawdę zamiast joysticka wpiętego do portu USB muszę mieć urządzenia wpinane do internetu, bo to jest trendi?

Edited 8 hours ago by 0x8000ffff

[error723]

Przecież MQTT nie broni Ci wpięcia urządzenia po USB, co napisałem tu:

MQTT w takim ujęciu jest jedynie API dla Twojego sterownika, którym łączysz się po USB, czy nawet porcie szeregowym (jak masz ochotę). Tak, w takim ujęciu masz dodatkową pracę, bo musisz napisać adapter, który zepnie komunikację MIDI czy jaką tam sobie wymyślisz, z API wystawionym przez programistów (MQTT). To wszystko. Pisanie o narzucie miałoby sens, gdybyśmy mieli jednordzeniowe procesory pokroju 80286 - faktycznie, dodanie ramek byłoby kosztowne, ale nie dla wielordzeniowych procesorów mających miliardy operacji na rdzeń! 
Mówimy o brokerze i subskrybencie na tym samym hoście, koszt "narzutu" to 100µs na wiadomość? Tak, mówimy o rzędzie wielkości 100 mikro sekund, gdzie jedna mikro sekunda jest jedną milionową sekundy. Utyskiwanie na opóźnienia przy tego typu procesorach (a ten minimalny, zalecany do gry to:  jest absurdalne. 
I uzupełnijmy, jakiekolwiek by API przez programistów nie było, to i tak na Tobie wisi stworzenie sterownika, do układu który chcesz podłączyć, a MQTT zwalnia każdego chętnego choćby z tworzenia kolejek i priorytetów, bo tym  zajmuje się broker, który będzie wystawiony jako API.
A jeśli chodzi o "trendi" i automotive https://bmw-cardata.bmwgroup.com/customer/public/api-documentation/Id-Streaming_MQTT-example   tutaj masz więcej o samym projekcie, ile funkcjonuje, jak funkcjonuje i w jakim zakresie https://www.hivemq.com/case-studies/bmw-mobility-services/ 

I wierz mi, to nie jest jedyne rozwiązanie MQTT w szeroko rozumianej automatyce.

edited.
Ponadto, jak API się pojawi to sam na github wystawie repo, które udokumentuje i pokaże jak podpinać kolejne elementy, a z pewnością nie będę jedynym. Powstaną nie tylko gotowe projekty, ale także template dla różnych rozwiazań.

Edited 7 hours ago by error723

[Mywasher]

Bo idea powinna być prosta, niskolatencyjna, efektywna i wspierana natywnie przez system operacyjny. Spośród wielu gotowców, które są dostępne i łatwe do wdrożenia najlepiej wypada właśnie MIDI. Możemy sobie to potwierdzić w bardzo przystępny sposób wpisując takie coś w yT:

Gwarantuję Ci, że gdyby był to protokół zawodny i obarczony co najmniej "takimi zaletami" jak MQTT to żadna normalna osoba nie próbowała by grać muzyki na żywo za pomocą komputera. Stworzenie kontrolera MIDI w oparciu o RPi/ARDU/ESP to banał w obecnych czasach. Ja trzymam się rękami i nogami tego, że to co robię musi być natychmiastowo przetwarzane - koniec i kropka. Opowiadanie o tym, że MQTT uratuje sprawę to najwyższy poziom ucierania dupy szkłem o jakim słyszałem w branży gier od dekady. 

[0x8000ffff]

Czytam, po translacji: Jedną z takich usług opracowanych przez BMW Mobility Services jest produkt car-sharingowy dla operatorów flot. Usługa ta umożliwia operatorom zdalne zarządzanie flotą pojazdów, wydawanie zdalnych poleceń poszczególnym pojazdom (np. blokowanie/odblokowywanie) oraz gromadzenie danych z każdego pojazdu.
Mam jeden pulpit i jedna lokomotywę, pulpit lokalny, podłączony do portu komunikacyjnego. Mnie interesuje takie rozwiązanie, a nie ciągnięcie danych z internetu o lokomotywie, która mam lokalnie. Do tego nie jest mi potrzebny żaden pośrednik  (chyba że sprzętowy), ale nie kolejny serwer czy coś w tym rodzaju... Chyba jestem idiotą, bo ni w ząb tego nie rozumiem, zatem kończę wtrącanie się w tematykę, która mnie przerasta.

[error723]

Skończ już z wycieczkami osobistymi, chyba, że to jedyne co potrafisz w formie argumentacji:




I teraz udowodnij, na liczbach, ile zajmuje Publish - Routing (w brokerze) - Deliver do subscriber. Wykaż, że naprawdę wiesz o czym mówisz utyskując na "opóźnienia". Do obliczeń użyj najsłabszego procesora jaki jest rekomendowany, czyli .
Chcę zobaczyć tą "kompetencję", której mi odmawiasz, nie mając pojęcia kim jestem. I by było jasne, ja naprawdę widziałem te Twoje obrzydlistwa:

[error723]

2 minuty temu, 0x8000ffff napisał(a):

Czytam, po translacji: Jedną z takich usług opracowanych przez BMW Mobility Services jest produkt car-sharingowy dla operatorów flot. Usługa ta umożliwia operatorom zdalne zarządzanie flotą pojazdów, wydawanie zdalnych poleceń poszczególnym pojazdom (np. blokowanie/odblokowywanie) oraz gromadzenie danych z każdego pojazdu.
Mam jeden pulpit i jedna lokomotywę, pulpit lokalny, podłączony do portu komunikacyjnego. Mnie interesuje takie rozwiązanie, a nie ciągnięcie danych z internetu o lokomotywie, która mam lokalnie. Do tego nie jest mi potrzebny żaden pośrednik  (chyba że sprzętowy), ale nie kolejny serwer czy coś w tym rodzaju... Chyba jestem idiotą, bo ni w ząb tego nie rozumiem, zatem kończę wtrącanie się w tematykę, która mnie przerasta.

Z jakiego internetu? Broker działa na sockecie na Twoim hoście, lokalnie! 

[Królik Uszasty]

@Mywasher Nie uważasz, że jednak Twoje wypowiedzi trochę zbyt emocjonalnie podchodzą do tematu, a niektóre porównania wręcz niesmaczne? Wydaje mi się, że jest już bliżej jak dalej do ukończenia prac i z jakiegoś powodu taki standard został wybrany - nie wiem, nie znam się i nie będę tłumaczył powodów wyboru i całego toku myślowego, jaki za tym stał. Nie sądzę, żeby na tym etapie ktoś zaorał wszystko tylko dlatego, że jeden użytkownik forsuje inny standard. 

 

Natomiast porównywanie pulpitu w domu do rozwiązań przemysłowych (a już co gorsza - pojazdów kolejowych) nie jest chyba na miejscu. Ja wiem, że nawet wyolbrzymione pół sekundy opóźnienia przy włączaniu hamowania przy prędkości 200 km/h to prawie 30 metrów różnicy w miejscu zatrzymania, ale bądźmy szczerzy - jeśli komuś naprawdę takie coś uniemożliwiałoby za każdym razem zatrzymanie się w miejscu, to jednak chyba trzeba zmienić technikę jazdy. Inna sprawa, że ja nie spodziewałbym się jakichś dużych i zauważalnych opóźnień w transmisji, zwłaszcza że te istotnie responsywne to muszą być w większości wypadków ze... 4(?) manipulatory (nastawnik, bocznik/tempomat, hamulec zespolony, hamulec pomocniczy). Myślę, że prawdziwe pojazdy w niektórych sytuacjach serwują większe opóźnienia (typu zawieszający się na kilka sekund monitor diagnostyczny przy włączaniu hamowania nagłego, bo musi przetworzyć na raz kilkanaście komunikatów o błędach). Sam do MaSzyny skonfigurowałem swój pulpit do komunikacji co 100 ms i jeździło mi się dobrze. Głównie dlatego, że wystarczyło ruszyć ręką zamiast korzystać z klawiatury.

 

Co do samych magistral komunikacyjnych, no to cóż... no mamy na przykładowoym pojeździe (EZT) magistralę CAN, nawet 5-6 niezależnych linii, żeby te dane przesłać, ale wciąż hamowanie nagłe to otwarcie dziury pod grzybem lub zadajnikiem hamulca oraz równolegle poprowadzony przewód wzdłuż całego pojazdu (tzw. "pętla bezpieczeństwa"), który w tradycyjny sposób odcina zasilanie zaworów bezpieczeństwa. No i na tyle, na ile liznąłem TMCSów (systemów sterowania pojazdami), to tam komunikacja jest raczej dosyć surowa z odczytywaniem bitów i bajtów po adresach/pozycjach w ramce. MQTT wraz z bibliotekami pozwoli to opakować w trochę bardziej przyjazną formę odczytu.

3 minuty temu, 0x8000ffff napisał(a):

Mam jeden pulpit i jedna lokomotywę, pulpit lokalny, podłączony do portu komunikacyjnego. Mnie interesuje takie rozwiązanie, a nie ciągnięcie danych z internetu o lokomotywie, która mam lokalnie. Do tego nie jest mi potrzebny żaden pośrednik  (chyba że sprzętowy), ale nie kolejny serwer czy coś w tym rodzaju... Chyba jestem idiotą, bo ni w ząb tego nie rozumiem, zatem kończę wtrącanie się w tematykę, która mnie przerasta.

Na pewno nie będzie to ciągnięcie danych z internetu - dane będą przetwarzane i wystawiane lokalnie, szczegółów podłączenia nie znam, ale na pewno będą podane.

[0x8000ffff]

Ja ze swej strony dziękuję za odpowiedź, nie jestem znawcą tematu, więc nie muszę również wiedzieć, dlaczego takie a nie inne rozwiązanie zostało wybrane, prawdopodobnie że względu na optymalizację, prostotę, czy też wspomniane upakowanie danych. Bez szczegółów technicznych, ale też i bez zbędnej filozofii. Ważne aby było łatwe w implementacji i zrozumiałe dla twórców pulpitów. Na podstawie podanego przykładu zastosowania w IoT wyciągnąłem wniosek, że to będzie pobieranie danych z Internetu.

[Mywasher]

Godzinę temu, Królik Uszasty napisał(a):

Nie uważasz, że jednak Twoje wypowiedzi trochę zbyt emocjonalnie podchodzą do tematu, a niektóre porównania wręcz niesmaczne?

Co jest niesmaczne? Wskaż mi to konkretnie palcem. Bo zaczyna robić się nieśmiesznie. Bardzo nieśmiesznie. 

 

 

Godzinę temu, Królik Uszasty napisał(a):

Ja wiem, że nawet wyolbrzymione pół sekundy opóźnienia przy włączaniu hamowania przy prędkości 200 km/h to prawie 30 metrów różnicy w miejscu zatrzymania, ale bądźmy szczerzy - jeśli komuś naprawdę takie coś uniemożliwiałoby za każdym razem zatrzymanie się w miejscu, to jednak chyba trzeba zmienić technikę jazdy

Kto nie testował obciążeniowo MQTT na różnych platformach ten nie wie co to życie. Tak na poważnie nawet Facebook ma systematycznie kłopoty ze swoim brokerem, ale to pewnie przypadek bo mają za mało zasobów.

 

 

Godzinę temu, Królik Uszasty napisał(a):

MQTT wraz z bibliotekami pozwoli to opakować w trochę bardziej przyjazną formę odczytu.

Z całym nadmiarowym narzutem oraz zupełnie niepotrzebnym ograniczaniem przepływu danych. Z poziomu sterowania enkoderem, ile komunikatów chcesz wysłać do brokera o zmianie zadajnika z pozycji +100 do -100 aby utrzymać odczucie liniowości z tak samo liniowym feedbackiem? Bo rozumiem, że skoro ma stać MQTT to wypchniecie do niego wszystkie parametry, które są wizualizowane w kabinach, i pozwolicie pchać w broker co najmniej 8 bitowe wartości analogowe z urządzeń sterowania.

 

Godzinę temu, Królik Uszasty napisał(a):

magistralę CAN

CAN z definicji ma swoje ograniczenia już na warstwie fizycznej, które obijają się na jego "przepustowości" więc nie wiem jak się to ma do całkiem ciekawego sterowania przez pośrednika, a sterowaniem I/O do samego silnika. Że niby magistrala rozgłoszeniowa? 

 

Godzinę temu, Królik Uszasty napisał(a):

Myślę, że prawdziwe pojazdy w niektórych sytuacjach serwują większe opóźnienia (typu zawieszający się na kilka sekund monitor diagnostyczny przy włączaniu hamowania nagłego, bo musi przetworzyć na raz kilkanaście komunikatów o błędach). Sam do MaSzyny skonfigurowałem swój pulpit do komunikacji co 100 ms i jeździło mi się dobrze.

MQTT nie działa deterministycznie. To jest jego uroda.