BWP-SS19-01/Dokumentation

Aus Verteilte Systeme - Wiki
Zur Navigation springen Zur Suche springen

Dokumentation 25.4. – 1.5.

Bei unserem Treffen haben wir die grundlegenden Funktionen und mögliche Hardware unseres Roboters mithilfe der vorhandenen Dokumentation „Energy harvesting systems for low energy mobile robots“ besprochen und haben uns für das anstehende Meeting Fragen notiert.

Im anstehenden Meeting, welches ca. 2 Stunden dauerte wurden viele grundlegende Fragen geklärt.

Die erste Frage ging um den Einsatz eines RISC5-Prozessors. Dieser Prozessor ist im Wesentlichen mit mehr Leistung als der „nRF52832 BLE SoC“ ausgestattet, da es sich bei dem RISC5-Prozessor um einen 8-Kern-Prozessor mit 250MHz pro Kern handelt. Da so viel Leistung für unser Projekt nicht benötigt wird, da so der Energieverbrauch ebenfalls steigt, wurde diese Idee schnell verworfen.

Die nächste Frage drehte sich um die Lokalisierung, damit der Roboter sich bewegen kann und den Weg zurück „nach Hause“ wiederfindet. „Zu Hause“ soll der Ort sein, wo der Roboter seinen Energiespeicher mittels Solarenergie wieder aufladen kann. Das Ganze muss so genau wie möglich sein und wir besprachen verschiedene Möglichkeiten dies zu realisieren. Eine Möglichkeit ist eine IMU einzusetzen, welche über I2C angeschlossen ist und aufgrund der Beschleunigung die Wegstrecke berechnen kann. Außerdem sollte das „zu Hause“ markiert Zentimeter genau markiert sein. Das Ganze kann auf verschiedenen Wegen passieren, beispielsweise durch einen Laser, der den Punkt markiert und mittels Lichtsensor erfasst wird. Hier entsteht das Problem, dass der Roboter womöglich lange sucht, bis er den korrekten Punkt gefunden hat und eventuell bevor er diesen Punkt findet keine Energie mehr hat. Als Alternative zu dieser Idee könnte man das „zu Hause“ des Roboters mit einer kleinen Metallplatte markieren, damit der Roboter an dem ein Magnet befestigt ist dort hingezogen wird. Die letzte Idee wäre eine Art Trichter zu bauen. Sobald der Roboter diesen erreicht, wird er punktgenau wie auf Schienen, in diesen hineingezogen und steht am Ende des Trichters an der richtigen Stelle.

Anschließend haben wir über die Energieabschätzung gesprochen. Hier ging es um die Speichergröße des Akkus und welche Solarzellengröße eingesetzt werden und wie wir diese berechnen können.

In der Doku des bereits existierenden Projekts sind unter dem Roboter links und rechts jeweils 2 Räder montiert, damit der Roboter nicht nach vorne oder hinten fallen kann, gibt es vorne und hinten jeweils einen „Plastikstopper“. Diesen Stopper halten wir für nicht sinnvoll und besprachen was wir stattdessen einsetzen könnten: Entweder bewegliche Räder, ähnlich zu denen an einem Schreibtischstuhl oder aber Kugeln, um möglichst wenig Widerstand bei Richtungsänderungen zu haben.

Da der Roboter seine Umgebung kartieren soll, haben wir als letztes technisches Thema über die Möglichkeiten der Darstellung einer Kartierung gesprochen. Das Ganze muss, aufgrund der kleinen Architektur, sehr Speichereffizient umgesetzt werden. Ein Vorschlag war es die Umgebung mittels Gitternetzkoordinaten abzulegen. Was in der Gruppe noch besprochen werden muss.

Als letztes Thema ging es um die verschiedenen Rollen, die wir als Teammitglieder einnehmen und haben diese zugewiesen. Jan übernimmt für die ersten 2 Wochen die Rolle des Managers, Jonas die Test-Rolle und René schreibt die Dokumentation.



Dokumentation 2.5. – 9.5.

Bei unserem Team-Treffen haben wir über verschiedenen Hardware-Optimierungen gesprochen. So haben wir uns entschieden auf ein Ultraschallsensor zu setzen, der einen kleinen Radius besitzt und somit eine bessere Auflösung bietet. Zusätzlich haben wir uns über mögliche Testfälle unterhalten und diese erweitert.

