Pojazd sterowany — działa na radio!

Pojazd sterowany – nRF24L01

Pan Przemek oprogramował pojazd – działa przez radiówkę! Na razie sterowanie odbywa się przy pomocy 4-rech przycisków, a „grzybek” nie jest jeszcze oprogramowany. Od czegoś trzeba było zacząć 😉

Chwilowo nie zgłaszamy problemów z opóźnieniami spowodowanymi tekstowym protokołem – zobaczymy, co będzie dalej. Powyżej warsztat pracy Pana Przemka – jak widać kontroler jest minimalistyczny, a temat stworzenia fajniejszego pozostawiamy na później. Prace nad pojazdem sterowanym przez radio idą w bardzo dobrym kierunku. Za tydzień upgrade Maskotki, a potem nowe podwozie (+ modyfikacje serwomechanizmów do pracy ciągłej).

PM2D3D – małe kroczki, nowe wózki

Przełączenie sterowników silników krokowych na 1/16 kroku (poprzednio: 1/8 kroku) poskutkowało cichszą pracą, lekko wolniejszą – ale za to dokładniejszą (mniej „chwiejnych” linii). Poniżej fajny wydruk:

Dodatkowo trwają prace nad kolejną zmianą konstrukcji – nowe wózki, wydrukowane w 3D, mają zastąpić te z profili Makerbeama.  Zobaczymy co wyjdzie.


Więcej o projekcie PM2D3D na dedykowanej stronie.

(c) K.G.

Kontroler do pojazdu — tekstowy protokół

Pojazd sterowany – nRF24L01

Pan Przemek dalej kombinuje z komunikacją radiową na bazie układu nRF24. Jako nową zabawkę dostał JoyShield-a do Arduino, o takiego:

Jest to bardzo ciekawy układ, bo nie dość, że ma joystick oraz 7 przycisków (4 duże, kolorowe, jeden w joysticku, oraz 2 małe – mikrostyki), to ma jeszcze adaptery na radiówkę nRF24 (i inne też, ale tego nie tykamy). Wszystko złożone w „kanapkę” może pełnić funkcję kontrolera – po przyczepieniu bateryjki 9V (np. gumką recepturką).

Tekstowy protokół — kodowanie

Bazujemy na protokole tekstowym – shield odczytuje położenie joysticka, oraz 5 przycisków (chwilowo nie obsługujemy wszystkich). Dane wysyłane są przez nRF24 jako tekst, a poszczególne pola oddzielone są średnikiem. Jedna paczka danych wygląda więc tak:

507;512;0;1;1;0;0;

gdzie pierwsza liczba określa położenie joy-a na osi X, druga na osi Y, a kolejne zera i jedynki to stan logiczny 5-ciu przycisków. Bardzo proste w utworzeniu tego napisu — dzięki klasie String i jego licznie przeciążonych konstruktorach, oraz operatorowi „dodawania”.

#include <SPI.h>
#include <nRF24L01.h>
#include <RF24.h>
 
RF24 radio(9, 10);//CE, CS
 
uint8_t rxAddr[6] = "grzyb";
 
void setup(){
  Serial.begin(9600);
  Serial.print("nRF24 INIT=");

  bool ok=radio.begin();
  Serial.println(ok);
  radio.setRetries(15, 15);

  radio.openWritingPipe(rxAddr);  
  radio.stopListening();

  //dla modulu JoyShield
  pinMode(2, INPUT);
  pinMode(3, INPUT);  
  pinMode(4, INPUT);  
  pinMode(5, INPUT);  
  pinMode(6, INPUT); 
}
 
char bufor[32];
String napis;
 
void loop(){
  //tworzymy napis wedlug naszego protokolu 
  napis = String(analogRead(A0)) + ";" + String(analogRead(A1)) + ";" + String(digitalRead(2)) + ";" + String(digitalRead(3)) + ";" + String(digitalRead(4)) + ";" + String(digitalRead(5)) + ";"  + String(digitalRead(6)) + ";";

  //przygotowujemy bufor -- tablice z napisem...
  napis.toCharArray(bufor, 32);

  //wazne! wysylamy bufor a nie napis!
  radio.write(&bufor, sizeof(bufor));
}

Ponieważ radio wysyła dane w postaci tablicy, nie możemy wysyłać obiektu napis. Dlatego korzystamy z metody toCharArray() klasy String i przekopiowujemy zawartość napisu do bufora – tablicy. W „eter” wysyłamy tablicę bufor.

Tekstowy protokół — odczyt

