BWP-WS19-02/Dokumentation/AntriebMechanikKommunikation

Aus Verteilte Systeme - Wiki
< BWP-WS19-02‎ | Dokumentation
Version vom 6. März 2020, 18:52 Uhr von Fsimo001 (Diskussion | Beiträge) (Eagle-Schaltplan anfertigen)

Wechseln zu: Navigation, Suche

Teamstruktur

1. Projektphase 2. Projektphase 3. Projektphase
Ellen (Manager) Ellen (Tester) Ellen (Dokumentation)
Felix (Tester) Felix (Dokumentation) Felix (Manager)
Laura (Dokumentation) Laura (Manager) Laura (Tester)

Teaminterne Milestones

  • Auto montiert
  • fahrendes Auto
  • fahrendes Auto mit Sensor Austausch
  • Drehungen
  • Kommunizierendes Auto

Arbeitspakete

Die Arbeitspakete unserer Gruppe sind ab sofort im gitlab zu finden

Antrieb & Mechanik

Chassis

Entwurf

Für das Chassis des autonomen Fahrroboters haben wir verschiedene Formen und Aufbau-Ideen evaluiert und uns schließlich für eine Kombination eines Rechtecks mit einem Trapez ausgesucht, da das Sensoren-Team uns als Anforderung vorgegeben hatte, dass die Time of Light Sensoren alle gleichweit von dem Fahrzeugdrehpunkt angebracht werden sollen.

Text der Bildlegende Text der Bildlegende Text der Bildlegende Text der Bildlegende

Brett sägen und Kugelrad basteln

Für das Aussägen unserer ausgewählten Form, haben wir für die Dekupiersäge ein Sägeblatt gesucht. Nachdem wir keine vorort gefunden haben, haben wir eins im Baumarkt beschafft. Darauffolgend haben wir für unsere Form Löcher in die Pressspanplatte gebohrt, um die Löcher für die Räder und Zahnräder gebohrt. Schließlich haben wir mit der Dekupiersäge die Vorlage ausgesägt und die Kanten anschließend abgefeilt.


Text der Bildlegende


Das Kugelrad

Da unser ITS-E leider nicht auf 2 Rädern balancieren kann benötigt er ein drittes Stützrad. Beim Vorgängerprojekt wurde dieses Problem mit einer einfachen Lenkrolle gelöst. Nachteil daran war, das die Lenkrolle sich beim drehen erst ausrichten muss und somit in Abhängigkeit von ihrer vorherigen Position unterschiedliche Reibungswiderstände erzeugt. Fuhr man beispielsweise erst gerade aus und drehte dann das Fahrzeug um seinen Mittelpunkt musste die Rolle sich um 90° drehen. Wenn man nun das Fahrzeug in die entgegengesetzte Richtung drehen wollte musste die Rolle sich um 180° drehen, was ohne schleifen des Rads in diesem Aufbau nicht möglich war.


Da unser Auto sich jedoch sehr exakt drehen können muss war ein reibungsarmes Stützrad schnell motiviert.

Es entstanden verschiedene Ideen, die das Problem minimieren, aber nicht beseitigen würden. So unter anderem eine doppelt gelenkte Lenkrolle. Schließlich einigten wir uns auf ein Kugelrad, da die vorher genannte Problematik hierbei behoben wäre.


Version 1.0:

Die erste Version des Kugelrads war eine auf Drähten gelagerte Murmel. Hierzu bohrten wir test-weise ein Loch in eine Platte und klebten zur Lochmitte hin 4 Drähte auf, auf welchen die Murmel gleiten sollte.


Version 1.1:

Um das Ganze am Auto montieren zu können sägten wir eine Halterung für die Murmel aus und lagerten die Murmel auf 4 Nägeln, deren Spitzten rund gefeilt wurden. Der Schwachpunkt bei dieser Konstruktion war die Unebenheit der Murmel. Bei gießen der Murmeln entstehen offenbar kleine rillen die uns zum Verhängnis wurden, wenn die Nägel darin hängen blieben. Außerdem war keine der Murmeln 'perfekt' rund. Ein weiterer Nachteil bestand darin die Kugel auf 4 Punkten auf zu legen. Dies gestaltete sich aufgrund der nicht so präzisen Bohrungen als schwierig.

Kugelrad_V1.1 Kugelrad_V1.1


Version 2.0:

Schließlich bestellten wir gehärtete Edelstahlkugeln in der Qualität G28 nach DIN 5401, die extra sorgfältig poliert wurden! Diese Kugeln haben ein maximale Unrundheit von 0,7 µm und eine maximale Rauheit von 0,05 µm. (Verglich der Rauheiten) Die Kugel wurde bei www.kugel-winnie.de bestellt (www.kugel-winnie.de).


