2x BT master i slave + Maskotka + RGB

Wojny robotów:

Prace podzieliły się na dwa tory – niezależnie powstaje sterowanie, niezależnie poznawane są możliwości kolorowych LED-ów WS2812B. Dzięki takiemu podziałowi projekt brnie do przodu, choć przyznać trzeba, że powstanie tylko jedno sterowanie – bez konkurencji, więc… oby było dobre 😉

BT master

Pan Rafał postanowił wykorzystać dwa moduły Bluetooth (BT) aby komunikować się pomiędzy pojazdem a kontrolerem (bez czekania na wykorzystanie radiówek nRF24L – szkoda… ale do tego pewnie jeszcze wrócimy).

Pojazd (z lewej, moduł BT MASTER) oraz „kontroler” do sterowania (z prawej, BT SLAVE)

Dotychczas to telefon z aplikacją na Androida był MASTEREM (kontrolerem) łączącym się z pojazdem, czyli BT SLAV-em. Teraz jednak używamy dwóch BT w tym celu – choć przyznać trzeba, że prościej, efektywniej i taniej wydaje się zastosowanie wspomnianych na wstępie modułów nRF24L.

Kontroler ma podłączony moduł JOY-stica oraz moduł BT, który wysyła odczyty. Odbiorcą tych pakietów jest moduł BT w pojeżdzie, który łączy się z naszym kontrolerem. Aby to było możliwe należy MASTERA skonfigurować tak, aby po jego uruchomieniu „szukał” kontrolera i się z nim łączył. Realizuje się to przez tryb komend AT.

