kolorowo – ws2812b

Posted on 18 stycznia, 201920 stycznia, 2019 by gawryl

Poznaliśmy bardzo ciekawy układ: 3x LED (kolor czerwony, niebieski i zielony) + sterownik ws2811 – wszystko razem tworzy moduł oświetlenia RGB, który bardzo łatwo się steruje – a uzyskane efekty są bardzo przyjemne ;-)Moduły mogą być sprzedawane osobno (pojedynczo), ale super prezentują się układy połączone w „oczko” lub listwy.

3x RGB

Każdy LED świeci światłem o danej długości (L [nm]), maksymalną jasnością (J [mcd]) i cechuje się też konkretnym spadkiem napięcia (V [V]). Poniżej dane z datasheet.:
Red L=620-625 J=390-420 V=2.0-2.2
Green L=522-525 J=660-720 V=3.0-3.4
Blue L=465-467 J=180-200 V=3.0-3.4

Trzeba uważać, aby zasilając takie paski uważnie dobrze policzyć wymagany MAKSYMALNY prąd pobrany przez układ! Mamy tu 3 LEDy, więc gdy wszystkie będą świecić na 100% to potrzeba ~3x20mA na każdy jeden moduł. Nasze „oczko” ma 12 takich układów, więc daje to około 0.72A prądu – czyli już uszkodziliśmy Arduino (pamiętamy, że wydajność prądowa płytki Arduino UNO <0.5A ? trzeba na to uważać!). Gdy zasilamy paski/oczka bezpośrednio z Arduino proszę zmniejszyć jasność ledów do 10% albo i niżej (w zależności ile ich mamy).

Przestrzegaj tych reguł (wzięte z /dev/jarzebski)

Nie przekraczaj napięcia zasilania powyżej 5V,
Dodaj kondensator elektrolityczny o pojemności od 100µF do 1000µF (np.: 6.3V lub wyższy) przy zasilaniu pierwszej diody,
Dodaj rezystor o wartości od 300Ω do 1kΩ pomiędzy mikrokontrolerem, a pierwszym pinem DIN. Rezystor ten umieść jak najbliżej diody,
Postaraj się możliwie skrócić odległość pomiędzy mikrokontrolerem, a pierwszą diodą,
Nie podłączaj diod przy włączonym zasilaniu. Jeśli już musisz, rób to w kolejności: masa, zasilanie, linia sterująca, a odłączaj w odwrotnej kolejności
Jeśli diody zasilasz z oddzielnego źródła zasilania, najpierw doprowadź zasilanie do diod, potem do mikrokontrolera,
Pamiętaj o zabezpieczeniu antystatycznym 🙂 swetry, polary i inne ubiory łatwo gromadzące ładunek nie są wskazane

Polecam cały wpis o tych układach na /dev/jarzebski.

NeoPixel

Biblioteka do programowania układów WS2812B.

    #include <Adafruit_NeoPixel.h>
     
    #define PIN 7
    #define LICZBADIOD 12
     
    Adafruit_NeoPixel pixels = Adafruit_NeoPixel(LICZBADIOD, PIN, NEO_GRB + NEO_KHZ800);
     
    void setup(){
      pixels.begin(); // najpierw inicjalizacja biblioteki
    }
    
    int nr=0;
    void loop(){
        if (nr > LICZBADIOD) nr=0;
        pixels.setPixelColor(nr, random(0,256), random(0,256), random(0,256)); //programujemy LED-a o numerze nr
        pixels.show(); // konieczne, aby zmiany były widoczne
        delay(30);
        pixels.setPixelColor(nr, 0, 0, 0); //kolor czarny dla  LED-a o numerze nr 
        nr++;
    }

Kompilacja zakończona z komunikatem:

Szkic używa 3046 bajtów (9%) pamięci programu. Maksimum to 32256 bajtów. Zmienne globalne używają 46 bajtów (2%) pamięci dynamicznej, pozostawiając 2002 bajtów dla zmiennych lokalnych.

