Autor Wątek:  Zachowanie AI - hamowanie  (Przeczytany 3525 razy)

0 użytkowników i 1 Gość przegląda ten wątek.

Offline Ra

  • Zasłużony dla Symulatora
  • Wiadomości: 6355
  • Ostatni gasi światło...
    • Zobacz profil
    • Instalator+Starter+Edytor
  • Otrzymane polubienia: 388
Zachowanie AI - hamowanie
« dnia: 25 Maja 2008, 22:03:01 »
Przejechałem właśnie Nowy Świat na SN61 razem z AI (EXE Dizelpack). Mam parę obserwacji.

1. Parametr velocity w torze działa tak, że AI hamuje nieco wcześniej, ale i tak nie daje rady wjechać z podaną prędkością na ten tor. Następnie ustawia sobie podaną prędkość jako obowiązującą do odwołania. Innymi słowy, od toru z velocity 50 AI pojedzie dalej 50km/h po torach bez velocity. Skądinąd STV pokazuje tory z velocity jako ograniczenie prędkości, tak jakby ograniczenie obowiązywało tylko na tym torze. Wg Scenery.doc: "Velocity (opcjonalny) - prędkość jakiej będzie się starał nie przekroczyć jadący przez ten tor obiekt dynamic jeśli jest sterowany przez AI". Nie ma mowy, że będzie tą prędkość utrzymywać dalej, po zjechaniu z tego toru. Czyli zgodnie z STV, a niezgodnie z EXE.

2. AI bardzo beztrosko używa hamulca. Hamując, w zasadzie co rusz zwiększa stopień hamowania (co ok. sekundę). Zupełnie "nie wie" o tym, że wystarczyło by ustawić którąś pozycję i poczekać na zadziałanie hamulca. Moim zdaniem hamuje tak, jakby jechało samochodem (o niewielkiej masie), czy też miało hamulce tarczowe - im bardziej wciśniemy hamulec, tym z większą siłą hamujemy. W pociągu jednak tak nie jest.

3. AI jest bardzo rygorystyczne. Jeśli jadąc 90km/h zobaczy tor z velocity 50, zacznie hamować, ale zbyt późno i zbyt słabo. Jeśli następnie wjedzie na ten tor z prędkością np. 53km/h, będzie nadal zwiększać siłę hamowania "bo przecież większa niż 50" - a już powinien odhamowywać. W efekcie zatrzyma się, bo gdy zwolni poniżej 50km/h, to ciśnienie będzie na tyle duże, że odhamowanie w tym momencie niewiele da. Żeby znów ruszyć, ustawi kran na odhamowanie, a nastawnik na maksimum, nie czekając z tym na spadek ciśnienia w cylindrach hamulcowych. Czyli "będzie się starał nie przekroczyć" oznacza tu, że jak przekroczy choćby o minimum, to zahamuje tak, że się zatrzyma.

4. Jeśli ktoś ustawi velocity 1, czy velocity 5, AI będzie wykonywać następującą procedurę: nastawnik na maksumum -> przekroczona prędkość -> hamulec na maksimum -> prędkość poniżej limitu -> odhamowanie -> zatrzymanie (bo hamulec działa z opóźnieniem) -> nastawnik na maksimum -> ruszenie po spadku ciśnienia w cylindrach hamulcowych -> przekroczona prędkość... W efekcie porusza się "żabimi skokami" i nie jest w stanie jechać z niewielką prędkością.

5. Moim zdaniem, zamiast kręcić regularnie kranem hamulca jak nastawnikiem w SN61, hamowanie powinno być zrobione inaczej. Powinien wyliczyć różnicę prędkości (między obecną a oczekiwaną) i w zależności od dostępnej drogi hamowania ustawić kran hamulca na parę sekund. Następnie np. co sekundę wyliczać uzyskane opóźnienie chwilowe (przyspieszenie ujemne) i wyliczać czas do uzyskania oczekiwanej prędkości. W zależności od tego czasu, albo zwiększyć siłę hamowania, albo ją zmniejszyć - ale po zmianie znów odczekać 5 sekund. No i więcej tolerancji. Jeśli aktualna prędkość jest większa od oczekiwanej o 10%, a już hamujemy, to nie ma potrzeby zaciskać bardziej szczęk i stanąć. Żeby zwolnić o 2% nie potrzeba od razu używać hamulca, który zadziała po 10 sekundach, wystarczy wyłączyć napęd i zdać się na opory ruchu. Zmiana położenia kranu hamulca powinna odbywać się w dłuższych odstępach czasu (5-10s), za to być bardziej przemyślana (wyliczana).

