PRACA DYPLOMOWA MAGISTERSKA - production · PRACA DYPLOMOWA MAGISTERSKA Przemysław Ogorzałek...
Transcript of PRACA DYPLOMOWA MAGISTERSKA - production · PRACA DYPLOMOWA MAGISTERSKA Przemysław Ogorzałek...
Rok akademicki 2013/2014
POLITECHNIKA WARSZAWSKA
Wydział Elektroniki i Technik Informacyjnych
Instytut Informatyki
PRACA DYPLOMOWA MAGISTERSKA
Przemysław Ogorzałek
Projekt zabawki edukacyjnej dla dziecka
Opiekun pracy
dr inz. Wiktor Dzaszczuk
Ocena:................................................
......................................................
Podpis Przewodniczacego
Komisji Egzaminu Dyplomowego
Kierunek: Informatyka
Specjalnosc: Inzynieria Systemów Informacyjnych
Data urodzenia: 1989 06 01
Data rozpoczecia studiów: 2012 02 20
ZYCIORYSPrzemysław Ogorzałek ukonczył w 2012 roku studia pierwszego stopnia na wydziale Elektro-
niki i Technik Informacyjnych Politechniki Warszawskiej na kierunku Elektronika, Informatyka
i Telekomunikacja. Nastepnie podjał studia drugiego stopnia na tym samym wydziale, na kie-
runku Inzynieria Systemów Informacyjnych.
W roku 2011 odbył trzymiesieczne praktyki inzynierskie w firmie InventLab S. C., od
lipca 2012 roku pracuje jako inzynier oprogramowania w firmie Wincor Nixdorf.
Jego zainteresowania zawodowe skierowane sa w strone programowania, zarówno na po-
ziomie software’u (jezyki C, C++, Java, Python), jak równiez hardware’u (jezyki VHDL
i Verilog). Zajmuje sie równiez administracja systemami Linux, zarówno na poziomie
komputerów osobistych, jak równiez serwerów i urzadzen wbudowanych.
.....................................................
Podpis studenta
EGZAMIN DYPLOMOWY
Złozył egzamin w dniu.............................................................................................2014 r
z wynikiem..........................................................................................................................
Ogólny wynik studiów:.......................................................................................................
Dodatkowe wnioski i uwagi Komisji:.................................................................................
.............................................................................................................................................
.............................................................................................................................................
Streszczenie
Projekt zabawki edukacyjnej dla dziecka
Nauka poprzez zabawe uwazana jest za jedna ze skuteczniejszych form sty-
mulacji rozwoju dzieci. Zaowocowało to powstaniem szerokiego rynku zabawek
edukacyjnych.
Aby zachecic dziecko do zabawy konieczne jest zapewnienie interesujacej
oprawy, dostarczenie wyzwania na odpowiednim poziomie oraz postawienie go
w roli głównego bohatera fascynujacej opowiesci. Zabawka powinna oferowac
wiele mozliwosci i scenariuszy, by podtrzymac zainteresowanie uzytkownika.
Ponizsza praca zawiera projekt zabawki, majacej na celu zachecenie dziecka
do zgłebienia podstaw elektroniki. Pozwoli ona zapoznac sie zarówno z aspektami
teoretycznymi jak i praktycznymi tworzenia układów elektronicznych, pobudzajac
jednoczesnie uzytkownika do korzystania z innych dziedzin wiedzy.
Dzieki modułowemu charakterowi zabawki dziecko doswiadczy wielu godzin
edukacyjnej zabawy przechodzac przez liczne scenariusze.
Słowa kluczowe: zabawka, edukacja, elektronika, Arduino, Bluetooth
__________________________________________________________________
Abstract
Educational toy for children
Learning by playing is considered to be one of the best ways of stimulating
child’s development. It led to creation of a large market of educational toys.
In order to encourage the child to play, it’s important to provide interesting
setting, a proper challenge, and make it feel like a main character of a fascinating
story. The toy should offer many possibilities and scenarios to keep user’s attention.
This paper is contains a project of toy, which is supposed to encourage children
to learn basics of electronics. It will let the user to face both theoretical and practical
aspects of creating electronic circuits, and allow him to make use of his knowledge
from other fields.
Toy’s modularity will let the child enjoy it for many hours, by playing with
different scenarios.
Keywords: toy, education, electronics, Arduino, Bluetooth
Spis tresci
1 Wstep 8
1.1 Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 Cel pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Załozenia pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Koncepcja rozwiazania 10
2.1 Opis zabawki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1 Cele edukacyjne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.2 Profil potencjalnego uzytkownika . . . . . . . . . . . . . . . . . . . . 11
2.1.3 Motyw przewodni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.4 Scenariusz zabawy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.5 Konstrukcja i wyglad zabawki . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Opis funkcjonalny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Komponenty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3 Projekt 21
3.1 Kontroler bomby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.1 Wymagania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.2 Przeglad wybranych rozwiazan . . . . . . . . . . . . . . . . . . . . . 23
3.1.3 Decyzja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Komunikacja bezprzewodowa . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.1 Wymagania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.2 Przeglad wybranych technik . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.3 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4 Realizacja 40
4.1 Aplikacja PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1.1 Zasada działania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1.2 Wybór jezyka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.3 Implementacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2 Bomba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3
4.3 Komunikacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3.1 Protokół komunikacyjny . . . . . . . . . . . . . . . . . . . . . . . . . 53
5 Napotkane problemy 57
5.1 Modem Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6 Mozliwosci rozwoju 61
6.1 Dalsze prace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.2 Moduły uzyteczne w innych projektach . . . . . . . . . . . . . . . . . . . . . 62
6.3 Migracja na platformy mobilne . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.4 Tryb wieloosobowy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7 Podsumowanie i wnioski 67
7.1 Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.1.1 Platforma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.1.2 Protokół komunikacyjny . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.1.3 Wybór jezyka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.1.4 Implementacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.1.5 Rezultat projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.2 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A Typy i formaty rekordów 74
B Obsługiwane elementy 76
C Przykłady opisu stanów portów 78
D Przykładowy scenariusz 79
E Przykładowy scenariusz 80
WYKAZ SKRÓTÓW
• ARM - Advanced RISC Machine, 32-bitowa architektura procesorów typu RISC, popu-
larna w systemach wbudowanych
• ASIC - Application Specific Integrated Circuits, układ cyfrowy przeznaczony do konkret-
nego zadania, bez mozliwosci przeprogramowania
• CPU - Central Processing Unit, urzadzenie pobierajace dane z pamieci i wykonujace na
nich stosowne operacje, na podstawie zdefiniowanych rozkazów
• CSMA/CA - Carrier Sense Multiple Access with Collision Avoidance, protokół warstwy
łacza umozliwiajacy sledzenie stanu medium w celu unikania kolizji
• CSV - Comma-Separated Values, format danych tekstowych, w którym pola pojedyn-
czego rekordu oddzielone sa okreslonym znakiem (zazwyczaj przecinkiem, od którego
pochodzi nazwa formatu)
• DHCP - Dynamic Host Configuration Protocol, protokół dynamicznej dystrybucji konfi-
guracji parametrów sieci
• DSP - Digital Signal Processor, procesor specjalizowany do obsługi sygnałów elektrycz-
nych
• EEPROM - Electrically-Erasable Programmable Read-Only Memory, nieulotna pamiec,
której zawartosc zmienic mozna jedynie przy pomocy sygnału elektrycznego, wykorzy-
stywana w systemach wbudowanych przechowywania danych, które musza byc dostepne
po właczeniu zasilania
• FPGA - Field Programmable Gate Array, programowalny układ cyfrowy oparty na blo-
kach logicznych
• GNU/GPL - GNU General Public License, licencja wykorzystywana w dystrybucji wol-
nego oprogramowania
• GPU - Graphics Processing Unit, urzadzenie specjalizowane pod katem przetwarzania
danych w celu uzyskania obrazu
5
• HDMI - High-Definition Multimedia Interface, interfejs dedykowany do przesyłania nie-
skompresowanego obrazu i dzwieku
• I2C - Inter-Integrated Circuit, szeregowa, dwukierunkowa szyna słuzaca do przesyłu da-
nych
• IEEE - Institute of Electrical and Electronics Engineers, miedzynarodowe stowarzysze-
nie inzynierów z dziedziny układów elektrycznych i elektronicznych
• IP - Internet Protocol, bezpołaczeniowy protokół okreslajacy działanie sieci pakietowej
• ISO - International Organization for Standardization, miedzynarodowa organizacja zrze-
szajaca krajowe organizacje normalizacyjne, w celu opracowywania jednolitych norm
i standardów
• ITU-T - International Telecommunication Union - Telecommunication Standardization
Sector, miedzynarodowa organizacja zajmujaca sie tworzeniem standardów sieci teleko-
munikacyjnych
• JNI - Java Native Interface, interfejs umozliwiajacy uruchamianie na maszy-
nie wirtualnej Javy kodu napisanego w jezykach C, C++ i Assembler
• LCD - Liquid-Crystal Display, wyswietlacz, którego działanie oparte jest o zmiany pola-
ryzacji swiatła poprzez manipulowanie stanem czasteczek ciekłego kryształu
• MOS - Mean Opinion Score, subiektywna ocena jakosci systemu przez grupe uzytkowni-
ków
• NFC - Near-Field Communication, radiowy standard komunikacji na bliska odległosc
przy pomocy fal o wysokiej czestotliwosci
• OSI - Open Systems Interconnection, inicjatywa na rzecz standaryzacji sieci komputero-
wych podjeta przez organizacje ISO i ITU-T
• PAN - Personal Area Network, siec komputerowa złozona z urzadzen osobistych takich
jak komputery i telefony, charakteryzuje sie niewielkim zasiegiem
• PIN - Personal Identification Number, ciag cyfr poswiadczajacy tozsamosc lub upraw-
nienia uzytkownika
6
• PWM - Pulse-Width Modulation, metoda symulacji sygnału analogowego przy pomocy
sygnału cyfrowego za pomoca zmian długosci impulsu elektrycznego
• RAM - Random Access Memory, pamiec umozliwiajaca szybki zapis i odczyt danych
• RISC - Reduced Instruction Set Computer, koncepcja projektowania procesorów polega-
jaca na uproszczeniu listy dostepnych polecen w celu poprawy wydajnosci
• ROM - Read-Only Memory, pamiec tylko do odczytu, programowana przy pomocy sto-
sownych urzadzen, przechowujaca dane po utracie zasilania
• SBC - Single Board Computer, komputer (procesor, pamiec i układy wejscia/wyjscia)
osadzony w pojedynczym układzie scalonym
• SD - Secure Digital, uniwersalny format kart pamieci nieulotnej
• SoC - System-on-Chip, system elektroniczny składajacy sie z wielu modułów (cyfrowych
i analogowych) znajdujacy sie na pojedynczym układzie scalonym
• SoRC - System-on-Reprogrammable-Chip, system elektroniczny znajdujacy sie na poje-
dynczym układzie scalonym, którego zachowanie mozna modyfikowac w zaleznosci od
wgranego oprogramowania
• SRAM - Static Random Access Memory, rodzaj pamieci operacyjnej niewymagajacej okre-
sowego odswiezania
• TCP - Transmission Control Protocol, połaczeniowy protokół komunikacyjny umozliwia-
jacy bezbłedna wymiane danych
• UART - Universal Asynchronous Receiver/Transmitter, urzadzenie
umozliwiajace translacje danych przenoszonych przez rózne standardy komunikacji sze-
regowej i równoległej
• UDP - User Datagram Protocol, bezpołaczeniowy protokół komunikacyjny, pozbawiony
mozliwosci mechanizmów kontroli przepływu
• USB - Universal Serial Bus, uniwersalna magistrala do szeregowej transmisji danych
w systemie komputerowym
7
1 Wstep
1.1 Wprowadzenie
Janusz Korczak powiedział: „Dzieci nie sa głupsze od dorosłych, tylko maja mniej
doswiadczenia[1].” Jednym ze sposobów, by dorosli mogli przekazywac dzieciom to doswiad-
czenie, jest stawianie im ciekawych wyzwan. Niestety, wielu rodzicom i opiekunom trudno
osiagnac ten cel z powodu braku wiedzy, czasu, lub srodków.
Na przeciw tym potrzebom wyszedł rynek zabawek Coraz wiecej produktów, które bawia
uczac i ucza bawiac, pozwala dzieciom poszerzac swoje horyzonty.
Ponizsza praca przedstawia proces projektowania takiej zabawki, poczawszy od okresle-
nia załozen (funkcjonalnych, technicznych i biznesowych), az do szczegółów implementacji.
Zawiera tez analize wielu popularnych rozwiazan uzywanych w systemach wbudowanych pod
katem wykorzystania ich w specjalizowanym urzadzeniu konsumenckim.
1.2 Cel pracy
Celem pracy jest zaprojektowanie edukacyjnej zabawki dla dziecka. Projekt podzielony
został na trzy etapy:
1. Zdefiniowanie wymagan i załozen.
2. Wybór narzedzi, podzespołów i protokołów.
3. Stworzenie prototypu czesci elektronicznej i przykładowej aplikacji do jego obsługi.
Kazdy z etapów projektu został udokumentowany, ze szczególnym uwzglednieniem ana-
lizy wymagan funkcjonalnych i niefunkcjonalnych, oraz porównania dostepnych rozwiazan.
Opisane tez zostały implementacja i działanie gotowego urzadzenia, a takze interakcja poszcze-
gólnych elementów z otoczeniem i miedzy soba.
Efektem koncowym jest prototyp, pozwalajacy przetestowac podstawowe funkcje za-
bawki. Projekt zawiera ogólne wytyczne dotyczace oprawy i wygladu produktu koncowego,
jednak nie były one uwzglednione przy tworzeniu prototypu.
Doswiadczenia zdobyte w ramach pracy nad projektem wykorzystac mozna przy tworze-
niu wielu innych systemów wbudowanych. Z technicznego punktu widzenia zabawka stanowi
8
układ reaktywny wchodzacy w interakcje z otoczeniem i w uproszczony sposób komuniku-
jacy sie z uzytkownikiem o niewielkiej wiedzy technicznej. Podobnie scharakteryzowac mozna
wiele innych urzadzen, na przykład układy sterowania, autonomiczne pojazdy, lub urzadzenia
diagnostyczne. Projekt zabawki nalezy zatem potraktowac równiez jako eksperyment, którego
wyniki moga dostarczyc wielu uzytecznych wniosków w zakresie mozliwych do napotkania
w trakcie projektu problemów, efektywnosci uzytych rozwiazan i reakcji uzytkowników kon-
cowych.
1.3 Załozenia pracy
Podstawowym załozeniem projektu jest edukacyjny charakter zabawki. Oznacza to, ze
zabawa powinna stanowic dla uzytkownika wysiłek intelektualny, który zaowocuje rozwinie-
ciem jego wiedzy i umiejetnosci. W odróznieniu od tradycyjnych metod nauczania, takich jak
ksiazki, cwiczenia i wykłady, dziecko otrzymuje nagrode za swój trud natychmiast, co stanowi
skuteczniejsza motywacje niz sama obietnica sukcesów w zyciu dorosłym. Czasami wystarcza-
jaca nagroda jest mozliwosc „pokonania” gry lub zdobycie najwiekszej liczby punktów w ran-
kingu.
Drugim istotnym załozeniem jest przyjecie modelu biznesowego opartego na przykładzie
popularnych klocków firmy LEGO, w którym produktem sa zestawy małych elementów, które
mozna łaczyc na wiele sposobów. Rózne zestawy sa miedzy soba kompatybilne, a zatem mozna
wykorzystac kilka mniejszych zestawów do złozenia jednej duzej zabawki.
Trzecie i ostatnie załozenie to wykorzystanie komunikacji bezprzewodowej pomiedzy
elementami zabawki. Wybór konkretnej techniki przesyłu danych dokonany bedzie w dalszej
czesci projektu.
9
2 Koncepcja rozwiazania
2.1 Opis zabawki
2.1.1 Cele edukacyjne
Jednym z podstawowych celów projektu jest zapewnienie wysokiej wartosci edukacyj-
nej finalnego produktu. W miare mozliwosci warto zadbac o rozwijanie wiedzy i umiejetnosci
uzytkownika w wielu dziedzinach. Interdyscyplinarnosc zapewnia nie tylko efektywniejszy roz-
wój młodego umysłu, ale równiez znaczaco poprawia atrakcyjnosc zabawy dostarczajac stale
nowych bodzców.
Ze wzgledu na zmiany społeczne i kulturowe wynikajace z nadejscia ery informacyjnej,
szczególnie silny nacisk nalezy kłasc na rozwój w zakresie nauk scisłych. Wiedza techniczna
i umiejetnosc logicznego myslenia, połaczona ze zdolnoscia do rozwiazywania problemów sa
szczególnie poszukiwane na rynku pracy[2]. Zachecenie młodego człowieka do zgłebienia pod-
staw nauk scisłych w formie „nauki przez zabawe[3]” moze miec pozytywny wpływ na całe
jego dorosłe zycie.
Jedna z gałezi nauk scisłych, która niewielkim kosztem mozna zaprezentowac w atrak-
cyjny sposób jest elektronika. Składanie nawet prostych układów moze zaspokoic naturalna
dla wieku dojrzewania potrzebe odkrywania swiata. Mozliwosc pochwalenia sie efektem kon-
cowym stanowi czesto dostateczna motywacje do działania, o ile mozna przedstawic go otocze-
niu w atrakcyjnej formie. Nalezy jednak zachowac ostroznosc, by nie przytłoczyc poczatkuja-
cego amatora nadmiarem informacji i nie zniechecic go do dalszej pracy.
Wazna umiejetnoscia, zanikajaca w alarmujacym tempie, jest równiez koncentrowanie sie
na wykonywanej pracy[4][5]. Od niedawna daje sie zaobserwowac w społeczenstwie problemy
z wykonywaniem przez jednostki powierzonych zadan zwiazane ze zle okreslonymi priory-
tetami bodzców. Zbyt czeste odrywanie sie od pracy w celu odwiedzenia portali społeczno-
sciowych i informacyjnych prowadzic moze do problemów w szkole, pracy i zyciu osobistym.
Zwiazane z tym złe nawyki mozna zwalczac dzieki odpowiedniej motywacji i cwiczeniom kon-
centracji. Efektywnosc takiego treningu zalezy od tego na ile interesujaca jest wykonywana
czynnosc oraz czy ewentualna nagroda warta jest włozonego wysiłku. Wazne jest tez wymu-
szenie działania z odpowiednia precyzja i nałozenie odpowiednich ograniczen, np. czasowych.
10
Po uwzglednieniu powyzszych czynników sprecyzowac mozna edukacyjne cele zabawki:
1. Interdyscyplinarnosc, ze szczególnym naciskiem na nauki scisłe.
2. Wykorzystanie potencjału elektroniki w celu uatrakcyjnienia nauki poprzez zabawe.
3. Postawienie uzytkownikowi wyzwania skłaniajacego do poswiecenia zagadnieniu pełnej
uwagi.
2.1.2 Profil potencjalnego uzytkownika
Istotnym etapem projektowania kazdego produktu jest okreslenie profilu docelowego
uzytkownika. Niemozliwe jest stworzenie jednego rozwiazania optymalnego dla wszystkich
konsumentów. Mozna jednak zapewnic osiagniecie załozonych celów edukacyjnych i bizneso-
wych dla okreslonej grupy docelowej.
Przede wszystkim konieczne jest wyznaczenie przedziału wiekowego, dla którego pro-
dukt jest przeznaczony. Zabawki dla młodszych dzieci musza spełniac wysokie wymogi bez-
pieczenstwa i kłasc nacisk na element zabawy. Produkty skierowane do starszych dzieci i na-
stolatków pozwalaja im zdobyc aprobate i szacunek otoczenia.
Poniewaz w ramach załozonych celów edukacyjnych nacisk kładziony jest na rozwój
umiejetnosci technicznych, projektowana zabawka kierowana jest raczej do starszych odbior-
ców. W wieku około 12 lat dziecko posiada juz zwykle umiejetnosci czytania, pisania i obsługi
komputera. Równiez elementarna matematyka nie stanowi dla niego problemu. Dziecku w tym
wieku mozna tez powierzyc drobne i delikatne elementy bez obaw o jego bezpieczenstwo i bez
ryzyka ich zniszczenia.
Zabawka projektowana jest z mysla o osobach zainteresowanych rozwijaniem swojej wie-
dzy, dla których szkolny materiał stanowi zbyt małe wyzwanie intelektualne. Moze byc to rów-
niez sposób na przekonanie mniej pilnych uczniów, ze nauki scisłe to ciekawe hobby.
2.1.3 Motyw przewodni
Projektowana zabawka opiera sie na regularnie powtarzajacym sie w mediach motywie
rozbrajania bomby. W ksiazkach, filmach, serialach i komiksach bohaterowie czesto staja wo-
bec koniecznosci neutralizacji ładunku wybuchowego. Dla wiekszego dramatyzmu scenarzysci
zazwyczaj umieszczaja na urzadzeniu wyrazny, czerwony licznik pozostałego czasu. Bohater
czesto zmuszony jest korzystac z pomocy osób trzecich, posiadajacych odpowiednia wiedze
techniczna, lub zdobywa wskazówki od swoich przeciwników.
11
Młodzi ludzie chetnie stawiaja sobie za wzorce bohaterów kina akcji, imponujacych siła,
inteligencja i charakterem. Przemysł reklamowy czesto wykorzystuje popularnosc takich po-
staci sprzedajac licencjonowane zabawki, ubrania i przedmioty codziennego uzytku.
Na podobnej zasadzie opiera sie koncepcja motywu przewodniego projektowanej za-
bawki. Nalezy jednak podkreslic, ze nie jest wykorzystywany wizerunek konkretnej postaci, ale
motyw wspólny dla wielu historii. Dzieki temu uzytkownik moze w swojej wyobrazni wcielic
sie w ulubionego bohatera i samemu przezyc przygode.
2.1.4 Scenariusz zabawy
Uzytkowanie zabawki składa sie z dwóch etapów: składania i rozbrajania bomby.
Pierwszy z nich polega na złozeniu układu elektrycznego na podstawie zadanego sche-
matu. W zaleznosci od stopnia skomplikowania układu mozna ustalac rózne poziomy trudnosci
tej czesci zabawy. W zestawie z zabawka moze znalezc sie wiele róznych schematów. W razie
potrzeby uzytkownik sciaga nowe propozycje z Internetu lub projektuje własne układy.
Drugi etap polega na rozmontowaniu układu w okreslonej kolejnosci i w ustalonych wa-
runkach. Uzytkownik otrzymuje zestaw wskazówek w formie zagadek, których rozwiazania
okreslaja kolejny krok na drodze do rozbrojenia bomby. Poszukujac odpowiedzi młody czło-
wiek rozwija w sobie umiejetnosc logicznego myslenia i efektywnego korzystania ze zródeł.
Proces składania bomby czesto zawiera wiele cennych wskazówek, ułatwiajacych roz-
wikłanie zagadek. Przykładem moze byc tu zagadka, której rozwiazaniem jest umieszczenie
bomby w ciemnym pomieszczeniu. Jesli uzytkownik przestudiował załaczony do schematu
układu opis działania fotorezystora moze domyslic sie, ze wystarczy zasłonic ten czujnik za-
miast gasic swiatła w pokoju.
Aby dostarczyc uzytkownikowi dodatkowych emocji i lepiej odwzorowac sceny znane
z mediów, bomba obowiazkowo musi byc wyposazona w wyrazny licznik czasu. Jesli odli-
czanie dojdzie do zera lub uzytkownik popełni bład, bomba wybuchnie i zabawa sie skonczy.
Dodatkowe „zycia”, mozliwosc zapisu stanu zabawy lub zatrzymanie licznika nie sa przewidy-
wane. Jedno z podstawowych załozen gry brzmi „saper myli sie tylko raz”.
2.1.5 Konstrukcja i wyglad zabawki
Konstrukcja zewnetrznej obudowy zabawki ma znaczenie zarówno estetyczne, jak tez
funkcjonalne.
12
Atrakcyjny wyglad przyciagnie uwage uzytkownika i zacheci go do zabawy. Elementami
o znaczeniu estetycznym moga byc wyswietlacz czasu, migajace diody i głosniki symulujace
dzwiek tykajacego zegara lub wybuchajacej bomby. Stylistyka wykonania powinna nawiazy-
wac do klasycznych filmów akcji, które znaczaco przyczyniły sie do popularyzacji archetypu
bohatera rozbrajajacego bombe na sekundy przed upłynieciem czasu.
Odpowiednio zaprojektowana obudowa powinna ułatwiac uzytkownikowi składanie i in-
terakcje z układem elektronicznym. Z jednej strony wymaga to, by podłaczenie i odłaczanie ele-
mentów było jak najprostsze i nie wymagało specjalistycznych narzedzi. Wrazliwe elementy za-
bawki musza byc jednak zabezpieczone przed mozliwym uszkodzeniem. Błedne złozenie przez
uzytkownika bomby powinno zaowocowac stosownym komunikatem o błedzie, ale w zadnym
wypadku nie moze zakłócic działania całosci urzadzenia. Odpowiednia izolacja poszczególnych
elementów powinna zapobiec przypadkowym zwarciom w trakcie manipulacji układem.
Istotne jest równiez odpowiednie zaprojektowanie systemu gniazd i wtyczek. Aplikacja
PC weryfikuje poprawnosc złozenia układu na podstawie stanu portów kontrolera, jednak nie-
które elementy moga dawac poprawne wyniki nawet jesli sa błednie podłaczone (na przykład
uzytkownik zamienił miejscami kabel czerwony z niebieskim). Ponadto w przypadku wielu
elementów kluczowe znaczenie ma polaryzacja. Odwrotne podłaczenie diody lub kondensatora
elektrolitycznego moze w niektórych przypadkach zakonczyc sie ich uszkodzeniem.
Stworzenie duzego zbioru wtyczek o róznym kształcie moze zapobiec takim problemom
juz na etapie składania bomby, poniewaz nieprawidłowe podłaczenie niektórych elementów nie
bedzie mozliwe (na przykład do kwadratowego gniazda pasowac moga tylko kable o zielonej
izolacji lub katoda diody). Bardziej zaawansowani uzytkownicy moga korzystac z zestawów
bez podobnych ułatwien.
Projektujac wtyczki trzeba pamietac o zapewnieniu odpowiedniej wytrzymałosci. Mo-
dułowy charakter zabawki sprawia, ze poszczególne elementy beda wielokrotnie podłaczane
i odłaczane, a mniej doswiadczeni uzytkownicy moga próbowac umiescic wtyczke w niepasu-
jacym do niej gniezdzie. Zbyt słaba konstrukcja moze w krótkim czasie ulec uszkodzeniu.
Istotne jest takze odpowiednie zbalansowanie tego, jakiej siły wymaga wyjecie wtyczki.
Jesli połaczenie bedzie zbyt luzne, podłaczony element moze przypadkowo wypasc z obudowy
powodujac niezawiniona porazke uzytkownika. Jezeli siła wymagana do wyjecia wtyczki be-
dzie zbyt duza, wzrasta ryzyko uszkodzenia elementu lub gniazda.
13
Przygotowany na potrzeby ponizszej pracy prototyp nie spełnia wszystkich opisanych tu
wymagan. Zaprojektowanie i wykonanie odpowiedniej obudowy i elementów wymagałoby za-
angazowania specjalistów od projektowania modeli trójwymiarowych oraz dostepu do maszyn
produkcyjnych lub profesjonalnej drukarki 3D.
2.2 Opis funkcjonalny
Zabawka składa sie z dwóch modułów komunikujacych sie bezprzewodowo:
1. Aplikacji.
2. Bomby.
Rysunek 2.1: Schemat ideowy projektu: komputer z odpowiednia aplikacja i układ elektro-
niczny stanowiacy „bombe” komunikujace sie bezprzewodowo
Aplikacja kontroluje zabawe i komunikuje sie z uzytkownikiem za pomoca obrazu i tek-
stu. W zaleznosci od decyzji uzytkownika inicjuje nowa gre lub wyswietla instrukcje obsługi.
W przypadku rozpoczecia nowej gry aplikacja podejmuje próbe nawiazania łacznosci
z kontrolerem bomby. Jesli sie to nie uda, zostaje wyswietlony komunikat o błedzie, a aplikacja
wraca do stanu poczatkowego. W przeciwnym przypadku kontroler otrzymuje dane o stanie
poczatkowym portów. Dzieki temu jest w stanie poprawnie ustawic kierunek odpowiednich
portów na wejscie lub wyjscie i zweryfikowac poprawnosc połaczenia komponentów.
Nastepnie aplikacja wyswietla uzytkownikowi schemat układu i oczekuje na sygnał goto-
wosci z kontrolera bomby. W razie potrzeby uzytkownik moze zazadac wyswietlenia dodatko-
wych szczegółów na temat danego elementu konstrukcji. Kontroler wykorzystuje czesc portów,
by zweryfikowac, czy układ został złozony poprawnie.
14
Rysunek 2.2: Diagram stanów aplikacji PC.
Gdy bomba jest juz gotowa, aplikacja przechodzi w tryb zagadek. Na podstawie konfigu-
racji powiazanej z danym schematem wybierana jest zagadka, której odpowiedz stanowi klucz
do kolejnego etapu rozbrojenia bomby. Jednoczesnie co pewien czas odbierane sa komunikaty
z kontrolera bomby na temat aktualnego stanu portów. Jezeli ten uległ zmianie, aplikacja spraw-
dza, czy otrzymany stan portów wejsciowych jest zgodny z oczekiwanym. Jesli nie, do kontro-
lera bomby zostaje przesłana odpowiednia informacja, a na ekranie wyswietla sie komunikat
o porazce. W przypadku otrzymania oczekiwanego stanu portów wejsciowych sprawdzane jest,
czy do wykonania pozostały dalsze kroki. Jesli tak, uzytkownik otrzymuje nowa zagadke. Je-
sli nie, do kontrolera przesyłana jest informacja o sukcesie, a na ekranie wyswietlony zostaje
komunikat o zwyciestwie. Po zakonczeniu gry aplikacja powraca do stanu poczatkowego.
15
Kontroler bomby jest urzadzeniem typu SBC (Single Board Computer) wyposazonym
w moduł komunikacji bezprzewodowej połaczony przez porty wejscia/wyjscia z zestawem ele-
mentów elektronicznych stanowiacych bombe. Zadaniem kontrolera jest monitorowanie stanu
podłaczonych do niego elementów w celu okreslenia działan uzytkownika i raportowanie wy-
ników pomiarów do aplikacji, która ocenia poprawnosc kroków uzytkownika.
Na poczatku niezbedne jest przygotowanie całego zestawu:
1. Sterownik uruchamia moduł komunikacji bezprzewodowej i oczekuje na połaczenie
z aplikacja wykorzystujac protokół opisany w dalszej czesci pracy.
2. Sterownik otrzymuje informacje o poczatkowym stanie portów, kazdy z portów opisany
jest numerem, kierunkiem (na przykład „wejsciowy”, „wyjsciowy”), typem (na przykład
„cyfrowy”, „analogowy”)1 i wartoscia poczatkowa.
3. Sterownik czeka, az uzytkownik złozy bombe zgodnie z wyswietlonym przez aplikacje
schematem.
4. Kontroler otrzymuje od uzytkownika sygnał gotowosci i sprawdza, czy stan portów wej-
sciowych jest zgodny z wartosciami odebranymi od aplikacji.
5. Jesli tak, sterownik wysyła informacje o gotowosci i inicjuje odliczanie czasu, co jest
równoznaczne z rozpoczeciem gry.
W trakcie zabawy kontroler co kilkadziesiat milisekund skanuje swoje porty i wysyła
ich liste wraz z wartosciami do aplikacji. W odpowiedzi moze odebrac informacje wskazujaca
na rezultat analizy przesłanych danych:
1. Stan portów zgodny z oczekiwaniami.
2. Stan portów zgodny z oczekiwaniami, wymagana rekonfiguracja.
3. Stan portów niezgodny z oczekiwaniami, koniec gry.
4. Wykryto bład, koniec zabawy.
Jesli odebrany sygnał pozwala kontynuowac zabawe, kontroler aktualizuje wartosc licz-
nika pozostałego czasu i czeka, az upłynie czas do kolejnego skanu. W przeciwnym razie infor-
muje uzytkownika o sukcesie lub porazce i wraca do stanu poczatkowego.1W miare projektowania kolejnych rozszerzen do zabawki mozna dodac nowe typy portów, na przykład „sze-
regowy”, lub wykorzystac dostepne biblioteki obsługujace takie elementy jak głosniki i serwomechanizmy. Na
potrzeby prototypu rozwiazania te nie zostały zaimplementowane.
16
Rysunek 2.3: Diagram stanów kontrolera bomby.
Nalezy zwrócic uwage na róznice miedzy informacja o stanie portów niezgodnym z ocze-
kiwaniami, a błedem. Pierwszy sygnał wskazuje na bład uzytkownika, powodujacy eksplozje
bomby. Drugi oznacza problem techniczny.
17
Rysunek 2.4: Diagram sekwencji komunikacji miedzy aplikacja, kontrolerem bomby i uzyt-
kownikiem.
Diagramy stanów ilustrujace zachowanie aplikacji PC i kontrolera bomby widoczne sa
na Rysunkach 2.2 i 2.3. Interakcje miedzy nimi i uzytkownikiem opisuje diagram sekwencji na
Rysunku 2.4.
18
2.3 Komponenty
Projekt obejmuje zarówno komponenty programowe, jak i sprzetowe.
Podstawowym zasobem, który musza posiadac komputer z działajaca aplikacja oraz kon-
troler bomby jest moduł komunikacji bezprzewodowej. Wynika to z podstawowych załozen
projektu. Procesowi decyzyjnemu odnosnie wybranej techniki przesyłu danych poswiecona jest
sekcja druga rozdziału “Projekt”.
Zasoby software’owe to przede wszystkim system operacyjny i biblioteki umozliwiajace
działanie aplikacji PC. Konieczny jest takze sterownik modemu komunikacji bezprzewodowej
umozliwiajacy wymiane danych z kontrolerem bomby.
Kontroler bomby jest układem spełniajacym okreslone wymagania techniczne, opisane
szczegółowo w sekcji pierwszej rozdziału “Projekt”. Do interakcji z uzytkownikiem słuza ele-
menty elektroniczne pełniace role czesci mechanizmu bomby. Przykładowe czujniki, wraz z ich
mozliwym przeznaczeniem, opisano w Tabeli 2.1.
Element Zadanie uzytkownika Wymagany typ
portu wejscia
Róznokolorowe
kable
Podłaczenie, odłaczenie Cyfrowy
Oporniki Zbudowanie prostego dzielnika napieciowego Analogowy
Przycisk Zwarcie obwodu Zalezny od in-
nych elementów
obwodu
Czujnik nacisku Zwarcie obwodu Zalezny od innych
elementów układu
Termistor Zdobycie czegos zimnego lub ciepłego Analogowy
Fotorezystor Oswietlenie lub osłoniecie bomby Analogowy
Czujnik wychyle-
nia
Poruszanie lub potrzasniecie wybranym ele-
mentem
Analogowy
Tabela 2.1: Zestawienie przykładowych elementów mechanizmu bomby wraz z niektórymi zadaniami,
jakie mozna wyznaczyc uzytkownikowi
Ponadto kontroler moze wykorzystywac diody elektroluminescencyjne i głosniki, by
przekazywac uzytkownikowi informacje o postepie prac.
19
Bomba posiada równiez elementy stałe, nie bedace bezposrednio czescia rozbrajanego
układu. Sa to jednostka centralna, włacznik, zródło zasilania, wyswietlacz odmierzajacy pozo-
stały czas i przycisk, którym uzytkownik sygnalizuje gotowosc rozpoczecia zabawy.
20
3 Projekt
Waznym elementem procesu projektowego jest wybór wykorzystanych narzedzi. W przy-
padku projektu bedacego przedmiotem ponizszej pracy szczególnej uwagi wymagaja decyzje
dotyczace technologii, o która oparty bedzie kontroler bomby, oraz wybór techniki bezprzewo-
dowej komunikacji.
Komponenty te decyduja o architekturze całego finalnego produktu, poniewaz to do nich
dostosowana jest aplikacja PC i dołaczone do zestawu czujniki. Od ich parametrów zalezy
tez płynnosc zabawy i niezawodnosc całego systemu.
Aby zapewnic, ze wybrane zostana najwłasciwsze rozwiazania, przeprowadzona została
szczegółowa analiza wymagan i dostepnych na rynku mozliwosci.
3.1 Kontroler bomby
3.1.1 Wymagania
Wymagania techniczne
Okreslenie wymagan technicznych zwiazanych z kontrolerem bomby dotyczy
przede wszystkim dostepnych zasobów. Jesli bedzie ich zbyt mało urzadzenie nie bedzie zdolne
pełnic wyznaczonej mu funkcji, natomiast ich nadmiar zawyza koszt finalnego produktu.
Zasoby najistotniejsze z punktu widzenia wymagan projektu to:
• cyfrowe porty wejscia/wyjscia,
• analogowe porty wejscia/wyjscia,
• szyna I2C,
• porty szeregowe,
• komunikacja bezprzewodowa.
Kryteria oceny nie uwzgledniaja tak waznych parametrów, jak dostepna pamiec i szybkosc pro-
cesora. Wynika to z przyjetych załozen, na podstawie których kontroler bomby nie wymaga do-
datkowych plików konfiguracyjnych, a jedynie wykonywalnego kodu binarnego, a czas reakcji
nie musi spełniac wymagan systemu czasu rzeczywistego. Czynniki te nie sa brane pod uwage,
21
poniewaz zapotrzebowanie na pamiec i szybkosc procesora uzaleznione jest od architektury, ilo-
sci kodu oraz parametrów kompilatora. W zwiazku z tym niemozliwe jest jednoznaczne porów-
nanie pod tym wzgledem analizowanych rozwiazan. Jedynie implementacja projektu na wielu
platformach i przeprowadzenie empirycznych testów wydajnosciowych umozliwiłoby jedno-
znaczne ustalenie hierarchii. To jednak znaczaco wykracza poza przewidziane ramy czasowe
projektu.
Kolejnym waznym kryterium oceny sa parametry energetyczne układu. Ze wzgledu na
wykorzystanie komunikacji bezprzewodowej, w finalnej wersji kontroler bomby wymagac be-
dzie zasilania bateryjnego. Aby poprawic komfort pracy uzytkownika nalezy zatem dazyc
do minimalizacji zuzycia pradu.
Ostatnim z branych pod uwage kryteriów jest skalowalnosc rozwiazania. W razie, gdyby
zasoby kontrolera okazały sie byc czynnikiem utrudniajacym rozwój projektu, np. niezbedne by
było zwiekszenie liczby portów, musi istniec sposób rozszerzenia mozliwosci zabawki. W przy-
padku nowych wersji poprawe parametrów mozna osiagnac przez zastapienie uzywanego kon-
trolera przez nowszy lub lepszy model z tej samej rodziny. Nie powinno to pociagac za soba
daleko idacych zmian w kodzie sterujacym ani kształcie samego urzadzenia. Modele obecne
na rynku mozna ulepszyc poprzez dołaczenie zewnetrznego modułu oferujacego dodatkowa
funkcjonalnosc.
Wymagania biznesowe
Wymagania biznesowe dotycza przede wszystkim kosztu urzadzenia. Jest to zwiazane
zarówno z kosztem na etapie projektowym, jak tez cena jednostkowa układu umieszczanego
w urzadzeniach koncowych.
Na etapie projektowym niezbedne jest, by wybrane urzadzenie było reprogramowalne.
Wiele decyzji zwiazanych z architektura kontrolera podejmowanych jest na biezaco, niekiedy
na bazie eksperymentów, zatem niemozliwe jest okreslenie z góry specyfikacji logiki urzadze-
nia. Przyjmuje sie, ze porty wejscia/wyjscia konfigurowane beda na podstawie danych przycho-
dzacych z aplikacji PC.
Koszt projektu wynika nie tylko z ceny jednostkowej układu. Konieczny jest równiez
zakup urzadzen i oprogramowania niezbednych do stworzenia i załadowania logiki kontrolera.
Ponadto wazna jest dostepnosc bibliotek i dokumentacji oraz dobrze rozwinieta społecznosc
programistów, poniewaz korzystanie z istniejacych rozwiazan pozwala znaczaco ograniczyc
czas i srodki niezbedne do realizacji celu.
22
Drugim czynnikiem waznym z biznesowego punktu widzenia jest stabilnosc rozwiaza-
nia. Kazdy bład pozostawiony przez producenta rzutowac moze na negatywny odbiór produktu
przez konsumentów. Ponadto przecietny uzytkownik nie posiada wiedzy ani narzedzi, które
moga byc niezbedne do rozwiazania problemu.
3.1.2 Przeglad wybranych rozwiazan
Mikrokontrolery
Mikrokontrolery to programowalne układy scalone stanowiace zamkniety, autonomiczny
system składajacy sie z procesora, pamieci i interfejsów wejscia/wyjscia. Charakteryzuja sie
niewielkimi rozmiarami, małym zapotrzebowaniem na energie elektryczna i niskim kosztem
jednostkowym. Przekłada sie to jednak na niewielkie dostepne zasoby.
Ze wzgledu na mnogosc dostepnych na rynku rozwiazan, analiza wszystkich potencjal-
nych rodzin produktów nie jest mozliwa. W zwiazku z tym konieczny był arbitralny wybór
przykładowej rodziny produktów, która poddana zostanie dalszej ocenie na podstawie opisa-
nych wczesniej kryteriów.
Wybór padł na platforme Arduino, wyposazona w układ scalony z rodziny ATmega,
tworzona w ramach inicjatywy Open Hardware. Decyzja ta podyktowana została otwartym
charakterem rozwiazania, który przyczynił sie do powstania aktywnej społecznosci programi-
stów. Zaowocowało to powstaniem wielu bibliotek i przykładowych projektów rozpowszech-
nianych na licencji GNU/GPL, stanowiacych bogate zródło materiałów szkoleniowych.
Ponadto rozpatrywane były równiez nastepujace platformy:
• LaunchPad, oferowany przez firme Texas Instruments - odrzucona ze wzgledu na
o wiele mniej aktywna niz w przypdku Arduino społecznosc programistów i kosztowne
licencje na narzedzia programistyczne i materiały szkoleniowe,
• Freedom - oferowany przez firme Freescale, odrzucona ze wzgledu na gorsza niz
w przypadku Arduino ergonomie i jakosc dokumentacji, a takze liczne sensory na stałe
wmontowane w urzadzenie, co utrudnia wykorzystanie ich w projekcie.
Rodzina produktów Arduino składa sie z wielu modeli, sposród których wyróznic
mozna cztery bazowe:
1. Arduino UNO - model podstawowy.
23
2. Arduino Leonardo - model z dodatkowym oprogramowaniem umozliwiajacym za-
awansowana komunikacje przez USB.
3. Arduino Mega - model z dodatkowa pamiecia i wieksza liczba portów wej-
scia/wyjscia.
4. Arduino Nano - model pomniejszony, majacy mniejsze wymiary, mniej pamieci
i mniej portów wejscia/wyjscia niz podstawowy.
Ponadto kazdy z wymienionych modeli dostepny jest w wielu konfiguracjach, róznia-
cych sie modułami umieszczonymi na płytce stykowej. Wielu producentów korzysta równiez
ze schematów Arduino tworzac własne rozwiazania, z reguły kompatybilne z oryginalnymi
platformami. Dostepne sa równiez tak zwane “shieldy1”, rozszerzajace funkcjonalnosc danej
platformy. Daje to szerokie mozliwosci wyboru rozwiazania najlepiej dostosowanego do wy-
magan projektowych.
Rysunek 3.1: Arduino UNO, widok z góry. Zródło: www.arduino.cc
Do dalszej analizy wybrany został model Arduino UNO. Poniewaz jest to produkt pod-
stawowy w swojej rodzinie, wszystkie jego zalety znalezc mozna w pozostałych rozwiazaniach.
1Polskie tłumaczenie nie jest stosowane.
24
Z drugiej strony, jesli w trakcie realizacji projektu stwierdzone zostanie wieksze zapotrzebowa-
nie na którys z zasobów, mozliwy jest zakup odpowiednio bogatszego modelu.
W podstawowej konfiguracji Arduino UNO oferuje nastepujace zasoby[6]:
• 14 cyfrowych portów wejscia/wyjscia (6 z nich moze funkcjonowac równiez jako analo-
gowe wyjscie),
• 6 analogowych portów wejscia,
• szyne I2C,
• 32 kB pamieci FLASH,
• 2 kB pamieci SRAM,
• 1kB pamieci EEPROM,
• zegar taktowany z czestotliwoscia 16MHz,
• port USB typu B.
Z punktu widzenia wymagan projektowych zasoby te byłyby całkowicie wystarczajace
do stworzenia prototypu zabawki, gdyby nie brak modułu komunikacji bezprzewodowej. Ela-
stycznosc platform z rodziny Arduino pozwala rozwiazac ten problem na trzy sposoby:
1. Wykorzystujac gotowy produkt oferowany przez oficjalnego dystrybutora Arduino lub
jedna z firm zewnetrznych, gdzie port USB został zastapiony modemem komunikacji
bezprzewodowej.
2. Podłaczajac do platformy zapewniajacy odpowiednia funkcjonalnosc shield.
3. Podłaczajac poprzez porty wejscia/wyjscia modem komunikacyjny zewnetrznego produ-
centa.
Jezeli wybrana forma komunikacji bezprzewodowej opiera sie na emulacji wirtualnego
portu szeregowego, na etapie projektowym nie ma znaczenia, które rozwiazanie bedzie stoso-
wane. Z punktu widzenia aplikacji wszystkie trzy mozliwosci sa nierozróznialne, zatem w roz-
wiazaniu produkcyjnym mozna stosowac inne rozwiazanie niz w prototypie, bez koniecznosci
zmian w kodzie.
Kazda z wymienionych mozliwosci dostepna jest dla wszystkich standardów komunikacji
bezprzewodowej opisanych w sekcji poswieconej temu zagadnieniu.
25
Koszt pojedynczego modułu Arduino UNOwynosi około 100zł. W wersji produkcyjnej
mozliwa jest rezygnacja z dostarczanej przez producenta płytki stykowej i wykorzystanie sa-
mego układu scalonego ATmega bedacego głównym elementem urzadzenia. Cena jednostkowa
takiego układu waha sie od 5 do 15 zł, w zaleznosci od modelu. W przypadku takiego podej-
scia nalezy uwzglednic jednak koniecznosc zaprojektowania i wyprodukowania dedykowanej
płytki stykowej oraz ograniczenia mozliwosci komunikacji bezprzewodowej do zewnetrznego
modemu.
Istotna cecha układów z rodziny Arduino sa duze mozliwosci skalowania rozwiaza-
nia do potrzeb. W najprostszym przypadku zamiast Arduino UNO zastosowac mozna wiek-
szy lub mniejszy model (Arduino Mega lub Arduino Nano), jesli podstawowy model
ma zbyt mało portów lub jest zbyt duzy. Poniewaz UNO jest modelem referencyjnym, kazda za-
projektowana pod jego katem aplikacja moze zostac przeniesiona na inne rozwiazania. Równiez
produkty firm zewnetrznych zachowuja zwykle podobna kompatybilnosc.
Druga mozliwosc to podłaczenie zewnetrznych modułów, takich jak rejestry przesuwne
lub rozgałeziacze portów, dzieki którym zwiekszy sie ilosc zasobów danego modułu. Dzieki
udostepnianym przez społecznosc programistów bibliotekom korzystanie z tych rozwiazan jest
proste i wygodne, a bogate materiały edukacyjne ułatwiaja szybkie uzyskanie informacji nie-
zbednych do właczenia danego układu w projekt.
Trzecim rozwiazaniem jest połaczenie ze soba kilku egzemplarzy z rodziny Arduino.
Wykorzystuje sie do tego porty cyfrowe, które umozliwiaja emulacje łacza szeregowego na
dowolnych dwóch portach cyfrowych. W ten sposób, jesli na jednym module zabraknie któregos
zasobu (np. szyny I2C), mozliwe jest połaczenie go z innym produktem Arduino (lub samym
układem scalonym ATmega) i rozszerzenie funkcjonalnosci całego systemu.
Podsumowujac, układy z rodziny Arduino spełniaja wszystkie postawione wymagania.
Oferuja bogate i dobrze udokumentowane biblioteki, maja wszystkie niezbedne zasoby i moga
łatwo zostac dostosowane do zmieniajacych sie potrzeb.
FPGA
Układy FPGA (ang. Field Programmable Gate Array) sa czesto spotykanym rozwiaza-
niem w projektach zwiazanych z cyfrowym przetwarzaniem sygnałów, gdzie liczy sie elastycz-
nosc, szybkosc i niski koszt projektu, a produkt koncowy wypuszczany jest na rynek w krótkich
seriach. Gotowy projekt rozwiazania dla układu FPGA stanowi tez dobry wzorzec dla układów
26
dedykowanych typu ASIC (ang. Application Specific Integrated Circuit), których wykorzysta-
nie pozwala na dalsza poprawe parametrów systemu.
Układy FPGA oparte sa o komórki logiczne, mogace realizowac dowolne funkcje logiczne
o z góry ustalonej liczbie argumentów i wyjsc, oraz rekonfigurowalne połaczenia miedzy nimi.
Sa tez zwykle wyposazone w bloki pamieci ROM, układy DSP (ang. Digital Signal Proces-
sing) i inne podsystemy pozwalajace przyspieszyc obliczenia. W przypadku bardziej zaawanso-
wanych modeli mozliwa jest realizacja paradygmatu System-on-Chip, dla układów FPGA
rozwijanego czesto do postaci System-on-Reprogrammable-Chip[7].
Projektowanie układów FPGA moze przebiegac na róznych poziomach, w zaleznosci
od wymagan projektowych. Tam, gdzie wazna jest optymalizacja szybkosci obliczen i zuzycia
zasobów, mozliwe jest manualne projektowanie zawartosci pojedynczych komórek, natomiast
w przypadku bardzo złozonych systemów dostepne jest programowanie na wyzszych pozio-
mach abstrakcji.
Niezaleznie od poziomu abstrakcji do programowania układów FPGA wykorzystuje sie
jezyki opisu sprzetu VHDL i Verilog. Ze wzgledu na specyfike układów wyszukiwanie po-
tencjalnych zródeł błedów w projekcie jest czynnoscia skomplikowana, poniewaz programista
nie dysponuje narzedziami takimi jak debugger lub testy jednostkowe. Dostepne sa natomiast
symulatory, które ułatwiaja analize zaprojektowanego układu.
Podstawowymi zasobami kazdego układu FPGA sa komórki logiczne, pamiec, zegar i in-
terfejsy cyfrowego wejscia/wyjscia. Wiele dostepnych na rynku rozwiazan wymaga zewnetrz-
nego przetwornika analogowo-cyfrowego. Układy FPGA nie posiadaja tez wbudowanych mode-
mów do komunikacji bezprzewodowej. Niekiedy producenci umieszczaja takie moduły na płyt-
kach stykowych w ramach zestawu uruchomieniowego, jednak jest to rozwiazanie, które mozna
wykorzystac wyłacznie na etapie prototypu. Koszt pojedynczego zestawu uruchomieniowego,
zawierajacego wszystkie komponenty, moze siegac setek lub tysiecy dolarów, w zaleznosci
od wybranego rozwiazania. Zestawy te charakteryzuja sie tez duzym rozmiarem, zapotrzebo-
waniem na moc przekraczajacym mozliwosci zasilania bateryjnego i znaczacym nadmiarem
funkcjonalnosci wobec wymagan projektowych.
Powaznym utrudnieniem w przygotowaniu dedykowanego dla projektu systemu zawiera-
jacego wyłacznie niezbedne komponenty jest brak gotowych bibliotek i otwartych projektów
dla rozwiazan producentów komponentów zewnetrznych. Wymusza to tworzenie własnych ste-
rowników, co znacznie komplikuje proces projektowy.
27
Rysunek 3.2: Altera Cyclone II FPGA Starter Development Board, zródło:
www.altera.com
Ceny układów FPGA sa bardzo zróznicowane i zaleza od zasobów oferowanych
przez dany moduł. Zestawienie przykładowych produktów, wraz z niektórymi zasobami i cena
znajduje sie w Tabeli 3.1.
Zapotrzebowanie układu FPGA na energie elektryczna zalezy wprost od ilosci wykorzy-
stanych komórek logicznych i moze byc przedmiotem ewentualnej optymalizacji.
Podsumowujac, układy FPGA sa niezwykle elastycznym rozwiazaniem, oferujacym duze
mozliwosci i znaczna moc obliczeniowa. Z punktu widzenia wymagan projektowych pojedyn-
czy układ tego typu z nawiazka pokryłby zapotrzebowanie na pamiec i porty wejscia/wyjscia.
Z drugiej strony, znacznie podrozyłyby koszt projektu ze wzgledu na wysoka cene zestawów
deweloperskich i skomplikowany proces tworzenia aplikacji.
28
Producent Układ Cena (układ) Cena (z ze-
stawem
deweloper-
skim)
Liczba ko-
mórek
Liczba
portów wej-
scia/wyjscia
Altera Cyclone II 12-420 USD 199 USD2 4600-70000 89-622
Altera Cyclone V 40-760 USD 1100-1600
USD
25000-
300000
66-560
Actel SmartFusion2 190 USD 1800 USD 150000 200
Tabela 3.1: Zestawienie przykładowych ofert producentów układów FPGA[8]
Raspberry PI
Raspberry PI jest najmniejszym na swiecie w pełni funkcjonalnym komputerem
klasy PC, opartym o architekture ARM[9]. Stworzony został z mysla o zastosowaniach w ro-
botyce, edukacji i walce ze zjawiskiem wykluczenia cyfrowego[10].
Podstawowa wersja Raspberry PI oferuje nastepujace zasoby:
• CPU 700MHz,
• GPU ze wsparciem biblioteki OpenGL 2.0,
• 256 MB RAM,
• port USB 2.0 (master),
• port monitora HDMI i analogowe porty audio/wideo,
• 8 cyfrowych portów wejscia/wyjscia, złacze UART, szyne I2C,
• slot karty SD.
Wersja rozszerzona wyposazona jest w dodatkowe 256 MB RAM, drugi port USB i port
Ethernet 100Mbit/s.
Urzadzenie działa pod kontrola systemu operacyjnego Linux. Umozliwia to pisanie apli-
kacji w wiekszosci popularnych jezyków programowania. Po podłaczeniu monitor przez port
HDMI mozna korzystac z interfejsu graficznego.
Platforma nie dysponuje wbudowanym modułem komunikacji bezprzewodowej, jednak
wykorzystujac port USB mozliwe jest podłaczenie wiekszosci dostepnych na rynku modemów.
29
Rysunek 3.3: Raspberry PI, model B, zródło: www.raspberrypi.org
Brak równiez przetworników analogowo-cyfrowych umozliwiajacych komunikacje z zewnetrz-
nymi czujnikami, choc istnieje mozliwosc wykorzystania w tym celu analogowych portów au-
dio/wideo. Szybki procesor, układ GPU i inne funkcjonalnosci układu generuja duze zapotrze-
bowanie na energie elektryczna, przez co zasilanie bateryjne wystarcza tylko na krótki czas.
Wersja podstawowa urzadzenia kosztuje 25 USD, natomiast rozszerzona - 35 USD. Koszt
ten dotyczy zarówno egzemplarza przeznaczonego do realizacji prototypu zabawki, jak tez kaz-
dego egzemplarza produkcyjnego. Platforma stanowi zamknieta całosc i nie ma mozliwosci
wykorzystania w finalnym produkcie pojedynczych komponentów.
Podsumowujac, Raspberry PI jest uzyteczna, elastyczna platforma, oferujaca liczne
uzyteczne zasoby. Z drugiej strony wiele z jego mozliwosci moze nie zostac wykorzystane
w finalnym produkcie, a mimo to przyczyni sie do wzrostu ceny zabawki.
3.1.3 Decyzja
Po przeanalizowaniu wszystkich dostepnych mozliwosci do realizacji kontrolera bomby
wybrane zostało Arduino.
30
Kazde z rozpatrywanych rozwiazan ma swoje silne i słabe strony, jednak w zwiazku
ze specyfika projektu wady pozostałych propozycji przewazaja nad zaletami.
Kontroler “bomby” nie musi spełniac kryteriów systemu czasu rzeczywistego, za-
tem szybkosc układów FPGA pozostałaby niewykorzystana. W zwiazku z tym równiez moz-
liwosc optymalizacji na poziomie sprzetowym okazałaby sie zbedna. Z drugiej strony koszt
zestawów deweloperskich i trudnosc zwiazana z programowaniem w jezykach opisu sprzetu
mogłyby powaznie zwiekszyc koszt i pracochłonnosc projektu.
Raspberry PI oferuje wiele mozliwosci, które na obecnym etapie projektu sa nad-
miarowe, zatem wysoka cena jednostkowa nie znalazłaby uzasadnienia. Po wprowadzeniu pro-
duktu na rynek moze sie jednak okazac, ze wymagania konsumentów wymusza rozszerzenie
funkcjonalnosci kontrolera, na przykład o mozliwosc podłaczenia urzadzen takich jak telewi-
zor, głosniki lub adapter USB. W takiej sytuacji Raspberry PI moze zostac wykorzystane
jako zamiennik Arduino lub zewnetrzny moduł komunikujacy sie z kontrolerem przez port
szeregowy.
W porównaniu do pozostałych platform Arduino oferuje funkcjonalnosc najbardziej
zblizona do potrzeb projektowych przy zachowaniu niskiej ceny i duzej dostepnosci materiałów
edukacyjnych. Szeroki wybór produktów z tej rodziny gwarantuje, ze w razie pojawienia sie no-
wych wymagan, dostosowanie do nich funkcjonalnosci kontrolera nie bedzie wymagało duzego
nakładu pracy.
Ponadto dla uzytkowników zainteresowanych dalszym rozszerzaniem swojej wiedzy za-
bawka moze stac sie punktem wyjscia do projektowania własnych układów opartych o Arduino.
Na poczatku moga to byc tylko własne schematy bomb, ale z czasem wielu uzytkowników moze
chciec stworzyc własne wersje kontrolera, bardziej odpowiadajace ich wizji zabawy. Ciekawa
forma nauki moze tez stac sie próba oszukania zabawki, np. poprzez zmiane kodu zródłowego
kontrolera, lub podstawienie fałszywej aplikacji PC. Wszystkie te mozliwosci znacznie pod-
wyzszaja wartosc edukacyjna projektu.
Powyzsze zalety przewazyły o wyborze Arduino na platforme do realizacji kontrolera
bomby.
31
3.2 Komunikacja bezprzewodowa
3.2.1 Wymagania
Wymagania techniczne
Zdefiniowanie wymagan technicznych polega na okresleniu minimalnych parametrów,
które musi posiadac medium komunikacyjne, by poszczególne elementy zabawki mogły po-
prawnie spełniac swoja role. Nalezy miec przy tym na uwadze nie tylko zapotrzebowanie okre-
slone na poczatkowym etapie projektowania urzadzenia, ale równiez potencjalne mozliwosci
rozwoju. Ze wzgledu na modułowa budowe bomby, mozliwe jest rozszerzanie jej o wiele róz-
nych elementów, które moga wymagac znacznie lepszych parametrów transferu danych niz
te na etapie prototypu. Poniewaz o charakterze nowych elementów zdecyduje zapotrzebowanie
rynku po prezentacji finalnego produktu nie sposób na wczesnym etapie projektu precyzyjnie
okreslic ich wymagan.
Z drugiej strony nadmierne wymagania w kwestii parametrów transferu danych prowa-
dzic moga do zwiekszenia kosztów zarówno projektu, jak tez produktu rynkowego. Moze to
doprowadzic do zmniejszenia sprzedazy i spadku zysków, a uzyskane za te cene korzysci nigdy
nie przyniosa pozytku.
Szybkosc przesyłu danych
Transfer danych pomiedzy aplikacja i kontrolerem bomby polega na przesyłaniu informa-
cji inicjalizacyjnych, raportów o stanie portów wejsciowych i potwierdzen.
Rozmiar danych inicjalizacyjnych i raportów uzalezniony jest od liczby uzywanych por-
tów i rozdzielczosci portów analogowych. Przykładowo, dla mikrokontrolera Arduino Uno
mozliwe jest wykorzystanie maksymalnie dwunastu portów cyfrowych i szesciu analogowych
o 256 poziomach dyskretyzacji. W zwiazku z tym do jednoznacznej identyfikacji danego portu
cyfrowego i okreslenia jego wartosci wystarcza dwa bajty. Natomiast do obsługi protokołu war-
stwy aplikacji wystarcza komunikaty o rozmiarze jednego bajtu. A zatem, zakładajac wymiane
komunikatów dwadziescia razy na sekunde3, minimalny transfer niezbedny do poprawnego
działania urzadzenia nalezy ocenic na około 8kbit/s.
Uwzgledniajac mozliwosc rozszerzenia funkcjonalnosci zabawki konieczne jest jednak
zwiekszenie tej wartosci. Poniewaz na obecnym etapie projektu nie jest mozliwa precyzyjna
3Załozenie to jest szerzej omawiane w sekcji dotyczacej opóznien i strat.
32
ocena przyszłego zapotrzebowania, przyjeta została wartosc dziesieciokrotnie wyzsza niz wy-
nikajaca ze wstepnej oceny. Umozliwia to zarówno przesyłanie wiekszej ilosci danych, jak tez
czestsza wymiane komunikatów.
Nalezy podkreslic, ze podana tutaj szybkosc transferu okreslona jest jako minimalna.
Im wyzsza wartosc tego parametru zapewni wybrana technika, tym bardziej maleje prawdopo-
dobienstwo, ze to własnie wybrana forma komunikacji bezprzewodowej okaze sie w przyszłosci
czynnikiem hamujacym rozwój projektu.
Opóznienie i straty
Opóznienia i straty rozpatrywane sa wspólnie, poniewaz miedzy tymi parametrami wy-
stepuje silna korelacja. Utrata danych wymusza odczekanie okreslonego czasu i retransmisje,
co wprowadza dodatkowe opóznienie w warstwie aplikacji.
Dopuszczalne opóznienie okreslone jest przez subiektywna percepcje uzytkownika. Sys-
tem działa poprawnie, jesli czas reakcji na zmiane stanu portów kontrolera bomby jest niedo-
strzegalny dla człowieka.
W systemach telekomunikacyjnych parametry jakosciowe oceniane sa na podstawie su-
biektywnego badania MOS (ang. Mean Opinion Score, subiektywny współczynnik jakosci).
Polega ono na testowaniu systemu gwarantujacego okreslona jakosc przez grupe ankietowa-
nych, którzy po badaniu przyznaja ocene w skali od 1 do 5.
Podobna metodologia została zastosowana do wyznaczenia dopuszczalnego opóznienia
w komunikacji miedzy kontrolerem bomby a aplikacja. Do badania został wykorzystany układ
składajacy sie z mikrokontrolera Arduino Uno podłaczonego do komputera PC przy pomocy
łacza USB. Gdy na wybranym porcie mikrokontrolera pojawił sie sygnał cyfrowy 1, przysyłana
była o tym informacja do komputera i rozpoczynał sie pomiar czasu. Aplikacja komputerowa
po zadanym czasie odpowiadała, po czym wyswietlała otrzymany z mikrokontrolera wynik
pomiaru czasu.
Podajac w aplikacji rózne wartosci opóznien mozna było stwierdzic, kiedy rezultat po-
miaru czasu otrzymywany jest zadowalajaco szybko. Na tej podstawie udało sie wyznaczyc, ze
srednie opóznienie reakcji systemu nie powinno przekroczyc 300 ms, natomiast percentyl 99%
- 500 ms.
Podobnie jak w przypadku przepływnosci podane powyzej wartosci stanowia granice,
po przekroczeniu której uznaje sie, ze system przestał działac zgodnie ze specyfikacja.
33
Wymagania biznesowe
Wymagania biznesowe okreslaja, jakie warunki powinna spełniac wybrana forma komu-
nikacji bezprzewodowej, by koncowy produkt został dobrze odebrany na rynku. Nalezy zwrócic
uwage, ze nie zawsze wynika to z przesłanek technicznych.
Z punktu widzenia rynku istotne sa nastepujace cechy urzadzenia:
1. Powszechnosc - wykorzystanie infrastruktury, która mozna znalezc w wiekszosci gospo-
darstw domowych pozwala znaczaco obnizyc koszt wyprodukowania i eksploatacji urza-
dzenia.
2. Prostota uzycia - uruchomienie zabawki powinno kosztowac uzytkownika jak najmniej
wysiłku. Jesli wykorzystywane sa zewnetrzne urzadzenia, konieczne jest minimalizowa-
nie zmian w ich konfiguracji niezbedne do poprawnej komunikacji.
3. Prostota implementacji - wymagany jest jak najmniejszy narzut na komunikacje i jak naj-
prostszy stos protokołów. Kazda dodatkowa warstwa zwieksza zapotrzebowanie na moc
obliczeniowa i zasoby kontrolera, podnoszac koszt całego produktu.
4. Przenosnosc - dana technika przesyłu danych powinna byc wspierana przez jak najwiek-
sza liczbe platform. Ułatwi to ewentualna ekspansje na nowe segmenty rynku.
5. Koszt - komponenty zwiazane z komunikacja powinny byc jak najtansze. Obejmuje to
zarówno hardware, jak tez ewentualne opłaty licencyjne.
3.2.2 Przeglad wybranych technik
Wi-Fi
Wi-Fi jest technika bezprzewodowego przesyłu danych opisana w standardzie IEEE
802.11[11]. Wykorzystuje nielicencjonowane pasmo 2.4 Ghz (równiez 5Ghz w przypadku
standardu n). W modelu OSI spełnia role warstwy fizycznej i warstwy łacza danych. W zalez-
nosci od standardu oferuje przepływnosc od 1 do 72 Mbit/s.
Z punktu widzenia komunikacji miedzy kontrolerem bomby a aplikacja technika Wi-Fi
ma wiele zalet. Najwieksza z nich jest duza przepływnosc, dajaca szerokie mozliwosci roz-
woju komponentów bomby. Ponadto jest to jedna z najpopularniejszych form bezprzewodo-
wego przesyłania danych na mała odległosc. Zgodnie z raportem ABI Research[12], w roku
34
2012 sprzedano około półtora miliarda urzadzen wspierajacych ten standard. Mozna zatem za-
łozyc, ze uzytkownik koncowy bedzie dysponował routerem lub komputerem posiadajacym
adapter Wi-Fi.
Opóznienia i straty pakietów scisle zaleza od natezenia ruchu w sieci i zakłócen elektro-
magnetycznych. Wykorzystanie techniki CSMA/CA, okreslajacej polityke zarzadzania doste-
pem do medium transmisyjnego, sprawia, ze nie mozna przewidziec jak długo adapter lub apli-
kacja beda oczekiwac na mozliwosc przesłania danych. W domowych warunkach całkowite
opóznienie nie przekracza jednak granic wyznaczonych w wymaganiach technicznych.
Istotnym problemem w przypadku sieci Wi-Fi jest implementacja pełnego stosu TCP/IP
lub UDP/IP na kontrolerze bomby. Ma to negatywny wpływ na zapotrzebowanie na zasoby
i opóznienia w komunikacji. Wiaze to sie równiez z duzym narzutem, jako ze rozmiar samego
nagłówka IPv4 jest porównywalny do rozmiaru przesyłanych danych.
Najistotniejsza przeszkoda w wykorzystaniu techniki Wi-Fi jest problem z konfiguracja
połaczenia. Siec Wi-Fi moze pracowac w dwóch trybach:
• poprzez Access Point,
• ad-hoc.
W pierwszym przypadku pojawia sie problem uzyskania adresu. Wymaga to implementa-
cji protokołu DHCP, co zwieksza zapotrzebowanie na pamiec kontrolera. Ze wzgledu na ogra-
niczony interfejs kontrolera brak jest mozliwosci podania hasła, zatem komunikacja moze od-
bywac sie jedynie poprzez sieci niezabezpieczone. Ponadto szyfrowanie połaczenia wprowa-
dziłoby znaczne opóznienia w komunikacji ze wzgledu na ograniczone mozliwosci procesora
w kontrolerze.
Z marketingowego punktu widzenia ograniczenie komunikacji do sieci niezabezpieczo-
nych jest czynnikiem bardzo negatywnym, poniewaz zmusza uzytkownika do zmiany konfigu-
racji routera, do czego moze on nie miec uprawnien. Promuje to szkodliwa postawe lekcewaze-
nia kwestii bezpieczenstwa, co ogranicza wartosc edukacyjna zabawki.
Istotnym problemem jest równiez zlokalizowanie adresu IP komputera, na którym działa
aplikacja. Poniewaz nie ma mozliwosci okreslenia z góry, w jakiej podsieci znajda sie oba
elementy zabawki, ani jakie otrzymaja adresy, a interfejs kontrolera uniemozliwia wprowadze-
nie lub odczytanie adresu przez uzytkownika, jedno z urzadzen musi odpytac wszystkie hosty
w podsieci szukajac odpowiedniego otwartego portu. Znaczaco wydłuza to czas rozpoczecia
zabawy obnizajac atrakcyjnosc produktu.
35
Problemów tych nie obserwujemy w przypadku trybu ad-hoc, dla którego mozliwe jest
samodzielne okreslenie parametrów sieci. Wykorzystanie tego trybu łaczy sie jednak z innymi
trudnosciami.
Po pierwsze nalezy załozyc brak w sieci serwera DHCP, co wymusza fabryczne ustawie-
nie na urzadzeniu jednego, stałego adresu IP. Co wazniejsze, by rozwiazac problem wzajem-
nego znalezienia sie urzadzen w podsieci, uzytkownik musi ustawic na komputerze konkretny
adres IP podany np. w instrukcji obsługi. Kazdy bład w konfiguracji uniemozliwi prawidłowe
funkcjonowanie urzadzenia.
Po drugie jesli w trakcie zabawy uzytkownik zechce skorzystac z Internetu, bedzie zmu-
szony podłaczyc sie do sieci kablowej, co nie zawsze jest mozliwe. Poza tym takie ograniczenie
stawia pod znakiem zapytania sensownosc wykorzystania technologii bezprzewodowej do po-
łaczenia aplikacji z kontrolerem, skoro tak czy inaczej konsument zmuszony jest skorzystac
z kabla.
A zatem, mimo wielu zalet technika Wi-Fi nie spełnia minimalnych wymagan bizneso-
wych i zostaje odrzucona jako czynnik potencjalnie ograniczajacy wygode uzytkownika.
Bluetooth
Bluetooth jest technika bezprzewodowego przesyłu danych opisana w standardzie IEEE
802.15.1[13]. Został zaprojektowany z mysla o zastapieniu łacza szeregowego w komuni-
kacji miedzy róznymi podzespołami jednego systemu. Bluetooth działa w nielicencjonowanym
pasmie 2.4 Ghz.
Najwieksza zaleta techniki Bluetooth jest powszechnosc zastosowania. Zgodnie z danymi
organizacji Bluetooth Special Interest Group[14] dziennie sprzedawanych jest na swiecie około
pieciu milionów urzadzen korzystajacych z tej techniki. Ta sama fundacja podaje, ze w roku
2010 77% sprzedanych laptopów posiadało wbudowany adapter Bluetooth. W przypadku kom-
puterów nie posiadajacych takiego komponentu mozliwe jest dokupienie modemu podłacza-
nemu przez USB za około 20 zł. Równiez koszt adaptera dla urzadzenia wbudowanego nie
podwyzszy odczuwalnie kosztów produktu koncowego.
Bluetooth ma zatem ugruntowana na rynku marke, a potencjalni konsumenci zaznajo-
mieni sa juz z wykorzystywaniem tej techniki. Ponadto wykorzystanie Bluetooth znacznie uła-
twia ewentualna ekspansje na rynek smartfonów, jako ze niemal 100% urzadzen tego typu
wspiera omawiany standard.
36
Technika Bluetooth oferuje, w zaleznosci od wersji, przepływnosc od 0.7 do 24 Mbit/s,
co znacznie przekracza minimum opisane w wymaganiach technicznych. Wykorzystanie pasma
2.4 Ghz znaczaco zwieksza ryzyko zakłócen i opóznien, jednak zastosowanie techniki Frequ-
ency Hopping pozwala ograniczyc ten efekt. Nalezy pamietac, ze ze wzgledu na długi czas
nawiazywania połaczenia stos protokołów wykorzystany w tej technice wprowadza opóznienia
dochodzace do 50 ms. Dostepne sa jednak na rynku modemy, w których protokoły zaimplemen-
towane sa sprzetowo, co znacznie poprawia wydajnosc i pozwala zaoszczedzic zasoby samego
kontrolera. Umozliwia to równiez efektywna emulacje portu szeregowego, a zatem ułatwia im-
plementacje modułu komunikacyjnego w warstwie aplikacji.
Z punktu widzenia uzytkownika zestawienie połaczenia miedzy aplikacja a kontrolerem
nie stanowi zadnej trudnosci. Wystarczy wykorzystac system operacyjny do sparowania od-
powiednich urzadzen. Poniewaz pojedynczy adapter pozwala utrzymac wiele połaczen w tym
samym czasie, nie sa konieczne zadne zmiany w istniejacej infrastrukturze.
Podsumowujac, ze wzgledu na rozpowszechnienie, niski koszt i prostote technika Blueto-
oth spełnia w najwyzszym stopniu wszystkie wymagania biznesowe. Z technicznego punktu wi-
dzenia jest rozwiazaniem poprawnym, jednak niepozbawionym istotnych wad, takich jak opóz-
nienia i potencjalna wrazliwosc na zakłócenia.
ZigBee
ZigBee jest protokołem bezprzewodowego przesyłu danych zaprojektowanym z mysla
o obsłudze sieci typu PAN (ang. Personal Area Network[15], siec, której zasieg ogranicza sie
do przestrzeni osobistej). Dzieki temu urzadzenia komunikujace sie w technice ZigBee cha-
rakteryzuja sie niewielkim rozmiarem i zuzyciem mocy. Z uwagi na ograniczone mozliwosci
sterowania elementami sieci PAN, tworzace ja urzadzenia same buduja ad-hoc siec kratowa, po-
zwalajaca komunikowac sie nawet tym komponentom, które znajduja sie nawzajem poza swoim
zasiegiem.
ZigBee operuje w dwóch nielicencjonowanych pasmach: 868 MHz (w USA: 915 MHz)
dla transmisji 20kbit/s i 2.4GHz dla transmisji 250kbit/s. Wykorzystanie pasma o nizszej cze-
stotliwosci pozwala znaczaco zwiekszyc zasieg komunikacji i ograniczyc opóznienia wywołane
zakłóceniami w pasmie 2.4Ghz.
37
Z punktu widzenia uzytkownika ZigBee jest najłatwiejsze w konfiguracji, poniewaz z za-
łozenia poszczególne elementy systemu same zajmuja sie organizacja sieci. Dzieki prostej im-
plementacji stosu protokołów programowanie kontrolera bomby jest znaczaco ułatwione, a za-
potrzebowanie na zasoby - ograniczone.
Najwieksza wada tej techniki jej słaba marka na rynku konsumenckim. ZigBee cieszy sie
popularnoscia głównie w zastosowaniach medycznych i pomiarowych, jest tez czesto wyko-
rzystywane w nowatorskich projektach zwiazanych z inteligentnym otoczeniem. Przecietny
uzytkownik nie dysponuje jednak urzadzeniami wspierajacymi ten standard. Przekłada sie to
na wzrost kosztów produktu i brak mozliwosci wykorzystania sprawdzonej marki w celach
promocyjnych. Znacznie utrudnia to tez ewentualna ekspansje na rynek smartfonów, bowiem
urzadzenia tego typu zwykle nie dysponuja odpowiednim adapterem ani portem USB, z któ-
rego mógłby skorzystac adapter zewnetrzny.
3.2.3 Podsumowanie
W powyzszym zestawieniu nie zostały uwzglednione dwie czesto stosowane techniki bez-
przewodowej komunikacji:
• siec GSM/UMTS/LTE - ze wzgledu dodatkowy koszt, opóznienia i straty wynikajace
z wykorzystania sieci publicznej,
• rozwiazania dedykowane - ze wzgledu na dodatkowy koszt projektu i produktu konco-
wego.
Sposród rozwazanych rozwiazan w pierwszej kolejnosci wyeliminowac mozna siec Wi-
Fi, zarówno ze wzgledów technicznych, jak tez biznesowych. Przemawiaja za tym duze wyma-
gania na zasoby, trudnosci zwiazane z konfiguracja i narzut komunikacyjny.
Sposród pozostałych dwóch omawianych metod komunikacji z technicznego punktu wi-
dzenia lepszym rozwiazaniem jest ZigBee. Zapewnia wprawdzie niezbyt wysoka przepływ-
nosc, ale gwarantuje mniejsze opóznienia i straty zwiazane z prostszym stosem protokołów
i wykorzystaniem pasma innego niz 2.4Ghz.
Z punktu widzenia biznesowego relacja ta jest odwrotna. Bluetooth jest marka znana
konsumentom i cieszaca sie duza popularnoscia. Wiekszosc urzadzen na rynku albo jest wy-
posazona w odpowiednie adaptery fabrycznie, albo umozliwia łatwe podłaczenie niedrogiego
modemu przez USB. Znacznie poprawia to marketingowa pozycje produktu koncowego.
38
W tej sytuacji rozstrzygajaca role maja kwestie biznesowe. Aby zabawka spełniła za-
równo swój cel edukacyjny, jak i umozliwiła osiagniecie zysku konieczna jest maksymalizacja
sprzedazy. Nawet najlepsze rozwiazanie techniczne na nic sie nie zda, jesli nie zostanie zaak-
ceptowane przez konsumentów.
A zatem, po podsumowaniu was i zalet wszystkich rozwiazan, to własnie Bluetooth zdaje
sie byc odpowiednia metoda komunikacji miedzy aplikacja a kontrolerem bomby.
39
4 Realizacja
4.1 Aplikacja PC
4.1.1 Zasada działania
Aplikacja PC zajmuje sie obsługa logiki zabawki. Steruje przebiegiem zabawy, informuje
uzytkownika o kolejnych działaniach, które powinien przedsiewziac, odbiera i interpretuje dane
z kontrolera, oraz decyduje o koncowym wyniku.
Komunikacja z uzytkownikiem odbywa sie przy pomocy interfejsu graficznego. Zabawka
z załozenia powinna obsługiwac wiele wersji jezykowych, dlatego wszystkie teksty wyswie-
tlane na ekranie powinny byc pobierane ze stosownych plików słownika. Przygotowany w ra-
mach ponizszej pracy prototyp obsługuje jezyki polski i angielski. Informacja o uzywanym
jezyku znajduje sie w pliku konfiguracyjnym.
Pełen opis zabawy dostepny jest z poziomu menu głównego. W trakcie składania bomby
uzytkownik moze kliknac na ikony poszczególnych elementów układu elektronicznego by
otrzymac skrócony opis ich działania oraz fotografie pozwalajaca mu odniesc symbol ze sche-
matu do obiektu ze swiata rzeczywistego.
Po rozpoczeciu zabawy, uzytkownik wybiera scenariusz z przedstawionej listy. Nazwa
scenariusza moze nawiazywac do popularnego filmu, motywu przewodniego zagadek lub byc
wytworem fantazji twórcy. Opcjonalnie autor moze umiescic krótkie wprowadzenie, pozwala-
jace uzytkownikowi lepiej wczuc sie w role bohatera. Ekran wyboru scenariusza widoczny jest
na Rysunku 4.1.
Na górze widoczne jest rozwijane menu z lista dostepnych scenariuszy. Po wybraniu jed-
nego z nich wyswietlony zostaje tytuł, poziom trudnosci i wprowadzenie.
Po wyborze scenariusza, aplikacja odczytuje z powiazanego pliku schemat bomby. Pliki
schematów zapisane sa w formacie CSV (ang. Comma Separated Values, poszczególne wartosci
dla rekordu oddzielone sa przecinkami), jednak dla jasnosci zapisywane sa z rozszerzeniem
SCH1. Kazdy rekord w pliku rozpoczyna sie identyfikatorem elementu, od którego zalezy układ
pozostałych pól rekordu. Lista rozpoznawanych identyfikatorów znajduje sie w załaczniku B.
1Skrót od angielskiego słowa schematics
40
Rysunek 4.1: Ekran wyboru scenariusza.
Po odczytaniu pliku schematu aplikacja wyswietla układ elektroniczny (którego złozenie
nalezy do uzytkownika) i oczekuje na dane z kontrolera. Gdy stan portów wejsciowych bedzie
zgodny z oczekiwanym, aplikacja automatycznie przejdzie w tryb zagadek.
W trybie zagadek aplikacja wyswietla na ekranie wskazówke umozliwiajaca uzytkow-
nikowi odgadniecie kolejnego kroku na drodze do rozbrojenia bomby. Poszlaka stanowiaca
odpowiedz na zagadke moze obejmowac tekst i multimedia w postaci dzwieków i obrazów.
Kontroler bomby co pewien czas przysyła do aplikacji raport o stanie swoich portów wej-
sciowych. Aplikacja porównuje otrzymane dane z oczekiwanymi w scenariuszu wartosciami.
W zaleznosci od wyniku analizy aplikacja moze wyswietlic kolejna zagadke, zakonczyc zabawe
lub zaczekac na kolejny raport.
Oczekiwane wartosci odczytane z portów wejsciowych kontrolera moga wystapic jako
lista stanów dozwolonych lub zabronionych, w zaleznosci od decyzji projektanta scenariusza.
W pierwszym przypadku wykrycie jakiegokolwiek stanu spoza listy automatycznie konczy gre.
W drugim przypadku przeciwnie - tylko stany zawarte na liscie powoduja porazke.
41
Rysunek 4.2: Przykładowy schemat układu wyswietlany przez aplikacje. Po prawej stronie
ekranu widoczny jest ekran pomocy opisujacy działanie rezystora. Plik na podstawie którego
wygenerowany został pokazany schemat znajduje sie w załaczniku E.
Kazda zagadka wymaga dwóch list stanu portów: warunków kontynuacji, przy któ-
rych zabawa trwa, ale zagadka sie nie zmienia, oraz warunków granicznych, przy których za-
gadka zostaje uznana za rozwiazana. Lista warunków granicznych poprzedniej zagadki powinna
byc dołaczana do listy warunków kontynuacji kolejnej. W przeciwnym razie gra zakonczy sie
natychmiast po przejsciu do kolejnej zagadki.
W przypadku cyfrowych portów wejsciowych stany podane na liscie musza byc okre-
slone precyzyjnie, wartosciami 0 lub 1. Jesli wartosc danego portu przy okreslonej zagadce jest
bez znaczenia, jego numeru nie nalezy umieszczac na liscie. W takim wypadku zalecane jest
przekazanie kontrolerowi informacji, by w czasie wyswietlania danej zagadki w ogóle nie prze-
syłał danych o stanie tego portu2. Wartosci portów analogowych powinny byc podawane jako
zakres ze wzgledu na ograniczona precyzje odczytu i niedoskonałosci elementów układu.
2Wiecej informacji o zarzadzaniu portami znajduje sie w sekcji dotyczacej komunikacji.
42
Wyswietlane na ekranie zagadki pochodzic moga z dwóch zródeł: plików skojarzonych
z konkretnym scenariuszem lub zestawu wspólnego dla całej aplikacji. Istnieje mozliwosc poda-
nia kilku zagadek, których rozwiazanie prowadzi do takich samych rezultatów. W takim przy-
padku wyswietlana zagadka wybierana jest losowo. Pozawala to urozmaicic zabawe i wielo-
krotnie wykorzystywac ten sam scenariusz.
Gdy rozwiazana zostanie ostatnia zagadka aplikacja wyswietla informacje o sukcesie.
Opcjonalnie twórca scenariusza moze umiescic krótki epilog opisujacy zaszczyty i nagrody dla
bohatera, w którego wcielał sie gracz.
4.1.2 Wybór jezyka
Do zaimplementowania aplikacji PC rozwazane były trzy jezyki programowania:
• C++,
• Java,
• Python.
Kazdy z nich niesie ze soba okreslone wady i zalety, zatem niezmiernie istotny jest wybór
odpowiedniego narzedzia do rozwiazania problemu. Nalezy zatem precyzyjnie okreslic zadania
aplikacji i dobrac jezyk jak najlepiej spełniajacy wynikajace z tego wymagania. Podstawowe
funkcjonalnosci aplikacji, obejmowane załozeniami projektu to:
1. Komunikacja przez wirtualny port szeregowy z kontrolerem bomby.
2. Parsowanie plików z danymi (wykorzystywane formaty: CSV, HTML).
3. Komunikacja z uzytkownikiem przez interfejs graficzny.
4. Przenosnosc miedzy systemami operacyjnymi.
W pierwszej kolejnosci odrzucony został Python. Głównym argumentem przeciw temu
jezykowi była koniecznosc instalacji interpretera na maszynie uzytkownika. Przecietny uzyt-
kownik nie korzysta z jezyków skryptowych, zatem konieczne byłoby dostarczenie srodowiska
w odpowiedniej wersji ze wszystkimi zaleznosciami.
Drugim problemem jest dystrybucja aplikacji bez kodów zródłowych. Z załozenia Python
nie oferuje takiej mozliwosci, choc istnieja zewnetrzne narzedzia umozliwiajace osiagniecie
tego celu. Ich wykorzystanie nastrecza jednak wielu problemów[17]. Po trzecie, jest to jezyk,
43
z którym autor pracy miał najmniej stycznosci w momencie podejmowania decyzji. Istotnie
utrudniłoby to wstepna ocene pracochłonnosci i potencjalnego ryzyka.
Za wykorzystaniem przemawiały z kolei liczne biblioteki, umozliwiajace efektywne
parsowanie plików tekstowych i platformy programistyczne pozwalajace tworzyc interfejsy
graficzne[16]. Do komunikacji szeregowej wykorzystywana jest biblioteka pySerial. Działa
ona poprawnie na wszystkich platformach, jednak jej istotna wada jest nietypowo zaprojekto-
wany interfejs, negatywnie wpływajacy na czytelnosc kodu.
Jezyk C++ został odrzucony z powodu problemów z przenosnoscia miedzy syste-
mami operacyjnymi. Dotyczy to zarówno modułu interfejsu graficznego, jak tez komunikacji
przez port szeregowy. Ze wzgledu na niewielka złozonosc wykonywanych obliczen wykorzy-
stanie tego jezyka nie przyniosłoby tez widocznego przyspieszenia działania aplikacji.
Ostatecznie do implementacji wybrany został jezyk Java. Dysponuje on bogatymi i wy-
godnymi w uzyciu narzedziami do tworzenia interfejsów graficznych i parsowania plików tek-
stowych, z załozenia jest przenosny miedzy platformami i w prosty sposób pozwala wygene-
rowac plik wykonywalny udostepniany uzytkownikowi. Ponadto maszyna wirtualna Javy jest
wymagana do działania wielu aplikacji internetowych, zatem mozna załozyc, ze uzytkownik
bedzie miał zainstalowane odpowiednie srodowisko.
4.1.3 Implementacja
Aplikacja działa w pojedynczym oknie. Obsługiwana jest przy pomocy myszki. Interfejs
dotykowy ani klawiatura nie sa wykorzystywane. Rozdzielczosc okna pobierana jest z pliku
konfiguracyjnego.
Do poprawnego działania potrzebuje pliku wykonywalnego i katalogu z zasobami. Struk-
tura takiego katalogu z przykładowymi plikami znajduje sie na Rysunku 4.3.
Plik Configuration.cfg przechowuje informacje o roboczej konfiguracji aplika-
cji, takie jak wersja jezykowa, rozdzielczosc i parametry połaczenia z bomba. W kazdej linii
pliku znajduje sie para klucz-wartosc. Dostep do danych z pliku konfiguracyjnego odbywa sie
przy pomocy metod publicznych klasy Configuration. Klasa ta przechowuje tez dane za-
kodowane na sztywno, do których uzytkownik nie powinien miec dostepu.
Pliki z rozszerzeniem .dic zawieraja teksty bedace elementami interfejsu uzytkownika.
Zabawka z załozenia wspiera wiele wersji jezykowych, zatem zadne teksty nie mogły byc cze-
scia kodu aplikacji. System słowników pozwala w prosty sposób podmieniac teksty i tworzyc
44
nowe wersje jezykowe bez modyfikacji samego programu. Znaki diakrytyczne kodowane sa
w standardzie Unicode.
Teksty przechowywane sa w postaci par klucz-wartosc. Lista dostepnych kluczy znaj-
duje sie w typie wyliczeniowym Entries. Kolejnosc umieszczenia tekstów w pliku jest do-
wolna.
Nazwa pliku słownika stanowi kombinacje oznaczenia wersji jezykowej pobranej z kon-
figuracji i rozszerzenia .dic. W plikach słownika nie ma tekstów zwiazanych z opisami sce-
nariuszy, elementów, ani zagadek.
Katalog Elements zawiera pliki z opisami poszczególnych elementów elektronicznych
wyswietlanymi w na etapie składania bomby. Nazwa podkatalogu koresponduje z oznaczeniem
danego elementu w aplikacji. Na Rysunku 4.3 przedstawiono tylko kilka przykładowych ele-
mentów - pełna lista znajduje sie w typie wyliczeniowym Types, a takze w załaczniku B.
Rysunek 4.3: Przykładowy katalog z zasobami aplikacji.
Wyjatkowymi elementami sa
Empty i Error.
Element Empty nie ma swo-
jego katalogu z zasobami. Na ry-
sunku ze schematem stanowi on pu-
ste miejsce, a klikniecie na niego
nie daje zadnego rezultatu. Jesli
w pliku ze schematem nie zostały
uwzglednione jakies współrzedne,
domyslnie wstawiany jest na nich
element EMPTY.
W przypadku problemów
z odczytaniem informacji o danym
elemencie na schemacie wyswie-
tlany jest symbol błedu, w postaci
wyraznego znaku X. Klikniecie na
ten symbol wywołuje wypisanie
odpowiedniego komunikatu na
ekranie pomocy, pobranego z pli-
ków zasobów elementu ERROR.
45
Opisy elementów znajduja sie w plikach .html, co umozliwia uzyskanie w prosty spo-
sób estetycznego efektu. Pozwala to tez korzystac z plików multimedialnych, w celu wzboga-
cenia prezentacji o obraz i dzwiek. Dla kazdej wersji jezykowej przewidziany jest osobny plik
z opisem. Nazwa kazdego z nich rozpoczyna sie od oznaczenia jezyka, po której nastepuje na-
zwa elementu, taka sama, jak nazwa katalogu. Jesli odpowiedni plik nie zostanie znaleziony dla
danej wersji jezykowej, na ekranie pomocy wypisywana jest jedynie angielska nazwa danego
elementu.
Katalog Riddles zawiera wspólna dla wszystkich scenariuszy pule zagadek. Wspólna
pula zagadek stanowi ułatwienie dla poczatkujacych twórców scenariuszy, którzy chca ograni-
czyc sie na przykład do projektowania układów elektronicznych. Znajdujace sie tam zagadki
stanowia tez zródło wskazówek dla osób chcacych wymyslac własne łamigłówki.
Zasoby danej zagadki znajduja sie w podkatalogu, którego nazwa jest jej identyfikato-
rem. Tresc zagadki znajduje sie w pliku .html. Dla kazdej wersji jezykowej przewidziany jest
osobny plik. Nazwa kazdego pliku .html składa sie z oznaczenia wersji jezykowej i identyfi-
katora zagadki.
Katalog Schematics zawiera wspólna pule plików ze schematami bomb do wykorzy-
stania w róznych scenariuszach. Taka organizacja ułatwia prace poczatkujacym twórcom. Pliki
schematów składaja sie z serii rekordów, których format opisany jest w załaczniku B.
Scenariusze zabawy znajduja sie w katalogu Scenarios. Kazdy z nich ma swój uni-
kalny identyfikator, bedacy jednoczesnie nazwa podkatalogu z jego zasobami.
W kazdym podkatalogu musi znajdowac sie plik w formacie .sce opisujacy dany sce-
nariusz. Zawarte sa w nim nastepujace informacje:
1. Tytuły, poprzedzone identyfikatorami jezyka i oddzielone przecinkami, np. "en-Title,pl-
Tytuł".
2. Poziom trudnosci, przyjmujacy jedna z czterech wartosci: EASY (łatwy), NORMAL
(sredni), HARD (trudny), EXPERT (bardzo trudny).
3. Nazwa pliku ze schematem układu, moze byc poprzedzona znakiem specjalnym @ jesli
znajduje sie on we wspólnej puli, lub $ jesli nalezy szukac go w zasobach scenariusza
(stosowny plik powinien byc umieszczony w podkatalogu Schematics), przy braku
znaku specjalnego najpierw przeszukiwane sa zasoby scenariusza, a nastepnie pula ogól-
nodostepna.
46
4. Lista plików z opisem scenariusza, który zostanie przedstawiony uzytkownikowi na po-
czatku zabawy, na kazda wersje jezykowa powinien przypadac przynajmniej jeden plik
(jesli plików dla danej wersji jezykowej jest wiecej, wybierany jest losowo jeden z nich).
5. Nazwa pliku z lista kroków rozgrywki.
Przykładowy plik scenariusza znajduje sie w załaczniku D.
Po rozpoczeciu nowej gry aplikacja skanuje katalog ze scenariuszami i wyswietla liste
tytułów pobranych ze znalezionych plików .sce. Wybierajac jeden z nich, uzytkownik otrzy-
muje informacje o poziomie trudnosci danego scenariusza i opis pobrany z wybranego pliku.
Opis ten moze zawierac róznego typu informacje, takie jak wprowadzenie fabularne, wska-
zówki odnosnie tematyki zagadek lub dowolna inna wiadomosc od autora do odbiorcy, majaca
zachecic uzytkownika do wybrania własnie tego scenariusza.
Po wybraniu jednego ze scenariuszy aplikacja nawiazuje połaczenie z kontrolerem, wy-
swietla schemat i oczekuje na sygnał gotowosci. W trakcie składania bomby uzytkownik moze
kliknac na rysunek dowolnego elementu, by uzyskac pomoc. Na panelu bocznym wyswietlona
zostaje wówczas tresc pliku .html skojarzonego z danym elementem.
Gdy bomba jest gotowa, aplikacja przechodzi w tryb zagadek. Lista zagadek i kolejnych
stanów aplikacji pobierana jest z pliku tekstowego z lista kroków. Plik ten nie ma z góry przy-
jetego rozszerzenia. Kazdy krok opisany jest jako lista wartosci w okreslonym formacie. Po-
szczególne kroki oddzielone sa pustymi liniami.
Pierwszym krokiem jest zawsze inicjalizacja kontrolera. Etap ten nie ma skojarzonej
z nim zagadki. Kazdy kolejny krok rozpoczyna sie nazwa odpowiedniej zagadki poprzedzonej
znakiem specjalnym @ dla zagadek ze wspólnej puli, lub $ dla pobieranych z puli scenariusza.
Rozwiazanie niektórych zagadek moze byc rozłozone na kilka kroków. W kolejnych liniach
podane sa rekordy dotyczace oczekiwanego stanu portów dla danego kroku.
Opis stanu portu składa sie z identyfikatora typu portu, numeru, oraz stanu. Ponadto
mozliwe jest korzystanie z operatorów, wskazujacych na to, jak aplikacja powinna zareagowac
na wykrycie danego stanu. Lista dostepnych operatorów znajduje sie w Tabeli 4.1, natomiast
przykłady uzycia w Załaczniku C.
Z kazdym portem moze byc skojarzonych wiele wpisów, przykładowo stan wysoki na da-
nym porcie cyfrowym moze wymusic trzy zmiany przesłane do kontrolera i jednoczesnie stano-
wic warunek przejscia do kolejnego etapu. Jesli port nie znajduje sie na liscie dla danego etapu
47
Operator Znaczenie
Brak operatora oznacza, ze dany stan jest dozwolony
~ Operator negacji, wykrycie tego stanu powoduje natych-
miastowa eksplozje
-> Operator zmiany, w wiadomosci zwrotnej nalezy nakazac
kontrolerowi zmiane stanu jednego z portów
! Jeden z warunków przejscia do kolejnego etapu
Tabela 4.1: Operatory uzywane w opisie stanów portów
przyjmuje sie, ze kazdy jego stan jest dozwolony. Aby przejsc do kolejnego etapu, spełnione
musza byc wszystkie warunki. Po spełnieniu warunków ostatniego etapu zabawa konczy sie,
a uzytkownik otrzymuje informacje o wygranej.
Opcjonalnie ostatnim wpisem w pliku z opisem kolejnych etapów moze byc identyfi-
kator ekranu koncowego, sformatowany podobnie jak identyfikator zagadki. Przy jego braku,
wyswietlany jest ekran domyslny. Rysunek 4.4 przedstawia przykładowy ekran z gratulacjami.
Błedne rozwiazanie zagadki powoduje natychmiastowy wybuch bomby. Nie sa przewi-
dziane zadne ostrzezenia ani mozliwosci naprawienia błedu. Powiadomienie o wybuchu składa
sie z serii zdjec (np. eksplozji i nadjezdzajacych wozów strazackich) i towarzyszacych im efek-
tów dzwiekowych (np. huku, krzyków i syren). Rysunek 4.5 przedstawia jedno z przykłado-
wych zdjec.
Poniewaz wszystkie pliki uzywane do opisu zabawy sa w formatach tekstowych, nie po-
trzeba zadnych specjalnych narzedzi do tworzenia własnych scenariuszy i zagadek. Wymagane
jest jedynie zachowanie ustalonej struktury katalogów.
4.2 Bomba
Bedaca przedmiotem zabawy bomba to w istocie układ elektroniczny złozony z modułów,
które mozna łaczyc na rózne sposoby. Złozenie układu z odpowiednich elementów, a nastepnie
jego stopniowe rozkładanie stanowi kluczowy element zabawy.
Rdzeniem bomby jest układ złozony z kontrolera, wyswietlacza, przycisku startu, mo-
demu do komunikacji bezprzewodowej, płytki stykowej i zasilacza. Na etapie prototypu ele-
menty te nie sa połaczone na stałe, jednak w przypadku gotowego produktu stanowic musza
zwarta całosc.
48
Rysunek 4.4: Przykładowy ekran widoczny po rozbrojeniu bomby.
Kontroler bomby to układ mikroprocesorowy nadzorujacy działanie reszty układów i ko-
munikujacy sie z aplikacja PC. Zgodnie z analiza przeprowadzona w rozdziale 3, wybrana
została do tego celu platforma Arduino. W prototypie wykorzystany został model Uno
ze wzgledu na wszechstronnosc i niska cene. Oferuje on 14 portów cyfrowych (z czego 6 pełnic
moze role analogowych portów wyjsciowych), 6 analogowych portów wejsciowych, szyne I2C
oraz piny 3.3V i 5V słuzace do zasilania zewnetrznych układów. Cyfrowe porty 0 i 1 przezna-
czone sa do obsługi modemu komunikacji bezprzewodowej, ponadto cyfrowy port 2 zarezer-
wowany jest na rzecz przycisku startu. Szyna I2C słuzy do obsługi cyfrowego wyswietlacza.
W przypadku koniecznosci uzycia jej do komunikacji z innym modułem mozliwe jest wyko-
rzystanie multipleksera lub drugiej płytki Arduino, z która zostanie nawiazana komunikacja
przez port szeregowy.
49
Rysunek 4.5: Przykładowy ekran widoczny po wybuchu bomby. W trakcie działania aplikacji
towarzyszy mu odgłos huku i okrzyk przerazenia (znany z filmów tak zwany „Wilhelm Scream”
[21].)
Wyswietlacz informuje uzytkownika o aktualnym stanie bomby. Jego główna funkcja jest
odliczanie czasu pozostałego na jej rozbrojenie. Ze wzgledu na głebokie zakorzenienie w po-
pkulturze, wykorzystany został czerwony wyswietlacz cyfrowy. Mozliwe stany wyswietlacza
wymienione zostały w Tabeli 4.2.
W tworzonym w ramach ponizszej pracy prototypie wszystkie wymienione elementy
bomby łaczone sa tymczasowo za pomoca kabli wielokrotnego uzytku i płytek prototypowych
(Rysunek 4.8). Wyjatkiem jest wyswietlacz LCD, który wymaga do komunikacji kabli lepszej
jakosci by uniknac zakłócen wynikajacych z odbic.
Docelowo układ mikroprocesorowy, wyswietlacz i przycisk startu zostana połaczone na
stałe wewnatrz obudowy. Polem działania uzytkownika bedzie płytka stykowa wzorowana na
płytce prototypowej, na której zostana wyszczególnione szyny zwarte z portami kontrolera.
50
Stan wyswietla-
cza
Znaczenie
„—-” Oczekiwanie na inicjalizacje
„InI ” Nawiazano komunikacje z aplikacja
PC, oczekiwanie na gotowosc
„0001”-„9999” Liczba sekund pozostałych do konca
„End ” Zabawa skonczona
„booo” Bomba eksplodowała
„Err ” Wystapił bład
Tabela 4.2: Stany wyswietlacza bomby.
Rysunek 4.6: Prototyp zabawki - elementy podstawowe. Kontroler jest w trybie oczekiwania na
inicjalizacje i nie sa do niego podłaczone zadne elementy zwiazane z konkretnym scenariuszem.
Aby ułatwic weryfikacje poprawnosci złozonego przez uzytkownika schematu wejscia płytki
stykowej moga miec rózny kształt, korespondujacy z kształtem wtyczek róznych modułów.
Ograniczy to pule mozliwych do popełnienia błedów i ułatwi ich identyfikacje. Ponadto czesc
portów wejsciowych kontrolera moze zostac przeznaczona do celów diagnostycznych.
W prototypie porty kontrolera ani elementy układu nie sa w zaden sposób zabezpieczone
przed ewentualnym uszkodzeniem. Przy projektowaniu finalnego urzadzenia pamietac nalezy
51
Rysunek 4.7: Prototyp zabawki - przykładowa bomba. Elementami zwiazanymi ze scenariu-
szem sa trzy róznokolorowe kable (czerwony, niebieski i biały), potencjometr, dzielnik napie-
ciowy składajacy sie z fotorezystora i opornika, oraz dwie diody elektroluminescencyjne.
o ryzyku wystapienia uszkodzen mechanicznych, zalania lub błednego podłaczenia komponen-
tów przez uzytkownika. Wrazliwe układy kontrolera powinny byc zatem jak najlepiej osłoniete
przed szkodliwymi czynnikami zewnetrznymi. Elementy bomby z kolei powinny byc wyko-
nane w taki sposób, by niemozliwe było stworzenie układu mogacego potencjalnie uszkodzic
kontroler.
4.3 Komunikacja
Zgodnie z załozeniami projektu, komunikacja miedzy aplikacja a kontrolerem bomby
odbywa sie droga bezprzewodowa. Na podstawie analizy przedstawionej w rozdziale 3 wybrana
została do tego celu technologia Bluetooth.
W projektowanym prototypie po stronie kontrolera został wykorzystany modem
BlueSmirf HID firmy Sparkfun. Istotna zaleta tego modelu jest automatyczne tworzenie
wirtualnego łacza szeregowego ze sparowanym komputerem, co znacznie ułatwia implementa-
cje komunikacji zarówno po stronie aplikacji PC, jak tez kontrolera. Ponadto połaczenie mo-
demu z Arduino jest znaczaco ułatwione dzieki mozliwosci podłaczenia go do sprzetowego
portu szeregowego obecnego w wiekszosci układów ATMega.
52
Rysunek 4.8: Płytki prototypowe (ang. breadboard) i kable wykorzystane w prototypie
Wada zastosowanego układu jest koniecznosc pobierania pradu bezposrednio z zasila-
cza zamiast z pinu +5V udostepnionego przez Arduino. Wynika to z duzego zapotrzebowania
na moc w trakcie parowania modemu z komputerem. Jako ze Arduino wymaga napiecia zasi-
lajacego w granicach 7-12V, a modem napiecia około 5V, niezbedne jest równiez zastosowanie
dzielnika napieciowego.
Z powodu problemów technicznych (opisanych szerzej w Rozdziale 5) modem został
zastapiony pózniej shieldem Bluetooth firmy Seeedstudio. Jego zalety to prostszy montaz,
nizsza cena i nizsze zapotrzebowanie na moc, dzieki czemu moze byc on zasilany bezposrednio
z portu 3.3V Arduino. Wadami shielda sa wiekszy rozmiar i dziesieciokrotnie mniejszy zasieg
(maksymalny zasieg modemu BlueSmirf HID to około 100 metrów).
4.3.1 Protokół komunikacyjny
Aby umozliwic poprawna komunikacje miedzy aplikacja a kontrolerem bomby niezbedne
było opracowanie stosownego protokołu komunikacyjnego. Projektowane rozwiazanie spełnic
musiało nastepujace warunki:
• zapewnienie integralnosci przesyłanych danych,
• umozliwienie modyfikacji stanu portów kontrolera przez aplikacje,
53
Rysunek 4.9: Arduino UNO z zamontowanym shieldem Bluetooth
• skalowalnosc pod katem nowych typów modułów podłaczanych do kontrolera.
Pojedyncza ramka protokołu składa sie z nastepujacych elementów:
1. Flagi startowej, majacej heksadecymalna wartosc 0x53 (kod ASCII litery ’S’).
2. Długosci pola danych zapisanej na jednym bajcie.
3. Pola danych.
4. Flagi koncowej, majacej heksadecymalna wartosc 0x45 (kod ASCII litery ’E’).
5. Sumy kontrolnej, bedacej wynikiem operacji XOR na bajtach pola danych (bez flagi po-
czatkowej, długosci i flagi koncowej).
Integralnosc danych zapewnia obecnosc flag poczatkowej i koncowej, oraz suma kontro-
lna. Moduł odbiorczy ignoruje przychodzace bajty dopóki nie natrafi na wartosc flagi poczat-
kowej. Nastepnie wczytywana jest długosc pola danych, po czym na podstawie tej informacji
do bufora odbiorczego kopiowana jest stosowna liczba wczytanych bajtów, po czym spraw-
dzana jest obecnosc flagi koncowej i wyliczana suma kontrolna.
54
Długosc pola danych zakodowana jest na pojedynczym bajcie, co ogranicza jego maksy-
malny rozmiar do 255 oktetów. Ograniczenie to narzucone jest przez niewielka ilosc pamieci
RAM dostepnej na Arduino. O ile przesyłanie danych z kontrolera do aplikacji nie wymaga
przechowywania w pamieci całego bufora, o tyle w przypadku odbierania wiadomosci, kon-
troler musi najpierw zapisac przesłane dane, a nastepnie sprawdzic poprawnosc flag i sumy
kontrolnej. Poniewaz podana jest liczba oczekiwanych bajtów pola danych, z góry znane jest
miejsce spodziewanego wystapienia flagi koncowej. Jej brak jest wskazuje na wystapienie błedu
transmisyjnego.
Jezeli stwierdzona zostanie obecnosc własciwych flag, pole danych jest poprawnie sfor-
matowane i zgadza sie suma kontrolna, odbiorca odsyła wiadomosc o tresci „ACK”. W przeciw-
nym razie nadawca informowany jest o porazce komunikatem „NACK”. W zaleznosci od kon-
tekstu nadawca moze dokonac retransmisji danych, zignorowac problem lub zakonczyc komu-
nikacje.
Aplikacja PC moze przesłac do kontrolera dwa typy wiadomosci: inicjalizacyjna
lub zwrotna, stanowiaca reakcje na odczytany stan portów. Wiadomosc inicjalizacyjna składa
sie wyłacznie z rekordów dotyczacych wstepnego stanu portów kontrolera. Wiadomosc zwrotna
zaczyna sie od trzybajtowego statusu okreslajacego zgodnosc odebranych danych z oczekiwa-
nymi. Lista statusów i przypisanych do nich kodów znajduje sie w Tabeli 4.3.
Kontroler przesyła do aplikacji tylko jeden typ wiadomosci, stanowiaca raport o stanie
portów. Otrzymanie pierwszego statusu typu „OK!” jest sygnałem do rozpoczecia zabawy.
Wiadomosc inicjalizacyjna, komenda „NEW” i raport kontrolera składaja sie z zestawu
rekordów opisujacych stan poszczególnych portów.
Pierwszy bajt rekordu wskazuje na typ opisywanego portu. Na tej podstawie odbiorca
wiadomosci ustala długosc i format rekordu.
Do jednego portu przypisanych moze byc wiele typów. Przykładowo, porty cyfrowe moga
pełnic role:
• cyfrowego wejscia,
• cyfrowego wyjscia,
• analogowego wyjscia,
• połaczenia z zewnetrznym modułem, np. głosnikiem, serwomechanizmem, rejestrem
przesuwnym.
55
Niektóre typy nie sa przypisane do konkretnego portu. Głównym przykładem jest tu czas
pozostały do konca zabawy, przypisany do zmiennej w pamieci, która w protokole komunika-
cyjnym traktowana jest jako wirtualny port.
Wartosc typu „0” zarezerwowana jest jako oznaczenie portów nieuzywanych. Lista uzy-
wanych rekordów wraz z oznaczeniami znajduje sie w załaczniku A.
Kod odpowiedzi
w ASCII
Znaczenie Uwagi
OK! Otrzymane dane sa zgodne
z oczekiwaniami
Komenda nie zawiera dalszych da-
nych
NEW Otrzymane dane sa zgodne
z oczekiwaniami, nalezy
zmienic status okreslonych
portów
Kolejne bajty sformatowane sa iden-
tycznie, jak w przypadku komendy
inicjalizacyjnej
ERR Otrzymane dane sa nie-
zgodne z oczekiwaniami,
uzytkownik poniósł porazke
Komenda wysyłana jest, jesli wartosc
danych jest niezgodna z oczekiwa-
niami, w przypadku otrzymania błed-
nie sformatowanej wiadomosci, apli-
kacja odsyła status „NACK”
WIN Uzytkownik osiagnał sukces
Tabela 4.3: Lista statusów okreslajacych zgodnosc otrzymanych danych z oczekiwaniami
Taka konstrukcja protokołu pozwala obsłuzyc w wiadomosci komunikacyjnej 254 rózne
formy wykorzystania portów kontrolera. Nalezy zauwazyc, ze obsługa wielu sensorów jest nie-
rozróznialna z punktu widzenia protokołu komunikacyjnego (na przykład odczyt stanu poten-
cjometru, termistora, fotorezystora i innych podobnych czujników sprowadza sie do wczytania
danych z portu analogowego wejscia).
Biorac pod uwage ograniczenia pamieci kontrolera, tak zaprojektowany protokół stanowi
rozsadny kompromis miedzy elastycznoscia, a zuzyciem zasobów. Jest tez niezalezny od uzy-
wanej wersji platformy, pełniacej role kontrolera - aby dostosowac go na przykład do Arduino
Mega (zamiast uzytego w prototypie Arduino Uno), wystarczy zmodyfikowac wartosci rekor-
dów stosownie do potrzeb, natomiast sama architektura protokołu pozostaje niezmienna.
56
5 Napotkane problemy
Kazdy projekt niesie ze soba okreslone wyzwania. Zródła problemów moga wynikac za-
równo z błedów popełnionych przy projektowaniu i implementacji rozwiazania, jak tez z po-
wodu czynników zewnetrznych. Istotnym elementem podsumowania pracy nad projektem jest
analiza napotkanych trudnosci i sposobów radzenia sobie z nimi. Dzieki temu producent zy-
skuje wiedze, która moze byc wykorzystana przy tworzeniu kolejnych produktów.
5.1 Modem Bluetooth
Zródłem wiekszosci problemów napotkanych w trakcie projektowania zabawki oka-
zał modem Bluetooth podłaczany do kontrolera bomby. Dzieki wykorzystaniu Arduino
jako układu sterowania, dostepne były az trzy rózne mozliwosci nawiazania komunikacji bez-
przewodowej. Kazde nich okazało sie jednak obarczone okreslonymi wadami.
Rozwiazaniem rozpatrywanym w pierwszej kolejnosci było ArduinoBT,
czyli Arduino Uno z wbudowanym modemem zamiast portu USB. Wybór ten podyk-
towany korzystna ergonomia i wygoda uzytkowania.
Niestety, w czasie miedzy przeprowadzeniem analizy dostepnych rozwiazan, a podjeciem
decyzji o zakupie urzadzenia, producent wycofał produkt ze sprzedazy z powodu wykrycia
wady konstrukcyjnej. Wkrótce potem podana została informacja o całkowitym zaprzestaniu
produkcji tego modelu.
Zalecanym przez fundacje Arduino rozwiazaniem zastepczym było wykorzystanie ze-
wnetrznego modemu. W momencie składania zamówienia na rynku znajdowały sie dwa pro-
dukty tego typu:
• Serial-Bluetooth M/S firmy Seeedstudio, odrzucony ze wzgledu na potencjalne
trudnosci z montazem, wynikajace z nietypowego rozmieszczenia pinów,
• BlueSmirf HID firmy SparkFun, wybrany ze wzgledu na szeroki wachlarz ofero-
wanych mozliwosci.
Po wstepnych testach wyszło na jaw, ze wybór modemu BlueSmirf HID okazał sie
nietrafny z wielu powodów. Pierwszym napotkanym problemem było doprowadzenie zasila-
nia do urzadzenia. W trakcie zwykłej komunikacji modem potrzebuje jedynie 1.25 mW mocy,
jednak podczas parowania z drugim urzadzeniem pobór rosnie do około 300 mW. Pojedynczy
57
port Arduino nie moze jednak dostarczyc wiecej niz 250 mW, przez co nawiazanie połacze-
nia było niemozliwe. W specyfikacji produktu na stronie producenta nie ma wzmianki o tym
problemie, dlatego wykryty on został dopiero przy próbie sparowania kontrolera z aplikacja.
Konieczne okazało sie podłaczenie zewnetrznego zródła zasilania do modemu. Spowodowało
to jednak dalsze problemy, poniewaz Arduino wymaga zasilania w zakresie 7-12V, natomiast
modem - 5V. Rozwiazaniem okazało sie wykorzystanie osobnego zródła zasilania dla kazdego
z urzadzen.
Drugim problemem okazały sie przewody łaczace modem z Arduino. Nawet przy ni-
skiej przepływnosci czesto mozna było zaobserwowac problemy z transmisja danych, wynika-
jace z odbic i zakłócen.
Pomimo podłaczenia dedykowanego zródła zasilania i zastosowania kabli wysokiej ja-
kosci, a takze umieszczenia modemu z dala od potencjalnych zródeł zakłócen komunikacja
z komputerem nadal sprawiała problemy na etapie parowania urzadzen. Modem czesto zgłaszał
bład uwierzytelnienia, mimo podania poprawnego PINu.
Wsród kryteriów, które zdecydowały o wyborze modemu BlueSmirf HID, były do-
datkowe opcje, wykraczajace poza wstepnie postawione wymagania, jak:
• tryb HID, dzieki któremu modem rejestrował sie w systemie sparowanego z nim urzadze-
nia jako klawiatura, nie zas wirtualny port szeregowy,
• opcje diagnostyczne, pozwalajace dokonac analizy jakosci kanału transmisyjnego,
• zasieg do 100 metrów,
• wiele mozliwosci konfiguracyjnych.
Poniewaz wybór urzadzenia został dokonany na wczesnym etapie projektu, rozsadne
wydawało sie zapewnienie mozliwosci eksperymentowania z wieloma rozwiazaniami, ta-
kimi jak tryb HID, a zaawansowana diagnostyka mogła umozliwic lepsza ocene finalnego pro-
duktu. W praktyce funkcjonalnosci te okazały sie niezbyt uzyteczne. Wstepny projekt wykorzy-
stania modemu jako wirtualnego portu szeregowego okazał sie byc najbardziej efektywny, a do-
datkowe mozliwosci oferowane przez zakupiony model spowalniały tylko działanie zabawki,
poniewaz wymagały wyłaczenia przy kazdym starcie kontrolera, by nie zakłócały komunikacji
z aplikacja PC.
Ostatecznie urzadzenie uległo awarii z powodu zle podłaczonego zródła zasilania.
58
Modem BlueSmirf HID został zastapiony dedykowanym dla Arduino UNO shiel-
dem Bluetooth firmy Seeedstudio. Pierwszy egzemplarz okazał sie miec wade fabryczna unie-
mozliwiajaca poprawne działanie. Producent uznał swój bład, przyjał reklamacje i wymienił
urzadzenie na nowe.
Kolejnym problemem był bład w przykładowej aplikacji pokazujacej, jak nalezy korzy-
stac z shielda. Aplikacja Korzystała z biblioteki SoftwareSerial do emulacji łacza szere-
gowego na portach cyfrowych 6 i 7. Niestety, biblioteka ta nie wspiera domyslnej szybkosci
transmisji wykorzystywanej przez shield równej 38400 bodów. Rozwiazaniem okazało sie wy-
korzystanie sprzetowego portu szeregowego do połaczenia z modemem Bluetooth.
5.2 Java
Aplikacja PC napisana została w jezyku Java. Jest to jeden z najpopularniejszych jezyków,
ceniony ze wzgledu na duza przenosnosc kodu miedzy platformami i bogaty zestaw bibliotek.
Cechy te zdecydowały o duzym sukcesie Javy na rynku rozwiazan biznesowych i konsumenc-
kich.
Mimo wielu lat ciagłego rozwoju i wsparcia Oracle, jednej z najwiekszych firm informa-
tycznych na swiecie, jezyk ten nie jest wolny od problemów. Szczególnie dwa z nich okazały
sie odczuwalne przy pracy nad projektem zabawki.
Po pierwsze, Java oficjalnie nie wspiera komunikacji po portach szeregowych. Je-
dyna próba umieszczenia stosownego interfejsu przez firme SUN była biblioteka JavaComm,
jednak dostepna jest ona jedynie na systemie operacyjnym Linux.
Najczesciej stosowana alternatywa dla multiplatformowych aplikacji jest otwarta biblio-
teka RxTx. Ze wzgledu na dynamiczny rozwój tej biblioteki problemem jest jednak stabilnosc
działania i czesto zmieniajace sie interfejsy.
Alternatywna mozliwoscia jest otwarta biblioteka jSSC (Java Simple Serial
Connector), oferujaca jedynie najprostsza funkcjonalnosc, ale stabilniejsza od RxTx.
Zarówno RxTx, jak tez jSSC obsługuja porty szeregowe przy pomocy modułów napisa-
nych w jezyku C++, korzystajac z nich przez interfejs JNI.
Ostatecznie wybrana została biblioteka jSSC. Zdecydowały o tym prostota interfejsu,
niewielki rozmiar oraz licencja LGPL, umozliwiajaca wykorzystanie jej w projektach komer-
cyjnych.
Drugim problemem napotkanym podczas pracy z jezykiem Java były błedy w obsłudze
plików HTML. Standard ten został wykorzystany do formatowania plików zawierajacych opisy
59
elementów elektronicznych i zagadki. Z powodu błedów w implementacji parsera HTML czesc
plików wyswietlanych było w sposób niepoprawny, przez co wiele czasu zostało stracone na
poszukiwanie przyczyn problemu w plikach, które zawierały poprawne dane. Prace mozna było
wznowic dopiero po ukazaniu sie odpowiedniej aktualizacji.
60
6 Mozliwosci rozwoju
W obecnym kształcie zabawka posiada szereg ograniczen wynikajacych z przyjetych za-
łozen lub ograniczonych srodków przeznaczonych na projekt. W zaleznosci od powodzenia
produktu na rynku i reakcji odbiorców mozna rozwazyc wprowadzenie zmian architektonicz-
nych lub dodatkowych funkcjonalnosci, umozliwiajacych zdobycie szerszego rynku.
6.1 Dalsze prace
Przygotowany na potrzeby projektu prototyp nie spełnia wszystkich wymagan bizneso-
wych, w szczególnosci zwiazanych z estetyka, ergonomia i bezpieczenstwem. Zanim zabawka
bedzie mogła byc przedstawiona potencjalnym odbiorcom, konieczne jest wprowadzenie naste-
pujacych zmian:
1. Udoskonalenie interfejsu aplikacji PC, w szczególnosci generowania scenariuszy i sche-
matów, a takze obsługi błedów i sytuacji wyjatkowych.
2. Umieszczenie zabawki w obudowie, chroniacej wrazliwe elementy przed uszkodzeniem.
3. Przygotowanie odpowiedniego systemu gniazd i wtyczek, umozliwiajacych bezpieczne
i wygodne podłaczanie elementów.
W pełni funkcjonalny interfejs aplikacji PC powinien oferowac wszystkie mozliwosci
znane ze współczesnych gier komputerowych. Dotyczy to zarówno warstwy estetycznej, jak
tez funkcjonalnej.
Przykładowe elementy estetyczne, które znacznie poprawiłyby odbiór zabawki to:
1. Obsługa pracy w oknie, trybu pełnoekranowego i wielu monitorów.
2. Wprowadzenie motywu muzycznego.
3. Animowane przejscia pomiedzy kolejnymi ekranami.
4. Tła okien zwiazane z motywem przewodnim.
Dodatkowe funkcjonalnosci interfejsu to:
1. Graficzny edytor scenariuszy, schematów i zagadek.
61
2. Mozliwosc sciagania aktualizacji i nowych scenariuszy (byc moze z obsługa mikropłat-
nosci).
3. Informacje o błedach umozliwiajace lepsze zdiagnozowanie zródła ewentualnego pro-
blemu.
Opracowanie odpowiedniej obudowy jest zadaniem wymagajacym specjalistycznej wie-
dzy z zakresu modelowania obiektów trójwymiarowych. Wykorzystanie narzedzi kompute-
rowych do zaprojektowania i symulacji współdziałania poszczególnych elementów pozwoli
znacznie ograniczyc koszty produkcji i wdrozenia. Na potrzeby egzemplarzy testowych
wstepne wersje obudowy i gniazd pochodzic moga z drukarki 3D.
6.2 Moduły uzyteczne w innych projektach
Czesc rozwiazan zaimplementowanych przy pracach nad prototypem zabawki wykorzy-
stac mozna w innych projektach. Najwygodniejszym sposobem na osiagniecie tego celu byłoby
stworzenie odpowiednich bibliotek i udostepnienie ich publicznie na licencji Wolnego Opro-
gramowania. Dzieki temu inni twórcy korzystajacy z opublikowanych rozwiazan pomagaliby
testowac i rozwijac moduły wykorzystywane w zabawce.
Szczególnie uzyteczne z punktu widzenia innych projektów moga byc:
1. Moduł zdalnego sterowania kontrolerem.
2. Biblioteka do rysowania schematów układów elektronicznych.
Wiekszosc dostepnych w Internecie projektów wykorzystujacych Arduino zakłada, ze
konfiguracja wykorzystanych portów bedzie znana juz na etapie programowania mikrokontro-
lera. Brakuje natomiast gotowych rozwiazan pozwalajacych na dostosowanie listy uzywanych
portów do warunków zewnetrznych.
Moduł komunikacji napisany na potrzeby zabawki pozwala zdalnie sterowac zarówno
portami wyjsciowymi i wejsciowymi w zaleznosci od potrzeb. Aplikacja posiada tez własny
jezyk skryptowy opisujacy spodziewane zachowanie kontrolera i liste portów uzywanych na
kazdym etapie. Kontroler po swojej stronie potrafi poprawnie zinterpretowac otrzymane dane
i zmienic liste odczytywanych portów wejsciowych oraz wartosc na portach wyjsciowych. Jesli
zachodzi taka potrzeba moze tez zmienic kierunek komunikacji na danym porcie.
Drugim uzytecznym modułem aplikacji PC jest czesc interfejsu graficznego odpowie-
dzialna za rysowanie układów elektronicznych. Pozwala ona w prosty sposób wizualizowac
62
nawet skomplikowane układy składajace sie z wielu elementów, równiez w formie interaktyw-
nej (na przykład z udostepniona pomoca kontekstowa).
Dodanie własnego elementu wymaga od uzytkownika przede wszystkim stworzenia funk-
cji rysujacej dany element przy pomocy interfejsu Graphics jezyka Java. Moze przy tym
korzystac z gotowych funkcji do rysowania czesto powtarzajacych sie elementów, na przykład
strzałek. Dzieki operowaniu na niskim poziomie abstrakcji moduł nie wymaga zbyt duzych
zasobów.
Aplikacja PC implementuje własny schemat przechowywania schematów w formie pli-
ków CSV. Interfejs modułu jest jednak oddzielony od danych wejsciowych odpowiednia war-
stwa abstrakcji, zatem nic nie stoi jednak na przeszkodzie, by w razie potrzeby uzytkownik
mógł skorzystac w tym celu z własnych rozwiazan, takich jak pliki XML.
6.3 Migracja na platformy mobilne
Aplikacja komunikujaca sie z uzytkownikiem i kontrolerem bomby została zaprojekto-
wana pod katem komputerów klasy PC. Wieloplatformowy charakter jezyka Java pozwala uru-
chamiac ja na systemach operacyjnych Linux i Windows1. Coraz czesciej jednak młodzi ludzie
zamiast komputerów osobistych wykorzystuja smartfony i tablety - w samym 2013 roku na
całym swiecie sprzedano prawie miliard smartfonów[18] i niemal 200 milionów tabletów[19].
Uzytkownicy urzadzen mobilnych stanowia wiec potencjalnie znaczace grono odbiorców. Prze-
niesienie aplikacji na smartfony i tablety wiaze sie z okreslonymi trudnosciami, ale tez otwiera
dodatkowe mozliwosci.
Podstawowy problem z wdrozeniem aplikacji urzadzenia mobilne wiaze sie z ograniczona
mozliwoscia wykorzystania istniejacego kodu. Systemy operacyjne iOS i Windows Phone
w ogóle nie wspieraja jezyka Java, natomiast na systemie Android wiele komponentów i bi-
bliotek (zwłaszcza zwiazanych z interfejsem uzytkownika) zostało zamienionych na lokalne
odpowiedniki. W praktyce wymaga to napisania aplikacji PC całkowicie od nowa.
Drugim problemem sa ograniczenia zwiazane z interakcja z uzytkownikiem. W przy-
padku komputerów osobistych dostepny jest duzy monitor, umozliwiajacy pokazanie wielu
elementów graficznych jednoczesnie. Jest to szczególnie istotne przy wyswietlaniu schematu
bomby, który zawiera wiele drobnych szczegółów i wymaga dodatkowego panelu do wyswietla-
nia pomocy. Na niewielkim ekranie telefonu mozna rozwiazac ten problem jedynie poprzez wy-
korzystanie mechanizmu powiekszania i pomniejszania obrazu, oraz przełaczania sie miedzy
1Nie przeprowadzono testów na systemie Mac OS X.
63
ekranem układu i ekranem pomocy. Jest to jednak rozwiazanie niedoskonałe, jako ze uzytkow-
nik w zadnym momencie nie miałby mozliwosci zobaczenia układu jako całosci. Stanowiłoby
to powazne utrudnienie przy składaniu bomby i mogłoby zniechecic uzytkownika do dalszej
zabawy.
Powazna wada z punktu widzenia uzytkownika moze byc równiez duze zuzycie baterii.
Komunikacja z bomba wymaga regularnych transmisji przez modem bezprzewodowy, a ekran
musi byc stale podswietlony, by uzytkownik miał nieprzerwany dostep do potrzebnych infor-
macji. Poniewaz idea gry nie przewiduje mozliwosci zatrzymywania lub zapisu jej stanu, wy-
czerpanie sie baterii spowoduje bezpowrotna strate informacji o dokonanym postepie. Moze to
zirytowac uzytkownika i zniechecic go do kolejnych prób.
Ze wzgledu na ograniczenia interfejsu urzadzen mobilnych (zwłaszcza smartfonów) czas
przeznaczony na rozbrojenie bomby musiałby zostac znacznie wydłuzony, ze wzgledu na utrud-
nione korzystanie ze zródeł. Przełaczanie sie miedzy oknami i wyszukiwanie konkretnych in-
formacji jest o wiele szybsze przy uzyciu klawiatury i myszki niz ekranu dotykowego. Ponadto
niektóre starsze wersje mobilnych systemów operacyjnych nie pozwalaja jednoczesnie korzy-
stac z aplikacji i przegladarki internetowej.
Wiele urzadzen mobilnych, głównie smartfonów i tanszych modeli tabletów nie posiada
interfejsu USB pozwalajacego podłaczyc zewnetrzne modemy komunikacji bezprzewodowej.
Urzadzenia takie sa zwykle wyposazone w moduły Bluetooth i Wi-Fi, zatem mozliwe jest na-
wiazanie połaczenia z nimi, jednak w razie potrzeby wykorzystania innego protokołu (np. Zig-
Bee), nie bedzie mozliwosci rozszerzenia ich funkcjonalnosci.
Z drugiej strony, wykorzystanie urzadzen mobilnych daje mozliwosci niedostepne w apli-
kacji przeznaczonej na komputery osobiste.
Pierwsza z nich jest mozliwosc wykorzystania wielu urzadzen wbudowanych w smartfony
i tablety, takich jak aparat cyfrowy, analogowe złacze słuchawkowe, mikrofon, głosnik, czytnik
NFC i inne, które moga pojawic sie w przyszłosci. Otwiera to wiele dodatkowych mozliwosci
komunikacji z bomba, a co za tym idzie, pozwala na projektowanie bardziej złozonych zabawek.
Urzadzenie mobilne moze wrecz stac sie czescia bomby, jesli zajdzie taka potrzeba.
Wykorzystanie aparatu cyfrowego i algorytmów rozpoznawania obrazu moze tez pomóc
na etapie składania bomby przy weryfikacji poprawnosci układu i wskazania uzytkownikowi
ewentualnych błedów. Mozna równiez wykorzystac je do identyfikacji poszczególnych ele-
mentów i uzyskania szczegółowych informacji na ich temat (np. podania oporu rezystora na
podstawie nadrukowanych oznaczen paskowych).
64
Wykorzystanie platform mobilnych umozliwiłoby równiez projektowanie zestawów prze-
znaczonych do gier terenowych. Rozbrojenie bomby wymagałoby nie tylko rozwiazania zaga-
dek, ale tez odwiedzenia konkretnych miejsc lub osób (co uzasadnione byłoby w zagadce ko-
niecznoscia zdobycia narzedzi lub informacji). Pozwoliłoby to na wspólna zabawe całej grupy,
nawiazanie nowych znajomosci i poznanie najblizszej okolicy. Do weryfikacji spełnienia posta-
wionych warunków mozna wykorzystac na przykład usługi lokalizacyjne.
Przenosne zestawy moga byc tez uzyteczne na prezentacjach, festiwalach nauki i spotka-
niach towarzyskich. Byłaby to ciekawa i atrakcyjna forma zaprezentowania swojego hobby.
Podsumowujac, ekspansja na rynek urzadzen mobilnych moze okazac sie duzym sukce-
sem. Wymaga wprawdzie rozwiazania wielu technicznych problemów, jednak rozmiar rynku
i nowe mozliwosci oferowane przez te platformy sprawiaja, ze moze okazac sie to opłacalne.
6.4 Tryb wieloosobowy
Obecna wersja zabawki pozwala jedynie na samodzielna zabawe (nie liczac ewentualno-
sci rozbrajania jednej bomby w kilka osób). Istnieje jednak wiele mozliwosci uatrakcyjnienia
produktu poprzez wprowadzenie współpracy miedzy uzytkownikami połaczonymi przez Inter-
net. Biorac pod uwage popularnosc róznych typów gier online (takich jak League of Legends,
Counter-Strike, World of Warcraft[20]) mozna wnioskowac, ze wprowadzenie takiej funkcjo-
nalnosci pozwoli przyciagnac uwage wielu nowych uzytkowników. Ponadto poczatkujacy uzyt-
kownicy mogliby wiele nauczyc sie poprzez współprace z bardziej doswiadczonymi kolegami.
Istnieje wiele mozliwych wariantów interakcji miedzy uzytkownikami. Najprostszy sce-
nariusz zabawy w kilka osób polega na jednoczesnym rozbrajaniu kilku bomb. Moga to byc
takie same bomby, co wymagałoby, by wszyscy uzytkownicy wykonywali poszczególne kroki
synchronicznie (przykładowo, od momentu gdy pierwszy wykona poprawne działanie, pozo-
stali musza powtórzyc jego działania w ciagu pieciu sekund), lub moze byc wyscig rozgrywany
w czasie rzeczywistym.
Nieco bardziej zaawansowana forma zabawy moze wymagac, by bomby nalezace do kaz-
dego uzytkownika były elementami składowymi poszczególnej konstrukcji. Gracze musieliby
współpracowac w celu ustalenia, jakie kroki powinien podjac kazdy z nich, by przejsc do ko-
lejnego etapu. Wiazałoby sie to z koniecznoscia projektowania skomplikowanych, wielopozio-
mowych zagadek.
65
Wszystkie te scenariusze wymagałyby, by aplikacje poszczególnych uzytkowników prze-
syłały sobie nawzajem informacje o stanie bomb. W przypadku wyscigu lub innych form współ-
zawodnictwa połaczenia powinny byc szyfrowane, by zminimalizowac ryzyko zapewnienia so-
bie nieuczciwej przewagi przez uzytkowników znajacych sie na protokołach sieciowych. Sce-
nariusze oparte na współpracy powinny przesyłac dane tekstem jawnym, aby zachecic uzyt-
kowników do podjecia wspólnego wysiłku oszukania mechanizmu zabawki. Dla wielu osób
mogłoby to byc niezwykle cenne i pouczajace doswiadczenie.
W niektórych przypadkach mozliwa jest wspólna zabawa nawet wtedy, gdy jeden z uzyt-
kowników nie dysponuje zestawem z bomba. W takiej sytuacji pełnic on moze role zadajacego
zagadki. Aplikacja poda mu informacje o tym, co musza zrobic pozostali uczestnicy zabawy by
przejsc dalej, a jego zadaniem bedzie naprowadzic ich bez uzywania okreslonych słów kluczo-
wych (przykładowo, opisujac koniecznosc odłaczenia czerwonego przewodu od portu szóstego
nie bedzie mu wolno uzywac nazw kolorów, synonimów słowa kabel, ani liczb). Poczatkowo
taka forma zabawy pozwoli na komunikacje jedynie przez protokoły tekstowe, jednak wyko-
rzystanie algorytmów rozpoznawania mowy mogłoby umozliwic tez komunikacje głosowa.
Ostatnia potencjalna forma zabawy wieloosobowej sa wspomniane wczesniej gry tere-
nowe z wykorzystaniem platform mobilnych. Ze wzgledu na opisane trudnosci zwiazane z prze-
niesieniem aplikacji na takie urzadzenia, poczatkowo wystarczyc musi jedynie prosta aplikacja
przekazujaca dane do komputera osobistego. Rozwiazanie zagadki moze wówczas polegac na
udaniu sie w konkretne miejsce lub spotkanie z innym graczem.
Reasumujac, rozwiniecie zabawki o rózne formy współpracy lub współzawodnictwa
moze znaczaco zwiekszyc jej potencjał edukacyjny i marketingowy. Wymaga jednak zapro-
jektowania odpowiedniego protokołu sieciowego, a takze o wiele bardziej złozonych zagadek.
66
7 Podsumowanie i wnioski
7.1 Wnioski
Zaprezentowany projekt zabawki składał sie z wielu etapów łaczacych rózne dziedziny
techniki, takie jak programowanie, tworzenie układów elektronicznych i systemy sieciowe.
Analizujac przebieg prac, napotkane problemy i rozwiazania, które okazały sie skuteczne
mozna uzyskac wiele informacji, które mozna wykorzystac w ramach kolejnych projektach.
7.1.1 Platforma
Wykorzystanie Arduino jako kontrolera bomby okazało sie dobrym wyborem. Zasoby
sa wystarczajace do osiagniecia wyznaczonego celu, a dostepne porty pozwalaja na podłaczenie
wielu róznych sensorów. Urzadzenie zostało zaprojektowane tak aby podłaczanie do niego ele-
mentów układu było łatwe, szybkie i wygodne, co dobrze wpisuje sie w idee działania zabawki.
Wazna kwestia, o której nalezy pamietac w przyszłych projektach jest uwzglednienie tego
sposobu zasilania produktu koncowego. Z powodu braku doswiadczenia projektanta kwestia ta
nie została wzieta pod uwage przy analizie wymagan wobec kontrolera, co mogło spowodowac
istotne problemy w dalszej czesci projektu. W przypadku Arduino rozwiazanie jest jednak
bardzo proste, poniewaz istnieje mozliwosc podłaczenia baterii 9V poprzez gniazdo zasilacza
lub do pinów Vin i GND. Pozwoli to uniknac ewentualnych trudnosci w finalnej fazie projektu.
Duza elastycznosc platformy pozwoliła wypróbowac wiele rozwiazan problemu z mo-
demem Bluetooth. Ostatecznie wykorzystanie dedykowanego shielda umozliwiło znaczna po-
prawe ergonomii prototypu.
Dostepne w Internecie materiały szkoleniowe okazały sie czytelne i uzyteczne.
Wyjatkiem były przykłady wykorzystania shielda Bluetooth udostepnione przez firme
Seeedstudio, które zawierały błedy. Duzym wsparciem w tym wypadku okazała sie spo-
łecznosc skupiona wokół Arduino, dzieki której udało sie wykryc zródło problemu.
Podsumowujac, Arduino jest platforma, która warto brac pod uwage przy projektach
dotyczacych elektroniki i robotyki. Oferuje ona duze mozliwosci i szeroki wachlarz modeli,
podstawy tworzenia oprogramowania sa łatwe do opanowania, a samo urzadzenie jest nieza-
wodne i efektywne w uzyciu.
67
7.1.2 Protokół komunikacyjny
Wybór protokołu Bluetooth do komunikacji bezprzewodowej nastreczył wielu proble-
mów natury sprzetowej. Mozna było ich uniknac analizujac przed zakupem nie tylko informa-
cje dostarczone przez producenta, ale tez opinie nabywców. Nalezało równiez przed ostateczna
decyzja zapoznac sie z problemami, na które natkneli sie inni uzytkownicy.
Kiedy udało sie nawiazac połaczenie miedzy kontrolerem a aplikacja, komunikacja od-
bywała sie bez zarzutu. Działanie zabawki zostało przetestowane w obecnosci zródeł zakłócen
typowych dla gospodarstwa domowego, takich jak telefony komórkowe, urzadzenia komuniku-
jace sie przez Wi-Fi i kuchenka mikrofalowa. Nawet przy tak zakłóconym medium, rezultaty
były zadowalajace.
Wykorzystanie systemu operacyjnego do parowania urzadzen znacznie ułatwiło prace
nad zabawka, ale wprowadziło do projektu czynnik niepewnosci, poniewaz na róznych sys-
temach proces ten przebiegał inaczej, co utrudniało przygotowanie instrukcji dla uzytkownika.
Problemów tych mozna było prawdopodobnie uniknac decydujac sie na protokół Zig-
Bee. W przyszłych projektach warto przetestowac to rozwiazanie, zwłaszcza, jesli nie beda one
tworzone pod katem szerokiego grona odbiorców. Tym niemniej, jesli uda sie zdobyc modem
odpowiedniej jakosci, Bluetooth pozostaje dobrym rozwiazaniem.
7.1.3 Wybór jezyka
Wybór Javy jako jezyka do implementacji aplikacji PC okazał sie trafny tylko pod niektó-
rymi wzgledami. Co prawda zalety tego rozwiazania dały o sobie znac szczególnie w kwestiach
zwiazanych z projektowaniem interfejsu uzytkownika i parsowaniem plików tekstowych jednak
komunikacja z bomba okazała sie duzym problemem.
Ponadto poprawne działanie zabawki zostało w znaczacym stopniu uzaleznione od opro-
gramowania firmy Oracle, zainstalowanego na komputerze uzytkownika. Biorac pod uwage
napotkane problemy z wyswietlaniem plików html, mozna obawiac sie innych problemów
ze stabilnoscia działania aplikacji.
Niewykluczone, ze własciwszym rozwiazaniem byłoby zastosowanie jezyka C++. Po-
zwoliłoby to uniknac opisanych problemów, jednak zarazem utrudniłoby to przenoszenie kodu
miedzy systemami operacyjnymi i uczyniło projektowanie interfejsu graficznego bardziej kło-
potliwym. Otwarty charakter jezyka i jego niezaleznosc od interesów pojedynczej firmy daja
tez wieksza stabilnosc w dłuzszej perspektywie.
68
Z tych powodów nalezy stwierdzic, ze mimo niewatpliwych zalet Javy, to jezyk C++
rekomendowany jest do kolejnych projektów.
7.1.4 Implementacja
Koncepcja umieszczenia zasobów w zewnetrznym katalogu o ustalonej strukturze i od-
separowanego od kodu aplikacji okazała sie słuszna. Dodawanie nowych scenariuszy, schema-
tów i zagadek wymagało niewielkiego wysiłku. Najprostsza metoda utworzenia nowego zasoby
było skopiowanie katalogu z przykładem i wypełnienie go trescia.
Wykorzystanie jezyka html umozliwiło tworzenie estetycznie sformatowanych informa-
cji dla uzytkownika w róznych jezykach. Z drugiej strony uniemozliwiło to parametryzowanie
zagadek, przez co niektóre wartosci (na przykład numery portów) musiały byc z góry usta-
lone. Uzalezniło to projektowane schematy od wybranych zagadek. Doswiadczenie wykazało,
ze znaczacym ułatwieniem przy tworzeniu nowych scenariuszy byłoby jednak uzaleznienie za-
gadek od zaprojektowanego układu. Rozwiazaniem mogłoby byc generowanie plików html
w trakcie działania aplikacji. Wiazałoby sie to jednak z ograniczeniem mozliwosci projekto-
wania ekranów do z góry ustalonych schematów i utrudniłoby tłumaczenie tekstów na rózne
wersje jezykowe.
Wybrany format plików opisujacych scenariusze i listy kolejnych kroków zabawy dobrze
sprawdził sie w praktyce. Pliki okazały sie byc czytelne i łatwe do edycji.
Jedynymi zasobami bezposrednio uzaleznionymi od aplikacji były konfiguracja, słownik
i opisy elementów. W dwóch pierwszych przypadkach było to uzasadnione ich przeznaczeniem
do wewnetrznego uzytku aplikacji (nie wymagaja zmian przez podmioty zewnetrzne, z wyjat-
kiem ewentualnego tłumaczenia słownika na inny jezyk).
W przypadku elementów elektronicznych decyzja ta była uzasadniona potrzeba kontroli
nad tym, jakie komponenty moga byc czescia zabawki. Ponadto do rysowania schematów wy-
korzystano grafike wektorowa, a obrazy generowane sa na biezaco, na podstawie danych z pliku
z opisem schematu. Celem takiego rozwiazania miała byc mozliwosc prostego generowania
podpisów (w szczególnosci zawierajacych wartosci poszczególnych parametrów, na przykład
rezystancji) i rysowania elementów w róznych kolorach (co jest szczególnie wazne dla diod
elektroluminescencyjnych i kabli).
Rozwiazanie to okazało sie skuteczne, jednak rozwijanie zabawki o nowe elementy kosz-
towało wiele pracy. Wykorzystanie wielu bitmap zawierajacych symbole danego elementu
we wszystkich wymaganych konfiguracjach i całkowite odseparowanie listy elementów od
69
kodu aplikacji pozwoliłoby znaczaco poprawic elastycznosc zabawki i przyspieszyłoby doda-
wanie nowych pozycji na liscie. Zmiana taka byłaby jednak bardzo trudna, poniewaz wiele
załozen odnosnie architektury aplikacji zostało opartych na załozeniu, ze wszystkie elementy
sa z góry znane.
7.1.5 Rezultat projektu
Jako całosc projekt przebiegł zadowalajaco. Szczegółowa analiza wymagan przed rozpo-
czeciem implementacji pozwoliła uniknac wielu problemów.
Głównym zródłem opóznien były podmioty zewnetrzne. Wiele czasu zostało poswiecone
na analize kodu aplikacji lub kontrolera w celu znalezienia błedu, podczas gdy rzeczywiste
zródło problemów znajdowało sie w zewnetrznej bibliotece lub w zepsutym urzadzeniu.
Zaprojektowanie architektury aplikacji pod katem duzej elastycznosci pozwoliło w efek-
tywny sposób dodawac i edytowac zasoby. Wymagało to dodatkowego nakładu pracy na po-
czatku projektu, jednak inwestycja ta zwróciła sie z nawiazka.
7.2 Podsumowanie
Cele projektu zostały osiagniete. Skonstruowany został działajacy prototyp zabawki, speł-
niajacy wyznaczone załozenia. Elastyczny charakter urzadzenia pozwala w duzym stopniu ma-
nipulowac trescia i poziomem zagadek, tak by osiagnac załozone cele edukacyjne.
Wnioski wyciagniete na podstawie przebiegu prac stanowia pozyteczne zródło wiedzy,
z którego warto skorzystac przy planowaniu podobnych projektów. Zabawka z załozenia miała
edukowac uzytkownika koncowego, jednak w trakcie prac nad nia równiez jej twórca wiele sie
nauczył.
Integracja systemu składajacego sie z komponentów programowych i sprzetowych jest
trudnym zadaniem, wymagajacym specjalistycznej wiedzy z obydwu dziedzin. Projekt za-
bawki, składajacej sie z aplikacji komputerowej, programowalnego mikrokontrolera i prostego
układu elektronicznego pozwolił na zyskanie cennego doswiadczenia w tej materii.
Zaprojektowana zabawka pozwala dziecku na zrozumienie podstaw tworzenia i analizy
układów elektronicznych. Na nizszych poziomach trudnosci mozliwe jest przedstawienie uzyt-
kownikowi działania pojedynczych elementów, aby nie przytłoczyc go nadmiarem informa-
cji. Scenariusze dla zaawansowanych pozwalaja z kolei zilustrowac interakcje miedzy róznymi
fragmentami układu. Rozwiazywanie zagadek stanowi wyzwanie uatrakcyjniajace zabawe i po-
zwalajace uniknac monotonii.
70
Projekt jako całosc stanowił ciekawe i rozwijajace doswiadczenie. Napotkane problemy
dostarczyły uzytecznych wniosków. Natura projektu pozwoliła zmierzyc sie z wyzwaniami uni-
kalnymi dla systemów integrujacych komponenty operujace na róznych poziomach abstrakcji.
Stworzony produkt jest interesujacy i ma szanse wyróznic sie na rynku o ile zostanie wdro-
zony i wyprodukowany. Wszystkie te elementy pozwalaja stwierdzic, ze projekt zakonczył sie
sukcesem.
71
Bibliografia
[1] Krzysztof Nowak, Leksykon złotych mysli
KIW, Ksiazka i Wiedza, Spółdzielnia Wydawniczo-Handlowa 1995
[2] http://vivat.agh.edu.pl/
index.php?option=com_content&view=article&id=248:4&catid=42:
numer-6&Itemid=68
12 kwietnia 2014
[3] Kathy Hirsh-Pasek, Roberta Michnick Golinkoff, Why Play = Learning
University of Delaware 2008
[4] http://www.telegraph.co.uk/education/educationnews/8142721/
Social-networking-teachers-blame-Facebook-and-Twitter-for-pupils-poor-grades.
html
12 kwietnia 2014
[5] http://nperov.com/health/social-networking-bad-mental-health/
12 kwietnia 2014
[6] http://arduino.cc/en/Main/ArduinoBoardUno
11 pazdziernika 2013
[7] Tadeusz Łuba, Synteza Układów Logicznych
Oficyna Wydawnicza PW 2005
[8] http://www.altera.com/devices/fpga/fpga-index.html
13 pazdziernika 2013
[9] http://www.raspberrypi.org/
18 pazdziernika 2013
[10] http://www.element14.com/community/docs/
DOC-43659/l/raspberry-pi-to-narrow-the-digital-divide
18 pazdziernika 2013
72
[11] http://standards.ieee.org/about/get/802/802.11.html
25 pazdziernika 2013
[12] https://www.abiresearch.com/press/wi-fi-enabled-device-shipments-will-exceed-15-bill
25 pazdziernika 2013
[13] http://www.ieee802.org/15/pub/TG1.html
27 pazdziernika 2013
[14] https://www.bluetooth.org/
27 pazdziernika 2013
[15] http://www.zigbee.org/Specifications.aspx
03 listopada 2013
[16] https://wiki.python.org/moin/GuiProgramming
04 marca 2014
[17] http://hackerboss.com/how-to-distribute-commercial-python-applications/
04 marca 2014
[18] http://techcrunch.com/2014/02/13/smartphones-outsell-dumb-phones-globally/
04 maja 2014
[19] http://techcrunch.com/2014/03/03/
gartner-195m-tablets-sold-in-2013-android-grabs-top-spot-from-ipad-with-62-share/
04 maja 2014
[20] http://www.cinemablend.com/games/Top-10-Online-Games-Revenue-2013-61753.
html
05 maja 2014
[21] http://www.hollywoodlostandfound.net/wilhelm/index.html
10 maja 2014
73
A Typy i formaty rekordów
Typ
(HEX)
Przeznaczenie Format Uwagi
0x00 Port nieuzywany brak Oznaczenie portu nieuzywa-
nego w kontrolerze, nie jest
uzywane w komunikacji
0x01 Czas <typ> <starsze 8 bitów>
<młodsze 8 bitów>
Czas pozostały do konca za-
bawy, nieskojarzony z kon-
kretnym portem fizycznym,
wyrazony w sekundach
0x02 Cyfrowe wejscie <typ> <numer portu>
<oczekiwana wartosc>
Port o danym numerze trak-
towany jako cyfrowe wej-
scie, port uwzgledniany przy
tworzeniu raportu, podana
przez aplikacje PC wartosc
wykorzystana jedynie do ce-
lów diagnostycznych
0x03 Cyfrowe wyjscie <typ> <numer portu> <war-
tosc>
Port o danym numerze trak-
towany jako cyfrowe wyj-
scie, wartosc zerowa ozna-
cza stan niski
0x04 Analogowe wyj-
scie
<typ> <numer portu> <war-
tosc>
Port o danym numerze trak-
towany jako analogowe wyj-
scie, wybrany port musi ob-
sługiwac PWM (nie jest
to sprawdzane przez logike
kontrolera)
74
0x05 Analogowe wej-
scie
<typ> <numer portu> <war-
tosc>
Port o danym numerze trak-
towany jako cyfrowe wej-
scie, port uwzgledniany przy
tworzeniu raportu, podana
przez aplikacje PC wartosc
wykorzystana jedynie do ce-
lów diagnostycznych, dane
odczytane przez kontroler
kompresowane sa z 10 do
8 bitów
75
B Obsługiwane elementy
Oznaczenia:
1. [ID] - Identyfikator elementu
2. [X] - Współrzedna pozioma
3. [Y] - Współrzedna pionowa
4. [Value] - Wartosc
5. [Name] - Nazwa lub oznaczenie
6. [Color] - Kolor, dostepne wartosci podane przy konkretnym elemencie
7. [UP | DOWN | LEFT | RIGHT] - Orientacja elementu jednopunktowego lub kierunek
przewodzenia diody
8. [HORIZONTAL | VERTICAL] - Orientacja elementu dwupunktowego
9. [T_UP | T_DOWN | T_LEFT | T_RIGHT] - Orientacja elementu trójpunktowego
10. [CROSS] - Rozgałezienie przewodów we wszystkie cztery strony
11. [OVERPASS] - Skrzyzowanie odizolowanych od siebie przewodów
12. [DOWN_LEFT | DOWN_RIGHT | UP_LEFT | UP_RIGHT] - Orientacja elementu dwu-
punktowego majacego połaczenie pod katem 90◦
13. [L1 | L2] - Pozycja poczatkowa przełacznika
Identyfikator Element Format rekordu
EMPTY Brak elementu
ERROR Bład w pliku
ze schematem
PORT Port kontrolera [ID][X][Y][Name][UP | DOWN | LEFT | RIGHT]
76
CONDUCTOR Przewodnik, moze
byc to przewód,
zworka lub płytka
stykowa
[ID][X][Y][HORIZONTAL | VERTICAL | T_UP |
T_DOWN | T_LEFT | T_RIGHT | CROSS | OVER-
PASS | DOWN_LEFT | DOWN_RIGHT | UP_LEFT |
UP_RIGHT]
COLOR_WIRE Przewód o okre-
slonym kolorze
[ID][X][Y][COLOR1][HORIZONTAL | VERTICAL]
RESISTOR Opornik [ID][X][Y][Name][Value][HORIZONTAL | VERTI-
CAL]
THERMISTOR Termistor [ID][X][Y][Name][HORIZONTAL | VERTICAL]
PHOTORESISTOR Fotorezystor [ID][X][Y][Name][HORIZONTAL | VERTICAL]
POTENTIOMETER Potencjometr [ID][X][Y][Name][Value2][Value3][Value4][T_UP |
T_DOWN | T_LEFT | T_RIGHT]
BUTTON Przycisk [ID][X][Y][Name][HORIZONTAL | VERTICAL]
TOGGLE Przełacznik [ID][X][Y][Name][L1 | L2][HORIZONTAL | VERTI-
CAL]
TOGGLE_SPDT Przełacznik trój-
punktowy
[ID][X][Y][Name][L1 | L2][T_UP | T_DOWN | T_LEFT
| T_RIGHT]
LED Dioda elektrolumi-
nescencyjna
[ID][X][Y][COLOR5][UP | DOWN | LEFT | RIGHT]
1Dostepne wartosci: BLACK, WHITE, RED, GREEN, BLUE, ORANGE, YELLOW2Wartosc minimalna3Wartosc maksymalna4Wartosc poczatkowa5Dostepne wartosci: RED, GREEN, BLUE, YELLOW, ORANGE
77
C Przykłady opisu stanów portów
Opis stanu Znaczenie
DIGITAL_INPUT,6,1 Dla cyfrowego portu o numerze 6 dozwolonym
stanem jest 1 (stan wysoki)
~DIGITAL_INPUT,6,1 Dla cyfrowego portu o numerze 6 niedozwolo-
nym stanem jest 1 (stan wysoki)
ANALOG_INPUT,0,50-255 Dla analogowego portu o numerze 0 dozwolone
sa wartosci z zakresu od 50 do 255 (włacznie)
DIGITAL_INPUT,6,1-
>DIGITAL_OUTPUT,3,1
Jesli na cyfrowym porcie wejsciowym o nu-
merze 6 znajdzie sie wartosc 1 (stan wysoki),
w wiadomosci zwrotnej ma zostac wysłana in-
formacja, by stan cyfrowego portu o numerze 3
zmienic na 1 (stan 1 dla portu 6 automatycznie
dodawany jest do listy stanów dozwolonych)
!ANALOG_INPUT,0,50-255 Dla analogowego portu o numerze 0 wartosci
z zakresu od 50 do 255 (włacznie) sa jednym
z warunków przejscia do kolejnego kroku
78
D Przykładowy scenariusz
Zawartosc przykładowego pliku ze scenariuszem zabawy:
en-Napoleon,pl-Napoleon
NORMAL
Example.sch
pl-fabula.txt,en-plot.txt
Ports.txt
pl-ending.html,en-ending.html
Plik składa sie z nastepujacych elementów:
1. Tytuły w róznych jezykach poprzedzone dwuliterowym prefiksem.
2. Poziom trudnosci.
3. Nazwe pliku .sch ze schematem układu.
4. Nazwy plików zawierajacych tekst wprowadzenia poprzedzone prefiksami okreslajacymi
wersje jezykowa.
5. Nazwe pliku z lista kolejnych stanów.
6. Nazwy plików z ekranami koncowymi własciwymi dla danej wersji jezykowej.
79
E Przykładowy scenariusz
Zawartosc przykładowego pliku ze schematem układu:
PORT,0,0,4,RIGHT
PORT,0,1,5,RIGHT
PORT,0,2,6,RIGHT
PORT,0,4,5V,RIGHT
CONDUCTOR,1,0,HORIZONTAL
CONDUCTOR,1,1,HORIZONTAL
CONDUCTOR,1,2,T_DOWN
COLOR_WIRE,1,3,BLUE,VERTICAL
CONDUCTOR,1,4,CROSS
CONDUCTOR,1,5,UP_RIGHT
CONDUCTOR,2,0,HORIZONTAL
CONDUCTOR,2,1,T_DOWN
CONDUCTOR,2,2,OVERPASS
COLOR_WIRE,2,3,WHITE,VERTICAL
CONDUCTOR,2,4,T_UP
RESISTOR,2,5,R4,67000,HORIZONTAL,
PORT,2,7,7,RIGHT
PORT,2,8,8,RIGHT
CONDUCTOR,3,0,T_DOWN
CONDUCTOR,3,1,OVERPASS
CONDUCTOR,3,2,OVERPASS
COLOR_WIRE,3,3,RED,VERTICAL
CONDUCTOR,3,4,T_UP
CONDUCTOR,3,5,T_DOWN
PORT,3,6,A1,UP
LED,3,7,RED,RIGHT
LED,3,8,BLUE,RIGHT
RESISTOR,4,0,R1,2200,HORIZONTAL
RESISTOR,4,1,R2,2200,HORIZONTAL
80
RESISTOR,4,2,R3,2200,HORIZONTAL
PORT,4,3,A0,DOWN
POTENTIOMETER,4,4,P1,20,10000,5000,T_UP
PHOTORESISTOR,4,5,RP,HORIZONTAL
RESISTOR,4,7,R5,1000,HORIZONTAL
RESISTOR,4,8,R6,1000,HORIZONTAL
CONDUCTOR,5,0,DOWN_LEFT
CONDUCTOR,5,1,T_LEFT
CONDUCTOR,5,2,T_LEFT
CONDUCTOR,5,3,T_RIGHT
CONDUCTOR,5,4,T_LEFT
CONDUCTOR,5,5,T_LEFT
CONDUCTOR,5,6,VERTICAL
CONDUCTOR,5,7,T_LEFT
CONDUCTOR,5,8,UP_LEFT
PORT,6,3,GND,LEFT
81