Um die Kugel ideal zu lagern verwendeten wir (diesmal 3, nicht 4) Edelstahlnadeln mit Glasköpfen. Um die Kugel zusätzlich zu federn wurde eine Scheibe angefertigt auf der die Nadeln aufgelötet wurden und zusätzlich die Unterseite des Autos freigefräst.

Kugelrad_V2_Ring Kugelrad_V2_Ring 3 Kugelrad_V2_Ring 2


Auf den Glasköfen ist die Reibung der Kugel minimal.

Kugelrad_V2_Nadel


Damit die Kugel beim anheben des Autos nicht herausfällt wurde eine Kappe darüber montiert. Die Kappe ist von einem Kugelrad von Pollin Elektronik genommen (Pollin Kugelrad). Es wurde lediglich der untere Ring abgeflext, beigeschliffen und M2 Muttern in die Löcher eingepresst und verlötet.

Kugelrad Pollin Kugelrad_V2_Ring_Kugel2


Um den idealen Abstand der Kappe ein zu stellen sind Federn zwischen der Kappe und dem Chassis angebracht.

Kugelrad_V2_Feder Kugelrad_V2


Diese Variante funktioniert selbst auf sehr glatten Unterflächen noch sehr gut.

Kugelrad_V2_vorne Kugelrad_V2_unten


Da die Kugel mit 66 gram relativ schwer ist wurde sie dichter zur Radachse gesetzt als ursprünglich geplant, um bei möglicher Schieflage der Fahrstrecke das Fahrzeug nicht zu sehr zur Seite zu ziehen.

Kugelrad_V2_oben


Halterung für Time of Flight Sensoren

Die Halterung der Time of Flight Sensoren wurde aus einem alten Scharnier geschnitten. Ziel war es den Sensor so einstellen zu können, dass er flach über den Boden schaut um auch niedrige Objekte zu erkennen und dennoch brauchbar ist um große Distanzen zu messen. Da der verwendete Time of Flight Sensor einen Auffangwinkel von 25° hat muss er in einem Winkel von 102,5° (90° + 25°/2) am Auto montiert werden.

Time Of Flight Sensor Halterung

Ein erster Entwurf einer Halterung der Time of Flight Sensoren.

Motorensteuerung

GPIO + Programme anschauen

Für die Ansteuerung der GPIOs haben wir die vorhandenen Demo-Programme gesichtet und durch die Zephyr Dokumentation sowie der Datei ITS-E/zephyr/boards/arm/nrf52_adafruit_feather/board.h konnten wir die GPIO Pins verwenden, um eine LED blinken zu lassen.

Versuch den Motor über PWM anzusteuern

Um später mittels PWM die Pins ansteuern zu können, braucht man einen aktivierten PWM-Driver. Diesen haben wir aus den ⁨bwp_ws19⁩/zephyr⁩/boards⁩/⁨arm⁩/⁨nrf52_pca10040⁩/Kconfig.defconfig

if PWM
config PWM_0
	default y

endif # PWM

in die Kconfig.defconfig des adafruit featherboard kopiert und danach ebenfalls aus den ⁨nrf52_pca10040-bordkonfigurationen in der Datei nrf52_pca10040.dts die Passage

&pwm0 {
	status = "okay";
	ch0-pin = <17>;
	ch0-inverted;
};

in die .dts-Datei im Ordner des genutzen Adafruit Featherboards nrf52 (zephyr/boards/arm/nrf52_adafruit_feather) kopiert, um bei dem angegeben Pin das Pwm-Signal zu aktivieren. → Wenn man einen anderen Pin als Pin 17 mit Pwm versorgen möchte, muss man ihn an dieser Stelle „ch0-pin = <pinnummer>; angeben!

Danach haben wir das PWMSignal mit dem Beispielprogramm blink_LED ausprobieren, jedoch haben wir das Pwm nicht zum laufen bringen können, weil die defines DT_ALIAS_PWM_LED0_PWMS_CONTROLLER und DT_ALIAS_PWM_LED0_PWMS_CHANNEL nicht gefunden wurden.

Jedoch haben wir bei dem Programm servo-Motor ein Signal erhalten. Wichtig ist, dass man beim Aufruf von static int pwm_pin_set_usec(struct device *dev, u32_t pwm, u32_t period, u32_t pulse) Set the period and pulse width for a single PWM output. Parameters

   • dev: Pointer to the device structure for the driver instance. 
   • pwm: PWM pin. 
   • period: Period (in microseconds) set to the PWM. 
   • pulse: Pulse width (in microseconds) set to the PWM. 

