Dzisiejszy temat kompletuje Świętą Trójcę największych pytań na grupach dla programistów embedded. Dwa pozostałe tematy – wybór mikrokontrolera i wybór języków omawialiśmy w poprzednich wpisach. Dzisiaj zajmiemy się wyborem tematów na własne projekty embedded. Zawęzimy temat właśnie do prywatnych projektów. Zarówno tych na początek przygody z programowaniem embedded, jak i tych na później. Nie będziemy natomiast omawiać projektów komercyjnych – to temat na oddzielną dyskusję.

Po co robimy własne projekty?

Przede wszystkim robimy je do celów edukacyjnych

Chcemy nabrać praktyki z konkretnymi językami, procesorami, narzędziami programistycznymi, czujnikami, bibliotekami, protokołami komunikacyjnymi itd.

To nasza piaskownica, gdzie możemy przetestować różne koncepcje, zobaczyć czy porady z internetu faktycznie nam pomogą. Możemy też sprawdzić jakie są trudności wdrażania poszczególnych technik i narzędzi zanim przeniesiemy je do projektu komercyjnego. Tutaj nikt nam niczego nie zabroni, niczego nie zepsujemy (no dobra, czasem spalimy jakiś układ), możemy na własnej skórze zobaczyć, czy dane podejście nam się podoba.

Aby pochwalić się projektem podczas rekrutacji

Link do GitHuba dodajemy do CV, a opowiadanie o projektach jest nieodłącznym elementem rozmowy technicznej. Doświadczonych programistów pyta się o projekty komercyjne. Ale osoby wchodzące do branży muszą pochwalić się projektami ze studiów, albo tymi robionymi w domu. Z takiej rozmowy można bardzo dużo dowiedzieć się o naszym podejściu do programowania i czy będziemy pasować na dane stanowisko. Może to banał, ale na rozmowie musimy pokazać pasję do programowania. Jeżeli robimy projekt, który nas interesuje, to przychodzi nam naturalnie.

Dla własnej satysfakcji

To również bardzo ważna motywacja dla naszych projektów. Po prostu są takie tematy, które cały czas za nami chodzą. Musimy do nich usiąść. A kiedy projekt się uda po prostu jesteśmy szczęśliwi, że go zrealizowaliśmy. Czasem satysfakcję dają nam zastosowane metody realizacji projektu np. przejrzystość kodu, architektura, konfiguracja narzędzi.

Żeby samemu używać

Nieraz mamy pomysły na projekty związane z naszym domem, czy hobby – sterowanie oświetleniem, podlewanie kwiatów, kontroler akwarium czy licznik rowerowy. Ale uważaj – taki projekt może okazać się miną!

Nic bardziej nie frustruje niż wstrzymywanie remontu mieszkania, bo nie mieliśmy czasu napisać sterownika do pieca. Nie rób tak – jeżeli czegoś potrzebujesz na już, kup gotowe części. Dopiero jak w domu wszystko działa baw się z własnym projektem. Najwyżej podepniesz swoje rozwiązanie kiedy indziej. Nie odbieraj sobie przyjemności z projektu nakładając niepotrzebnie presję. Walkę z przekroczonymi deadline’ami zostaw sobie na pracę zarobkową.

Myślimy o komercjalizacji

Każdy marzy, aby projekt do szuflady stał się docelowo prawdziwym produktem i początkiem własnego startupu, albo biblioteki open-source wykorzystywanej w tysiącach projektów. Niestety taki scenariusz bardzo rzadko się realizuje. Po raz kolejny – mając od początku taką motywację nakładamy na siebie dodatkową presję odbierając radość z realizacji projektu.

Warto też pamiętać, że komercyjne produkty realizują konkretne potrzeby biznesowe, potrzebują feedbacku od realnych klientów. Jeżeli nie trafimy w oczekiwania rynku – nasz produkt nie odniesie sukcesu. Widzisz więc, że takie podejście wymaga nieco innego mindsetu. I przypomina bardziej komercyjny projekt albo bycie przedsiębiorcą.

