diff --git a/lab04/README.md b/lab04/README.md
index eaa2e8e9839405530a3c795f9998cd6f59021218..330bafb7cf2ab2e0ec452a677aea454d23ea1575 100644
--- a/lab04/README.md
+++ b/lab04/README.md
@@ -61,7 +61,7 @@ W dowolnej chwili możemy sprawdzić aktualne przesunięcie (transformacje) pomi
 rosrun tf tf_echo <nazwa układu współrzędnych> <nazwa układu współrzędnych>
 ```
  
-@@@@@@@@@@
+![tf_echo](img/tf_echo.gif "tf_echo")
  
 ![tf_echo](img/tf_echo.png "tf_echo")
  
@@ -71,7 +71,9 @@ Program tf co sekundę pokazuje nam odległość i zmianę orientacji pomiędzy
 **Zadanie 3:** Uruchom tf_echo pomiędzy układami współrzędnych **katana_gripper_tool_frame** i **box**, a następnie ustaw końcówkę robota na tyle blisko układu współrzędnych **box**, aby odległość w żadnej osi nie przekraczała 0.2 m.
  
 -----------
- 
+
+# Odometria
+
 Przechodząc do pojazdów, standardowa struktura układów współrzędnych i ich nazewnictwo przedstawia się następująco:
  
 ![mobile_robot_standard_tf](img/mobile_robot_standard_tf.png "mobile_robot_standard_tf")
@@ -116,15 +118,20 @@ roslaunch turtlebot3_teleop turtlebot3_teleop_key.launch
  
 Przejdź do programu RVIZ, zmień ustawienie widoku na **ThirdPersonFollower**, zbliż kamerę do robota. Włącz wizualizację TF i włącz widoczność tylko następujących układów **base_link**, **base_scan**, **base_link**, **wheel_right_link**, **wheel_left_link**, **odom**. Zmniejsz rozmiar zwizualizowanych układów współrzędnych "Marker scale", tak aby nie przysłaniały modelu robota. 
  
-@@@@@@@@@
+![sim_rviz_setup](img/sim_rviz_setup.gif "sim_rviz_setup")
  
 **Zadanie 5:** Podejrzyj co dzieje się na topicu **/odom**. Obserwując robota jak i topic **/odom** przejedź około 1 m do przodu symulowanym robotem. 
  
 **Zadanie 6:** Zmień stały układ współrzędnych "Fixed Frame" z **odom** na **base_scan**. Przejedź ponownie robotem jakąś odległość w dowolnym kierunku. Jak teraz prezentowane są dane w programie RVIZ?
  
-@@@@ TU jeszcze pokazać jak układy przeskakują @@@@@
+Podczas tworzenia mapy 3d na laboratorium nr 3 mogłeś doświadczyć dopasowywania układu współrzędnych **odom** do **map**. Możesz ponieżej zobaczyć odpowiadający temu fragment mapowania. W początkowej fazie widzimy jak jedna ze ścian korytarza zbiega się do drugiej, tak jakby korytaż się zwęrzał. Na kamerze możemy zobaczyć, że algorytm widzi tylko jedną ściane. W momencie gdy na obrazie pojawiają się obie, algorytm uznaje, że znajduje się w początkowej pozycji i naprawia mapę. Tym samym zmieniając transformację pomiędzy mapą, a odometrią. Później kamery cały czas widzą znajomą przestrzeń, dlatego cały czas próbują dopasować swoją pozycję i mapę, co skrutkuje skakaniem układu współrzędnych **t265_odom_frame**
+
+![tf_jumping](img/tf_jumping.gif "tf_jumping")
  
 ------
+
+# Orientacja
+
 ![orientation](img/orientation.png "orientation")
  
 Oprócz pozycji często potrzebujemy również orientacji robota. Orientację w trzech osiach możemy uzyskać dzięki żyroskopowi, akcelerometrowi i magnetometrowi. Magnetometr jest bardzo podatny na zakłócenia, szczególnie w pomieszczeniach i wymaga dobrej kalibracji, aby działał poprawnie. Z tego powodu zwykle używa się jedynie żyroskopu i akcelerometru. Akcelerometr pozwala nam wyliczyć dokładny kąt Pitch i Roll na podstawie wektora grawitacji jednak tylko przy wolniejszych zmianach. Dzięki żyroskopowi jesteśmy w stanie natomiast nadążać, za szybkimi zmianami jednak wyliczanie orientacji na jego podstawie polega na całkowaniu prędkości kątowych w każdej osi, co skutkuje ciągle narastającym błędem. Łącząc dane z akcelerometru i żyroskopu możemy śledzić szybkie zmiany orientacji, a zarazem zniwelować narastające błędy dzięki wektorowi grawitacji, ale niestety odnosi się to tylko do kątów Roll i Pitch, ponieważ obrót w osi Z (kąt Yaw) nie wpływa na odczyt wektora grawitacji. Z tego powodu kąt Yaw uzyskuje się jedynie z żyroskopu i jest on obarczony narastającym błędem. Aby zniwelować ten błąd używa się magnetometru, który wskazuje biegun magnetyczny ziemi. Można również wykorzystać inne metody określania kąta Yaw, jak np. użycie dwóch odbiorników GPS zamontowanych na dwóch krańcach pojazdu. 
@@ -153,12 +160,12 @@ Najpierw rozpoczniemy pracę od programu QGroundControl. Zwykle używa się go p
  
 Uruchom program QGroundControl Znajdujący się na pulpicie komputera zdalnego.
  
-@@@@@@@
+![qgroundcontrol](img/qgroundcontrol.gif "qgroundcontrol")
  
 Najpierw program łączy się z kontrolerem Pixhawk i ściąga jego aktualną konfigurację. W naszym przypadku uzyskamy komunikat, iż pojazd jest nie zdolny do działania, ponieważ nie zostały podłączone kluczowe komponenty. Do prawidłowego działania potrzebne jest zdalne połączenie przez Radio RC oraz GPS. 
  
 PrzejdĹş do  widoku mapy. 
-@@@@@@
+![qgroundcontrol_map](img/qgroundcontrol_map.gif "qgroundcontrol_map")
  
 Jeśli mielibyśmy podłączony GPS, wiedzielibyśmy aktualną pozycję naszego pojazdu. W prawym górnym rogu można zauważyć kilka podstawowych parametrów jak orientacja w trzech osiach, wysokość, prędkość czy czas lotu. 
  
@@ -169,7 +176,7 @@ Możemy też dodać szybki podgląd dowolnego parametru klikając na koło zęba
  
 Parametry możemy również wyświetlać w formie wykresów, przechodząc do zakładki Analyze
  
-@@@@@@@@
+![QgroundControl_plot](img/QgroundControl_plot.gif "QgroundControl_plot")
  
 Po dodaniu Parametru do wykresu możemy zauważyć, że jego zmiany są bardzo skokowe. Jest to spowodowane małą częstotliwością wysyłania tego parametry przez kontroler. Aktualną częstotliwość odświeżania możemy zobaczyć po lewej stronie przy nazwie grupy parametrów.
  
@@ -178,16 +185,17 @@ Po dodaniu Parametru do wykresu możemy zauważyć, że jego zmiany są bardzo s
  
 Częstotliwość odświeżania możemy w ustawieniach w zakładce MAVLink:
  
-@@@@@@@@
+![QgroundControl_hz](img/QgroundControl_hz.gif "QgroundControl_hz")
 
 (Jeśli jest wyłączony to uruchom wiatrak na stronie zarządzania niniejszym laboratorium [link](), aby moduły zaczęły się poruszać)
 **Zadanie 8:** Wyświetl na wykresie trzy prędkości kątowe (xgyro, ygyro, zgyro) i zaobserwuj jak wyglądają wskazania przed zmianą i po zmianie częstotliwości odświeżania. 
 
 
  
-Ostatnim ważnym aspektem możliwość programu QGroundControl jest możliwość konfiguracji ustawień pojazdu. Poniżej zaprezentowano zmianę parametru opisującego typ używanych silników. **Umiejętność konfiguracji pojazdu będzie prawdopodobnie niezbędna przy realizacji zadań projektowych.**
+Ostatnim ważnym aspektem możliwość programu QGroundControl jest możliwość konfiguracji ustawień pojazdu. Poniżej zaprezentowano zmianę parametru opisującego typ używanych sterowników silników **MOT_PWM_TYPE**. **Umiejętność konfiguracji pojazdu będzie prawdopodobnie niezbędna przy realizacji zadań projektowych.**
+ 
  
-@@@@@@@@@
+![QgroundControl_param](img/QgroundControl_param.gif "QgroundControl_param")
  
  
 Zamknij program QGroundControl
@@ -234,7 +242,7 @@ To co pojawia się przy każdym podłączeniu nowego urządzenia do komputera to
  
 Po uruchomieniu stworzonego pliku powinno pojawić się wiele topiców udostępnionych przez mavros z danymi z naszego kontrolera. Wszystkie są opisane w [dokumntacji](http://wiki.ros.org/mavros).
  
-@@@@@@@
+![mavros_list](img/mavros_list.gif "mavros_list")
  
 Posiadając dostęp do danych możemy zająć się przedmiotem tego ćwiczenia, czyli obliczeniem orientacji naszego kontrolera, a potencjalnie robota/pojazdu. Po pierwsze potrzebne są nam dane z żyroskopu i akcelerometru. Są one dostępne na topicu **/mavros/imu/data_raw**. Wiadomości na tym topicu są typu [sensor_msgs/Imu](http://docs.ros.org/en/melodic/api/sensor_msgs/html/msg/Imu.html) i standardowo zawierają orientację (w tym przypadku jej niema ponieważ są wysyłane na tym topicu tylko dane z żyroskopu i akcelerowmetru), przyspieszenia liniowe w trzech osiach oraz prędkości kątowe w trzech osiach.
  
@@ -245,7 +253,7 @@ Przy przetwarzaniu tego typu danych ważna jest częstotliwość publikowania da
 ```bash
 rostopic hz <nazwa topicu>
 ```
-@@@@@ 
+![mavros_hz](img/mavros_hz.gif "mavros_hz")
  
 Sprawdź jak często pojawiają się wiadomości na tym topicu. Domyślnie dane wysyłane są z częstotliwością 2 Hz. Aby algorytm określający działał poprawnie potrzebujemy danych znacznie częściej. Ideałem byłyby informacje dostarczane z częstotliwością 200 Hz lub wyższą. Wtedy śledzenie orientacji byłoby bardzo płynne i pojawiałyby się mniejsze błędy. Pixhawk, z domyślnym firmwarem ardupilot rover jest w stanie wysyłać dane z sensorów z maksymalną częstotliwością ok 40 Hz. Nie jest to wartość idealna jednak już wystarczająca, aby wyznacza orientacja była użyteczna. 
  
@@ -260,7 +268,6 @@ Aby zmienić częstotliwość wysyłania surowych danych z sensorów musimy uży
 ```bash
 rosrun mavros mavsys rate --raw-sensors 40
 ```
-@@@@@@ 
  
 **Zadanie 10:** Zmień częstotliwość wysyłania danych z sensorów i sprawdź komendą ```rostopic hz```, czy dane rzeczywiście przychodzą częściej.
  
@@ -287,7 +294,7 @@ W powyższym pliku pojawiają się dwie nowe informacje. Po pierwsze możliwy je
  
 Po uruchomieniu pliku launch na topicu **/imu/data** powinny pojawić się dane tym razem wzbogacone o orientacje. Pakiet imu_tools dostarcza również plugin rozszerzający możliwość programu RVIZ o wyświetlanie orientacji obiektu. 
  
-@@@@@@
+![mavros_mad_wiz](img/mavros_mad_wiz.gif "mavros_mad_wiz")
  
 **Zadanie 11:** Uruchom filtr madgwicka plikiem launch z pakietu **laboratorium_pliki_dodatkowe** i uruchom wizualizacje w programie RVIZ. 
  
diff --git a/lab04/img/mavros_hz.gif b/lab04/img/mavros_hz.gif
new file mode 100644
index 0000000000000000000000000000000000000000..b0baa8c1fdfb782b4c1ca8ef0e8145c9c3df91de
Binary files /dev/null and b/lab04/img/mavros_hz.gif differ
diff --git a/lab04/img/mavros_list.gif b/lab04/img/mavros_list.gif
new file mode 100644
index 0000000000000000000000000000000000000000..6b5ce75203df64bbd7a3755d7c76e2521ecdc763
Binary files /dev/null and b/lab04/img/mavros_list.gif differ
diff --git a/lab04/img/mavros_mad_wiz.gif b/lab04/img/mavros_mad_wiz.gif
new file mode 100644
index 0000000000000000000000000000000000000000..b8e3b9d613d4be0b2482009c186133196591b285
Binary files /dev/null and b/lab04/img/mavros_mad_wiz.gif differ
diff --git a/lab04/img/qgroundcontrol.gif b/lab04/img/qgroundcontrol.gif
new file mode 100644
index 0000000000000000000000000000000000000000..5408aab514df12a054859fac0094a6db4d299fdb
Binary files /dev/null and b/lab04/img/qgroundcontrol.gif differ
diff --git a/lab04/img/qgroundcontrol_hz.gif b/lab04/img/qgroundcontrol_hz.gif
new file mode 100644
index 0000000000000000000000000000000000000000..d1219ae51be08826d9de1fcdb8b182a3cb936f84
Binary files /dev/null and b/lab04/img/qgroundcontrol_hz.gif differ
diff --git a/lab04/img/qgroundcontrol_param.gif b/lab04/img/qgroundcontrol_param.gif
new file mode 100644
index 0000000000000000000000000000000000000000..07852e5445c24443b41170a2790cfb97bee840f6
Binary files /dev/null and b/lab04/img/qgroundcontrol_param.gif differ
diff --git a/lab04/img/qgroundcontrol_plot.gif b/lab04/img/qgroundcontrol_plot.gif
new file mode 100644
index 0000000000000000000000000000000000000000..7756ad054b5e4955ead1b96e194859e93cd3939a
Binary files /dev/null and b/lab04/img/qgroundcontrol_plot.gif differ
diff --git a/lab04/img/sim_rviz_setup.gif b/lab04/img/sim_rviz_setup.gif
new file mode 100644
index 0000000000000000000000000000000000000000..daf01e3b2bc42990ae535782144cb820aa2c3082
Binary files /dev/null and b/lab04/img/sim_rviz_setup.gif differ
diff --git a/lab04/img/tf_echo.gif b/lab04/img/tf_echo.gif
new file mode 100644
index 0000000000000000000000000000000000000000..b17dad4c29819cbee95ba45a91fc6bb11c165de2
Binary files /dev/null and b/lab04/img/tf_echo.gif differ