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.

Salon Maturzystów Perspektywy 2019

Brawa dla Pana Bartka – autora projektu – za kolejne zmiany w sofcie (GRAPH CREATORZE) oraz w Maszynie (nowe wydruki 3D). Wszystko ukończone na pierwszą, publiczną prezentację projektu podczas Salonu Maturzystów (Kampus UwB).


Znaleźli się też ciekawscy dziennikarze (ESKA, Akadera oraz Radio Białystok) którzy bombardowali pytaniami Pana Bartka (trochę zaskoczonego, mocno speszonego)
Prezentacja Maszyny wyszła bardzo dobrze, wydruki (jak widać powyżej) fajne! Warto podkreślić, że nic nie powstało w jeden wieczór – projekt wymagał już wielu godzin pracy (ile? to nawet trudno powiedzieć samemu Autorowi…). Efekty są widoczne – praca popłaca! Szczere brawa dla Pana Bartka!

Więcej o projekcie Maszyny na stronie projektu.

(c) K.G.

Zamykanie okna processinga z potwierdzeniem – SOLVED!

Niby prosta sprawa – okienko „zapisz rysunek” przy wychodzeniu z programu processinga. Nie chcemy utracić tworzonej grafiki (problem powstał podczas tworzenia obrazów w GRAPH CREATORZE – softwarze do obsługi Wielozadaniowej maszyny 2D/3D do zadań precyzyjnych), więc musi sie pojawić dialog o zapisie/odrzeceniu tworzonej pracy. Nie wystarczyło nadpisać funkcji exit() w processingu…

Okienka w Processingu oparte są (chyba) na tzw. JFrame’ach. Aby nimi sterować musimy się dostać do obiektu odpowiedzialnego za konkretne okno w aplikacji. Na początku trzeba utworzyć uchwyt do JFrame’a:

  import javax.swing.JFrame;
  import processing.awt.PSurfaceAWT;
  ...
  PSurfaceAWT surf = (PSurfaceAWT) getSurface();
  PSurfaceAWT.SmoothCanvas canvas = (PSurfaceAWT.SmoothCanvas) surf.getNative();
  JFrame jframe = (JFrame) canvas.getFrame(); //uchwyt
  ...

Otrzymany w ten sposób uchwyt można wykorzystać do modyfikacji działania okienka, np. ustawienie czynności przy zamykaniu okna:

jframe.setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);

Po dodaniu tych linijek kodu można zauważyć, że nic się nie zmieniło. Processing również rejestruje czy użytkownik próbuje zamknąć okno i wywołuje specjalną metodę to zamykania programu: exit(). 

Teraz wystarczy tą metodę nadpisać własnym kodem aby otrzymać dialog z potwierdzeniem wyłączenia programu:

void exit(){  // nadpisanie metody exit()
    int id = showConfirmDialog(
    frame,
    "Are you sure?", // tekst okienka
    "Exiting", // tytuł okna
    YES_NO_OPTION); // opcja przycisków
    if(id == 0){ //id 0 dla przycisku “Yes”
      super.exit();
    }
}

Okienko zwróci 0 dla przycisku “Yes”, 1 dla przysku “No” oraz -1 jeżeli zamkniemy okienko dialogowe wciskając “X”. Następnie można sprawdzić wartość zmiennej “id” i wywołać nienadpisaną wersję metody exit() przy użyciu super.exit() gdy “id” wynosi 1. Wówczas Processing zajmie się resztą i zamknie aplikację.

Do działania dialogów trzeba jeszcze dodać:

import static javax.swing.JOptionPane.*; (tutaj import jako klasa statyczna?)

Całość wygląda więc tak

import javax.swing.JFrame;
import processing.awt.PSurfaceAWT;
import static javax.swing.JOptionPane.*;

void setup(){
  size(900,600);
  PSurfaceAWT surf = (PSurfaceAWT) getSurface();
  PSurfaceAWT.SmoothCanvas canvas = (PSurfaceAWT.SmoothCanvas) surf.getNative();
  JFrame jframe = (JFrame) canvas.getFrame(); //uchwyt
  jframe.setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
}
void draw(){
  rect(100,100, 200, 200);
}
void exit(){
  int id = showConfirmDialog(
    frame,
    "Are you sure?", // message
    "Exiting", // tytuł okna
    YES_NO_OPTION);
    println(id);
    if(id == 0){
      super.exit();
    }
}