Zmieniamy LICZBEDIOD z 12 na 59 i… ten sam rozmiar zajmowanej pamięci. Ta uwaga do porównania dla kolejnej (popularnej) biblioteki.

FastLed

Kolejna biblioteka do programowania tych układów WS2812B.

#include <FastLED.h>
#define NUM_LEDS 12
#define DATA_PIN 7

CRGB leds[NUM_LEDS];

void setup() { 
   FastLED.addLeds<NEOPIXEL, DATA_PIN>(leds, NUM_LEDS);
   FastLED.setBrightness(10);
}

void loop() { 
      if (nr > NUM_LEDS) nr = 0;
      //leds[nr] = CRGB::Blue; 
      leds[nr].r = random(0, 256);  
      leds[nr].g = random(0, 256);  
      leds[nr].b = random(0, 256);       
      FastLED.show();   //wyswietlamy zaprogramowale kolory LEDow
      leds[nr] = CRGB::Black;
      delay(30);
      nr++;
}

Kompilujemy i widzimy:

Szkic używa 4040 bajtów (12%) pamięci programu. Maksimum to 32256 bajtów. Zmienne globalne używają 139 bajtów (6%) pamięci dynamicznej, pozostawiając 1909 bajtów dla zmiennych lokalnych.

Widzimy, że ten sam kod jest większy z wykorzystaniem FastLed-a. OK. Idziemy krok dalej i zmieniamy NUM_LEDS na 59 i…

Szkic używa 4040 bajtów (12%) pamięci programu. Maksimum to 32256 bajtów. Zmienne globalne używają 280 bajtów (13%) pamięci dynamicznej, pozostawiając 1768 bajtów dla zmiennych lokalnych.

Która biblioteka lepsza – FastLed czy NeoPixel? hmmm… Po pierwsze: obie są proste w użyciu – to zaleta obu. Jednak: FastLed jednak rezerwuje 3 bajty (kolory RGB) dla każdego ws2812b – co jest dość pamięciożerne, tym bardziej, że takie Arduino UNO ma jedynie (aż?) 2kB pamięci. Jednak o wadach i zaletach na razie nie będę się wypowiadać.

(c) K.G. 2019

Nokia 5510 – wizualizacja 3D

Posted on 11 stycznia, 201928 stycznia, 2019 by bytler

Czy można zmusić Arduino do wyświetlania grafiki 3D? Wiadomo, że do grania w gry potrzebujemy potężnych akceleratorów graficznych (karty nVidii lub ATI) lub dla mniej wymagającej grafiki mocnego CPU. Arduino może i nie ma wielkich zasobów mocy obliczeniowej, ale przy użyciu prostego wyświetlacza i lekkiej imitacji biblioteki 3d możemy uzyskać interesujące efekty. Stworzę “silnik 3D” – który w zasadzie jest tylko prostym rzutowaniem punktów na ekran. Pomimo ograniczonej funkcjonalności, możemy uzyskać ciekawe efekty takie jak obracająca się przestrzenna siatka sześcianu.

Cała sztuczka uzyskania wrażenia 3D polega na dobrym rzutowaniu punków w przestrzeni na piksele ekranu. Wiadomo, że obiekty dalsze są mniejsze, a te bliższe – są większe (perspektywa!). Ta obserwacja prowadzi mnie do banalnego pomysłu – nie będę rzutować trójwymiarowych punktów (x,y,z) na ekranik wyświetlacza (x,y), uwzględniając pozycję kamery w przestrzeni a jedynie… będę zmniejszać/zwiększać obiekty w zależności od ich odległości! Do oddania efektu głębi użyję funkcji wykładniczej a nie liniowej – to kolejna obserwacja, z którą trudno się nie zgodzić (obiekt dwa razy dalej nie jest wcale dwa razy mniejszy!). Dzięki temu obiekty znajdujące się bliżej będą powiększane, a te dalej pomniejszane.

Daje nam to wrażenie, że obiekty znajdujące się dalej zbliżają lub oddalają się wolniej, a natomiast te bliżej – szybciej. Oddalające się punkty powinny się zbiegać do środka ekranu aby otrzymać efekt perspektywy punktowej.

