Da ich es leid war, bei meinen Mountainbiketouren, ständig nach der richtigen Route auf meinem Handy zu schauen. Habe ich mich dazu entschieden, für meine Ausarbeitung einen Navigationskompass zu entwickeln, der mir ohne großen Aufwand den richtigen Weg weist.
Neben dem Board, welches einen Mikrocontroller, eine IMU und einen Laderegler beherbergt, habe ich auch eine passende App für die Kalibrierung des Magnetometer und die Einpflegen der zu fahrenden Route erstellt.
In meiner Ausarbeitung beschreibe ich den Entwicklungsprozess und gehe kurz auf einige technische Aspekte meiner Arbeit ein.
Das Literaturverzeichnis finden Sie auf meiner zu diesem Projekt erstellten Webseite es1.kuhlti.me.
Begonnen hat alles mit einer Mountainbike-Tour mit meinem Vater. Die Tour die wir fahren wollten hatten wir zuvor in einer Outdoor-App auf unser Handy heruntergeladen doch trotz des elektronischen Helfers in der Tasche mussten wir alle paar Meter nach der richtigen Abzweigung Ausschau halten.
Da mir und meinem Vater das ständige Rausholen des Handys irgendwann auf die Nerven ging, suchte ich im Internet nach einer Alternative.
Ich stieß damals auf einen Kickstarter Eintrag namens „SmartHalo”.
Für mein Projekt in dem Modul Embedded Systems 1 werde ich nun versuchen, eben jenes Produkt nachzubauen. Die Bauteile, wie den LED Ring oder die IMU, hatte ich glücklicherweise schon vorher als Breakoutboard (Platine zum einfache Entwickeln eines Prototypen) gehabt und konnte diese direkt auf einem Breadboard testen.
Ich habe das Dokument in einige Themenbereiche gegliedert, in denen ich einzeln auf einige Besonderheiten des Projektes eingehe.
Da die Aufgabe darin bestand, eine Audio- oder Videodatei abzugeben, nutze ich diese schriftliche Ausarbeitung als ein Skript für mein Video.
Die Schaltung für das Gerät, welches schlussendlich am Lenker meines Fahrrads montiert werden soll, habe ich in Eagle entworfen.
Im Nachfolgenden werde ich näher auf die Wahl meiner verwendeten Bauteile eingehen.
Als Herz meiner Schaltung habe ich mich für einen ESP32 der Firma Espressif entschieden, da ich bereits häufiger mit diesem Mikrocontroller gearbeitet habe und bereits über die nötige Bluetooth Schnittstelle verfügt.
Anders als viele Atmel Mikrocontroller läuft dieser nicht auf den üblichen $5$ Volt, sondern mit $3.3$ Volt. Für die Aufgabe ist dieser Mikrocontroller sehr wahrscheinlich überdimensioniert und könnte wahrscheinlich durch einen sparsameren Mikrocontroller ersetzt werden. Zeit war hier ein entscheiden Faktor.
Für den LED-Ring verwende ich WS2812B.
Diese, von der Firma Worldsemi hergestellten, RGB-LEDs sind einzeln ansteuerbare LEDs, die über einen Datenpin ihre gewünschte Farbe erhalten. Jede weitere LED kann über den Datenausgang in Reihe geschaltet werden.
Für die LEDs wird eine Spannung von $3.5\text{V}\ bis\ 5.3\text{V}$ benötigt, welche ohne einen Spannungsbooster für die Batterie möglich seien sollte. Mit geringerer Spannung kommt es zu deutlich erkennbaren Farbverfälschung.
Das Ansteuern mit den $3.3\text{V} $ des ESP Ausgangs hat bei meinen Tests ohne Probleme funktioniert. Falls es hier allerdings zu Problemen mit dem Ansteuern der LEDs kommt müsste eventuell ein passender Level Shifter verwendet werden.
Um ein schnelles Umprogrammieren des Mikrocontrollers zu ermöglichen, habe ich mich für die Verwendung eines USB to Serial Converter entschieden. Damit lassen sich Programmupdates ohne großen Aufwand direkt auf den Chip des Navitron flashen. Für das Design habe ich auf Open Source Schaltungen der Firma Sparkfun zurückgegriffen.
Da das Gerät später mal am Lenker montiert werden soll, ist eine kabelgebundenen Stromversorgung keine Lösung. Wie bei den meisten Geräten auf dem Markt, verwende ich einen Lithium-Polymer Akku, der über eine Steckverbindung mit dem Gerät verbunden werden kann. Um nicht jedes Mal das Gehäuse öffnen zu müssen, um den Akku zu laden, verwende ich den MCP73831 Laderegler der Firma Microchip.
Mit einem Widerstand $\text{R}_{\text{PROG}}\ [\text{k}\Omega]$ lässt sich der maximale Ladestrom für die Batterie einstellen.
Funktionsweise eines Ladereglers
Ein Laderegler, reguliert Strom I und Spannung V so, dass der LiPo-Akku möglichst schonend geladen wird. Man sieht in der Grafik rechts die Ladekurve mit einen Ladestrom $\text{I}_{\text{REG}}=100\text{mA}$. Erreicht der Akku die gewünschten $4.2\text{V}$, regelt der Laderegler den Strom immer weiter herunter. Das Drosseln des Ladestrom geschieht bei etwa 80% Batterieladung.
Diagramm aus dem Datenblatt des MCP73831
Ich habe für meine Schaltung einen $\text{R}_{\text{PROG}} = 2\text{k}\Omega$ gewählt. Was meinen Akku mit einem maximalen Ladestrom von $\text{I}_{\text{REG}}=500\text{mA}$ versorgt.
Da der Mikrocontroller auf $3.3\text{V}$ und die IMU auf $1.8\text{V}$ laufen, habe ich zwei lineare Spannungswandler mit ausreichend Output Strom verwendet. Mehr Details im Datenblatt des AP2112.
Neben dem eigentlichen Gerät habe ich mich dafür entschieden, die Positionsbestimmung, sowie die Einpflegung und Verarbeitung der Route, über ein verbundenes Smartphone zu realisieren. Schlussendlich wird der errechnete Kurs dann über Bluetooth an das Gerät übertragen. Das Gerät soll dann aus gegebenen Magnetfelddaten und dem berechneten Kurs vom Smartphone den gewünschten Kurs auf den LEDs ausgeben.
In diesem Teil gehe ich etwas tiefer auf einige Konzepte und Bauteile ein, die für die Umsetzung dieses Projektes erforderlich sind.
Als Inertiale Messeinheit (engl.: „Inertial Measurment Unit”, kurz: IMU) beschreibt man einen Sensor, mit welchem die Lage und Bewegung im physikalischen Raum festgestellt werden kann. Ein solcher Sensor beinhaltet üblicherweise einen Beschleunigungssensor und einen Drehratensensor. Für meine Anwendung ist neben diesen beiden Sensoren auch ein Magnetfeldsensor vorhanden, welcher — wenn richtig kalibriert — das magnetische Feld der Erde erfassen soll.
Man spricht von einem Sensor mit 9 Freiheitsgeraden (9 DOF — Dimension of Freedom)
Um das Erdmagnetfeld richtig erfassen zu können, müssen zu Beginn sämtliche magnetischen Störgrößen erfasst und herausgerechnet werden. Dieser Prozess ist als „Kalibrieren des Sensors” bekannt und muss auch bei einem Smartphone vor der Verwendung des Kompasses durchgeführt werden. 1
Es gibt zwei Art von auftretenden Störgrößen:
Hard Iron Distortion
Hard Iron Sources sind Magnetfelder die sich mit dem Sensor bewegen und so für eine konstant gleiche Verfälschung der Daten sorgen. Mögliche Gründe dafür sind benachbarte, ferromagnetische Bauteile auf dem PCB oder im Gehäuse.
Soft Iron Distortion
Nachdem wir die magnetischen Störgrößen herausgefiltert haben werden wir schnell feststellen, dass die gemessenen Daten unseres Magnetometers nicht in Richtung geographischen Norden zeigen werden.
Unterschied zwischen geographischem und magnetischem Nordpol
Wohingegen der geogeraphische Nordpol immer an derselben Stelle zu finden ist, verschiebt sich der magnetische Nordpol jedes Jahr um ein paar Kilometer.
Der Grund für die Abweichung zwischen dem magnetischen und geographischen Norden ist, dass sich unser Schutzschild (das Erdmagnetfeld) permanent verändert und verschiebt.
Zu allem Übel verlaufen die Erd-Magnetfeldlinien auf unserem Breitengrad nicht horizontal zur Erdoberfläche sondern versinken in einem bestimmten Winkel in die Erde. Dieser Winkel wird die magnetische Inklination genannt. Auf nachfolgender Karte, von den National Centers for Enviormental Information (kurz: NOAA) lässt sich dieser Wert für jeden Ort der Erde ablesen. 3
Als Deklination wird der Winkel zwischen magnetischem und geographischen Norden bezeichnet. Es ist also die Abweichung zwischen den Beiden.
Bei einer Deklination von bspw. 10° an unserer Position, hätte das zur Folge, dass, wenn wir einen Kompass betrachten, die Nadel leicht nach rechts zeigen müsste, damit wir in Richtung Norden schauen.
Da unser Gerät natürlich in Richtung des geographischen Nordens ausgerichtet seien soll müssen wir diese Abweichung später mit in unsere Berechnung mit einfließen lassen.
Die Inklination und Deklination kann im Folgenden für die angegebenen Koordinaten berechnet werden. Die Daten kommen von Amentum Aerospace (API).
Das Ergebnis wird mit einem "." als Komma dargestellt.
Die Ermittlung der aktuellen GPS-Koordinaten, des Nutzers erfolgt über diec zum Gerät, zugehörige Smartphone App. Diese Architektur ist zwar nicht gerade nutzerfreundlich aber schneller für mich zu realisieren, da das Smartphone bereits mit einigen Bibliotheken für die Verwendung des integrierten GPS Moduls kommt.
Die Route liegt im Handy als Liste von Wegpunkten, als eine GPX Datei, vor. Jeder Wegpunkt besitzt eine Koordinate, welche nacheinander die gewünschte Tour ergibt.
Kommt der Nutzer einem Wegpunkt nahe, so soll automatisch der nächste Wegpunkt ausgewählt werden.
In dem nachfolgenden Konzept wird die aktuelle Position des Nutzers mit dem blauen Punkt dargestellt. Der transparente Kreis um den blauen Punkt ist der Detektionsradius in welchem ein Wegpunkt erkannt und der nächste Wegpunkt ausgewählt wird.
Eine mögliche Überprüfung, ob sich die Person in Reichweite eines Wegpunktes befindet, könnte wie folgt in Swift umgesetzt werden. Es handelt sich hier um Pseudocode und funktioniert so nicht direkt in der App.
/**
Die Funktion prüft ob sich der Wegpunkt (wp) im Radius
(radius) der aktuellen Position des Nutzers (pos)
befindet und gibt das Ergebnis als Boolean zurück.
*/
func überprüfenObAmWegpunkt(
pos: Coordinate,
wp: Coordinate,
radius: Double
) -> Bool {
// Die Entfernung zwischen der Position und dem
// Wegpunkt
let entfernung = pos.entfernung(zu: wp)
// Prüfen pb die Entfernung zum Wegpunkt kleiner ist
// als der Detektionsradius
return entfernung < radius
}Da vielleicht aufgrund von Ungenauigkeiten bei der GPS Bestimmung die Auswahl des Wegpunktes fehlschlägt, soll es in der App die Möglichkeit geben den nächsten Wegpunkt manuell auszuwählen.
Um automatisch den nächsten Wegpunkt auszuwählen muss die Entfernung zum nächsten Wegpunkt bestimmt werden. Gehen wir davon aus, dass die Erde eine perfekt runde Kugel ist dann können wir mit dem Erddurchmesser $\text{r}$ von $6378.13\text{km}$ (WolframAlpha) ausgehen.
Erd-ellipse statt Erd-kugel?
Tatsächlich ist die Erde aufgrund der durch die Erdrotation auftretenden Fliehkräfte keine perfekte Kugel sondern ist zum Äquator hin gestreckt. Das Bild rechts zeigt eine überzogene Darstellung dieser Ausdehnung. Zwischen der maximalen Stauchung und maximalen Streckung besteht ein Höhenunterschied von $22\text{km}$. Bezogen auf den Erdradius ist dies eine Differenz von $0.3\%$ und sollte für unsere Berechnungen keinen allzu großem Einfluss haben.
StackExchange (Geographical Information Systems)
Berechnung:
Im Folgenden habe ich die beiden Schritte, die nötig sind, um die Distanz rechnerisch zu ermitteln, näher beschrieben. Wen dies nicht interessiert kann den Teil auch überspringen.
$\zeta := \arccos \left( \sin \left( \phi_A \right) \cdot \sin \left( \phi_B \right) + \cos \left( \phi_A \right) \cdot \cos \left( \phi_B \right) \cdot \cos \left( \lambda_B - \lambda_A \right) \right)$
$ l_{\text{AB}}\left(\frac{\zeta}{rad}\right):=\zeta \cdot 6378.13\text{km} $ oder $ l_{\text{AB}}\left(\frac{\zeta}{°}\right):=\zeta \cdot \frac{180°}{\pi} \cdot 6378.13\text{km} $
Die Kalibrierung des Magnetfeldsensors dient dazu, Störgrößen zu ermitteln und schlussendlich aus den Messdaten herauszufiltern.
Welche Störgrößen es zu beachten gibt, habe ich bereits im Teil Magnetische Störungen näher erläutert.
Hard-Ironing verursacht eine Verschiebung des Mittelpunktes, der Messdaten.
Soft-Ironing verursacht eine Streckung bzw. Stauchung, der Messdaten.
Für die Kalibrierung habe ich eine eigenständige App entwickelt, welche sich die Messdaten über einen WebSocket einholt.
Zum Kalibrieren muss nun der Sensor in alle Richtungen bewegt werden, so dass auf dem angezeigten Streuungsdiagramm drei Kugeln entstehen. Sind die Kugeln verschoben oder gestreckt, so handelt es sich um die eben erwähnten Störfaktoren. Da die Achsen des Diagramms nicht einhundert prozentig gleich skaliert sind, kann es zu einer Streckung / Stauchung der Grafik kommen, was sich allerdings nicht auf die Messdaten auswirkt.
Nachdem genug Daten gesammelt sind kann die Verbindung unterbrochen werden und mit einem Klick auf Calibrate die Ausgleichswerte berechnet werden. 6 7
Hier ein kurzes Video des Prozesses:
Auf dem Board werden alle paar Millisekunden die neusten IMU Daten über I2C abgefragt und mit folgender Formel die Ausrichtung des Board bestimmt. Die Formel kommt aus einem Video über Sensor Fusion, des offiziellen Matlab YouTube Channels.
Die beiden Vektoren $\vec{\text{acc}}$ und $\vec{\text{mag}}$ können mittels der gelieferten Sensorwerte aufgestellt werden.
Die Vektoren $\vec{\text{offset}}$ und $\vec{\text{scale}}$ sind die beiden Ausgleichsvektoren, welche wir zuvor in Schritt 5.3 Magnetometer Kalibrierung ermittelt haben.
Der Offset wird von den Messdaten abgezogen und das Resultat Komponentenweise mit dem Hadamard Produkt multipliziert.
$ \vec{\text{mag}_c}:=\left( \vec{\text{mag}}-\vec{\text{mag}_{\text{offset}}} \right) \circ \vec{\text{mag}_{\text{scale}}} $Mit der Invertierung des Beschleunigungsvektors erhält man den Vektor in Richtung des Erdgravitation.
$\vec{\text{runter}}:=-\vec{\text{acc}}$Das Kreuzprodukt $\vec{ost}:=\vec{\text{mag}} ×\vec{\text{runter}}$ ergibt einen Vektor der in der xy-Ebene nach Osten zeigt.
Nimmt das Kreuzprodukt zwischen $\vec{\text{osten}}$ und $\vec{\text{runter}}$ erhält man den gewünschten Vektor mit Ausrichtung in Richtung Norden. $\vec{\text{norden}}:=\vec{\text{osten}} ×\vec{\text{runter}}$
Mit dem $atan2$ kann dann der eigentlich Winkel berechnet werden.
$\text{ausrichtung}:=atan2(y_{\text{norden}}, x_{\text{norden}})$
Wie auch im Praktikum, habe ich für die Erstellung der Platine, das von Autodesk kostenlos zu Verfügung stehende Programm Eagle verwendet. Mit diesem Programm habe ich mehrmals schon andere, kleinere Schaltungen entworfen und bin mit diesem am bestens vertraut. Das Design basiert größtenteils auf Open Source zugänglichen Designs der Firma Sparkfun. Einige der verwendeten Bauteile habe ich bereits vorher besessen und konnte diese auf einem Breadboard verwenden, um einige Design-Features vorab zu testen.
Da ich sichergehen wollte, dass meine Schaltung auch wirklich in vollem Umfang funktioniert, habe ich auf der Freelancer Platform Fiverr für ein paar Euro jemanden beauftragt, meine Schematic auf Fehler zu überprüfen. Neben einem Widerstand und einem Entkopplungskondensator hat, mein Prüfer allerdings keine Fehler feststellen können. Was genau ich an Hilfe bekommen habe können Sie sich ebenfalls in meinem Repository anschauen (damit Sie sehen, dass es mit rechten Dingen zugegangen ist).
Das PCB habe ich zu 100% selber erstellt und ist bis auf einen Entkopplungskondensator hoffentlich funktionsfähig.
Bei all meinen bisher erstellten Boards habe ich auf den chinesischen Hersteller JLCPCB zurückgegriffen. Aus Umweltgründen würde ich gerne einen Deutschen oder doch zumindest europäischen Hersteller vorziehen, konnte aber keine kostengünstige Alternative finden. Selbst mit Expresslieferung ist die Produktion in Fernost um einiges billiger. Auch aufgrund meines doch eher beschränkten Budgets für dieses Projekt, musste ich leider die umwelttechnischen Konsequenzen ausser Acht lassen. Für eine nächste Version, welche ich ohne Zeitdruck entwickeln könnte, wäre dies jedoch ein Hauptmerkmal.
Neben dem eigentlichen PCB habe ich zudem eine Schablone für das Auftragen der Lötpaste bestellt. Diese ist mit einem Spachtel auf das Board aufzutragen und kann dann mit einem Reflow-Ofen oder einem Heißluftföhn zum Schmelzen gebracht werden. Die Komponenten sind vorher vorsichtig auf die entsprechende Stelle zu platzieren.
Am meisten Sorgen bereitete mir der IMU, der mit seinen gerade einmal 3x3mm und ganzen 24 Pins, an der Unterseite, eine echte Herausforderung darstellt. Auch der doch recht hohe Preis von 7,13$\frac{\text{€}}{\text{Stück}}$ (Preis bei DigiKey) lässt wenig Fehlerspielraum zu.
Zu meinem Erstaunen hat bei der Inbetriebnahme meines ersten Prototypen FAST alles funktioniert. Die USB to Serial Verbindung, die LEDs (bis auf eine) und der Mikrocontroller haben funktioniert.
Nachfolgend die erste Inbetriebnahme mit einer Demo:
Einziges Problem war, wie bereits befürchtet, der IMU. Trotzdem meine Lötverbindungen auch eher zu wünschen übrig ließen, gehe ich davon aus, dass es schlussendlich nicht meine Lötverbindungen war, sondern meine offenen Verbindungen, für den Interrupt- und den FSYNC-Pin, unter dem Chip. Mir war von dem Datenblatt nicht bewusst, dass unter dem Chip eine kleine Metallplatte für das Abführen von Hitze angebracht ist, welche sehr wahrscheinlich INT und FSYNC kurzgeschlossen hat.
Da ich mir bereits vorher gedacht habe, dass der IMU eventuell nicht auf Anhieb funktioniert, habe ich mir glücklicherweise eine Hintertür eingebaut, die es mir ermöglicht, mein funktionierendes Breakoutboard über ein 4 adriges Kabel auf der Rückseite mit einem Stecker auf der Rückseite des PCBs zu verbinden. Bei Sparkfun wird diese Verbindung Qwiic genannt.
Aus Zeitgründen habe ich es nicht mehr geschafft meine zweite Platine zu bestücken.
Neben den verwendeten Bauteilen habe ich auch den Grund für die Verwendung sowie einige zusätzliche Ressourcen angegeben. Die Bauteile habe ich alle bei Digi-Key bestellt.
| Bauteil | Anzahl | Beschreibung | Preis |
|---|
Die Kosten pro Board belaufen sich auf etwa 15€ bis 20€. Da ich Ersatz-Komponenten für 3 Boards und einiges an zusätzlichem Werkzeug bestellt habe, lagen meine Anschaffungskosten bei etwa 250€. Mit zunehmender Abnahmemenge and PCB-Boards und Komponenten kann dieser Preis allerdings noch deutlich verringert werden. Damit liegen meine Ausgaben über den 139€, Anschaffungskosten des SmartHalo, habe aber durch das Entwerfen der Schaltung und das Programmieren der Apps einiges an Erfahrung gewonnen.
https://www.nxp.com/docs/en/supporting-information/ARTICLE_REPRINT.pdf ↩
