15 października odbyło się drugie spotkanie grupy Warsaw Self-Driving Cars. W ramach tego wydarzenia rozmawialiśmy o zawodach samochodów autonomicznych 1:10 oraz 1:1 na torze, a także o wykrywaniu i śledzeniu obiektów w celu zliczania przejeżdżających samochodów.

Udostępniamy prezentacje i nagranie z wydarzenia!

Self-Racing Cars, 2017-2018 – o zawodach samochodów autonomicznych na torze wyścigowym, Karol Majek

W ramach drugiego spotkania grupy Warsaw Self-Driving Cars zostały zaprezentowane trzy prezentacje. Pierwsza prezentacja dotyczyła samochodów autonomicznych w skali 1:1 podczas zawodów na torze wyścigowym. Karol Majek opowiedział o swoich doświadczeniach podczas dwóch edycji Self-Racing Cars, gdzie podczas pierwszej edycji był jednym z 18 osób wybranych poprzez Udacity spośród najlepszych studentów kursu Self-Driving Car Nanodegree. Mając 5 tygodni i tylko 2 dni samochodem przed zawodami wzięli udział w zawodach i udało im się pokonać wszystkie zakręty autonomicznie, natomiast nie w jednym okrążeniu. Podczas drugiej edycji zostało już tylko 4 osoby, bez wsparcia, bez samochodu i mając tylko 30 minut na integrację udało im się osiągnąć znacznie więcej.

Link do prezentacji

Transkrypcja

Witajcie na drugim Meetupie Warsaw Self-Driving Cars. Dzisiaj będą cztery prezentacje. Po dwóch prezentacjach planujemy krótki pokaz na torze. Tutaj mamy samochód, dwa zespoły mamy, samochody mamy ze trzy i dwa zespoły prosto z zawodów F1/10, które odbyły się w Turynie 1 października. Ale najpierw będzie moja prezentacja na temat zawodów Self-Racing Cars, dwóch edycji, z 2017 i 2018. W ramach tych zawodów mieliśmy samochód autonomiczny w skali 1:1. To była za pierwszym razem KIA Soul, natomiast więcej w prezentacji. Druga prezentacja będzie trochę skrócona, będziemy występować z Łukaszem i opowiadać o naszym rozwiązaniu, które przygotowaliśmy na zawody. Następnie będziemy mieli pokaz na torze. Trzecia prezentacja tuż po przerwie i tu będzie występował Michał Drzał, z tej prezentacji jestem bardzo zadowolony i bardzo mam duże oczekiwania, mam nadzieję, że będzie super. Następnie prezentacja Adama z Koła Naukowego Robotyków, który będzie przedstawiał system autonomicznej jazdy, gdzie będzie mapowanie i lokalizacja. Tego w naszym rozwiązaniu nie ma, więc tutaj jest znacząco lepiej. Więc zobaczymy. Okay. A na koniec pizza plus rozmowy przy torze, przy samochodzie, więc myślę, że będzie dość ciekawie. Ale jakoś sobie poradzimy, mam nadzieję.

A więc, pierwsza edycja zawodów odbyła się w 2017 roku, to był koniec, znaczy to był 1 i 2 kwietnia, więc Prima Aprilis i 2 kwietnia. Natomiast jeśli chodzi o nasze wystąpienie, drużyny stworzonej przez Udacity to my przyjechaliśmy dwa dni wcześniej.

O co chodziło w zawodach?

W zawodach brały udział drużyny, które wystawiały swoje samochody autonomiczne. Celem było przejechanie jak najszybciej całego okrążenia, więc mamy kilka przejazdów i jedziemy tak, aby jak najszybciej pokonać okrążenie. Tak wyglądała nasza trasa, to był zachodni tor. Tam było dziesięć zakrętów, niektóre były bardzo, bardzo trudne, bo tam praktycznie trzeba było zawrócić, trzeba było bardzo zwolnić, szczególnie tutaj. I tak wyglądał nasz plan, mieliśmy rozrysowane na zielono-niebiesko, tutaj nie wiem, czy widać, natomiast mieliśmy rozrysowane linie, zewnętrzną i wewnętrzną i mieliśmy także plan, jak jechać, żeby najszybciej, z największą prędkością pokonać trasę. To jest ta linia na czerwona, która tu ścina zakręty.

Także plany były naprawdę ambitne.

Natomiast jak wyglądała cała sytuacja? Udacity w lutym mniej więcej, jakieś 6 tygodni przed zawodami postanowiło, że zbuduje drużynę, zespół, który będzie się składał z 10 osób. Takie było założenie, natomiast wyszło 18 osób. I miały to być osoby z kursu Self-Driving Cars Nanodegree organizowanym przez Udacity i mieliśmy na przygotowanie się do zawodów pięć tygodni, nie było samochodu, więc nikt nie miał dostępu do samochodu, mieliśmy pięć tygodni, nie mieliśmy symulatora i potem miały być cztery dni z samochodem, dwa dni przed zawodami i dwa dni w trakcie zawodów. Więc dość trudna sprawa.

A zespół był z siedmiu stref czasowych.

Mieliśmy kolegę z Australii, trzy osoby z Europy i sporo ze Stanów. A więc od czego zaczęliśmy? Zaczęliśmy  przygotowania symulatora. Bazując na symulatorze z Udacity stworzyliśmy mapę trójwymiarową na podstawie widoku satelitarnego. Stąd mamy tak bardzo rozmazane obrazy. To jest ten nasz symulator, który stworzyliśmy w tydzień, półtora tygodnia tak, żeby móc pracować już na danych z symulacji i trenować nasze podejście. Założenie, jakie Udacity wymusiło na nas to było takie, że musimy korzystać tylko z kamery, więc nie bierzemy żadnych innych sensorów, bierzemy kamery i na podstawie kamery sterujemy samochodem z jeszcze jednym zastrzeżeniem, musimy wykorzystać deep learning. A tu z prawej strony to od razu przy okazji chciałbym pokazać dla kontrastu nasz progres przez rok.Tak wygląda symulator, który przygotowaliśmy już na zawody po roku, na 2018 rok.

Więc widać skok jakościowy.

Już nie mamy tak kiepskiego modelu, prawda? Mamy to już zrobione, i tak dalej. A więc trenując sieci neuronowe stwierdziliśmy, że nie możemy polegać na samych danych, które są z symulacji, będą nam potrzebne te dane z tego toru, żeby po prostu to rozwiązanie mogło pojechać później na torze. Bez tego nie byłoby to możliwe. A więc znaleźliśmy w Internecie filmy z toru, jeden był bardzo wdzięczny do odczytania wartości, bo to były wszystkie wypisane parametry na wyświetlaczu OSD i tutaj mamy odczytane wartości, które były odczytane z tych wskazań, nawet przyśpieszenia. I następnie z tego stworzyliśmy sobie jeden zbiór danych, drugi zbiór to to, co widzimy tutaj z prawej, to jest zbiór jaki dostaliśmy od PolySynca, bo to PolySync, firma, która tworzy kit, dzięki któremu możemy przerobić naszą KIA Soul na samochód autonomiczny, możemy się łatwo zintegrować. Wtedy jeszcze była ta starsza wersja, gdzie trzeba było dokupić hamulec od Priusa, natomiast obecnie sprzedają już gotowe rozwiązanie. Jak widzimy, mamy tutaj sporo problemów, mamy wycięty fragment, bo tam po prostu chyba zły obiektyw zastosowali.

Mamy odwrócony obraz, natomiast to już nie jest takie trudne.

A więc przygotowaliśmy sobie [dane] na podstawie tamtych filmów, poprzekształcaliśmy obrazy i przygotowaliśmy, tam zdaje się, były w zbiorze danych, nagrywane kąty, stąd mamy tutaj kąt. Więc to była przewaga względem tego zbioru, który znaleźliśmy w Internecie, który sami opracowaliśmy. Tu mamy oryginalne kąty, jakie były w tamtym samochodzie, jakie pozwalały na takie przejechanie trasy. I tutaj mamy z góry widok, jak kierowca jechał. Tam jest kilka przejazdów, dlatego jest ta zielona ścieżka grubsza. A więc jeśli chodzi o sieci neuronowe, jako że zespół miał 18 osób, tak z 7-8 pracowało właśnie nad rozwiązaniami związanymi z budową różnych modeli, z testowaniem. I zaczęliśmy od modelu End to End po lewej, to jest sieć, którą zaproponowała NVIDIA.

I oni faktycznie uzyskali dobre wyniki.

Nie mieliśmy problemu, żeby powtórzyć ten rezultat w symulatorze, natomiast w praktyce, na danej symulacji z poprzednich lat kompletnie się to nie udało. Ale o tym za chwilkę, jak przyjdziemy do toru. Testowaliśmy również podejście wykorzystujące rekurencyjne sieci neuronowe, natomiast nic z tego nie wychodziło.

Było wręcz gorzej.

I w pewnym momencie na torze testowaliśmy również uczenie ze wzmocnieniem, gdzie uczyliśmy nasz samochód reagując na jego błędy, co było negatywnym wzmocnieniem. Natomiast w praktyce szybko z tego zrezygnowaliśmy z uwagi na czas tej iteracji, żeby przejść, przetrenować podczas jazdy. To było dosyć długotrwałe. I na koniec, takie podejście, które dawało nam już bardzo dobre wyniki, które tak naprawdę na koniec wykorzystaliśmy. To właśnie PoseNet, sieć, która oprócz tych rzeczy, oprócz podstawowych rzeczy takich, jak kąt kierownicy, czy pedał gazu, poziom naciśnięcia gazu, zwracała również pozycję. No takie podejście ma odwzorować zachowanie kierowcy na torze wyścigowym. Bo nie reagujemy na zasadzie: „O taki jest zakręt to troszkę mocniej” tylko na zasadzie, wiemy, że jesteśmy w tym miejscu toru i za chwilę będzie trzeba na przykład wyprostować, czy przyspieszyć, więc zachowujemy się odpowiednio. Więc chodziło o to, żeby sieć nasza na podstawie cech, które wyekstrahowała w pierwszych warstwach konwolucyjnych była w stanie ocenić, w którym miejscu toru się znajduje. I tym podejściem byliśmy w stanie przejechać ładnych kilka zakrętów.

29 marca

29 marca spotkaliśmy się pierwszy raz w rzeczywistości, bo wszystko wcześniej odbywało się za pomocą Hangoutów, za pomocą Google Drive i Slacka, więc mieliśmy kanały komunikacyjne. To było też ciekawe, bo w siedmiu strefach czasowych pracowaliśmy nad projektem. Budząc się rano, oglądało się na przykład sto wiadomości. I trzeba było to nadrobić, bo każdy tam pracował. I przyjechaliśmy, spotkaliśmy się wszyscy w hotelu, zebraliśmy się w jednym miejscu, znaleźliśmy nawet jakiś sposób, żeby zhackować WiFi i żeby dało się połączyć w sieć lokalną.

I przygotowaliśmy modele.

Następnego dnia, 30 marca, pierwszy raz zobaczyliśmy samochód. Więc samochód wyjechał z pudełka i bez kawy, jaką mogliśmy dostawać w ilościach amerykańskich, nie wiem, to chyba pięć litrów, czy więcej jest w tych baniakach, także to nam pozwoliło tak naprawdę przeżyć te trzy, czy cztery krótkie dni. I teraz, tak wygląda, to jest mój filmik z zawodów.

OK, to jest nasza KIA Soul.

Ona była wyposażona we wszystkie sensory, tam był Velodyne ten z trzydziestoma dwoma wiązkami, starszy jeszcze. Mieliśmy kilka kamer, zdaje się dwa odbiorniki GPS. To jest [widok] z kamery pokładowej. I wyposażeni w te wszystkie sensory mogliśmy korzystać z tej jednej kamery firmy Pointgrey. Obok odbywały się zawody w skali 1:10. Tu było przed chwilą jeszcze, jak pierwszy raz nam się udało kierownicą sterować. Bo jak przyjechaliśmy, pierwszy problem to była integracja. Integracja zawsze jest najtrudniejsza, jeżeli pracujemy ze sprzętem to musimy się liczyć z tym, że bardzo dużo czasu stracimy na podłączenie się.