6. Wracając do velocity w torze, w obecnej sytuacji należałoby przed velocity 50 wstawić tor z velocity 75, żeby zdążył trochę zwolnić, a z kolei z drugiej strony wstawić tor z velocity 160, żeby nie jechał dalej ciągle 50km/h. Aby taki tor był przejezdny z sensem w obydwie strony, musiałoby być po kolei velocity 160, velocity 75, velocity 50, velocity 75, velocity 160. Być może musiałoby być więcej takich torów, z mniejszym skokiem prędkości. Trzeba by to sprawdzić doświadczalnie. To już się bez sensu robi, ale takie mamy AI.
« Ostatnia zmiana: 29 Maja 2008, 20:35:25 wysłana przez Ra »
¯\_( ͡° ͜ʖ ͡°)_/¯ Ra

Polecam: kręgarz Wojciech Walczak, projekt masarni

Offline Mariusz1970

  • Zasłużony dla Symulatora
  • Wiadomości: 3932
    • Zobacz profil
  • Otrzymane polubienia: 288
Odp: Zachowanie AI - hamowanie
« Odpowiedź #1 dnia: 26 Maja 2008, 01:02:28 »
Cytuj
1. Parametr velocity w torze działa tak
6. Wracając do velocity w torze...

Dokładnie.
Kiedyś próbowałem zrobić eventy do przystanku osobowego gdzieś na szlaku, gdzie AI pędziło ok. 100 km/h. Właśnie tak robiłem, iż zmuszony niejako byłem do skokowego zmniejszania prędkości. Natomiast co do ruszenia znowu z pełną parą, użyłem eventu, który wpisuje żądaną prędkość do AI (nie pamietam, get czy put). Założenia było takie, iż AI ma sobie stopiowo zwalniać (jak nie zwalniał stopniowo, to przejeżdżał tor, na którym były dalsze eventy sterujące, a uparłem się na event0), zatrzymać i ruszyć ponownie po żądanym czasie.
To robiłem na exe 664.


Offline youBy

  • Deweloper
  • Wiadomości: 6169
  • Co tam?
    • Zobacz profil
    • Automat Weryfikujący Regulację i Lambdę
  • Otrzymane polubienia: 889
Odp: Zachowanie AI - hamowanie
« Odpowiedź #2 dnia: 30 Maja 2008, 20:51:40 »
2 i 5:
Należałoby wykonać hamowanie kontrolne. Albo poprzez klasyczną procedurę: 60/30, 130/100, albo poprzez nowy sposób: ileś i ustabilizować siłę, albo poprzez zrobienie symulacji symulacji i zrobienie czegoś w rodzaju tabeli wyników. To pomoże w sprawie 3.

Poza 1 wiedziałem o tych problemach, jednakże nie mam jak się do nich zabrać. Koncepcja ogólna jest, ale jeszcze dojrzewa :)
Xoov
Powyższy post wyraża jedynie opinię autora w chwili publikacji. Autor zastrzega sobie prawo do zmiany poglądów bez podawania przyczyny, jak również informowania o tym.

Offline Ra

  • Zasłużony dla Symulatora
  • Wiadomości: 6355
  • Ostatni gasi światło...
    • Zobacz profil
    • Instalator+Starter+Edytor
  • Otrzymane polubienia: 388
Odp: Zachowanie AI - hamowanie
« Odpowiedź #3 dnia: 31 Maja 2008, 00:44:27 »
Może by jakąś prostą sieć neuronową zrobić, którą by się wstępnie nauczyło np. plikami .DAT z jazd odręcznych, a douczało potem zależnie od pociągu, w przypadku nietrafienia z odpowiednią prędkością w miejsce ograniczenia czy zatrzymania. Na wejściu sieci musiałyby być takie dane jak: prędkość obecna, długość odcinka, prędkość oczekiwana na końcu odcinka, obecne ciśnienie, masa pociągu, dopuszczalne opóźnienie (większe dla towarowych), kategoria hamowania (inna dla S1, inna dla ograniczenia prędkości), może coś jeszcze. Na wyjściu powinno ustawienie hamulca albo optymalne ciśnienie. Sieć powinna być optymalizowana pod kątem najkrótszego czasu przejazdu przy założeniu nieprzekroczenia dopuszczalnego opóźnienia.

Ale dla mnie sama idea przekazywania informacji z semafora do pociągu poprzez event wydaje się dziwna. Jeśli na skutek wywołania *_sem_info zostaje przekazana docelowa prędkość, to musi być jakieś miejsce, od którego ona obowiązuje. Jeśli semafor pokazuje S1, to wyzwolenie eventu musi dać odpowiednio dużo czasu na zatrzymanie. Zakładając, że pociąg może dojechać do końca toru z takim eventem (bo niby dokąd?), to ten tor musi być odpowiednio długi.

Moim zdaniem, dużo lepiej byłoby powiązać semafor z velocity toru, gdyż velocity wygląda tak, jakby było widoczne z daleka dla AI (ale i tak obecnie AI za późno lub za słabo reaguje).
¯\_( ͡° ͜ʖ ͡°)_/¯ Ra

Polecam: kręgarz Wojciech Walczak, projekt masarni