No właśnie, prostota użycia napisów pociąga za sobą „problem” odczytywania takich danych. W grę wchodzą bardzo przydatne metody klasy String:

  • indexOf(napis) — zwracająca pozycję napisu w danym stringu (u nas napis to średnik, którym oddzielaliśmy liczby)
  • length() — zwracająca długość stringu
  • remove(od, do) — ucinająca napis od pozycji od do pozycji do
  • substring(od, do) — zwracająca podciąg w danym napisie, od pozycji od do pozycji do
  • toInt(napis) — zamienia napis na liczbę całkowitą (int)

Poniżej program dekodujący nasz protokół – czyli zamieniający napis na

int x,y;
byte b1,b2,b3,b4,b5;

Napis wczytany z klawiatury, przez komunikację szeregową – dzięki temu możemy testować nasz program na różne sposoby (o przeniesieniu tego kodu na radio — będzie za tydzień).

void setup() {
  //dane wprowadzamy z klawiatury przez Serial
  Serial.begin(9600);
}

String tekst;
String ciag;
char znak = ';';//separator pola
int x,y; //wspolrzedne x,y
byte b1,b2,b3,b4,b5;//stan 5 przyciskow
int k,l;//pomocnicze

unsigned long int t1,t2;

void loop() {
 if(Serial.available()>0){
    tekst=Serial.readString();
    Serial.println(tekst);

    t1=micros();
    k=tekst.indexOf(znak);
    ciag=tekst.substring(0,k);
    x=ciag.toInt();
    l=k+1;
    
    k=tekst.indexOf(znak,l);
    ciag=tekst.substring(l,k);
    y=ciag.toInt();  
    l=k+1;
    
    k=tekst.indexOf(znak,l);
    ciag=tekst.substring(l,k);
    b1=ciag.toInt();
    l=k+1;

    k=tekst.indexOf(znak,l);
    ciag=tekst.substring(l,k);
    b2=ciag.toInt();  
    l=k+1;

    k=tekst.indexOf(znak,l);
    ciag=tekst.substring(l,k);
    b3=ciag.toInt();  
    l=k+1;

    k=tekst.indexOf(znak,l);
    ciag=tekst.substring(l,k);
    b4=ciag.toInt();  
    l=k+1;

    k=tekst.indexOf(znak,l);
    ciag=tekst.substring(l,k);
    b5=ciag.toInt();  
    l=k+1;
    
    t2=micros();
    
    Serial.print("Pozycja X: ");
    Serial.println(x);
    Serial.print("Pozycja Y: ");
    Serial.println(y);
    Serial.print("PRZYCISK 1: ");
    Serial.println(b1);
    Serial.print("PRZYCISK 2: ");
    Serial.println(b2);
    Serial.print("PRZYCISK 3: ");
    Serial.println(b3);
    Serial.print("PRZYCISK 4: ");
    Serial.println(b4);
    Serial.print("PRZYCISK 5: ");
    Serial.println(b5);
    Serial.print("czas dekodowaia [mikrosekundy]= ");
    Serial.println(t2-t1);
  }//if
}//loop

Tekstowy protokół — szybkość dekodowania

Wielokrotne użycie powyższych funkcji powoduje, że odkodowanie napisu 507;512;0;1;1;0;0; i zamiana go na

int x, y;
byte b1,b2,b3,b4,b5;

zajmuje dla Arduino UNO od 260 do 550 mikrosekund (czyli ~0.5ms). A dlaczego nie jeden, równy czas? Bo w zależności od postaci dekodowanego napisu mikrokotrolerek musi więcej lub mniej pracować. Mniej „męczy” się w przypadku ciągu 1;1;1;0;0;0;0; a więcej w przypadku 1012;1017;0;0;0;1;1; Dobra, zrozumiałe. A czy to duży czas? Dla człowieka to nic, dla elektroniki sporo… Czy to nam wystarczy – czy nie spowoduje opóźnień (tzw „lagów”) w sterowaniu pojazdem? O tym przekonamy się po zastosowaniu tego protokołu do pojazdu (za tydzień).

Tekstowy protokół: modyfikacje — suma kontrolna

Można pomyśleć o rozbudowie naszego protokołu na dodatkowe „pole”, będące sumą kontrolą. Jeden z pomysłów to wysumowanie wszystkich danych (w końcu to liczby całkowite) i zapisanie tej sumy jako ostatni, dodatkowy element. Dla naszego przypadku wyglądałoby to tak: 507;512;0;1;1;0;0;1021; Po stronie odbiornika dekodujemy napis, liczymy sumę x+y+b1+b2+b3+b4+b5 i porównujemy z ostatnią wartością – nazwijmy ją sumak. A Jeśli nie ma równości… odrzucamy (ignorujemy) paczkę danych i czekamy na kolejną.