Więc 30-go w nocy uzyskaliśmy pierwszy raz, pierwszy raz sterowanie kierownicą.

Tu jeszcze mam drugi film, natomiast tutaj nie będę go długo pokazywał, bo to jest ten sam film z przejazdu tylko, że w 360. Natomiast tutaj to nie ma większego znaczenia. Będziemy mieli też nagranie z toru. Natomiast co się okazało? Nie mieliśmy danych, jeśli chodzi o ten pedał gazu w zbiorach danych, które dostaliśmy z poprzedniego roku. I też był problem na torze. Cały dzień jeździliśmy, zbieraliśmy dane, natomiast potem okazało się, że wszystkie dane są wybrakowane, brakuje nam informacji na temat przyspieszenia. Więc tę informację ktoś z nas, naszego zespołu sztucznie odtworzył na podstawie kątów, na podstawie kątów. Więc i to fajnie się udało, tutaj mamy dwa wykresy, które w miarę się pokrywają, bo następnego dnia po prostu sprawdziliśmy, jak to działa po poprawce. A  tutaj 30-go właśnie w nocy, nas pierwszy raz, kiedy udało nam się wysterować z programu skręt kierownicy. Także to był wielki triumf i to był dzień przed zawodami, dzień przed pierwszym dniem zawodów. Także bardzo trudno jest zrobić taki projekt, nie mając dostępu do sprzętu.

Było oczywiście jeszcze jedno bardzo trudne zagadnienie, w którą stronę jest +1, w którą stronę -1.

Natomiast w końcu się okazało, że jest w lewo -1, co w sumie jest intuicyjne. I zdążyło nam się jeszcze zepsuć wspomaganie. Wysłaliśmy coś złego do samochodu i trzeba było kasować błędy. Więc co mogło się nie udać dzień przed zawodami? Nie wiem, czy to nie ja byłem za to odpowiedzialny, natomiast wciąż się nie przyznam. Na szczęście, jak na takie zawody, dość proste było znaleźć kogoś, kto będzie miał akurat oprogramowanie i sprzęt do resetowania tych kodów przez złącze OBD2, więc to się udało. Następnie zrobiliśmy kilka przejazdów z maksymalnymi prędkościami. Muszę powiedzieć, że na torze niby taki samochód miejski jak KIA Soul naprawdę potrafi zaskoczyć, szczególnie jak się siedzi z tyłu.

To jest naprawdę coś strasznego.

Gdy uruchomiliśmy nasze modele, wszystkie wytrenowane do tej pory, samochód jechał cały czas prosto, kompletnie nie skręcał. Nie było tak naprawdę żadnej reakcji. I mieliśmy bardzo duży problem z uwagi na bardzo duże opóźnienie pomiędzy obrazem, jaki dostajemy, bo my wykorzystaliśmy z PolySynca oprogramowania, konwertowane to było do ROSa. My właśnie to jeszcze odbieraliśmy, więc tam było opóźnienie naprawdę duże. Popracowaliśmy chyba przez noc jeszcze nad architekturą, żeby to przyspieszyć. Część osób znowu trenowała sieci neuronowe na tych danych, które przyszły. Ja na szczęście miałem ze sobą komputer z dość mocną kartą graficzną. Okazało się, że w hotelu nie mamy dobrego Internetu, więc nasz komputer w chmurze, który miał osiem kart graficznych był kompletnie bezużyteczny. Więc to też trzeba uważać na takie rzeczy.

Dzień pierwszy.

Nie wiem, czy ktoś zna tego pana. To jest George Hotz z Comma.ai, człowiek, który zhackował iPhone’a i tak dalej, bardzo sławny. No więc mieliśmy parę rozmów z różnymi ludźmi, oni też tam byli, mieli tam swój samochód, ale nie startowali, czy coś. Nie wiem, tego dokładnie nie pamiętam. Natomiast po rozmowach właśnie doszliśmy do tego, że trzeba by zastosować PoseNet, to jest właśnie ten moment. PoseNet o tym wcześniej rozmawialiśmy. I zastosowaniePoseNeta, którego trenowaliśmy jeszcze w noc, w noc i poranek, tam miałem taki system, że

trenowałem sieć neuronową, wsiadaliśmy szybko do samochodu i jeszcze pół godziny jadąc ten komputer wytrzymywał trenując ciągle i mogliśmy dokończyć to.

Więc przejechaliśmy wszystkie zakręty, niestety nie w jednym okrążeniu. Więc mieliśmy różne modele, które były w stanie przejechać różne zakręty, natomiast nie udało nam się stworzyć jednego rozwiązania opartego właśnie na tej sieci End to End, które by przejechało wszystkie zawody. Więcej informacji jest w naszym poście. Tytuł wzorowaliśmy na tych zawodach Grand Challenge, które tam były w 2006 roku, to były zawody dla samochodów autonomicznych.

I tam jest dokładnie to opisane.

Natomiast w tym roku, w tym roku już były tylko cztery osoby. Nie mieliśmy wsparcia od Udacity. Więc ja tak naprawdę tam przyjechałem hobbystyczne, chciałem zobaczyć, co jest dalej, mieliśmy też plany, pracowaliśmy nad projektem w międzyczasie przez rok. Po godzinach. Znaczy był jeszcze jeden nasz kolega, który nie angażował się w ogóle, natomiast jest profesjonalnym kierowcą na tym torze, więc był z nami, towarzyszył nam, ale niestety nie brał udziału w tym. I nie mieliśmy samochodu, nie mieliśmy sprzętu, mieliśmy oprogramowanie, natomiast nie dokończyliśmy go, bo w parę dni przed zawodami okazało się, że nie uda nam się pożyczyć samochodu. Mieliśmy dwie różne propozycje, jeśli chodzi o pożyczenie samochodu, aby wystartować. Na szczęście wśród osób, które były na torze, była jedna osoba, firma, która sprzedaje zestawy Drive By Wire, gdzie można podłączyć się do samochodu.

To był samochód demo, który miał drugą kierownicę.

I to jest też ciekawe doświadczenie sterować z tej drugiej kierownicy, bo nie mamy sprzężenia zwrotnego, więc nie wiemy, czy koła stawiają opór, czy nie. Więc możemy sobie kręcić do woli. Nie mieliśmy też kamery, więc udaliśmy się do Walmartu, gdzie to jest kamera oklejona jakimś takim wysokiej jakości taśmą i kartonem. Nasze podejście na ten rok było zastosowanie segmentacji semantycznej by wyznaczyć drogę. To jest w ogóle zdjęcie z Warszawy, natomiast to nie jest to, co ja robiłem, to robił mój kolega, więc nie wiem w sumie, skąd się ono wzięło. Natomiast chcieliśmy wykorzystać, wzorując się trochę na sieciach, które są autokoderami, czyli zakładamy, że mamy wejście i wyjście, powiedzmy, takie samo albo podobne, zastosować tylko tę część pierwszą i kolega stwierdzić, że dobrze będzie wziąć sieć YOLO i odciąć tak naprawdę część do wykrywania obiektów i wziąć tylko sam początek, czyli warstwy, które ekstrahują cechy z obrazu. Więc mając w jakiś sposób wyekstrahowane cechy, nauczyliśmy sieć rozpoznawania naszych klas, nasze klasy to była droga, pasy i pachołki.

Nie wiedzieć czemu, sieć tutaj na zielono na górze oznaczała jeszcze szczyty gór. To miały być linie.

Więc nie było idealnie, natomiast było wystarczająco. I na podstawie, na podstawie takiego obszaru na czerwono zaznaczonego, wyznaczaliśmy ścieżkę aproksymując krzywą drugiego rzędu, jakiś kwadrat i sytuacja była dość prosta. Braliśmy linia po linii od dołu, środek, medianę, czyli środek takiego obszaru i po prostu w ten sposób wyznaczaliśmy trajektorię. Później była dopasowana szyba i następnie taką trajektorię chcieliśmy zastosować używając MPC (Model Predictive Control), natomiast nie mieliśmy dobrego modelu, bo samochód dostaliśmy pół godziny przed startem. A więc zastosowaliśmy aproksymację liniową, czyli tak naprawdę ten kąt skrętu kierownicy wyznaczaliśmy. I tam zrobiliśmy to z jednym małym błędem, natomiast jakoś tam działało. Tu widzimy, że samochód…

To jest jazda autonomiczna, więc on sobie tutaj jedzie. Dość często wjeżdża na trawę. Natomiast były też momenty, kiedy to działało dużo lepiej. Teraz przez chwilę będzie dobrze.

To, co mamy zrobione to właśnie tutaj był chyba wzięty któryś punkt tak gdzieś daleko i ścinało zakręty po prostu. W pewnym sensie to było niedopracowane. No więc, jak wyglądała sytuacja? Zawody mają dwa dni, tak jak w poprzednim roku i w połowie pierwszego dnia udaje nam się pożyczyć Toyotę Prius, z dwoma kierownicami. I dostajemy do tego sieć CAN z samochodu wyprowadzoną i dostajemy urządzenie firmy Kwazer, które nam konwertuje ten CAN na USB i możemy się komunikować z samochodem. Udało nam się to zintegrować w pół godziny, w międzyczasie druga osoba pracowała nad dopracowaniem takiego końca tej sieci neuronowej, żeby to zintegrować. Tu widzimy to, co przed chwilą tylko, że w samochodzie na żywo. Pośrodku jest jeszcze telefon, który wyświetla ten kąt, to było zintegrowane przez dostawcę samochodu. Także mogliśmy spokojnie w ogóle jechać. Tam po każdej interferencji na telefonie coś się tam zmieniało, natomiast ja dodałem na dole napis, który zmieni się w przypadku dotknięcia kierownicy.

Jakiego to rzędu prędkości były? Prędkość była niska.

W poprzednim roku ustawiliśmy prędkość na 35 mil na godzinę z uwagi na to, że nie chcieliśmy się tym męczyć, bo mieliśmy problemy ze skręcaniem, więc ustawiliśmy na najniższą, to jest 35 w Stanach, 35 mil. A tutaj, nie no, to było dość wolno. Dość wolno było. Natomiast gdy zbieraliśmy dane, jeździliśmy 50, 60, 70 mil na godzinę, natomiast potem byłoby to dość, powiedziałbym, niebezpieczne. W ogóle nie wiem, jak wiele osób jeździ na torze i było na torze. To był mój pierwszy raz tam i z takich ciekawostek, jeździ się na przykład z otwartymi szybami z uwagi na reakcję przy wypadku, żeby można było łatwo wyciągnąć.

Wszyscy w kasku.

Tylko podczas testów można było być w cztery osoby, tak normalnie dwie osoby. Przy czterech osobach było ograniczenie właśnie chyba do 60 mil, to też wynikało z tego. Na tych zawodach zobaczyłem pierwszy raz tego Velodyne’a 128, bo ma 128 wiązek. Bardzo fajne urządzenie.

Jechaliście pojedynczo?

Idea taka już w zeszłym roku była, żeby był więcej niż jeden samochód na raz autonomiczny, natomiast biorąc pod uwagę te samochody, jak one jechały to zmieniono, że jednak będzie pojedynczo. To samo mieliśmy w tym roku na 1/10 natomiast już następne zawody mają być raczej na 100% z oponentem, czyli będą wyścigi z omijaniem przeszkód. My już w tym roku się przygotowywaliśmy, natomiast okazało się na zawodach tak naprawdę, na testach?

Jakoś na zawodach się okazało, że nie będzie oponenta.