Jako przykład użyjemy wyświetlacza Nokii 5110 oraz bibliotek Adafruit_PCD8544.h oraz Adafruit_GFX.h. Biblioteki posłużą nam do kontrolowania ekranem i wyświetlania linii.

Na początku musimy zaimplementować rzutowanie:

struct point2D{
 int x,y;
};

struct point3D{
 float x,y,z;
 point2D CastTo2D(){
   point2D ret;
   ret.x = szerokosc_ekranu/2 + (x * X_SCALE *  pow(Z_SCALE, z));
   ret.y = wysokosc_ekranu/2 - (y * Y_SCALE * pow(Z_SCALE, z));
   return ret;
 }
};

Tworzę w ten sposób dwie struktury oraz metodę do późniejszego rzutowania na ekran. X_SCALE, Y_SCALE to współczynnki skalowania na poszczególnych osiach ekranu (bardzo przydatne w przypadku gdy piksele wyświetlacza nie są kwadratowe). Z_SCALE natomiast to współczynnik skalowania głębi.

Po podłączeniu ekranu do Arduino używamy bibliotek, żeby coś wyświetlić:

#include <SPI.h>
#include <Adafruit_GFX.h>
#include <Adafruit_PCD8544.h>
Adafruit_PCD8544 disp = Adafruit_PCD8544(5, 4, 3);

void setup() {
    disp.begin();
    disp.display(); // wyswietlanie buffera
}

Ten krótki kawałek kodu powinien wyświetlić logo Adafruit na ekranie. Można poświęcić chwilę na przyjrzenie się bliżej bibliotece i postarać się stworzyć własne logo, np. takie:

Gdy już wszystko nam działa możemy przejść do wyświetlenia czegoś przestrzennego. Pomocna będzie funkcja rysująca linię na ekranie pomiędzy punktami w przestrzeni:

void draw3DLine(point3D a, point3D b){
 disp.drawLine(a.CastTo2D().x, a.CastTo2D().y, b.CastTo2D().x, b.CastTo2D().y, BLACK);
}

Musimy jednak mieć na uwadze w jaki sposób punkty przestrzenne są konwertowane na piksele ekranu. Punkt (0,0,0) znajduje się na środku ekranu, a składowa Z określa powiększenie (Z>0) lub pomniejszenie (Z<0) obiektu. Dla Z=0 rozmiar obiektu nie zostanie zmodyfikowany. Znaczenie ma również skala (X_SCALE, Y_SCALE), gdyż to właśnie przez te wartości mnożymy położenie punktu (dla małej skali musimy podać większe współrzędne, bo nasz obiekt na ekranie może okazać się jedynie małą kropką).

Wyświetlenie siatki sześcianu to odpowiednie połączenie ośmiu punktów – dosyć proste. Ale jak sprawić, żeby ten sześcian się obracał? W tym celu sięgamy po parę funkcji trygonometrycznych, a mianowicie sinus i cosinus.

Zamiast podawać konkretne współrzędne x i y, możemy użyć kąta i odległości od środka. Punkt (r*cos(a), r*sin(a)), niezależnie od kąta a, jest zawsze oddalony o odległość r od punktu(0,0). Zwiększając ten kąt, punkt będzie “wędrować” po okręgu. Możemy to wykorzystać właśnie do obracania sześcianem.

Teraz możemy określić pionową parę punktów współrzędnymi:

(cos(a)*R, y, sin(a)*R) i (cos(a)*R, -y, sin(a)*R),

gdzie R to promień okręgu, po którym będą poruszać się punkty i jednocześnie połowa przekątnej sześcianu. Aby uzyskać następną parę punktów musimy je obrócić o 90 stopni, czyli do poprzedniego kąta dodajemy ℼ/2:

(cos(a+PI/2)*R, y, sin(a+PI/2)*R) i (cos(a+PI/2)*R, -y, sin(a+PI/2)*R).