Tekstowy protokół: modyfikacje — protokół binarny

Lepiej by było stworzyć podobny protokół ale binarny, czyli nie bawić się w zapis liczb w postaci stringów, dodatkowo oddzielać je przecinkami tylko wysyłać x,y jako integer, a przyciski b1,b2,b3,b4 i b5 jako byte (nie 5 bajtów, a jeden – wszak 1 bajt = 8 bitów, mamy więc nadam zapas). Zyskujemy na tym mniejsze porcje danych – wszystkie informacje z JoyShielda to tylko 5 bajtów, a nie 14 (najlepszy przypadek) czy nawet 20 bajtów (najgorszy przypadek). No i nie ma zabawy w dekodowanie danych z wykorzystaniem metod klasy String… Ale to może przy innej okazji 😉

(c) K.G.

Processing — oscyloskop (starcie nr 2)

Oscyloskop

Kontynuujemy poznawanie processinga. Podążamy w kierunku stworzenia aplikacji, która będzie wyświetlać napięcia z portów Arduino UNO (A0, A1..A5) – czyli taki softwarowy oscyloskop. Na poprzednich zajęciach przekonaliśmy się, że wysyłanie liczb z poziomu Arduino za pomocą Serial.println(analogRead(A0)) kiepski pomysł, bo

  • każda cyfra w wysyłanej liczbie to 1 bajt, np. liczba „1017” to aż 5 bajtów (4 cyfry + znacznik końca linii)
  • jest kłopot z odczytem liczb przesyłanych jako napisy, gdyż trzeba je odczytywać jako napis (tablica znaków) a następnie zamienić napis na liczbę – skoplikowane i powolne. Bez takiej procedury odczytu liczby będą błędnie wczytywane i dodatkowo będą pojawiać się nadmiarowe liczby (śmieci) odpowiadające znacznikowi końca linii.

Dlatego też musimy zmienić sposób wysyłania liczb z Arduino – bez udziału Serial.println. 

Własny protokół

Będziemy wykorzystywać metodę Serial.write(dana) – która wysyła pojedynczy bajt przez komunikację szeregową. Nie jest wysyłany żaden znacznik końca linii, a na dodatek liczba z zakresu 0..255 wymaga wysłania tylko jednego bajta – duża oszczędność w porównaniu do Serial.println(). Z tego samego powodu liczba z przedziału 0..65535 będzie wymagać wysłania tylko 2 bajtów. Oszczędność na transmisji (a więc na szybkości!) widoczny jest od razu.

Jest jednak pewien problem – skoro wysyłamy tylko jeden bajt, bo jak wysłać liczbę typu int (czyli 2 bajty)? Przecież wyjścia analogowe w Arduino UNO są 10-cio bitowe, czyli generują liczby z zakresu 0..1023 (2 bajty = int). Rozwiązujemy to wysyłając te dwa bajty budujące liczbę typu int oddzielnie – najpierw bajt starszy, potem młodszy (za chwilę będzie to wyjaśnione). Brzmi dość zawile, ale tak nie jest – proszę przyjrzeć się poniższemu programikowi:

void setup(){
Serial.begin(9600);
}

void loop(){
  int dana = analogRead(A0);
  Serial.write( 0xff);
  Serial.write( (dana>>8) & 0xff);
  Serial.write( dana & 0xff);
}

W tym programie wysyłamy liczbę odczytaną z portu A0 Arduino jako 3 bajty – dwa bajty to ten odczyt- liczba int, ale przed nim wysyłam „flagę” informującą, że podaję właśnie liczbę typu int. Ta flaga jest potrzebna w sytuacjach, gdy z jakiegoś powodu rozsynchronizuje się nam transmisja i wówczas nie będziemy w stanie określić, który bajt jest pierwszym, a który drugim budującym liczbę typu int. Dzięki istnieniu flagi (u mnie liczby 0xff czyli 255 dziesiętnie) zawsze będziemy wiedzieć prawidłową kolejność. 

Wartość flagi nie ma znaczenia, ja wygrałem 255 – ale każdy może wpisać swoją ulubioną liczbę z przedziału 0..255 (oczywiście, gdy zmieni wartość flagi to przy odczycie liczby należy to uwzględnić).