Return Value

   • 0: If successful. 
   • Negative: errno code if failure. 
nochmals den PWM-pin angibt(typ u32_t) siehe Parameters.


Wir haben dieses Beispielprogramm in unseren ITS-E-Ordner kopiert. Hierfür muss man noch in der ITS-E/project.conf- Datei „CONFIG_PWM=y“ setzen.

Bei dem Servo-Beispiel setzt man MinPulsWidth und MaxPulsWidth in Mikrosekunden und gibt die Periodendauer


Text der Bildlegende


Des Weiteren haben wir versucht den Strom durch einen 3 Ohm Widerstand der 1206 Baureihe auf dem Breakout-Board auf 66,6 mA zu begrenzen. Die Formel zur Berechnung des Maximalstroms Imax=0,2V/R (0,066 A=0,2 V / 3 Ohm). Die Spannung ist laut Datenblatt auf 0,2 V festgelegt. Da der Motor als induktive Last bei fallenden Flaken des PWM Signals eine negative Spannung induziert, sind auf dem Breadkout-Board bereits Kick-Back-Dioden assembliert, um den Motortreiber vor negativen Spannungsimpulsen zu schützen. Trotzdessen muss die Spannung am Motor über einen Wechselspannungskondensator (ca. 10µF) geglättet werden und das Tastverhältnis (duty cycle) des PWM-Signals berücksichtigt werden, um die Spannung im gewünschten Spannungsbereich von 0,3 - 1V regeln zu können. Dem Datenblatt entsprechend haben wir die Pins VM(VCC) und SLP(SLEEP) mit einem 68 KOhm Pullup-Widerstand verbunden.

Vorerst haben wir uns dazu entschieden den Versuch die Motoren mittels PWM ansteuern zu können erstmal auf Eis zu legen, und die Motoren über die GPIOs anzusteuern.


Ermittlung der idealen Periodendauer des PWM Signals

Wann ist die Periodendauer ideal?

Da ein minimaler Energieverbrauch eine große Zielsetzung für unser Auto ist, haben wir das Wort 'ideal' daran fest gemacht, dass die Motoren mit maximal kurzen High Impulsen gerade noch laufen, die Periode jedoch nicht zu groß ist sodass die Motoren unruhig laufen.

Um den Energieverlust durch negative Spannungsimpulse des Motors beim Wechsel der Eingangsspannung von High zu Low zu minimieren besteht die Möglichkeit das Signal durch geeignete Kondensatoren zu glätten. Durch den Kondensator werden jedoch die Spannungsimpulse des PWM Signals auf die Periodendauer verteilt, und damit entsprechend kleiner. Dies hat den Nachteil das die Spannung bereits bei ca. 30% High Anteil des PWM Signals unter die Einschaltschwelle des Motors fällt und dieser folglich stehen bleibt. Eine zu große Kapazität ist damit aus Sicht eines minimalen Energieverbrauchs von Nachteil! Da nur während der High Impulse Energie verbraucht wird, kann es für unser Projekt von Vorteil sein, die Motoren mit minimalen High Impulsen an zu steuern.

Ein Versuch hierzu zeigt das der Motor prozentual gesehen mit einer maximal langen Periodendauer den geringsten Energieverbrauch aufweist um sich noch drehen zu können. Unsinnig wird dieses Experiment allerdings ab 100mS, da der Motor dann quasi im 100ms Takt angeschubst wird und durch seine Trägheit nicht ruhig rund läuft. Nicht umsonst scheint ein üblicher Wert für kleine Elktromotoren bei einer PWM-Periodendauer von 20mS zu liegen. Bei dieser Frequenz sind zwar noch mindestens 5% High Anteil des PWM Signals nötig, um den Motor noch zu bewegen, dafür läuft er allerdings von 5% - 100% sehr ruhig.

Einige Versuchswerte sind in dieser Tabelle ersichtlich:

opitmales PWM Signal

Die y-Achse gibt die Effizienz der Motoren bei minimalem PWM High Anteil in % an.

Für unsere Motoren hat sich ein 1µF Kondensator bei einer Periodendauer von 20mS als ideal erwiesen.

Implementierung der Motorfunktionen

Mit Hilfe der vorgegebenen GPIO-Funktionen, die die Zephyr Dokumentation zur Verfügung bereitstellt, haben wir die Motoren ansteuern können. Für eine bessere Wartbarkeit des Programms haben wir die Funktionalität für vorwärts, rückwärts, halten, rechts und links in einzelne Funktionen ausgelagert. Das Programm ist aktuell unter Link-zum-Programmcode zu finden.