Dlatego na początku może lepiej odpuścić sobie tak wielkie ambicje i po prostu zacząć z projektem. Być może później dopiero wyewoluuje w coś ciekawego, czym możemy podzielić się ze światem.

Cele projektu

Robiąc prywatny projekt najczęściej mamy więc inne cele niż w przypadku projektów komercyjnych. Warto zdawać sobie z nich sprawę, aby uniknąć nieporozumień.

Najczęściej prawdziwe cele takich projektów to:

  1. Zdobycie umiejętności.
  2. Sprawdzenie konkretnych narzędzi/rozwiązań.
  3. Dopiero potem wartość użytkowa.

Z tego wynika ciekawy wniosek. Dojście do niego zajęło mi trochę czasu. Ale było warto, bo dzięki temu własne projekty stały się dużo większą frajdą:


Nie musisz dokończyć projektu, aby uznać go za udany.

Tak naprawdę prawie żaden projekt domowy nie zostaje skończony. Nawet jak zrealizujemy początkowe założenia, w międzyczasie dochodzą kolejne. A projekty prowadzimy na tyle nieformalnie, że potem sami nie pamiętamy jaki był nasz początkowy cel.

Jednym z moich prywatnych projektów był robot micromouse. Nigdy go nie dokończyłem, nigdy nie wystartowałem w nim w zawodach, nigdy nawet nie przejechał żadnego labiryntu. Według typowych kryteriów oceny projektu – kompletna klęska. Dopiero z perspektywy czasu dotarło do mnie, że:

  • Dzięki niemu dostałem pierwszą pracę w embedded. Zostałem zarekrutowany podczas Trójmiejskiego Turnieju Robotów, kiedy miałem być sędzią zawodów Micromouse.
  • Ten blog powstał początkowo po to, żeby opisywać postępy prac nad projektem (tutaj archiwum wpisów o micromouse).
  • Dzięki niemu projektowałem PCB, projektowałem części do druku 3d, dobierałem silniki i przekładnie – nabrałem umiejętności niezwiązanych z programowaniem.
  • Na tym projekcie sprawdzałem różne frameworki do unit testów, build systemy, narzędzia do analizy statycznej, podejścia do zarządzania projektem – to wszystko później wykorzystywałem w pracy.

Projekt był więc niesamowitym sukcesem i miał ogromny wpływ na moją karierę zawodową.

Dlatego warto sobie zadać pytanie dlaczego chcemy poświęcić wolny czas na robienie akurat tego projektu? Co musimy osiągnąć, aby spełnił swoje zadanie? Dzięki temu oszczędzimy sobie wiele frustracji. Szczególnie polecam takie podejście osobom pracującym w branży i robiącym czasem własne projekty z doskoku. Z racji pracy nie mamy tyle czasu i energii na własny projekt, a niebezpieczeństwo frustracji rośnie.

Czego prywatny projekt Cię nie nauczy?

Tutaj będzie wiele punktów, ale wszystkie mają jeden wspólny mianownik.

Współpracy z ludźmi

Najczęściej taki projekty robimy sami. Oczywiście możemy robić go ze znajomymi (jest też open source, ale to już trochę jak projekt komercyjny). Ale prawda jest brutalna – projekty wieloosobowe zwykle szybko umierają. Na początku praca przez chwilę się układa. Potem przychodzi przerwa i już nigdy do niego nie wracamy.

Na projekt przeznaczamy swój wolny czas, inni też. Nie możesz wymagać, że będą dostępni. Poza tym nikt nie chce zużywać wolnego czasu z fajnym projektem na pisanie dokumentacji, taski, meetingi i inne nudne, ale niezbędne rzeczy. W ten sposób płynnie przechodzimy do kolejnego punktu

Procesów wytwarzania oprogramowania

Takie procesy zwykle zakładają współpracę i komunikację wielu osób. Komunikacja to jest najtrudniejszy aspekt komercyjnego projektu i procesy starają się przedstawić rozwiązanie. Nie nauczymy się więc komunikacji z klientem, zbierania wymagań, negocjacji terminów, zmian zakresu projektu w trakcie, ani metodologii prowadzenia projektu takich jak Agile czy V-Model.