I po problemie! Zachęcam do kopiowania tego rozwiząnia — (c) Bartosz Butler, 2019

Samochodzik sterowany – radiówka (nRF24L01) – oraz PM2D3D

Pojazd sterowany – nRF24L01

Pan Przemek zapoznał się z komunikacją radiową. Nadajnik i odbiornik działają, ale trzeba wysyłać konkretne dane (np. z joysticka) a nie losowe „śmieci”. Na razie powstał pomysł kodowania danych w sposób tekstowy — i pojawiły się problemy z obsługą takich „napisów”… Prace w toku 😉

Precyzyjna Maszyna (PM2D3D) – soft

Kolejne już prace nad softem – można zapisywać utworzone obrazy w GRAPH CREATORZE do plików – robi się wersja PRO 😉

Skoro jest zapis plików, to warto nie stracić swojej pracy przez nieumyślne zamknięcie programu – pojawi się stosowne okienko z potwierdzeniem (było przy tym trochę roboty, ale się udało).
Więcej o projekcie Maszyny na stronie projektu.

(c) K.G.

Błędy z biblioteką IRLib i czujka TSOP22xx — SOLVED!

Zauważyłem, że wykorzystywana biblioteka IRLib do obsługi pilotów na podczerwień MOŻE generować błędy – programy nawet się nie kompilują! Jeśli zobaczysz komunikaty o błędach w stylu:


to jest to problem z biblioteką IRLib i wersją Arduino AVR Boards. Działającym rozwiązaniem jest powrót do AVR Boards w wersji 1.6.21 (lub niższej), w której wszystko działa.

Wybierz menu Narzędzia -> Płytka -> Menadżer płytek i zmień ją (nie aktualizuj do najnowszej! no chyba, że problem jest już rozwiązany).

(c) K.G.

Samochodzik sterowany – podczerwień, TSOP – oraz PM2D3D

Pojazd sterowany – TSOP23xx

Pan Przemek uporał się z płynnym sterowaniem pojazdu (naprawa softu) – auto śmiga teraz całkiem gładko! Koła nie są uruchamiane i zatrzymywane na określony czas po wciśnięciu danego przycisku – brak efektu „czkawki”. Zamiast tego, auto zatrzymuje się gdy użytkownik zwolni przycisk na pilocie. Obsługiwane są też kody repetycji przycisku, w tym także tajemniczy kod ZERO – który pojawiał się na skutek jakiś problemów komunikacji pilota z czujką TSOP. Można więc się cieszyć, choć pilot płata figle i… mimo wszystko zrywa się komunikacja – wówczas auto się zatrzymuje (na chwilę, bo w końcu przycisk cały czas jest wciśnięty więc po chwili auto rusza). śmiało można to nazwać sukcesem. Niestety – testowy pojazd jest kiepski – 4 koła mają różne silniczki i jeden z nich działa zdecydowanie słabiej niż reszta, przez co auto marnie jeździ po podłodze (wykładzina = duże tarcie, trefne koło stoi w miejscu zamiast się kręcić). Będzie trzeba zmienić platformę (na zmodyfikowane serwomechanizmy – ale o tym za tydzień). Za tydzień też zastosowanie tej części kodu w komunikacji radiowej (lepszej niż na podczerwień).

Precyzyjna Maszyna (PM2D3D) – soft

Kolejne prace nad softem, wydruk wydaje się zachęcający 😉 Z poziomu GRAPH CREATORA można już tworzyć grafikę, która zostanie przeniesiona na kartkę papieru. Brawo!

Więcej o projekcie Maszyny na stronie projektu.

(c) K.G.

Samochodzik sterowany – podczerwień, TSOP – oraz PM2D3D

Pojazd sterowany – TSOP23xx

Pan Przemek zapoznał się z odbiornikiem podczerwieni TSOP 2230, dzięki któremu jego pojazd był sterowany bezprzewodowo. Poniżej prosty programik do dekodowania sygnałów z pilota telewizyjnego z wykorzystaniem biblioteki IRLib (do pobrania w dziale Do pobrania):