W podobny sposób uzyskujemy pozostałe pary punktów dodając odpowiednio wielokrotność kąta ℼ/2 (dla trzeciej pary: 2*PI/2 i czwartej: 3*PI/2).

Kiedy już zapisaliśmy pozycje punktów w tej postaci, możemy zwiększać kąt a (lub zmniejszać co spowoduje obrót w przeciwnym kierunku). Warto pamiętać, że jest to kąt w radianach i należy go zwiększać o stosunkowo małe wartości.

Efekt jest następujący:

Kod programu:

#include <SPI.h>
#include <Adafruit_GFX.h>
#include <Adafruit_PCD8544.h>
#define Z_SCALE 1.2
#define X_SCALE 20
#define Y_SCALE 16
#define ANGLE 0.08
#define DT 60
#define RADIUS 1.3

struct point2D{
  int x,y;
};

struct point3D{
  float x,y,z;
  
  point2D CastTo2D(){
    point2D ret;
    ret.x = round(42. + (x * X_SCALE *  pow(Z_SCALE, z)));
    ret.y = round(24. - (y * Y_SCALE * pow(Z_SCALE, z)));
    return ret;
  }
};
// Software SPI (slower updates, more flexible pin options)
// pin 7 - Serial clock out (SCLK)
// pin 6 - Serial data out (DIN)
// pin 5 - Data/Command select (D/C)
// pin 4 - LCD chip select (CS)
// pin 3 - LCD reset (RST)
Adafruit_PCD8544 disp = Adafruit_PCD8544(7, 6, 5, 4, 3);

void draw3DLine(point3D a, point3D b){
  disp.drawLine(a.CastTo2D().x, a.CastTo2D().y, b.CastTo2D().x, b.CastTo2D().y, BLACK);
}

void setup() {
  disp.begin();
}

float fi = 0.;
void loop() {

  fi+=ANGLE;
  disp.clearDisplay();
  for(int i=0; i<4; i++){
    point3D a= {cos(i*2*M_PI/4 + fi)*RADIUS, 1, sin(i*2*M_PI/4+ fi)*RADIUS};
    point3D b= {cos(i*2*M_PI/4 + fi)*RADIUS, -1, sin(i*2*M_PI/4+ fi)*RADIUS};
    draw3DLine(a,b);
    point3D c= {cos((i+1)*2*M_PI/4 + fi)*RADIUS, 1, sin((i+1)*2*M_PI/4+ fi)*RADIUS};
    point3D d= {cos((i+1)*2*M_PI/4 + fi)*RADIUS, -1, sin((i+1)*2*M_PI/4+ fi)*RADIUS};
    draw3DLine(a,c);
    draw3DLine(b,d);  
  }
  disp.display();
  delay(DT);
}

(c) Bartosz Bytler 2019

Pomiar ciągu silnika

Posted on 6 stycznia, 201930 stycznia, 2019 by gawryl

Pomiar ciągu silnika

Okazuje się, że zaproponowany na zajęciach schemat pomiarowy (wykorzystany do określenia ciągu naszego balonu) nie zadziała w przypadku silniczka:

Dorysowane strzałki tłumaczą sprawę, ale wyjaśniam: waga nie wskazała mniejszej masy, gdyż powietrze z wirujących łopat śmigieł powodowało ciśnienie na wagę… Z balonem ten pomysł „wypalił”, a tutaj nie. Ulepszony zestaw pomiarowy wykorzystujący „dźwignię” – ważne: oba ramiona tej samej długości, ech ta fizyka 😉

Tym razem nie ma problemu z ciśnieniem powietrza, gdyż to wypychane jest za dźwignię, podnosząc lekko ramię – co rejestruję na wadze. Działa to w dwie strony: przy odwrotnej pracy silnika (lub innych śmigłach: CW zamiast CCW) ramię będzie dociskane do wagi i obserwować będę zwiększenie wskazań masy. Trzeba więc jedynie zanotować odczyt wagi na początku (przed uruchomieniem silniczka) i wykonywać pomiary.

