W świecie inżynierii istnieje wiele doskonałych kursów, ale często program nauczania oparty na nich ma jeden poważny mankament — brak dobrej spójności między różnymi tematami. Można zapytać: jak to możliwe?
Podczas tworzenia programu nauczania dla każdego kursu określa się wymagania wstępne oraz ścisłą kolejność, w jakiej należy studiować przedmioty. Na przykład, aby złożyć i zaprogramować prymitywnego robota mobilnego, trzeba znać nieco mechaniki do stworzenia jego konstrukcji fizycznej; podstawy elektryczności na poziomie praw Ohma/Kirchhoffa, przedstawienia sygnałów cyfrowych i analogowych; operacje na wektorach i macierzach, aby opisać układy współrzędnych i ruch robota w przestrzeni; podstawy programowania na poziomie przedstawienia danych, najprostszych algorytmów oraz struktur kontroli przepływu, aby opisać jego zachowanie.
Czy wszystko to znajduje się w kursach uniwersyteckich? Oczywiście, że tak. Jednak do praw Ohma/Kirchhoffa dochodzi termodynamika i teoria pola; oprócz operacji na macierzach i wektorach trzeba mierzyć się z formami Jordana; w programowaniu badanie polimorfizmu — tematy, które nie zawsze są niezbędne do rozwiązania prostego zadania praktycznego.
Edukacja uniwersytecka jest ekstensywna — uczniowie poruszają się po szerokim spectrum i często nie dostrzegają sensu ani praktycznego znaczenia zdobywanej wiedzy. Postanowiliśmy odwrócić paradygmat uniwersyteckiego nauczania STEM (od Science, Technology, Engineering, Math) i stworzyć program, który opiera się na spójności wiedzy, umożliwiając jej rozwój w przyszłości, co oznacza intensywne przyswajanie przedmiotów.
Zgłębianie nowej dziedziny można porównać do odkrywania nowego terenu. W tej kwestii są dwie opcje: albo mamy do czynienia z bardzo szczegółową mapą pełną detali, które trzeba zrozumieć (co zajmuje dużo czasu), aby pojąć, gdzie znajdują się główne punkty orientacyjne i jak się ze sobą łączą; albo można posłużyć się prostym planem, na którym zaznaczone są tylko najważniejsze punkty i ich wzajemne położenie — taka mapa wystarczy, aby od razu zacząć poruszać się w odpowiednim kierunku, doprecyzowując szczegóły w trakcie podróży.
Koncepcję intensywnego nauczania STEM przetestowaliśmy podczas zimowej szkoły, którą zorganizowaliśmy wspólnie z studentami MIT przy wsparciu
Przygotowanie materiału
Pierwszą częścią programu szkoły był tydzień zajęć skoncentrowanych na podstawowych tematach, które obejmowały algebrę, obwody elektryczne, architekturę komputerów, programowanie w Pythonie i wprowadzenie do ROS (Robot Operating System).
Tematy zostały wybrane nieprzypadkowo: uzupełniając się nawzajem, miały pomóc studentom dostrzec powiązania między, na pozór, różnymi dziedzinami — matematyką, elektroniką i programowaniem.
Oczywiście, głównym celem nie było wygłoszenie wielu wykładów, lecz umożliwienie studentom zastosowania nowo nabytej wiedzy w praktyce.
W sekcji algebry studenci mogli ćwiczyć operacje na macierzach i rozwiązywanie układów równań, które były przydatne przy studiowaniu obwodów elektrycznych. Poznając budowę tranzystora i elementów logicznych opartych na jego zasadzie, uczniowie mogli zobaczyć ich zastosowanie w procesorze, a po zapoznaniu się z podstawami języka Python, napisali program dla rzeczywistego robota.
Duckietown
Jednym z celów szkoły było zminimalizowanie pracy z symulatorami tam, gdzie to możliwe. Dlatego przygotowano duży zestaw układów elektronicznych, które studenci mieli zmontować na płytce prototypowej z prawdziwych komponentów i przetestować je w praktyce, a jako baza dla projektów wybrano Duckietown.
Duckietown to otwarty projekt, który obejmuje niewielkie autonomiczne roboty, nazywane Duckiebot, oraz sieci dróg, po których się poruszają. Duckiebot to platforma kołowa z mikrokomputerem Raspberry Pi i jedną kamerą.
Na tej podstawie przygotowaliśmy zestaw możliwych zadań, takich jak budowa map dróg, wyszukiwanie obiektów i zatrzymywanie się w ich pobliżu, a także szereg innych. Studenci mogli również zaproponować własny problem i nie tylko napisać program do jego rozwiązania, ale także niezwłocznie uruchomić go na rzeczywistym robocie.
Nauczanie
Podczas wykładów wykładowcy przedstawiali materiał, korzystając z wcześniej przygotowanych prezentacji. Niektóre zajęcia były nagrywane na wideo, dzięki czemu studenci mieli możliwość obejrzenia ich w domu. W trakcie wykładów studenci korzystali z materiałów na swoich komputerach, zadawali pytania, wspólnie i samodzielnie rozwiązywali zadania, czasami przy tablicy. Na podstawie wyników pracy obliczono ranking każdego studenta oddzielnie w różnych przedmiotach.
Rozważmy przeprowadzenie zajęć z każdego przedmiotu bardziej szczegółowo. Pierwszym przedmiotem była algebra liniowa. Studenci w ciągu jednego dnia uczyli się o wektorach i macierzach, układach równań liniowych itd. Praktyczne zadania były realizowane w trybie interaktywnym: proponowane zadania rozwiązywano indywidualnie, a wykładowca i inni studenci udzielali komentarzy i wskazówek.
Drugim przedmiotem było elektryczność i proste układy. Studenci poznali podstawy elektrodynamiki: napięcie, prąd, opór, prawo Ohma i prawa Kirchhoffa. Praktyczne zadania częściowo wykonywano w symulatorze lub na tablicy, ale więcej czasu poświęcano budowie rzeczywistych układów, takich jak układy logiczne, obwody oscylacyjne itd.
Następnym tematem była architektura komputerów, która w pewnym sensie stanowi pomost łączący fizykę i programowanie. Studenci poznawali fundamentalną podstawę, której znaczenie jest bardziej teoretyczne niż praktyczne. W ramach praktyki studenci samodzielnie projektowali układy arytmetyczno-logiczne w symulatorze i za wykonane zadania otrzymywali punkty.
Czwarty dzień to pierwszy dzień programowania. Wybranym językiem programowania był Python 2, ponieważ jest on używany w programowaniu pod ROS. Dzień został zorganizowany w następujący sposób: nauczyciele przedstawiali materiał, podawali przykłady rozwiązywania zadań, podczas gdy studenci słuchali ich, siedząc przed komputerami, i powtarzali to, co nauczyciel napisał na tablicy lub slajdzie. Następnie uczniowie samodzielnie rozwiązywali podobne zadania, a ich rozwiązania były oceniane przez nauczycieli.
Piąty dzień był poświęcony ROS: uczestnicy zapoznawali się z programowaniem robotów. Przez cały dzień uczniowie siedzieli przed komputerami, uruchamiając kod, o którym mówił nauczyciel. Samodzielnie uruchomili podstawowe jednostki ROS i poznali projekt Duckietown. Po zakończeniu tego dnia studenci byli gotowi do przystąpienia do części projektowej szkoły — rozwiązania praktycznych zadań.
Opis wybranych projektów
Studenci zostali poproszeni o połączenie się w zespoły po trzy osoby i wybór tematu projektu. Ostatecznie przyjęto następujące projekty:
1. Kalibracja kolorów. Duckiebot wymaga kalibracji kamery przy zmianie warunków oświetleniowych, dlatego istnieje potrzeba automatycznej kalibracji. Problemem jest to, że zakresy kolorów są bardzo wrażliwe na oświetlenie. Uczestnicy opracowali narzędzie, które wyodrębniałoby na obrazie wymagane kolory (czerwony, biały i żółty) i budowało zakresy dla każdego z kolorów w formacie HSV.
2. Duck Taxi. Idea tego projektu polega na tym, aby Duckiebot mógł zatrzymać się obok jakiegoś obiektu, podnieść go i podążać określoną trasą. Wybranym obiektem był jasny żółty kaczek.
3. Budowanie grafu dróg. Istnieje zadanie zbudowania grafu dróg i skrzyżowań. Celem tego projektu jest zbudowanie grafu dróg bez dostarczania a priori danych o otoczeniu dla Duckiebot, opierając się wyłącznie na danych z kamery.
4. Samochód patrolowy. Ten projekt został wymyślony przez samych studentów. Zaproponowali, aby nauczyć jeden Duckiebot, 'patrolujący', ścigać inny — 'łamiący przepisy'. W tym celu wykorzystano mechanizm rozpoznawania celu z użyciem markeru ArUco. Gdy rozpoznawanie zostanie zakończone, 'łamiącemu przepisy' wysyłany jest sygnał o zakończeniu pracy.
Kalibracja kolorów
Celem projektu Color Calibration była korekta zakresu rozpoznawanych kolorów nawiezienia do nowych warunków oświetleniowych. Bez takich korekt rozpoznawanie linii zatrzymania, separatorów pasów i granic drogi stawało się niepoprawne. Uczestnicy zaproponowali rozwiązanie oparte na wstępnym przetwarzaniu wzorców kolorów nawiezienia: czerwonego, żółtego i białego.
Dla każdego z tych kolorów ustalono wstępny zakres wartości HSV lub RGB. Przy użyciu tego zakresu na klatce odnajdywane są wszystkie obszary zawierające odpowiednie kolory, z których wybierany jest największy. Ten obszar uznawany jest za kolor, który należy zapamiętać. Następnie stosowane są formuły statystyczne, takie jak obliczanie średniej i odchylenia standardowego, aby ocenić nowy zakres koloru.
Ten zakres zapisywany jest w plikach konfiguracyjnych kamery Duckiebota i może być użyty w przyszłości. Opisane podejście stosowane było do wszystkich trzech kolorów, co w rezultacie formowało zakresy dla każdego koloru nawiezienia.
Testy wykazały niemal idealne rozpoznawanie linii nawiezienia, z wyjątkiem przypadków, kiedy jako materiałów nawiezienia używano błyszczącej taśmy, tak mocno odbijającej źródła światła, że pod kątem widzenia kamery nawiezienie wydawało się białe, niezależnie od jego pierwotnego koloru.
Duck Taxi
Projekt Duck Taxi zakładał stworzenie algorytmu wyszukiwania w mieście kaczki-pasażera, a następnie jej transport do wymaganego punktu. Uczestnicy podzielili to zadanie na dwa: detekcja i poruszanie się po grafie.
Studenci przeprowadzili detekcję kaczki, zakładając, że kaczka to każdy obszar na klatce, który można rozpoznać jako żółty z czerwonym trójkątem (dziobem) na nim. Gdy taki obszar zostanie wykryty w kolejnej klatce, robot powinien zbliżyć się do niego, a następnie zatrzymać się na kilka sekund, naśladując lądowanie pasażera.
Następnie, mając w pamięci wcześniej wprowadzony graf dróg całego Duckietown oraz położenie bota, a także uzyskawszy jako dane wejściowe punkt docelowy, uczestnicy budują trasę z punktu startowego do punktu docelowego, wykorzystując algorytm Dijkstry do wyszukiwania ścieżek w grafie. Wyniki przedstawiane są w postaci zestawu poleceń — skrętów na każdym z kolejnych skrzyżowań.
Graf dróg
Celem tego projektu było zbudowanie grafu - sieci dróg w Duckietown. Węzłami wynikowego grafu są skrzyżowania, a krawędziami - drogi. W tym celu Duckiebot musi zbadać miasto i przeanalizować swoją trasę.
Podczas pracy nad projektem rozważono, ale następnie odrzucono pomysł stworzenia ważonego grafu, w którym koszt krawędzi określany byłby odległością (czasem przejazdu) między skrzyżowaniami. Realizacja tego pomysłu okazała się zbyt pracochłonna, a czasu brakowałoby w ramach szkoły.
Kiedy Duckiebot dociera do kolejnego skrzyżowania, wybiera drogę wychodzącą z tego skrzyżowania, po której jeszcze nie podróżował. Gdy wszystkie drogi na wszystkich skrzyżowaniach zostaną pokonane, w pamięci bota pozostaje utworzona lista sąsiedztwa skrzyżowań, która zostaje przekształcona w obraz przy pomocy biblioteki Graphviz.
Zaproponowany przez uczestników algorytm nie nadaje się do dowolnego Duckietown, ale dobrze działał w małym mieście składającym się z czterech skrzyżowań, używanym w ramach szkoły. Idee polegała na tym, aby każdy skrzyżowanie uzupełnić markerem ArUco, zawierającym identyfikator skrzyżowania, aby śledzić porządek przejazdu skrzyżowań.
Schemat działania opracowanego przez uczestników algorytmu przedstawiono na rysunku.
Samochód Patrolowy
Celem tego projektu jest poszukiwanie, ściganie i zatrzymywanie bota-złodzieja w mieście Duckietown. Bot patrolowy powinien poruszać się po zewnętrznym pierścieniu drogi w mieście w poszukiwaniu z góry znanego bota-złodzieja. Po wykryciu przestępcy, patrolowy bot powinien podążać za nim i zmusić go do zatrzymania się.
Praca rozpoczęła się od poszukiwania pomysłu na detekcję bota w kadrze i rozpoznawania go jako przestępcy. Zespół zaproponował wyposażenie każdego bota w mieście w unikalny znacznik z tyłu - podobnie jak rzeczywiste samochody mają numery rejestracyjne. W tym celu wybrano znaczniki ArUco. Były one już wcześniej używane w Duckietown, ponieważ łatwo z nimi pracować i pozwalają określić orientację znacznika w przestrzeni oraz odległość do niego.
Następnie wymagane było, aby patrolujący bot poruszał się wyłącznie po zewnętrznym okręgu bez zatrzymywania się na skrzyżowaniach. Domyślnie Duckiebot porusza się w pasie i zatrzymuje się na linii stop. Następnie za pomocą znaków drogowych określa konfigurację skrzyżowania i podejmuje decyzję o kierunku przejazdu. Za każdy z opisanych etapów odpowiada jeden ze stanów automatu stanów robota. Aby pozbyć się zatrzymań na skrzyżowaniu, zespół zmodyfikował automat stanów w taki sposób, aby przy podjeździe do linii stop bot natychmiast przechodził w stan przejazdu przez skrzyżowanie na wprost.
Kolejnym krokiem było rozwiązanie problemu zatrzymania bota-naruszyciela. Zespół założył, że patrolujący bot może mieć dostęp przez SSH do każdego z botów w mieście, to znaczy, że posiada pewne informacje o danych autoryzacyjnych oraz identyfikatorze każdego bota. W ten sposób, po wykryciu naruszyciela, patrolujący bot zaczął łączyć się przez SSH z botem-naruszycielem i wyłączał jego system.
Po potwierdzeniu, że polecenie wyłączenia zostało wykonane, patrolujący bot również się zatrzymywał.
Algorytm działania patrolującego robota można przedstawić w postaci następującego schematu:
Praca nad projektami
Praca była zorganizowana w formacie podobnym do Scrum: każdego poranka studenci planowali zadania na bieżący dzień, a wieczorem relacjonowali wykonane prace.
W pierwszy i ostatni dzień studenci przygotowali prezentacje opisujące postawione zadanie i metody jego rozwiązania. Aby pomóc studentom w realizacji wybranych planów, w pokojach, w których odbywała się praca nad projektami, na bieżąco znajdowali się nauczyciele z Rosji i Ameryki, którzy odpowiadali na pytania. Komunikacja odbywała się głównie w języku angielskim.
Wyniki i ich prezentacja
Praca nad projektami trwała tydzień, po upływie którego studenci przedstawili swoje wyniki. Wszyscy przygotowali prezentacje, w których opowiedzieli, czego się nauczyli w tej szkole, jakie były najważniejsze lekcje, które wyciągnęli, co im się podobało, a co nie. Następnie każda drużyna zaprezentowała swój projekt. Wszystkie drużyny zrealizowały postawione zadania.
Zespół zajmujący się kalibracją kolorów zakończył prace nad projektem szybciej niż inni, dzięki czemu zdążyli także przygotować dokumentację do swojego programu. Natomiast zespół pracujący nad grafem dróg nawet w ostatnim dniu przed prezentacją projektu starał się dopracować i poprawić swoje algorytmy.
Podsumowanie
Po zakończeniu szkoły poprosiliśmy uczniów o ocenę zrealizowanych aktywności i odpowiedzi na pytania dotyczące tego, jak szkoła odpowiadała ich oczekiwaniom, jakie umiejętności zdobyli itd. Wszyscy uczniowie zauważyli, że nauczyli się pracować w zespole, rozdzielać zadania oraz planować swój czas.
Uczniowie zostali również poproszeni o ocenę użyteczności i trudności odbytych kursów. I tutaj uformowały się dwie grupy ocen: dla jednych kursy nie stanowiły dużej trudności, a inni ocenili je jako maksymalnie trudne.
To oznacza, że szkoła przyjęła właściwą postawę, pozostając dostępną dla nowicjuszy w danej dziedzinie, ale także oferując materiały do powtórki i utrwalenia dla doświadczonych uczniów. Należy zauważyć, że kurs programowania (Python) został praktycznie przez wszystkich uznany za niezbyt trudny, lecz przydatny. Najtrudniejszym, zdaniem studentów, okazał się kurs "Architektura komputerów".
Kiedy studentów zapytano o wady i zalety szkoły, wielu odpowiedziało, że przypadł im do gustu wybrany styl nauczania, w ramach którego nauczyciele szybko i indywidualnie udzielali pomocy oraz odpowiadają na pojawiające się pytania.
Uczniowie zauważyli także, że podobało im się pracować w trybie codziennego planowania swoich zadań i samodzielnego ustalania terminów. Jako wady studenci wskazali brak dostarczonej wiedzy, która była potrzebna do pracy z botem: przy podłączeniu, zrozumieniu podstaw i zasad jego działania.
Praktycznie wszyscy uczniowie zauważyli, że szkoła przerosła ich oczekiwania, co świadczy o dobrze wybranym kierunku organizacji szkoły. W związku z tym należy zachować ogólne zasady przy organizacji kolejnej szkoły, biorąc pod uwagę i w miarę możliwości eliminując niedociągnięcia, które zauważyli uczniowie i nauczyciele, może zmieniając listę kursów lub czas ich nauczania.
Autorzy artykułu: zespół do
P.S. Nasz firmowy blog ma nową nazwę. Teraz będzie poświęcony projektom edukacyjnym firmy JetBrains.
Źródło: habr.com