Niektórych narzędzi projektowych

To kolejny aspekt związany z współpracą wielu osób. Zwykle w większych projektach proces wprowadzania zmian zakłada tickety w Jirze, odpowiednie gałęzie w Gicie, Code Review, Continuous Integration, sprawdzenie przez narzędzia do analizy kodu, przejście testów, dokumentację itd.

Kiedyś próbowałem te wszystkie kroki symulować w prywatnych projektach. Ale to przerost formy nad treścią. Po pewnym czasie olewałem pojedyncze kroki, aż w końcu rezygnowałem. W projekcie hobbystycznym te kroki są ok, żeby poznać narzędzia, ale na przykład nie zrobisz sam sobie rzetelnego Code Review. Więc po co tracić czas na sztuczne operacje.

Dlatego do własnych projektów polecam uproszczony zestaw narzędzi np. prosty branch model w gicie, jak koniecznie chcemy CI to GitHub Actions żeby zobaczyć z czym to się je, a nie własny serwer CI z testami na HW, generowaniem wszystkich możliwych raportów i konfiguracją trwającą miesiąc. Zawsze jak projekt się rozrośnie – możemy stopniowo rozbudowywać zestaw narzędzi.

Czy własne projekty są przez to gorsze?

Absolutnie nie! Nie ma w tym nic złego. Jak byśmy robili mały projekt komercyjny, pewnie działalibyśmy tak samo. Nie dodajemy wszystkich elementów od razu. Zwykle robimy najpierw MVP (Minimum Viable Product) i dopiero kiedy się przyjmie – mamy budżet na rozbudowanie projektu i dodanie fajerwerków.

Dlatego tych wszystkich aspektów nauczysz się w projektach komercyjnych. Podczas współpracy z innymi ludźmi. Pracując 8 godzin dziennie od poniedziałku do piątku, a nie z doskoku.

Warto też wspomnieć, że jeden projekt nie wystarczy, aby to wszystko poznać. Potrzebujesz doświadczenia z kilku. Zobaczysz różnice. Widzisz co się sprawdza, a co nie. W jakich przypadkach dane podejście działa i od czego to zależy. Zobaczysz, że są różni programiści, managerowie, projekty, firmy, klienci i ich zachowanie wpływa również na aspekty techniczne projektu.

Najważniejsze różnice

Podsumujmy więc najważniejsze różnice między projektami hobbystycznymi a komercyjnymi. Tak naprawdę te nie są one zbyt odkrywcze, ale to z nich wynikają ograniczenia i różnice w realizowanych celach.

Projekt komercyjny:

  • Jest nastawiony na zysk.
  • Twoja praca również jest nastawiona na zysk.
  • Stabilne godziny pracy – 8h, 5 dni w tygodniu, to Twój główny priorytet.
  • Współpracujesz z wieloma osobami.
  • Wiele decyzji jest narzucanych z góry.

Projekt prywatny:

  • Nie jest nastawiony na zysk finansowy, nie musi być nawet dokończony.
  • Twoją motywacją do pracy również nie jest zysk.
  • To nie jest Twój priorytet, przeznaczany czas jest zmienny.
  • Współpraca z ludźmi ograniczona do minimum.
  • Masz władzę nad wszelkimi decyzjami – i związaną z tym niezależność.
  • Odpowiadasz za wszystkie aspekty – programowanie, części, elektronikę, mechanikę, narzędzia, wymagania, planowanie, priorytety zadań.

Najważniejsze narzędzie w każdym projekcie

Zanim przejdę do tego jak wybierać projekt, jak dobierać tematy do nauki, co robić na początku, a co jako zaawansowany programista – musze na chwilę zatrzymać się na jednej mega ważnej rzeczy.