Pomiary najlepiej wykonywać zmieniając napięcie zasilające silniczek – ja tu mam regulowany zasilacz laboratoryjny, który dodatkowo podaje mi informację o prądzie pobieranym przez podłączony układ (ważna informacja).

Pomierzyłem „osiągi” swojego silniczka MT-62 (4 gramy) ze śmigiełkiem 60mm (0.2g) i otrzymałem takie wyniki

napięcie [V]	prąd [A]	ciąg [g]
2	0.06	2
3	0.11	4
3.7	0.14	5.4
4	0.16	6.3
5	0.21	8.8

Oszałamiające one nie są… przy docelowym napięciu z baterii Li-Po 3.7V będę tylko „lekko” na plusie – jeśli chodzi o samą masę silniczka (masa śmigiełka na tyle mała, że pomijam).

Ważymy podzespoły

Arduino Nano (z pinami)	5.7 g
1x pakiet Li-Po 3.7V 800mA	16g
DRV8833 (trzeba 2x)	1g (według producenta)
silniczki + śmigła (trzeba 4)	4g
XM-15B	3.7g
rama? mocowania?	x?

Jak widać jest kłopot przy tym silniczku – aby podnieść ~50g (zakładam ramę 10g), to dysponując balonem o sile nośnej ~20g musimy silniczkami dostarczyć brakujące 30g ciągu! MT-62 przy zasilaniu z pojedynczej Li-Po nie wystarcza. Sprawa wygląda lepiej gdy zwiększamy zasilanie (choć nie możemy robić tego do poziomu 2×3.7V, bo te silniczki działają do 6V), ale jeszcze lepiej – gdy zmienimy silniczki (za chwilę).

Rama

Można zaprojektować i wydrukować w 3D samodzielnie, o tak jakoś:

co zrobiłem wzorując się na „klasyku” QX80. Co zyskujemy drukując samemu? możemy ustawić dwa silniczki w innej płaszczyźnie, tak jak nam potrzeba. Tak czy owak fajne jest to, że waga takiej ramy to <10g (zarówno tej kupnej, jak i mojej – wydrukowanej w 3D).

Zapotrzebowanie na prąd

Silniczek MT-62 przy pracy z napięciem 3.7V pobierał 0.14A, czyli 140mA. Cztery takie silniczki będą zjadać 560mA. Dodatkowo trzeba uwzględnić prąd pracy Arduino – zmierzyłem, że to jest 10mA przy działaniu prostego programiku – ale przy bardziej skomplikowanym programie może być więcej. Uwzględnić trzeba sterownik DRV8833 (lub podobny, patrz specyfikacja) oraz moduł Bluetooth (ponownie: patrz specyfikacja). Niech dla prostoty dalszych rachunków zaokrąglę wszystko do 800mA. Bateria Li-Po o pojemności 800mAh umożliwia pobranie właśnie 800mA przez całą godzinę, czyli wychodzi na to, że mamy około godziny latania! To wygląda bardzo optymistycznie.

Można pomyśleć o mniejszej pojemności baterii, np. 250mAh – wówczas będziemy mogli latać tylko ~1/3 godziny (bo taka bateria dostarcza prąd 250mA przez godzinę, a my potrzebujemy 800mA), ale… zyskujemy na wadze! Taki akumulator waży TYLKO 6.6g ! Można też lekko zmniejszyć masę naszej konstrukcji wybierając pakiet 560mAh (waga 11g), co jest niezłym kompromisem. Trzeba to przemyśleć (albo kupić kilka pojemności takich aku). Obowiązkowo zachęcam do poczytania o bateriach Li-Poli przed ich zakupem i używaniem.

Inne silniczki i śmigła

Poniżej przedstawiam zawartość swojej „spóźnionej” paczuchy…

Czyli: kilka (tanich) śmigieł (30mm oraz 60mm), oraz mikro silniczki szczotkowe 716 (po dwa CW i CCW – na wszelki wypadek, gdybym przypadkiem je przepalił czy inaczej uszkodził – są tanie, za to przesyłka droga). Silnik prezentowany na zajęciach MT 62 okazał się słaby w porównaniu do 716-tki (wydaje się odpowiedni do sterowania, ale nie do uzyskiwania ciągu balona).