Berechnung der Drehungen (Implementierung inkl.)

  1. Ellen trägt das ein

Drehzahlmessung

Drehzahlmessung mit Gabellichtschranke

Erste Versuche die Drehzahl über eine IR-Diode QCX48 (950 nm Wellenlänge) und einen Phototransistor SFH309 (380 nm bis 1180 nm) liefern keine stabielen Signale.

Weiterer Versuch mit verschiedenen Gabellichtschranken:

1.) LTH-301-07 und LTH-309-08

(Datenblatt LTH-301-07)

2.) HOA0872

(Datenblatt HOA0872 )


Zu 1.)

Die LTH Gabellichtschranken der Firma LITEON erweisen sich für unsere Drehzahlmessung als untauglich, da der Abstand zwischen IR-Diode und Phototransistor mit 5mm für unsere 1mm Lochscheibe zu groß ist. Außerdem ist das Licht der IR-Diode nicht gut gebündelt, wodurch der Phototransistor bei nicht vollständiger Abdeckung der IR-Diode teilweise leitfähig wird.

Auf diesem Photo sieht man auf der linken Seite wie die Spannung sich langsam erhöht, wenn ein schwarzes Plättchen zwischen IR-Diode und Phototransistor geschoben wird. Zwischen dem ersten erkennbaren Spannungsanstieg und dem voll durchgesteuerten Phototransistor wird mit dem Plättchen ein Weg von fast 3mm zurückgelegt, wodurch die Streuung der IR-Diode sehr deutlich wird. Auf der Rechten Seite sieht man wie die Spannung schwankt wenn man das 1mm dicke Plättchen zwischen Phototransistor und IR-Diode hin und her bewegt.

Gabellichtschranke LTH


Zu 2.)

Wesentlich bessere Ergebnisse erzielen wir mit der Gabellichtschranke von Honeywell HOA0872. Der Abstand zwischen IR-Diode und Phototransistor beträgt hier 3,3mm. Außerdem kann man eine eindeutige Schaltschwelle auf 0,5 mm beobachten, wodurch unsaubere Zwischenwerte für unsere Anwendung ausgeschlossen sind.

Im linken Photo sieht ist ein schwarzes Plättchen zwischen IR-Diode und Phototransistor. Im Rechten wurde das Plättchen entfernt.

Gabellichtschranke Honeywell Gabellichtschranke Honeywell


Skizze:

In der Skizze sieht man wie das Ausgangssignal des Phototransistors über einen LM258N OP im Aufbau als 'Nicht-invertierender Operationsverstärker' unendlich verstärkt wird. Die Verstärkung berechnet sich aus dem 1M Widerstand und dem Vorwiderstand am Negativen Eingang des OP. Da es keinen Vorwiderstand gibt, dieser also gleich Null ist, ist die Verstärkung V=1000000/0 = Unendlich = 3,3V (Versorgungsspannung des OP).

Gabellichtschranke Skizze

Beim Versuch die Signale der Gabellichtschranke über GPIO Polling ein zu lesen ist uns aufgefallen das die Verstärkerschaltung das Signal zwar maximal verstärkt, die Low Impulse bei höheren Frequenzen jedoch nicht unter den benötigten Low Pegel des GPIO des feather boards fallen. Dies wurde durch austauschen der Widerständen am OP angepasst. Das Signal kommt der Gabellichtschranken kommt nun unter den benötigten Low Pegel von 1V und über den benötigten High Pegel von 1,3V.

Gabellichtschranke_onOff Pegel


Messung mit ADC an Analogeingängen, ohne Operationsverstärker

Eine weiter Möglichkeit die Drehzahl auszuwerten bieten uns die Analogeingänge des feather boards. Zum einlesen der Drehzahl könnte man den Phototransistor an einen Analogeingang anschließen und die Schaltschwelle entweder über eine interne oder externe Referenzspannung festlegen. Somit könnte man den Operationsverstärker einsparen dessen einzige Aufgabe es war 'saubere' Rechteckimpulse zu erzeugen. (Ob wir dies tun ist jedoch noch nicht sicher. Ein möglicher Nachteil hierbei könnte sein das wir die Drehzahl 'aktiv' einlesen müssen und nicht über einen Counter der möglicherweise auch im Schlafzustand des feather boards weiter zählen könnte. Ob es sich lohnt den Operationsverstärker einzusparen hängt aber auch davon ob das feahter board im Schlafzustand deutlich mehr als 500µA einsparen kann, da der Verbrauch des LM258N bei 480-510 µA liegt [es wurde einer von 2 verfügbaren OPs des ICs verwendet, weitere Messung folgt])