Więc troszeczkę prościej, natomiast przygotowywaliśmy się na coś innego. Więc jeśli chodzi o nasze przygotowania to nasz zespół osiemnastoosobowy w 2017 mając 4 dni z samochodem i 1 dzień integracji, 2 dni i jeszcze 2 godziny podczas już samych zawodów na torze, i świetne sensory, byliśmy w stanie tak naprawdę przejechać jeden zakręt naraz w jednym okrążeniu. Ewentualnie wszystkie zakręty, ale przy różnych sieciach. W tym roku, z tymi doświadczeniami w 4 osoby mając 24 godziny z samochodem, bo to było od… bo właściciel musiał jechać do domu, więc skończyliśmy wcześniej, w 30 minut zintegrowaliśmy, mając 40 minut na to, że byliśmy w stanie uzyskać dużo lepsze wyniki i mając jakąś tam kamerę za, nie wiem, 100-200 złotych. Tutaj opierałem się w części na prezentacji Anthony’ego i Jendrika. Anthony jest teraz szefem albo Self-Driving Car Nanodegree albo tego robotycznego albo obu, teraz już nie wiem, bo to się chyba zmieniało ostatnio. Tu jest jeszcze link do postu. Wszystkie prezentacje będę udostępniał, będą też nagrania, natomiast proszę zdjęcia robić. A, i tu jest napisane dziękuję, więc to już wszystko. Dziękuję bardzo.

Z czego wynikało to ograniczenie dostępu do samochodu?

Więc tak, w przypadku pierwszych zawodów to nie mieliśmy po prostu nikogo na miejscu, gdzie był samochód, czyli tam w siedzibie PolySync w Stanach. Więc to jest ten problem do momentu zawodów. Gdy jechaliśmy na zawody w 2017, plan był taki, że będziemy mieli tydzień integracji, natomiast PolySync okazało się, że zmienił zdanie w ostatniej chwili i przyjechali dopiero dwa dni przed zawodami. Mmy byliśmy już wcześniej, chwilę tam spędziliśmy ze sobą właśnie jeszcze pracując trochę nad tymi rozwiązaniami. Natomiast w tym roku po prostu nie mieliśmy żadnego sponsora, żadnego samochodu, po prostu mieliśmy pomysły, rozwiązania, natomiast no tak wyszło. Ja leciałem tam z myślą, że będę widzem po prostu. Czy są jeszcze jakieś pytania? Bo nie zadałem tego pytania, więc może jeszcze ktoś ma pytania?

Jak dostałeś się do ekipy Udacity? Bo rozumiem, że skończyłeś Nanodegree, tak? I potem był jakiś nabór, który był organizowany przez Udacity? Jak to wyglądało?

Jeśli chodzi o ten kurs to kurs zaczął się 2016 chyba we wrześniu, czy październiku. I wtedy była pierwsza tura, oni tam co miesiąc potem zbierali następnych studentów, ja byłem w drugiej grupie. Nabór do tego programu był w lutym, oni zrobili po prostu takie coś, że można było się zgłosić. Ja się zgłosiłem, zgłosiło się tam bardzo dużo osób, sporo odrzucili i zostawili osiemnaście. Więc tam w jakiś sposób oceniali. Chcieli zrobić zespół dziesięciu najlepszych, natomiast rozszerzyli to do osiemnastu. Czy jeszcze jakieś pytania? Okay. Dziękuję.

Doświadczenia z zawodów F1/10, Łukasz Sztyber / Karol Majek

W drugiej prezentacji Łukasz Sztyber wraz z Karolem opowiadali o swoim rozwiązaniu które wygrało zawody F1/10 w Turynie. Poznali się pół roku przed zawodami i wraz z Maciejem Dziubińskim  przygotowali pojazd i wystartowali w zawodach. Ich rozwiązanie nie wykorzystywało mapy tylko nawigację reaktywną. Na szczęście posiadając oprogramowanie napisane w C++ oraz skaner laserowy działający z częstotliwością 40 Hz udało się jeździć wystarczająco szybko i reagować na zmiany na trasie.

Kliknij tu aby poprać prezentację

Tutaj możesz zobaczyć filmy z zawodów:

Transkrypcja

Czy ktoś z was w ogóle się zastanawia nad przygodą z takimi autonomicznymi pojazdami?

Oprócz kolegów i koleżanki z Politechniki? To tak, żebym też wiedział, na czym się bardziej skupić, a co można przewinąć. Pytanie, czy w ogóle jest to dla was interesujące, bo możemy tą część prezentacyjną przewinąć i przejść od razu na tor, tam jest tego dużo. Dobra, to tak w skrócie przejdziemy. Koncepcję F1/10 znana wam jest, czy niekoniecznie? Okay, dobra. Zacznę od początku. Teraz w Turynie w październiku, 1 października odbyły się zawody, trzecia edycja, to są samochody w skali 1:10. Oczywiście tu się pojawiają już pierwsze kontrowersje, bo tak typowy klasyczny samochód to tutaj koledzy z Politechniki mają w skali 1:10, natomiast jak się okazuje to specyfikacja zawodów jest taka, że to jest 1:8 albo tak zwane powiększone 1:10. Samochody mają być zbudowane według identycznej specyfikacji, natomiast w związku z tym, że nie wszystkie części są dostępne tak samo we wszystkich regionach świata, niektórzy się tym zajmują, mają jakieś swoje modele. To tak do końca jakby organizatorzy tej specyfikacji nie trzymają. No i my też na początku, jak mieliśmy jakiś tam pojazd, prezentowaliśmy go na poprzedniej edycji spotkania, natomiast myślę, że tym pojazdem jeżeli byśmy wystartowali to pewnie ciężko byłoby nawet ukończyć jedno okrążenie. A za chwilkę powiem wam dlaczego. To jest specyfikacja naszego pojazdu. Podwozie wzięliśmy z takich samochodów, pewnie gdzieś tam widzieliście na jakichś tam filmikach, być może w życiu, są takie samochody spalinowe. One są dość solidne, mają metalową konstrukcję, metalowe podwozie, bardzo solidne zawieszenie. To oczywiście niesie ze sobą jakby i plusy i minusy, no plusem jest ta solidność, taka stabilność, one mają bardzo fajnie, niskie zawieszenie, świetnie się nadają do wyścigów, natomiast one są dość adekwatnie cięższe.

Ten nasz pojazd jakby razem z baterią ważył około 4 kilo.

To jest dość sporo i przy takim samym silniku zastosowanym w takim pojeździe, a w ciężkim to wiadomo, że zupełnie inne będą przyśpieszenia przede wszystkim, a te przyspieszenia są dość kluczowe. Napęd 4×4, w poprzednim samochodzie mieliśmy tylko na tylną oś. Jeżeli jeździmy na krótkim torze, torze, który jest śliski to taki samochód z tylnym napędem przy odrobinie większym przyśpieszeniu kręci się w kółko, nie jedzie wcale. Tutaj wcześniej samochód na przykładzie właśnie z tylnym napędem, dość dużą mocą, on nie jest w stanie stabilnie jechać. Więc jakbyście się zastanawiali to polecam od razu napęd 4×4. Servo wzięliśmy takie, no powiedzmy, na poziomie średnim, średnim plus, to nie jest nic wypasionego. Większość drużyn startowała z servo takim zaawansowanym używanym do deskorolek elektrycznych. Tam to servo zdecydowanie jest lepsze, na to servo na pewno będziemy się przesiadać przed kolejnymi zawodami. Tam oprócz tego, że jest bardzo precyzyjne i płynne sterowanie to jest też dużo takich informacji o tym, co się dzieje z pojazdem, czyli jakie są na przykład obroty, co się bezpośrednio na przykład przedkłada na prędkość w danym momencie, z tego można różne ciekawe rzeczy wyciągać. Silnik sensorowany, to też jest jakby spójniejsza jazda.

2350kV, taki tajemniczy skrót,

przynajmniej dla mnie był tajemniczy chwilę temu, na początku myślałem, że to jest kilowolt, ale to nie miałoby zupełnie sensu. To chodzi o to, ile z jednego wolta można wyciągnąć obrotów. Tak to jest jakby stały element. Biorąc pod uwagę, że mamy baterię 3S, czyli tam 11 woltów to mnożymy 11 razy 2350 i wychodzi nam właściwa wartość. Ten silnik, który był zalecany przez organizatorów był silnikiem o większej liczbie obrotów, 3500 woltów, silnik Traxxas Velineon 3500. Dość istotny element to jest servo, a w zasadzie jakby jego parametry, jeśli chodzi o skręt, zestrojenie pozycji w jedną stronę, zestrojenie pozycji w drugą stronę. No tutaj postawiliśmy na dość dobre urządzenie, czyli takie no nominalnie ma czas na poziomie 60 milisekund, natomiast no można ten czas jeszcze trochę poprawić puszczając wyższe napięcie, dając wyższe napięcie na to servo. Oczywiście w granicach, które są akceptowalne przez producenta.

Czujnik laserowy, podstawowy sensor, którym się lokalizowaliśmy na torze.

Zgodnie z zaleceniami UST 10 LX Hokuyo, bardzo solidne urządzenie. Przyznam szczerze, że nie myślałem, że ono przetrwa tyle wypadków, co mieliśmy przed zawodami i jak się dowiedziałem od kolegów, w trakcie zawodów. Tak że był też bardzo wytrzymały, warto zainwestować. Nominalnie w zależności od rodzaju powierzchni i koloru tych powierzchni ten laser jest w stanie do 30 metrów spokojnie wykrywać przeszkody. 10 metrów jest jakby super pewnie, więc no tyle spokojnie można wykorzystywać. No i ten laser pracuje z prędkością, częstotliwością 40 hz, czyli 40 razy na sekundę jest podawany pełny odczyt. Jak się później okazało, to później o tym opowiem, nie jest to też takie proste, żeby te informacje z taką prędkością odebrać i przetworzyć. Jeżeli chodzi o główne urządzenia do przetworzenia informacji to my mieliśmy pod ręką Raspberry PI, więc skorzystaliśmy z tego, natomiast zalecanym rozwiązaniem był Jetson TX2 od Nvidii, czyli zdecydowanie mocniejsze urządzenie. No i zalecany kontroler PWM, czyli urządzenie, które można do wielu zastosowań wykorzystać no to jest Teensy, skorzystaliśmy z tego, chociaż na początku jak mieliśmy też PWM, ale mieliśmy sporo problemów chociażby z czasem reakcji. Czyli podawanie z tego Raspberry PI czasami kończyło się opóźnieniem 0.5s, co przy 10 metrach na sekundę to mówimy o tym, że co 5 metrów jesteśmy w stanie rozpoznać, co się dzieje i wprowadzić jakby odpowiednie komendy do samochodu. Z takich sensorów, z których można było skorzystać oprócz LIDAR-a, o którym mówiliśmy, no to jest IMU i tam te wszystkie przyspieszenia we wszystkich ważnych kierunkach, my z tego nie skorzystaliśmy, no i też można było skorzystać jakby z kamer głębi, czy z kamerki stereoskopowej. Też jakby nie widzieliśmy zastosowania, poza tym jakby nie mając przyspieszenia graficznego na naszym Raspberry PI trudno nam by było przetwarzać dane z kamery stereoskopowej. Nie widzieliśmy też jakby wartości dodanej w stosunku do lasera. Jeżeli chodzi o algorytm, który przygotowaliśmy to

ambicje na początku były dość mocno rozdmuchane,