Uważaj! Pracuja z szybkoobrotowymi silniczkami z zamontowanymi śmigłami jest niebezpieczna – uważaj na palce, oczy i zadbaj o bezpieczeństwo!

716-tka – maleństwo o masie ~3g ze śmigłami (+1 g?) 60mm daje czadu! Przy okazji: śmigła miały za duży otwór (chyba 1mm) więc je zaklinowałem (nóżka od rezystora 1/4W okazała się w sam raz) aby wał mojego 716 siedział sztywno – zadbaj o to i Ty!

napięcie [V]	prąd [A]	ciąg [g]
1	0.42	15
2	0.8,0.66,1.04	28,20,39
3	1.8,1.63	64,62
3.7	2	69

W tabelce zwróć uwagę na DUŻY PRĄD pracy silniczka – pamiętaj, że to tylko jedna sztuka, a są (chyba) potrzebne 2. Przy takich prądach trzeba stosować odpowiedni sterownik. No i uważać na grzanie się układu (sterowniki DRV8833 mają zabezpieczenia termiczne wyłączające układ, gdy temeratura jest zbyt wysoka – trzeba mieć to na uwadze). Dodatkowo: przy napięciach 2 i 3V podałem kilka pomiarów (wartości po przecinkach) – byłem zaskoczony bardzo niestabilną pracą maleństwa 716! To może być problem…

A jak mikro silniczek szczotkowy 716 działa z malutkim śmigłem 30mm (CX-10)? Wydawało mi się, że szkoda na to czasu, a tu jednak miła niespodzianka!

napięcie [V]	prąd [A]	ciąg [g]
1	0.07	2
2	0.16	6
3	0.28	11
3.7	0.42	17

I właśnie taki wariant wydaje się bardzo obiecujący – prąd „zjadany” przez silniczek jest akceptowalny do tego projektu, a jego ciąg też sensowny. Sądzę, że warto kupić parę innych zestawów śmigieł i jeszcze poeksperymentować (są tanie, nie ma biedy).

Wyciek helu

Balon gubi gaz… te aluminiowe gubią powoli (szczególnie w porównaniu do gumowych balonów, dla których zalecane jest kupno specjalnego sprayu). Chyba najbardziej gaz ucieka przez „zawór” – warto o to zadbać, dobrze go wiążąc.

Rozpocząłem pomiary (dopiero) 12-go stycznia 2019 (zakup 5-go stycznia) i już wyraźna część helu uciekła – patrz zdjęcie. Przyczepiłem balon do czegoś ciężkiego (u mnie kluczyk, zresztą widoczny na zdjęciu), przywiązałem nitką krawiecką do balona (bo wytrzymała i lekka!) ale jeszcze nitki nie puściłem – mój układ (kluczyk) ważył 35.7 g. Po puszczeniu nitki balon chciał poderwać kluczyk, ale wyporność była za mała i jedynie zmniejszył wskazania wagi. Rejestrowałem te zmiany w czasie (21 g, 24 g,…,35.2 g), przed każdym pomiarem sprawdzając „kalibracje” – ważyłem kluczyk, trzymając nitkę i sprawdzałem, czy mam 35.7 g. Dopiero potem dokonywałem pomiaru – widziałem, jak kluczyk robił się „coraz cięższy”.

Poniżej wykres przedstawia zależność siły nośnej w funkcji czasu – siła („udźwig”, czyli masa początkowa 35.7g minus wskazania wagi kluczyka) maleje, bo gaz ucieka…

Ciekawa sprawa z tym wykresem – bo jest liniowy (szkoda, że tak późno rozpocząłem swoją zabawę w ważenie kluczyka, bo może początek był nieliniowy – tego bym się spodziewał, ze względu na większe ciśnienie na początku). Może to też oznaczać, że wyciek helu odbywa się nie przez powierzchnię balona, a głównie przez „zawór” – ten pozostaje cały czas tak samo „ściśnięty” (niedoskonały).