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