chcieliśmy zrobić lokalizację, chcieliśmy wprowadzić zaawansowane nabywanie ścieżek, jakieś tam optymalizacje, być może jakieś elementy oparte na sieciach neuronowych do sterowania, natomiast to wszystko zweryfikowało na wczesnym etapie i okazało się, że wszystkie te elementy, po pierwsze, są dość trudne do wdrożenia, czyli wymagają bardzo dużej ilości pracy, żeby je przygotować, a po drugie, no one zazwyczaj wiążą się z tym, że są bardzo złożone obliczeniowo. Więc na takim sprzęcie małym, który jest na pojeździe to znowu czasy przetwarzania są na tyle nieatrakcyjne, że zbyt rzadko bylibyśmy w stanie wprowadzać modyfikację w torze jazdy. Więc no poszliśmy trochę na skróty i wymyśliliśmy, że takie rozwiązanie wdrożymy, które będzie podejmowało decyzje lokalnie, czyli po każdym odczytaniu informacji z lasera, będzie sprawdzało, w które miejsce najdalej na torze może dojechać z danej pozycji, w której stoi. Może dojechać, to znaczy, że zmieści się samochód, jakby biorąc pod uwagę jego szerokość plus ewentualnie jakiś tam offset na bezpieczeństwo. Natomiast w ustawieniach ustawiliśmy szerokość, połowę szerokości samochodu, czyli odległość od lasera do brzegu samochodu. No i okazało się, że takie rozwiązanie po zoptymalizowaniu, czyli też jakby biorąc pod uwagę to, że jeżeli mamy odczyty z lasera to też jakby nie musimy za każdym razem sprawdzać całej przestrzeni punktów, możemy tą rozdzielczość sobie zmniejszyć poprzez samplowanie, ale możemy też zmniejszyć w sposób trochę bardziej inteligentny, czyli na przykład możemy poszukać punktów nieciągłości, czyli tam gdzie odległość pomiędzy kolejnymi dwoma punktami jest większa niż wynikałoby to z odległości od lasera i odległości kątowej pomiędzy nimi to widać, że coś tam się dzieje dziwnego. Możemy tam wprowadzić parametr i w ten sposób możemy ilość punktów z 1080 sprowadzić do, no w zależności od tego, jaką rozdzielczość sobie ustawimy, 20-40 punktów. No to jest znacznie szybciej. Napęd na 4 koła to już powiedziałem. Sterowanie PWM to też powiedziałem, mieliśmy ten kłopot, że na początku bardzo wolno byliśmy w stanie podawać ten sygnał i nie byliśmy w stanie z prędkością większą niż minimalna jeździć wcale. Odkryliśmy też, że są bardzo duże narzuty, więc też warto, o tym pewnie koledzy z Politechniki, mają dużo większe doświadczenia, mogliby dużo więcej opowiedzieć. Że pewnie bardzo dużo rzeczy, co to tu też się da to wyrzucać poza ROSa.

ROS absolutnie nie jest systemem na dzień dzisiejszy czasu rzeczywistego.

Świetnie się sprawdza do prowadzenia łazików, które sobie jeżdżą i zwiedzają, ale nie do pojazdów wyścigowych, które gdzieś tam jeżdżą w krańcowych, brzegowych sytuacjach, jeżeli chodzi o parametry. Tak jak wspomniałem, poszliśmy trochę na skróty i wdrożyliśmy drzewo decyzyjne do sterowania zamiast kontrolera P(I)D, tego kontrolera też mieliśmy, natomiast okazało się, że nie mając lokalizacji, nie mając możliwości podejmowania bardziej wyszukanych decyzji co do trasy przejazdu to ten kontroler liniowy, który nadawał nam fajne sterowanie, żadnej wartości nie dodawał. Natomiast zoptymalizowanie takiej funkcji, nawet gdyby to była funkcja liniowa, chociaż w tym przypadku nie była, to jest dość trudne zadanie. Więc stwierdziliśmy, że zrobimy drzewo decyzyjne z trzema prędkościami, „jedź wolno”, „jedź średnio szybko”, „jedź szybko” i przy takich trzech parametrach można dość szybko zoptymalizować rozwiązanie. A o to nam chodziło, żeby na nieznanym torze, po przejechaniu na zawody, żeby to nasze rozwiązanie można było ustawić do parametrów bliskich optymalnym. Jeżeli chodzi o laser to przez długi czas walczyliśmy z tym, żeby 40 herców wyciągnąć.

Mnóstwo parametrów jest, które trzeba poustawiać odpowiednio.

Ten ostatni dopiero gdzieś tam na chwilę przed zawodami nam się udało ustawić. Przez większość czasu mieliśmy no faktyczne 20 herców, znaczy liczba odczytów była taka, jak trzeba, czyli było 40 odczytów na sekundę, natomiast rozłożenie ich nie było równomierne, więc jakby odczyty były kumulowane i podawane co 5, 50 milisekund, czyli robiło się i tak 20 herców. Więc lepiej było obcinać jakby te nadmiarowe odczyty, żeby one nie przeszkadzały. Natomiast jakby no jeżeli ktoś z was planował zabawę z takim laserem to chętnie się podzielimy, jak ustawić te parametry. No i ostatnia dość ważna rzecz, python jest bardzo fajnym językiem, jeżeli chodzi o prototypowanie, bo można dużo rzeczy zmieniać, puszczać i tak powtarzać wiele razy, natomiast tak jakby na zawody to tylko i wyłącznie C++ wchodzi w grę, no bo w przypadku naszego rozwiązania tutaj różnica była rząd wielkości, dziesięciokrotnie szybsze rozwiązanie, powtórzenie tego samego algorytmu.

To co planujemy na następne zawody to przesiadka na Jetson TX2,

mamy ambicję, żeby to rozwiązanie było znacznie bardziej wyszukane i zaawansowane, więc chcemy wprowadzić mapowanie i lokalizację. Bardziej zaawansowane generowanie trajektorii, które będą oparte na modelu fizycznym samochodu, a nie tak, jak w tym momencie, to są jakby funkcje liniowe. Chcemy znaleźć jakiś wydajny kontroler do sterowania prędkością, być może to będzie oparty na sieciach neuronowych, być może jakaś tam odmiana PD, czy P(I)D. No i teraz kluczowa rzecz jest taka, że jeżeli testujemy sobie rozwiązanie na jakimś tam torze, tak jak tutaj mamy jakąś tam elipsę i no my przygotowując się do zawodów też coś takiego tylko mieliśmy, no to ciężko jest wytestować wiele sytuacji. I kluczowe jest to, że jakby jeżeli pojedziemy na tor, którego nie znamy to trzeba mieć taką procedurę, która pozwoli jakby zoptymalizować i podtunować rozwiązanie do optymalnych parametrów w krótkim czasie, bo jest na to tam, powiedzmy, jeden, czy dwa dni. Więc no też planujemy przygotować sobie taką procedurę, żeby nie poruszać się na chybił trafił tylko, żeby przejść po prostu procedurę i mieć pewność, że w skończonym czasie jesteśmy w stanie parametry bliskie optymalnym znaleźć. Tym razem nie było wyprzedzenia, chociaż było zapowiadane, że będzie wyprzedzanie innych pojazdów, natomiast spodziewamy się, że na kolejnych zawodach takie wyprzedzenia już może się pojawić, więc też chcemy się na to przygotować. To tyle. Macie jakieś pytania może do tej części?

Skąd dane do sterowania PWM?

Z testów, empiryczne. Znaczy trajektorie były naiwne, czyli znajdujemy linię prostą, która prowadzi do punktu, który jest najdalej oddalony i do którego bezpiecznie jesteśmy w stanie dojechać. I po wyliczeniu takiego punktu, no to ten punkt jakby w skali powiedzmy od 0 do 180 stopni, czy tam od +/- 90 stopni pokazuje nam kierunek, w którym możemy jechać. Plus możemy jakieś tam parametry oczywiście dodać, żeby to przeskalować w dół, w górę.

Czyli prędkość była, te trzy prędkości wstępne, były funkcją tego, jaka daleka jest wspólna przestrzeń?

Prędkość była w zasadzie funkcją tego, jak daleka jest przestrzeń, czyli ile metrów jakby jesteśmy w stanie wykonywać plus jeszcze tam parametr związany ze skrętem kół. Przy dużym skręcie kół nawet jak świeżo wyjedziemy na przykład z zawrotki, za którą jest jakby duża przestrzeń to nie możemy jechać na śliskim torze na pełnej prędkości, no bo się obrócimy w miejscu.

LIDAR, co on daje? Co uzyskujemy z niego? Odległości jakieś?

Tak, znaczy ten LIDAR jakby daje zestaw, w tym przypadku 1080 punktów, czyli tam rozdzielczość ¼ stopnia. 270 stopni, czyli 90 stopni z tyłu jest wycięte. Daje odległości z każdego takiego strzału, jaka jest odległość do najbliższej przeszkody. Czyli tam gdzie doleci laser, odbije się i wróci no to taka jest wartość podawana.

Na pewnej jakieś tam wysokości, rozumiem, tak?

Na tej wysokości, na którym jest zainstalowany i tam jest jakby jedna wiązka, więc to jest taka płaszczyzna.

Karol: Teraz się zamienimy, ja wezmę dwa mikrofony.

Jako, że kolegi na zawodach nie było, niestety nie mógł pojechać, ja pojechałem z jeszcze jednym kolegą, którego tutaj nie ma. Z Maciejem. Tak wyglądał nasz tor. To jest nasza mapa, którą zbudowaliśmy bez odometrii, używając samych danych z lasera, natomiast potem tej mapy nie wykorzystywaliśmy niestety, ale jesteśmy przygotowani, jeśli chodzi o budowę mapy. To w zasadzie dość wcześnie nam się udało przygotować. Zawodów były dwa dni. Niedziela i poniedziałek. W niedzielę były testy na torze, a w poniedziałek już była część zawodów, jeszcze było trochę testów, natomiast potem odbyły się, potem odbyły się już konkurencje z pomiarem czasów. W ramach zawodów była jedna sesja pięciominutowa i druga sesja trzyminutowa. Więc w ramach tych pięciu minut celem było uzyskanie jak największej liczby okrążeń. Więc wiadomo, jeżeli nasz samochód uderzy w przeszkodę, tracimy czas. W takim przypadku również musimy cofnąć samochód do checkpointu, tam było kilka checkpointów, chyba trzy, czy cztery, oznaczone taśmą po prostu na torze.

I po takim wypadku trzeba było wejść na tor,

jeżeli był zespół jednoosobowy to ktoś pomagał z innych zespołów, więc trzeba było wejść na tor, cofnąć samochód, naprawić tor, jeżeli były uszkodzenia i można było jechać dalej. Było dziewięć zespołów. 2 zespoły z Polski, obecne tutaj. 2 zespoły z Korei, 1 z Włoch, 3 ze Stanów i 1 z Czech. Zespół z Czech to byli zwycięzcy z poprzedniej edycji, więc tutaj wszyscy oczekiwali od nich, że również im się to uda razem. Natomiast jeśli chodzi o zespół z Czech to oni bardzo zmienili skład. Tam były tak naprawdę, jedna osoba była z poprzedniego zespołu i to był zupełnie nowy zespół tak naprawdę, więc tylko logo zostało. Dzień przed zawodami w ramach, w ramach takiej praktyki i testów, bo nie mieliśmy toru, nie mogliśmy toru rozłożyć tam jeszcze dzień przed tymi testami, nie udało się, mamy symulator samochodu autonomicznego 1:10, tam jak widziałem później w dzień zawodów, już zespół z Korei miał mapę stworzoną, tą właśnie przeniesioną mapę z wydarzenia. Bo to jest inna mapa. I tutaj w tym przypadku symulator mógłby nam nieco pomóc, bo wydaje mi się, że

dużo łatwiej będzie nanieść wszystkie szumy na takie dane z lasera niż na dane z kamery.

Bo tutaj mamy widok z symulowanej kamery, co powiedziałbym, nieco odbiega temu widokowi, który będzie później na torze i będzie dużo trudniej to zamodelować. Natomiast dodać szum na danych laserach, tutaj widzimy na górze w lewym górnym rogu, dosłownie pod tym oknem. Przepraszam, ale to jest prezentacja na żywo. A więc tutaj samochód znajduje się w środku, tu gdzie jest to przecięcie tych dwóch linii. I tu widzimy punkty pomiarowe, widać tutaj, ta kropka to jest, zdaje się, 5 metrów.

Czy to jest możliwe? Chyba tak. 5 albo 10. Strzelałbym, że 5 albo 10.

Dobra, tu nie jestem pewien, więc nie będę ryzykował. Dobra, 10 metrów, już sprawdziłem. A więc to jest kropka dziesięciometrowa. I tak, jak Łukasz wcześniej wspominał, mamy 1081 punktów, bo tam jest pierwszy taki jeszcze, wysokość 270 stopni, tu widać teraz większy zakres przez chwilę. O, widać jeszcze punkt jakiś z tyłu, bo mamy widoczność do tyłu, dość niedużą i mamy też fragment wycięty, te 90 stopni wycięte. Tutaj nic nie widzimy.

