BWP-WS19-02/Feindesign

Aus Verteilte Systeme - Wiki
Wechseln zu: Navigation, Suche

Antrieb, Mechanik & Kommunikation

Antriebs API

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

Image from iOS.jpg

Sensoren & Kartierung

Adafruit BNO055 Absolute Orientation Sensor

Der BNO055-Sensor beinhaltet drei Accelerometer, drei Gyroscope und drei Magnetometer (jeweils X-, Y- und Z-Achse). Außerdem steht ein ARM-Cortex-M0 zur Verfügung, welcher mittels Sensor Fusion direkt auswertbare Daten liefert.

Folgende Daten stehen als Output zur Verfügung:

  • Absolute Orientation (Euler Vector, 100Hz)
Three axis orientation data based on a 360° sphere
  • Absolute Orientation (Quaterion, 100Hz)
Four point quaternion output for more accurate data manipulation Angular
  • Velocity Vector (100Hz)
Three axis of 'rotation speed' in rad/s
  • Acceleration Vector (100Hz)
Three axis of acceleration (gravity + linear motion) in m/s^2
  • Magnetic Field Strength Vector (20Hz)
Three axis of magnetic field sensing in micro Tesla (uT)
  • Linear Acceleration Vector (100Hz)
Three axis of linear acceleration data (acceleration minus gravity) in m/s^2
  • Gravity Vector (100Hz)
Three axis of gravitational acceleration (minus any movement) in m/s^2
  • Temperature (1Hz)
Ambient temperature in degrees celsius

Nachfolgendes Bild zeigt einen Testaufbau mit BNO055 und einem nRF52 Feather auf einem Steckbrett. Das nRF52 Feather kommuniziert über I2C mit dem BNO055.

Testaufbau mit BNO055 und einem nRF52 Feather auf einem Steckbrett

Um den Sensor für das Projekt zu benutzen, musste ein eigener Treiber entwickelt werden. Dieser basiert im wesentlichen darauf, dass über I2C-Aufrufe von Zephyr in bestimmte Register des Sensor geschrieben bzw. von ihnen gelesen wird. Anhand des Datenblatts wurde bestimmt welche Register zu welchem Zweck dienen. Daraus ergab sich eine API, welche zum jetzigen Zeitpunkt alle benötigten Funktionen des Sensors abbildet, jedoch nicht den selben Umfang wie die Bibliothek von Adafruit aufweist.

Adafruit Learning Systems

BNO055 Datasheet

Kalman Filter

Das Grundprinzip des Kalman Filter ist im Grundlagenkapitel beschrieben. Die eigentliche Implementierung des Filters für das Projekt wird im Folgenden genauer erläutert. Zum besseren Verständnis soll nachfolgendes Diagramm dienen. Der Kalman Filter ist auch eine Art der Sensorfusion, deshalb ist das Modul, dass die Filterung durchführt auch als Fusionmodul betitelt.

UML-Diagramm zur Implementierung des Kalman Filters

Das Antriebsmodul legt seine aktuellen Daten über die zurückgelegte Strecke und die Geschwindigkeit in die msgbox_fusion_in ab. Dazu werden die Funktionen benutzt, welche vom Systemarchitekturmodul für die Benutzung der Messageboxen zur Verfügung gestellt werden. Dann fragt das Antriebsmodul die Filterung beim Fusionmodul an. Das Fusionmodul liest die Daten aus der msgbox_fusion_in aus und führt die Filterung durch. Für Details über die Filterung können die Kommentare im Code gelesen werden und die Hauptreferenz aus dem Grundlagenkapitel zu Rate gezogen werden. Anschließend legt das Fusionmodul die gefilterten Daten in der msgbox_fusion_out ab und meldet die Fertigstellung des Jobs an das Antriebsmodul. Abschließend ließt das Antriebsmodul die gefilterten Daten aus der msgbox_fusion_out.

Positionbestimmung mit einer optischen Maus

For the determination of the X-Y position we used a PS/2 optical mouse.Thanks the "Computer Mouse Project" from hofaciens.de.We were able to read the X-Y positions of the mouse using an Arduino UNO:
mouse-uno-conections

Basic overview of the PS/2 protocol of a mouse

The PS2 mouse uses a bidirectional synchronous serial communication. Where both lines(Data and Clock) are open collector. If nothing is done they are in “idle” state/high impedance(two external or internal pull up resistors pull the lines to high state).
The Clock signal is always generated by the Mouse device. In order to get Clock signals, the Host(Micro-controller) need to put the bus lines in “request to send” mode: Put the Clock bus to low, wait at least 100us, put the Data bus low and release the Clock. Now commands can be sent to the mouse.

