Pokaż wiadomości

Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.


Wiadomości - jumo81e

Strony: [1]
1
[...]
Na razie udało mi się zrobić w kodzie obiekt sortujący nazwy torów (w formie drzewa na statycznym obszarze pamięci). Sortuje dobrze. Pozostaje jeszcze do zrobienia optymalizacja tego drzewa tak, aby było możliwie symetryczne, wtedy wyszukiwanie będzie najszybsze.

A może coś prostszego: posortowana tablica z nazwami, w końcu po wczytaniu scenerii nazwy torów już się nie zmieniają - więc wystarczy to zrobić raz. Binarne szukanie na posortowanej tablicy to O(log2(N)) - czyli identycznie jak dla zrównoważonego drzewa binarnego.

Ewentualnie coś jeszcze bardziej odjechanego - w Pythonie jest typ 'dict' (słownik, czyli tablica asocjacyjna) - tam wyszukiwanie jest O(1).

2
"Virtual Dispatcher"

A można więcej szczegółów - czy taki pomysł jest zrealizowany, w realizacji, w planach, nie planowany?


Są dwa osobne zagadnienia: ustalenie trasy oraz bieżące ustawianie przebiegów. A póki co to nikomu się nie chce używać rozkładów, bo trzeba by przypisywać W4 do torów i ustalić czasy przejazdów... Ale zawsze możesz też utknąć w SPT.

Tak, oczywiście. Trzeba rozpocząć od rzeczy najniższego rzędu aby potem móc na ich podstawie budować coś większego. Stąd też wstępna wizja kroków, od których należy zacząć.

Jak rozumiem W4 służy głównie jako informacja dla AI od prowadzenia pociągu.


Pomysł jest bardzo ciekawy, tylko czy każdy zwykły user nie wnikając w strukturę danej scenerii - będzie mógł w sposób taki jak obecnie prowadzić i cieszyć się symulatorem? To pytanie skierowane jest do autora wątku.

Dla zwykłego usera nic się nie powinno zmienić - dalej powinien jeździć wedle planu ustalonego przez autora scenariusza, dalej ruszać po podaniu zezwolenia. Oczywiście symulacja powinna być bardziej realna - żadnych atakujących składów, sygnalizacja działająca nawet w przypadku większego zagęszczenia ruchu. Jak każdy pomysł dotyczący "wnętrzności" największy zysk widzę tutaj dla tworzących scenariusze. Ludzie robiący przy tym projekcie są różni, każdy ma swoje zainteresowania i rzeczy, które mu najlepiej wychodzą. Nie sądzę, że wszyscy się interesują urządzeniami SRK. Na szczęście nie muszą - wydaje mi się, że sytuacje ruchowe można zautomatyzować i nie trzeba będzie już ręcznie wpisywać wszystkich zależności dla każdego obiektu osobno. Należy pozwolić robić komputerom to, do czego zostały stworzone - efektywnie wykonywać powtarzalne, automatyczne operacje. A dla twórców scenerii opracować proste informacje, aby mogli sprawnie wykorzystywać dobrodziejstwa automatyki.

3
Witam wszystkich.

Zdanie wstępu - w tematach kolejowych szczególnie interesuje mnie automatyka sterowania i zabezpieczania ruchu (jako hobby).

Jeżdżąc na scenariuszu "bałtyk_zima" w sm42 kilka razy zostałem zaatakowany przez inne składy wjeżdżające na mój tor. Prawdopodobnie z powodu mojego ociągania się zostały niepoprawnie skierowane, bo zakładam że u autora działa właściwie. Obejrzenie źródeł scenariusza wskazuje na potencjalnego źródło dziwnego zachowania - eventy używane do indywidualnego sterowania wszystkimi elementami infrastruktury kolejowej, bez żadnego globalnego nadzorcy i koordynatora.

W rzeczywistości takie zdarzenia nie mogą mieć miejsca. Większość sytuacji ruchowych opiera się na określeniu skąd i dokąd dana lokomotywa/skład ma się przemieścić.

Stąd też pomysł dodania modułów realizujących logicznie bardziej zaawansowane funkcje.


"Układacz przebiegów" - zajmujący się automatycznym wytyczaniem trasy przebiegu z zadanego miejsca początkowego (nazwy toru, nazwy semafora spod którego startuje skład) do zadanego miejsca docelowego (jw.) opcjonalnie przez określone miejsce(a) pośrednie - jeśli zachodzi potrzeba wybrania nieoczywistego przebiegu wariantowego.