Największym skokiem cywilizacyjnym w projekcie jest dodanie systemu kontroli wersji. Dlatego już podczas pierwszego większego projektu powinniśmy zacząć naukę Gita. Kontrola wersji jest wymagana w każdej firmie i musimy się tego nauczyć przed pierwszą rekrutacją. Pierwsze projekty są do tego idealne. Poza tym pozwolą nam wypełnić porfolio na GitHubie.

Dlaczego kontrola wersji zmienia wszystko? Posłuchaj mojej historii:

Ok, teraz możemy przejść do wskazówek co do tematyki i zakresu projektów.

Jaki wybrać projekt?

Oczywiście to zależy na jakim jesteśmy poziomie, co chcemy osiągnąć, ile możemy przeznaczyć czasu, w jakim kierunku chcemy się rozwijać. Ale spróbuję sformułować kilka zasad. Zacznę od projektów dla początkujących. Potem będę dodawać kolejne poziomy komplikacji.

I tutaj musimy dokładnie określić, co już jest projektem, a co tylko zadaniem/przykładem. Jak dla mnie projekt wykorzystuje wiele peryferiów procesora i realizuje kilka niezależnych od siebie zadań. Na przykład pomiar z ADC, przesłanie go przez DMA i wysłanie przez UART wykorzystuje kilka peryferiów, ale realizuje jedno logiczne zadanie. Więc to jeszcze nie będzie projekt.

Z kolei robot mobilny omijający przeszkody, który steruje silnikami za pomocą Timerów i GPIO, wykrywa przeszkody za pomocą czujników i po wykryciu przeszkody modyfikuje sterowanie silnikiem już będzie projektem. Nie będę tutaj silić się na precyzyjne definicje, ale mam nadzieję, że wyczuwacie różnicę.

Moim zdaniem pierwszy projekt powinien być w miarę prosty i opierać się na pętli głównej, przerwaniach i kilku peryferiach. Wspomniany wyżej robot omijający przeszkody to świetny projekt na start.

W trakcie projektu będziemy podejmować decyzje dotyczące poszczególnych modułów, sposobu realizacji zadań, współpracy między peryferiami. Aby się na tym skupić musimy już coś umieć. Dlatego do pierwszego projektu siadamy, gdy potrafimy w miarę programować w C i znamy peryferia procesora. Czyli mamy za sobą trochę przykładów działających na sprzęcie. Oczywiście w trakcie projektu wyjdzie wiele nowych pól do nauki. I bardzo dobrze. W końcu taki był cel. Ale nie chcemy się zatrzymać na amen,zniechęcić i porzucić kompletnie programowanie. Dlatego wstępna wiedza jest potrzebna.

Rozbudowywanie projektu

W kolejnych krokach możemy coraz bardziej rozbudowywać istniejące projekty. Albo zrobić nowe wykorzystujące kolejne elementy. Możemy dodać RTOSa, zewnętrzne biblioteki, kolejne peryferia i urządzenia zewnętrzne.

Na pewno warto zrobić projekt wykorzystujący typowe dla embedded elementy interfejsy użytkownika – przyciski z debouncingiem, LEDy, wyświetlacze, konsolę na porcie szeregowym. Obsługa tych interfejsów jest na początku nieintuicyjna i trzeba się przyzwyczaić. A połączenie odczytu wejść i wyświetlania wyjść może być jednym z pierwszych praktycznych wyzwań na poziomie architektury.

A później dodajemy kolejne elementy w zależności czego się chcemy nauczyć. Możliwości jest bardzo dużo:

  • Protokoły komunikacyjne – np. CAN, Bluetooth, Modbus
  • Webserwery – na ETH lub WiFi
  • Projekty wieloprocesorowe
  • Bootloadery, Low Power
  • Projekty zbierające dane np. do EEPROM i do serwera
  • Machine learning
  • DSP