There is a command set that may be sent to the mouse or that the mouse may sent to the Host. For example, for this implementation the following commands were used:
Reset Mode 0xFF: set default values.
Remote Mode 0xF0: mouse send data only when the
Read Data 0xEB command is received.

  • Host to Mouse Communication


Host to mouse.png

Data is sent in a 12 bit frame:

-start bit
-data byte : For example the reset command.
-Parity bit
-stop bit
-acknowledgment bit


  • Mouse to Host Communication


Mouse to host.png

Data is sent in a 11 bit frame:

-start bit
-data byte: For example data byte with the X or Y position.
-Parity bit
-stop bit.

Implementation using the "feather_board"

For the implementation using the feather board, some problems popped up:
-Voltage of the nRF52 is 3.3v, mouse is 5v.
-The Data and Clock signals from the mouse are both open-collector. Zephyr OS does not support open collector configuration at this moment.

To solve this, two additional modules were added:
-Level Conversion Module 5-3v System.Lvl converter.png
-SN74LS07 IC with Open-Collector output. 74LS07_Datasheet

Nrf52 mouse.png

Nrf52 mouse breadboard.png


Test Cases

Test Case Description Expected-Actual Results Pass/Fail
01 Check Measurements against a Physical Object 130mm - 130mm
128/132mm - 130mm
NA
02 Check Measurements against a Physical Object with appropriate equipment NA NA
03 Check Measurements when "ITSE" fully assembly is complete NA NA
  • Test Case 01

In order to emulate a Linear movement some Physical Objects were used.

Test1.png

Test2.png

Test3.png

Test01mouse.png


Note that for a better test perform a mechanical system for the linear movement should be used.

References

THE DESIGN AND DEVELOPMENT OF A PS/2 MOUSE CONTROLLER AND MULTIPLE I/O BUS SYSTEM INTEGRATION[1]
The PS/2 Mouse/Keyboard Protocol

Simultaneous localization and mapping(SLAM)

Slam is the Estimation and Mapping of the positions of the robot, in an Unknown environment. This is a hard problem because, in order to estimate a good robot position a Map is needed, and for a good Map the robot positions are needed.

The SLAM for the ITSE is a very basic approach:
Two 2D Cartesian Coordinate Systems will be use:

  • For the absolute positions, where Origin punt (0,0) is the Charging Station. Global Coordinates
  • For the Local positions of the ITSE, where the IMU axis XY are the ITSE axis. Local Coordinates

Self Localization

For the determination of the ITSE absolute position, a translation of the local coordinates to global coordinates is needed. This can be achieved by doing a translation and rotation operation. These operations can be done by using “homogeneous coordinates”. For our 2D case a 3×3 Rotation and Translation Matrix are necessary:

Itse position.png

This example is based on Embedded Robotics by Thomas Bräuln

Path Planning

Distance to Charging Station:

This is done by getting the magnitude of the vector of the Charging Station(0,0) to the actual absolute position. If ISTE is in X or Y axis (X== 0 or Y==0) the distance will be the absolute value of X or Y. Otherwise, the distance will be the result of the Pythagorean theorem operation of X and Y.

Direction to Charging Station:

This is done using the absolute position, polar coordinates, arc tangent and right-angled triangle properties.
- Note that IMU has a fixed reference for the angles:

Itse direction.png

Mapping

The mapping approach is the simplest part of the ITSE_SLAM. It is just an Array of Structs where the visited points that are valuable to store will be saved.

VL53L0X Time-Of-Flight Distance Sensor

Der VL53L0X Time of Flight (ToF) Laser Distanzsensor (Link zur Herstellerseite) kann Distanzen bis zu einer Entfernung von 2m genau bestimmen. Angesprochen wird der Sensor über I2C, was sich jedoch bei der Verwendung mehrerer Sensoren als ziemlich schwierig erwies. Dabei traten vorlegende Probleme auf:

Die I2C-Adresse des VL53L0X kann über I2C programmiert werden, jedoch kann der Sensor sich diese Adresse nicht dauerhaft merken. Bei Neustart des Roboters verlieren somit alle Sensoren ihre gesetzte I2C-Adresse und nehmen die Standard Adresse 0x29 an, was zu Chaos auf dem I2C-Bus führt. Die Sensoren haben einen XSHUT-Pin, über den sie sich ausschalten lassen und den GPIO1-Pin, über den man Interrupts an den Sensor senden kann. Der Hersteller der Sensoren gibt an, dass man die Sensoren über diese Pins alle ausschalten, anschließend nacheinander wieder einschalten und dann über den GPIO1-Pin interrupten soll, um dann die I2C-Addressen setzen zu können. Dies hat in der Praxis auch gut funktioniert, jedoch gab es dann das Problem, dass zu jedem Sensor zwei zusätzliche GPIO-Pins auf unserem Feather-Board belegt werden würden. Da wir 6 ToF-Sensoren geplant hatten, wären das insgesamt 12 zusätzliche GIOP-Pins die belegt worden wären.

Als Abhilfe dafür haben wir zwei PCF8574N 8 Bit I2C GPIO Portexpander verwendet, einer der Portexpander wird für alle XSHUT-Pins und der andere wird für alle GPIO1-Pins der Sensoren verwendet. Dadurch lassen sich alle ToF-Sensoren nacheinander über I2C starten und ihre I2C-Adresse neu setzen.

Zephyr hat eine eigene Sensor-API, die das Handling und die Integration von Sensoren in das System vereinfachen soll. Es gibt auch bereits implementierte Treiber für unseren ToF-Sensor, jedoch wird in diesem Treiber nicht berücksichtigt, dass man auch mehrere dieser Sensoren mit unterschiedlichen I2C-Adressen initialisieren und verwenden können soll. Hierfür wurde der ToF-Sensoren Init-Prozess, um das nacheinander Starten der ToF-Sensoren und das Vergeben der I2C-Adressen erweitert. Des Weiteren wurden noch einige Funktionen zum vereinfachten Abfragen der Sensorwerte bereitgestellt und eine Mailbox eingerichtet, die permanent alle Sensorwerte bereitstellt.

Die Treiberimplementierug und Konfiguration der der ToF-Sensoren ist zu finden unter:

 Verzeichnis:
 /bwp_ws19/zephyr/drivers/sensor/vl53l0x
 
 Konfiguration und Funktionen zur Abfrage der Sensoren:
 /bwp_ws19/zephyr/drivers/sensor/vl53l0x/vl53l0x_ITSE.h
 
 Implementierung des Treibers:
 /bwp_ws19/zephyr/drivers/sensor/vl53l0x/vl53l0x.c

Testaufbau aller ToF-Sensoren auf einem Breadboard:

ITS-E ToF Sensoren Testaufbau

Die ToF-Sensoren sollen wie folgt auf ITS-E angebracht werden:

         TOF0    
 TOF1  ________  TOF2
      | Front  | 
      |        |
 TOF3 | ITS-E  | TOF4
      \        /
       \ ____ / 
         TOF5

ITS-E ToF Sensor kompletter Aufbau

Systemarchitektur & Energiemanagement

Kommunikation zwischen einzelnen Teilmodulen

Kommunikation zwischen Threads [Team Systemarchitektur]

Jeder Thread, der etwas Kommunizieren möchte, muss dafür entsprechende Mailboxen erstellen

und mithilfe eines Info Headers für andere sichtbar machen.


Veranschaulichung der Kommunikation zwischen Modulen/Threads


Übersicht der Position des Verhaltensmoduls [Team Systemarchitektur]

Veranschaulichung der Aufgabe des Verhaltensmoduls

Thread übergreifende Motorsteuerung

Da die Geschwindigkeitsregelung in kurzen Intervallen geschieht und nicht erst nachdem das Auto sein Ziel erreicht hat wurde die Geschwindigkeitsregelung und der Nachrichtenaustausch wie folgt geplant:


Steuerung der Motoren [Team Antrieb Mechanik]

Motor_steuerung


Änderung der Geschwindigkeit [Team Sensoren]

Kalman_Motorsteuerung

Wichtig: Das Diagramm zur Geschwindigkeitsänderung zum Team Sensoren wurde praktisch nicht umgesetzt! Dies ist ein möglicher Ansatz, falls man Geschwindigkeitsänderungen vorsieht, um vorgegebene Distanzen exakter umzusetzen. Da bei diesem Projekt jedoch die Geschwindigkeiten der Motoren nur verändert werden, um die Motoren zu synchronisieren, findet das oben abgebildete Verfahren hier keine Anwendung.