Bei der Besprechung mit den Teamleitern wurden weitere Dinge zur Hardware besprochen. So kam heraus, dass die Getriebeübersetzung weniger als 50 U/min betragen sollte und der Motor ein sogenannter Glockenankermotor sein sollte, wenn möglich von Faulhaber, dem Marktfrüher in diesem Bereich. Außerdem wurde über die Realisierung der Lenkung gesprochen. Da unser Roboter hinten 2 feststehende Räder haben wird und vorne ein bewegliches Rad muss hier bei der Programmierung darauf geachtet werden, dass man bei einem Richtungswechsel eine „Gegenlenkbewegung“ durchführt, um das Rad wieder in die richtige Position zu bringen.

Um die genaue Position des Roboters zu ermitteln, werden wir eine IMU einsetzen, diese kann auch einen Schlupf der Räder gut ausmerzen. Mittels dieser IMU wird das Finden der Base „leicht“ zu realisieren sein. Um das Finden bzw. das Navigieren zur Base etwas leichter zu gestalten, haben wir uns erst einmal darauf geeinigt, dass es keine beweglichen Gegenstände im Testgebiet des Roboters gibt.

Um den Stromverbrauch zu messen, wurde von Marcus vorgeschlagen einen Coulomb-Counter einzusetzen. Hier kann sehr genau der Stromfluss gemessen werden, da man die Flanken, auch im Schlafmodus zählen kann. Um die mögliche Aufladung über das Solarpanel zu erfassen, könnte man den Energieeintrag über die Solarzellenspannung messen und diese über die Zeit integrieren, so wäre das Ganze ohne Coulomb-Counter möglich zu realisieren.

Danach haben wir mit Andreas Grothe den Vorgang der Bestellung geklärt. Und anschließend besprochen, dass wir die Architektur mittels SysML darstellen können.

Dokumentation 10.5. – 21.5.

In den zwei Wochen vom 09.05. bis 21.05. wurde hauptsächlich der Bestellvorgang der einzelnen Bauteile vorangetrieben und abgeschlossen.


Bei dem ersten Meeting am 09.05. wurde versucht die Bestell-Liste zu vervollständigen. Dabei sind jedoch Probleme aufgetaucht. Zum Einen waren manche Bauteile falsch gewählt worden bzw. waren nicht kompatibel mit den jeweils Anderen. Zum Anderen hatten wir uns eine andere, alternative Umgebungs-Erkennung überlegt, welche unserer Meinung nach energie-effizienter ist. Dabei sollen durch Laser die Entfernungen zu Objekten vor dem Roboter gemessen werden. Außerdem konnten für bestimmte Bauteile keine kompatiblen Treiber gefunden werden. Um sich die zusätzliche Arbeit zu ersparen und sich mehr auf andere Teilgebiete des Projektes konzentrieren zu können wurden daher Bauteile gewählt, für die es bereits vorgefertigte Treiber gibt. Nach längerer Diskussion über die Vor- und Nachteile der verschiedenen Komponenten konnte eine fertige Bauteil-Liste angefertigt und zur Bestellung an Herrn Grothe weitergeleitet werden. Diese sah zu dem Zeitpunkt wie folgt aus.

Bauteil-Liste:

Zum Programmieren des Boards:


Außerdem wurde der Roboter ITS-E getauft.


Im Laufe der darauffolgenden Woche kam von Herrn Grothe eine Antwort auf unseren Bestell-Wunsch, bei dem es darum ging, dass wir keine Bauteile bei dem Shop adafruit kaufen können. Daraufhin wurde die Bauteil-Liste dementsprechend angepasst.


Da bei diesen Änderungen auch Bauteile komplett geändert werden mussten wurde im darauffolgenden, verkürzten Meeting am 16.5. nochmal über die Änderungen gesprochen. Außerdem mussten die Stückzahlen der einzelnen Bauteile angepasst werden, damit, im Fall eines Schadens an einer Komponente, Reserve vorhanden ist. Aus diesem Meeting heraus ist wiederum eine neue Bauteil-Liste entstanden. Diese sah wie folgt aus:

Diese Liste an Komponenten wurde als final angesehen und bestellt.

Außerdem wurde der Termin für das wöchentliche Meeting von Donnerstag 16 Uhr auf Dienstag 10 Uhr geändert.

Am darauffolgenden Meeting am 21.05. wurde über die UML-Darstellung der Hard- und Softwarekomponenten gesprochen und es wurden die Themengebiete der einzelnen Teammitglieder festgelegt.

Dabei kam folgende Einteilung heraus:

  • Jonas : Odometrie / SLAM
  • Rene : Telemetrie
  • Jan : Energy Harvesting

Außerdem wurde festgelegt, dass alle übrigen, bei dem Projekt anfallenden, Aufgaben von allen Team-Mitglieder gemeinschaftlich gelöst werden sollen.

