Praca magisterska z robotyki to jeden z trudniejszych projektów, z jakimi mierzą się studenci inżynierii. Nie dlatego, że temat jest nieinteresujący, bo zazwyczaj jest odwrotnie. Problem tkwi w tym, że roboty łączą mechanikę, elektronikę, algorytmy i oprogramowanie w jednym miejscu, a do tego wszystkiego trzeba dołożyć sensowną strukturę naukową i napisać to po ludzku. Ten przewodnik pokazuje, jak przez to przejść bez zbędnych wykolejeni.
Jakie typy prac magisterskich dominują w robotyce
Zanim wybierzesz temat, warto wiedzieć, w jakim kierunku może pójść praca. W robotyce i systemach autonomicznych wyróżniam kilka głównych typów:
Projekt i implementacja robota – budujesz fizyczny system, opisujesz jego architekturę, testujesz w warunkach rzeczywistych. Np. mobilny robot inspekcyjny do hal magazynowych.
Algorytm sterowania – głównym wkładem pracy jest nowy lub zmodyfikowany algorytm (PID, MPC, reinforcement learning). Implementujesz go, porównujesz z benchmarkiem.
Autonomiczna nawigacja – skupia się na tym, żeby robot sam się przemieszczał w nieznanym środowisku. Często łączy SLAM z planowaniem ścieżki.
Wizja komputerowa – robot „widzi” i podejmuje decyzje na podstawie obrazu. Detekcja obiektów, segmentacja, rozpoznawanie gestów.
Manipulacja robotyczna – ramię robotyczne, chwytaki, planowanie trajektorii, współpraca człowiek-robot.
Systemy wieloagentowe – kilka robotów działających razem: roje dronów, floty AGV, koordynacja w magazynie.
Każdy z tych typów ma inną strukturę rozdziałów i inne metryki oceny. Wybierz świadomie, bo to determinuje całą resztę.
Jak wybrać temat i platformę sprzętową
Temat powinien być konkretny. „Robot autonomiczny” to za dużo. „Implementacja algorytmu SLAM opartego na ORB-SLAM3 dla robota mobilnego w środowisku biurowym z oceną dokładności odwzorowania” – to temat na pracę. Widzisz różnicę: jest metoda, jest platforma, jest środowisko, jest metryka.
Przy wyborze tematu kieruję się kilkoma pytaniami. Po pierwsze: czy masz dostęp do sprzętu? Po drugie: czy promotor zna się na tej dziedzinie? Po trzecie: czy temat da się skończyć w 12-18 miesięcy?
Popularne platformy i kiedy je wybrać
ROS 2 (Robot Operating System 2) – domyślny wybór dla większości prac. Działa na Ubuntu 22.04, wspiera C++ i Python, ma tysiące gotowych pakietów. Jeśli nie masz powodu, żeby wybrać inaczej, wybierz ROS 2 Humble lub Jazzy.
ROS 1 (noetic) – jeszcze żywy w starszych laboratoriach, ale wsparcie skończyło się w maju 2025. Jeśli możesz, przenieś projekt na ROS 2.
Gazebo / Ignition Gazebo – symulator fizyczny zintegrowany z ROS. Niezbędny, gdy nie masz fizycznego robota lub chcesz testować bez ryzyka rozbicia sprzętu za 40 000 zł.
Arduino – dla prostszych systemów wbudowanych, czujników, niskopoziomowej komunikacji. Często pojawia się jako warstwa fizyczna w systemach, gdzie wyższe obliczenia idą na Raspberry Pi lub laptopa.
Raspberry Pi 5 – dobry komputer pokładowy do prototypów. Wystarczy do uruchomienia lekkiego ROS 2, OpenCV, sterowania silnikami.
DJI SDK (dron) – jeśli pracujesz z dronami DJI (Matrice, Phantom), masz gotowy SDK do komunikacji i kontroli lotu. Uwaga: integracja z ROS wymaga dodatkowego mostu (dji-ros2-driver).
Manipulator UR (Universal Robots) – UR5e lub UR10e to standardowy sprzęt laboratoryjny. MoveIt2 obsługuje UR natywnie przez ur_ros2_driver.
Nie wybieraj najnowszej, nieudokumentowanej platformy tylko dlatego, że brzmi ekscytująco. Straciłem kiedyś 3 tygodnie na integrację sprzętu, który miał „pełne wsparcie ROS”, a dokumentacja była plikiem README z 2019 roku. Sprawdź, ile osób rzeczywiście używa danej platformy z ROS – GitHub stars to nie wszystko, liczy się aktywność issues i data ostatniego commitu.
Metodologia: rzeczywistość vs symulacja
To jeden z najczęstszych dylematów w pracach z robotyki. Krótka odpowiedź: rób jedno i drugie, jeśli możesz.
Kiedy symulacja wystarczy
Jeśli badasz algorytm nawigacji, możesz go w całości przetestować w Gazebo. Budujesz mapę środowiska (URDF + SDF), konfigurujesz czujniki (lidar 2D: Hokuyo UST-10LX lub 3D: Velodyne VLP-16), uruchamiasz algorytm. Zaletą jest powtarzalność: te same warunki za każdym razem, zero losowych awarii sprzętu.
Metryki do symulacji: RMSE pozycji (porównujesz estimated_pose z ground truth z Gazebo), czas konwergencji mapy, success rate planowania ścieżki (ile prób zakończyło się dotarciem do celu bez kolizji).
Kiedy potrzebujesz fizycznego środowiska
Jeśli Twoim wkładem jest system percepcji (kamera, lidar), symulacja zbyt mocno odbiega od rzeczywistości. Renderowane obrazy wyglądają inaczej niż rzeczywiste, szum czujników nie jest identyczny. Tutaj musisz testować na prawdziwym sprzęcie.
Typowy protokół eksperymentalny dla pracy z nawigacją w środowisku rzeczywistym:
- Minimum 10 przebiegów testowych dla każdego wariantu algorytmu
- Zdefiniowane punkty startowe i celowe (zaznaczone fizycznie taśmą na podłodze).
- Pomiar: czas przejazdu, błąd końcowy pozycji (Euclidean distance od celu), liczba kolizji lub zatrzymań awaryjnych
- Testy w różnych warunkach: przeszkody statyczne, dynamiczne (ktoś przechodzi przez scenę), różne oświetlenie
Nie testuj tylko raz i nie wybieraj najlepszego wyniku. Przemilczenie 7 nieudanych przebiegów z 10 to błąd metodologiczny, który promotor zauważy.
Metryki, których szukają recenzenci
- RMSE pozycji (m): root mean square error między odczytywaną a rzeczywistą pozycją
- MAE orientacji (rad lub stopnie): mean absolute error kąta kursu
- Success rate (%): procent zadań zakończonych sukcesem bez interwencji człowieka
- Czas wykonania (s): czas od start do cel, uśredniony po N przebiegach
- Map accuracy (dla SLAM): porównanie wygenerowanej mapy z mapą referencyjną, np. przez ICP (Iterative Closest Point) lub Hausdorff distance
Zbieraj surowe dane do plików CSV lub bag files (rosbag2). Analiza post-hoc jest znacznie łatwiejsza niż próba odtworzenia wyników z pamięci.
Wyślij fragment tekstu, bezpłatną wycenę otrzymasz w 24 h. Poprawki bez limitu w cenie usługi.
SLAM: jakie algorytmy opisywać i porównywać
Prace z autonomiczną nawigacją prawie zawsze zawierają rozdział o SLAM-ie. Oto przegląd najczęściej używanych podejść:
gmapping – klasyczny 2D SLAM oparty na particle filter. Działa z lidarem 2D, prosty w konfiguracji. Dobry jako baseline do porównań, ale na dużych mapach radzi sobie słabo.
Hector SLAM – 2D SLAM bez wymagania odometrii. Przydatny dla robotów, które trudno wyposażyć w enkodery kółek (np. MAV – micro aerial vehicles). Wrażliwy na prędkość skanowania lidara.
Cartographer (Google) – 2D i 3D SLAM, obsługuje zarówno lidary 2D jak i 3D (Velodyne). Używa graph-based optimization. Dobra dokładność, ale wymaga tuningu parametrów i mocniejszego komputera.
ORB-SLAM3 – visual i visual-inertial SLAM. Używa kamery (mono, stereo lub RGB-D) zamiast lidara. Działa w czasie rzeczywistym na CPU i GPU. Jeśli Twoja platforma ma kamerę Intel RealSense D435i lub ZED 2, to naturalny wybór.
LIO-SAM, LOAM, LeGO-LOAM – algorytmy lidar-inertial SLAM dla środowisk 3D. Wymagają drogiego lidaru 3D (Velodyne, Ouster, Livox). Dobry temat dla pracy z bardziej zaawansowanym sprzętem.
W rozdziale poświęconym SLAM opisz: zasadę działania algorytmu (wzory matematyczne, ale nie przepisuj w całości z papera), jak go skonfigurowałeś, jakie parametry były krytyczne, i jak radził sobie w Twoim środowisku testowym.
Planowanie ścieżki i sterowanie
Algorytmy planowania
A* – klasyczny, optymalny w siatkach dyskretnych. Dobry baseline. Wszyscy recenzenci go znają, więc możesz się do niego odwoływać bez szczegółowego opisu.
Dijkstra – podobny do A*, ale bez heurystyki. Wolniejszy na dużych mapach, ale w 100% optymalny.
RRT (Rapidly-exploring Random Tree) i RRT* – planowanie w przestrzeniach ciągłych i z ograniczeniami. Standardowe podejście dla manipulatorów (MoveIt2 używa RRT* przez OMPL). RRT* jest asymptotycznie optymalny, RRT nie.
MPC (Model Predictive Control) – sterowanie z horyzontem predykcyjnym. Odpowiednie dla systemów z ograniczeniami (prędkość, przyspieszenie, granice obszaru roboczego). Wymaga modelu dynamiki robota.
PID – wszechobecny regulator. Prosty, nie wymaga modelu. W robotyce mobilnej steruje różnicowym napędem. Kaskadowe PID (pozycja + prędkość) działa zaskakująco dobrze dla wielu zadań.
Pisząc o algorytmach sterowania, zawsze podaj wartości parametrów, których użyłeś (Kp, Ki, Kd dla PID; wagi macierzy Q, R dla MPC), i wyjaśnij, jak je dostrajałeś. „Parametry dobrano empirycznie” to za mało – napisz, że zacząłeś od Kp=0.5, obserwowałeś oscylacje i zmniejszyłeś do 0.3.
Wizja komputerowa w pracy magisterskiej
Detekcja obiektów
YOLOv8 / YOLOv9 (Ultralytics) – aktualny standard dla real-time object detection. Fine-tuning na własnym datasecie zajmuje od kilku godzin do 2 dni, zależnie od klasy GPU. Wyniki podajesz jako mAP50 i mAP50-95.
OpenCV – biblioteka do przetwarzania obrazów. Używana do filtrowania, transformacji, operacji morfologicznych, kalibracji kamery. W pracy z robotyką rzadko starcza sama, ale jest fundamentem pod wyższe algorytmy.
PointCloud Library (PCL) – dla chmur punktów z lidarów 3D i kamer depth (RealSense, ZED). Segmentacja płaszczyzn (RANSAC), klasteryzacja (Euclidean cluster), rejestracja chmur (ICP).
Jeśli Twoja praca dotyczy wizji, musisz opisać: kalibrację kamery (macierz K, distortion coefficients, użyj ros2 camera_calibration lub kalibr), zbiór danych (ile obrazów, jakie klasy, skąd pobrałeś lub jak annotowałeś – labelImg, Roboflow), architekturę sieci i wyniki na zbiorze testowym.
Nie uciekaj od własnych danych. Praca, w której użyłeś gotowego datasetu z COCO bez żadnego fine-tuningu, jest słabsza niż ta, gdzie zebrałeś 500 własnych zdjęć w warunkach laboratoryjnych i doszkoliłeś model.
Dokumentacja techniczna: co musi znaleźć się w pracy
Diagramy bloków i architektura systemu
Każda praca z robotyki potrzebuje diagramu architektury systemu. Pokazuje on przepływ danych: czujniki -> preprocessing -> algorytmy -> aktuatory. Rysunek w draw.io, Inkscape lub Mermaid (Markdown). Wersja exported do PDF lub PNG, nie screenshoty z ekranu.
Diagram ROS-owy (nodes i topics) możesz wygenerować automatycznie: rqt_graph w ROS 2 albo ros2 run rqt_graph rqt_graph. Eksportuj jako SVG lub PNG i wklej do pracy. To robi wrażenie i jest obiektywne.
Kinematyka i dynamika
Jeśli pracujesz z manipulatorem, rozdział o kinematyce jest obowiązkowy:
- Kinematyka prosta (forward kinematics): macierze DH (Denavit-Hartenberg), wyznaczenie pozycji end-effector na podstawie kątów przegubów
- Kinematyka odwrotna (inverse kinematics): jak z żądanej pozycji end-effector wyznaczasz kąty przegubów. Analitycznie (dla 6-DOF manipulatorów jest gotowa biblioteka ikfast) lub numerycznie (Newton-Raphson, KDL w ROS 2).
Dla robotów mobilnych: model kinematyczny (unicycle model, ackermann, differential drive), wyprowadzenie równań ruchu, ograniczenia holonomiczne/nieholonomiczne.
Nie kopiuj wzorów z Denavit (1955) bez rozumienia. Promotor zapyta, co oznacza dana litera w równaniu. Jeśli tego nie wiesz, to masz problem niezależnie od tego, jak pięknie wyglądają wzory.
Opis środowiska testowego
Podaj dokładnie: wymiary hali/pomieszczenia, rozkład przeszkód, warunki oświetlenia, temperatury (dla elektroniki na zewnątrz to ważne), rodzaj podłoża. Zdjęcie środowiska testowego w pracy to nie wstyd, to dobra metodologia.
Struktura rozdziałów pracy magisterskiej z robotyki
Typowy układ dla pracy implementacyjnej (ok. 80-100 stron):
- Wstęp (5-8 stron): motywacja, cel pracy, zakres, teza lub hipoteza badawcza, krótki opis rozdziałów
- Przegląd literatury (15-20 stron): co zrobili inni w tym obszarze, gdzie Twoja praca się wpisuje, jaką lukę wypełnia. Minimum 30-40 pozycji, z czego co najmniej połowa to artykuły z konferencji ICRA, IROS, IEEE T-RO lub RA-L (2019-2024 żeby były aktualne).
- Opis systemu / architektura (10-15 stron): sprzęt, software, diagramy
- Metody i algorytmy (15-20 stron): szczegóły techniczne, wzory, implementacja
- Eksperymenty i wyniki (15-20 stron): protokół testów, metryki, tabele porównawcze, wykresy
- Dyskusja (5-10 stron): interpretacja wyników, ograniczenia, porównanie z literaturą
- Podsumowanie (3-5 stron): co osiągnąłeś, co można zrobić dalej
- Bibliografia + Załączniki (kod, tabele surowych danych, instrukcja uruchomienia).
Jak pisać rozdział z eksperymentami
Ten rozdział decyduje o ocenie bardziej niż cokolwiek innego. Kilka zasad, które widzę u dobrych magistrantów:
Opisuj eksperymenty, które się nie udały. Promotorzy i recenzenci wiedzą, że coś zawsze nie działa. Opisanie dlaczego coś zawiodło i jak zareagowałeś to cecha dojrzałego inżyniera, nie słabość.
Tabele wyników mają mieć jednostki. „RMSE: 0.043” to bezużyteczne. „RMSE pozycji: 0.043 m (N=15 przebiegów)” – to coś znaczy.
Wykresy opisane po polsku, z legendą. Oś X: „Czas [s]”, oś Y: „Błąd pozycji [m]”. Nie wklejaj wykresów z matplotlib bez sprawdzenia, czy etykiety są czytelne w druku.
Porównanie z baseline jest obowiązkowe. Jeśli proponujesz nowy algorytm nawigacji, musisz go porównać z czymś istniejącym (DWA, TEB planner, pure pursuit). Bez tego nie ma „lepszy” ani „gorszy”.
Odchylenie standardowe lub przedziały ufności. Jeden wynik nic nie mówi. Dziesięć wyników ze średnią i odchyleniem standardowym – to jest nauka.
Opisywanie ograniczeń
Najgorszy błąd w dyskusji: udawanie, że ograniczeń nie ma. Każda praca ma ograniczenia, szczególnie w robotyce, gdzie hardware jest drogi, czas jest ograniczony, a środowisko testowe bywa sztuczne.
Napisz wprost: „System był testowany wyłącznie w środowisku laboratoryjnym na podłodze z kafelkami. Zachowanie na nierównym terenie nie jest zbadane.” Albo: „Detekcja obiektów osiąga zadowalające wyniki przy natężeniu oświetlenia powyżej 200 lux. Przy słabym oświetleniu mAP spada do 0.41, co ogranicza zastosowanie w środowiskach magazynowych bez dodatkowego oświetlenia.”
Ograniczenia sformułowane precyzyjnie pokazują, że rozumiesz swój system. To jest zaleta, nie minus.
Najczęstsze błędy w pracach z robotyki
W ciągu kilku lat pracy z magistrantami widzę te same błędy, które powtarzają się niezależnie od uczelni:
Za duży zakres pracy. „System autonomicznego robota rolniczego do zbioru truskawek z sortowaniem jakości owoców” to może i ciekawa wizja, ale nie na pracę magisterską. Zrób jedną rzecz dobrze.
Brak powtarzalnych testów. Jeden udany przebieg to demo, nie eksperyment. Minimum 10 pomiarów dla każdego wariantu.
Kopiowanie wzorów bez rozumienia. Macierze DH są wszędzie w sieci. Problem pojawia się, gdy promotor pyta: „Dlaczego wybrałeś tę konwencję DH, a nie MDH?” i nie masz odpowiedzi.
Ignorowanie ROS 2 na rzecz „własnego rozwiązania”. Widziałem prace, gdzie student napisał własny bus komunikacyjny zamiast użyć ROS topics. Stracił 4 miesiące na debugowanie tego, co ROS robi od 15 lat. Nie rób tego.
Brak wersjonowania kodu. Praca bez repozytorium git to sygnał alarmowy. Załącz link do repo w pracy (może być prywatne GitHub z dostępem dla promotora).
Za długi przegląd literatury, za krótkie eksperymenty. Obserwuję odwrotną proporcję do pożądanej: 40 stron o tym, co zrobili inni, i 8 stron własnych wyników. Powinno być odwrotnie.
Nieaktualna literatura. Praca magisterska z 2025 roku, w której przegląd literatury kończy się na 2019, budzi pytania.
Kilka słów o pisaniu
Styl techniczny to nie znaczy suchy i niezrozumiały. Pisz tak, żeby kolega z laboratoriów, który nie zna Twojego systemu, mógł to przeczytać i zrozumieć, co zrobiłeś i po co.
Unikaj zdań z siedmioma klauzulami połączonymi „który” i „gdzie”. Jedno zdanie – jedna myśl. Jeśli musisz coś wyjaśnić, zrób to w osobnym zdaniu.
Akronimy definiuj przy pierwszym użyciu: „algorytm SLAM (Simultaneous Localization and Mapping) pozwala robotowi…”. Potem możesz używać skrótu.
Rysunek jest wart tysiąca słów, ale tylko jeśli jest dobrej jakości. Pixelowy screenshot z ekranu laptopa to nie ilustracja do pracy naukowej.
FAQ: praca magisterska z robotyki
Czy muszę mieć własnego robota, żeby napisać pracę z robotyki?
Nie. Symulacja w Gazebo jest w pełni akceptowana dla wielu typów prac, szczególnie gdy badasz algorytmy. Jeśli Twoja uczelnia ma laboratoria z robotami, skontaktuj się z opiekunem i umów dostęp – większość placówek udostępnia sprzęt dla magistrantów. Praca czysto symulacyjna jest OK, o ile jasno opisujesz jej ograniczenia w kontekście real-world deployment.
Jaki język programowania wybrać: C++ czy Python w ROS 2?
Dla algorytmów wymagających niskich opóźnień (sterowanie, odczyt czujników, przetwarzanie chmury punktów): C++. Dla prototypowania, skryptów, sieci neuronowych (PyTorch, TensorFlow): Python. W typowej pracy masz mix – węzły sterowania w C++, skrypty analizy danych i trening sieci w Pythonie. ROS 2 obsługuje oba języki natywnie.
Ile stron powinna mieć praca magisterska z robotyki?
Zazwyczaj 70-120 stron bez załączników. Ważniejsza od liczby stron jest jakość: lepiej 80 stron z rzetelnymi eksperymentami niż 130 stron z rozdmuchanym przeglądem literatury i trzema testami. Pytaj promotora o wymagania uczelniane, bo różnią się między wydziałami.
Jak szybko można nauczyć się ROS 2 do pracy magisterskiej?
Podstawy (komunikacja publisher-subscriber, services, actions, launch files) opanujesz w 4-6 tygodni przy 2-3 godzinach dziennie. Polecam oficjalny tutorial ros.org (ROS 2 Humble lub Jazzy) i kurs „ROS 2 for Beginners” na Udemy. Nie zaczynaj pracy bez przejścia przez te podstawy.
Jak opisać w pracy coś, co nie zadziałało?
Wprost i rzeczowo. „Implementacja algorytmu X nie osiągnęła zakładanej dokładności z powodu Y. Zidentyfikowałem trzy możliwe przyczyny: (1)…, (2)…, (3)…. W dalszej pracy skupiłem się na podejściu Z, które wyeliminowało problem.” Takie opisy są cenione, bo pokazują, że rozumiesz swój problem, a nie tylko piszesz o sukcesach. Praca naukowa to raport z badania, nie folder marketingowy.