I nie widzimy też tego, co jest za zakrętem, co w zasadzie jest oczywiste, tak?

Bo promienie lasera nie są w stanie tam dotrzeć. Więc mając takie dane możemy wnioskować, możemy budować mapę, możemy wnioskować, jaka jest, jaka jest trajektoria. Tu jest nasza symulowana odometria na podstawie danych z lasera. Więc mamy tutaj trajektorię, jaką jechaliśmy. Plus skumulowane pomiary. To nie była mapa tylko skumulowane pomiary. Natomiast ta trajektoria jest na tyle dobra, że te skumulowane pomiary układają się w mapę, a mapę widzieliśmy, mapę widzieliśmy wcześniej. Tutaj jeździ nasze rozwiązanie, które zostało zaadaptowane w dość prosty sposób do jeżdżenia w symulatorze, bo symulator przyjmuje, jako parametry przyjmuje prędkość liniową w metrach na sekundę. I prędkość, nie prędkość kątową tylko kąt skrętu kół przednich. Natomiast u nas mamy dane, wartości, które przesyłamy bezpośrednio na servo i na kontroler prędkości, które nie są wprost w metrach na sekundę ani w kącie, więc no niestety tam musieliśmy jakieś dodatkowe współczynniki dobrać. Tu jest przykład, jakie problemy możemy napotkać przy budowie mapy, jeżeli zrobimy jedno okrążenie, a później z uwagi na błąd lokalizacji możemy uzyskać, tu jest nie wiem, pół metra, czy metr błędu, natomiast my jesteśmy w stanie to jeszcze wyeliminować dodając drugi algorytm, bo tutaj jest wykorzystany hector SLAM, hector mapping. O, to są też ciekawe problemy. Więc może pójść źle. Natomiast jeżeli użyjemy dwóch algorytmów do budowania mapy, czyli hector SLAM i do tego jeszcze gmapping,

jesteśmy w stanie odtworzyć odometrię z samych skanów lasera, z samych skanów.

I jesteśmy w stanie zbudować na podstawie tej odtworzonej odometrii mapę dokładną, którą widzieliśmy na samym początku. Na zawodach, jak się okazało, bardzo trudny był ten zakręt, ta zawrotka tutaj i praktycznie, nie wiem, jeden, czy dwa zespoły były w stanie od razu zacząć jeździć tutaj. My też mieliśmy bardzo duży problem. Szczególnie biorąc pod uwagę nasze podejście, które miało być troszkę inne, natomiast my się poznaliśmy pół roku temu i wszystko stworzyliśmy właśnie w ciągu tego pół roku na czterech samochodach, czterech modelach, jeśli się nie mylę. Jeszcze mam przygotowane kilka filmów z zawodów, natomiast tu chciałem pokazać jeden, jeden krótki piętnastominutowy. Tak wyglądają nasze pierwsze eksperymenty, gdzie jeździliśmy po siedzibie Daftcode. I budynek jest bardzo ciekawy, zrobiliśmy tam kilka okrążeń, tutaj widać, jak mapa się dowiązała. I tu jeszcze było kilka okrążeń, natomiast tutaj obciąłem film. Tak wyglądały nasze pierwsze przygotowania, gdy budowaliśmy tor na sali gimnastycznej. Pierwszy tor, pierwszy samochód, z którego zostało tylko serce, to właśnie to Raspberry PI, testowaliśmy również przeszkody rozmieszczone na torze, robiliśmy również testy w biurze z uwagi na brak dostępności innych miejsc

I mieliśmy także mnóstwo, mnóstwo porażek, mnóstwo wypadków samochodem.

Laser jest przypięty na rzepach, więc on za każdym razem po prostu odpadał. Co jest w sumie dobre, bo nie przyjmował upadku, więc tam się nic nie zniszczyło. Tuż przed zawodami zrobiliśmy testy na bardzo małej sali z uwagi na to, że nie mieliśmy zupełnie innego miejsca. Więc tu macie przygotowanie. A później na zawodach. Na zawodach było jeszcze więcej problemów.

Niszczyliśmy tor wszędzie, gdzie się dało.

Potem zaczęło nagle iść już lepiej. Nie mam żadnego filmu z tego momentu, kiedy nie mogliśmy pokonać tamtej zawrotki, nie kręciłem, bo ratowaliśmy sytuację. Jeśli chodzi o te przejazdy później już oceniane…

Ja mam pytanie. Czy to, że jest zupełnie inne podłoże to jakoś wam komplikowało?

Tak, znaczy podłoże komplikuje, natomiast… tu widać, takie jest błyszczące, tu też jest na przykład dość trudno. My jeździliśmy na sali gimnastycznej, gdzie było bardzo ślisko, ale jeździliśmy również na wykładzinie. Na wykładzinie to naprawdę w ogóle się nie ślizgał, natomiast teren śliski nawet pomagał, on sobie radził, ratował się z tych zakrętów, gdzie wszedł w poślizg. Tak że… Nie, tu niestety nie widać. Chyba trzecie okrążenie będzie takie najszybsze. Tu niestety dźwięku nie włączyłem. Ten dźwięk tam zdradza trochę emocji, ale zaraz będziemy słyszeć na żywo. A, wyniki. Tu mamy samochody wszystkie ustawione w rzędzie. Nasz to jest ten, ktoś go poznaje? Była tam też tablica wyników. Generalnie to, co u nas się udało to 16 okrążeń w 5 minutach plus 10 w trzech minutach. I najlepszy czas 18:29, który powtórzyliśmy w naszym trzyminutowym okrążeniu, więc mieliśmy identyczny czas w dwóch przejazdach.

I co nam tak naprawdę pomogło?

To, że zamroziliśmy oprogramowanie, nie pracowaliśmy nad oprogramowaniem od połowy dnia w ogóle poprzedzającego zawodu. Wtedy już tylko dostosowaliśmy parametry. A więc opracowywaliśmy procedurę uruchamiania, czyli mieliśmy ściśle ustalone co po kolei. Wspomniał o tym Łukasz, mam wrażenie. Zaplanowaliśmy testy. Mieliśmy tabelę, którą niestety wyrzuciłem, gdzie zapisywaliśmy kolejne parametry i ocenialiśmy jak te parametry zadziałały. Więc zaplanowaliśmy testy i dostosowaliśmy parametry. Zapisywaliśmy historię wyników. Właśnie, żeby śledzić to, co robimy, żeby nie robić, na przykład nie zmieniać dwóch różnych parametrów naraz tylko iść po kolei. No i najważniejsze, żeby przygotować się do zawodów, czyli właśnie się wyspać, odpocząć, a niekoniecznie zarwać całą noc. Dziękuję. I za chwilę zapraszam na tor, natomiast jeszcze może są jakieś pytania.

Powiedziałeś, że nagle zaczęło działać, to był przypadkiem, czy po prostu zmieniliście jakieś parametry?

Nie no, zdecydowanie przypadek. Tak naprawdę dostosowaliśmy te parametry, bo mieliśmy tam parametrów ustawionych dobre dziesięć. Mieliśmy parametry w zależności na przykład od tej odległości w przód, przy jakiej odległości jedziemy jeszcze na przykład tą dużą prędkością średnią, czy niską. Były również parametry, jak blisko chcemy omijać zakręty. No bo mamy właśnie ten środek samochodu, a dwa, odległość od, odległość lasera od przeszkody. Więc to jest dość ważny parametr. Czyli zwiększamy prędkość, to chcemy te zakręty pokonywać z większym dystansem od przeszkód. Znaleźliśmy w ogóle w sobotę wieczorem, znaleźliśmy buga w sofcie, gdzie źle mamy liczoną odległość jakąś tam. Na pewno poprawiliśmy, natomiast w niedzielę, pierwsze co zrobiliśmy, uruchomiliśmy raz test, kompletnie nie zadziałało i zostawiliśmy to oprogramowanie i jechaliśmy na tym z błędem, bo wiedzieliśmy jak ten błąd działa. To jest dość ważne, żeby zaakceptować, prawda, tą funkcjonalność, którą znamy i już testowaliśmy wcześniej.

Bo z tego co rozumiem to też dowiedzieliście się przed zawodami, że nie będzie przeciwników. Czy macie rozwiązanie na przeszkody statyczne i dynamiczne?

A więc to co planowaliśmy do tej pory robić, to znaczy testowaliśmy nasze rozwiązanie, jak ono będzie działało przy przeszkodach. I w miarę nie było z tym problemów, natomiast nie mamy do tej pory rozpoznawania przeszkód i chcemy to zrobić, biorąc pod uwagę, że będziemy mieli lokalizację… Jeżeli będziemy mieli lokalizację to będziemy umieli stwierdzić które punky należą do toru, które punkty nie należą do toru, a też myślę, że możemy spokojnie obserwować, znając nasze położenie, możemy obserwować na bazie poprzednich skanów, co się pojawiło na torze. Mamy mapę, mamy też wiedzę… Znaczy tak, mamy, będziemy mieli, tak, mamy nadzieję. Czyli nie ma pytań? Okay. To w takim razie będziemy ruszać teraz na drugą stronę. To będzie w ramach takiej dziesięciominutowej przerwy, a później kontynuujemy.

First steps in traffic analysis – vehicle detection and simple tracking, Michał Drzał

Jako ostatni prezentował Michał Drzał, który opowiedział o swoich doświadczeniach z wykrywaniem i śledzeniem obiektów na filmach z kamer pomiaru ruchu. wykorzystał sieć neuronowa YOLO V3 i przetestował kilka różnych technik śledzenia obiektów wprost z OpenCV, a także zaimplementował jedną metodę opisaną w artykule.

Stąd możecie pobrać prezentację Michała

Nagranie z Meetupu Warsaw Self-Driving Cars

A więc tu jest całość, skrócona do 1h40min:

Transkrypcja

Nazywam się Michał, na co dzień zajmuje się robotyzacją obserwatoriów astronomicznych, to jest taka moja, że tak powiem, praca, którą wykonuję w ciągu dnia. Tak że pracuję w bydgosko-toruńskiej firmie Sybilla Technologies, tak że jeżeli tutaj szefowie będą oglądać to pozdrawiam was serdecznie. Ale wieczorami, powiedzmy, jeżeli mam chwilę wolnego czasu to zajmuję się też, powiedzmy, jak sieciami neuronowymi, z deep learningiem, no to jest, powiedzmy, ostatnio zacząłem się interesować analizą ruchu drogowego. Tutaj ludzie, prawda, w pół roku robią całkiem duże projekty. Ja się zająłem tym, powiedzmy, miesiąc temu i chciałbym pokazać moje takie pierwsze kroki z analizą ruchu drogowego. I dlaczego jestem zainteresowany tą analizą? Pierwsza rzecz to jest połączenie image processingu i uczenia maszynowego. Zawsze mnie te tematy jakoś tak interesowały. Wydaje mi się, że większość osób tutaj te tematy interesują. Druga rzecz, mój znajomy ze studiów, z którym mieszkałem, pracował w transporcie. I pewnego dnia spytał się mnie, czy można zautomatyzować zliczanie pojazdów, tak? Czyli wyobraźmy sobie sytuację, że mamy jakiś przekrój drogi i

potrzebujemy w jakiś sposób zmierzyć, ile pojazdów, przejechało przez dany przekrój drogi.

