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

Aus Verteilte Systeme - Wiki
Zur Navigation springen Zur Suche springen
 
(14 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 6: Zeile 6:
 
{| Border=1 style="border-collapse:collapse; width: 800px;" cellpadding=10
 
{| Border=1 style="border-collapse:collapse; width: 800px;" cellpadding=10
 
| SysML Diagramm
 
| SysML Diagramm
| [[Datei:BWPSS1901_Sysml.PNG|1400px|right|Sysml_diagramm]]
+
| [[Datei:BWPSS1901_Sysml.PNG|1000px|right|Sysml_diagramm]]
 
|-}
 
|-}
 
</table>
 
</table>
Zeile 19: Zeile 19:
 
<table>
 
<table>
 
{| Border=1 style="border-collapse:collapse; width: 800px;" cellpadding=10
 
{| Border=1 style="border-collapse:collapse; width: 800px;" cellpadding=10
  +
| Modul
  +
| gedachter Aufbau am Anfang des Projektes
  +
| Änderungen, die während des Projektes nötig waren
 
|-
 
| Sequenz-Diagramm Main Control
 
| Sequenz-Diagramm Main Control
 
| [[Datei:BWPSS1901_Sequenz1.JPG|400px|right|Sequenzdiagramm Main Control]]
 
| [[Datei:BWPSS1901_Sequenz1.JPG|400px|right|Sequenzdiagramm Main Control]]
  +
| Keine Änderungen
|-}
 
 
|-
</table>
 
 
<table>
 
{| Border=1 style="border-collapse:collapse; width: 800px;" cellpadding=10
 
 
| Sequenz-Diagramm Coulomb Counter
 
| Sequenz-Diagramm Coulomb Counter
 
| [[Datei:BWPSS1901_Sequenz2.JPG|400px|right|Sequenzdiagramm 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
|-}
 
 
|-
</table>
 
 
<table>
 
{| Border=1 style="border-collapse:collapse; width: 800px;" cellpadding=10
 
 
| Sequenz-Diagramm IMU
 
| Sequenz-Diagramm IMU
 
| [[Datei:BWPSS1901_Sequenz3.JPG|400px|right|Sequenzdiagramm IMU]]
 
| [[Datei:BWPSS1901_Sequenz3.JPG|400px|right|Sequenzdiagramm IMU]]
  +
| Dieses Modul wurde weg gelassen
|-}
 
 
|-
</table>
 
 
<table>
 
{| Border=1 style="border-collapse:collapse; width: 800px;" cellpadding=10
 
 
| Sequenz-Diagramm Laser-/Ultraschallsensoren
 
| Sequenz-Diagramm Laser-/Ultraschallsensoren
 
| [[Datei:BWPSS1901_Sequenz4.JPG|400px|right|Sequenzdiagramm Laser/Ultraschall]]
 
| [[Datei:BWPSS1901_Sequenz4.JPG|400px|right|Sequenzdiagramm Laser/Ultraschall]]
  +
| Keine Änderungen
|-}
 
 
|-
</table>
 
 
<table>
 
{| Border=1 style="border-collapse:collapse; width: 800px;" cellpadding=10
 
 
| Sequenz-Diagramm Engine
 
| Sequenz-Diagramm Engine
 
| [[Datei:BWPSS1901_Sequenz5.JPG|400px|right|Sequenzdiagramm Engine]]
 
| [[Datei:BWPSS1901_Sequenz5.JPG|400px|right|Sequenzdiagramm Engine]]
  +
| Die Errechnung der Reaktion über die IMU wurde weg gelassen
 
|-}
 
|-}
 
</table>
 
</table>
Zeile 54: Zeile 47:
 
=== Einzelmodule ===
 
=== Einzelmodule ===
   
Im folgenden werden die Einzelmodule grob beschrieben.
+
Im Folgenden werden die Einzelmodule grob beschrieben.
   
 
==== Energy Management System ====
 
==== 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.
 
Das Energy Management System verwendet den Coulomb-Counter zur Messung der Energie und beinhaltet Mechanismen, die den Energie-Eintrag und den Energie-Verbrauch überwachen.
Zeile 62: Zeile 58:
 
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.
 
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.
   
  +
Dieses Aufzeichnen der Berechnungen und Bewegungen soll im späteren Verlauf dazu verwendet werden können, um zu lernen wie viel Energie ein einzelner Ausführungs-Schritt benötigt,
 
  +
''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.
 
womit dann der Energieverbrauch von Ausführungs-Ketten im Voraus berechnet werden kann.
   
Zeile 68: Zeile 75:
 
* Jede Bewegung und jede Berechnung wird einem State einer State-Maschine zugeordnet
 
* Jede Bewegung und jede Berechnung wird einem State einer State-Maschine zugeordnet
 
* Jedem State wird ein Mittelwert und eine Zähler-Variable gegeben
 
* Jedem State wird ein Mittelwert und eine Zähler-Variable gegeben
* Bei der Ausführung eines States wird der Mittelwert mit folgender Formal aktualisiert und die Zähler-Variable wird hochgezählt
+
* 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)
 
MW_neu_ = (MW_alt_ * N + X) / (N+1)
Zeile 75: Zeile 82:
 
* Zusammen mit dem Akku-Stand kann daraus errechnet werden, ob der Roboter noch genug Energie führt eine bestimmte Aufgabe hat.
 
* Zusammen mit dem Akku-Stand kann daraus errechnet werden, ob der Roboter noch genug Energie führt eine bestimmte Aufgabe hat.
   
 
==== Odometrie ====
Zur Entwicklung der Schaltung an dem MPPT werden zusätzliche Bauteile benötigt. Diese können aus dem Datenblatt des MPPT entnommen werden:
 
   
  +
''Algemein''<br>
<table>
 
  +
Die Odometrie stellt Funktionen bereit, die die angeschlossene Sensorik ansteuern und abfragen kann.
{| Border=1 style="border-collapse:collapse; width: 800px;" cellpadding=10
 
| Bill of Materials entnommen aus:
 
"User's Guide for bq25570 Battery Charger Evaluation Module for Energy Harvesting" von Texas Instruments
 
|-
 
| [[Datei:BWPSS1901_billofmaterials.JPG|400px|left|Bill of Materials]]
 
|-}
 
</table>
 
   
 
==== BLE und Logging ====
Dabei werden jedoch nicht alle Bauteile benötigt.
 
Die benötigten Bauteile sind:
 
* C1 - C7 (Kondensator)
 
* J1 -J13 und JP1 - JP6 (Header/Jumper)
 
* L1 und L2 (Inductor/Energiespeicher)
 
* R1 - R10 (Widerstände)
 
* U1 (MPPT)
 
   
Außerdem braucht man eine Verbindung zwischen den SMD Pins des MPPT und den Schaltungselementen.
 
   
  +
''Allgemein:''<br>
==== Odometrie ====
 
  +
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>
==== BLE und Logging ====
 
  +
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