Die eingebauten Gabellichtschranken

Gabellichtschranke Honeywell oben Gabellichtschranke Honeywell unten


Drehzahlmessung mit Reflexlichtschranke

Nachdem uns neue Motoren mit nur ca. 15 mA (bei 3,3V im Leerlauf) zur Verfügung standen war die Idee irgendwann nur mit Solar zu fahren wieder aufgeblüht. Da unsere ersten Motoren ca. 80 mA (bei 3,3V im Leerlauf) verbrauchten fielen die 20 mA der Gabellichtschranke prozentual nicht so sehr ins Gewicht. Nun aber mehr Strom für die Drehzahlmessung zu verbrauchen als zum Fahren schien uns absolut absurd. Daher begrenzten wir zunächst den Strom der Infrarot Diode auf 13 mA, womit die Amplitude am Ausgang des Operationsverstärkers gerade noch groß genug war um die Ein- und Ausschalt Pegel eines GPIO des featherboards zu erreichen. Eine weiter Idee zur Begrenzung des Stroms war eine Reihenschaltung von Operationsverstärkern, womit man die gesamte Schaltung auf etwa 6 mA begrenzen hätte können.

Da bei den neuen Motoren die Achse des Läufers auf der Rückseite nicht herausgeführt war, überlegten wir mit einer Reflexlichtschranke die Umdrehungen eines Getriebezahnrads zu erfassen. Hierfür wurde ein kleiner Versuchsaufbau mit IR-Diode, IR-Fototransistor und einer Lichtwellenleiter-Y-Weiche gemacht:

Reflexionslichtschranke mit Lichtwellenleiter:

Reflexlichtschranke Reflexlichtschranke ON Reflexlichtschranke OFF

In dem hier verwendeten Lichtwellenleiter (LWL) sind etwa 25 einzelne LWL-Strings. Durch verwenden von nur 2 LWL-Strings könnte man einzelne Punkte bis ca. 0,5mm auf dem Zahnrad detektieren. Ein Nachteil wäre allerdings das die LWL und die Zahnräder entsprechend gegen Licht abgeschirmt werden müssten und die Stromaufnahme höher wäre als bei einer Gabellichtschranke, da hierbei nur das reflektierte Licht zum Photostrom in der Photodiode beiträgt.


Drehzahlmessung mit Hallsensoren

Eine weitere Idee die Drehzahl mit minimalem Stromverbrauch zu ermitteln war es, den Läufer eines ohnehin mit Encoder ausgestatteten Motors durch den Läufer unseres 15 mA Motors zu ersetzen. Um den Schaden zu begrenzen schlugen wir die Achse eines Motors der sowieso etwas 'kratzte' aus dem Läufer heraus. Da diese sehr fest saß wurde der Läufer in eine Halterung eingespannt:

Achsenwechsel Halterung

Um die Achse heraus zu schlagen wurde eine Stahlnadel mit gleichem Durchmesser abgesägt. Leider sind beim heraus schlagen der Achse am Motor mit Encoder die Bürstenkontaktflächen auseinander gebrochen.

Auch beim 15 mA Motor ging die Achse nur sehr schwer heraus. Diesmal wurde die Achse in Richtung der Bürstenkontaktflächen herausgeschlagen um den selben Fehler nicht noch einmal zu machen. Dabei ist sind zu allem Überfluss die Bürsenkontaktflächen von den Spulen abgerissen. Diese konnten aber wieder erfolgreich angelötet werden. Eine Messung der Spulenwiderstände, die alle gleich groß waren, zeigte das alle Spulen wieder guten Kontakt haben.

Die neu verlöteten Motor-Spulen

Achsenwechsel Spule neu verlötet Achsenwechsel Spule neu verlötet mit Bürstenkontaktflächen


Nach erfolgreicher Montage der neuen Achse wurde der Motor wieder zusammengebaut

Achsenwechsel Motor fertig


Das Ergebnis war äußerst enttäuschend: Der neue Motor benötigt nun statt 15 mA 100 mA. Möglicherweise hatte die Achse des auseinander gebauten Motors schon einen Schlag, da dieser bereits zuvor kratzende Geräusche von sich gab. Wahrscheinlicher ist es jedoch das die Achse beim herausschlagen beschädigt wurde, da diese enorm fest saß.


Da nun auch dieser Versuch alles andere als zufriedenstellend war lag die Lösung auf der Hand :)