Jeżeli jeszcze jesteśmy w stanie sklasyfikować, czy to były samochody ciężarowe, czy zwykłe samochody, czy w ogóle motocykle, czy jakieś trucki to powiedzmy, tym lepiej. No a druga rzecz, jeszcze, powiedzmy, właśnie jakiś niecały miesiąc temu natrafiłem na kanał na YouTube Karola i tam zobaczyłem te sieci YOLO i RCNN i strasznie mi się spodobały. Bo generalnie to, co one robią, przynajmniej dla mnie tak z perspektywy programisty, powiedzmy, dotnetowca, który raczej na co dzień siedzi w jakichś Web serwisach i tego typu softwarze to po prostu była magia. I chciałem, powiedzmy, zrobić jakiś projekt, który będzie z tym związany. No i taki problem, który sobie postawiłem to się zastanowiłem, jak korzystając z miarę gotowych elementów, czyli powiedzmy, nie chciałbym trenować sam tej sieci, tylko powiedzmy, o ile to jest możliwe, wykorzystać jakieś gotowe wagi do detekcji i z jakichś gotowych algorytmów trackowania, czy dałoby radę z takich prefabrykatów w miarę szybko coś złożyć? Ponieważ chciałem się też trochę więcej nauczyć w tym temacie, a wydawało mi się, że jeżeli będę w stanie zrobić jakieś pierwsze proste rozwiązanie to przynajmniej będę miał motywację, żeby dalej kontynuować naukę. Więc tak to się zaczęło. No i to oczywiście powinno być proste, ponieważ, powiedzmy, mamy już sieci, które są w stanie wykrywać te obiekty.

I powiedzmy, trackowanie raczej nie powinno być trudne. Przynajmniej takie było moje początkowe nastawienie do tematu.

To akurat przykładowy kadr z tego filmu, który właśnie Karol ma na swoim kanale, tam jest w wersji surowej, można sobie ściągnąć, też można sobie zapuścić te algorytmy. No i rozwiązanie, które przetestowałem. Pierwsza rzecz, do detekcji użyłem sieci YOLO w wersji 3, o tym, dlaczego później. A jeżeli chodzi o trackowanie to jako, że chciałem skorzystać albo z prefabrykatów albo z jakichś prostych algorytmów, żeby nie było zbyt skomplikowanie, to skorzystałem najpierw z trackerów, które są od razu gotowe w OpenCV, one są dostępne w tej paczce OpenCV, trzeba jeszcze contriba dociągnąć, ale one tam są. A druga rzecz, to był taki trochę bruteforce’owy IOU tracking, ale o tym za chwilę opowiem. I tak jak powiedziałem, wszystkie te moje trackery przetestowałem na tym pojedynczym filmie i jeżeli, powiedzmy, chcielibyście troszkę bardziej profesjonalnie podejść do tematu to są, powiedzmy, całe takie zestawy benchmarkowe, jest DETRAC, też znalazłem na stronie Uniwersytetu w Brnie jakieś przykładowe zbiory danych. To co jeszcze można zrobić to można wejść na YouTube, wybrać filmy dłuższe niż dwadzieścia minut i traffic analysis i też tam trochę wyskoczy filmów, jeżeli potrzebowaliśmy czegoś do trenowania. Chciałem tu jeszcze tak szybko powiedzieć o IOU, ponieważ to jest bardzo przydatna metryczka, którą wykorzystywałem w wielu miejscach podczas tworzenia trackerów. Generalnie często potrzebujemy, mamy jakąś detekcję i zazwyczaj te detekcje będą w postaci prostokątów. I potrzebujemy mieć jakąś miarę, która nam porówna jak bardzo dwie detekcje są do siebie podobne. Oceniając tylko po prostokątach istnieje taka bardzo prosta metryka, po prostu mierzy się część wspólną i dzieli się ją przez powierzchnię sumy dwóch prostokątów. I to jest bardzo fajna metryczka, ponieważ jeżeli są rozłączne to daje nam 0. Czyli jakby podobieństwo jest zerowe. Jeżeli są, identycznie się pokrywają, są identyczne, daje nam 1. No i ładnie się skaluje, więc mamy od 0 do 1, możemy sobie mierzyć podobieństwo. Jest bardzo wygodna metryczka, polecam.

I tak, do detekcji, do detekcji użyłem YOLO w wersji 3.

Znalazłem całkiem przyjemną implementację w kerasie, do której można było ściągnąć w miarę gotowe wagi. Tam wystarczyło je troszkę przetworzyć i można było je wykorzystać. I tak, dlaczego YOLO? Wybrałem YOLO z prostego względu, w tej klasie dokładności, które, powiedzmy, oferują te sieci, on jest najszybszy. Co na laptopie, na którym, powiedzmy, odpalałem te trackery miało dosyć duże znaczenie, na mobilnej karcie graficznej. I daje bardzo dobrze rezultaty po prostu od kopa. Naprawdę byłem zaskoczony, ponieważ można tę sieć, ściągnąć wagi, uruchomić ją, odpalić na takim filmie i już będą takie naprawdę dobre detekcje. W sensie, że nie trzeba tego samemu trenować, nie trzeba mieć jakiegoś, nie wiem, osiem kart graficznych, można po prostu odpalić sobie od razu taką gotową sieć i od razu ona będzie w stanie wykrywać z całkiem niezłą dokładnością obiekty na ramce. Dlaczego, powiedzmy, z perspektywy tego, co już przetestowałem może bym nie polecał YOLO? Prostokąty, którymi zaznacza się obiekty w takich ramkach mają to ograniczenie, że po prostu próbują złapać cały obiekt. Więc jeżeli mamy obiekt, który będzie rozciągły, o właśnie w taki sposób, to dla niego zostanie wygenerowane bounding box, który będzie bardzo duży. Więc prawdopodobnie złapie nie tylko samochody, ale i sąsiednie obiekty, całą masę tła, więc pod tym względem detekcje, które dostarcza YOLO to jest, powiedzmy, mała niedogodność. I pod tym względem lepsza byłaby inna sieć, która robi podobną rzecz, Mask RCNN, ponieważ ona oprócz tego, że dostarcza bounding boxy to ona jeszcze jest w stanie na takim obiekcie narysować maskę. Powiedzmy, jeżeli tu mielibyśmy detekcję busa to po prostu by nam jeszcze tutaj ładną maskę wyrysowała dokładnie na tym busie. Znacznie precyzyjniejsza. Niestety koszt tego jest, że jest znacznie wolniejsza, więc powiedzmy, dla mnie to odpadało z perspektywy moich testów. Jeżeli chcecie jakieś porównania… i jeszcze jedna rzecz, slajdy z tego udostępnię, tu jest troszkę linków pozamieszczanych, nie musicie tego jakby na szybkości robić zdjęć, ani próbować sobie zapamiętać. Po prostu slajdy możecie sobie później przypomnieć, te linki, które tutaj podaję.

Jest porównanie szybkości YOLO z innymi architekturami,

podobnymi, tak że to możecie sobie przyglądnąć. I jeszcze takie rozwiązania, które właśnie w Uniwersytecie w Brnie stosują, to jest całkiem ciekawy pomysł, ponieważ są w stanie robić trójwymiarowe bounding boxy. Czyli mniej więcej są w stanie sobie wyznaczyć, jak powinien wyglądać trójwymiarowy bounding box dla takiego autobusu. To jest bardzo ciekawa rzecz, też polecam sprawdzić. I tak, jeżeli chodzi o trackery to chciałem sprawdzić, jak będą działały te trackery, które są dołączone do OpenCV. Wziąłem trackery, które były w takim tutorialu podane, wziąłem trzy najlepsze, które autor polepszał, to był CSRT, KCF i MOSSE. Generalnie CSRT i KCF, one są niby dokładniejsze, ale znacznie wolniejsze. A MOSSE jest taki, powiedzmy, nie do końca dokładny, ale jest bardzo szybki. Tak mniej więcej, jak się różnią. No i algorytm, który sobie wziąłem był bardzo prosty, co n ramek, mniej więcej co 5, co 6, co 7 wykonywałem detekcję, w której właśnie wykrywałem sobie te wszystkie bounding boxy, następnie pomiędzy tymi ramkami, na których robiłem detekcję, po prostu sprawdzałem, które tracki się zaczęły łączyć ze sobą. I powiedzmy, jeżeli były dwa tracki, które miały bardzo wysokie IoU to po prostu je łączyłem w jeden. I rezultat czegoś takiego, dla trackowania CSRT wygląda następująco. Widzimy, że mniej więcej jesteśmy w stanie, kolorami zaznaczamy mniej więcej ID, powiedzmy, jeżeli zmienia się kolor to prawdopodobnie zmienia się też w ID detekcji. Czyli widać na tym filmiku, że mniej więcej jesteśmy w stanie trackować i powiedzmy, identity obiektu jest zachowane między ramkami. To jest akurat na CSRT minusem, tu może jeszcze odnośnie wniosków to powiem je później. Tu mamy CSRT i następne mam jeszcze KCF. On jest bardzo podobny.

MOSSE jest ciekawy, ponieważ jest, powiedzmy, najszybszym i tak jakby najmniej dokładnym algorytmem z tej całej rodziny,

ale też jak się okazało, też całkiem nieźle ogarniał. Widać też bardzo charakterystyczne, że jeżeli mamy jakiś bounding box to on się bardzo szybko kurczy, ale powiedzmy, następny krok detekcji trochę go powiększa. Więc powiedzmy, jeżeli się zrobi detekcję co 5, powiedzmy, co 5 ramek to akurat jesteśmy w stanie tutaj nie gubić poszczególnych detekcji. Tak to wyglądało. Widzimy, że również radzi sobie, powiedzmy, z takimi mniejszymi obiektami, też jest w stanie wykrywać, powiedzmy, jak motocyklista przejeżdża. W sumie chciałem przetestować taki bardzo prosty, można powiedzieć bruteforce’owy tracker, to jest

IoU tracker, to jest tracker, który korzysta z czegoś takiego, co się nazywa tracking by detection.

Zakłada, że powiedzmy, dla każdej ramki, którą będziemy mieć w filmie, ona ma na tyle szybki detektor, że jesteśmy w stanie dla każdej ramki wygenerować detekcję. I to, co on robi to jest bardzo prosty trik, po prostu dla każdej ramki sprawdza z poprzednią IoU, dla każdego elementu. Jeżeli jest wystarczająco dużo to je matchuje. Tu jest jakby opis algorytmu. W takim, powiedzmy, pseudokodzie. No i to jest naprawdę bardzo prosty tracker. Nie ma w nim żadnej predykcji, czyli powiedzmy, jeżeli widzieliśmy, mamy jakiś track z kilku poprzednich ramek to nie próbujemy przewidzieć, gdzie będzie się znajdowało w następnej, gdzie będzie się ten bounding box znajdował w następnej ramce. To jest jakby minus tego. Ale dzięki temu jest naprawdę prosty, można go po prostu w pseudokodzie napisać w niewielkiej ilości linii kodu. I wygląda mniej więcej tak. Działa zaskakująco dobrze. Co jakiś czas będą wyskakiwać jakieś błędy. Szczególnie zwróć uwagę, jak będzie motocyklista. To też błędy, które będziecie widzieć na motocykliście są związane właśnie z tym, że motocyklista ma dosyć niewielki bounding box i zmienia się jego prędkość dosyć dynamicznie. Przez co tak jakby nie jest w stanie IoU zmatchować z poprzednią. Za chwilę się powinien pojawić motocyklista i co jakiś czas widać takie przeskoki. Ale tak jakby na tak… W motocykliście się co chwilę zmienia, te kolejne bounding boxy za mało na siebie nachodzą.

Ale i tak byłem,  dosyć pozytywnie zaskoczony, jak tak prosty algorytm, jak dobrze był w stanie sobie poradzić.

Algorytm który w ogóle nie bierze żadnych informacji z obrazka tylko porównuje same prostokąty między sobą. Tak że to też byłem pod dużym wrażeniem tego. I tak, to co się udało, tak jakby, te moje odkrycia, to tak, IoU tracker działa zaskakująco dobrze i praktycznie ma zero narzutu w porównaniu do detektora. Czyli powiedzmy, jeżeli YOLO był mi w stanie pracować z prędkością 5 fps to po prostu ten IoU tracker miał wzorowy narzut na niego. Tak że to jest duży plus, że on jest bardzo szybki. Co też zauważyłem, tutaj YOLO często posiadało takie bardzo krótkie braki w bardzo dobrych trackach. Czyli możemy mieć, powiedzmy, samochód, dla którego mamy 90 ramek, na których mamy po kolei detekcję. Będzie się zdarzało, że zwyczajnie na jednej, czy na dwóch ramkach pozostanie wykryty. Więc potrzebny jest mechanizm, który będzie pozwalał na to, że jeżeli mamy jakiś box, dla którego nie zmatchowaliśmy w jednej ramce żadnego innego to, żeby on mógł chociaż przez chwilę przetrwać. Czyli powiedzmy, to co ja dodałem do tego podstawowego trackera, do tego algorytmu, który był podany to po prostu dam ok. Jeżeli w jednej ramce nie znalazł to wytrzymaj jeszcze jedną albo dwie ramki i dopiero wtedy uznaj ścieżkę za zakończoną. To był taki bardzo prosty dodatek. I tak, i wolniejsze trackery, takie jak KCF, czy CSRT, dają gorsze fpsy niż trackowanie by detection. Czyli powiedzmy,