W tym celu podłączamy BT z dodatkowym pinem ustawionym na HIGH (poniżej pin #6 z Arduino, nazwany KEY, połączony z pinem STATUS w module XM-15B) i programikiem według poniższego schematu:

Wejście w tryb komend AT.

Jak widać program czyta bajty z portu szeregowego PC-ta i wysyła je do modułu BT podłączonego do Arduino (metody readString() oraz write()). Sprawdzamy, czy mamy wszystko poprawnie działające wywołując komendę AT+NAME. Powinna pojawić się nazwa naszego modułu (uwaga: nawet niepoprawnie wyświetlona) ORAZ nowa linia z napisem OK. Jeśli tak nie jest, trzeba sprawdzić podłączenia.

Moduł BT w trybie komend AT. Zwróć uwagę na znacznik końca linii: NL+CR.

Tryb komend AT umożliwia nam zmianę nazwy urządzenia BT, zmianę hasła czy innych parametrów komunikacji (np. szybkość transmisji szeregowej). Ale my wykorzystujemy go najpierw do odczytania numeru identyfikacyjnego urządzenia BT SLAVE – naszego kontrolera. Parowanie urządzeń BT odbywa się przez ten numer (a nie przez przyjazne nazwy, jak w Androidzie). Wydajeny komendę AT+ADDR i mamy odpowiedź: u nas 001135938823. Teraz wychodzimy z tryb AT dla kontrolera (BT SLAVE) i wgrywamy ten sam program na Arduino z BT MASTEREM.

Pojazd (BT MASTER) ma się łączyć z konkretnym modułem BT – znamy jego ID. Musimy więc najpierw ustawić go w tryb MASTER-a (komenda AT+ROLE zwróci 0 gdy moduł jest SLAVE-em, a 1 gdy MASTER-em; zmiana trybu odbywa się komendą AT+ROLE=1). Następnie zapisujemy adres kontrolera poleceniem AT+BIND=001135938823. Teraz można już wyłączyć program dla modułów BT pracujących w trybie AT i wgrać nasz własny programik na Arduino, które przez UART będzie odczytywać dane przesyłane przez kontroler modułami BT (oczywiście – jeśli włączymy pojazd, a kontroler nie będzie włączony – nie nastąpi komunikacja i pojazd nie będzie otrzymywać instrukcji sterująych).

Kto ma być MASTER, kto ma być SLAVE?

Pan Rafał zdecydował, że kontroler będzie SLAVE, a pojazd MASTEREM. Czy to dobrze? Można było by zrobić na odwrót… I takie właśnie rozwiązanie jest chyba lepsze, bo pojazd jako SLAVE czeka na dane wysyłane przez… dowolne sparowane urządznie! Może to być dedykowany kontroler (który właśnie tu powstaje) ale także jakaś apka na Androidzie – wówczas telefon jako MASTER może sterować naszym pojazdem. Takie rozwiązanie jest bardziej uniwersalne, więc pewnie w przyszłości będzie zastosowane.

Można też zajrzeć do opisu łączenia modułów BT master <-> slave na tej stronie – polecam.

WS2812B

Pan Tomasz postawił sobie zadanie płynnego przejścia kolorów: od niebieskiego do czerwonego w module WS2812B. Te dwa kolory mają być odpowiedzialne za wartości odczytanego pola magnetyczna magnesu. Zapis kolorów w systemie RGB nie jest tutaj najwygoniejszy, więc wybór padł na zastosowanie modelu HSV.

Model kolorów RGB. Przejście od czerwieni do niebieskiego to jednoczesna zmiana dwóch amplitud kolorów: R i B.
Model kolorów HSV. Droga od czerwieni do niebieskiego to zmiana jednego parametru – „kąta”, czyli wartości H.

Więcej…

Fajny link: https://www.arduinoslovakia.eu/blog/2018/4/neopixel-ring-hsv-test?lang=en

Maskotka – sterowanie.

Sam PID nie wystarczył. Moduł JOY-sticka ma mechaniczną „wadę”, że wychyla się góra/dół (lewo/prawo) mniej niż „pod kątem”. Maksymalne odczyty (1023 w przypadku Arduino UNO) otrzymuje się przy skrajnym wychyleniu w górę/prawo (dół/lewo) ale wychylając joy „po skosie” mamy (teoretycznie) o pierwiastek z dwóch więcej! Dlatego też to właśnie wychylenia „pod kątem” mają wartości 1023 a skrajne pionowe/poziome uzyskują te wartości jeszcze przed swoim maksymalnym wychyleniem – dalsze wychylanie nic już nie daje (mamy ciągle 1023 – zakres ruchu joya „zmarnowany”). Aby to zniwelować Pan Bartek znalazł ciekawe mapowanie kwadratu na kółko:

Odwzorowanie kwadratu na okrąg (kliknij obrazek aby przejść do źródła).

Taka modyfikacja sterowania pozytywnie wpłynęła na kontrolowanie Maskotki. Gratulacje!

Kolejne spotkanie: czwartek 6 maj 2021, godz. 15:15.

Wojny robotów („kanapka”) + problem: BT + serwo

Wojny robotów: problem – serwa i Bluetooth (BT)

Pan Rafał oprogramowywał sterowanie swojej „kanapki” z wykorzystaniem modułu BT. Nie jest to może najlepsze rozwiązanie sterowania, ale szybkie i bezproblemowe (jasne, jasne – czytaj dalej). Proste, po włączamy dwie standardowe biblioteki Servo.h oraz SoftwareSerial.h i piszemy prosty kod.

#include <Servo.h>
#include <SoftwareSerial.h>

SoftwareSerial bt(8, 9);//RxD, TxD
Servo silnik;

void setup() {
  Serial.begin(9600);
  bt.begin(9600);
  silnik.attach(3);
  Serial.println("start!");
}

void loop() {
  if (bt.available()){
    char komenda=bt.readString());
    Serial.print("odebrano= ");
    Serial.println(komenda);//dla sprawdzenia

    switch (komenda){
      case 'W': silnik.writeMicroseconds(1000); break;  //przod
      case 'S': silnik.writeMicroseconds(2000); break;  //tyl
      case 'X': silnik.writeMicroseconds(1500); break;  //stop
    }//switch
}

A tu klops! Ilekroć przesyłane są dane przez moduł BT, to serwa „wariują”, zachowują się zupełnie nieoczekiwanie. Można to sprawdzić powyższym kodem gdzie przesyłamy 'W’ przez Bluetooth i silnik kręci się na maksa do przodu, a następnie wysyłamy z apki kolejne, nic nie znaczące znaczki (wciskamy inne, zdefiniowane przyciski, np. 'A’, 'D’ itd). Te komendy powinny zostać zignorowane (brak odpowiednich instrukcji w switch-u), a serwo powinno utrzymywać swój dotychczasowy ruch. Tak się jednak nie dzieje…

Jak zawsze najpierw należało sprawdzić przewody połączeniowe, ale to nie one okazały się przyczyną problemów. Grzebanie w internecie okazało się sukcesem – biblioteka SoftwareSerial.h korzysta z tego samego układu czasowego (timera) w Artudino co biblioteka Servo.h, do sterowania PWM. Chodzi o to, ze Arduino (a dokładniej ATmega 328P) posiada trzy niezależne timery: dwa 8-bitowe oraz jeden 16-to bitowy. Właśnie z tego ostatniego korzystają dwie wspomniane biblioteki i powstaje konflikt!

Rozwiązaniem może być alternatywna biblioteka do obsłui serw: ServoTimer2. Już sama nazwa wskazuje, że korzysta ona z drugiego timera – nie powinno być więc konfliktu z SoftwareSerial.h. Lekko zamieniamy kod programiku i sprawdzamy zachowanie serw podczas przesyłania danych z BT. Klops: jednak nie pomogło.

Jeśli nie biblioteka serw, to szukamy zamiennika do drugiej biblioteki – komunikacji szeregowej. Tutaj trafiamy na AltSoftSerial i nasze nadzieje nie gasną 😉 Ponownie modyfikujemy kod (uwaga: pinami do komunikacji są „na sztywno” pin 9 oraz 10 – nie ma możliwości wyboru, jak w przypadku biblioteki SoftwareSerial.h).

Nie poddajemy się i stosujemy dwa zamienniki bibliotek jednocześnie – bum! mamy to! działa!

#include <ServoTimer2.h>
#include <AltSoftSerial.h>

AltSoftSerial bt;//Arduino UNO -> RxD=9, TxD=10, nie ma wyboru!
ServoTimer2 silnik;

void setup() {
  Serial.begin(9600);
  bt.begin(9600);
  silnik.attach(3);
  Serial.println("start!");
}

void loop() {
  if (bt.available()){
    char komenda=bt.readString());
    Serial.print("odebrano= ");
    Serial.println(komenda);//dla sprawdzenia

    switch (komenda){
      case 'W': silnik.write(1000); break;  //przod
      case 'S': silnik.write(2000); break;  //tyl
      case 'X': silnik.write(1500); break;  //stop
    }//switch
}

Niewielkie zmiany, ale istotne. Warto zwrócić uwagę, że funkcja write() dla obiekty ServoTimer2 zapisuje mikrosekundy wypełnienia, czyli dokładnie to co robi funkcja writeMicroseconds() z obiekty Servo (biblioteka Servo.h), co jest trochę mylące. Wystarczy mieć to na uwadze i będzie OK.

Jeszcze jedno: wspomniany problem nie występuje na starszych wersjach środowiska i bibliotek Arduino IDE. Warto sprawdzić.

Wojny robotów: trzecia „kanapka” i korki (przymyślenia).

Pan Kacper buduje trzeci pojazd „kanapka”. Mamy nowe, trochę zmodyfikowane tymczasowe koła – choć drukarka 3D pracuje powoli, to i tak trzeba się natrudzić przy składaniu całej konstrukcji (jakieś 3h?).

Trzeci pojazd. Nowe koła. Ba(k)teria na ścisk!

Myślałem, że wykorzystanie korków od wina jest oryginalne – a tu się okazało, że takie zabiegi były znane i (zapewne) stosowane przynajmniej od roku 1200+. Źródła historyczne donoszą, że prawdziwy podróżnik awanturnik na szlaku musiał posiadać zestaw korków – pewnie w celach majsterkowania, bo po cóż innego miał on je w swoim ekwipunku?

Ekwipunek Geralta: korki to podstawa! Witcher 3, CDPR

Wojny robotów: szybkość obrotowa (RPM) silczka

Pan Tomasz z kolei zawziął się na zbadaniu prędkości obrotej kół (RPM = Revolutions Per Minute). Prosty układ pomiarowy (tymczasowy) pozwolił mu zmierzyć tą prędkość. Układ składa się z potencjometru do sterowania prędkością serwa Feetech FT90R (z prawej strony), oraz czujki szczelinowej (umieszczonej na – oczywiście – korku do wina) wraz z przymocowanym kołem zębatym (druk 3D).

Pomiar prędkości obrotowej serwa.

Pan Tomasz wykorzystał przerwania z Arduino UNO (a dokładniej jedno, ze zboczem narastającym). cdn…

Maskotka

BB zakończył prace nad płytą główną do Maskotki – aktualnie przygotowywane jest lepsze sterowanie prędkością kół – kontroler PID.

Kolejne spotkanie: czwartek 15:00

Podcasty? Wojny robotów („kanapka”) + Maskotka

Podcasty?

Rusza Uniwersyteckie Centrum Podcastów „Na końcu świata” – nowa inicjatywa na naszym Uniwersytecie. Dostaliśmy propozycję prowadzenia takiej cyklicznej audycji. Tematyka w naszych rękach, ale z racji specjalności Fizyka gier komputerowych i robotów same narzucają się gry komputerowe, sprzęt komputerowy, sprzęt do programowania elektroniki oraz nowinki robotyczne/IT. Myślę, że w zależności od poruszanej kwestii może to być audycja 30-to minutowa (dłuższa temat do omówienia) ale także krótsza (15 min na „nowinki”). W kilka osób będzie łatwiej prowadzić takie audycje, więc zachęcam do zastanowienia się i zgłoszenia po Świętach.

Wojny robotów: „kanapka”.

Ulepszamy nasze konstrukcje, montujemy lepsze mocowania silniczków. Sporo pracy manualnej… ale projekt idzie do przodu!

W pracach nad drugą konstrukcją wykorzystaliśmy korek od wina – jest wytrzymały, świetnie się modeluje (przycina, docina) a także łączy i dzieli! Brawo Pan RŁ!

Prace trwają… ale już koniec tego etapu!

Maskotka

BB pracuje nad płytą główną do Maskotki – jest już moduł uporządkowujący przewody + integrujący moduł nRF24L. Fajnie!

Nowy moduł Pana Bartka – ten „zielony” shield 😉

Kolejne spotkanie: czwartek 15:00

Wojny robotów („kanapka”) + Maskotka

Wojny robotów: „kanapka”.

Budujemy drugie podwozie (ciągle w wersji v0.1) – chodzi o to, aby na Święta mieć dwa, a może nawet trzy egzemplarze pojazdów rozdysponowane po zainteresowanych Studentach. To powinno przyspieszyć pracę nad projektem 😉

W pracach nad drugą konstrukcją wykorzystaliśmy korek od wina – jest wytrzymały, świetnie się modeluje (przycina, docina) a także łączy i dzieli! Brawo Pan RŁ!

Drugie podwozie i niezastąpiony materiał „konstruktora amatora” – korek od wina 😉

Pan Tomasz w międzyczasie przypomniał sobie komunikację Bluetooth i wykorzystał nową apkę ze sklepu Androida – Arduino RC. Zaletą jest prostota i wystarczająca funkcjonalność!

Maskotka

BB pracuje nad płytą główną do Maskotki…

Kolejne spotkanie

Proponuję czwartek, godz. 11:00. Zapraszam!

Podstawy: Bluetooth + mikroserwa

Podstawy Arduino

Tym razem poznajemy coś konkretnego – moduł Bluetooth XM-15B. Umożliwi on komunikację z naszym smartfonem i sterowanie wieżtyczką (zbudowaną z 2 mikroserw, jak na poprzednich zajęciach).

Komunikacja z Bluetoothem z wykorzystaniem SoftwareSerial-a.

Poznaliśmy obiekt SoftwareSerial pomocny w komunikacji z dwoma urządzeniami działającymi przez UART, a (niestety) Arduino UNO ma tylko jeden Serial… Wykorzystaliśmy darmową apkę z AndroidStore „Bluetooth control 8 lap” która sterowała wieżyczką. Brawo Studenci!

Wieżyczka z 2x mikroserwo sterowana przez Bluetooth.

Ta apka jest dobra na początek, można poszukać czegoś lepszego w sklepie ale… dlaczego nie stworzyć własnej? To naprawdę proste – z odpowiednim środowiskiem, czyli (polecam) MIT App Inventor

MIT App Inventor – tworzenie pod Androida z bloczków/klocku jak w Scrachu!

Maskotka

Prace trwają: BB poprawia łącza i soft, KG wierci i kręci 😛 A co z tego wyszło? Skrzypi, ale jeździ jak wariat 😀

Optymalizacja sterowania

Słowem wstępu…

Dzisiejszego dnia pracowaliśmy nad optymalizacją naszego sterowania pojazdem.

Wciąż używamy do tego naszego smartfona, a konkretniej aplikacji „ArduinoRC”, która za pomocą bluetooth w naszym telefonie łączy się z modułem Bluetooth XM-15B podłączonego do Arduino. Więcej o tym w tym artykule.

Na poniższym zdjęciu nasz wypasiony „panel sterowania” 🙂

 

Dotychczas nasz program działał w dosyć prosty sposób – jeżeli Arduino odczytało określony znak z komunikacji szeregowej  bluetooth, to przekazywało do silniczka konkretne stany tak aby koła kręciły się na przykład w przód.

 

Poznaliśmy jednak głębszą teorię sterowania i pojawił się następujący problem:

A więc w aplikacji „ArduinoRC” klikamy strzałkę w górę. Załóżmy że przekazywany znak to literka 'W’, po odczytaniu której kółka mają się kręcić w przód.  Po przekazaniu jej komunikacją szeregową, Arduino posłusznie uruchamia silniczki, po czym je wyłącza. Gdy na telefonie tym razem przytrzymamy strzałkę, zamiast pojedynczego znaku 'W’, Arduino odczyta serie znaków – „WWWWWWWWWW … „. Po każdym z odczytanych znaków silniczki na chwilę staną, po czym po wczytaniu następnego – znowu ruszą. Taki efekt 'szarpania’ to nienajlepsze rozwiązanie ponieważ ciągłe włączanie i wyłączanie silniczka powoduje większe zużycie baterii. Więc zamiast sekwencji:

włącz(1) – wyłącz(1) – włącz(2) – wyłącz(2) – włącz(3) – wyłącz(3)

proponujemy logiczniejsza sekwencje:

włącz(1) – kontynuuj(2) – kontynuuj(3) – wyłącz(3).

Oczywiście nie zobaczymy tego problemu gołym okiem, ponieważ Arduino może odczytywać parę tysięcy takich znaków na sekundę.

Rozwiązanie problemu

Pomysłów na rozwiązanie tego problemu było parę, trzeba było jednak liczyć się z tym że Arduino to nie komputer stacjonarny i warto zrobić to w miarę możliwości optymalnie, aby nie zaśmiecać pamięci mikrokontrolera.

Z pomocą przyszła nam funkcja millis() z wbudowanej biblioteki, która zwraca czas który upłynął od włączenia urządzenia w milisekundach. Utworzyliśmy też parę pomocniczych zmiennych i utworzyliśmy sprytny sposób aby usprawnić pracę silnika.

Znowu użyłem swoich ponadprzeciętnych umiejętności artystycznych oraz zaawansowanego oprogramowania do obróbki graficznej (Paint i Gimp) aby stworzyć kilka schematów blokowych.

Przedstawiają one po kolei:

1. Działanie głównej pętli loop

Jak widać główna pętla programu Arduino będzie składała się z dwóch bloków: Obsługi Bluetootha, a potem Obsługi stopu silnika. Tak, tylko stopu silnika, bo uruchomienie silników zajdzie się w Obsłudze Bluetooth. Raz puszczone koła w ruch zatrzymają się dopiero w drugim bloku, po upływie określonego czasu. 

2. Działanie obsługi Bluetooth

Powyższy schemat koncentruje się tylko na jednej instrukcji – jedz do przodu (wczytanie W). Gdy już wszystko będzie dobrze działać – w podobny sposób trzeba dodać kolejne polecenia (zda do tylu, w lewo i w prawo). 

Sama obsługa instrukcji jazdy do przodu (obsługa 'W’) będzie obszerniej wytłumaczona za chwilę, ale już sam schemat algorytmu dużo może wyjaśnić:

3. Działanie obsługi odczytania znaku 'W’

Na początku, utwórzmy zmienną pomocniczą P i na razie przypiszmy jej liczbę 0. Będzie to zmienna przechowująca czas działania Arduino w milisekundach, po którego przekroczeniu nasze kółka przestaną się kręcić.

Zmienna DeltaT przechowywuje czas w milisekundach, przez jaki nasze kółka mają się kręcić po jednorazowym odczytaniu znaku. My akurat ustaliliśmy wartość 100 milisekund, jest to optymalna wartość przy której w praktyce nasza maszyna śmiga jak należy.

Dla lepszego wyobrażenia sobie tego o czym mowa, poniżej przedstawiłem oś przedstawiającą upływ czasu od włączenia Arduino. Zaznaczyłem zupełnie przypadkową wartość, akurat w tym przypadku oznacza, że minęło 10234 milisekund (czyli jakieś 10,2 sekund od włączenia urządzenia).

Kolejny krok w naszym schemacie to instrukcja warunkowa:

Czy P<milis() ?

W tej chwili Arduino wywołuje funkcje millis() i porównuje ją ze zmienną P. Między uruchomieniem urządzenia a wczytaniem znaku z naszego telefonu musiała minąć przynajmniej 1/1000 sekundy. Warunek zostaje więc spełniony – upływ czasu w milisekundach jest większy od 0. Przechodzimy więc do następnego bloku zgodnie ze schematem.

  1. P = millis() + DeltaT
  2. włączSilnik()

1.Zmienna P przyjmuje wartość sumy aktualnego upływu czasu   i   czasu przez jaki nasze kółka mają się kręcić po jednorazowym odczytaniu znaku.

2.Nasz silnik uruchamia się a wehikuł jedzie do przodu.

 

Tak jak wspominałem, zmienna P będzie przetrzymywała czas działania Arduino po którym silnik przestaje działać – teraz widzimy to na osi. Działa to mniej więcej w ten sposób:

  1. Wczytany został sygnał 'W’.
  2. Aktualnie minęło 10234 milisekund od czasu uruchomienia urządzenia.
  3. Silnik uruchamia się.
  4. Silnik ma pracować dopóki czas działania Arduino nie przekroczy 10334 milisekund.

Całkiem proste prawda? 🙂

To co opisałem do tej pory, to reakcja na pojedynczy znak 'W’. Jednak ja chcę aby mój samochodzik podjechał dwa metry do przodu, a co mi tam! Zobaczmy więc co zdarzy się jeśli przytrzymam strzałkę w aplikacji sterującej, a Arduino dostanie serie znaków „WWWWWWWWWWW … „.

Ok, analogiczna do powyższej sytuacja:

  1. Arduino odczytuje pojedynczy znak 'W’
  2. zmienna P przyjmuje odpowiednią wartość
  3. silniczek rusza

Jednak zanim minie nasze DeltaT czyli 100 milisekund, Arduino dostaje kolejny znak – kolejne 'W’. I co teraz? Wróćmy do naszego schematu blokowego nr 2 – tym razem zacznijmy działanie od instrukcji warunkowej (zmienne przypisuje tylko na początku działania programu) – i spójrzmy na poniższy wykres:

Aktualnie nasze P jest większe od czasu który upłynął dotychczas – rozpatrując więc działanie schematu blokowego, pierwszy warunek nie zostaje spełniony – wykonuje się instrukcja:

P = P + DeltaT

Czyli zmienna P która dotychczas przyjmowała konkretną wartość, powiększy się o kolejne DeltaT – czyli o 100. Oznacza to że czas działania urządzenia w którym silnik ma się wyłączyć wydłuża się o 100 milisekund.

Po odczytywaniu kolejnych znaków – analogicznie czas ten będzie się wydłużał. Będzie tym bardziej dłuższy, im dłużej przytrzymam strzałkę i im więcej znaków w jednej sekwencji odczyta Arduino. Przy tym warto zauważyć że w takiej sytuacji nasz silnik nie zatrzyma się, będzie działał dopóki trzymam strzałkę. Tak więc nasz problem został rozwiązany.

Na koniec ostatni blok programu – sprawdzenie, czy trzeba zatrzymać silniki.

4. Działanie obsługi stopu silników

 

PROGRAM i obiekty

Teraz zapoznajmy się z praktycznym kodem na Arduino. Naturalnie jest on obszerniejszy niż schematy blokowe, ponieważ obsługuje On całe działanie samochodu. W tym przykładzie zdecydowałem się na stworzenie klasy – jest to forma programowania obiektowego,  co umożliwia język C++. Różni się więc od poprzednich programów z fi-bot-a – gdzie programowaliśmy strukturalnie (język C). Opiszę więc komentarzem kluczowe linijki kodu których działanie opisałem wcześniej.

#include <SoftwareSerial.h>
#define RxD 2
#define TxD 3
#define IN1 4
#define IN2 5
#define IN3 6
#define IN4 7

SoftwareSerial btSerial(RxD,TxD);
unsigned long int przod = millis();                           
unsigned int delta_t=100;               

class Silnik      //w tym przykladzie zdecydowalem sie na stworzenie klasy - jest to forma 
{                 //programowania obiektowego co umozliwia język C++, a nie jak w poprzednich
  public:         //artykulach - tylko programowania strukturalnego a'la język C

  void wylaczSilnik()
  {
    digitalWrite(IN1,HIGH);
    digitalWrite(IN2,HIGH);
    digitalWrite(IN3,HIGH);
    digitalWrite(IN4,HIGH);
  }
 
  void doPrzodu()                        
  {
    digitalWrite(IN1,HIGH);
    digitalWrite(IN2,LOW);
    digitalWrite(IN3,HIGH);
    digitalWrite(IN4,LOW);
  }

  void doTylu()
  {
    digitalWrite(IN1,LOW);
    digitalWrite(IN2,HIGH);
    digitalWrite(IN3,LOW);
    digitalWrite(IN4,HIGH);
  }

  void wPrawo()
  {
    digitalWrite(IN1,HIGH);
    digitalWrite(IN2,LOW);
    digitalWrite(IN3,HIGH);
    digitalWrite(IN4,HIGH);
  }

  void wLewo()
  {
     digitalWrite(IN1,HIGH);
     digitalWrite(IN2,HIGH);
     digitalWrite(IN3,HIGH);
     digitalWrite(IN4,LOW);
  }
};

  Silnik Maria;

void setup() {
  Serial.begin(9600);
  Serial.println("start!");
  btSerial.begin(9600);
  pinMode(4,OUTPUT);
  pinMode(5,OUTPUT);
  pinMode(6,OUTPUT);
  pinMode(7,OUTPUT);
 
}
              
void loop() {                          //schemat blokowy nr 1
  if(btSerial.available())             //schemat blokowy nr 3
  {
    char zn=btSerial.read();           
    Serial.println(zn);

   
    switch(zn)
    {
      case 'W':                        //schemat blokowy nr 2
      if(przod<millis())               
      {
        przod=millis()+delta_t;        
        Maria.doPrzodu();
      }

      else                              
      {
        przod+=delta_t;
      }

      break;

      case 'S':
      if(przod<millis())
      {
        przod=millis()+delta_t;
        Maria.doTylu();
      }

      else
      {
        przod+=delta_t;
      }
     
      break;

      case 'A':
      if(przod<millis())
      {
        przod=millis()+delta_t;
        Maria.wLewo();
      }

      else
      {
        przod+=delta_t;
      }
      break;
     
      case 'D':
      if(przod<millis())
      {
        przod=millis()+delta_t;
        Maria.wPrawo();
      }

      else
      {
        przod+=delta_t;
      }
      break;
    }
  }

  if(millis()>przod)                    //schemat blokowy nr 4
    {
      Maria.wylaczSilnik();             
    }
}

To by było na tyle, bądźcie na bieżąco 🙂

Pozdrawiam!

(c) Przemysław Baj 2018

pojazd cz.1

Dziś było więcej mechaniki, niż elektroniki… choć na koniec udało się Wszystkim złożyć swoje pojazdy i uruchomić – gratuluję! Za tydzień sterowanie i pierwsze jazdy próbne 😉

(c) KG 2018

Bluetooth

Z wielkim sukcesem i zadowoleniem oprogramowaliśmy moduł Bluetooth XM-15B

  • biblioteka SoftwareSerial.h — bardzo przydatna w pracy z bluetooth, bo potrzebujemy komunikacji szeregowej (Arduino UNO ma tylko jedną parę Tx/Rx!)
  • tworzymy zmienną SoftwareSerial i przypisujemy jej dwa piny cyfrowe – w kolejności Rx, Tx
  • nie zapomnijcie o włączeniu metodą begin(9600)
  • łączenie „na krzyż” z modułem XM-15B, czyli: Tx <–> Rx, Rx <–> Tx
  • czytanie i interpretowanie komend…. a myślicie, że po co ciągle ćwiczyliśmy czytanie z klawiatury? teraz się przyda!

Poniżej działanie aplikacji Blutooth Control Lamp i wyświetlaczem 7-mio segmentowym:

Podłączamy sterownik silników L298N i kolejna apka z Androida: Android RC

A tu mamy to, co niebawem nas czeka: troszkę większe silniczki (37Dx73L) z zaprojektowanym i wydrukowanych „trzymakiem”

Chciałem pogratulować całej 5-tce obecnej na dzisiejszych zajęciach – za zaangażowanie w pracę nad projektem – i naukę nawet w długi weekend majowy. Jestem przekonany, że Wam się to opłaci.

(c) KG 2018

Zajęcia nr 5 – serwo silniki, map(), bluetooth

 Serwo silnik (a właściwie mikro-serwo)

serwo1Czyli silnik, który obraca się od 0 do 180 stopni (ma blokadę na inne wychylenia). Potem utrzymuje swoją pozycję. Służy do tworzenia obrotowych ramion itd…

Trzy przewody – zasilanie (czerowny +5V, czarny/brązowy GND) oraz jeden sterujący – musi być PWM. Za dużo nie wnikałem o co chodzi w sterowaniu tym silnikiem, tylko wspomniałem o potencjometrze wewnątrz i o wypełnieniu sygnału sterującego… więcej może później? Zobaczymy.

 

Do sterowania tym silnikiem użyliśmy 2 nowych funkcji z nowej biblioteki:

  • #include <Servo.h> – na początku programu informujemy, że chcemy funkcje z tej nowej biblioteki
  • Servo silniczek; tworzymy zmienną typu silnik-serwo, czyli właśnie o to nam chodzi!
  • silniczek.attach(3); powoduje przekazanie informacji do Arduino, że sterujemy silnikiem przez pin numer 3 (przypominam: musi być to pin PWM, czyli jak nie 3, to 5,9…)
  • silniczek.write(133); ustawia nasz silnik w pozycji 133 stopni. Albo na dowolny inny z zakresu 0..180 stopni. Dziecinie proste 😉

Serwo sterowane z klawiatury

Przypomnieliśmy sobie jak odczytywać liczby z klawiatury (funkcja parseInt() dla obiektu Serial) i stworzyliśmy program ustawiający silnik w pozycji wczytanej z klawiatury. Proste a przyjemne. No i zawsze warto powtarzać wiedzę 😉

Serwo sterowane potencjometrem

Połączenie poprzednich zajęć – potencjometr liniowy (dzielnik napięć!) wykorzystany do ustawiania pozycji serwa – ruszam „gałką” w lewo, orczyk w serwie obraca się w lewo. Tak samo w prawo. Fajne!

Serwo sterowane potencjometrem – program PRO

Dbamy o szczegóły – i nie chcemy ustawiać położenia serwa wówczas, gdy potencjometr nie zminił swojej pozycji. Bez złośliwości – my staramy się programować na serio

Prąd „zjadany” przez serwo – mierzymy!

W skrajnych ustawieniach serwa (tj. w okolicy 0 stopni, oraz w okolicach 180 stopni) słyszymy buczenie/piszczenie serwo-silnika. Coś się dzieje. Amperomierz w garść i mierzymy prąd.

serwo1

Przyjrzyj się uważnie obrazkowi i zwróć uwagę, jak podłączony jest amperomierz.

Oczywiście w wirtualnym Arduino (ciągle polecam circuits.io) silniczek serwo jest idealny i nie widzimy tego, co było u nas na zajęciach….

Dodatkowo: w przypadku mierników uniwersalnych ustaw największą wartość prądu, jaką się spodziewasz dostać – nie odwrotnie! W przeciwnym przypadku zwiększając zakres przepalisz bezpiecznik w multimetrze…

Funkcja map()

Czyli skalowanie wartości z jednego zakresu na drugi zakres. Przykład, z którym my się bawiliśmy: serwo silniczek sterowany potencjometrem. Odczytujemy nastawy potencjometru z portu analogowego Arduino jako liczbę (nazwijmy ją x) z zakresu 0..1023, a następnie ustawiamy serwo w położeniu z zakresu 0..180 stopni (nazwijmy te stopnie y). Czyli musimy dokonać zamiany wczytaj liczby x na y. Na zajęciach pokazałem skalowanie funkcją liniową, rozwiązaliśmy ten układ równań, ale Arduino jest także dla tych co tego nie umieją zrobić i przygotowało funkcję map(). W naszym przypadku będzie to:

y=map(x, 0, 1023, 0, 180);

Należy pamiętać, że funkcja map() działa tylko na liczbach całkowitych (int).

Serwo sterowane przez Androida – bluetooth XM-15B

Dlaczego ten? Bo działa w zakresie 3-6V, czyli można go bezpiecznie podłączyć do Arduino. Inne modele – popularne HC-05, HC-06 komunikują się przez 3.3V i wymagają „zbijania” napięcia (np. dzielnikiem napięć). To proste, ale… po co się w to bawić, jak można kupić właśnie moduł pozbawiony tej uciążliwości? Praujemy więc z XM-15B.

 

Pamiętajmy o łączeniu „na krzyż” portów RxD,TxD modułu XM-15B z portami RxD,TxD płytki Arduino (także tymi wirtualnymi).

Komunikacja z 8LAMP

Ze sklepu Play bierzemy prostą apkę i sprawdzamy, co ona wysyła do naszego bluetootha. Kod:

#include <SoftwareSerial.h>

#define RxD 8
#define TxD 9
SoftwareSerial btSerial(RxD,TxD);

void setup() {
  Serial.begin(9600);
  btSerial.begin(9600);
  Serial.println("start!");
}

void loop() {
  if (btSerial.available()){
    Serial.print("Odebrałem znak= ");
    Serial.println(btSerial.read());
  }  
}

Następnie tak modyfikujemy ten program, by wczytany znak sterował naszym serwem – guzik '1′ ustawiał serwo na 90 stopni, guzik '2′ na 10 stopni i guzik '3′ na 170 stopni. Inne modyfikacje mile widziane 😉

Ważne

Na następne zajęcia proszę o zainstalowanie ze sklepu Play aplikacji Arduino Bluetooth Controler bo będziemy sterować pojazdem.

RemoteXY – bardzo fajna obsługa Arduina via smartfon (+Bluetooth)

Dziś tematem naszego spotkania był moduł Bluetooth HC05 – ale nie sam moduł, tylko sposób jego programowania z poziomu Androida. W markecie jest sporo darmowego oprogramowania, ale często nie spełnia naszych oczekiwań – ze względu na brak możliwości pełnej konfiguracji, lub nieatrakcyjność interfejsu. Cóż – nie ma co narzekać jak za darmowe apki, ale… dziś – dzięki uprzejmości Pani Noemi – poznaliśmy płatną apkę RemoteXY do zarządzania Arduinem via moduł Bluetooth (tak, to właśnie Pani Noemi poprowadziła dzisiejsze spotkanie, jako osoba z doświadczeniem z tym programem).

Mowa o RemoteXY, które po zakupie na telefon (tablet, etc) trzeba doinstalować na kompa, gdzie mamy Arduino IDE. Potem wszystko działa według schematu:

i trzeba przyznać, że faktycznie – jest to

  1. proste
  2. intuicyjne
  3. ładne graficznie!

Cóż więcej dodać? Chyba po takiej reklamie już nic nie trzeba 😉

DSC_1104

A tutaj już konkretny przykład Pani Noemi – sterowanie silniczkami oraz LEDami przez smartfon. Dwa przyciski włączają/wyłączają diody, joystik w prawej części ekranu to panel sterowania silniczkami (zmieniamy szybkość i kierunki ruchu oby silników). Na biurku hardware: HC05 oraz Arduino + MotorShiel AdaFruit.

Edit:

stety/niestety znalazłem słaby punkt tej apki. Po jej zakupie tylko my możemy korzystać z przygotowanych layoutów. Nie możemy oddać komuś innemu, nieposiadającemu pełnej wersji naszej zabawki (np. robocika) aby sterował nim z poziomu swego smartfona. Ten ktoś musi posiadać RemoteXY. Cóż.