W kodowaniu liczby posługuję się pojęciami „starszego” i „młodszego” bajtu – w końcu liczba typu int to 2 bajty (=16 bitów), więc pierwszy z nich (pierwsze 8 bitów) niech się nazywa „starszy”, a drugi (kolejne 8 bitów) – „młodszy”. Kodowanie polega na:

  • przesunięcie liczby o 8 bitów w prawo, w ten sposób mamy nową liczbę (w zapisie bitowym) jako 8-zer i 8 bitów z pierwotnej liczby, czyli tylko ten „starszy” bajt właśnie
  • iloczyn logiczny z bajtem o wartości 255 (szesnastkowo 0xff) zwróci nam właśnie ten starszy bajt – który wysyłamy przez Serial.write jako pierwszy
  • iloczyn logiczny danej liczby int bez wykonywania przesunięcia z bajtem 255 (szesnastkowo 0xff) „wycina” nam starszy bajt, pozostawiając jedynie młodszy bajt – który wysyłamy drugim poleceniem Serial.write

W ten sposób wysyłamy liczby odczytywane z portu A0 – przy czym teraz do ich oglądania nie możemy użyć Monitora portu szeregowego z Arduino IDE – gdyż zobaczymy tylko „krzaczki” (nawet bez końca linii, no chyba, że przypadkowo trafi się liczba 13 – który jest znakiem Entera). Jak więc odczytywać takie liczby? Trzeba wykonać operację odwrotną, czyli:

  1. czekać na nadejście 3 bajtów do portu szeregowego,
  2. sprawdzić, czy pierwszy z nich to nasza flaga – u nas 0xff,
  3. jeśli nie, to wracam do punktu punktu 1,
  4. jeśli jednak tak, to wczytujemy kolejny bajt, przesuwamy go w lewo o 8 bitów, robimy sumę logiczną ze wczytanym następnym bajtem,
  5. wracamy do 1. i odczytujemy kolejną liczbę.

Skomplikowane? może tak, może nie… zależy dla kogo 😉 Czy nasz protokół jest dobry? Tyle o ile… ma co prawda informację o początku liczby (to plus), ale nie ma jakiejś sumy kontrolnej, sprawdzającej poprawność wysłanej daje (to minus). Ale jest prosty i szybki (przesuwanie litów i liczenie iloczynu/sumy bitowej to „pestka”, nawet dla Arduino) – to kolejny plus, który przeważa o jego wykorzystaniu. Pamiętajmy, że zależy nam na wykreślaniu liczb z otrzymywanych z przetwornika analogowo-cyfrowego Arduino, który pracuje z częstością 10k – nadaje więc 10 000 liczb na sekundę. Sprawdziłem, że operacje kodowania liczb w naszym protokole skutkują nadawaniem około 9000 liczb na każdą sekundę, czyli całkiem dobrze.

Podsumowując: nadajemy flagę (0xff), potem starszy bajt, a potem młodszy. Ktoś może nie znać naszego protokołu i odczytywać (dobrą) flagę, a potem 2 bajty ALE myśleć, że to młodszy i starszy bajt – w odwrotnej kolejności niż my to zrobiliśmy. Więc zbudowane przez niego liczba int nie będzie tą liczbą, którą my wysłaliśmy. Chcąc uniknąć nieporozumień należałoby zaznajomić taką osobę z naszym protokołem – i teraz już rozumiemy, skąd się bierze konieczność standaryzacji w informatyce (i nie tylko).

Arduino + potencjometr

Aby mieć w pełni kontrolę nad tym, co robimy, proponuję zacząć od wysyłania liczb z portu analogowego Arduino z wykorzystaniem potencjometru – temat wielokrotnie przez nas wałkowany. Tym razem jednak nie używamy płytki stykowej i przewodów, a podłączymy potencjometr bezpośrednio do portów analogowych Arduino, o tak:

5

W ten sposób tracimy 2 porty analogowe (zamieniając ich funkcję na porty cyfrowe), a 3-ci wykorzystujemy do odczyty napięcia. Pozbywamy się konieczności stosowania płytki stykowej – coś za coś. W tym przypadku chodzi mi o maksymalne uproszczenie kwestii po stronie Arduino, a skupienie się na processingu. Dodam tylko, że na pinie A0 muszę włączyć napięcie 5V,a na pinie A4 napięcie 0V z wykorzystaniem funkcji pinMode(OUTPUT) i digitalWrite().

Skech łączący w sobie wysyłanie danych w naszym protokole ze wspomnianym „sprytnym” (ale kosztownym!) podłączeniu potencjometru:

#define OUT A2
#define POWER A0
#define GND A4

void setup() {
 Serial.begin(9600);
 pinMode(POWER, OUTPUT);
 pinMode(GND, OUTPUT);
 digitalWrite(GND, 0);
 digitalWrite(POWER, 1);
}

void loop() {
 int val=analogRead(OUT);
// Serial.println( val);
 
 Serial.write( 0xff);
 Serial.write( (val>>8) & 0xff);
 Serial.write( val & 0xff);
}