bardziej się opłaca dla każdej ramki odpalić sieć neuronową,

szczególnie jeśli mamy wystarczająco dużo obiektów, czyli powiedzmy, mamy 10 obiektów i dla każdego z tych obiektów musimy zainstancjonować ten tracker to bardziej się opłaca naprawdę dla każdej ramki, odpalać sieć neuronową, niż odpalać te wolniejsze trackery. Natomiast MOSSE dawało lepsze wyniki. Tak że opłaca się wziąć taki nieco gorszy, tracker z nieco gorszym accuracy, ale dostaniemy dzięki temu lepsze fpsy. I jedną rzecz, którą też zauważyłem, co na tych filmikach może nie zauważyliście, wbudowane trackery OpenCV mają problem z zauważeniem, kiedy powinny skończyć. To jeszcze cofnę się chwilkę i pokażę. Tu jest taka czarna ramka i to jest tak jakby dodatkowa informacja, że jeżeli box opuszcza tą ramkę to wtedy jest, jakby uzna za to, że on już opuścił, tak jakby, że on nie znajduje się w scenie niż, że ta ścieżka powinna się zakończyć. Ponieważ trackery, takie jak CSRT to, co one robiły to

box dochodził do krańca ekranu, samochód wyjeżdżał i ten box zostawał po prostu tutaj.

On tak jakby cały czas chciał go trackować, nawet jeżeli obiekt wystarczająco powoli się usuwał z boxem, to on stwierdzał, no okay, to teraz trackuje kawałek drogi. Tak że na to trzeba było uważać. I tak, całość kodu do tych przykładów, które zrobiłem jest dostępna tutaj w repozytorium, więc możecie sobie odpalić. Tak że to jest ten kod. Jeżeli chodzi o jakieś wnioski to tak, to podstawowe tracki można zrobić i całkiem dobrze działa, korzystając z trackera MOSSE połączonego z częstymi update’ami z YOLO. Detekcjami. Na pewno warto było by się zastanowić, że nie rozbudować tego trackera IOU, ponieważ obecnie jest naprawdę bruteforce’owy, a można by do niego dodać jakiś model ruchu, który by pozwalał na przewidywanie, gdzie powinien być następny box. Na przykład jakieś filtry, powiedzmy, żeby przewidzieć, żeby mieć jakiś model ruchu tego boxa. I to, co jest jeszcze ważne to jest reidentyfikacja obiektu po tym, jak zostanie zasłonięty przez inny obiekt. Czyli powiedzmy, jeżeli mieliśmy jakiś mały samochodzik, przyjechał przed nim szybciej autobus to żebyśmy wiedzieli, że ten samochodzik, który gdzieś tam na górze ramki pojawił się z powrotem na dole ramki, że to jest ten sam. Czyli potrzebny jest jakiś sposób na generowanie feature’ów, który by nam pozwalał na reidentyfikację obiektów. Tak.

Co będę próbował w trakcie mojej nauki tego tematu, jako następne rzeczy?

No to chciałbym dodać jakiś model trackera IOU, prawdopodobnie jakiś filtr Kalmana Chciałbym zapoznać się, czy są jakieś lepsze możliwe opisu, możliwości opisu kształtu obiektu niż dwuwymiarowe bounding boxy, ponieważ tak, jak tam pokazałem, szczególnie dla obiektów, które na tych ramkach nie są, nie są prostokątne, są właśnie bardziej rozciągłe, tak jakby wzdłuż przekątnej, te bounding boxy nie są aż tak dobrą metodą opisu. Druga rzecz, chciałbym jeszcze sprawdzić, jakie są dobre deskryptory pozwalające na reidentyfikację po tym, jak zostanie obiekt zasłonięty. Jedną z takich ciekawych rzeczy, które znalazłem, to co stosowali, to po prostu biorą z sieci neuronowych, większość tych sieci neuronowych tak jak YOLO, czy maska RCNN, one na końcu jakby mają takie gęste warstwy neuronów, tutaj jakby generował te finalnie aktywacje, aż w końcu mamy te końcowe klasy. I to widziałem, że niektórzy próbują używać to po prostu wziąć te przedostatnie warstwy i potraktować, jako feature’y i później, powiedzmy, próbować porównywać je między klatkami. I jakąś odległość między tymi aktywacjami. To jest ciekawy pomysł. No i zdecydowanie chciałbym popracować na nieco większym zbiorze danych. Tutaj wszystko testowałem na pojedynczym filmiku, wiadomo, to jest tak jakby dosyć prosty sposób testowania, ale zdecydowanie chciałbym testować na większych zbiorach takich, jak te, tak?

Kolejną rzecz, którą też chciałbym się zająć w przyszłości to przetestować sieć Superpoint,

nie wiem, czy ktoś z was słyszał o tej sieci, czy stosował? Superpointa. To jest całkiem fajna sieć, bo tutaj właśnie też na kanale u Karola jest pokazane, jak ona działa. To, co ona robi to robi tracking keypointów. SIFTa kojarzycie na pewno, generalnie jesteśmy w stanie generować jakieś punkty charakterystyczne i to, co ta sieć w stanie jest zrobić to generować te punkty charakterystyczne, do tego ma całkiem dobry point tracker. Czyli ma on tak jakby, nie trackujemy całych pojazdów tylko jakieś takie punkty charakterystyczne. I to, co stwierdziłem, że można byłoby zrobić to zacząć, powiedzmy, od śledzenia pojedynczych punktów, a później wykorzystać, jako YOLO, żeby te punkty powiązać w plastry, żeby odpowiadały pojedynczym pojazdom. Tak że to jest też coś, co chciałem przetestować. No i ostatnia rzecz, to jest powiedzmy, jakby lepsze zrozumienie systemu z vanishing pointami. To będzie przydatne szczególnie przy konstruowaniu trójwymiarowych bounding boxów. Tak że to jest wszystko z mojej strony, dzięki.

Czy robiłeś ewaluacje tych wyników? Mówisz lepsze, gorsze, a to… Procenty jakieś, czy były jakieś przeskoki pomiędzy ID, pomiędzy dwoma?

Dokładnie. Właśnie tego jeszcze nie robiłem i to jest też jedna rzecz, którą chciałbym zrobić właśnie w ramach pracowania na większych zbiorach tak, żebym był w stanie rzeczywiście w jakiś bardziej rygorystyczny sposób porównywać te rzeczy.

Nie miałeś metryki żadnej?

Tak, tak, tak. To było bardzo proste. To mówię, ja jestem dosyć zadowolony, mniej więcej dwadzieścia dni temu zacząłem wieczorami pracując nad tym. Nie chodzi o to, żeby jakoś działać tylko po prostu dopiero się uczyłem. I na przykład to, co ty mówisz, jakieś takie metryki, czy powiedzmy, zmiany ID pojazdu, powiedzmy, czy ścieżka była w większości śledzona, czy była w większości zgubiona, też właśnie między innymi, jak wpadłem na ten zbiór DETRAC to też zobaczyłem, że są porównania pomiędzy różnymi mechanizmami śledzenia. I to jest jak najbardziej jedna rzecz, którą chciałbym teraz jakby robić.

Karol Majek: Tak, to jest minus mojego zbioru danych.

Bo mój zbiór danych na razie jest przystosowany do analizy jakościowej, a nie ilościowej. Więc ilościowych to jeszcze nie możemy mieć z uwagi na to, że nie ma referencyjnych po prostu trajektorii obiektów i tak dalej. Nie jest to oznaczone ręcznie. Natomiast tak, jak kolega mówi, jest parę zbiorów danych, tam ładnych kilka, szczególnie ten, który wymienił jest bardzo ciekawy, gdzie mamy trajektorię obiektów. Czyli mamy po prostu klatka po klatce oznaczone, który obiekt jest w którym miejscu. Czy jakieś kolejne pytania?

Ja chciałem się zapytać, bo tu od początku było wspomniane zliczanie, na przykład przejeżdżających, czy już takie były te próby, ile obiektów? Tego nie widziałem. Ile, na przykład przez jakąś linię, ile z tych samochodów przejeżdża? To jest pod takim kątem, żeby na przykład próbować oszacować, jaki jest przepływ ruchu drogowego? Czy nie wiem, mi się akurat kojarzy z jakąś cieczą, szacowanie przepływu jak dla cieczy, jest, można by w kilku miejscach, bo tak jak ciecz, nagle nie pojawia się ni stąd ni zowąd. Na przykład odgałęzienia, można byłoby się, jak gdyby trochę, jak gdyby tak modelować z cieczą, porównywać, prawda? I próbować szacować taki ruch, przepływ takiego ruchu samochodowego, co zastosowanie byłoby super do optymalizacji ruchu drogowego w mieście.

Michał: Dokładnie. Powiedzmy, na tym przykładzie, co można zrobić, to postawić, wyrysować sobie linię o powiedzmy, gdzieś tutaj. I później mierzyć sobie, które kolejne ścieżki przejeżdżają przez to. To jest w pewnym sensie prostszy problem niż śledzenie, niż rysowanie ścieżki przez cały. Bo wystarczy, że zliczymy, że ten obiekt przejechał przez jakąś linię. Wtedy jakby liczenie przez przekrój jest w pewnym sensie nawet prostszym problemem niż, powiedzmy, wyznaczanie ścieżki w ramach całego, w ramach całej ramki. Też jest ciekawe zastosowanie z tą cieczą.

Czy ciężko jest znaleźć rejestrację danego samochodu i na tej podstawie przypisywać ID?

No to zależy, jak ciężko jest, to jest generalnie problem, jak to powiedzieć, bardziej jakości kamerki, prawda? Bo weźmy sobie, przykładowo jakąś jedną ramkę z filmu. Okay, dobra. Powiedzmy, mamy też tutaj, co nie? Tak, żeby… Czyli powiedzmy, mamy tutaj, tutaj wizualnie nie jesteśmy w stanie, tak? Jest pytanie, powiedzmy, jeżeli rzeczywiście robimy jakieś pomiary to jest pytanie, gdzie… Bo tu jakby w pewnym sensie tak samo, może nie powiem, że ważniejsze, ale na pewno tak samo ważne, jak same algorytmy, których używasz jest, gdzie będziesz mógł sobie położyć kamerki. Akurat znajomy pracuje bardziej w pomiarach takiego ruchu drogowego, stąd, powiedzmy, też mam trochę danych do testów. Takich, których nie mogę publicznie pokazywać. Ale generalnie jest bardzo ważne, jeżeli powiedzmy, robisz pomiary rejestracji to prawdopodobnie chciałbyś mieć, nie wiem, kamerkę, która by była, nie wiem, albo gdzieś tutaj… Znaczy najlepiej w takim miejscu, żeby nikt ci jej nie zwinął, tak? Jak zostawisz ją sobie na cały dzień. To optymalnie byłoby takie miejsce. Ale generalnie chciałbyś mieć gdzieś bardziej na poziomie ulicy, że w momencie, w którym ty będziesz widział te rejestracje to, żeby można było je zgarnąć. A do odczytania rejestracji jest trochę też jakiegoś gotowego softu. Nie pamiętam teraz nazwy bibliotek, ale też byłoby do zrobienia. Powiedzmy, to co możesz zrobić to możesz połączyć ten algorytm z tym, czyli powiedzmy, to co robisz, to ustawiasz sobie kamerkę tutaj i to, co robi YOLO to też ci zgarnia pojazdy, tylko powiedzmy, ich przody. I w momencie, w którym wiesz, że masz tutaj przód pojazdu to w tej ramce możesz zacząć szukać rejestracji.