W procesie tym następuje:
- odnalezienie drogi w grafie, łączącej punkt początkowy i końcowy
- sprawdzenie że cała droga jest niezajęta innym przebiegiem oraz wszystkie jej elementy nie wchodzą w sposób kolizyjny z np. ochroną boczną innego przebiegu
- dla przebiegów pociągowych, sprawdzenie czy żaden odcinek nie jest już zajęty taborem
- przestawienie wymaganych rozjazdów i wykolejnic (wszystkie na raz lub jedna po drugiej - bardziej realistycznie, aby nie robić przeciążeń włączeniem wszystkich napędów na raz),
- automatyczne wyszukanie ochrony bocznej dla rozjazdów (inny rozjazd, semafor, wykolejnica, ewentualnie pewna odległość od innych obiektów np. 200m),
- ustalenie przebiegu - "zawłaszczenie" wszystkich elementów dla danego przebiegu
- zamknięcie rogatek przecinających przebieg
- wyświetlenie odpowiednich wskazań na semaforach (uwzględnienie ograniczeń prędkości po drodze np. 40km/h dla jazdy w bok, informacji o wskazaniu następnego semafora oraz miłe dla oka drobiazgi typu oświetlenie kształtowej tarczy ostrzegawczej stojącej tuż przed kształtowym semaforem zapala się tylko wtedy gdy semafor dopuszcza przejazd)

Po utwierdzeniu drogi następuje przejazd składu. W trakcie przejazdu składu następuje sukcesywne zwalnianie "zawłaszczonych" elementów, które powracają do położenia zasadniczego. Można w prosty sposób uwzględnić drobne niuanse typu: dla przebiegów pociągowych powrót do S1 następuje (upraszczając) po minięciu lokomotywą semafora, a dla manewrów dopiero po opuszczeniu całego składu (aby maszynista realizujący popych miał cały czas Ms2). Dla kształtowych można upraszczająco założyć, że wszystkie mają sprzęgła sygnałowe i dzięki temu mogą reagować podobnie do świetlnych. Oczywiście dla przypadku gdy pojazd nie dojedzie do końca zarezerwowanego przebiegu (np. nie ma potrzeby cofać się aż tak daleko) - następuje zwolnienie niezrealizowanej części przebiegu.

Dzięki takiemu rozwiązaniu można by wprowadzić bardziej realistyczny, a przede wszystkim zdecydowanie prostszy dla tworzących scenariusze, sposób prowadzenia ruchu - zamiast przestawiać w eventach ręcznie wszystkie rozjazdy i podawać sygnały, można zgłosić po prostu przebieg do realizacji. Nic nie stoi na przeszkodzie, żeby zakończenie procesu ustawiania przebiegu wyzwalało kolejne zdarzenia.

Zadania do realizacji na tym etapie: automatyczne określenie typu i "przynależności torowej" (którego toru i kierunku ruchu dotyczy wskazanie) semaforów i innych nietorowych obiektów, określenie sposobu reprezentacji obiektów w grafie (do poszukiwań przebiegów i ich rezerwacji), budowanie grafu opisującego zależności ruchowe na podstawie scenerii, testy poprawności reprezentacji, implementacja szukania drogi w grafie (przebieg i jego ochrona boczna) ze zwróceniem uwagi na różne nieoczywiste szczegóły (choćby wyjazd dwóch składów w przeciwne strony z jednego toru), implementacja zwalniania przebiegu. Do celów ładnej prezentacji oraz pomocy w zadaniach deweloperskich można pokusić się o syntezowanie widoku pulpitu zawiadowcy z obrazem sytuacji ruchowej na podstawie wygenerowanego grafu. Stąd już tylko krok do opcji przejęcia sterowania przez żywego operatora.

Część z tych zadań już widziałem na filmie zaimplementowaną w module AI (też musi wiedzieć, który semafor jest "jego" i z jaką prędkością może go minąć).


Po wspomnianym opanowaniu przebiegów w obrębie stacji, kolejnym krokiem automatyzacji prowadzenia ruchu jest obsługa komunikacji pomiędzy sąsiadującymi stacjami. W to wchodzi automatyczna i półautomatyczna blokada liniowa (oczywiście realizowana samoczynnie przez program - "scenerzysta" musi tylko postawić semafory na szlaku i ew. dla SBL określić że zamiast domyślnie trzystawnych są czterostawne), zagadnienia kierunku ruchu na danym torze, obsługa SSP.


Dysponując takim rozwiązaniem, można na jego podstawie zbudować moduł wyższego rzędu - "dyżurnego ruchu" pilnującego ruchu pociągów. I tu znowu jest szerokie pole do kreatywności: skład może mieć określony rozkład (konkretne godziny odjazdów), określony czas postoju, losowy (w podanym zakresie) czas postoju, oczekiwania na skomunikowanie z innym składem, itp. W sytuacji opóźnienia priorytetowanie kolejności wyjazdu na szlak w zależności od typu pociągu (np. najpierw pospieszne, potem osobowe a na końcu towarowe - wystarczy przeanalizować wagony). Dysponując wiedzą o krawędziach peronowych można realizować kierowanie pociągów pasażerskich na tory przy peronach, a towarowych w miarę możliwości poza perony. Można także zrealizować formowanie, przejazd i rozformowanie składu.


Oczywiście, żeby nie było że tylko po próżnicy piszę posty - jako, że ten temat mnie interesuje i trochę doskwiera obecna postać, chętnie dołożę swój wkład w rozwój symulatora i zrealizuję wspomniane pomysły lub pomogę w ich realizacji. C, python, perl, rozproszone systemy wersjonowania kodu, a także po części C++, nie są mi obce.

Strony: [1]