Ein ca 0,4 mm dicker Magnet

Lösung liegt auf der Hand


Es wurde getestet ob die Hallsensoren noch auf einen winzigen Magneten, der auf einem Zahnrad aufgebracht wurde, reagieren würden. Das Fräsen der Magnete nahm viel Zeit in Anspruch, da diese durch überhitzen ihren Magnetismus verlieren (oder etwas wissenschaftlicher ausgedrückt: Die weißschen Bezirke bei Überhitzung Ihre Orientierung verlieren.)

Die Idee das Zahnrad zu nehmen über dem ohnehin der meiste Platz wäre um den Hallsensor zu montieren funktionierte zwar gut, war jedoch nicht gut durchdacht. Die Drehzahl des gewählten Zahnrads war für eine ausreichend hohe Auflösung viel zu gering. Um den Hallsensor zu montieren wurde eine Ecke der Getriebehalterung abgetrennt. Damit kein Messingspäne ins Getriebe gelangen wurde dieses zuvor mit Frischhaltefolie gut verpackt:


Magnet auf vorletztem Zahnrad

Ecke von Motorhalterung ab - Getriebe verpackt Ecke von Motorhalterung ab


Um nun auch brauchbare Messwerte zu bekommen wurde der Magnet auf das dritte Zahnrad nach dem Motorritzel geklebt, hierfür musste jedoch das Getriebe auseinander gebaut werden und die mittlere Messingplatte der Getreibehalterung ausgeschnitten werden.

Magnet auf innerem Getriebezahnrad

Mittlere Getriebehalterung - Getriebe verpackt Getreibe mit Magnet - Getriebe verpackt

Es wurde eine entsprechende Halterung für den Hallsensor gebaut und der Hallsensor vom Encoder (44E-938) des zerlegten Motors 0,5 mm über dem Magnet montiert.

Der montierte Hallsensor

Hallsensor Halterung Sensor montiert

Das Ergebnis ist einigermaßen zufriedenstellend. Der Hallsensor registriert jede Umdrehung des Zahnrads zuverlässig. Leider kommt man auch mit diesem Zahnrad auf gerade mal 39 Impulse für eine Radnabenumdrehung. Eine doppelte Auflösung wäre durch einen zweiten Magneten auf dem Zahnrad möglich. Es besteht auch die Möglichkeit einen zweiten Hallsensor etwa 150° versetzt zu montieren, würde unser Auto jedoch wieder ca. 4 mA mehr Strom je Hallsensor kosten.


Beim Versuch den zweiten Hallsensor aus zu löten ist diesem ein Beinchen ausgerissen. Daher wurde der nächste Motor wurde dann mit einem AH180-PL-A Hallsensor ausgestattet, der wesentlich sensibler und stromsparender ist (siehe Tabelle). Dank der hohen Sensibilität konnte dieser Sensor sogar eine 0,3 mm dicke Magnetfolie registrieren. Eine passend ausgestanztes und zugeschnittenes Magnetfolienstück war dann aber leider doch zu schwach um den Sensor zu triggern.

Auch das Ergebnis mit einem gefrästen Magneten war leider enttäuschend: Die Entmagnetisierungszeit des Sensors war zu groß um die 'hohe' Geschwindigkeit des Zahnrads zu messen. Bei einer typischen Periodendauer von 75 ms (laut Datenblatt) sollte der Sensor zwar eine Frequenz von 1000ms/75ms = 13,3Hz messen können, übersprang aber regelmäßig die Messungen:

Messung des Zahnrads bei ca. 18 Hz. Der AH180-PL-A Sensor überspringt einige Messungen

AH180_Frequenz_zu_hoch


Es wurde nun ein 3144 Hallsensor eingebaut, der zwar wiederum weniger sensibel ist und auch einen höheren Stromverbrauch hat, dafür aber zuverlässig misst.

Mit einem 3144 Hallsensor funtioniert auch der zweite Motor zuverlässig

Motor mit Molex-Stecker Motor fertig 17Hz_44E-938_und_3144


Zum Vergleich hier noch eine Tabelle mit Kennwerten der Hallsensoren:

Hallsensoren Stromaufnahme
Hallsensor Mit Magnet (Low) Ohne Magnet (High) Gesamtverbrauch mit Motor (3,3V; Leerlauf)
44E-938 2200 µA 1800 µA 18,5 mA
3144 4100 µA 3600 µA 19,6 mA
AH180-PL-A 7 µA 29 µA Sensor Stromverbrauch zu vernachlässigen