Ale jest jeszcze prostsze rozwiązanie, jest taki hack trochę, jak oświetlisz sobie rejestrację to one świecą, jeżeli wyłączysz całe… jeśli poodświeżasz to infraredem to wtedy te rejestracje będą Ci świeciły, to jest dużo prostszy problem, bo masz dużo mniej danych. Więc to też jest taki hack.

Michał Drzał: I sobie kamerka zbiera w Infraredzie, tak?

Tak.

Może słowo komentarza, bo to jest stosowane w radarach popularnych, tak. Tylko, że wciąż jakość danych, jeśli chcemy na przykład analizację do tego podpiąć, musi być bardzo wysoka. Za to do trackingu tylko ścieżek, tak naprawdę wydaje mi się, że im bardziej pionowy rzut będzie łatwy z góry, dlatego że nas nie interesuje, co jest w środku tak naprawdę. Nie będzie okluzji i tak dalej. Im wyżej będziemy, im bardziej pionowo w dół tym powinno być łatwiej.

Michał Drzał: To tak jest najlepiej, to widok, jak w GTA 1, czy GTA 2 jest w sumie najlepszy. Też były całkiem takie przykłady, że ktoś właśnie z dronów, z dronów właśnie nagrywał. No i wtedy jest fajnie, bo to jest zero okluzji, Pojazdy nie nachodzą na siebie, po prostu ma się takie boxy, które się poruszają. To jest bajka. Tylko problem jest zazwyczaj taki przy takich nierzeczywistych pomiarach, że gdzieś tą kamerkę trzeba przyczepić. No jeżeli, powiedzmy, nie wiem, robi się to na zamówienie, czy dla jakiejś firmy, no to powiedzmy, pozwolą ci na jakiejś latarni przyczepić, tak? I powiedzmy, latarnia i ustawienie tego na drogę to jest po prostu maks, na co możesz liczyć. Tu to było nagrywane z jakiegoś mostu nad drogą, to też jest dobra pozycja. To jest bardziej ograniczenie, gdzie w ogóle można położyć tą kamerkę, tak?

Karol Majek: Coś takiego. Możemy sobie sztucznie przekształcić nasz obraz do widoku z góry. I wtedy teoretycznie możemy coś takiego zrobić, taką analizę. Oczywiście mamy artefakty, nie jest to to samo, i najlepiej, jeżeli ten odcinek drogi jest akurat prosty, to wiele ułatwia. I druga rzecz, najlepiej jak po tym moście, na którym jest kamera nie jeżdżą autobusy, tak? Bo to się wszystko trzęsie. Ale to jest kwestia założeń, bo jeżeli na słupie postawimy to znowu wiatr i tak dalej. Rzeczywiste warunki produkcyjne. Czy jeszcze pytanie?

Ja mam jeszcze jedno. Jeżeli chodzi o takie zliczanie to czemu nie zrobiliście…? W sensie jest jeszcze prostsze, są metody, tak? Kładę taki kabel i sobie wtedy, samochód ma, każdy pojazd ma dwa koła i kiedy one będą uderzały w tym samym… liczą pary kół. To jest super dokładne, jeżeli chodzi tylko o zliczanie, jeżeli nie chodzi o nic więcej.

Ale zobacz, kamera jest takim uniwersalnym interfejsem. Zrobisz soft, który działa na kamerze, bo możesz uruchomić wszędzie.

Ja to kumam, to bardzo. Tylko zastanawiam się, jeżeli to byłby jakby objective to można to zrobić jeszcze prościej.

Linie mają takie ograniczenie, że na przykład nie można, należy obniżać prędkość przejazdu przez nie. Czyli na przykład na autostradzie już tego nie zrobią.

Okay, to tego nie wiedziałem.

Michał Drzał: To znaczy w zależności, jak byś spytał mojego kolegę, który tam pracuje w transporcie i powiedzmy, tam chciałby różne rozwiązania, żeby były zrobione, czyli nie. Jeżeli pytasz mnie, to chciałem wykorzystać sieci neuronowe. To to jest ten powód taki. A jeżeli chodzi o zliczanie to prawdopodobnie jeżeli byłyby przejazdy przez przegrodę to rzeczywiście byłby najlepszy pomysł. Ale też wiem, że kolega był zainteresowany, powiedzmy, ogólnymi możliwościami. Jemu chodzi nie tylko o zliczenie ruchu drogowego, ale na przykład też go interesują piesi na przykład, jak się mogą poruszać. Czyli też, powiedzmy, zliczanie pieszych. Czyli generalnie tutaj prędzej, tak jakby korzystając z sieci neuronowych, jakbyś jego tralkowania, byłbym w stanie jakieś w miarę uniwersalne rozwiązanie zrobić niż próbować jakimiś takimi bardziej hardwareowymi metodami. A dla mnie to po prostu była ciekawa rzecz do zabawy.

Karol Majek: Pamiętajmy, że to jest taki dodatkowy projekt, z ciekawości zrobiony w bardzo krótkim czasie. Także tutaj wielki, wielki szacunek dla kolegi. Czy jeszcze mamy pytania do tego, do tej prezentacji?

Ja mam pytanie takie, czy próbowałeś robić może przemodelowanie trackera YOLO, bo on wykrywa, samo YOLO wykrywa dwadzieścia kilka klas na końcu, a tak naprawdę cztery obiekty interesują. Może byłoby jak najwygodniej trochę przemodelować. Próbowałeś coś takiego?

99% twojej sieci jest nieużywane. W tej samej cały model istnieje tylko… Naprawdę, jak się YOLO wsadzi. No to teraz pomyśl, że jeżeli jakiś procent tego, możesz więcej klatek puścić, a możesz też trochę ograniczyć , będziesz miał cztery węzły, a nie dwadzieścia pięć.

Michał: No to zdecydowanie… dzięki za sugestię. O tym w sumie po prostu nie pomyślałem.

A jakie są dalsze plany, co mieliście jeszcze wyresearchować?

Michał Drzał: Tu jest generalnie SuperPoint, to jest bardzo fajna sieć, która właśnie, jak widzicie, jest w stanie trackować i trackuje bardziej na poziomie i w sumie to mnie bardziej teraz interesuje nawet. To, co generalnie IOU trackuje to bardziej punkty charakterystyczne. I to, co pomyślałem, że można by teraz powiązać z takim kolejnym, to pewnie będzie pet project, to wykorzystać YOLO i brać detekcję. Czyli powiedzmy, że ja będę tu miał prostokąt, tu się pojawi kolejny prostokąt, żeby punkty, które występują w tym samym prostokącie, łapać je w klaster. Czyli powiedzmy, jeżeli mamy, one mają swoje ID, i ono jest zachowywane, żeby pomiędzy tymi ID, wtedy jakby zwiększać, tworzyć jakąś macierz podobieństwa i za każdym razem, kiedy one występują w jednej detekcji YOLO zwiększać im o jeden tu macierz prawdopodobieństwa. I później, powiedzmy, tworzy się nam taki właśnie graf podobieństwa, jesteśmy w tym grafie w stanie wyszukiwać, wyszukiwać, powiedzmy, jakieś klastry. I pomyślałem, że może w ten sposób dałoby radę też odtrackowanie, czyli jakby odwrócić problem. Czyli tutaj mamy trackowanie i do niego detekcję, a nie tak jakby robić trackowanie na bazie detekcji. To tak teraz myślę, że można by to wykorzystać.

To może być dla ciebie bardzo fajne rzeczywiście. Moja sugestia by była taka, że skoro masz całą kamerę to możesz pierwszą warstwę odejmować od całego materiału.

Michał: Znaczy to nie jest mój film, to jest w ogóle Karola. On po prostu odpalił tak na surowo. To co ja jeszcze robię, to może później jakoś dodłubię się do tego filmiku, ja po prostu zrobiłem coś takiego, że generalnie biorę tylko te punkty, w których jest chociażby minimalna ilość ruchu. Przez co, że tak powiem, większość tych punktów charakterystycznych odpada i zostają praktycznie tylko te ładne punkty, których jest…

Jak weźmiesz pierwszą ramkę i odejmiesz ją od całego swojego materiału to będziesz znacznie szybszy materiał. Bo masz całą kamerę. Możesz pierwszą ramkę odjąć od całej reszty materiału i podejrzewam, że będzie lepiej. Jak na zbiorach zrobisz takie substrakcje to te wszystkie rzeczy, które masz na jednej, jakby jeżeli one zostały to wiadomo, że one nie będą, w sensie one nie są istotne, bo zawsze występują. W sumie możesz sobie olać.

Karol: To co można zrobić, to w ogóle nie potrzebujemy tutaj wykrywania obiektów, bo możemy śledzić same zmiany. Tak jak Michał mi podsyłał właśnie artykuły. Bardzo żałuję, że tutaj nie wspomniał o tym, bo on sporo zrobił, jeśli chodzi o SuperPointa, więc to nie jest jedyne, co tam było. Natomiast możemy po prostu na podstawie samego structure promotion, czy czegokolwiek, co pozwoli nam wykryć ruch na podstawie poprzednich klatek, bo niekoniecznie subtrakcja pierwszej klatki jest dobra, prawda? Powiedzmy, że tej klatki wstecz i tak dalej, porównywanie, nie? Więc jeżeli będziemy oceniać sobie ruch w danym pikselu na podstawie po prostu tam poprzedniej klatki to jesteśmy w stanie bez problemu trackować. Jeżeli wyznaczymy perspektywę w jednym kierunku i w drugim kierunku, jesteśmy w stanie uzyskać trzy osie, jesteśmy w stanie zrobić trójwymiarowe bounding boxy podążające za samochodem, co właśnie…

Dobra, wiesz, czy ktoś próbował robić wykrywanie marek? Bo jakby masz te charakterystyczne punkty, często samochody jakby są definiowane przez układ lamp, tak? Więc to może być ciekawe.

Michał: To można taki patent zrobić, chyba w OpenCV są gotowe paczki, gotowe algorytmy do robienia background subtraction, czyli po prostu można tak jakby tam, gdzie się jakaś akcja dzieje, to można wyciągać te punkty, powiedzmy, to można by z SuperPointem połączyć i wtedy, powiedzmy, łapać tylko te punkty, gdzie jest jakaś akcja. Powiedzmy, w ten sposób filtrować.

Karol: A więc w tym samym artykule, właśnie a propos wykrywania tych samochodów i rysowania tych bounding boxów jest też rozpoznawanie marki, nie mylę się? Tam była jakaś Skoda, czy coś tam się udało nawet. Tak że jak najbardziej. Druga rzecz, jest też zbiór danych 196 marek samochodów, jest coś takiego. Generalnie programy są. Więc jeżeli mamy wykrycie samochodu, możemy na podstawie tego wykrycia samochodu zrobić jeszcze potem dodatkową kategoryzację, jaka to jest marka. Więc takie coś można robić jako dodatkowy krok przetwarzania. Czy to wszystkie pytania? Bardzo, bardzo dziękujemy.

Karol: Dostałem informację na temat pizzy, która miała być 15 minut temu, że będzie 20 po. Więc możemy jeszcze przejść w stronę toru albo się troszkę rozproszyć i prowadzić dyskusję w mniejszych grupach. I proponuję podziękować brawami Michałowi.
BRAWA

Karol: W planie miała być jeszcze prezentacja jedna, z Politechniki, natomiast z problemów technicznych Adam nie będzie mógł niestety zaprezentować. Tak że to była ostatnia prezentacja na dzisiaj.

Linki

• Nagranie z WSDC2 Warsaw Self-Driving Cars
•  Prezentacje:
  • Karol Majek – Self-Racing Cars 2017,2018
  • Łukasz Sztyber i Karol Majek – Doświadczenia z zawodów F1/10
  • Michał Drzał – First steps in traffic analysis – vehicle detection and simple tracking

Szczególnie chciałbym podziękować Natalii Zaborniak, która przygotowała transkrypcję tego i poprzedniego wydarzenia. Dzięki!