Oczywiście w przyszłości zastąpimy potencjometr jakimiś czujkami – np. pola magnetycznego, natomiast na chwilę obecną bawimy się potencjometrem (daje to nam pełną kontrolę nad kreślonym wykresem).

Processing – funkcja odczytu

Dodajemy do naszego projektu (z poprzednich zajęć) funkcję odczytu danych – uwzględniających nasz protokół

int getValue(){
 int value = -1;
 while (port.available() >= 3){
 if (port.read() == 0xff)
     value = (port.read() <<8) | (port.read()); 
 }
 return value;
}

Nazwałem ją getValue() i jak widać realizuje wspomniany wyżej sposób odczytywania liczby typu int. Najpierw czekamy na (przynajmniej) 3 bajty w buforze, potem odczytuje pierwszy porównując do flagi, a następnie tworzę liczbę typu int ze starszego i młodszego bajtu.

Wyświetlamy słupki (dane)

W głównej funkcji processinga – funkcji draw() – dodajemy rysowanie prostokąta o wysokości odpowiadającej otrzymanej liczbie z portu szeregowego. Funkcja rysująca prostokąt to rect(x0, y0, szer, wys) – gdzie para (x0,y0) to lewy-dolny wierzchołek rysowanego prostokąta, o wysokości wys i szerkości szer. Cały kod poniżej:

int xPos=0;

void draw(){
 int w=getValue(); 
 println(w);
 
 rect(xPos, height, 10, height-w);
 xPos=xPos+10;
 if (xPos>=width){
    xPos=0;
    background(0);
 }
}

Rysowanie jest bardzo prymitywne – dla każdej otrzymanej i odczytanej liczby rysuję prostokąt od dołu ekrany – czyli współrzędna lewego-dolnego rogu naszego prostkoąta to (xPos,hight). Dlaczego y-kowa współrzędna wynosi height, czyli wysokość okienka? Dzieje się tak dlatego, że układ współrzędnych w grafice processinga jest inny niż ten z lekcji matematyki/fizyki ze szkoły – o ile współrzędne x-owe rosną w prawo, to współrzędne y-kowe rosną z góry na dół, przy czym punkt (0,0) jest lewym, górnym rogiem okienka. Szerokość prostokąta ustalam na 10 punktów, a wysokość – odpowiednio do wczytanej liczby (u mnie nazwanej w). Dlatego wysokość ta wynosi height – w. Po narysowaniu zwiększam zmienną xPos w programie o 10 pikseli, by kolejny prostokąt rysował się obok tego właśnie narysowanego. Kolejna linia kodu sprawdza, czy oby nie „wyszedłem” z wartością xPos poza szerokość okienka (sprawdzam, czy xPos>width) i jeśli tak jest, to zeruję zmienną xPos i czyszczę ekran graficzny. Poniżej wynik działania programu:

oscy2

Kręcimy potencjometrem w lewo i prawo i obserujemy wykres na ekranie komputera – w sposób kontrolowany (potencjometr) wysyłamy dane do preocessinga. Widzimy, że dane większe niż 800 wylatują poza ekran – tym zajmiemy się na kolejnych zajęciach.

Ulepszenia:

Kilka rzeczy od razu przychodzi do głowy:

  • kolor słupków – może niech zależy od rysowanej wartości? w ten sposób będziemy mieć kolorowe wykresiki, a któż nie lubi kolorów 😉
  • może amiast prostokątów rysować linie? Jak wiadomo – do rysowania linii w processingu potrzebujemy współrzędnych początka (x0,y0) i końca (x1,y2). Dlatego aby to zrealizwać, musimy pamiętać wartość poprzedniej danej, a po narysowaniu linii zamienić tą wartość na aktualną.

Czego się dziś nauczyłeś

  • nowa funkcja w Arduino: Serial.write()
  • dlaczego stosujemy Serial.write() a nie Serial.println()
  • tworzenie (prostego) protokołu
  • liczba int = 2 bajty, bajt „starszy” i „młodszy”, operacje na bitach
  • processing: rysowanie prostokątów

(ciągle) pozostaje kilka kwestii do rozwiązania:

  • poprawne wczytywanie liczb (z Arduino wysyłamy 0..1023, a processing „widzi” tylko jakieś małe liczby, <30?)
  • skalowanie wykresu – czyli chcemy mieć tak, by liczby z zakresu 0..1023 zawsze mieściły się na ekranie, a nie „wyskakiwały” poza aktualną wysokość ekranu
  • ładniejsza grafika

Zapraszam na kolejne zajęcia!