diff --git a/lab04/README.md b/lab04/README.md
index 330bafb7cf2ab2e0ec452a677aea454d23ea1575..ecad669229aa3747d3dd985950b8b887c4c1c6c3 100644
--- a/lab04/README.md
+++ b/lab04/README.md
@@ -71,9 +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")
@@ -124,14 +124,14 @@ Przejdź do programu RVIZ, zmień ustawienie widoku na **ThirdPersonFollower**,
  
 **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?
  
-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**
-
+Podczas tworzenia mapy 3d na laboratorium nr 3 mogłeś doświadczyć dopasowywania układu współrzędnych **odom** do **map**. Możesz poniżej zobaczyć odpowiadający temu fragment mapowania. W początkowej fazie widzimy jak jedna ze ścian korytarza zbiega się do drugiej, tak jakby korytarz się zwężał. Na kamerze możemy zobaczyć, że algorytm widzi tylko jedną ścianę. 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 skutkuje skakaniem układu współrzędnych **t265_odom_frame** w stosunku do układu **map**
+ 
 ![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. 
@@ -186,11 +186,11 @@ 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 sterowników silników **MOT_PWM_TYPE**. **Umiejętność konfiguracji pojazdu będzie prawdopodobnie niezbędna przy realizacji zadań projektowych.**
  
@@ -260,7 +260,7 @@ Sprawdź jak często pojawiają się wiadomości na tym topicu. Domyślnie dane
 Aby zmienić częstotliwość wysyłanych danych musimy użyć komendy:
  
 ```bash
-rosrun mavros mavsys rate <nazwa grupy danych> <częstotliowść>
+rosrun mavros mavsys rate <nazwa grupy danych> <częstotliwość>
 ```
  
 Aby zmienić częstotliwość wysyłania surowych danych z sensorów musimy użyć komendy:
@@ -298,3 +298,5 @@ Po uruchomieniu pliku launch na topicu **/imu/data** powinny pojawić się dane
  
 **Zadanie 11:** Uruchom filtr madgwicka plikiem launch z pakietu **laboratorium_pliki_dodatkowe** i uruchom wizualizacje w programie RVIZ. 
  
+ 
+