#define IR 12
#include <IRLib.h>
IRrecv pilot(IR);//pin
IRdecode dekoder;
 
void setup(){
  pilot.enableIRIn();//uruchamiamy odbiornik IR
  Serial.begin(9600);
}
 
void loop(){
   if (pilot.GetResults(&dekoder)) {
     dekoder.decode();    //dekoduj dane
     pilot.resume();     //restartuj odbiornik
     Serial.println(dekoder.value);//kody klawiszy! zanotuj je sobie....
   }//if
}/loop

Po zapisaniu sobie kodów pilota TV można zmienić program do poruszania naszym samochodzikiem – instrukcjami typu  if (dekorer.value==432421) jedz_do_przodu() — oczywiście funkcję tą należało wcześniej sobie napisać 😉

Wspólnie ustaliliśmy, że każdokrotne naciśnięcie przycisku do przodu na pilocie uruchamia silniki na zadany czas (np. 100ms) a następnie je wyłącza. Tak samo z jazdą do tyłu – włączamy odpowiednio silniki (ponownie na 100ms) a potem je wyłączamy (no i ze skrętami tak samo). Wszystko ładnie działało, ale… nie do końca. Silniki są cały czas włączane i wyłączane – a wiadomo, że prąd potrzebny na „rozruch” silnika jest znacznie większy niż podczas jego pracy ze stałą prędkością. Nie ma potrzeby je zatrzymwać, jeśli użytkownik trzyma wciśnięty dany przycisk! Dodatkowo, przy mniejszym czasie pracy silnika (nie 100ms a 50ms czy nawet 20ms) samochód miał „czkawkę” – ciągle uruchamiał i zatrzymywał silniczki. Te dwa powody były wystarczające do zmiany pierwszej wersji kodu – na bardziej zaawansowaną, która nie wyłącza silnika gdy ciągle wciskamy ten sam przycisk.  „Czkawka” została (częściowo) opanowana, ale… są błędy w kodzie 🙁 Na dodatek należy obejść (dobrze zaprogramować) błędy w komunikacji pilota na podczerwień z czujką TSOP23xx – przy trzymanym przycisku pojawia się tajemniczy kod ZERO, co przerywa pracę silników. Za tydzień się z tym uporamy!

Precyzyjna Maszyna (PM2D3D) – soft

Choć najwięcej zmian zostało w softwarze – to nastąpiła także modyfikacja konstrukcji ramy: silniki zostały przeniesione z jednej strony na przeciwne, aby zrónoważyć całą konstrukcję. Ciągle pozostaje kwestia dodania przeciwwagi po przeciwnej stronie ramy, aby nie tylko kirunek wschód-zachód był zrównoważony, ale także północ-południe. Dodatkowy ciężarek będzie pewnie w niedalekiej przyszłości, gdy powstanie panel do sterowania.

Są też anty-poślizgowe nóżki do ramy, z dodatkowymi „dociskaczami” kartki A4 (wydrukowane w 3D). Jak wspomniano, najwięcej zmian Pan Bartek wykonał w sofcie i… poprawnie rysowane są już ukośne linie! Brawo

Więcej o projekcie Maszyny na stronie projektu.

(c) K.G.

Krańcówka w PM2D3D oraz samochodzik (L293N)

Sterownik silników L293N

Pan Przemek zapoznał się z sygnałami PWM (obowiązkowy programik „gaszący” LEDa – i funkcja analogWrite) a następnie poznał sterowanie silnikami DC – za pomocą sterownika L293N. Najpierw podłączaliśmy zasilanie 6V z żelowego akumulatorka:a następnie konstrukcja uległa modyfikacji (w tym także zasilanie) i powstała taka oto platforma testowa:
Udało się „nauczyć” jeździć ten pojazd do przodu, tyłu i skręcać. Na razie wykonuje on wszystkie te czynności w kółko – więc jest to mało sensowne. Ale kolejny krok to zdalne sterowanie i ten krok to już duży krok w kierunku Wojny Robotów 😉

