D I P L O M A R B E I T
Akustische Kommunikation in einem
Schwarm von ad hoc Netzwerkknoten
basierend auf der Arduino Prot...
Ich erkläre hiermit, dass ich die vorliegende Arbeit selbständig verfasst und
keine anderen als die angegebenen Quellen un...
Inhaltsverzeichnis
1. Einleitung 1
1.1. Zielsetzung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Glie...
vi Inhaltsverzeichnis
4.3. Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.3.1. Einrichtung der...
1. Einleitung
Die heutige Zeit ist gekennzeichnet durch eine stark zunehmende Anzahl von
embedded Geräten in unserem Allta...
2 1. Einleitung
Cloud Robotics1 wäre hierfür ein in jüngster Zeit immer öfters angewandter
Versuch Roboterplattformen, wie...
3
Aus den vorherigen Passagen sollten sich folgende wichtigen Punkte heraus-
kristallisiert haben:
• Homogene und heteroge...
4 1. Einleitung
1.1. Zielsetzung der Arbeit
Das Ziel dieser Arbeit ist die Ausarbeitung eines akustischen Schwarmnetz-
wer...
1.2. Gliederung der Arbeit 5
fangsstationen, wie in der Unterwasserakustik weit verbreitet, als Funksender
mit höheren Rei...
6 1. Einleitung
Nachdem die Grundlagen im vorherigen Kapitel abgehandelt wurden, wid-
met sich Kapitel 4 der Erstellung ei...
2. Grundlagen
In diesem Kapitel werden wir den grundlegenden theoretischen Hintergrund
für den Aufbau eines akustischen Sc...
8 2. Grundlagen
2.1. Akustik
Da wir für unser Projekt eine alternative Übertragungsform, die Akustik,
wählen, werden wir i...
2.1. Akustik 9
ähnlich wie bei elektromagnetischen Radiowellen, können diese erstaunliche
Distanzen zurücklegen. Eine Reic...
10 2. Grundlagen
2.1.1. Wellentheorie
Die folgende Abbildung 2.2 zeigt eine typische Sinuswelle mit ihren Eigen-
schaften....
2.1. Akustik 11
hörbaren Frequenzen zwischen 17 m und 17 mm.’
• Periode (T): ’Die Form einer solchen idealen Schwingung is...
12 2. Grundlagen
entgegen und mit der Ausbreitungsrichtung im Medium. Dagegen abzugren-
zen wären Transversale Wellen, die...
2.1. Akustik 13
Schallleistungspegel (LW): ’Der Schallleistungspegel ist ein logarithmisches
Maß zur Beurteilung von Schal...
14 2. Grundlagen
Nach [Frie08] erfolgt die ’[...]Schallausbreitung [...] in der Realität immer ge-
richtet. Die Punktschal...
2.2. Unterwassernetzwerke 15
Wassermoleküle, die Absorptionsrate, wie in Abbildung 2.4 ersichtlich ist, im
Bereich bis 100...
16 2. Grundlagen
Abbildung 2.5.: Network topology of an UAN [SoSP00a]
2.2.1. Multiple Access Protocols
In vielen Netzwerke...
2.2. Unterwassernetzwerke 17
denen Kanälen nutzen kann von entscheidender Bedeutung. Da die Frequenz
während der Übertragu...
18 2. Grundlagen
2.2.2. Medium Access Control (MAC)
Die raren Ressourcen in einem limitierten Unterwasserkanal sollten in ...
2.2. Unterwassernetzwerke 19
Abbildung 2.6.: Knotentopologie für unser Beispiels UAN [SoSP00a]
zen, durch die gleichzeitig...
20 2. Grundlagen
ten kompensieren diesen Faktor und führen , wie eben schon erwähnt zu
einem höheren Datendurchsatz.
Abbil...
2.3. Verwandte Arbeiten und Herangehensweise 21
Abbildung 2.9.: Zeitüberschreitung eines RTS-Pakets und fehlerhafte RTS-
Ü...
22 2. Grundlagen
Hierbei stellte sich natürlich die Frage, warum so wenige Arbeiten für die
terrestrische akustische Daten...
2.3. Verwandte Arbeiten und Herangehensweise 23
ten, stand zu aller Erst die geeignete Auswahl einer Plattform zu Disposit...
24 2. Grundlagen
Somit ist festzuhalten, dass wir eine recht unorthodoxe Vorgehensweise ge-
wählt haben, indem wir uns für...
2.3. Verwandte Arbeiten und Herangehensweise 25
Das Slotted-FAMA-Protokoll (Floor Acquisition Multiple Access):
In Unterka...
26 2. Grundlagen
Nachteile des Slotted-FAMA-Protokolls sind:
1. Synchronisierung ist notwendig, was aufwendig ist.
2. Durc...
3. Hardware
In diesem Kapitel widmen wir uns der Hardware, mit der ein Aufbau ei-
nes akustisch kommunizierenden Schwarms ...
28 3. Hardware
Um einen schnellen und kostengünstigen Prototypenbau zu realisieren, wol-
len wir jedoch nicht den puren Mi...
3.1. Mikroprozessor-Architekturen 29
Abbildung 3.2.:
(voraussichtlich 2014) soll das ARM Design noch um eine stärkere 64-B...
30 3. Hardware
RAM, Flash-Speicher, Bussysteme, ADC und vieles mehr untergebracht. Dies
ermöglicht einen vielseitigen Eins...
3.2. Mikrocontroller 31
3.2.1. AVR
’Atmel AVR ist eine 8-Bit-Mikrocontroller-Familie des US-amerikanischen Her-
stellers A...
32 3. Hardware
3.3. Physical-Computing-Plattformen
Da wir einen in seiner Funktion leicht erweiterbaren Prototypen-Schwarm...
3.3. Physical-Computing-Plattformen 33
die zu speichernden statischen Variablen, dem Stack und Heap vorhanden.
Somit muss ...
34 3. Hardware
Abbildung 3.5.: Vergleich von Größe und Layout von: Raspberry Pi Model-
B(links oben), Arduino Uno Rev 3.0 ...
3.3. Physical-Computing-Plattformen 35
• es folgt dem standardisierten Arduino Layout6
• es ist geeignet auf ihrer Webseit...
36 3. Hardware
ino-Shield-Layout und vieles mehr haben möchte, empfiehlt sich für den ge-
nerellen Aufbau eines flexiblen Pr...
3.3. Physical-Computing-Plattformen 37
Aktionen auszulösen. Dies wird durch den Zugriff auf einen der drei verfüg-
baren i...
38 3. Hardware
Arduino-Varianten, fällt das Raspberry Pi mit seinen deutlich höheren Werten
auf. Das muss jedoch nicht zwa...
3.3. Physical-Computing-Plattformen 39
und hat zudem deutlich höhere Speicherwerte und eine höhere Rechenleis-
tung.
So la...
40 3. Hardware
Abbildung 3.8.: XBee-Shield aufgesteckt auf einer Arduino Shield Bridge, die
wiederum auf einem Raspberry P...
3.3. Physical-Computing-Plattformen 41
verfügen sie jedoch über Schnittstellen wie I2C und können somit mit anderen
Module...
42 3. Hardware
3.3.3. Beaglebone (Black)
Das Beaglebone Black ist ein Einplatinencomputer der Firma Texas Instru-
ments mi...
3.3. Physical-Computing-Plattformen 43
mit Projekte realisierbar, an denen ein Raspberry Pi bei zeitkritischen Anwen-
dung...
44 3. Hardware
oder beim Beaglebone Black auch auf dem internen 2GB Flash Speicher aus-
geführt werden.
Folgende Linux20 O...
3.3. Physical-Computing-Plattformen 45
Tabelle 3.3.: Spezifikation des Beagleboard Black [http13b]
46 3. Hardware
Abschließend kann diese Physical-Computing-Plattform wie folgt charak-
terisiert werden:
Das Beaglebone (Bl...
3.4. Peripherie 47
Die Namensgebung Ultraschallsensor ist an sich irreführend, da ein Ultra-
schallsensor kein reiner Empf...
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
diploma thesis
Nächste SlideShare
Wird geladen in …5
×

diploma thesis

681 Aufrufe

Veröffentlicht am

0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
681
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
6
Aktionen
Geteilt
0
Downloads
2
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

diploma thesis

  1. 1. D I P L O M A R B E I T Akustische Kommunikation in einem Schwarm von ad hoc Netzwerkknoten basierend auf der Arduino Prototyping Plattform von Sascha Friedrich eingereicht am 30.09.2013 beim Institut für Angewandte Informatik und Formale Beschreibungsverfahren des Karlsruher Instituts für Technologie Referent: PD Dr. -Ing. Sanaz Mostaghim Heimatanschrift: Studienanschrift: Brüderstraße 14 Brüderstraße 14 75210 Keltern 75210 Keltern
  2. 2. Ich erkläre hiermit, dass ich die vorliegende Arbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. Karlsruhe, den 30. September 2013
  3. 3. Inhaltsverzeichnis 1. Einleitung 1 1.1. Zielsetzung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Grundlagen 7 2.1. Akustik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.1. Wellentheorie . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.2. Theorie und Einheiten der Akustik . . . . . . . . . . . . 11 2.2. Unterwassernetzwerke . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2.1. Multiple Access Protocols . . . . . . . . . . . . . . . . . . 16 2.2.2. Medium Access Control (MAC) . . . . . . . . . . . . . . 18 2.3. Verwandte Arbeiten und Herangehensweise . . . . . . . . . . . 21 3. Hardware 27 3.1. Mikroprozessor-Architekturen . . . . . . . . . . . . . . . . . . . 28 3.1.1. ARM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.1.2. x86 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2. Mikrocontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.2.1. AVR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3. Physical-Computing-Plattformen . . . . . . . . . . . . . . . . . . 32 3.3.1. Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.3.2. Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.3.3. Beaglebone (Black) . . . . . . . . . . . . . . . . . . . . . . 42 3.4. Peripherie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4. Realisierung eines akustischen Modems 59 4.1. Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.1.1. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . 62 4.1.2. Existierende Lösungsansätze . . . . . . . . . . . . . . . . 63 4.1.3. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . 67 4.2. Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.2.1. Alternative Ansätze . . . . . . . . . . . . . . . . . . . . . 74 4.2.2. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . 75
  4. 4. vi Inhaltsverzeichnis 4.3. Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.3.1. Einrichtung der Softwareumgebung . . . . . . . . . . . . 76 4.3.2. Hardwareaufbau und Steuerung . . . . . . . . . . . . . . 78 4.3.3. Softwareimplementierung . . . . . . . . . . . . . . . . . . 81 4.3.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . 81 4.4. Evaluierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 4.4.1. Evaluation des akustischen Modem mit Pausen-Verzögerten Ablauf für die Abtastintervall-Erzeugung . . . . . . . . . 83 4.4.2. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . 89 5. Anpassung des akustischen Modems für eine bidirektionale Da- tenübertragung im Schwarm 91 5.1. Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.1.1. Existierende Lösungsansätze . . . . . . . . . . . . . . . . 92 5.1.2. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . 93 5.2. Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.2.1. Synchronisierungsalgorithmus . . . . . . . . . . . . . . . 94 5.2.2. Synchronisierungsimpuls . . . . . . . . . . . . . . . . . . 96 5.2.3. Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.2.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . 100 5.3. Evaluierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 5.3.1. Synchronisierungs-Algorithmus . . . . . . . . . . . . . . 101 5.3.2. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . 104 6. Zusammenfassung und Ausblick 107 A. Anhang 111 A.1. Quellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Literaturverzeichnis 143
  5. 5. 1. Einleitung Die heutige Zeit ist gekennzeichnet durch eine stark zunehmende Anzahl von embedded Geräten in unserem Alltag, die in verschiedenster Art und Weise miteinander teils lose (ad hoc) oder fest strukturiert vernetzt sind. So ent- stehen mittlerweile Netzwerke, an Orten, an denen vor einigen Jahrzehnten niemand damit gerechnet oder als realisierbar erachtet hätte. Einen beachtlichen Einfluss auf diese Gegebenheit hat natürlich zum einen Moore’s Law und den sich daraus ergebenden drei Faktoren: Miniaturisie- rung, Kapazitäts-/Leistungssteigerung und Kostensenkung. Vor allem die kostengünstige Produktion von größeren Chargen von Netzwerkteilnehmern, die für den Aufbau von ganzen Schwärmen notwendig sind, trägt ihren Teil zu dieser Entwicklung bei. Da gerade die Anzahl an Teilnehmern eines Sen- sornetzwerkes einen Einfluss auf die zu erledigende Aufgabe hat, ist dies von Vorteil. Zudem werden auch die notwendigen Kommunikationsmodule im- mer günstiger und energiesparender, wodurch der mobile ad hoc Einsatz ver- stärkt in den Vordergrund tritt. Und gerade bei diesem lassen sich feste Netz- werkstrukturen nicht mehr realisieren, sondern man muss ein sich ständig veränderndes, quasi ein lebendiges Netzwerk, handhaben. Eine Entwicklung, die wohl jedoch erst in den kommenden Jahren verstärkt zu tragen kommen wird, ist die Möglichkeit durch gezielte Auslagerung von Speicher- und Rechenkapazitäten in eine Cloud, Projekte zu realisieren, die mit recht rudimentären Clients auskommen können. Diese kostengünstigen und somit massenproduktionstauglichen Thin-Clients sind jedoch durch die Nutzung der Cloud sehr leistungsfähig und erzeugen in der Masse gewis- sermaßen einen empathischen Schwarm. Dieser kann durch eine ergänzende zusätzlich zentrale Stelle bei Bedarf ferngesteuert oder um zusätzliche Infor- mationen ergänzt werden.
  6. 6. 2 1. Einleitung Cloud Robotics1 wäre hierfür ein in jüngster Zeit immer öfters angewandter Versuch Roboterplattformen, wie bei einem Software as a Service (SaaS) An- satz, eine Skalierung der Rechen- und Speicherleistung möglich zu machen. Dies kann natürlich nicht nur für ein einzelnes Individuum, sondern auch im Maßstab eines Schwarms genutzt werden. Naturgemäß können Echtzeitentscheidungen durch die sich resultierenden Netzwerklatenzen nicht ausgelagert werden. Hier vermögen jedoch die Thin- Clients, und hier insbesondere diejenigen, die mit einem Mikrocontroller aus- gestattet sind, ihre volle Stärke als reflex-basierte (für sehr schnelle und schwer- wiegende Entscheidungen) oder einfache Echtzeit-Entscheider auszuspielen. Diese Dynamik basiert auf dem schnellen Auslesen von Sensorwerten und der Regulation von Aktoren. Offline-Learning-Anwendungen wiederum sind da- für prädestiniert in die Cloud verschoben zu werden, da sie nicht zeitkritisch zu handhaben sind und rechen- und speicherintensiv gestaltet sein können. Ein weiterer Trend, der zu einem verstärkten Netzwerkausbau in den ver- schiedensten Bereichen führt, ist das Phänomen der Physical-Computing- Plattformen, welche einerseits einen schnellen Prototypen-Aufbau gewährleis- ten, andererseits durch ihre leichte Handhabung und Erweiterbarkeit eine Vielzahl von Mashup-Lösungen ermöglichen. Neben anerkannten Institutio- nen wie die NASA, dem MIT, et cetera nutzen auch Hobbyisten, Start-Ups und Unternehmen die vielfältigen Möglichkeiten dieser Plattformen. Zudem bieten diese einfache und schnelle Baukasten-Lösungen, die vergleichbar mit denen von Lego NXT und dergleichen sind. Auch im Rahmen dieser Diplom- arbeit nutzen wir eine kostengünstige und flexible Systemlösung. Jedoch was ist zwingend notwendig für einen Schwarm? Das wäre die Kom- munikation bzw. die Abstimmung mit anderen Teilnehmern, die zum jetzi- gen Zeitpunkt hauptsächlich über elektromagnetische Funk- oder Infrarot- Transceiver gewährleistet wird. Eine Ausnahme hierzu bilden Räumlichkei- ten, die wie ein Faraday-Käfig aufgebaut sind, das wären zum Beispiel Kup- ferrohrleitungen, die eine elektromagnetische Abschirmung verursachen oder der Einsatz unter Wasser, der durch die starken Dipol-Kräfte der Wassermo- leküle, die durch einen zu hohen Dämpfungsfaktor, die elektromagnetische Übertragung ineffizient machen. Des weiteren, wie schon in den Absätzen zuvor erwähnt, nimmt die Anzahl der netzwerkfähigen Endgeräte immer stärker zu, und verursacht dadurch eine immer höhere Client-Dichte, welche zur Folge hat, dass dieser Übertra- gungskanal immer mehr Störungen unterliegt und an seine Grenzen stoßen kann. Somit ist ein alternativer Einsatz über akustische Signale erwägenswert, davon abgesehen, dass gerade akustische Übertragung in den eben genannten Umgebungen wie Faraday-Käfige und Unterwasser ohne größere Probleme einsetzbar wäre. 1Interessante Informationen hierzu findet man in [QuMD11]
  7. 7. 3 Aus den vorherigen Passagen sollten sich folgende wichtigen Punkte heraus- kristallisiert haben: • Homogene und heterogene Schwärme werden immer einfacher, un- komplizierter und kostengünstiger zu realisieren, beziehungsweise tre- ten durch die inzwischen allgegenwärtige Vernetzung von Endgeräten automatisch auf und können für Schwarmalgorithmen genutzt werden. • Eine Skalierung der Speicher- und Rechenleistung durch die Nutzung einer Cloud und Thin/Rich-Clients fördert das Auftreten von Schwär- men und erweitert deren Einsatzbereich. • Gerade Physical-Computing-Plattformen ermöglichen einen schnellen und kostengünstigen Aufbau eines mobilen ad hoc Netzwerkes, der fle- xibel erweiterbar ist. Zudem können schon vorhandene Offline-Geräte durch Physical-Computing-Plattformen unproblematisch in ein beste- hendes oder neu aufzubauendes Netzwerk integriert werden. • Die anzutreffenden Netzwerke werden immer mobiler und besitzen meist einen ad hoc multihop Charakter. • Eine terrestrische Umgebung unterliegt einer immer höheren Client- Dichte an elektromagnetisch orientierten Akteuren, die sich ein Über- tragungsmedium (Luft) teilen müssen. Dies macht alternative Übertra- gungskanäle immer interessanter, auf die bei Engpässen oder Störungen ausgewichen werden kann. • Es gibt Umgebungen, bei denen von vornherein eine elektromagnetische Übertragung auszuschließen ist. All diese Punkte tragen zu der Motivation bei, ein ad hoc Netzwerk in Schwarm- größe zu konzipieren, dass durch eine Physical-Computing-Plattform reali- siert werden soll. Dadurch soll es auch möglich sein, bestehende Projekte um Schwarminteraktion erweitern zu können und unkompliziert und schnell neue ad hoc Netzwerke mit Physical-Computing-Plattform-Eigenschaften zu ermöglichen. Um hierbei alternative Wege zu bestreiten, wird statt Funk, die akustische Übertragung gewählt, die für bestimmte Umgebungen, wie elektrisch leiten- de Rohrleitungen oder Unterwasser, ohnehin zu präferieren ist. Des weiteren sollte nicht außer Acht gelassen werden, dass zum Zeitpunkt der Erstellung dieser Diplomarbeit der Großteil der vorhandenen Roboter zwar über akusti- sche Transceiver, meist in Form von Ultraschall-Abstandsmessern, verfügen, jedoch ein Funkmodul nicht zwangsläufig integriert sein muss. Somit kann ein bereits existierender Roboter, der mit einer Ultraschall-Messeinheit (ein Typ, wie er in dieser Diplomarbeit verwendet wird) ausgestattet ist, ohne weitere Kosten oder Hardwareaufwand, um ein Kommunikationsmodul er- weitert werden.
  8. 8. 4 1. Einleitung 1.1. Zielsetzung der Arbeit Das Ziel dieser Arbeit ist die Ausarbeitung eines akustischen Schwarmnetz- werkes, wobei hier die Implementation eines physischen akustischen Modems für eine uni-direktionale Datenübertragung zwischen zwei Netzwerkknoten erstellt werden soll. Für auf dieser Diplomarbeit aufbauenden Arbeiten, soll zudem ein Konzept für die Implementation eines MAC-Protokolls für einen bidirektionale Datenübertragung in einem ad hoc Schwarmnetzwerk konzi- piert werden. Dieser Schwarm aus Netzwerkknoten soll, wie auch das Mo- dem, zudem durch die Arduino Physical-Computing-Plattform realisiert wer- den. Dieses Schwarmnetzwerk soll auf Basis von akustischen Transceivern ei- ne Alternative zu bereits vorhandenen elektromagnetischen Netzwerken dar- stellen und für den Einsatz in Faraday-Käfig ähnlichen Umgebungen, sowie durch Impedanzanpassung des Transceiver-Moduls, den Unterwassereinsatz ermöglichen. Hierbei soll vor allem durch die Verwendung einer Physical-Computing- Plattform sicher gestellt werden, dass in kürzester Zeit ein Schwarmnetzwerk aufgebaut werden kann und zukünftige Updates und Upgrades sich leicht bewerkstelligen lassen. Das zu entwickelnde ad hoc Schwarmnetzwerk ist von den sonst üblichen Da- tennetzwerken insoweit abzugrenzen, dass Schwarm-Algorithmen innerhalb des Netzwerkes zum Tragen kommen sollen und daher keine direkte globa- le Adressierung von einzelnen Individuen im Schwarm vorgesehen ist2. Die Kommunikation findet somit auf Basis von lokalen Broadcasts und mittels lokal direkt adressierten Übertragungen mit den unmittelbar benachbarten Einheiten statt. Des weiteren sind pure Sensordatenübertragungen zu einer zentralen oder multiplen Stellen vorgesehen, die wiederum ihrerseits Synchronisierungssi- gnale an den kompletten Schwarm wiedergeben können. Wir bedienen uns hier dem Beispiel aus der Natur, dass in Schwarm-Kolonien, zum Beispiel bei Ameisen, es verschiedene Gruppen mit unterschiedlichen Fähigkeiten und Be- fugnissen gibt. So gibt es bei den Ameisen nicht nur Sammler und Arbeiter, sondern auch Wächter und eine Brutmutter. Auch in unserem Schwarm sind verschiedene Gruppen mit unterschiedlichen Fähigkeiten und Aufgaben vor- gesehen. So soll es Synchronisierungs-Knoten geben, die beispielsweise mit einem GPS-Modul ausgestattet sind, das eine genaue Zeitwiedergabe ermög- licht. Diese Knoten dienen dem Schwarm als Taktgebern für eine synchrone Zeitsteuerung der einzelnen Knoten. Außerdem sollen diese Knoten als Emp- 2Damit ist gemeint, dass die Adresse und die Existenz von Knoten, die nicht in unmittelbarer Nachbarschaft vorhanden sind, dem Sender unbekannt sind und somit nicht von diesem direkt angesprochen werden können.
  9. 9. 1.2. Gliederung der Arbeit 5 fangsstationen, wie in der Unterwasserakustik weit verbreitet, als Funksender mit höheren Reichweiten zur Basisstation an Land, eingesetzt werden. Als Ziele für diese Diplomarbeit sind folgende Punkte vorgesehen: 1. Als erstes zu verwirklichendes Ziel ist die Erstellung eines Akustik- Modems, um das Transceiver-Modul der Netzwerkknoten, als auch die akustische Übertragung als solches zu testen und zu untersuchen. 2. Als zweites Ziel ist die theoretische Betrachtung eines Netzwerkes von mehr als zwei Teilnehmern vorgesehen, die sich ein Übertragungsme- dium teilen müssen. Hierzu muss ein Multi-Access-Protokoll aus der Unterwasserakustik dem terrestrischen Umfeld entsprechend angepasst und konzipiert werden, um in darauf aufbauenden Arbeiten die Soft- ware der Netzwerkknoten den neuen Nebenbedingungen (Interferen- zen durch gleichzeitige Übertragung von mehreren Netzwerkknoten im gleichen Empfangs- und Senderadius) anzupassen. Hierdurch kann, auf dieser Diplomarbeit aufbauend, ein akustisches ad hoc Netzwerk auf Basis der Arduino Physical-Computing-Plattform implemen- tiert werden. Dieser Prototyp eines physischen Schwarms kann darauf fol- gend für weitere Untersuchungen verwendet werden. 1.2. Gliederung der Arbeit Wir werden in Kapitel 2 die Grundlagen, die für den Aufbau dieser Arbeit benötigt werden, abhandeln. Im ersten Unterkapitel 2.1, das sich zuerst mit den physikalischen Grundlagen der Akustik auseinandersetzt, wird eine kurze Auffrischung bzw. eine grobe Zusammenfassung, der für diese Arbeit wichtigen physikalischen Begeben- heiten, die im späteren Projektverlauf eine Rolle spielen, geboten. Ein Haupteinsatzgebiet akustischer Netzwerke und somit eine Quelle vie- ler schon vorhanden Lösungsansätze, Herangehensweisen, Konzeptionen und Analysen reiht sich mit Unterkapitel 2.2 Unterwassernetzwerke in die Folge ein. Hier wird näher auf den grundsätzlichen Aufbau, den Problemen und Lösungsansätzen der akustischen Netzwerke eingegangen und dient diesem Projekt als Hauptangelpunkt. Hierbei stellen die verschiedenen Netzwerkprotokolle eine entscheidende Rol- le dar und sind daher in den Unterkapiteln 2.2.1 und 2.2.2 detailliert beschrie- ben. Hierbei nutzen wir die Erfahrungswerte aus der Unterwasser-Akustik und gehen näher auf schon bestehende Lösungsvarianten in Unterkapitel 2.3 ein. Zum Abschluss der Grundlagen wird in Unterkapitel 3 das notwendige Fach- wissen für die spätere Auswahl und der Arbeit mit den verwendeten Hard- warekomponenten und möglichen Alternativen beleuchtet.
  10. 10. 6 1. Einleitung Nachdem die Grundlagen im vorherigen Kapitel abgehandelt wurden, wid- met sich Kapitel 4 der Erstellung eines akustischen Modems. Die Gliederung des Kapitels ist der wissenschaftlichen Arbeitsweise ange- passt und besteht aus den folgenden Unterkapiteln: 4.1 Analyse, 4.2 Entwurf, 4.3 Implementierung und 4.4 Evaluierung. Nach erfolgreicher Erstellung eines akustischen Transceiver-Moduls, beschreibt Kapitel 5 die notwendigen Schritte für die Entwicklung eines kompletten akustischen Schwarmnetzwerkes, dass vor allem durch das verwendete Multi- Access-Protokoll gekennzeichnet ist. Auch hier spiegeln die Unterkapitel, wie in Kapitel 4 die methodisch klar strukturierte wissenschaftliche Arbeitsweise wider. Zum Abschluss wird in Kapitel 6 das Resümee der vorgestellten Arbeit und ein Ausblick für den Einsatz, den Erweiterungsmöglichkeiten und ein Anstoß für mögliche weiteren Untersuchungen gegeben.
  11. 11. 2. Grundlagen In diesem Kapitel werden wir den grundlegenden theoretischen Hintergrund für den Aufbau eines akustischen Schwarms erläutern. Hierbei werden wir in Kapitel 2.1 die für uns verfügbare Frequenzspektrum für die Nutzung in einem akustischen Schwarmnetzwerkes und den jeweiligen Charakteristika der jeweiligen Frequenzbereiche näher beschreiben. Darauf erläutern wir in Kapitel 2.1.2 die wichtigsten wellentheroetischen Grundlagen, sowie Begriff- lichkeiten und sehen in Kapitel 2.1.2 anschließend noch gezielter auf die für uns wichtigen Schallwellenparameter ein. Nachdem die Grundlagen der Akustik beschrieben wurden, können wir in Kapitel 2.2 uns der für uns wichtigen Unterwassernetzwerken widmen und uns näher damit auseinandersetzen warum gerade in dem Medium Wasser diese Art von Netzwerk eine so entscheidende Rolle für die Forschung und für praktische Anwendungen spielt. Diese haben auf unsere Diplomarbeit in- sofern einen wichtigen Einfluss, da wir sie als Grundlage für unseren terrestri- schen akustischen Schwarm zu einem erheblichen teil als Vorlage heranziehen werden. Hier werden wir vor allem auf die zur Verfügung stehenden Protokol- le für den Mehrfachzugriff in Kapitel Unterkapitel 2.2.1 und in Unterkapitel 2.2.2 der Medienzugriffssteuerung (MAC) und der möglichen Verwendung in einem akustischen Netzwerk beschreiben. Als letztes Protokoll in dieser Analyse in 2.2.2 werden wir uns sehr genau das FAMA-Protokoll anschauen, das wir in in letzten Unterkapitel 2.3, das sich mit den herangezogenen Arbeiten unserer Diplomarbeit und dem generellen Vorgehen unserer Verwirklichung eines akustischen Schwarms erläutern wer- den, um eine Synchronisation-Variante, dem Slotted-FAMA erweitern. Die- ses Protokoll bildet die Grundlage für die Kommunikation von abschließend mehreren Knoten in einem akustischen Netzwerkes.
  12. 12. 8 2. Grundlagen 2.1. Akustik Da wir für unser Projekt eine alternative Übertragungsform, die Akustik, wählen, werden wir in den folgenden Unterkapiteln grob die wichtigsten Informationen aufbereiten, die für den Aufbau eines akustischen Schwarm- Netzwerkes von Bedeutung sind. Das wären im Einzelnen die generellen wellentherotischen Begrifflichkeiten bezüglich der Form und Ausbreitung einer Druckwelle in Unterkapitel 2.1.1 und deren energetischen Eigenschaften in 2.1.2. Zuvor werden wir noch das Schallspektrum mit seinen unterschiedlichen Frequenzbändern erläutern. Die Frequenzbänder in der Akustik werden hauptsächlich in drei Abschnit- te untergliedert. Wie aus Abbildung 2.1 ersichtlich wird, sind das im Bereich unter 20 Hz der Infraschall, den Menschen nicht wahrnehmen können, sowie im Intervall zwischen 20Hz und 20kHz der hörbare Bereich, den wir Menschen wahrnehmen und somit für Datenübertragungszwecke unbedingt zu vermei- den ist. Hierauf folgt mit über 20kHz der Ultraschallbereich, der außerhalb der menschlichen Wahrnehmungsschwelle liegt und für unsere Zwecke ge- nutzt werden kann. In Kapitel 3.4 werden wir bei der Beschreibung des von uns genutzten Ul- traschallsensors weiter auf die dadurch bedingte Richtungscharakteristik und weiteren Eigenschaften näher eingehen. Wir werden nun jedoch kurz die be- reits erwähnten Frequenzbereiche charakterisieren, um auf die damit verbun- denen Störquellen und Besonderheiten für unser Projekt einzugehen. Abbildung 2.1.: Akustische Frequenzbereiche [Wiki13g] Infraschall: Infraschall wird von vielen Tieren wahrgenommen, da viele zer- störerische Ereignisse, wie beispielsweise Gewitter, Vulkanausbrüchen und Erdbeben damit verbunden sind. Somit stellt die Wahrnehmung dieser Früh- signale evolutionsbiologisch einen Vorteil dar. Beispielsweise können Brieftau- ben und Elefanten diese niederfrequenten Schallwellen wahrnehmen, und im Fall von den Dickhäutern sogar initiiert werden. In Bezug auf Brieftauben werden diese niederfrequenten Wellen, durch Wasserwellen tief im Ozean erzeugt und über weite Distanzen bis in die Atmosphäre übertragen. Diese Ultraschalltöne werden als akustischer Marker eingesetzt und zur Navigati- on herangezogen1. Durch die geringe Absorption dieses Frequenzspektrums, 1Nähere Informationen findet man in [KrQu79]
  13. 13. 2.1. Akustik 9 ähnlich wie bei elektromagnetischen Radiowellen, können diese erstaunliche Distanzen zurücklegen. Eine Reichweitenerhöhung kann zudem durch Schall- kanäle erreicht werden, wenn kühlere Luftschichten mit weniger Turbulenzen, eine bis zu dreifache Erweiterung ermöglichen2. Zudem weißt dieses Fre- quenzband, wie wir in Kapitel 3.4 näher beschreiben werden, eine weniger richtungsabhängige Ausbreitung auf. Da der Infraschall von Tieren wahrgenommen werden kann, muss im Einzel- fall geprüft werden, inwieweit diese Frequenzen für eine Datenübertragung ausscheiden. Der Mensch kann hier als Faktor ausgeschlossen werden. Hörbarer Bereich: Hier wird eine Richtungscharakteristik mit steigender Frequ– enz immer ausgeprägter, welche immer noch deutlich geringer ist als im Ul- traschallbereich. Da hier der Mensch mit in die Betrachtung für die Daten- übertragung einbezogen werden muss, scheidet dieser Bereich für unser akus- tisches Schwarmnetzwerk aus, es sei denn man will dem Menschen Informa- tionen in Form von Warntönen oder besonderen Zuständen des Schwarms zukommen lassen. Ultraschallbereich: Ultraschall wird von einigen Tieren, wie beispielsweise Delphinen, Hunden und vor allem nachtaktiven Tieren wie Fledermäuse wahr- genommen. Hier müssen die Einsatzbereiche und Frequenzen der jeweiligen Situation angepasst werden. Diese sind in Bezug auf den Menschen jedoch außerhalb der Wahrnehmungsschwelle und somit für das Projekt nutzbar. Durch die hohen Frequenzen wird allerdings eine deutliche Richtungscharak- teristik sichtbar und zudem die Reichweite durch erhöhte frequenzabhängige Dämpfung gemindert. Wiederum bedeuten hohe Frequenzen für unseren akustischen Schwarm ho- he Bitraten, was in einem Schwarm von essentieller Bedeutung ist, bei dem beträchtlicher Overhead durch die vielen Einheiten verursacht wird, und so- mit für eine gute Funktionsweise erforderlich ist. Daher ist abschließend zu sagen, dass ein gewisser Tradeoff zwischen Bitrate und Richtungscharakteristik bei der von uns für die akustische Kommunika- tion ausgewählten Frequenz eingegangen werden muss. Umgangen werden kann die Richtungsabhängigkeit durch die Anbringung mehrerer Schallwand- ler, die jeweils außerhalb des Interferenzbereiches der Anderen liegen. 3 Eine andere Möglichkeit wäre durch zeitlich seriell geschaltete Schallwandler dies zu bewerkstelligen. Daraus resultieren allerdings auch ein höherer Komplexi- tätsgrad für die Kommunikation, ein damit verbundener höherer Energiever- brauch sowie eine größere Fehleranfälligkeit. 2Weitere Informationen hierzu können in der, von der National Geographic geförderten Forschung, in dem Paper [GLRL95] entnommen werden. 3In Kapitel 3.4 beschreiben wir dies anhand des Halbwertswinkels.
  14. 14. 10 2. Grundlagen 2.1.1. Wellentheorie Die folgende Abbildung 2.2 zeigt eine typische Sinuswelle mit ihren Eigen- schaften. Auf Basis dessen, werden wir die in diesem Abschnitt die für uns essentiellen Variablen/Parameter für die Diplomarbeit erläutern. Abbildung 2.2.: Sinus-Welle Die folgenden Definitionen sind aus [Frie08] entnommen: • Amplitude (A): ’Die Amplitude ist das Mass für die Starke der Schwin- gung. In der Hörwelt klingen starke Schwingungen gleicher Frequenz lauter als schwache. Die Amplitude hat keinen Einfluss auf die Fre- quenz.’ • Phase (φ): ’Der dritte Parameter einer Schwingung ist die Phasenlage. Sie ist interessant im Zusammenhang mit anderen Schwingungen und gibt an, um welchen Grad die Schwingungen gegeneinander verscho- ben sind. Zwei Schwingungen sind in Phase, wenn der Kurvenverlauf übereinstimmt, also die Maxima und die Nulldurchgänge zum selben Zeitpunkt stattfinden. Gegenphasige Signale haben zur selben Zeit Null- durchgänge, wahrend am Scheitelpunkt die eine Schwingung ihren po- sitiven Maximalwert, die andere ihren negativen erreicht. Angegeben wird die Phasenlage in Grad. 0◦ bedeutet gleichphasige, 180◦ gegenpha- sige Signale. Eine Phasenverschiebung von 90◦ weist auf unkorrelierte - das heißt voneinander unabhängige - Signale hin. Die Phasenlage ist entscheidend, wenn es um Überlagerungen von Schallwellen, die soge- nannten Interferenzen geht.’ • Wellenlänge (λ): ’ Die Wellenlänge ist der Weg, den der Schall wahrend einer Periodendauer zurücklegt. In der Luft liegen die Wellenlängen der
  15. 15. 2.1. Akustik 11 hörbaren Frequenzen zwischen 17 m und 17 mm.’ • Periode (T): ’Die Form einer solchen idealen Schwingung ist sinusfor- mig. Visualisieren lasst sich so etwas durch ein Masse-Feder-Pendel, das auf und ab schwingt. Befestigt man einen Stift an der Unterseite, der die momentane Auslenkung auf ein Blatt Papier zeichnet, das mit konstan- ter Geschwindigkeit vorbeiläuft, ergibt sich die Sinuskurve. Der Schwin- gungsverlauf wiederholt sich periodisch, solange die Schwingung nicht gebremst wird. Die Zeit, in der eine solche Schwingungsperiode durch- laufen wird, nennt man Periodendauer.’ • Frequenz (f): Die Anzahl Schwingungen pro ’Sekunde ist die Frequenz. Die Einheit der Frequenz ist das Hertz (Hz),[...]’ • Geschwindigkeit (v): ’Je nach Medium breitet sich der Schall unterschiedlich schnell aus. Die Schallgeschwindigkeit c in Luft liegt für normale Temperaturen bei et- wa 343 m/s. Aus der Schallgeschwindigkeit lasst sich die Wellenlänge λ (sprich lambda) ableiten.’ • Wellenzahl (k): Die Wellenzahl ist der Quotient aus 2π und λ. Diese Variablen stehen in folgenden Beziehungen zueinander: f = 1 T (2.1) λ = v · T (2.2) k = 2π λ (2.3) 2.1.2. Theorie und Einheiten der Akustik Eine für uns wichtige Größe für die akustische Datenübertragung ist die mög- liche maximale Reichweite, die wir erzielen können und der Einfluss von Ma- terialien auf die Wellenausbreitung. Da Schallwellen keine Materie übertra- gen, nachdem die Partikel nur um die Gleichgewichtslage schwingen, wird Energie durch Schwingungsanregung jeweils benachbarter Moleküle erzeugt. Je nach Kopplung dieser Moleküle kommt es zu einer schnelleren oder lang- sameren Ausbreitung in einem Material. Die Wellen werden als Longitudina- le Wellen bezeichnet und sind gekennzeichnet durch Dichte-Schwankungen
  16. 16. 12 2. Grundlagen entgegen und mit der Ausbreitungsrichtung im Medium. Dagegen abzugren- zen wären Transversale Wellen, die beispielsweise bei Wasser-Oberflächen- wellen vorkommen. Im Gegensatz zu Longitudinalen Wellen, werden hier die Moleküle rechtwinklig zur Ausbreitungsrichtung zur Schwingung angeregt. Für uns sind in diesem Zusammenhang im Wesentlichen diese Werte von Be- deutung: Schalldruck, Schallschnelle, Relativer Schalldruckpegel, Schall- leistung, Schallleistungspegel, Kugelwelle, Schallintensität und Nahfeld/- Fernfeld. Die folgenden Definitionen sind [Frie08] entnommen: Schalldruck (p): ’Er tragt das Formelzeichen p von pressure und wird in Pas- cal (Pa) angegeben.[...] Der Schalldruck ist ortsabhängig. Je weiter man sich von der Schallquelle entfernt, desto geringer ist der Schalldruck. Er halbiert sich mit jeder Verdopplung der Entfernung. Der Schalldruck ist durch die Schwingung nicht konstant. Deshalb wird auch nicht sein Spitzenwert ver- wendet, sondern der Effektivwert. Der Effektivwert entspricht dem Wert, den ein unveränderliches Signal mit denselben Eigenschaften - in diesem Fall den- selben Druck - hatte. Bei Sinusschwingungen berechnet man den Effektivwert, indem man den Spitzenwert durch √ 2 dividiert. Das Verhältnis von Spitzen zu Effektivwert nennt man auch den Crest-Faktor.’ Schallschnelle (v): ’Die mittlere Geschwindigkeit, mit der sich die Luftmole- küle um ihren Ruhepol bewegen ist die Schallschnelle v. Sie hat nichts mit der Schallgeschwindigkeit zu tun sondern liegt bei unter einem Millimeter pro Sekunde. Sie steigt mit zunehmender Lautstärke an.’ Relativer Schalldruckpegel (Lp): ’Der große Wertebereich der hörbaren Schall- drücke ist für die tägliche Arbeit zu unübersichtlich. Außerdem wird sie dem Gehör nicht gerecht. Das Weber-Fechnersche Gesetz besagt, dass die Wahrnehmungsorgane eine Reizverstärkung nicht linear, sondern nur loga- rithmisch übertragen[...]. Daher bietet sich ein logarithmisches Verhältnismaß an, um Schalldruckdifferenzen auszudrücken. Das ist der Schalldruckpegel. Um zwei Schalldrücke miteinander in Beziehung zu setzen, kann anstelle der Hörschwelle auch jeder andere Schalldruck als Referenzwert p0 verwendet werden. Die Einheit dieses relativen Schalldruckpegels ist das Dezibel (dB). 6dB entsprechen einer Verdopplung oder Halbierung des Schalldrucks, 20 dB dem Zehnfachen. Durch die Ortsabhängigkeit des Schalldrucks sinkt der Schalldruckpegel um 6 dB mit jeder Verdopplung der Entfernung.’ Schallleistung (Pak): ’Im Gegensatz zum Schalldruck ist die Schallleistung ortsunabhängig. Sie beschreibt eine Eigenschaft der Schallquelle, nämlich die Menge an Schallenergie, die pro Zeiteinheit abgestrahlt wird. Diese akustische Leistung Pak hat die Einheit Watt (W).’
  17. 17. 2.1. Akustik 13 Schallleistungspegel (LW): ’Der Schallleistungspegel ist ein logarithmisches Maß zur Beurteilung von Schallleistungen im Verhältnis zur Referenz von P0 = 10−12W. Seine Einheit ist das Dezibel. Er wird wie folgt berechnet: LW = 10 lg P P0 (2.4) ’ Kugelwelle: ’Man unterscheidet Kugelwellen von ebenen Wellen. Kugelwel- len werden von Punktschallquellen erzeugt, ebene Wellen von Flächenstrah- lern, die aber in der realen Welt kaum und wenn dann nur für hohe Fre- quenzen vorkommen. Statt dessen nähert sich eine Kugelwelle mit steigender Entfernung einer ebenen Welle an. Nahe der Schallquelle ist die Krümmung der Kugelwelle noch sehr stark, mit steigendem Durchmesser wird sie aber immer schwächer, so dass man in einiger Entfernung von einer ebenen Wel- lenfront sprechen kann.’ Dieser Approximation werden wir uns in 3.4 für die Herleitung der Impedanz bedienen. Schallintensität (I): Die Schallintensität ist die Schallleistung dividiert durch den Flächeninhalt. Diese Größe ist somit im Gegensatz zur Schallleistung ent- fernungsabhängig und ist im Fall einer Kugelwelle durch eine veränderte Oberfläche abhängig vom jeweiligen Radius. Bei einer ebenen Welle ist das wiederum nicht der Fall, da hier die Fläche konstant bleibt. Für eine Punktschallquelle (Kugelwelle) gilt: I = Pak A = Pak 4πr2 =⇒ I ∼ 1 r2 (2.5) Diese Abnahme der Energie/Flächeneinheit führt, wie die Absorption, zur einer Amplitudenminderung und beschränkt damit die effektive Reichweite für unsere Datenübertragung. Nahfeld/Fernfeld: ’Das Nahfeld bezeichnet einen Abstand zur Schallquelle bis etwa zur halben Wellenlänge. Darüberhinaus gelten Fernfeldbedingungen. Im Fernfeld sind Schalldruck und Schallschnelle gleichphasig.’ Abbildung 2.3 zeigt den Nahbereich und den sich langsam annähernden Fern- bereich, mit einer gemeinsamen Wellenfront. Wie aus dieser Abbildung er- sichtlich wird, ist mit Interferenzen im Nahbereich zu rechnen. Im Fernbereich wiederum können durch die Verwendung mehrerer Schallquellen ebene Wel- len angenommen werden. Phasenunterschiede im Nahfeld wirken sich hier auf die Schallschnelle aus, indem sie zu einer ∝ 1 r2 Berechnung, anstatt einer ∝ 1 r dieser führen. Dadurch sinkt auch die Schallschnelle im Nahbereich mit 1 r2 und im Fernbereich nur noch um 1 r für eine Kugelwelle.
  18. 18. 14 2. Grundlagen Nach [Frie08] erfolgt die ’[...]Schallausbreitung [...] in der Realität immer ge- richtet. Die Punktschallquelle und ihre kugelförmige Schallabstrahlung ist ein idealisiertes, theoretisches Modell.’ Dies hat auf unsere Arbeit insofern Einfluss, da wir keine kreisförmige Si- gnalübermittlung mit nur einem Sender bewerkstelligen können. Wir müssen daher mehrere Transceiver-Module nutzen, oder uns die Richtungscharakte- ristik zu Nutze machen. Abbildung 2.3.: Hier sind, sich langsam bildende, ebene Wellenfronten am rechten Rand zu sehen. Die ganze Abbildung zeigt den Nah- bereich, da für die zusätzliche Darstellung des Fernbereichs, eine sonst viermal so breite Abbildung gezeichnet werden müsste. [Wiki13d] 2.2. Unterwassernetzwerke Laut [SoSP00a] ist ein Unterwassernetzwerk wie folgt gekennzeichnet: ’Un- derwater acoustic networks (UAN) are generally formed by acoustically connec- ted ocean-bottom sensors, autonomous underwater vehicles, and a surface station, which provides a link to an on-shore control center.’ Ein Unterwas- sernetzwerk hat den Throughput zu maximieren, ebenso zuverlässig zu funk- tionieren und den Energieverbrauch zu minimieren, da ein Austausch oder ein Wiederaufladen der vorhandenen Energiespeicher Unterwasser mit hohen Bergungskosten auf See verbunden ist. In den frühen Jahren der Unterwasser- forschung wurden Sensoren am Meeresboden und in verschiedenen Schichten des Meeres verankert. Diese Sensoren konnten ihre gesammelten Daten nur speichern und nicht an die Oberfläche übermitteln, so war man daran ge- bunden, dass die Sensoren absolut zuverlässig funktionsfähig waren. Da dies naturgemäß nicht immer gewährleistet werden kann, kam es des öfteren zu unbrauchbaren Daten, die zudem erst nach Wochen oder Monaten entdeckt wurden. Um dies zu umgehen, musste nach einer Lösung für dieses Problem gesucht werden. Da im Wasser, jedoch wegen den wirkenden Dipolkräften der
  19. 19. 2.2. Unterwassernetzwerke 15 Wassermoleküle, die Absorptionsrate, wie in Abbildung 2.4 ersichtlich ist, im Bereich bis 100MHz einen viel zu großen Wert für eine energieeffiziente Da- tenübertragung darstellt musste man eine andere Übertragungsform suchen. Diese ist die akustische Schallübermittlung. In Abbildung 2.4 sieht man den deutlich geringeren Absorptionskoeffizienten für Schallwellen im Vergleich zu elektromagnetischen Wellen. Abbildung 2.4.: Vergleich der Dämpfungswerte für EM und Schallwellen [LeSW09] Die Topologie eines typischen UAN kennzeichnet sich durch einen ad hoc multi-hop-Charakter. Diese Netzwerke haben einen hierarchischen Aufbau, da als zentraler Hub ein Oberflächensender, der neben eines akustischen Mo- dems auch einen Funksender für die Datenübertragung ans und vom Festland integriert hat, eingebunden ist. Ein Nachteil dieses Aufbaus ist die geringere Robustheit bei Ausfall des Hubs, was jedoch durch redundante Hubs kom- pensiert werden könnte. Die Reichweite der verwendeten akustischen Mo- dems wird auf ein Minimum angesetzt, damit möglich wenige Interferenzen durch Überlagerung mehrerer Signale entstehen können. Zudem wäre eine direkte Kommunikation aller Knoten miteinander energetisch wenig sinnvoll und wird daher durch eine multi-hop-Verbindung realisiert. Zudem würde der Versand zu einem sehr weit entfernten Knoten die Datenübertragung von anderen Knoten in der Nachbarschaft blocken und zu einem geringeren Throughput führen. Dieses Problem wird als Nah-Fern-Problem bezeichnet. Der große Nachteil eines multi-hop-Ansatzes ist andererseits eine vergrößerte Latenz, die bei der Akustik durch die deutlich niedrigeren Geschwindigkeiten als bei elektromagnetischen Wellen ohnehin sich schon nachteilig auswirkt. Da in UAN jedoch der Energieverbrauch eine höhere Gewichtung, als die La- tenz einnimmt, wird der multi-hop Charakter präferiert.
  20. 20. 16 2. Grundlagen Abbildung 2.5.: Network topology of an UAN [SoSP00a] 2.2.1. Multiple Access Protocols In vielen Netzwerken ist der Datenverkehr durch stoßweisen Versand von Da- tenpaketen gekennzeichnet, wobei die meiste Zeit das System als solches sich in Ruhezustand befindet. Da die Bandbreite bei UAN ein wertvolles Gut dar- stellt und das Übertragungsmedium für alle Knoten zugänglich ist, muss die verfügbare Zeit und die nutzbaren Frequenzen effizient für die Datenübertra- gung eingeteilt werden. Da wir uns, wie Unterwasser im terrestrischen mit einem Mehrfachzugriff-Medium auseinandersetzen müssen, werden wir in den folgenden Abschritten auf die drei wichtigsten Multiple Access Protocols näher eingehen. Dies wären der Reihenfolge nach Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA) und Code Division Mul- tiple Access (CDMA). Frequency Division Multiple Access (FDMA): bei diesem Protokoll für den Mehrfachzugriff auf ein Medium wird die verfügbare Bandbreite in mehre- re Teilbänder untergliedert. Ein spezifischer Kanal, mit einer verbundenen Frequenz ist hier ausschließlich für einen Netzwerkknoten zu einer bestimm- ten Zeit nutzbar, bis dessen Übertragung beendet wurde. Bei diesem Proto- koll müssen leistungsstarke Filter genutzt werden um die unterschiedlichen Frequenzen voneinander abgrenzen zu können. Dafür gibt es hier nicht das Nah-Fern Problem, wie wir es in Kapitel 2.1.2 angesprochen haben und zu- dem muss keine aufwendige Synchronisierung wie bei TDMA implementiert werden. Hier ist jedoch die vorhandene Bandbreite, die man für die verschie-
  21. 21. 2.2. Unterwassernetzwerke 17 denen Kanälen nutzen kann von entscheidender Bedeutung. Da die Frequenz während der Übertragung nicht verändert werden kann, ist man auf einen störungsfreien Kanal angewiesen. Time Division multiple access (TDMA): Hier wird im Gegensatz zu FDMA nicht die Bandbreite in Subkanäle untergliedert, sondern ein vorgegebenes Zeitfenster (Frame) in mehrere Zeitintervalle (Slots) eingeteilt. Jeder Slot wird einem Knoten zugewiesen. So können quasi simultan Daten von mehreren Knoten verschickt werden ohne das Interferenzen entstehen. Um Kollisionen von benachbarten Slots zu vermeiden werden Wartezeiten zwischen ihnen an- gewandt. Diese Wartezeiten müssen proportional zur Laufzeitverzögerung im Kanal angesetzt werden. Da wir bei UAN jedoch mit hohen Laufzeitverzöge- rungen zu kämpfen haben, ist dies hier weniger praktikabel. Da bei TDMA erst die Daten gepuffert werden müssen, bis ein zugeteilter Slot turnusgemäß noch einmal aufgerufen wird und nun die Daten versendet werden können, erfolgt hier ein sehr stoßweiser Netzwerkverkehr. Hier benötigen wir jedoch höhere Bitraten als bei FDMA. Während keine Datenübertragung erfolgt, kön- nen zudem die Knoten zur Energieeinsparung in einen Ruhemodus versetzt werden. Ein schwerwiegender Nachteil von TDMA ist die benötigte Zeitsyn- chronisierung der knoten, damit die Slots im richtigen Moment auch auf dem dafür bestimmten Knoten genutzt werden können. Dies ist in UAN schwierig, kann durch ein regelmäßiges gesendet Synchronisierungssignal mit einmali- ger (bei statischen Netzwerken) oder periodischer (mobiles Netzwerk) Latenz- berechnung erreicht werden. Wie werden in Kapitel 2.2.2 zwar kein Multiple Access Protocol, sondern ein Medium Access Control Protocol mit der Be- zeichnung Slotted-FAMA mit genau dieser synchronen Eigenschaft widmen. Somit wäre eine die Einführung von diesem Mehrfachzugriff-Protokoll nach einigen Anpassungen realisierbar. Code Division Multiple Access (CDMA): bei CDMA können alle Knoten die komplett verfügbare Frequenzbandbreite simultan benutzen. Dies wird durch eine Codierung eines Signals mit Pseudo-Rauschen ermöglicht. Durch dieses Rauschen unterscheiden sich die Signale von unterschiedlichen Knoten und können beim Empfänger dementsprechend decodiert werden. Im Gegen- satz zu FDMA und TDMA kann hier das Nah-Fern-Problem jedoch auftre- ten, wenn ein starkes Signal ein schwächeres Signal überlagern sollte. Dies kann man zwar durch Mehrfachbenutzer-Detektion mildern indem man die Signalstärke auf ein Minimum beschränkt um den Empfänger zu erreichen und dabei möglichst wenig andere Signale um ein vielfaches zu überlagern, erfordert jedoch einen erhöhten Aufwand. Wiederum senkt dies ebenso den Energieverbrauch und sollte daher hier deswegen bei UAN angewandt wer- den.
  22. 22. 18 2. Grundlagen 2.2.2. Medium Access Control (MAC) Die raren Ressourcen in einem limitierten Unterwasserkanal sollten in einer möglichst effizienten Art und Weise genutzt werden. Hierfür ist das Media Access Protokoll verantwortlich, mit dessen verschiedenen Varianten wir in den folgenden Abschnitten uns näher befassen. Das originale ALOHA Protokoll besteht aus einem Zufallszugriff für die ein- zelnen Knoten. Wenn ein Knoten Informationen für einen Datenversand hat, so werden diese auch unmittelbar versendet. Wenn die Datenübertragung er- folgreich von einem Sender an einen Empfänger zu Stande kommt, was be- deutet das keine Paketkollisionen auftraten, sendet der Empfänger eine Be- stätigung in Form von einem (ACK)4, andernfalls wird nach einer zufällig gewählten Wartezeit eine erneute Datenübertragung versucht. Durch den Zu- fallscharakter ist eine weitere Kollision recht unwahrscheinlich, kann jedoch dennoch auftreten. Dieses Protokoll erfordert allerdings sehr geringe Latenzen und führt zu einem relativ hohen Energieverbrauch, den man sich bei UAN jedoch nicht leisten kann. Der maximale Throughput liegt laut [SoSP00a] bei circa 15%. Das weiterentwickelte Extended-ALOHA Protokoll erweitert das ALOHA Pro- tokoll und synchronisiert die Uhren der Netzwerkknoten und erlaubt nur Datenübertragungs-Anfragen zu Beginn eines designierten Sendezeitraumes. Da die Wahrscheinlichkeit für Kollisionen zu diskreten Zeitpunkten herab- setzt, erhält man hier einen Throughput von 36%. In stoß weise erfolgenden Datenübertragungsnetzwerken, erfolgen trotz alledem zu viele Kollisionen für ein UAN und resultieren daher in einem viel zu hohen Energieverbrauch. Das Carrier Sense Media Access (CSMA) tastet den Übertragungskanal nach Trägerwellen ab, um präventiv Kollisionen zu vermeiden. Hierfür ist natür- lich eine möglichst geringe Latenzen notwendig, damit möglichst schnell eine Trägerwelle erkannt werden kann, bevor selbst Anfragen ausgesendet oder Daten übertragen werden. Nur wenn ein Knoten einen freien Kanal annimmt, versucht er sein Paket zu senden. Hierbei gibt es zwei problematische Sze- narios bei denen trotz alledem Kollisionen auftreten können. Diese Szenarien werden das Versteckte Knoten (hidden node) Szenario und das Freiligende Kno- ten (exposed node) Szenario genannt. Auf Basis von Abbildung 2.6 werden wir nachfolgend diese zwei Szenarien erläutern. Versteckte Knoten Szenario: Wenn Knoten A ein Paket an Knoten B sendet, so erkennt C nicht die Trägerwelle und sendet sein eigenes Paket, was zu einer Kollision mit dem Paket von B führt. Da der Knoten A für C versteckt war, wird dieses Szenario Verstecktes Knoten Szenario genannt. Freilegender Knoten Szenario: Wenn das Ziel von einem Paket von C nicht B wäre, so sollte B keine Kollision feststellen, falls dieser Knoten Interferen- 4ACK=Acknowledgment
  23. 23. 2.2. Unterwassernetzwerke 19 Abbildung 2.6.: Knotentopologie für unser Beispiels UAN [SoSP00a] zen, durch die gleichzeitig eintreffenden Pakete verursacht werden handha- ben kann. Auf der anderen Seite, wenn B eine Nachricht an A sendet, so ist C blockiert, selbst, wenn es nicht das ziel für das Paket von B darstellen sollte. Das sorgt für einen unnötig niedrigen Datendurchsatz. Das CSMA Protokoll kann diese zwei Szenario durch Schutzzeiten, welche proportional zur maximalen Übertragungszeitverzögerung im Netzwerk an- gewendet werden. Da jedoch der akustische Informationsaustausch im Wasser mit hohen Laufzeitverzögerungen, durch die niedrige Schallgeschwindigkeit, verbunden ist, resultiert CSMA in hohen Leerzeiten und somit in einen ge- ringeren Datendurchsatz. Als Konsequenz ist CSMA nicht praktikabel für ein UAN und daher noch weniger für terrestrische akustische Netzwerke, mit noch geringerer Schallgeschwindigkeit in der Luft, wie wir eines erstellen wollen. Das Multiple Access with Collision Avoidance (MACA) nutzt zwei Signal- pakete um den Datenverkehr zu regeln. Das sind im Einzelnen: request-to-send (RTS) und clear-to-send (CTS). Sobald ein Knoten A seine Daten verschicken will, sendet es ein RTS an den Empfangsknoten mit den Metainformationen der Länge des beabsichtigten Datenpakets, das verschickt werden soll. Wenn B das RTS empfängt und in der Warteschlange Zeit für diese Nachfrage hat, so sendet Knoten B ein CTS. Nun kann die richtige Datenübertragung nach die- sem Handshake erfolgen. Dies löst sowohl das Versteckte Knoten Szenario als auch das Freilegende Knoten Szenario. Eine Automatische Leistungssteue- rung kann durch das Erlernen der minimalen Schallamplitude beim RTS- CTS-Handshake zudem erlernt. Das Freilegende Knoten Szenario kann daher durch die Verringerung der Signalstärke für den Versandt an nah gelegenen Knoten erzielt werden. So verblasst das Signal bevor es einen weit entfernten Knoten erreicht und wird nicht mehr registriert. Dadurch werden Leerlaufzei- ten reduziert und in Folge dessen der Datendurchsatz erhöht. Zudem werden durch die minimale Reichweitenanpassung undder vermeidung von Kollisio- nen der Energieverbrauch gesenkt. Als Nachteil wird gerade durch diesen Handshake zusätzlicher Overhead erzeugt. Aber die geringeren Leerlaufzei-
  24. 24. 20 2. Grundlagen ten kompensieren diesen Faktor und führen , wie eben schon erwähnt zu einem höheren Datendurchsatz. Abbildung 2.7.: Handshake zwischen Knoten A und B [MoSt06] Abbildung 2.8.: RTS von Knoten C kollidiert hier mit einem Datenpaket von Knoten A [MoSt06] Eine modifizierte Version von MACA ist MACAW. MACAW nutzt wie MA- CA die RTS-CTS-DATA-Sequenz für den Datenaustausch. Wie man anhand Abbildung 2.9 erkennt, sind keinerlei Bestätigungspakete ACK oder NACK in den Ablauf involviert. Diese Aufgabe übernehmen übergeordnete Schich- ten, was jedoch sehr zuverlässige Verbindungen erfordert. Diese können bei der UAN wiederum schwer gewährleistet werden und daher ist dieses Proto- koll für die akustische Datenübertragung nicht zu präferieren. Floor Acquisition Multiple Access (FAMA) Das FAMA Protokoll nützt eine Trägerwellenerkennung zur Kollisionsvermei- dung, wie auch CSMA und erweitert dies noch mit dem von MACA genutzten Handshake, um die zuvor erwähnten Szenarios zu vermeiden und zudem die hohe Latenz auszugleichen die in akustischen Netzwerken auftreten. Hohe Laufzeitverzögerung verhindern jedoch eine effektive Anwendung dieses Pro- tokolls für unsere Zwecke, da hierdurch die nötigen Pufferzeiten, damit alle Nachbarknoten nach der längst möglichen auftretenden Verzögerung, viel zu hohe Werte annehmen würden und somit der Datendurchsatz und auch die
  25. 25. 2.3. Verwandte Arbeiten und Herangehensweise 21 Abbildung 2.9.: Zeitüberschreitung eines RTS-Pakets und fehlerhafte RTS- Übermittlung [PrSo01] Latenz schlechte Werte einnehmen würden. Diese Pufferzeiten werden durch die Festlegung der Länge eine RTS auf mindestens der Laufzeitverzögerung im Netzwerk und einem CTS, dass länger als die doppelte Laufzeitverzöge- rung im Netzwerk addiert um die Zeitdauer der Signalverarbeitung in einem Knoten ist. Da jedoch viel zu große Metapakete gesendet werden müssen, um eine aktive Trägerwelle konstant im Übertragungskanal zur Kollisionsvermei- dung bei einer beabsichtigen Datenübertragung zu etablieren ist dieses noch nicht angepasste Protokoll für akustische Netzwerke nicht zu empfehlen. zu- dem erhöht es wie eben beschrieben die schon vorhandene Latenz durch die langen Metapakete zusätzlich! 2.3. Verwandte Arbeiten und Herangehensweise Bei der Konzeption eines akustischen Schwarmnetzwerkes haben wir uns zu aller erst mit der Akustik als solches auseinander setzten müssen und haben daher vor allem durch die Opencourseware-Vorlesung ’Physics III: Vibrati- ons and Waves’ [MIT13] , die von Prof. Walter Lewin gehalten wurde, die Grundlagen für die weitere Arbeit erarbeitet. Für die technische Konzeption wurde in der Planungsphase sodann [LeSW09] zu Rate gezogen. Nachdem die Grundlagen erlernt werden konnten, stellte sich die Frage, wo und in welchen Gebieten die Akustik schon zur Datenübertragung herange- zogen wurde. Für den terrestrischen Anwendungsbereich suchten wir fast vergebens, mit Ausnahme von Akustikkopplern, die während der Monopol- zeit von Bell in den USA als Workaround ihre Verwendung fanden, Infosound von Yamaha und kleineren Hobby-Projekten im DIY-Bereich, nach schon er- folgreich implementierten Projekt, die wir für unseren akustischen Schwarm hätten heranziehen können.
  26. 26. 22 2. Grundlagen Hierbei stellte sich natürlich die Frage, warum so wenige Arbeiten für die terrestrische akustische Datenübertragung bisher zu Stande kamen. Eine mögliche Erklärung könnten die folgenden Punkte bieten: 1. Elektromagnetische Wellen sind mit clight = 299.792.458m/s5 im Gegen- satz zu csound = 343, 2m/s einfach deutlich schneller und ermöglichen somit geringere Latenzen. Zudem sind wir Menschen für Akustik im Bereich zwischen Infra- und Ultraschall, somit zwischen 16 Hz und 20 kHz empfänglich, wodurch dieses Frequenzband für technische Anwendungen im Bereich der Da- tenübertragung ausscheidet und unsere nutzbare Bandbreite neben der durch Absorption, Richtungscharakteristik und Wellengröße eingeschränk- ten Bereich noch weiter verkleinert. 2. Bis zur Entwicklung von Piezo-Elementen war der Wirkungsgrad bei der Energieumwandlung von elektrische in Schall-Energie bei weniger als 1% bis maximal 50%6 im Gegensatz zu 80-95% die bei Piezo Schall- wandlern üblich sein können. 3. Der momentane Übertragungsstandard ist nun einmal auf elektroma- gnetische Wellen ausgelegt. Hierfür besteht auch schon eine geeignete Infrastruktur und Übertragungsmodule zur Verfügung. Somit sind wir darauf angewiesen andere Einsatzgebiete, als das von uns ausgewählte für weitere Untersuchungen heranzuziehen. Wir mussten daher das Hauptverbreitungsgebiet der akustischen Datenübertragung, dem Einsatz Unterwasser, als Ausgangspunkt für bereits vorhandene Forschungsergebnis- se zu rate ziehen. Hier fanden wir insbesondere in [SLMR05],[Stoj95],[Stoj96] und [StPr09] Informationen die für unseren Projektaufbau einfließen konn- ten. Die Ansätze der akustischen Unterwasser-Netzwerke haben jedoch die für uns entscheidende Unterschiede, dass sie mit dem Übertragungsmedium Was- ser mit höherer Dichte als Luft, csound = 1.482m/s und einer nicht mit Men- schen bevölkerten Umgebung arbeiten. Die noch geringere geringere Geschwin- digkeit von Schallwellen an Land erhöht nochmal die Problematik der La- tenzen und sorgt im Endeffekt für insgesamt geringere Datenraten. Zudem schließt das Vorhandensein von anderen Lebewesen mit anderen Hörschwel- len, wie Unterwasser andere Frequenzbänder für die Nutzung aus. Ansonsten sind der terrestrische und der Unterwassereinsatz miteinander ver- gleichbar und es können Lösungen und Erkenntnisse aus den UAN ange- wandt werden. Da wir eine Physical-Computing-Plattform für unseren Schwarm, wegen den schon in Kapitel 1 und Unterkapitel 3.3 erwähnten Vorteilen, verwenden woll- 5Geschwindigkeit für elektromagnetische Wellen im Medium Luft und nicht im Vakuum. 6mit Schallbündelung durch Trichter und Druckkammern. Siehe hierzu [LeSW09] S.424 und S.669
  27. 27. 2.3. Verwandte Arbeiten und Herangehensweise 23 ten, stand zu aller Erst die geeignete Auswahl einer Plattform zu Disposition. Nach sorgfältiger Analyse, entschieden uns für die Arduino-Plattform, was wir in Unterkapitel 4.1 noch genauer erläutern werden. Hierdurch hatten wir nun unsere Rechen- und Steuereinrichtung für unser Projekt und mussten dieses noch um ein Kommunikationsmodul erweitern. Nach Betrachtung der üblichen Konstruktionen von akustischen Modems, entschlossen wir uns aus Zeit- und Vereinfachungsgründen ein fertiges Piezo- Transceiver-Bauteil für unser Modem zu nutzen, um uns den Aufbau folgen- der sonst notwendiger Module zu ersparen und nicht unseren Zeitrahmen zu sprengen: • Vorverstärker • Verstärker • Filter (Bandpassfilter) • Signalformerzeugung • Kalibrierung des Transceiver-Moduls auf die Resonanzfrequenz des Pie- zos • Saubere Signalformerzeugung Zudem entschlossen wir, uns auf eine einzige Frequenz, durch die Nutzung des SRF02 ist das bei uns 40kHz, für die Datenübertragung zu beschränken. Natürlich macht das unser System anfällig durch Störeinflüsse, da wir auf kei- ne alternative Frequenz wechseln können. So stellen Schallquellen wie zum Beispiel fahrende Eisenbahnen (Abrolltöne) oder Tastaturen(Klicken) , sollten bei unserer beabsichtigten Nutzung der Schwärme vernachlässigbar sein. Einen großen Vorteil den wir durch die Nutzung des SRF02 erhalten, ist das wir ein optimiertes Transceiver-Modul erhalten, das man zusätzlich zur Ab- standsmessung heranziehen kann. Dies ohne zusätzliches Modul und damit zusätzlich verbundenen Kosten und Energieverbrauch. Zudem kann man da- durch schon vorhandene Projekte, die gerade diesen Ultraschallsensor ver- wenden nachträglich mit einem Modem versehen und drahtlos Daten über- tragen. Folgende Nachteile handeln sind uns durch den SRF02 ein: • proprietäres Bauteil • Signalstärke und Frequenz sind fix • Von Hersteller vorgesehenes Zeitintervall für eine Abstandsmessung von 65ms, was ohne einen von uns genutzten Tweak7, zu einer Datenrate von nur um die 15 Bits führen würde. 7Um es schon vorweg zu nehmen: Wir haben uns der Eigenschaft des SRF02 bedient, der nach erfolgreicher Messung, die umgerechnet laut Datenblatt minimal 0,4ms betragen
  28. 28. 24 2. Grundlagen Somit ist festzuhalten, dass wir eine recht unorthodoxe Vorgehensweise ge- wählt haben, indem wir uns für ein schon fertiges Transceiver-Moduls für ein an sich anderes Einsatzgebiet entschieden haben. Dafür erhalten wir durch das Umfunktionieren ein 2 in 1 Modul, dass wir für unsere Zwecke nut- zen und anpassen können. Des weiteren steht uns dadurch ein kostengünsti- ger und sehr schneller Aufbau für einen Schwarm in Kombination mit einer Physical-Computing-Plattform zur Verfügung. Nach der Auswahl der Plattform und des Transceiver-moduls mussten dieses natürlich über eine geeignete Schnittstelle verbunden werden. Hier mussten wir uns zwischen I2C und RS232(TTL) entscheiden und diese Schnittstelle im- plementieren. Zudem mussten sämtliche Hardwarekomponenten per Steck- brett (Breadboard) für einen schnellen Prototypenaufbau verkabelt werden. Neben der hiermit nun kombinierten Hardware war die Erstellung von geeig- neten Sourcecode für die Steuerung des Mikrocontrollers und des Transceiver- moduls notwendig. Hierfür schrieben wir ein vereinfachtes Übertragungspro- tokoll für eine unidirektionales akustisches Modem in den Programmierspra- chen C8 und C++. Da die physische Schicht natürlich von einem Protokoll für den Mehrfach- zugriff innerhalb eines Mediums für den erfolgreichen Einsatz einer bidi- rektionalen Datenübertragung erweitert werden muss, entschlossen wir uns hier das in [MoSt07] beschriebene Slotted-FAMA-Protokoll anzuwenden. Die Gründe hierfür waren vornehmlich das dieses Protokoll für den akustischen Einsatz angepasst wurde, es sehr energiesparend, durch die Vermeidung von Kollisionen von Datenpaketen und für multi-hop ad hoc Netzwerke, wie es unser Schwarm ist, ausgelegt ist, scheint es prädestiniert für unsere Zwecke zu sein. In diesem Zusammenhang wollen wir das Protokoll nicht für Broadcasts nut- zen, sondern für die gezielte Datenweitergabe an einzelne Knoten in der di- rekten Nachbarschaft. Das kann für die Weitergabe von Sensordaten an einen Hauptsender mit elektromagnetischen Funkmodul oder für die Implementie- rung eines Synchronisierungsalgorithmus, der uns Timestamp-Funktionalität von Ereignissen und ein synchrones Arbeiten des Schwarms ermöglicht. Für reine Broadcast wäre das Slotted-FAMA mit seinem Handshake durch RTS > CTS > DATA9 ein viel zu großer Overhead für die geringen Bitraten in un- serem Netzwerk. Für Broadcasts sollten CS-Protokolle ohne Handshake zum Einsatz kommen. Das erhöht natürlich die Wahrscheinlichkeit für Kollisionen, macht jedoch für diese Art von Datenübertragungen mehr Sinn. darf, weitere Messungen ermöglicht. So nutzen wir diesen Fakt indem wir nach jedem Bit ein Trigger-High-Bit für den Sensor mit schicken, der einen erfolgreichen Messvorgang jeweils beendet. 8Die von uns verwendete Wire-Bibliothek der Arduino-Community, die für die Steuerung der I2C-Schnittstelle notwendig ist, wurde in C implementiert. 9RTS: Request to send; CTS: Clear to send; DATA: Daten.
  29. 29. 2.3. Verwandte Arbeiten und Herangehensweise 25 Das Slotted-FAMA-Protokoll (Floor Acquisition Multiple Access): In Unterkapitel 2.2.1 zeigten wir schon die Entwicklung von CSMA über MACA/MACAW zu FAMA auf und beschrieben ausführlich das FAMA- Protokoll und dessen Handshake-Mechanismus von RTS > CTS > DATA. Die Anpassung des FAMA-Protokolls an die akustische Datenübertragung kenn- zeichnet nun den Aufbau von Slotted-FAMA. Da das reine FAMA bei den hohen Latenzen die wir durch die Verwendung von akustischen Modem er- halten zu viel zu großen Paketen für RTS und CTS führen würde, was sich wiederum auf einen höheren Energieverbrauch der Knoten auswirken wür- de, erstellt das Protokoll Zeitintervalle, an deren Beginn nur gesendet werden darf. Hierdurch kann man die Paketgröße von RTS und CTS, die als Carri- er für den CS-Teil des Protokolls fungieren, auf ein Minimum heruntersetzen und erhält trotzdem eine kollisionsfreie Datenübertragung im Netzwerk. Ab- bildung 2.10 zeigt einen erfolgreichen Handshake des Slotted-FAMA. In die- ser Abbildung sieht man die einzelnen Slots, zu deren Beginn nur gesendet werden darf. Abbildung 2.10.: Erfolgreicher Handshake zwischen Knoten A und B, trotz für A verstecktem Knoten C [MoSt07] Die Größe der Slots berechnet sich wie folgt: tSlot = max(tLaufzeitverzögerung) + tÜbertragungszeit eines CTS (2.6) Vorteile des Slotted-FAMA-Protokolls sind: 1. Es ist den Bedingungen der akustischen Datenübertragung mit hohen Latenzen und geringer Bitrate angepasst. 2. Es vermeidet Paketkollisionen und senkt somit den Energieverbrauch der Knoten.
  30. 30. 26 2. Grundlagen Nachteile des Slotted-FAMA-Protokolls sind: 1. Synchronisierung ist notwendig, was aufwendig ist. 2. Durch das Handshake vor Beginn einer Datenübertragung entsteht ein nicht zu verachtender Overhead. Da Slotted-FAMA synchrone Knoten für seine Ausführung benötigt, waren wir gezwungen unser Netzwerk um eine solche Komponente zu erweitern. Dies führten wir durch die Konzeption eines Synchronisierungs-Algorithmus und der Hinzunahme von Sender-Knoten mit genaues zeitliches Takten über zusätzliche Module, wie GPS. Zur Evaluation unseres eigens für dieses Projekt entwickelten Algorithmus, entwickelten wir zusätzlich mit Python und dem Framework Pyside eine gra- fische Simulationsumgebung um diesen zu testen. In Unterkapitel 5 werden wir genauer auf den Algorithmus und die Simulationsumgebung eingehen. Mit der Implementierung des Slotted-FAMA-Protokolls in unsere zuvor er- stellten akustischen Modems steht nun eine kollisionsfreie Datenübertragung für unseren Schwarm zur Verfügung.
  31. 31. 3. Hardware In diesem Kapitel widmen wir uns der Hardware, mit der ein Aufbau ei- nes akustisch kommunizierenden Schwarms von Netzwerkknoten realisierbar wäre. Darunter gehören für jeden Knoten zum einen eine geeignete Rechen- und Steuereinheit, welche die eingehenden Daten verarbeiten und die ange- schlossenen Sensoren und Aktoren koordinieren kann, und zum anderen, die eben erwähnten Sensoren und Aktoren. Abbildung 3.1.: Darstellung eines Netzwerkknoten und dessen gestaffelten Aufbau. Zuerst befassen wir uns mit der Unterscheidung und Eingrenzung von Mi- krocontrollern und Mikroprozessoren. Im Anschluss gehen wir näher auf die verschiedenen Chip-Designs und deren Vor- und Nachteile ein und beleuch- ten im Detail die jeweils verwendeten Befehlssätze der Chips.
  32. 32. 28 3. Hardware Um einen schnellen und kostengünstigen Prototypenbau zu realisieren, wol- len wir jedoch nicht den puren Mikrocontroller, sondern eine geeignete Physical- Computing-Plattform zum Aufbau heranziehen. Daher wird in Unterkapitel 3.3 auf die momentan am weitesten verbreiteten Plattformen eingegangen. Hier werden vor allem, zur Einschätzung von Alternativen zu der Arduino- Plattform, die in diesem Projekt verwendet wurde, das Beaglebone (Black) und das Raspberry Pi ausführlich beschrieben. Jede Plattform hat seine Vor- züge und Nachteile, somit sollte bei jedem Projekt, zuvor analysiert werden, ob ein einzelner Mikrocontroller oder eine bestimmte Plattform den Anforde- rungen eher gerecht wird, beziehungsweise besser dafür geeignet sein sollte. Im Unterkapitel 3.4 widmen wir uns abschließend der noch zusätzlich not- wendigen Peripheriekomponenten, die nicht ohnehin schon durch eine Platt- form oder einem Mikrocontroller integriert sind. Dies gestaltet sich bei unse- rem Projekt recht überschaubar und besteht nur aus einer Komponente: dem Ultraschallsensor, der uns als akustisches Transceiver-Modul dienen wird. ’Ein Mikroprozessor ist ein Prozessor in sehr kleinem Maßstab, bei dem alle Bausteine des Prozessors auf einem Mikrochip (integrierter Schaltkreis, IC) vereinigt sind.’ [Wiki13c] 3.1. Mikroprozessor-Architekturen In Embedded Geräten, die mit einem Mikrocontroller (MCU) ausgestattet sind, findet man momentan vorherrschend die Prozessorarchitekuren ARM, AVR, wohingegen bei Desktop-PCs vor allem die Architektur x86 bevorzugt wird. Dies liegt zum einen an der unterschiedlichen Leistungsaufnahme der zwei Architekturen, als auch an der unterschiedlich notwendigen Flexibilität der Programmierung der jeweiligen Einsatzgebiete der Geräte. Ein Trockner muss nun mal die immer gleichen Aufgaben erledigen, im Vergleich zu einem Desktop-PC der sowohl E-Mail-Versand, Bildbearbeitung, Surfen etc. ermög- lichen sollte. Neben den generellen Aufbauunterschieden von ARM, AVR und x86, unter- scheiden sich die Gruppe, bestehend aus ARM, AVR von der Gruppe der x86 Prozessoren insoweit, dass sie einen einfachen Befehlssatz RISC im Gegensatz zu x86, der bei den heute geläufigen Modellen einen Hybriden CISC/RISC beherbergt, nutzen. Dieser Unterschied macht sich vor allem in der Leistungsaufnahme bemerk- bar, wodurch sie vor allem in eingebetteten Systemen Verwendung finden. 3.1.1. ARM ARM steht für Advanced RISC Machines, was somit auch gleich den Befehls- satz dieser momentanen 32-Bit-Chiparchitektur erläutert. In naher Zukunft
  33. 33. 3.1. Mikroprozessor-Architekturen 29 Abbildung 3.2.: (voraussichtlich 2014) soll das ARM Design noch um eine stärkere 64-Bit Va- riante ergänzt werden. Chips mit ARM-Architektur zeichnen sich, wie schon in Kapitel 3.1 erwähnt, durch eine geringe Leistungsaufnahme aus. Im Gegensatz zu den Atmel AVR können sich jedoch mal eine Von-Neumann- Architektur oder eine Harvard-Architektur beinhalten. 3.1.2. x86 Für dieses Projekt nicht wirklich als Option zu erwägen, der vollständig hal- ber erwähnt, ist die x86 Prozessorarchitektur, die in vielen Desktop-PCs ihre Heimat findet. Sie arbeitet momentan hauptsächlich mit 64-Bit-Registern und höheren Tak- tungsraten im GHz-Bereich und einer größeren Anzahl an Kernen, im Ver- gleich zu den ARM, geschweige denn den AVR Mikrocontroller-Prozessoren. Früher wurden hauptsächlich pure CISC Prozessoren hergestellt, heutzutage sind die Hybridmodelle mit CISC/RISC geläufiger. Diese Prozessoren haben einen RISC-Kern mit einer CISC-Emulationsschicht. Da die x86er Serien jedoch weit mehr Leistung aufnehmen und zudem deut- lich teurer als die ARM und AVR Prozessoren sind, werden wir diese Archi- tekturfamilie für die Verwendung in unserem Schwarm außer Betracht lassen, auch wenn x86 natürlich leicht zu programmieren, eine große Programmier- Bibliothekssammlung, eine große Community und flexiblere Eigenschaften bereitstellen. Erweitert man den Chip, auf dem der Mikroprozessor untergebracht ist, um weitere Peripherie, spricht man von einem Mikrocontroller. Hier sind meist
  34. 34. 30 3. Hardware RAM, Flash-Speicher, Bussysteme, ADC und vieles mehr untergebracht. Dies ermöglicht einen vielseitigen Einsatz des Mikrocontrollers als Miniaturrech- ner. 3.2. Mikrocontroller Zu beachten sei jedoch, dass ein Mikroprozessor für jede zu wählende Physical- Computing-Plattform notwendig ist, ein Mikrocontroller dagegen eine optio- nale Komponente darstellen kann. Ob der Mikroprozessor somit direkt, fest-gelötet beziehungsweise bestückt, oder indirekt über einen Mikrocontroller in einem Einplatinen-Rechner inte- griert ist, das ist von der jeweiligen Plattform abhängig. Abbildung 3.3.: Layeraufbau Wenn man jedoch statt der einfachen Erweiterbarkeit einer Physical-Computing- Plattform, die Kosten minimal halten will, sollte man zuerst analysieren, ob ein Mikrocontroller einer bestimmten Mikrocontroller-Familie, mit geeigneter integrierter Peripherie, ausreichend wäre. Die heute gängigen Mikrocontroller sind mit 4-, 8- 16- und 32-Bit-Prozessoren ausgestattet. Will man eine geringere Leistungsaufnahme erreichen, sollte man eine niedrigere Bit-Rate bevorzugen. Da sich jedoch 8- und 16-Bit-Prozessoren fertigungstechnisch kaum von den 32-Bit Varianten unterscheiden und daher fast gleichpreisig gefertigt werden können, werden momentan die 4-,8- und 16-Bit Varianten von den 32-Bit MCUs, mit ihrer höheren Rechenleistung, ver- drängt.
  35. 35. 3.2. Mikrocontroller 31 3.2.1. AVR ’Atmel AVR ist eine 8-Bit-Mikrocontroller-Familie des US-amerikanischen Her- stellers Atmel. Die Controller dieser Familie sind wegen ihres einfachen Auf- baus und ihrer leichten Programmierbarkeit auch bei Hobby-Anwendern weit verbreitet.’ [Wiki13b] Besonderheit der gängigen Atmel AVR (alle außer der 32-Bit Variante, die eine Harvard-Architektur mit Koppelfeld beinhaltet) ist das Schaltungskon- zept der Harvard-Architektur. Bei der Harvard-Architektur gibt es eine strik- te Trennung zwischen Daten- und Programm-Speicher, da beide über jeweils eigene voneinander getrennten Bussen erreichbar sind. Das hat den Vorteil, dass auf Daten und Programmcode gleichzeitig zugegriffen werden kann und nicht auf nacheinander folgenden Buszyklen verlegt werden muss. Die physikalische Trennung der beiden Speicherbereiche vereinfacht zudem das Programmcode schreibgeschützt genutzt werden kann, indem der separierte Speicherbereich als Flash-ROM ausgelegt wird. Bei den Atmel AVR sind der Programmcode und der Bootloader im Flash-ROM und die Laufzeitvariablen etc. getrennt im RAM untergebracht. Des weiteren ist die AVR Familie für höhere Programmiersprachen, wie C ausgelegt. Somit kann mit einem C-Compiler effizienter Code erzeugt werden und man ist nicht zwingend daran gebunden, selbst auf Assemblerebene zu programmieren. Da ein Atmel AVR jedoch den binären Programmcode direkt aus dem inte- grierten Flashspeicher bezieht, sind geringere Taktraten von Nöten, als wenn der Code in einem SRAM-Speicher vorliegen würde. Die neueren Atmel-32-Bit Mikrocontroller ähneln schon eher der ARM-Ar- chitektur und ergänzen die geringe Leistungsaufnahme mit einem höheren Datendurchsatz als bei den früheren Varianten. Um späteren Namensverwechslungen vorzubeugen, sei darauf hingewiesen, dass die Firma Atmel MCUs mit AVR eigener Prozessor-Architektur, als auch ARM-Prozessor Architekturen vertreibt. Durch den Namen Atmel auf einem MCU, kann somit nicht direkt auf die Atmel AVR Baureihe geschlossen wer- den. In der Peripherie sind: AD-Wandler mit 10 bit, 8- und 16-Bit-Timer mit Puls- weitenmodulation (PWM), SPI, I2C (TWI), UART, Analog-Komparator, Wat- chdog untergebracht. Wie schon in Kapitel 3.2 erwähnt, macht gerade die In- tegration von Peripheriestrukturen auf dem Mikrochip einen Mikrocontroller aus. Angeschlossen an eine 1,8 - 5,5 V Spannungsquelle und versehen mit einem externen Taktgeber ist der AVR Mikrocontroller schon out of the box betriebs- bereit.
  36. 36. 32 3. Hardware 3.3. Physical-Computing-Plattformen Da wir einen in seiner Funktion leicht erweiterbaren Prototypen-Schwarm erstellen und funktionstüchtig betreiben wollen, spielt die Auswahl einer ge- eigneten Physical-Computing-Plattform1 eine entscheidende Rolle. Optimierungen und der Austausch von Hardware und Softwarekomponenten können nach erfolgreicher Erstellung des Prototypen-Netzwerkes noch heran- gezogen werden. Abbildung 3.4.: Die folgenden Zielsetzungen begleiten die Auswahl einer geeigneten Platt- form: 1. Die vorgesehenen Algorithmen müssen mit dem zur Verfügung stehen- den Speicher und der Rechenleistung erzielbar sein. 2. Kostengünstig, da ein ganzer Schwarm in Planung ist und Funktiona- lität über Schwarmintelligenz erreicht werden soll und nicht über hohe Individualleistungen. 3. Geringer Energieverbrauch (da ein mobiler Einsatz vorgesehen ist). 4. Eine Erweiterung und Verbesserung der Funktionalität der erstellten Netzwerkknoten sollte möglichst leicht von statten gehen. 5. Die Dimensionierung der Hardware in möglichst geringer Größe. Dabei ist zu beachten, dass je nach verwendeter Prozessorarchitektur un- terschiedliche Speicherbereiche zur Verfügung stehen. So ist bei der Von- Neumann-Architektur, die schon in 3.2.1 erwähnt wurde, ein gemeinsamer Speicher für die Unterbringung des auszuführenden Programms, sowie für 1Für weitere Informationen siehe [SLMR05].
  37. 37. 3.3. Physical-Computing-Plattformen 33 die zu speichernden statischen Variablen, dem Stack und Heap vorhanden. Somit muss dementsprechend die Größe des gemeinsamen Speichers ausge- wählt werden. Bei der Harvard-Architektur wiederum liegt der auszuführende Binärcode in einem separaten ROM-Bereich und statische Variablen, Stack und Heap im RAM. Hier muss auf zwei Speicherbereiche bei der Dimensionierung geachtet werden. Egal ob Harvard- oder ’Princeton-Architektur’2 gewählt wurde, ist zudem ein EEPROM vorhanden, können statische Variablen, hier vor allem String- Konstanten, in den Langzeitspeicher ausgelagert werden und schaffen somit Platz für Stack und Heap. Somit hat auch der EEPROM Einfluss auf das Spei- chervermögen für bestimmte Programm-Variablen und kann als Erweiterung des RAM angesehen werden und sollte daher mit beachtet werden. Zudem kann abschließend gesagt werden, dass durch den Erfolg der in den folgenden Unterkapiteln beschriebenen Physical-Computing-Plattformen, auf Open Source Basis (sei es unter GPL und/oder LGPL)3, und einer wachsenden DIY-Mentalität4, in immer kürzeren Zeitintervallen ähnliche oder adaptierte Plattformen entstehen. Diese schaffen es meist bis hin zur Massenproduk- tion, durch Crowdfounding-Webseiten, wie Kickstarter oder Indiegogo. Daher sollte in regelmäßigen Abständen bzw. nach Fertigstellung des Prototypen- Schwarms überprüft werden, ob nicht eine neue und bessere Möglichkeit für die Realisierung eines ad hoc Netzwerk-Schwarms möglich wäre. Abbildung 3.5 zeigt die verschiedenen Plattformen, inklusiver einer weiteren Variante, dem Arduino-Due, bei der Arduino-Plattform. Wie ersichtlich wird sind die Größenverhältnisse nicht allzu unterschiedlich, jedoch die Ausstat- tung mit Pins und unterschiedlicher Peripherie fällt einem sofort auf. 3.3.1. Arduino Was ist ein Arduino? Die Definition ist sogar dem Team um das Projekt mit der Zeit immer schwerer gefallen, als dieses stets populärer wurde und sich durch das Open Source Prinzip bei der Hard- und Software zunehmend Klone und Arduino-Derivate entwickelten. So beschlossen sie das Logo und den Namen rechtlich zu schützen. In ihrem Internetblog 5 geben sie die folgenden Punkte für die Eingrenzung eines offiziellen Arduino an: • es wird direkt von der offiziellen Arduino IDE unterstützt 2Als Randnotiz: Von Neumann war Professor in Princeton. 3Eine schöne Übersicht über die verschiedenen Lizenzen erhält man durch [BuDH13] 4Siehe hierzu [KuPa10]. 5Den genauen Blogeintrag findet man in: [Banz13]
  38. 38. 34 3. Hardware Abbildung 3.5.: Vergleich von Größe und Layout von: Raspberry Pi Model- B(links oben), Arduino Uno Rev 3.0 (rechts oben), Beaglebone Black (links unten) und Arduino Due (rechts unten) Abbildung 3.6.: Hier ist das Arduino Uno Rev 3.0 zu sehen.
  39. 39. 3.3. Physical-Computing-Plattformen 35 • es folgt dem standardisierten Arduino Layout6 • es ist geeignet auf ihrer Webseite dokumentiert • es trägt den Namen ’Arduino’ und das Logo • es wird durch autorisierte Hersteller produziert Wir erwähnen diesen Sachverhalt, da für die Konzeption und Implementie- rung eines eigenen Arduino-Plattform-Derivats, je nach gewählter Funktiona- lität und Komfortverhalten, nur wenige Komponenten erforderlich sein müs- sen. Somit gehört zu einer Arduino-Plattform ein unterstützter Mikrocontroller. Dieser hat an sich einen eigenen Arduino-Bootloader für die schnelle und un- komplizierte Übertragung von Binärcode, mittels serieller Schnittstelle inte- griert. Um Speicherplatz zu sparen und/oder den Startvorgang des Mikro- controllers zu beschleunigen, kann dieser jedoch weggelassen und der Binär- code per externen ISP jedes Mal frisch aufgespielt werden. Das wahre Herz, neben dem jeweiligen genutzten Mikroprozessor der Platt- form, ist die Bibliothekensammlung, die von der Arduino-Community be- reit gestellt wird. Dadurch können schnell und unkompliziert viele Funktio- nen, ohne eigene Assemblerprogrammierung, somit unter Verwendung einer Hochsprache, eingebettet und programmiert werden. Daher empfiehlt es sich beim Aufbau eines eigenen Arduinos diese zu verwenden, jedoch auch diese sind nicht zwingend notwendig. Legt man nun nicht besonderen Wert auf eine genaue Taktung7 könnte man sogar einen externen Taktgeber beim eigenen Aufbau außen vor lassen und muss sich nur noch um eine geregelte Stromversorgung mittels Spannungs- regler, um für eine konstante Versorgungsspannung zu sorgen. Für komfortables Arbeiten mit dem Mikrocontroller empfiehlt es sich noch eine Status-LED und einen RESET-Schalter zu integrieren. Auch diese sind optional. Nun hätte man im Grunde genommen seine eigene Arduino-Plattform. Eine andere Möglichkeit wäre, die freien Leiterplatten- und Schaltkreis- Layouts, welche die Arduino-Community in Form von Eagle8-Dateien zur Verfügung stellt, für eine eigene Ätzung der Leiterbahnen und zur Bestückung zu verwenden. Da man jedoch mehr Peripherie, leichte Upgrade-Möglichkeit durch das Ardu- 6Momentan ist das die Revision 3.0 7So haben die AVR-Familie z.B. einen internen Taktgeber. Dieser ist nicht besonders genau, ist in manchen Fällen jedoch ausreichend. 8CAD-Software für das Leiterplatten-Design
  40. 40. 36 3. Hardware ino-Shield-Layout und vieles mehr haben möchte, empfiehlt sich für den ge- nerellen Aufbau eines flexiblen Projektes schon fertige Arduino-Boards her- anzuziehen. So ist beispielsweise ein USB-to-Serial-Konverter, mit dem man bequemen den Flash-ROMs Programmieren kann, in der Arduino-Plattform vorhanden und erspart uns einen zusätzlichen anzuschließenden ISP9. Tabelle 3.1 zeigt eine aktuelle Übersicht über die zur Verfügung stehenden Varianten der Physical-Computing-Plattform Arduino. Das standardisierte Platinendesign der Arduino-Plattform, ermöglicht eine schnelle und platzsparende Erweiterungsmöglichkeit mit verschiedensten zu- sätzlichen Modulen. So sorgen aufsteckbare Platinen, den sogenannten Shields, die entweder für den Formfaktor des Arduino-Mega oder des kleineren Arduino-Uno ange- passt sind, für eine schnelle und einfache Funktionserweiterung der jeweiligen Plattform-Variante. Hierbei ist zu beachten, dass die I/O-Pins des Arduino- Due nur für Shields mit 3,3V, im Gegensatz zu den anderen Boards, die für 3,3V und 5V konzipiert sind.10 Neben der einfachen Variante mittels Stecksystem die Plattform zu erweitern, bietet das System zudem die Möglichkeit auf die folgenden Schnittstellen und Bussysteme: USB, SPI, ICSP und I2C11 zuzugreifen und hierdurch nachzu- rüsten. Auf die eben erwähnten Schnittstellen und Bussysteme werden wir in Kapitel 3.4 näher eingehen. Auch wir haben von der Möglichkeit Gebrauch gemacht, unsere Schwarm- knoten durch die Verwendung des I2C-Bussystemes für den Anschluss ei- nes Ultraschall-Transceiver-Moduls mit zusätzlichen kleinen Mikrocontroller- Board, zu erweitern. Ein weiteres Beispiel für eine Funktionserweiterung, wäre die Möglichkeit unser System, mit dem gerade bei Kickstarter angelaufenen optischen Erken- nungssensor mit den bereitgestellten Schnittstellen: UART, SPI, I2C; der Car- negie Mellon University, einzubinden.12 Zusätzliche Funktionalitäten können auch per Software, durch Nutzung von der Arduino-Communiy erzeugten Programmierbibliotheken, die es inzwi- schen in großer Menge gibt, in ein Projekt integriert werden. So erhält man zum Beispiel durch die Timer1-Bibliothek, ohne in die Registerprogrammierung und hier vor allem den Counter/Timer-Registern und den jeweilig nötigen In- terrupts und Prescaler einzutauchen, die Möglichkeit sehr genaue zeit-basierte 9Ein ISP ist eine Hardware für das Programmieren eines Mikrocontrollers 10Die komplette Übersicht über allen momentan verfügbaren Shields erhält man durch: http: //shieldlist.org/ 11Das Arduino-Mega hat zudem noch UART und das Arduino-Ethernet TWI zur Verfügung. 12Kickster-Projektseite für Pixy: http://www.kickstarter.com/projects/254449872/ pixy-cmucam5-a-fast-easy-to-use-vision-sensor
  41. 41. 3.3. Physical-Computing-Plattformen 37 Aktionen auszulösen. Dies wird durch den Zugriff auf einen der drei verfüg- baren internen Timern beim Arduino-Uno bewerkstelligt. Arduino MCU Be- triebs- span- nung Flash KiB EEPROM KiB SRAM KiB Dig. I/O Pins . . . mit PWM Anal. Ein- gän- ge Interfaces Abmessungen in mm Nano ATmega328 (8-bit) 5V 32 1 2 14 6 8 Mini-B, USB, I2C, SPI 43 × 18 Diecimila ATmega168 (8-bit) 5V 16 0.5 1 14 6 6 USB 68,6 × 53,3 Duemilanove ATmega168 (8-bit) 5V 16 0,5 1 14 6 6 USB,SPI, ICSP, I2C 68,6 × 53,3 Uno ATmega328 (8-bit) 5V 32 1 2 14 6 6 USB, SPI, ICSP, I2C 68,6 × 53,3 Ethernet ATmega328 (8-bit) 5V 32 1 2 14 4 6 Ethernet, SD card, SPI,TWI 68,6 × 53,3 Mega ATmega1280 (8-bit) 5V 128 4 8 54 14 16 USB, SPI, ICSP, I2C, UART 101,6 × 53,3 Mega2560 ATmega2560 (8-bit) 5V 256 4 8 54 14 16 USB, SPI, ICSP, I2C, 4 UART 101,6 × 53,3 Mega ADK ATmega2560 (8-bit) 5V 256 4 8 54 14 16 USB, SPI, ICSP, I2C, 4 UART 101,6 × 53,3 LilyPad ATmega168V oder ATmega328V (8-bit) 2,7 - 5,5V 16 0.5 1 14 6 6 USB (FTDI Basic Breakout requ. ) ø 50 BT (Bluetooth) ATmega328 (8-bit) 5V 32 1 2 14 4 6 Bluegiga WT11 Bluetooth, TWI, I2C, SPI 81,2 × 53,3 Leonardo ATmega32U4 (8-bit) 5V 32 1 2.5 20 7 12 USB, ICSP, TWI, I2C, 1 UART 68,6 × 53,3 Micro ATmega32U4 (8-bit) 5V 32 1 2.5 20 7 12 USB, ICSP, TWI, I2C, 1 UART 48,3 × 17,8 Esplora ATmega32U4 (8-bit) 5V 32 1 2.5 - - - Micro USB, ICSP, Tinkerkit Konnektoren, TFT- Konnektor(LCD- Display) Due AT91SAM3X8E (32-bit) 3,3V 512 - 96 54 12 12 USB, CAN, ICSP, 2 TWI, 2 I2C, 4 UART, 2 DAC 101,6 × 53,3 Tabelle 3.1.: Übersicht der Arduino Modelle [Wiki13a] 3.3.2. Raspberry Pi Im Gegensatz zu der zuvor vorgestellten Physical-Computing-Plattform Ar- duino, die mit einem Mikrocontroller ausgestattet ist, bedient sich das Raspberry- Pi eines 700 MHz ARM-Prozessors mit ausgelagerten RAM in der Größe von 256MB/512MB und mehreren GB an Programmspeicher durch Einbinden ei- ner Speicherkarte. Die integrierte Peripherie und weitere Spezifikationen kön- nen der Tabelle 3.2 entnommen werden. Vergleicht man schon alleine die Größe des Arbeitsspeichers und der Rechen- leistung der CPU des Raspberry Pi, mit deren der momentan verfügbaren
  42. 42. 38 3. Hardware Arduino-Varianten, fällt das Raspberry Pi mit seinen deutlich höheren Werten auf. Das muss jedoch nicht zwangsläufig bedeuten, dass diese Plattform die geeignetere Wahl für I/O-Anwendungen darstellt, da hier im Vergleich zu ei- nem Mikrocontroller noch ein Betriebssystem im Hintergrund seine Routinen und Prozesse ablaufen lässt und die Ausführung dementsprechend verlang- samt. Gerade bei Echtzeitanwendungen stößt man hier an die Grenzen des Raspberry Pi. Durch Echtzeit-Betriebssysteme wie beispielsweise RISC OS13, kann die Plattform zwar in die Richtung eines Mikrocontrollers verschoben werden, ein Arduino ist trotz alledem noch optimierter für diese Art von An- wendungen. Abbildung 3.7.: Raspberry Pi Model-B Diesen Sachverhalt bringen Matt Richardson und Shawn Wallace in [RiWa12] schön auf den Punkt: When you have a problem that requires exact control in real time, such as a controller for a 3D printer. [...] Raspbian is not a Real Time operating system, and programs can’t necessarily depend on the same “instruction per clock cycles” rigor of a microcontroller Zudem arbeiten die Pins des Raspberry Pi mit 3,3V und tolerieren keine 5V, was einige Peripheriekomponenten jedoch benötigen. Dafür hat man im Gegensatz zu der Arduino-Plattform ein Betriebssystem sei- ner Wahl, das auf der verwendeten ARM-Architektur aufbaut, zur Verfügung 13Hier wird ein Echtzeitkernel innerhalb eines OS-Kernels ausgeführt und sorgt für die zeit- lich genauere Ausführung und Steuerung.
  43. 43. 3.3. Physical-Computing-Plattformen 39 und hat zudem deutlich höhere Speicherwerte und eine höhere Rechenleis- tung. So lange man keine Echtzeit Anwendungen verwenden will, kann man die GPIO-Pins problemlos zum Steuern von LEDs und dergleichen gebrauchen. Außerdem können über die zusätzlichen Schnittstellen: SPI, I2C und UART viele Module integriert werden. In unserem Fall wäre das der SRF02-Ultraschall- Abstandmesser, der durch I2C mit der Plattform verbunden wurde. Im Unterschied zur Arduino-Plattform ist das Raspberry Pi daher eher als Miniatur-PC anzusehen. So ermöglichen Audio- und Grafikausgänge (HDMI und Video-OUT), sowie USB-Eingänge für Tastatur und Maus einen Einsatz im Desktop-PC-Bereich. Nimmt man zudem das Modell B, so erhält man zusätzlich einen integrier- ten Ethernet-Controller, wodurch man diese Plattform in ein kabelgebunde- nes LAN einbinden kann. So wird über LAN oder WLAN (per WLAN Stick über USB) das Raspberry Pi zu einem Teil des ’Internet of things’14. Diese Netzwerk-Funktionalitäten besitzt das Arduino, abgesehen von dem Arduino- Ethernet und Arduino-YÚN nicht out of the box, diese können jedoch inzwi- schen leicht auf Basis von Arduino eigens gefertigten Shields erreicht wer- den15. Zudem kann, wie auch die Arduino-Plattform, das Raspberry Pi, den für Sen- sornetzwerke oft genutzten ZIGBEE-Stack 16, verwenden. Dafür ist die Platt- form mit einer Zusatzplatine mit dem Namen RaspBee, welche bei Arduino Xbee genannt wird, zu ergänzen. Im Gegensatz zu den Shields der Arduino Plattform haben die aufsteckbaren Module auf den verfügbaren Pins hier keinen speziellen Namen, sondern wer- den einfach als Erweiterungsplatinen bezeichnet. Hier gibt es momentan noch keine allzu große Auswahl, wenn man im Gegensatz die Arduino-Plattform heranzieht. An dieser Stelle weisen wir besonders auf zwei Module hin: Das Gertboard und die Arduino Shield Bridge. Gertboard: Das Gertboard ist eine I/O-Erweiterungsplatine, die das Raspber- ry Pi um einen ATmega Mikrocontroller bereichert und somit Echtzeitanwen- dungen durchführbar macht. Arduino Shield Bridge: Die Arduino Shield Bridge ist ein Adapter, mittels dessen man Arduino Shields direkt auf dem Raspberry Pi nutzen kann. Des weiteren kann über die Bibliothek arduPi ursprünglich nativer Arduino Code für das Raspberry Pi kompiliert werden. Als OS laufen die verschiedensten Linux-Distributionen, die in Tabelle 3.2 nä- her betrachtet werden können. Die am gängigsten genutzte Distribution ist 14Die Bezeichnung für embedded Geräte mit Internetanschluss 15Das wären insbesondere:Arduino WiFi Shield,Arduino Wireless SD Shield,Arduino WiFi Shield,Arduino Ethernet Shield und Arduino GSM Shield. 16Standardisierter Protokollstapel nach IEEE 802.15.4
  44. 44. 40 3. Hardware Abbildung 3.8.: XBee-Shield aufgesteckt auf einer Arduino Shield Bridge, die wiederum auf einem Raspberry Pi aufgesteckt ist. Schön zu erkennen, ist die unkomplizierte und kompakte Integration der Module. [chac13] hierfür Raspedian, ein Debian-Derivat. Durch die Verwendung von GNU/Li- nux stehen somit natürlich auch die Repositories der jeweiligen Distributionen zur Verfügung und können je nach Belieben die Funktionalität der Plattform erweitern. Ein schnelles sudo apt-get install <Paket> in Raspedian zum Beispiel, ermöglicht auf schnelle und unkomplizierte Art und Weise Bibliotheken, An- wendungen inklusive benötigter Abhängigkeiten zu installieren. Betrachtet man die Leistungsaufnahme, so wird aus Tabelle 3.2 ersichtlich, dass wir im Gegensatz zum Arduino17 eine vielfach höhere Leistungsauf- nahme der puren Leiterplatte ohne zusätzlicher angesteckter Peripherie zu beachten haben. Beim Thema Lizenzen und verfügbaren Platinenlayouts sieht es bei dieser Plattform ein wenig anders als bei Arduino, mit seinem puren Open Source Charakter, aus. Für das Raspberry Pi sind nur insoweit quelloffene Informa- tionen bekannt, so dass Erweiterungsmodule dadurch erstellt werden können und man einen Überblick über dessen Aufbau erhält. Hier wurde nicht be- absichtigt, dass man die Platine selbst erstellen kann, um damit Klone und Varianten fertigen zu können. Vergleicht man zudem die Preise der zwei Plattformen miteinander, so liegt momentan das Raspberry Pi bei ca. 39 EUR18 und das Arduino Uno bei ca. 23,80 EUR und ist somit fast doppelt so teuer. Dafür bekommt man jedoch auch einen kleinen Miniaturrechner. Reichen dagegen die Spezifikationen für das Arduino Uno, sollte man sich die Frage stellen, warum man eine dop- pelt so teure und mit einer höheren Leistungsaufnahme versehene Plattform auswählen möchte. So kann abschließend als Fazit gesagt werden, dass das Raspberry Pi ein ande- res Anwendungsspektrum, im Vergleich zum Arduino abdeckt. Das Raspber- ry Pi ist nun einmal eher ein Miniaturrechner, als ein Mikrocontroller. Beide 17Arduino Uno: Leistungsaufnahme bei 7-12V liegt bei unter <1 Watt für das reine Board. 18inklusive Mehrwertsteuer
  45. 45. 3.3. Physical-Computing-Plattformen 41 verfügen sie jedoch über Schnittstellen wie I2C und können somit mit anderen Modulen oder direkt über ihre Pins mit anderer Peripherie und der Umwelt agieren und zeichnen sich somit als Physical-Computing-Plattformen aus. Modell A Modell B Preis (inkl. MwSt): 27 EUR 34 EUR Größe: Kreditkartengröße 85,60 mm × 53,98 mm × 17 mm Kreditkartengröße 85,60 mm × 53,98 mm × 17 mm SoC Broadcom BCM2835 Broadcom BCM2835 CPU: VIA ARM1176JZF-S (700 MHz) VIA ARM1176JZF-S (700 MHz) GPU: Broadcom VideoCore IV Broadcom VideoCore IV Arbeitsspeicher (SDRAM): 256 MB 512 MB (bis Oktober 2012 256 MB) USB 2.0 Anschlüsse: 1 2 (über integrierten Hub) Videoausgabe: FBAS, HDMI FBAS, HDMI Tonausgabe: 3,5 mm-Klinkenstecker (analog), HDMI (digital) 3,5 mm-Klinkenstecker (analog), HDMI (digital) Nicht-flüchtiger Speicher: SD (SDHC und SDXC)/MMC/SDIO- Kartenleser SD (SDHC und SDXC)/MMC/SDIO- Kartenleser Netzwerk: – 10/100 MBit Ethernet-Controller (LAN9512 des Herstellers Han Run) Schnittstellen: Bis zu 16 GPIO-Pins, SPI, I2C,UART Bis zu 16 GPIO-Pins, SPI, I2C,UART Echtzeituhr: – – Leistungsaufnahme: 5 V, 500 mA (2,5 Watt) 5 V, 700 mA (3,5 Watt) Stromversorgung: 5 V Micro-USB-Anschluss (Micro-B), alternativ 4 × AA-Batterien 5 V Micro-USB-Anschluss (Micro-B), alternativ 4 × AA-Batterien Betriebssysteme: Arch Linux ARM, Debian GNU/Linux, Fedora, FreeBSD, NetBSD, Plan 9, Raspbian OS, RISC OS, Slackware Linux Arch Linux ARM, Debian GNU/Linux, Fedora, FreeBSD, NetBSD, Plan 9, Raspbian OS, RISC OS, Slackware Linux Tabelle 3.2.: Modellübersicht Raspberry Pi [Wiki13e][Wiki13f]
  46. 46. 42 3. Hardware 3.3.3. Beaglebone (Black) Das Beaglebone Black ist ein Einplatinencomputer der Firma Texas Instru- ments mit Open Source Hardwarekomponenten19. Somit kann das Platinen- layout frei eingesehen werden. Es liegt in den Varianten Beaglebone und Beag- lebone Black vor. Die Variante Beaglebone wird jedoch nicht mehr produziert. Abbildung 3.9.: Beaglebone Black Bei dieser Plattform ist besonders hervorzuheben, dass keinerlei Lizenzen existieren. Das Beaglebone (Black) stellt im Vergleich zu dem größeren zuvor erschie- nenen Einplatinencomputer BeagleBoard eine größere Erweiterbarkeit und Mikrocontroller-Funktionalitäten bereit. Wenn man Abbildung 3.9 betrachtet, fällt einem dabei sofort auf, dass die Plattform über eine Fülle von Pins verfügt und RAM und CPU separat vor- liegen. Es ist quasi eine Kombination von Arduino und Raspberry Pi. So sind auf der Platine ein AM335x 720MHz ARM Cortex-A8 beziehungsweise ein AM335x 1GHz ARM Cortex-A8 verbaut, was für viel Rechenleistung sorgt. Der Arbeitsspeicher ist mit 256MB DDR2 / 512 MB DDR3L auch für viele Anwendungen im Vergleich zur Arduino-Plattform sehr hoch dimensioniert. Die Plattform ist mit zwei programmierbaren Echtzeit-Einheiten (PRU) ver- sehen, die im Vergleich zum Raspberry Pi neue Anwendungsgebiete erschließt. Durch diese 2x PRU 32-bit RISC CPUs / 2x PRU 32-bit Mikrocontroller, wird aus dem Miniaturrechner ein System mit Echtzeitfunktionalität, wie bei ei- nem Arduino. Diese zwei programmierbaren Echtzeit-Einheiten machen da- 19Bis auf die PowerVR-GPU.
  47. 47. 3.3. Physical-Computing-Plattformen 43 mit Projekte realisierbar, an denen ein Raspberry Pi bei zeitkritischen Anwen- dungen scheitern würde. Interessant hierbei ist, dass die zwei PRUs auf einen gemeinsamen Bus zusammen mit einem Interrupt-Controller zugreifen. So ist es möglich, dass die zwei PRUs komplett unabhängig voneinander oder auch gemeinsam agieren. Durch den zusätzlichen Interrupt-Controller wird außer- dem eine Kommunikation auf Geräteebene in beide Richtungen ermöglicht. So kann die Host-CPU mit in den jeweiligen Programmablauf und umgekehrt integriert werden. Abbildung 3.10.: Aufbau des PRU-Subsystems[Inst13] Die Plattform stellt neben weiteren, die für uns interessanten Schnittstellen: 69 GPIO-Pins, McASP, CAN0, SPI1, I2C, UART0 und TTL bereit. Somit ist auch hier eine Erweiterbarkeit mit weiteren Modulen möglich. Auch ein Client und ein Host Port sind für die Kommunikation mit weiterer Peripherie vorhanden, was das System wie das Raspberry Pi, flexibler macht. Um es in das ’Internet of Things’ integrieren zu können, gibt es die Mög- lichkeit über WLAN-Stick oder direkt über den integrierten Ethernet-Port mit dem jeweiligen Netzwerk zu interagieren. Die Leistungsaufnahme ohne zusätzliche Komponenten liegt bei max. 2,4 Watt / 2,5 Watt, was wiederum um ein vielfaches über dem Arduino Uno liegt. Der Preis für ein Beaglebone Black liegt momentan bei circa 47 EUR, und ist somit nicht wesentlich teurer als ein Raspberry Pi. Entscheidend hier bei der Auswahl ist der genaue Verwendungszweck und die benötigten Ein- und Aus- gänge, wie USB, Video-Out, ecetara, sowie die vorhandenen Erweiterungspla- tinen und Bibliotheken. Da wir es hier mit einem Einplatinen-Computer mit PRUs zu tun haben und nicht mit einem reinen Mikrocontroller, verwendet das Hauptsystem ein Be- triebssystem. Davon abgekoppelt oder eingebunden arbeiten die PRUs ihren Programmcode ab. Das OS kann je nach Version auf einer Micro-SD Karte
  48. 48. 44 3. Hardware oder beim Beaglebone Black auch auf dem internen 2GB Flash Speicher aus- geführt werden. Folgende Linux20 OS werden unterstützt: So wird neben Angström Linux, das zu Beaglebone (Black) kompatibel ist, auch Android und Ubuntu unterstützt. In dem folgenden Absatz, werden wir uns nun noch detaillierter das neuere Beaglebone Black anschauen. Das Beaglebone Black ist ein Upgrade des Beaglebones. Es besitzt einen zu- sätzlichen internen 2GB 8-Bit eMMC Flash Speicher und einen NEON Floating- Point Accelerator. Gerade durch verbesserte Handhabung von Fließkomma- zahlen, können hier interessante Anwendungen geschrieben werden, die trotz alledem noch schnell ausführbar sein sollten. Für unser Projekt jetzt weniger interessant, jedoch dennoch vorhanden, ist eine Micro-HDMI-Schnittstelle für die Bildausgabe. Weitere Spezifikationen dieser Physical-Computing-Plattform können der Ta- belle 3.3 entnommen werden. Erweiterungsmodule - Capes: Beim Beaglebone (Black) werden die Erweiterungsplatinen als Capes21 be- zeichnet. Wie bei Arduino kann so im Baukastenstecksystem schnell und ein- fach mehr Funktionalität hinzugefügt werden. So stellt beispielsweise das Be- agleBone TiWi-5E-Cape 2.4 and 5 GHz IEEE 802.11 a/b/g/n und Bluetooth 4.0 für diese Plattform bereit. In Abbildung 3.11 sieht man exemplarisches dieses Cape. Abbildung 3.11.: Cape: BeagleBone TiWi-5E [http13a] 20Wir haben hier mit Absicht nicht GNU/Linux geschrieben, da Android recht wenig mit GNU im Gegensatz zu zum Beispiel Ubuntu zu tun hat. 21In [http13a] kann eine Übersicht über die momentan verfügbaren Erweiterungsmodule gefunden werden.
  49. 49. 3.3. Physical-Computing-Plattformen 45 Tabelle 3.3.: Spezifikation des Beagleboard Black [http13b]
  50. 50. 46 3. Hardware Abschließend kann diese Physical-Computing-Plattform wie folgt charak- terisiert werden: Das Beaglebone (Black) ist für die Entwicklung und für das Prototyping ei- ne optimale Plattform. Sie hat viele Schnittstellen in vielfachen Variationen, besitzt mit 700MHz / 1GB und 256 MB / 512 MB viel Raum für aufwendi- ge Programme und ist durch die zwei integrierten PRUs in der Lage Echt- zeitfunktionalität bereitstellt. Nur wenn man den Energieverbrauch mit dem eines Arduino vergleicht, fallen die für bestimmte Projekte unnötigen inte- grierten Peripheriekomponenten, mit ihrer zusätzlichen Leistungsaufnahme, ins Gewicht. Diese erschweren den mobilen Einsatz mittels Batterie bezie- hungsweise Akkumulatoren. 3.4. Peripherie Die Liste der Peripheriemodule, die wir für unseren akustisches Schwarm- netzwerk benötigen, hält sich mit einem einzigen Modul, einem Ultraschall- Sensor, in Grenzen. Abbildung 3.12.: Nachdem wir uns festgelegt haben, einen Ultraschall-Transceiver als fertiges Modul zu beschaffen, um zeitaufwendige Kalibrierungen zu vermeiden und zudem einen akustischen Schwarm in möglichst geringer Zeit aufbauen zu können, entschieden wir uns für den Ultraschallsensor SRF02 der Firma De- vantech, mit integriertem Transceiver. In Kapitel 4 gehen wir genauer auf die Beweggründe hierfür ein. Wir werden nun in Folge detaillierter auf die SRF-Reihe von Ultraschallsenso- ren eingehen, um anhand derer den Begriff der Richtungscharakteristik zu erläutern, die nötigen Grundlagen der Ultraschalltechnik und die Spezifika- tionen für den späteren Umgang mit dem SRF02 kennenzulernen.
  51. 51. 3.4. Peripherie 47 Die Namensgebung Ultraschallsensor ist an sich irreführend, da ein Ultra- schallsensor kein reiner Empfänger, sondern auch einen Sender darstellt und somit auch in die Gruppe der Aktuatoren einzuordnen ist. Kernstück dieses Ultraschallsensors ist der Piezo-Schallwandler, ein Piezo22-Keramik-Plättchen, mit an die Richtungscharakteristik und Frequenz angepassten Maßen. Abbildung 3.13.: Halbstreuwinkel zwischen zwei -6 dB Punkten eines Ultra- schallwandlers [Olym06] Die Richtungscharakteristik kann, laut [Olym06] wie folgt für den Halbstreu- winkel zwischen zwei -6 dB Punkten, der in Abbildung 3.13 veranschaulicht wird, berechnet werden: f = Frequenz [Hz] α 2 = Halbstreuwinkel zwischen zwei -6 dB Punkten [◦] D = Durchmesser des Piezoplättchens [m] c = Schallgeschwindigkeit[m/s] sin( α 2 ) = 0, 515c 0, 514c f D (3.1) Somit ist der Öffnungswinkel des Haupt-Strahls reziprok proportional zu f und/oder D. Dementsprechend kann die Richtungscharakteristik für einen größeren Winkelbereich durch Senkung der Frequenz und/oder Reduzierung des Durchmessers erreicht werden. Für λ ≥ D tendiert die Form zur Kreisbil- dung. Dies kann auch sehr schön in Abbildung 3.14 in Kombination mit Tabelle 22Auf S.110 in [WiHW11] wird der Piezo-Effekt wie folgt beschrieben: ’Der 1880 von Jacques und Pierre Curie entdeckte piezoelektrische Effekt besteht aus einer linearen elektrome- chanischen Wechselwirkung zwischen den mechanischen und den elektrischen Zustän- den in einem Kristall. Eine mechanische Deformation des Kristalls erzeugt eine zu dieser Deformation proportionale elektrische Ladung, die als elektrische Spannung abgegriffen werden kann (direkter piezo-elektrischer Effekt). Umgekehrt kann durch Anlegen einer elektrischen Spannung an den Kristall in diesem eine mechanische Deformation erzeugt werden (reziproker oder inverser piezoelektrischer Effekt). ’

×