Dokumentation 21.5. – 07.06.

Zunächst haben wir einige Anforderungen definiert und dazugehörige Milestones erstellt, beides wurde im Wiki eingetragen. Dabei haben wir das Ganze bewusst etwas gröber definiert, da es hauptsächlich einer ersten Übersicht dienen soll.

In der Woche vom 03.06 kamen die ersten Bauteile. Darunter befanden sich das Chassis, die Ultraschallsensoren, der J-Link Edu Programmer sowie die Motoren. Letztere haben wir erfolgreich auf ihre Funktionalität überprüft.

Beim Zusammenbau des Chassis ergab sich die Frage, wie die Motoren am Chassis und letztlich an den Reifen befestigt werden sollen, da die Fassung der Reifen einen größeren Durchmesser hat, als die Welle der Motoren. Erste Ideen, das Getriebe der zum Chassis gehörenden DC-Motoren zu nutzen, oder uns einen Adapter bzw. Ritzel mit einem 3D-Drucker zu drucken wurden verworfen, da sich die Teile zu schnell abnutzen würden. Daher haben wir uns bei einem Modellbauladen eine Wellenkupplung und eine Stange, jeweils aus Messing, besorgt und werden versuchen uns damit etwas zu basteln.

Außerdem ist ein erstes Fein-Design der Software enstanden.

Dokumentation 08.06. - 15.06.

Nachdem Jonas und René in verschiedenen Läden nach Möglichkeiten gesucht haben die Räder mit den Motoren zu verbinden, haben wir uns die Lösung von Jonas angeschaut. Leider hat diese gute Idee aufgrund von falschen Maßen nicht funktioniert - also haben wir uns alle gemeinsam auf die Suche nach einer Alternative gemacht. Auf verschiedenen Webseiten haben wir nach möglichen Bauteilen gesucht - leider ergebnislos. Also schauen wir uns verschiedene Lösungen anderer Bastler an - was wir am Ende aber zurückstellen, da wir den Roboter in der nächsten Zeit auch ohne Räder entwickeln können.

Um unabhängig der Telemetrie den Akkustand grob zu visualisieren haben wir uns über eine RGB-LED unterhalten. Hier könnte man beispielsweise für die Schritte 100%-75% - 74%-50% - 49%-25% - 24%-10% & < 10% unterschiedliche Farben darstellen.

Außerdem haben wir uns über mögliche Aufruf-Schnittstellen und übergebene Daten unterhalten, die wichtig für die Telemetrie sind. Zusätzlich haben wir uns darüber unterhalten was wir im Error-Fall machen wollen. Hier kam uns die Idee, dass wir verschiedene Fehlerlevel definieren und so Fehler eingrenzen.

Dokumentation 25.06. - 09.07.

In dieser Woche wurde die Haupt-Steuerung innerhalb des Teams abgesprochen und grob zusammengestellt. Außerdem wurde am Code weitergearbeitet.

Bei der Realisierung der Haupt-Steuerung ging es darum, Funktionen zu finden, über die mit den anderen Modulen gesprochen werden kann. Dabei war auch wichtig die Art der Daten festzulegen, die zwischen den einzelnen Modulen und der Haupt-Steuerung verschickt werden sollen.

Beispielsweise haben wir dabei festgelegt, dass die virtuelle Umgebungs-Karte global für den Haupt-Thread einsehbar sein muss damit die Bewegungsschritte berechnet werden können.

Außerdem haben wir die Einheiten festgelegt, die zwischen den Modulen und zur richtigen Übersetzung verwendet werden müssen. Die dafür notwendigen Datentypen können sich jedoch teils noch etwas verändern. Wir haben uns darüber hinaus entschlossen, die Einheiten sehr klein zu wählen genauere Bewegungen machen zu können.

Diese Realisierung wurde im Wiki dokumentiert.

In der darauffolgenden Woche haben wir uns der Hardware gewidmet. Dabei wurde eine Platine mit einzelnen Leiterbahnen bestückt und gelötet.

Das Augenmerk lag hierbei darauf, einheitliche Pin-Reihen für Vcc und Ground zentral auf die Platine zu bringen und auch zwei Pin-Reihen für das I2C-Interface bereit zu stellen. Also eine Pin-Reihe für SDA und Eine für SCK.

Außerdem wurden die einzelnen Bauteile wie zum Beispiel die IMU oder der Motor-Treiber angeschlossen.

Die Einzelnen Teammitglieder haben zwischenzeitlich an ihren jeweiligen Bauteilen weitergearbeitet und Jan hat mit Hilfe des Motor-Treibers den Motor über Zephyr ansteuern können.