Precyzyjna Maszyna (PM2D3D) – krańcówka

Pan Bartek zamontował krańcówki – wydrukował odpowiednie elementy trzymające.
  Skoro są już krańcówki, to należy je oprogramować. Drogi są (co najmniej) dwie: 1) w programie realizującym poruszanie silnikami sprawdzamy, co się dzieje z krańcówkami – i w razie czego zatrzymujemy konkretny silnik, lub 2) inicjalizujemy przerwania, które robią to automatycznie. Jednak zanim doszło do tego to… pojawiły się problemy z rysowaniem linii po skosie. Przygotowany przez Pana Bartka kod miał działać – jednak okazało się, że ma wady. Wiadomo – ten się nie myli, kto nic nie robi 😉 Dlatego dzisiejsze zajęcia poszły w kierunku naprawy softwaru… Jeszcze jest trochę roboty 😉

Więcej o projekcie Maszyny na stronie projektu.

(c) K.G.

Precyzyjna Maszyna oraz RPM

Obroty na minutę: RPM (czujka pola magnetycznego SS49E)

Pan Przemek ukończył kod, który zlicza obroty wirującego silniczka – brawo! Należy się pochwała, bo to jego pierwsze zmagania z Arduino.

Układ doświadczalny:

W układzie celowo zamontowano magnesy tak, by czujka SS49E „widziała” raz biegun północny (N) magnesu, a za drugim razem (gdy silniczek obróci sie o 180 stopni) biegun południowy (S). Ustawienie magnesów na końcach patyka nie jest więc przypadkowe 😉 Czujnik SS49E odczytuje zarówno biegun S jak i N (uwaga: nie wszystkie czujki pola magnetycznego, bazującego na efekcie Halla, tak mają – warto to sprawdzić przed zakupejm), dlatego widzimy dwa „piki” podczas obracania silniczka – jeden „do góry” (większe napięcie) oraz „do dołu” (napięcie mniejsze). Z dala od magnesów czujka zwraca napięcie ~2.5V informując, że wartość pola magnetycznego jest (około) zera. Poniżej wykres z Kreślarki

Program zliczający liczbę obrotów na sekundę (zmienna czas – aktualnie 1000ms, ale można zmienić, także przez krotność – zmienna krok). Algorytm polega na znajdowaniu maksimum i minimum napięcia – a zapisywane jest moment ich wystąpienia (do zmiennych t_1oraz t_2, odpowiednio). Różnica tych czasów do pół obrotu.

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

int i,max_=518,min_=518,a=0,b=0,czas,n=0,krok=1;
float v;
long int t_1=0,t_2=0,t_k=0,t_3=0,t_p;

void loop(){
 t_p=millis();
 czas=1000;
 i=analogRead(A0);
 if(i>540){
   if(i>max_){
    max_=i;
    t_1=millis();
   }
   else if(i<max_){
    a=1;
   }
 }
 if(i<490){
   if(i<min_){
    min_=i;
    t_2=millis();  
    }
   else if(i>min_){ 
    b=1; 
  }
 }

 if(t_1>t_2){
  t_3=t_2;
 }
 else{
  t_3=t_1;
 }
 
 if(a==1&&b==1){
    t_k=abs(t_2-t_1);
    a=0;
    b=0;
    max_ = 518;
    min_ = 518;
    if(czas>t_3){
      n++;
    }
    else if(czas<t_3){
    Serial.print("Liczba pol-obrotow: ");
    Serial.println(n);
    n=0;
    krok++;
    czas=czas*krok;
    }
 }
 }

Zmienna n (małe n) zlicza wystąpienia „półobrotów”, a co ustalony czas wypisywany jest komunikat z tą liczbą. W ten sposób mamy właśnie pół-RPS (revolutions per second), z którego łatwo można już otrzymać RPM (revolutions per minute).

Precyzyjna Maszyna

Sprężynka nie wytrzymała – chyba była zbyt twarda 🙁

Nowy model powinien być lepszy – bo wydrukowany z Z-Ultratu:

No i mamy coraz lepszą pracę Maszyny:

Więcej o projekcie Maszyny na stronie projektu.

(c) K.G.