- Symulator MaSzyna -
Symulator EU07 (i nie tylko) => Bieżące Symulatorowe => Wątek zaczęty przez: El Mecánico w 14 Czerwca 2011, 16:09:07
-
Zadam pytanie pomocnicze. Czy AI prowadzący skład robi hamowanie kontrolne? Mam bowiem pomysł. W czasie kontrolnego AI powinno zapamiętać kilka współczynników, głównie opóźnienie ruchu na pierwszej, drugiej, i ew. trzeciej pozycji hamowania służbowego oraz czas pełnego luzowania z tej pozycji. Co potem z tym robi? AI wiedząc jak daleko ma do semafora (widzi w ogóle tarcze?) czy do ograniczenia, policzy jakie hamowanie wdrożyć i jak długo hamować, żeby się zatrzymać pięknie przed S1 czy wjechać na odcinek z ograniczeniem prędkości.
Ponieważ dygresja dość mocno się rozbudowała, za sugestią @youBy'a wydzielam.
Quark-t
-
Nie robi. Też uważam, że powinno się zapiąć sieci neuronowe, które by się douczały po wykonaniu każdego kolejnego hamowania. Czy widzi tarcze to nie wiem, nie dotarłem jeszcze do tego. Pisali, że tarczy widzieć nie musi, gdyż może od razu widzieć semafor. Problem jest jeszcze w tym, że istnieje 5 rodzajów maksymalnej prędkości i trzeba z nich wybrać najmniejszą na dany moment.
-
Nie robi. Oczywiście można to wdrożyć (próbne implementacje zostały wykonane już jakiś czas temu), tylko problemem jest właściwe przekazywanie sygnałów, szczególnie przy ich następstwie. Twoja koncepcja pomija jedno ważne ograniczenie – czas. Zrobienie hamowania kontrolnego to około minuty. Fizycznie nie da rady zrobić w tym czasie hamowania pierwszym, drugim i potem jeszcze trzecim stopniem. Pierwszy stopień (lub półtora) powinien w zupełności wystarczyć do tego. Trzeba tylko pamiętać, że żeliwo gorzej hamuje przy dużych prędkościach i nie można opóźnień hamowania tak o sobie przenieść ;)
PS W temacie z taśmami jest nawet jedna z przejazdu AI po drobnych usprawnieniach.
@Ra: moim zdaniem problem nie leży w wyborze tylko w odpowiednim przekazaniu tych prędkości.
-
Ciekawe jakby sobie z hamowaniem PI lub B-BAC poradził...
-
Pewnie poradziłby sobie tak dobrze, jak umiejętnie dobrane byłyby nastawy. Tylko jak na pociągu wywołać skok jednostkowy? ;)
-
Zmieniając prędkość zadaną. Tak na prawdę to nas interesuje. Ja bym chciał poddać pod rozwagę uproszczenie AI. Prawda jest taka, że poza jazdą w kabinie z włączonym autopilotem, nie bardzo nas obchodzi ciśnienie w cylindrach, pozycja kranu i nastawnika. AI ma jechać z prędkością rozkładową i stosować się do sygnałów. Czyli "sterowanie AI" sprowadzałoby się do ustalania wartości siły (lun ominąć jeszcze jeden wzór i nadawać bezpośrednio przyspieszenie) skierowanej w kierunku ruchu pociągu lub przeciwnie do niego. Czyli zrobić z AI coś a'la makiety kolejowej. Tylko jeżeli trzeba zrobić dobrze AI działające jako "instruktor", to nie ma po co dublować i robić uproszczonego.
-
A także poza jazdą jako kierownik pociągu, pasażer, lokomotywa popychająca, lokomotywa ściągana ze szlaku. Pozostaje tutaj jeszcze kwestia manewrów — zostawianie zahamowanego składu. Moim zdaniem, można zrobić dobrze jeżdżące AI w oparciu o pełną symulację fizyki. Nie ma wtedy problemów z przełączaniem się w sytuacji, gdy pojazd kierowany przez człowieka dojeżdża do składu sterowanego przez AI.
-
Jeśli AI może mieć dostęp do informacji o
1. Punkcie początku zmiany prędkości
2. Punkcie w którym prędkość docelowa ma zostać osiągnięta
to może sobie stworzyć uproszczoną funkcję prędkości od odległości pomiędzy punktami 1 i 2 na podstawie tego jako to wygląda kiedy hamuje człowiek. Parametry PID (jako błąd mamy odchyłkę od porządnej prędkości w danym momencie wyliczonej z pomocą naszej uproszczonej funkcji, a nie jako odchyłkę od końcowej wartości docelowej) nie powinny być bardzo trudne w dobraniu w takim układzie. Co więcej parametry PID dla różnej długości pociągów byłyby chyba dosyć zbliżone, wiec odpadłby problem konieczności nauki AI jak zachowuje się konkretny skład. Wadą tego rozwiązania byłoby to, że AI pewnie by kręciła kranem jak szalona, więc jako nauczyciel dla człowieka raczej by się nie nadawała.
-
Długość to jedno, a nastawy hamulców to drugie — nawet krótkie składy prowadzone na hamulcu wolno działającym mają duży czas reakcji na zmiany. Doliczmy do tego opowiednie załadowanie i już się robi problem, gdyż trzeba mocno hamować, co powoduje, że skład jeszcze dłużej reaguje na luzowanie.
-
Po pierwsze, to może być gain scheduling, a po drugie nie samym PID automatyka stoi. Coś pewnie by się dobrało.
-
Jeżeli jest temat o autopilocie, to wadą jest dla mnie jak gram w nocy to nie widzę klawiatury. Jak chcę dać RP1 to zamiast SHIFT+A naciskam SHIFT+Q co włącza autopilota i nie ma możliwości wyłączenia go. Często tak się zdarza w środku służby gdy jadę na dużej scenerii np. L053.
-
Jeżeli jest temat o autopilocie, to wadą jest dla mnie jak gram w nocy to nie widzę klawiatury.
http://www.a4tech.pl/Item.aspx?ITEMNMBR=A4TKLA41045&GroupID=33&SubGroupID=57 ;)
-
Fajne. Szkoda, że nie ma maszynowego zielonego koloru :)
-
Jak tylko wrócę do domu, to postaram się pokazać moje rozwiązanie tej kwestii. Będzie to przedstawione na podstawie pewnych doświadczeń z czasów pracy nad AI współpracującym z SPKS.
Może by wydzielić tę część dyskusji do osobnego wątku, gdzie można by przedstawiać koncepcje?
-
Skoro już jest oddzielny temat o AI, to dlaczego po włączeniu autopilota nie da się go wyłączyć? Powodowałoby to jakieś anomalia w sterowaniu pozostałymi pojazdami?
-
No tak jakoś wyszło :) W debugmode można go wyłączyć i nie ma z tym problemu, więc nie powinno być komplikacji.
EDIT: No to tak, moje rozwiązanie (niedokończone) wygląda w następujący sposób: po wyjeździe ze stacji i osiągnięciu 60 km/h robimy hamowanie kontrolne pierwszym stopniem hamowania. Przy prędkości 45 km/h odczytujemy i zapamiętujemy opóźnienie hamowania i wykonujemy luzowanie. Zbliżając się do ograniczenia prędkości (zatrzymania), AI liczy wymagane opóźnienie (powiększone o jakiś procent) i gdy tylko wartość tego opóźnienia przekroczy zapamiętaną wartość, następuje hamowanie pierwszym stopniem. To rozwiązanie ogranicza ruszanie kranem, przez co hamowanie odbywa się w miarę stabilnie. W przypadku zbliżania się do ograniczenia przy różnicy prędkości 10 km/h następuje luzowanie składu. Co to daje? AI wjeżdża w ograniczenia już wyluzowane. Unika się też sytuacji znanej zwłaszcza z dawnych exeków, kiedy AI wszczynało hamowanie, gdy tylko prędkość została przekroczona. Skutkowało to często zatrzymaniami w polu albo znacznym ograniczeniem prędkości. Wadą takiego rozwiązania jest to, że AI sobie pozwala na przekraczanie i w głowice wjeżdża pociągami pasażerskimi pięćdziesiątką, cały czas jadąc z wybiegu. W przypadku zatrzymania margines ten został ustalony na 30 km/h i 100 metrów — jest to dystans wystarczający dla większości składów do zatrzymania się z tej prędkości. Pociąg hamuje do 30 i z tą prędkością zbliża się do semafora. Gdy znajduje się on 100 metrów od niego, następuje wdrożenie hamowania z większą siłą (obecnie to jest 2–3 pozycja kranu, czyli upuszczenie 0,7 do 1,0 bar w PG).
Możliwe ulepszenia systemu: odczyt opóźnień w kilku puntach (sprawdzenie charakterystyki hamulca: żeliwo/kompozyt), pomiar czasu luzowania w celu dobrania marginesu, ustalenie odległości hamowania przed sygnałem „Stój” w zależności od opóźnienia. Teoretycznie można by do tego zaprząc jeszcze masę hamującą składu, ale to nie jest dobry pomysł ;)
-
No dobrze, ale co w przypadku, gdy np. szlakowa/rozkładowa jest mniejsza? Jasne, można obniżyć próg prędkości dla HK. Pomysł sensowny, analogiczny do sieci neuronowych @Ra. Pytanie - gdyby nie robić HK przez AI już w trakcie działania scenariusza, ale robić je symulacyjnie np. w trakcie ładowania? Dla każdego składu w scenerii, który ma obsadę i np. zdefiniowany rozkład. Przekazać potem tablicę parametrów do symulatora i HK nie jest potrzebne. Był kiedyś program do analizowania dynamiki, może coś w ten deseń? Symulator ładuje scenerię i modele, a z przełączeniem na "warstwę użytkową" czeka do otrzymania danych.
Wada: co z AI, które będzie wreszcie w stanie zmienić skład w trakcie symulacji. Odpalenie programu w tle?
-
Zgodnie z przepisami HK trzeba zrobić ;] Równie dobrze można przeliczyć siłę hamowania od prędkości, a nawet zrobić tabelę średnich opóźnień między poszczególnymi prędkościami przy różnych stopniach dla każdego pojazdu i potem to przeliczyć dla składu. Później trzeba tylko z tabelki odczytać odpowiednią komórkę i już.
-
Ale HK można zrobić dla idei HK a nie testów :) Pytanie do Ciebie jako do hamulcowego :) - czy nie da się tego po prostu policzyć z tych wszystkich wzorków, % masy hamującej etc. Nie mówię tutaj o wartościach super dokładnych (bo pewnie zaraz napiszesz, że co ze zużyciami klocków etc. :p). Po prostu obliczyć wartość idealną/książkową dodać do tego jakiś margines bezpieczeństwa i tak jak napisałeś, przy ~+10 km/h zacząć luzować skład. Zatem nawet jak zahamuje za szybko, to nie powinno stanąć.
-
No część mogę przeliczyć poza symulatorem, a część przy ładowaniu pojazdu. Tylko pytanie, co nas interesuje — średnia siła hamowania na przedziale prędkości, średnie opóźnienie, średni stopień hamowania dla danego opóźnienia, najwyższa prędkość dla danego stopnia (opóźnienia) i prędkości końcowej? Wiesz, % masy hamującej mówi tylko o hamowaniu od prędkości maksymalnej do zera, więc tutaj raczej bym tutaj musiał skorzystać z nacisku klocków (częściowego) i współczynnika tarcia.
-
Z punktu widzenia ruchu - IMHO średnie opóźnienie. Z tego policzysz drogę wymaganą do zatrzymania/zredukowania prędkości i tak jak pisałeś, będzie wiadomo kiedy wdrożyć hamowanie.
-
Interesuje jak (dalej) hamować, aby mając obecną prędkość v0 uzyskać zadaną z góry prędkość v1 po przebyciu drogi s, a jednocześnie nie przekroczyć opóźnienia adop, no chyba że drogi mało a stanąć trzeba.
-
Czy to przyspieszenie adop jest takie ważne? Ja bym powiedział, że ważniejsze jest nieprzekroczenie prędkości v1 na końcu odcinka. O jako takim przyspieszeniu dopuszczalnym ciężko mówić, ja bym powiedział raczej o wartości preferowanej. Próba z hamowaniem kontrolnym miała u mnie na celu ustalenie sensownego progu początku hamowania, żeby zrobić to raz a dobrze. Należy ograniczyć używanie kranu do minimum, bo częste zmiany nie wpływają dobrze na stabilność jazdy.
-
A co ile mechanik kręci kranem? Może ograniczyć kręcenie kranem poprzez ustawienie minimalnej luki czasowej pomiędzy zmianami. Wtedy trzeba policzyć o ile spadnie prędkość przy danym ustawieniu spadku ciśnienia w PG. Ale tylko raz na lukę czasową. Po niej jeszcze raz wszystko obliczamy z funkcją celu skierowaną na osiągnięcie wymaganego Vk przy dostępnej drodze s.
-
No myślę, że nie częściej niż kilka sekund. AI powinny wystarczyć 3, no góra 4 ruchy kranu na cały proces:
1) zahamowanie wstępne odpowiednim stopniem (wymagane przyspieszenie przekracza próg),
2) skorygowanie ustawienia (delikatne zmniejszenie/zwiększenie stopnia hamowania),
3) wyluzowanie przy odpowiedniej prędkości.
Jak widzisz te luki czasowe? Czy to oznacza, że AI sprawdza co pewien czas ustawienia i je koryguje, czy też przez pewien czas po dokonaniu zmiany nie może dokonywać następnych?
-
To zależy od złożoności obliczeń jakich trzeba dokonywać. W przypadkach:
1. AI oblicza sobie wszystkie dane raz na zadaną lukę czasową i nie oblicza nic do minięcia czasu. Przy złożonych obliczeniach ograniczamy sobie obciążenie, szczególnie przy dużej ilości pociągów obsługiwanych.
2. Jeśli AI oblicza sobie wszystkie dane co cykl, a tylko może zmieniać co ileś cykli to obliczenia do wykonania nie mogą być zbyt obciążające. W tym przypadku jednak AI ma bardziej aktualne dane co do sposobu w jaki hamuje. Aby ograniczyć machanie kranem można wprowadzić st. odchylenie od miejsca w które ma trafić (np +/- 50 m), albo % zmianę od wartości idealnej, która powoduje dopiero reakcję.
W zasadzie ograniczenia w obu przypadkach mogą być podobne.
-
Obecnie wymagane przyspieszenie jest liczone ze wzoru (vz2-va2)/(2 ∙ k ∙ s), gdzie: vz – prędkość zadana w km/h, va – prędkość aktualna w km/h, s – pozostała odległość w m, k – stała przeliczeniowa jednostek równa 12,96 km2∙s2/(m2∙h2). Do tego dochodzi kilka warunków na różnice prędkości bądź przyspieszeń. No i blokada na kilka sekund po zmianie stopnia hamowania, bo na towarowym trzeba czekać zawsze. Drobnym problemem może się okazać to, że odległość, jaką widzi AI, nie uaktualnia się ona ciągle tylko skokowo. Poza tą niedogodnością system zdaje się działać dobrze :)
-
Tylko nie masz w tym układzie nawet przybliżonej predykcji zachowania składu. Tzn. nie obliczasz o ile spadnie prędkość w ciągu najbliższej luki czasowej. A to jest kluczowa informacja, gdyż jak inaczej możesz założyć, którym stopniem hamowania musisz zadziałać, żeby uzyskać efekt o który chodzi.
No chyba, że czegoś nie zrozumiałem ze wzorów.
-
Nie obliczam, bo tego nie potrzebuję. W fazie wdrażania hamowania i tak jest czas na poprawki. W fazie środka hamowania uzyskane opóźnienie powinno być na zapas zwiększone ponad obliczone. W fazie końcowej nie ma to znaczenia, bo zostaje jeszcze pewien margines na wyluzowanie składu. Przewidywane zachowanie składu jest takie: nie ruszając kranu, przez najbliższą lukę będzie z opóźnieniem takim, jakie jest teraz. Może uda mi się to pokazać na obrazku jakoś ładnie.
-
No to ja nie rozumiem po co Ci sieć neuronowa w takim razie jak nie do predykcji zachowania składu właśnie.
-
Ja o sieci neuronowej nie pisałem :D
Ogólnie można wydzielić dwa podejścia do tego tematu — danej drogi i danego opóźnienia. W pierwszym wypadku wykorzystujemy całą drogę na hamowanie i dopasowujemy stopień hamowania. W drugim zaś stosujemy jeden stopień hamowania i czekamy na odpowiedni moment do zahamowania. Problemem są wtedy hamowania, które trzeba wykonać z większą siłą, ale to można obejść odpowiednim warunkiem — jeśli nagle pojawia się duże wymagane opóźnienie, należy wdrożyć hamowanie pełne bądź 2/3.
-
Ja myślałem nad tym, czy by nie stworzyć profili hamowania odpowiadających mniej więcej zachowaniom mechaników. Czyli:
1. Łajza - wybiera drogę hamowania jako podstawę, nigdzie się nie spieszy, powoli hamuje na długim odcinku
2. Normalny - miks drogi i opóźnienia
3. Wariat - podstawą opóźnienie
W każdym przypadku musisz jednak znać maksymalne możliwe do uzyskania opóźnienie, oraz wykres dojścia do niego. Tylko w ten sposób możesz policzyć jaką drogę przejedziesz na danym stopniu hamowania. Szczególnie ważne to jest w przypadku podejścia o opóźnieniu jako podstawie.
-
1. Łajza — hamuje zawsze z najniższym opóźnieniem, jakie może (amin).
2. Normalny — hamuje ze znanym sobie opóźnieniem ulubionego stopnia hamowania (aHK). Zwiększa je tylko wtedy, gdy droga jest za krótka.
3. Wariat — hamuje zawsze używając najwyższego możliwego opóźnienia (amax), chyba że to nie ma sensu — np. obniżenie prędkości o 10–20 km/h.
W załącznikach wykresy obrazujące hamowanie. Na osi pionowej jest prędkość, na osi poiomej jest… powiedzmy, że czas. Powinna być prędkość, ale nie chciało mi się parabolek robić ;) Pierwszy przedstawia hamowanie przez całą dostępną drogę – wymaga ono kilku hamowań i luzowań. Drugi przedstawia hamowanie wg mojej koncepcji. Opóźnienie aHK jest odpowiednio przeliczonym opóźnieniem z hamowania kontrolnego. Próg jest tak dobrany, że skład zawsze hamuje mocniej i prędkość mieści się pod krzywą. Właściwie wymaga to tylko jednego zahamowania. Nie potrzeba przewidywania zachowań składu, wystarczy tylko z grubsza ustalić próg luzowania VL. Ktoś może spytać: a co się stanie, jeśli opóźnienie amin, wynikające z drogi hamowania, jest większe niż znane aHK? Nic, przy niewielkiej różnicy hamowanie odbywa się normalnie. W międzyczasie wymagane opóźnienie z danego punktu rośnie i AI widzi, że coś jest nie tak. Wtedy następuje zwiększenie stopnia hamowania i prędkość się bezpiecznie zmniejsza. Jeśli amin w takiej sytuacji staje się niebezpiecznie większe (sięga powiedzmy 2∙aHK), wtedy wdrażane jest hamowanie pełne albo nagłe. Znajomość najwyższego opóźnienia niewiele da, bo i tak albo się wtedy zmieścimy, albo sygnał został zauważony za późno i nic się nie dało z tym zrobić.
-
Nie wiem, czy to gdzieś pisałem, ale tu będzie dobre miejsce. Mamy następujące maksymalne prędkości (wybieramy najmniejszą):
- konstrukcyjna dla składu
- rozkładowa
- drogowa (zwana szlakową)
- ustawiana sygnalizatorem (semaforem)
- ograniczenia odcinkowe (mogą się nakładać)
- ograniczenia ze względu na przeszkody na torze
Oprócz prędkości konstrukcyjnej wszystkie pozostałe są zależne od położenia składu w scenerii. W związku z tym na poziomie pociągu proponuję utworzyć tabelkę na te prędkości oraz modyfikację eventów ustawiających prędkość tak, aby było precyzyjnie określone, którą prędkość zmieniamy. Pewnym problemem jest ustalenie zakresu obowiązywania danej prędkości, bo wymagało by to określenia pozycji pojazdu w formie liniowej (w tym znajomości kilometrażu). Tabelka musiałaby być tworzona dynamicznie (albo mieć pozycje rezerwowe), aby można było dodawać do niej pozycje z zakresem obowiązywania.
-
Konstrukcyjna — jedna, stała. Rozkładowa — dwie: obecna i następna. Drogowa — dwie: obecna i następna. Semaforowa — dwie: obecna i następna. Ograniczona stale — dwie: obecna i następna. Ograniczona czasowo — dwie: obecna i następna. Przeszkodowa: jedna. Teoretycznie daje nam to 12 możliwości. Można jednak zauważyć pewną prawidłowość: prędkość rozkładowa jest niewyższa niż drogowa, czyli drogowa nam ucieka. Ograniczenia stałe/czasowe nie mogą się nakładać ramach swojej kategorii, co więcej, powinno unikać się niejednoznaczności (czyli nie stawiać serii krótkich ograniczeń jedno za drugim).
Moim zdaniem wystarczy zmodyfikowanie zdarzeń na tyle, żeby zawierały w sobie typ ograniczenia i modyfikować odpowiednią pozycję w tabeli. Skanowanie może odbywać się na odległość równą podwojonej drodze hamowania (albo powiększonej o połowę potrzebnej do zatrzymania pojazdu z opóźnieniem hamowania kontrolnego).
Jeszcze słówko odnośnie semaforów. Podawanie prędkości przy następnym nie ma sensu bez podania dokładnej informacji o odległości do niego. Lepszym rozwiązaniem jest umożliwienie bezpośreniej obserwacji kolejnych semaforów. Wtedy nie trzeba jechać asekuracyjnie no i można zareagować od razu na zmiany jego stanu. Dlatego też tarcze ostrzegawcze powinny zostać ograniczone do roli graficznego przedstawienia sygnału dla ludzi.
-
youBy, ale czy aby na pewno trzeba skanować szlak do przodu? Przecież przed wyjazdem pociągu na szlak ze stacji początkowej maszynista dostaje do ręki rozkład jazdy, wykaz ostrzeżeń stałych, wykaz ograniczeń czasowych. Na wszystkich jest kilometraż, wystarczy więc pilnować drogi i stosować się do listy ostrzeżeń z wykazów i rozkładu jazdy. Jedyne co nie jest ujęte w papierach to rzeczy nagłe i nieznane, typu wiatrołom leży na szlaku w poprzek;]
-
Skanować i tak trzeba, żeby odczytać semafory. W sumie można by w rozkładzie jazdy rozpisać całą drogę łącznie z nazwami semaforów, które mają być odczytane. Problem jest jednak, jeśli z jakiego losowego powodu skład pojedzie innym torem.
-
Ale skanować można tylko raz, aż do następnego semafora, i zapisać sobie wszystkie ograniczenia które wystąpią po drodze. Taka lista zajmie trochę pamięci (no ale nie przesadzajmy) a spadnie potrzeba skanowania tego ileś razy. Można trzymać namiar do tamtego semafora i odczytywać sobie jego sygnał (ograniczenie prędkości) dopiero jeśli zbliżymy się na odległość mniejszą niż droga hamowania.
-
A pamiętacie że w drodze hamowania semafora stoi do niego tarcza ostrzegawcza? Teoretycznie rozpoczęcie hamowania z odpowiednią siłą (sprawdzoną wcześniej na kontrolnym:P) w miejscu ustawienia tarczy powinno doprowadzić do zatrzymania składu tuż (kilka metrów) przed semaforem. Jedyne co musi być zrobione to przekazanie do AI stanu tarczy przez event (dla pewności warto go wstawić jakieś 10 metrów przed samą tarczą).
Pewnie padnie pytanie co w przypadki jak czoło przeleci tarczę Os1 a w międzyczasie na semafor wskoczy droga wolna? Rozwiązań mnogo bo i sytuacja każda inna, więc krótka analiza zachowań mechanika. Jak jest prosta i dobra widoczność na semafor to jasna sprawa. Gorzej jak mgła że na metr przed czoło nie widać (miałem okazję w takiej jechać), bo trzeba pod sam semafor podjechać. Jak jest semafor za łukiem to są powtarzacze, czasami gęsto i często, vide wjazd do Oświęcimia od Bierunia, tutaj jeszcze pod wiaduktem. No więc teraz jak to przenieść do symka. Powtarzacz - proste, event przekazujący wskazanie do AI. Zastanawiam się jak by można rozwiązać sytuację długa prosta bez powtarzaczy. Może zmienić program tak, aby event przekazujący wskazanie zadziałał dynamicznie w zależności od widoczności? Znaczy nie był przypisany na sztywno do jednego punktu, tylko do całego odcinka między tarczą a semaforem i aktywowany by był ustawieniem semafora i widocznością, jaka akurat jest (widoczność trzeba by wykalkulować z atmo(?)).
-
Można, ale… od semafora będzie prościej. Nie potrzeba tyle kombinowiania, dorabiania funkcji i komplikowania (chyba jednak zbędnego obecnie) całej sytuacji. AI trzeba trzymać na możliwie prostym poziomie, żeby zachowywało się w sposób przewidywalny.