BWP-SS19-01/Grob Design: Unterschied zwischen den Versionen

Aus Verteilte Systeme - Wiki
Zur Navigation springen Zur Suche springen
(Die Seite wurde neu angelegt: „== Hardware == == Software == Als Software wird Zephyr OS mit, in der folgenden Abbildung dargestellten, Tasks verwendet. Auch die Kommunikation zwischen den…“)
 
 
(29 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
 
== Hardware ==
 
== Hardware ==
  +
  +
Im Folgenden wird der Aufbau der Hardware als Block-Definition Diagramm dargestellt.
  +
  +
<table>
  +
{| Border=1 style="border-collapse:collapse; width: 800px;" cellpadding=10
  +
| SysML Diagramm
  +
| [[Datei:BWPSS1901_Sysml.PNG|1000px|right|Sysml_diagramm]]
  +
|-}
  +
</table>
   
 
== Software ==
 
== Software ==
   
  +
=== Allgemein ===
Als Software wird Zephyr OS mit, in der folgenden Abbildung dargestellten, Tasks verwendet. Auch die Kommunikation zwischen den Tasks ist hier dargestellt.
 
  +
  +
Als Software wird Zephyr OS mit folgenden Tasks verwendet.
  +
Sequenz-Diagramme:
   
 
<table>
 
<table>
 
{| Border=1 style="border-collapse:collapse; width: 800px;" cellpadding=10
 
{| Border=1 style="border-collapse:collapse; width: 800px;" cellpadding=10
  +
| Modul
| Sequenzdiagramm
 
  +
| gedachter Aufbau am Anfang des Projektes
| [[Datei:BWPSS1901_Sequenz.JPG|400px|right|Sequenzdiagramm]]
 
  +
| Änderungen, die während des Projektes nötig waren
  +
|-
  +
| Sequenz-Diagramm Main Control
  +
| [[Datei:BWPSS1901_Sequenz1.JPG|400px|right|Sequenzdiagramm Main Control]]
  +
| Keine Änderungen
  +
|-
  +
| Sequenz-Diagramm Coulomb Counter
  +
| [[Datei:BWPSS1901_Sequenz2.JPG|400px|right|Sequenzdiagramm Coulomb Counter]]
  +
| Der Coulomb-Counter hat zwar die gleiche Funktion, ist aber nicht mehr als externes Modul an den Feather angeschlossen sondern als Simulation in Software umgesetzt
  +
|-
  +
| Sequenz-Diagramm IMU
 
| [[Datei:BWPSS1901_Sequenz3.JPG|400px|right|Sequenzdiagramm IMU]]
  +
| Dieses Modul wurde weg gelassen
  +
|-
  +
| Sequenz-Diagramm Laser-/Ultraschallsensoren
  +
| [[Datei:BWPSS1901_Sequenz4.JPG|400px|right|Sequenzdiagramm Laser/Ultraschall]]
  +
| Keine Änderungen
  +
|-
  +
| Sequenz-Diagramm Engine
  +
| [[Datei:BWPSS1901_Sequenz5.JPG|400px|right|Sequenzdiagramm Engine]]
  +
| Die Errechnung der Reaktion über die IMU wurde weg gelassen
 
|-}
 
|-}
 
</table>
 
</table>
  +
  +
=== Einzelmodule ===
  +
  +
Im Folgenden werden die Einzelmodule grob beschrieben.
  +
  +
==== Energy Management System ====
  +
  +
  +
''Allgemein:''
  +
  +
Das Energy Management System verwendet den Coulomb-Counter zur Messung der Energie und beinhaltet Mechanismen, die den Energie-Eintrag und den Energie-Verbrauch überwachen.
  +
  +
Dabei soll sowohl der Akku-Stand überwacht werden als auch der Energie-Verbrauch der einzelnen Roboter-Bewegungen und Einzel-Berechnungen der jeweils anderen Module aufgezeichnet werden.
  +
  +
  +
''Funktionsweise:''
  +
  +
Das Energy Management System wird als Energiemessungs-Simulation realisiert. Hierfür werden 4 Pins verwendet. Von diesen 4 Pins werden zwei mit jeweils einer GPIO-Callback Funktion verbunden, die jeweils ein Register hochzählt. Der Trigger für das Hochzählen ist das Auftreten einer High Edge an dem jeweiligen Pin.
  +
Die anderen Zwei Pins werden von an einen gemeinsamen Timer getoggelt. Dabei wird innerhalb des Timers, abhängig von dem aktuellen State des Systems, entschieden, wie groß die Periodendauer des Signals ist.
  +
  +
Die Kommunikation zwischen Haupt-Steuerung und Energy Management System läuft über einen globalen Pointer auf eine Daten Struct, in der die momentane Aufgabe für das Energy Management System steht.
  +
  +
  +
''Vorausberechnung als mögliche Erweiterung des Projektes:''
  +
  +
Dieses Aufzeichnen der Berechnungen und Bewegungen soll im späteren Verlauf (Nicht Teil des Projektes) dazu verwendet werden können, um zu lernen wie viel Energie ein einzelner Ausführungs-Schritt benötigt,
  +
womit dann der Energieverbrauch von Ausführungs-Ketten im Voraus berechnet werden kann.
  +
  +
Diese Vorausberechnung soll wie folgt funktionieren:
  +
* Jede Bewegung und jede Berechnung wird einem State einer State-Maschine zugeordnet
  +
* Jedem State wird ein Mittelwert und eine Zähler-Variable gegeben
  +
* Bei der Ausführung eines States wird der Mittelwert mit folgender Formel aktualisiert und die Zähler-Variable wird hochgezählt
  +
  +
MW_neu_ = (MW_alt_ * N + X) / (N+1)
  +
  +
* Nun kann die Motorsteuerung eine Ausführungs-Kette bei dem Energie Management System anfragen und erhält die zusammenaddierten Mittelwerte zurückgeliefert
  +
* Zusammen mit dem Akku-Stand kann daraus errechnet werden, ob der Roboter noch genug Energie führt eine bestimmte Aufgabe hat.
  +
  +
==== Odometrie ====
  +
  +
''Algemein''<br>
  +
Die Odometrie stellt Funktionen bereit, die die angeschlossene Sensorik ansteuern und abfragen kann.
  +
  +
==== BLE und Logging ====
  +
  +
  +
''Allgemein:''<br>
  +
Das Bluetooth-Low-Energy-Modul verwendet das standardmäßig auf dem Feather vorhandene BLE.<br>
  +
Hierbei soll das Senden möglichst energiesparend geschehen. Deshalb wird hier auf eine energieaufwendige Bluetooth-Kopplung verzichtet und die Nachricht mittels einer Advertise-Nachricht versendet.<br><br>
  +
  +
''Funktionsweise:''<br>
  +
Jedes vorhandene Modul kann innerhalb der eigenen Funktionen eine BLE-Nachricht versenden.<br>
  +
Um eine bessere Logging-Übersicht zu erhalten, wird das jeweilige Modul mitgeloggt. Zusätzlich werden auch das aktuelle Datum und die aktuelle Uhrzeit (Client-seitig) mitgeloggt. <br>
  +
Da die jeweilige Uhrzeit vom Client beim Empfang gesetzt wird, ist eine korrekte Reihenfolge so nicht gegeben. Hier müsste eine Synchronisation zwischen Server (Feather) und dem Client (Laptop) realisiert werden.<br>
  +
Um eine Art Synchronisation zu realisieren wurde eine fortlaufende, eindeutige ID eingesetzt, die jede Nachricht erhält - so kann die korrekte versende Reihenfolge hergestellt werden, unabhängig vom Empfangszeitpunkt.<br>
  +
Mittels eines Switch-cases wird das jeweilige Modul, welches eine Nachricht versendet, unterschieden und die Nachricht entsprechend gesetzt und versendet.<br>
  +
Ein Log-Eintrag sieht wie folgt aus:'''12 2018-12-25 09:27:53 ENERGIEMANAGEMENT SUCCESS: AKKU: 33.6'''<br>

Aktuelle Version vom 25. August 2019, 12:12 Uhr

Hardware

Im Folgenden wird der Aufbau der Hardware als Block-Definition Diagramm dargestellt.

SysML Diagramm
Sysml_diagramm

Software

Allgemein

Als Software wird Zephyr OS mit folgenden Tasks verwendet. Sequenz-Diagramme:

Modul gedachter Aufbau am Anfang des Projektes Änderungen, die während des Projektes nötig waren
Sequenz-Diagramm Main Control
Sequenzdiagramm Main Control
Keine Änderungen
Sequenz-Diagramm Coulomb Counter
Sequenzdiagramm Coulomb Counter
Der Coulomb-Counter hat zwar die gleiche Funktion, ist aber nicht mehr als externes Modul an den Feather angeschlossen sondern als Simulation in Software umgesetzt
Sequenz-Diagramm IMU
Sequenzdiagramm IMU
Dieses Modul wurde weg gelassen
Sequenz-Diagramm Laser-/Ultraschallsensoren
Sequenzdiagramm Laser/Ultraschall
Keine Änderungen
Sequenz-Diagramm Engine
Sequenzdiagramm Engine
Die Errechnung der Reaktion über die IMU wurde weg gelassen

Einzelmodule

Im Folgenden werden die Einzelmodule grob beschrieben.

Energy Management System

Allgemein:

Das Energy Management System verwendet den Coulomb-Counter zur Messung der Energie und beinhaltet Mechanismen, die den Energie-Eintrag und den Energie-Verbrauch überwachen.

Dabei soll sowohl der Akku-Stand überwacht werden als auch der Energie-Verbrauch der einzelnen Roboter-Bewegungen und Einzel-Berechnungen der jeweils anderen Module aufgezeichnet werden.


Funktionsweise:

Das Energy Management System wird als Energiemessungs-Simulation realisiert. Hierfür werden 4 Pins verwendet. Von diesen 4 Pins werden zwei mit jeweils einer GPIO-Callback Funktion verbunden, die jeweils ein Register hochzählt. Der Trigger für das Hochzählen ist das Auftreten einer High Edge an dem jeweiligen Pin. Die anderen Zwei Pins werden von an einen gemeinsamen Timer getoggelt. Dabei wird innerhalb des Timers, abhängig von dem aktuellen State des Systems, entschieden, wie groß die Periodendauer des Signals ist.

Die Kommunikation zwischen Haupt-Steuerung und Energy Management System läuft über einen globalen Pointer auf eine Daten Struct, in der die momentane Aufgabe für das Energy Management System steht.


Vorausberechnung als mögliche Erweiterung des Projektes:

Dieses Aufzeichnen der Berechnungen und Bewegungen soll im späteren Verlauf (Nicht Teil des Projektes) dazu verwendet werden können, um zu lernen wie viel Energie ein einzelner Ausführungs-Schritt benötigt, womit dann der Energieverbrauch von Ausführungs-Ketten im Voraus berechnet werden kann.

Diese Vorausberechnung soll wie folgt funktionieren:

  • Jede Bewegung und jede Berechnung wird einem State einer State-Maschine zugeordnet
  • Jedem State wird ein Mittelwert und eine Zähler-Variable gegeben
  • Bei der Ausführung eines States wird der Mittelwert mit folgender Formel aktualisiert und die Zähler-Variable wird hochgezählt
 MW_neu_ = (MW_alt_ * N + X) / (N+1)
  • Nun kann die Motorsteuerung eine Ausführungs-Kette bei dem Energie Management System anfragen und erhält die zusammenaddierten Mittelwerte zurückgeliefert
  • Zusammen mit dem Akku-Stand kann daraus errechnet werden, ob der Roboter noch genug Energie führt eine bestimmte Aufgabe hat.

Odometrie

Algemein
Die Odometrie stellt Funktionen bereit, die die angeschlossene Sensorik ansteuern und abfragen kann.

BLE und Logging

Allgemein:
Das Bluetooth-Low-Energy-Modul verwendet das standardmäßig auf dem Feather vorhandene BLE.
Hierbei soll das Senden möglichst energiesparend geschehen. Deshalb wird hier auf eine energieaufwendige Bluetooth-Kopplung verzichtet und die Nachricht mittels einer Advertise-Nachricht versendet.

Funktionsweise:
Jedes vorhandene Modul kann innerhalb der eigenen Funktionen eine BLE-Nachricht versenden.
Um eine bessere Logging-Übersicht zu erhalten, wird das jeweilige Modul mitgeloggt. Zusätzlich werden auch das aktuelle Datum und die aktuelle Uhrzeit (Client-seitig) mitgeloggt.
Da die jeweilige Uhrzeit vom Client beim Empfang gesetzt wird, ist eine korrekte Reihenfolge so nicht gegeben. Hier müsste eine Synchronisation zwischen Server (Feather) und dem Client (Laptop) realisiert werden.
Um eine Art Synchronisation zu realisieren wurde eine fortlaufende, eindeutige ID eingesetzt, die jede Nachricht erhält - so kann die korrekte versende Reihenfolge hergestellt werden, unabhängig vom Empfangszeitpunkt.
Mittels eines Switch-cases wird das jeweilige Modul, welches eine Nachricht versendet, unterschieden und die Nachricht entsprechend gesetzt und versendet.
Ein Log-Eintrag sieht wie folgt aus:12 2018-12-25 09:27:53 ENERGIEMANAGEMENT SUCCESS: AKKU: 33.6