Maskotka – 2-gi etap

Plany z Maskotką są duże: 1) wymiana kół (co wiąże się z powiększeniem otworów w podstawie Maskotki), 2) zrobienie profesjonalnej konsoli sterującej – a wszystko to do polowy stycznia 2020. Zobaczymy 😉

Odpowiednie narzędzia to podstawa – z taką piłą to daleko nie pojedziemy…
Stare koła już odłączone i czekają na powiększne otwory… Nowa piła potrzebna! Mniejsza, zręczniejsza (bo nie chcemy wszystkiego demontować).
Konsola, w tracie projektowania. Bazujemy na projekcie edukacyjny z Amsterdamu – ale niebawem zdemontujemy wszystko i na tej podstawie zbudujemy własną (z komponentami nam potrzebnymi),

W kolejnym tygodniu wymiana kół – piłowanie nadwozia – oraz prace nad konsolą? Zobaczymy!

(c) K.G. 2019

Maskotka – reaktywacja (2-gi etap)

Pan Przemek (na moją prośbę) zabrał się za Maskotkę i wymienił w niej sterowanie: zamiast modułu Bluetooth wstawił radiówkę nRF24. Trudność polegała na zrozumieniu tego, co już zostało zrobione na płycie głównej Maskotki, co jak jest tam sterowane, co wyłączyć i co gdzie podłączyć… Udało się – moduł podłączony poprawnie, sprawdzony w działaniu z tekstowym protokołem.

Warte zapamiętania: ponieważ większości pinów na pierwszym Arduino UNO została już wykorzystana, zaszła konieczność podłączenia modułu nRF24 w dość niestandardowy sposób – pin CS radiówki został połączony z A0 Arduino. To spora rozrzutność, ale cóż zrobić, gdy nie ma już wolnych pinów cyfrowych w Arduino? Został „poświęcony” analogowy, który może działać jako cyfrowy input i właśnie działa! Potrzeba matką wynalazców 😛

W kolejnym tygodniu wymiana kół i komunikacja pomiędzy dwoma Arduino UNO w Maskotce.

(c) K.G. 2019

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.

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.

Płyta główna do Maskotki, turbina 3D, radiówka nRF24 oraz LOGO!

Chaos wewnątrz Maskotki powoli zostaje ujarzmiony… jednak to sporo pracy, ale jak na razie jest zapał! Najpierw powstał projekt płyty głównej (oczywiście po burzliwej naradzie):

..potem rozebranie działającego układu:

…ciężka praca nad modułami zasilania:

a dążymy do poskładania tego wszystkiego na jednaj płycie:

Przy okazji – co to produkcja bez znaku firmowego? Taka płyta główna powinna mieć swoje  LOGO. Więc powstał wstępny projekt, który trzeba chyba umieścić na tej dużej powierzchni właśnie tworzonej płyty głównej (w końcu ta biała przestrzeń musi być zapełniona!). Acha – wszelkie skojarzenia z logo nadgryzionego jabłka są tylko przypadkowe 😉

Ma powstać coś takiego:

Idąc słowami klasyka: nie tylko na zewnątrz ma być elegancko, wykonanie wnętrza ma być też nienaganne, estetyczne i perfekt! (kto wie o kim mówię – śmiało w komentarzach, będą nagrody!).

Natomiast Pan Łukasz i Mateusz wprowadzeni zostali w świat sieci 2.4GHz i komunikacji bezprzewodowej… Była o tym mowa w innych latach o module nRF24L, ale dla nich to nowość. OK, czekam więc na wykonanie pracy domowej (bezprzewodowa wieżyczka z laserem + protokół kompikacyjny 7-mio literowy).

Co się tyczy Dżina Stefana to pomysł przeewaluował do balona-niespodzianki, trochę bardziej militarny temat ale też z pazurem 😉 zobaczymy! Na razie Pan Bartek wydrukował wentylator do silnika bezszczotkowego, gdyż śmigła od drona były lekko przerażające (no i niebezpieczne!).

Z mocowaniem trzeba było kombinować… wychodzi na to, że trzpień silniczka ma średnicę 3.17mm, a takowego wiertła nie posiadaliśmy (mam jedynie 3.08mm). Więc otwór wyszedł lekko za duży – spytacie: „małym wiertłem? jak to?” Otóż trzeba było trochę „pogibać” aby otwór był większy 😉 no i wyszedł lekko za duży 😛 Więc na „klina” dodałem nitki… z przewodów elektrycznych (kto zdzierał izolację z przewodów ten wie, że (często) składa się on z wielu mikro-przewodów – i to właśnie je wykorzystałem). No tak, ale z taką kombinowaną produkcją nie odważyłem się zakręcić więcej niż 20%. Wiało nieźle. Dobrze mieć LEJ kierujący powietrze centralnie do góry. Wniosek z tego taki, że trzeba projektować turbinę, lej (prowadzący powietrze) a także i kratkę ochronną – przed przypadkowym oderwaniem/zerwaniem turbiny z trzpienia.

Gratuluję twórczej pracy i zapraszam na kolejne spotkanie za tydzień!

(c) K.G. 2019