1.) 44E-938 und 3144*

(Datenblatt 44E-938 und 3144 )

2.) AH180-PL-A

(Datenblatt AH180-PL-A )

  • 44E scheint zur der Reihe A3144E zu gehören. Es wird daher auf das selbe Datenblatt verwiesen.


Implementierung der Drehzahlmessung

Auch hier wurde mit Hilfe der vorgegebenen GPIO-Funktionen, der Zephyr Dokumentation gearbeitet. Der aktuelle Code ist unter Link-zum-Programmcode zu finden. Die Funktionalität wurde mit einer Kabelbrücke vom 3.3V Port und dem GPIO-Pin getestet.


Messung der maximalen Anzahl Interrupts

Erste Messungen zeigen das die UART Ausgaben des feather boards bei 1 Interruptpin noch bis 138.000 Interrupts/sec funktionieren, bei 2 verwendeten Interruptpins schaffen das board noch 125.000 Interrupts/sec. Bei einer höheren Anzahl Interrupts bekommt UART keine Zeitscheiben mehr zugeteilt.

Ohne UART können sogar bis zu 800.000 Interrupts/sec gemessen werden.


Eine theoretische Annahme über die benötigte Zeit der CPU bei 800.000 Interrupts/Sekunde:

Wenn die CPU 800.000 Interrupts/sec behandeln kann benötigt sie je Interrupt Service Routine 1/800.000 sec. Das heißt sie kann bei 1 Interrupt/sec 0,99999875 sec schlafen. Bzw. bei 300 RPM des Motors, dann 300 Interrupts/sec, 0,99962375 sec schlafen. Folglich wären Interrupts also eine gute Alternative zum counter. Dennoch probieren wir über das PPI (programmable peripheral interface) einen Pin des boards an einen Counter anzuschließen, da die CPU bei jedem Interrupt geweckt wird, ein Counter hingegen zählen kann ohne die CPU zu wecken.


Versuchsaufbau zur Bestimmung der maximalen Anzahl Interrupts/Sekunde:

Die CPU wacht mit 1Hz auf und gibt die gemessenen Interrupts an Pin A4 (Right) und A5 (Left) aus. Der Funktionsgenerator erzeugt eine Frequenz von 120 kHz. Die gemessenen Werte sind in RPS (rounds per second = Hz) angegeben.

Versuchsaufbau Motorspeed_120k.jpeg

Platinenaufbau

Eagle-Schaltplan anfertigen

Zur Planung des Platinenlayouts und insbesondere der Pinbelegung des feather boards haben wir begonnen einen Schaltplan mit eagle zu erstellen. Hierbei haben wir auch kontrolliert, das die einzelnen Module technisch zusammen arbeiten können, da die jeweils verbauten ICs unterschiedliche Spannungen benötigen. Glücklicherweise sind die Breakout-boards bereits mit Spannungsreglern und Logikpegelwandlern bestückt, womit der Betrieb des Bussystems als auch des Gesamtsystems mit einer Betriebsspannung von 3,3V möglich ist. Da die I/O's des feather boards eventuell nicht ausreichen, werden wir diese voraussichtlich über I2C-Schieberegister erweitern. Ob die I/O's ausreichen hängt vorerst noch davon ab, wie viele Helligkeitssensoren tatsächlich installiert werden und ob wir diese einzeln über die Analog-Eingänge des feather-boards einlesen, oder auf Helligkeitssensoren mit direkter Busanbindung zurückgreifen.


Hier ein vorläufiger Plan und ein Entwurf wie die Boards ungefähr aussehen werden: ...es wird noch ein paar Änderungen und Erweiterungen geben.