Polecam również pisanie kilka razy tych samych projektów z dodatkowymi ograniczeniami. Wtedy nie rozwiązujemy kilku problemów na raz. Na przykład wiemy jakie jest docelowe rozwiązanie od strony sprzętu i chcemy je zaimplementować w innym języku. To idealny sposób nauki nie tylko Rusta, czy C++, ale również testów automatycznych, CMake, nowych edytorów kodu, czy narzędzi do statycznej analizy. Możemy też pójść w drugą stronę i przeportować projekt na nowy procesor ucząc się w ten sposób peryferiów i poruszania po dokumentacji.

Seria na YT o projekcie zegara szachowego pokazuje ewolucję projektu. Moim założeniem było stworzenie prostego prototypu i dodawanie kolejnych elementów dopiero kiedy są potrzebne. To dobrze się sprawdza przy własnych projektach. W końcu nie chcemy tracić miesięcy na konfigurację.

Pomysły na projekt

Jeżeli brakuje Ci konkretnych pomysłów na projekt – sprawdź poniższą listę (wiele z tych propozycji padało już wcześniej):

  • Proste roboty mobilne – światłolub, omijacz przeszkód, sumo, line follower
  • Urządzenia do automatyki domowej – sterowanie oświetleniem, ogrzewaniem, zbieranie danych z czujników w domu, wyświetlanie ich na telefonie/stronie
  • Dosyć podobnym projektem jest stacja pogodowa – zbieranie danych z czujników i ich prezentacja w przyjaznym formacie + zbieranie danych historycznych
  • Projekty związane z hobby – sterownik podlewania roślin, sterownik akwarium, licznik rowerowy, zegar szachowy
  • Trudniejsze roboty mobilne – platforma z manipulatorem, kroczący, micromouse

Na popularnych polskich forach znajdziesz działy, gdzie ludzie chwalą się gotowymi projektami:

A poza tym polecam sprawdzić kilka fantastycznych projektów:

  • Projekty Bartłomieja Ufnalskiego – Bartłomiej pracuje na Politechnice Warszawskiej i prowadzi zajęcia na STM32 w ramach których publikuje ogromną ilość projektów idealnych dla początkujących.
  • Rustmass – sterownik oświetlenia na choinkę  – o tym projekcie pisałem już sporo w relacji z grudniowego meetupu. To jest super projekt łączący w sobie ciekawe rozwiązania techniczne, zastosowanie we własnym domu i potencjał komercyjny.
  • Evil Submarine – to jest niesamowity projekt interaktywnej gry wykorzystującej to co było pod ręką. Został stworzony przez członków Hackerspace Trójmiasto. Mamy różne ekrany, oscyloskopy z figurami Lissajous, panel z przyciskami od pralki, odtwarzanie dźwięków i wideo. Pod spodem siedzą Arduino i Raspberry Pi. W efekcie otrzymujemy kokpit łodzi podwodnej i różne zadania do wykonania.

Podsumowanie

W temacie własnych projektów pamiętaj o kilku rzeczach:

  • Celem projektu najczęściej jest nauka – nie musisz go dokończyć, aby spełnił cel
  • Zanim weźmiesz się za projekty opanuj podstawy (programowania i mikrokontrolerów)
  • Podczas projektu zawsze używaj systemu kontroli wersji, najlepiej gita
  • Zacznij od czegoś prostego, a potem dodawaj nowe elementy
  • Niektórych rzeczy nauczysz się w pełni jedynie w komercyjnych projektach

Pamiętaj jeszcze o jednym. Na złożoność projektu składają się dwa aspekty. Złożoność techniczna związana z programowaniem, elektroniką, narzędziami itp. Oraz złożoność domeny związana z problemem, który rozwiązujemy. Jeżeli robimy projekt odczytujący dane z samochodu – musimy mieć wiedzę o samochodach, jeżeli robimy sterownik klimatyzacji – musimy mieć wiedzę o klimatyzacji. Chyba rozumiesz do czego zmierzam. Aby zrobić dobrze projekt z danej domeny, musisz zdobyć odpowiednią wiedzę o tej domenie.

A jeżeli interesuje Cię temat rozwoju w branży embedded – już w środę 13 marca zapraszam na webinar: Jak wejść do branży embedded w 2024 roku?