Änderungen:

  Version 17.12.2019: Zweiter I/O Expander. Wannenstecker auf Motherboard umgedreht. (Keine Änderungen an featherboard Pinbelegung.)
  Version 05.02.2020: Änderung an feahterboard Pinbelegung (Motor Speed Left -> A3, Motor Speed Right -> A4, LDR1 -> A0, LDR2 -> A1, LDR3 -> A2)
                      Änderung an Spannungsversorgung (Provisorische Taster Schalter kombination zum Einschalten des Boards)
                      Operationsverstärker von Motor Drehzahl Messung entfernt. -> Nur noch 150k Pullup für Hallsensoren zur Drehzahlerfassung.
                      I2C Pullup.
                      Anschluss für Kondensatoren zur Glättung des PWM Signals.
                      Jumper zur Wahl zwischen Zusatzversorgungsspannung für Maus oder allgemeine Versorgungsspannung.
                      Jumper an Coulomb Counter waren vertauscht.
  Version 24.02.2020: Neues Mouse Board mit Boost Converter, Level Shifter, Hexbuffer, ON/OFF und Start Button.
                      Verdrehte Stiftleisten gedreht.
                      Leiterbahnen (händisch) geroutet, sodass alle Lötstellen auf der Unterseite der Platine sind
                      und alle Leiterbahnen maximal weit voneinander entfernt sind.
  Version 28.02.2020: Änderungen nachdem die Platinen hergestellt wurden.
                      Coloumb Counter Battery OUT und Coloumb Counter Solar OUT Jumper gedreht (Polarität verdreht).
                      Maus nutzt kein I2C -> daher LDR2 und LDR3 vom Wannenstecker entfernt und die Anschlüsse ASCL, ASDA des 3V3->5V Levelshifters
                      an deren Stelle angeschlossen. -> ASCL ist nun mit GPIO A1 und ASDA auf GPIO A2 des feather boards verbunden.
                      DRV8833 Motortreiber hatte keine Versorgungsspannung und der SLP (sleep) Pin war nicht auf 3V3 angeschlossen.
                      Der SCL Pin des I2C Busses war nicht verbunden, da im laufe der Entwicklung das Rastermaß des Eagle Schaltplans geändert wurde
                      und erst bei starker Vergrößerung des Schaltplans sichtbar wurde das die Leitung nicht am gewünschten Pin des Featherboards
                      angeschlossen war. -> Ein Sinnvolles Rastermaß für den Schaltplan ist 2,54 mm (0,1 inch). Für das Board Design 0,1 mm.
  Version 06.03.2020: Spannungsversorgung geändert. JP20.1 (Batterie Coloumb Counter Ausgang Plus) wird ist über den ON/OFF Schalter geschleift.
                      Damit kann die Versorgungspannung für das Board ausgeschaltet werden während der Akku weiterhin vom Solar Click geladen wird.
                      Der Solar Click kann nur über den START Button gestartet werden, kann aber nicht ausgeschaltet werden.
                      Der gesamte Energieverbrauch des Autos, inklusive Energieverbrauch des Solar Clicks wird nun über den Coloumb Counter Battery gezählt.


Datei:ITS-E Circuit Diagrams.pdf

Datei:ITS-E Circuit Diagrams Mouse.pdf


ITS-E_Motherboard_V1-3.png ITS-E_Mouseboard.png

(Links: ITS-E Energy Board, Rechts: ITS-E Motherboard)

Implementierung der Hauptsteuerungs API

Implementierung des ersten Meilensteins

Für die Implementierung des ersten Meilensteins wurde vom Systemarchiteckturteam die generelle Kommunikation zwischen den Teams festgelegt. Hierbei wird ein Job-System verwendet, womit jedes Subteam seine Jobs abfängt und abarbeitet. Während dieser Jobs ist es möglich mittels Mailboxen die Informationen der anderen Teams abzufragen. Die dazugehörige Implementierung findet sich aktuell unter diesem Link.

Implementierung und Erfüllung des zweiten Meilensteins

Bei der Implementierung des zweiten Meilensteins haben wir das Chassis des Prototyps für den ITS-E zusammen gebaut. Hierbei ist aufgefallen, dass das Auto, wenn es durch die Motoren angetrieben wurde leicht schräg fährt. Nach einigen Optimierungen am Chassis waren die Abweichungen nicht mehr ganz so groß - jedoch noch sichtbar. Das könnte durch nicht "echt-parallel" zueinander angebrachten Motoren und/oder der ungleichmäßigen Drehung der Motoren und/oder an der unterschiedlichen Spannungsversorgung durch den Motortreiber liegen. Die eigentliche Implementierung der Motorfunktionen war ja schon im ersten Meilenstein behandelt, für den zweiten Meilenstein haben wir hier nichts anpassen müssen. Das erbrachte Ergebnis ist unter diesem Link zu finden.

Implementierung und Erfüllung des dritten Meilensteins

Für die Modifizierung der Implementierung auf die Anforderungen des dritten Meilensteins, wurde die Funktion nach links zu drehen implementiert. Das Drehen der Räder wurde mit dem Stillstand des jeweils anderen Rads implementiert. Da die Motoren für die Räder noch nicht mit PWM angesteuert werden, fährt der Roboter noch leicht schief. Die dazugehörige Implementierung findet sich aktuell unter diesem Link.

Aktivitätendiagramm

Das folgende Aktivitätendiagramm ist für den gesamten Ablauf der Antriebs API gedacht.

Image from iOS.jpg

Kommunikation

Quellen