Roboter auf Basis Rover-5 chassis

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)



  • Aufgrund eines Vorschlages hier im Forum stelle ich mein Projekt hiermit öffentlich vor:

    Ich werde diesen Eintrag jeweils wöchentlich aktualisieren und bitte Euch Diskussionen unter diesem Link zu führen und nicht im Projekt.

    Das Recht der Veröffentlichung dieses Inhalts an anderen Orten im Internet, aber auch drucktechnisch, behalte ich mir ausnahmslos vor. Die Inhalte dürfen lediglich für private Zwecke verwendet werden.


    Prolog

    Ich bin pensionierter Ingenieur für Elektrotechnik und Informatik und habe mir dieses Projekt ausgesucht um meine grauen Zellen flott zu halten. Es ist die Fortsetzung meiner Programmieraktivitäten nachdem ich ein Kartenspiel (Schafkopf) in Python realisierte. Ich bin nicht der Typ der Spekulationen veröffentlicht, die hier vorgestellten Ergebnisse sind also nach bestem Wissen und Gewissen getestet und dokumentiert.

    Warnung1: So ein Projekt geht schnell ins Geld, auch wenn diverse Komponenten für weniger als 1$ zu bekommen sind. Mit Anschaffungskosten im Bereich um 1000 EUR sollte man rechnen, dazu gehören auch Literatur und das eine oder andere Werkzeug. Man sollte auch etwas Bastelbegabung mitbringen, denn es gibt einiges zu sägen, bohren, schrauben, löten.

    Warnung2: Das Projekt beschreibt einen autonomen Roboter. Die theoretischen Grundlagen für Navigation und Kartierung sind hohe Mathematik, um die Lösungen nachvollziehen oder sogar Änderungen vornehmen zu können bedarf es einiger Vorkenntnisse. Man sollte auch gewöhnt sein englische Literatur zu studieren und in verschiedenen Sprachen zu programmieren (C, Python).

    Ermunterung: Wer von den vorgenannten Voraussetzungen weniger oder keine mitbringt, ist nicht von vorne herein zum Scheitern verurteilt, aber er/sie hat einen steinigen Weg vor sich. Die hier gegebenen Informationen können dazu dienen die Steilheit der Lernkurve etwas zu verflachen.


    Erkenntnis: Die von mir ausgewählte Hardware leistet nicht das, was ich erwartet habe.


    1. Das Rover5 Chassis hat enorme mechanische Toleranzen und ist nicht in der Lage eine stabile Geradeausfahrt sicherzustellen. Ich musste die PWM Ansteuerung ca. 30% asymmetrisch vornehmen, damit das Fahrzeug geradeaus fährt. Das hat zur Folge, dass die Odometrie Daten verfälscht werden, da nun eine Seite mitgezogen wird. (Derzeit ist nur ein Geber in Betrieb)


    2. Die Odometrie Daten weichen zwischen dem linken und dem rechten Geber bereits auf dem Prüfstand erheblich ab. Der Lieferant hat mir daraufhin ein Ersatzchassis zur Verfügung gestellt.


    3. Der Einsatz der US Sensoren (US-015) erweist sich als trickreich. Die Werte können mit justieren der Ansteuerungszeiten auf eine Fehlerrate von ca. 20% (out of range) gebracht werden. Durch Mehrfach Messung und Mittelwertbildung kann der Wert optisch in einem Bereich +- 6 cm gehalten werden. Die Absolute Messung weicht jedoch gröber ab und ist durch die ausgefilterten Falschmessungen zeitlich nicht repräsentativ. Für die Verwendung als Hindernis Detektor ist das genügend. Mein Anspruch ist aber zu erkennen ob ein Hindernis im Restfahrweg von einem Navigationspunkt zum nächsten existiert. D.h. ich erwarte eine Genauigkeit im Messbereich von 1 bis 8 m (hin und zurück) von +- 0.1m. Das leistet dieser Geber absolut nicht bzw. nicht mit konstanter Qualität über die Zeit. Laser Sensoren mit Industrie Qualität kosten pro Stück 400-500 EUR, das möchte ich dafür nicht ausgeben, die Baugrösse dieser Sensoren ist auch nicht akzeptabel.


    4. Die Verwendung eines Kompasses zur Navigation in einem Gebäude ist nicht ohne weiteres möglich. (siehe auch die Dokumentation weiter unten)


    Fazit: Die von mir ausgewählte Hardware ist für ein solches Projekt ungeeignet! Es handelt sich um Billigware aus dem fernen Osten.


    Wie hat es angefangen?

    Einer meiner Enkel äusserte eines Tages den Wunsch, einen Roboter zu bauen. Er dachte dabei an etwas das er in Filmen gesehen hatte. Er ist erst 12 und kann noch wenig Englisch. Programmiert hat er ausser "Hello world" in Python noch nicht. Ich begann also seiner Vision etwas realistische Züge zu geben und habe Anforderungen spezifiziert, denn das kann ich besonders gut aus meiner Zeit als IT project manager. Bei meinen Recherchen stiess ich dann in diesem Forum auf das Projekt von meigrafd (Link). Das Projekt hat mir geholfen zu den wichtigsten Quellen zu finden.



    Projektziele

    Wenn man ein Flugzeug erfinden möchte und es das vorher noch nicht gab, muss man eine Vorstellung davon haben, dass fliegen überhaupt möglich ist und welche Teilprobleme dazu zu lösen sind. Man benötigt eine geeignete Struktur, nach der man den Plan vorwärts treiben kann. Der Plan muss dabei gemäss dem aktuellen Kenntnisstand immer wieder an die realistisch verfügbaren Möglichkeiten (technisch und finanziell) angepasst werden.

    Mein oberstes Strukturelement ist also „Ein Roboter“ und nun müssen, je nach Verfügbarkeit von Ressourcen, Anforderungen und Komponenten definiert werden.

    Dazu habe ich im Internet recherchiert, wer geeignete Komponenten für den Roboterbau zu bezahlbaren Preisen liefert. Es gibt viele Roboterbausätze zu sehr niedrigen Preisen im Angebot, allerdings haben alle Einschränkungen, die ich nicht haben wollte. Ich möchte eine generische Lösung die auch wachsen kann, kein Spielzeug. Meine minimale Spezifikation dabei war:

    Die Lösung soll sich autonom, auf Rädern bewegen und Sensoren haben, die den Bewegungsverlauf und vor allem Hindernisse erkennt! Dabei bin ich auf die nachstehenden Komponenten als Grundlage gestossen und werde an diesen das ganze Projekt ausrichten:

    https://robosavvy.com/store/ bietet ein Fahrzeug, eine Antriebssteuerung und einen Arduino Microcontroller als Bundle für ca. 122.- Pfund incl. Versandkosten an: Dagu Rover-5

    Rückblickend hat sich die Entscheidung für die Variante mit 4 Motoren bewährt. Das Gesamtgewicht des Fahrzeugs beträgt immerhin 2,7 kg.


    Anforderungen an die Hardware

    Stromversorgung

    • Motor Control Board 7.5 V (über einen Spannungswandler an der 9.6V Batterie)
    • Motor Control Board “VCC/Gnd” über Arduino 5V versorgt
    • Raspberry mit 5V Powerbank 20‘000 mAh 2.1 A Ausgang (VOLTCRAFT)
    • Arduino mit 8x 1.2 V = 9.6 V (7.2 .. 12 V) der Antriebsbatterie (Arduino nur über USB versorgen genügt nicht, die I/O können 40mA pro Stift Last tragen das wären für ca. 30 I/Os 1.2 A)
    • 2 poliger Miniaturschalter für 7.5 V und 9.6 V


    Sensoren

    • Das Motor Control Board liefert pro Motor ein 0..5 V Signal mit 1 V/A
    • Batterieüberwachung über Analogeingänge (0..5V) für höhere Spannungen 1:1 Spannungsteiler verwenden
    • [font="Arial"]U[/font][font="Arial"]ltraschall[/font][font="Times New Roman"] [/font]Distanzmessung 2cm bis 7m (Winkel <= 15 Grad)
    • Infrarot Distanzmessung als Redundanz zu US abwärts 10cm bis 80 cm
    • Kompass mit Auflösung 0.1 Grad, Neigungs- und Rollwinkel
    • Wegerfassung über die Encoder des Antriebs
    • Kamera fest montiert, direkt an Raspberry pi 2 betrieben


    Kommunikation

    • W-LAN Adapter
    • USB Kabel zwischen Raspberry und Arduino
    • Sprachausgabe


    Chassis

    • Das Fahrzeug bietet 4 Befestigungslöcher für eine Trägerplatte an. Die Trägerplatte habe ich aus 5mm Acrylglas angefertigt. Ebenso den Träger für Kompass, Schalter, Ultraschall Höhenmessung und den Raspberry. Bevor man beginnt Löcher zu bohren sollte man alle Teile auf dem Tisch liegen haben und eine Zeichnung anfertigen. So vermeidet man alles mehrfach umzukonstruieren, weil ein Bauteil nicht da hinpasst wo man es angedacht hatte.
    • Die Raupen können auch durch Räder ersetzt werden, das sollte man bei der Konstruktion der Trägerplatte und der Platzierung von Sensoren berücksichtigen.


    Literatur zum Thema
    /1/ Raspberry Pi, Kofler, Kühnast, Scherbeck, Gallileo Press Bonn, 2014
    /2/ Python 3, Ernesti, Kaiser, Gallileo Press Bonn, 2012
    /3/ Pro Git, Chacon, Straub, Springer New York
    /4/ Semantische Kartierung und Navigation für mobile Roboter, Uhl, BoD-Books on Demand, Norderstedt 2014
    /5/ FastSlam2.0, Link
    /6/ JQuery, Vollendorf, Bongers, Gallileo Press Bonn, 2014

    Anforderungen an die Funktionen

    Ebene Arduino

    • Messen von Analogwerten
    • Messwertverarbeitung (0 Punkt Unterdrückung, Fertigwertbildung, Grenzwertprüfung, lineare Regression)
    • Lesen der Antriebs Encoder per Timer Interrupt
    • Lesen der Kompasswerte (0 Punkt Unterdrückung, Glättung)
    • Messen der Hindernisabstände (2 cm bis 7m) per US Sensoren (45 Grad vorne links/rechts, voraus, abwärts, nach oben,)
    • Messen von Wandabständen mittels US Sensoren seitlich links/rechts
    • Elementare Steuerkommandos über USB Schnittstelle ausführen
    • Überwachung der Kommunikation (W-LAN und USB)
    • Bildung und Ausführung eines Notstopp Signals
    • Übertragung der Daten über die USB Schittstelle
    • Atomatisiertes Drehen um 45 bzw 90 Grad, oder in eine bestimmte Richtung nach Kompass
    • Regeln der Geradeausfahrt


    Ebene Raspberry pi 2

    • W-LAN Kommunikation
    • Kamerabild alle 0.5 Sekunden speichern
    • W-LAN überwachen und Ergebnis an USB Schnittstelle senden
    • Datenstrukturen (Objekte), um die Messdaten des Arduino zu speichern, bereitstellen
    • Alarmliste mit Klartexten der Störungen
    • Webserver für die Bedienung
    • Sambaserver für Softwaretransport vom PC auf den Raspby
    • 2D Kartenmodell für eine Wohnung auf einer Ebene
    • Darstellung der Karte
    • Algorithmus für die Ermittlung der Deviation
    • Algorithmus für Zielfahrten
    • Darstellung des Planpfads in der Karte
    • Neuberechnung des Planpfades wenn ungeplante Hindernisse auftauchen
    • Sprachausgabe für Störungsmeldungen

    Ich bin mir bewusst, dass einige der Ziele hoch gesteckt und nur längerfristig erreichbar sind! Für die Kartierung und Navigation habe ich bisher lediglich Literatur in den Händen, die das Ziel erreichbar erscheinen lässt.


    Konzept

    (Wer ohne Plan versucht ein Ziel zu erreichen, sollte sich nicht wundern, wenn er dort ankommt wo er nicht hin wollte)


    Als Schichtmodell betrachtet, wird die unterste Ebene die der Aktoren und Sensoren sowie der Motorsteuerung sein. Darauf aufbauend befindet sich ein Arduino mega, der die Erfassung der Messdaten und deren Aufbereitung wie Störunterdrückung, Glättung soweit erwünscht und die Grenzwertprüfung enthält. Der Arduino kann elementare Befehle umsetzen, überwacht die Kommunikation und bildet selbst ein Notstopp Signal. Eigenständig führt der Arduino nur die Turn Kommandos aus, bis der geforderte Drehwinkel erreicht ist und den Notstopp sowie die Regelung der Geradeausfahrt im Automatikbetrieb.

    Hierzu läuft der Arduino in der Hauptschleife mit einer Verzögerung von <500 ms. Ein Timer Interrupt mit 1 ms dient der Abtastung der Encoder Signale für die Wegerfassung (Odometrie).

    Befehle der übergeordneten Ebene (PC oder Raspberry):

    • Stop, ForwardSlow, ForwardHalf, ForwardFull, SteeringAhead, SteeringLeft, SteeringRight
    • TurnSlow45Left, TurnSlow45Right, TurnSlow90Left, TurnSlow90Right, TurnTo angle
    • W-LanReady
    • EncoderReset
    • Amplifier on/off
    • Align


    Zustandsdiagramm_1.pdf

    Die Messdaten werden an die USB Schnittstelle geliefert und die Kommandos können über die Arduino Konsole eingegeben werden. Kommunikationsgeschwindigkeit ist z.B. 38.4 kBaud.

    Ohne darüber liegende Intelligenz kann damit der Roboter bereits am PC über ein USB Kabel direkt bedient werden.

    Hier noch der Algorithmus für die Regelung der Geradeausfahrt:

    Es sollen die Werte der seitlichen Distanzsensoren in einem 10 plätzigen Schieberegister gesammelt werden. Aus den Werten wird eine Regressionsgerade berechnet. abhängig vom Wert (a = 0) bzw. dem Vorzeichen (+ - a) der gefundenen Funktion (f = ax + b) wird ein Steuerbefehl links rechts oder geradeaus abgeleitet.

    Forward direction controller.pdf

    Die nächste Ebene besteht aus dem Raspberry pi 2, der für die höheren Aufgaben in Python programmiert wird.


    Zunächst benötigen wir die USB Schnittstelle zwischen Arduino und Raspberry respektive PC.


    Dazu habe ich mir ein Test-script (siehe Implementierung) gebaut, das die Schnittstellenfunktion abbildet. Das Script liest die Schnittstelle und gibt die Daten auf die Shell aus. Fällt die Schnittstelle aus bleibt das Script stehen bis die Schnittstelle wieder bereit ist und läuft dann weiter. (das kann man mit Stecker ziehen und wieder einstecken testen)


    Als nächstes wollen wir diese Schnittstellensoftware als unabhängigen Prozess laufen lassen. Das Konzept sieht Multi processing vor. D.h. Die Einschränkungen des Multi threading werden vermieden, es laufen echt getrennte Prozesse simultan möglicherweise sogar auf unterschiedlichen Prozessorkernen.

    Architektur:
    Raspberry Architektur.pdf

    Der nächste Miniatur Prozess ist die Audio Ausgabe. Störungsmeldungen werden mit einer Roboterstimme auf Lautsprecher ausgegeben (Spassfaktor!). Um Energie zu sparen, wird der Verstärker über einen Digitalausgang und mittels eines FET Transistors nur bei Bedarf eingeschaltet.

    Weitere Prozesse werden für die Status- und Messwertverarbeitung, sowie die Alarmliste eingerichtet. Die Alarmliste bleibt dadurch auch bei grösserem Meldungsaufkommen jederzeit schnell blätterbar und quittierbar.

    Das User Interface könnte etwa so aussehen:

    User Interface.pdf

    Für die Erstellung des Bedienpanels kommt ein Namensschema für die Datenpunkte zum Einsatz. Damit kann die Meldungs- und Messwertverarbeitung generisch die Daten erzeugen, die zum Webserver gesendet werden müssen.

    Grundsätzlich können fast alle Properties der Statusliste und der Messwertliste als Datenpukt konstruiert werden. Eine Besonderheit stellen zusätzlich abgeleitete Datenpunkte dar, mit denen die Styles gesteuert werden. Messwerte werden damit abhängig von Grenzwertüberschreitungen eingefärbt und Grafiken oder Buttons ebenfalls.

    Id Schema für die Datenpunkte in der Panel.html


    Für die Kartierung habe ich mir folgende Überlegungen gemacht:

    Navigation beschäftigt sich mit Methoden zur Bestimmung der aktuellen Position und den Aktionen, die notwendig sind von der aktuellen Position aus eine Zielposition zu erreichen. [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]Für den Roboter ist es also wichtig möglichst genau zu wissen wo er jetzt ist. und mit welchen Manövern er ein Ziel erreichen kann. Dazu benötigt er so etwas wie Leuchttürme (Navigationspunkte), an denen er sich orientieren kann. Die Navigationspunkte liegen normalerweise auf einem Weg ohne Hindernisse. Aber es gibt oft mehr als einen Weg zu einem Zielpunkt, das ist besonders von Bedeutung wenn ein Hindernis einen Navigationspunkt als nicht erreichbar erscheinen lässt.[/font]

    [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]Der Raspby soll einen statischen Plan der Wohnung haben (Türen, Räume, Flur) Der Plan hat eine Kompass Ausrichtung, die Raum-Objekte bekommen Attribute wie absolute Koordinaten ihrer Mitte, Länge, Breite, Winkelabweichung zur Nordrichtung. Aus der Topologie können automatisch Navigationspunkte abgeleitet werden. Der Roboter kann auf Grund dieser Navigationspunkte Fahrwege vorausplanen, sobald ihm ein Ziel vorgegeben wird.[/font]

    [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]Voraussetzung sind 6 US Sensoren vorne, 45 Grad vorne links, vorne rechts und seitlich links und rechts sowie oben (Tür Durchfahrt)[/font]

    [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]Mittels der Sensoren können Abstände gemessen werden und die Odometrie liefert zusätzlich gefahrene Distanzen.[/font]

    [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]Zielfahrt (von Arbeitszimmer, nach Küche):[/font]

    [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]Der Roboter startet an einer definierten Position (Navigationspunkt) mit Ziel (Navigationspunkt) [/font][font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]Er berechnet den kürzesten Weg auf Grund der vorhandenen Navigationspunkte. An jedem Navigationspunkt kann entschieden werden, mit welchen Roboter Befehlen der nächste Navigationspunkt erreicht wird. Sollte ein Hindernis auftauchen und ein Navigationspunkt nicht erreichbar sein, soll wenn möglich ein Ersatzweg berechnet werden.[/font]


    Implementierung
    Entwicklungsumgebung

    Um Abhängigkeiten zwischen Paketen kompatibel zu halten ist es oft ratsam, nicht die höchste Version eines Paketes einzusetzen. Das Basis Setup eines Raspberry ist im Netz hinreichend beschrieben und wird hier nicht weiter verfolgt.

    • Arduino Software (Link)
      (Die Installation auf Windows ist trivial)
    • debian wheezy für Raspberry pi
      (Die Installation wie im Netz vielfach dokumentiert mittels PC auf eine SD Karte vornehmen)
    • Python 3.4 für Raspberry pi 2 (Link), Windows oder Linux (Link)
      (Wird auf dem debian bereits mitgeliefert, Installation für Windows ist trivial)
    • Zusatzpakete zu PYTHON
      pyserial, pyglet, beautifulSoup, tornado (Installation mit pip)
    • NINJA-IDE 2.3 (Editor für Python) (Link)
      (Die Installation auf Windows ist trivial)
    • Git 2.5 (Link)
      (Zur Versionsverwaltung der entwickelten Software, Installation auf Windows ist trivial)
    • JQuery 1.12 (Link)
    • Scriptly (Editor für HTML, CSS und js) (Link)
      (Die Installation auf Windows ist trivial)


    Trägerplatte für Aufbauten

    Die Trägerplatte hier noch ohne Befestigungslöcher für die Sensoren. Die 5 V Batterie kann mit Aluwinkeln (10x10) gegen das Verschieben nach vorne und hinten gesichert werden (Achtung sie deckt Befestigungslöcher auf der Grundplatte ab, kleben ist eine schlechte Idee). Die grossen 10mm Löcher sind Kabeldurchführungen und werden zu Langlöchern erweitert, damit die Motor Stecker durchpassen. Für die Befestigung von Motorsteuerung, Arduino und oberer Trägerplatte werden die mit dem bundle gelieferten Messing-hülsen und M3 Schrauben verwendet. Die kleinen Hülsen sind etwas zu kurz und werden deshalb mit je 3 Beilagscheiben aus Nylon an beiden Enden auf 20 mm verlängert. Somit ist genug Abstand zwischen den Steckern des MC Boards und den darüber liegenden Lötenden der Bauteile des Arduino. Durch die 6mm Löcher werden die Kabel der beiden Encoder vorne links und vorne rechts gesteckt. Die Kabellänge reicht genau um die Stecker im MC Board noch rein zu bekommen.

    Traeger fuer Aufbauten.pdf

    Trägerplatte für Schalter, Raspberry, Kompass und Ultraschallsensor Höhe

    Hier sind ebenfalls die Befestigungslöcher für die Sensoren noch weggelassen. Der Kompass ist hier am besten aufgehoben um wenig Störfelder zu haben. Die I2C Kabellänge kann dabei unter 10cm gehalten werden. Der Kompass wird natürlich mit Nylon Schrauben befestigt. Zwischen Platine und Träger legt man eine Nylon Beilagscheibe.

    Traeger fuer Raspberry.pdf

    Audio Verstärker

    Verstaerkerschaltung.pdf



    Webserver

    Der Webserver liefert die erste Seite mit den Störungsmeldungen aus. Die Aktualisierung der Seite erfolgt per Ajax in einem2s Zyklus.

    Nun auch die ersten Daten des Bedienpanels mit Ajax in einem 1s Zyklus. ich habe das auch mit 100ms Zykluszeit erfolgreich testen können. Der Datenverkehr benötigt pro Zyklus etwa 25 ms.

    Datenmodell für die Kartierung

    Um mit einem Algorithmus die Kartierungsdaten bearbeiten zu können, ist es notwendig diese in maschinell verarbeitbare Form zu bringen und zu speichern. Für die Kartierung sind Daten von Interesse wie Ausdehnung eines Raumes, Lage zum Kompass, Beziehungen zu benachbarten Räumen usw.

    Für das Modell werden zunächst reale Koordinaten und Winkel verwendet. Die Auflösung der Geometrie beträgt 1cm bzw. 0.1 Grad. Für die Darstellung auf dem Schirm wird später ein Umrechnungsfaktor verwendet z.B. 1/1.6 so kann eine Strecke von 1200 cm mit 750px dargestellt werden. Wenn man die Karte nur ausschnittweise darstellt (z.B. nur 1 Zimmer in dem sich der Roboter gerade befindet) hat man genug Gestaltungsspielraum auf einem Full HD Schirm.

    Die Objektorientierung leistet gute Dienste um ein solches Modell zu erstellen, ohne gleich mit einer Datenbank loszulaufen.

    Die hier verwendeten Begriffe sind an /4/ angelehnt, wenngleich das dort beschrieben Konzept begrifflich nicht ohne weiteren Denksport in OO Terminologie umgesetzt werden kann.


    Zunächst werden die erfassten Daten als Map dargestellt. Weitere Daten wie Navigationspunkte und Wege wurden davon automatisch abgeleitet und ebenfalls dargestellt. Deutlich ist ein Tag, gesetzt an einem Positionspunkt zu erkennen (neben dem Mauszeiger) Solche Tags sperren die Durchfahrt für den Roboter bzw. veranlassen den Wegalgorithmus zu einem Umweg. Start- und Targetposition sind ebenfalls farblich (blau, orange) dargestellt.


    Der berechnete kürzeste Weg zwischen zwei Punkten wird weiss dargestellt. Die Roboter Startposition ist als blaues Quadrat sichtbar.

    Wenn ein Hindernis in Form eines Tags erkannt wird, wird ein Ersatzweg berechnet. Falls das Ziel nicht erreichbar ist wird ein Hinweis mittels Sprachausgabe gegeben.


    Details zum Datenmodell und einige Erklärungen zum Thema Kartierung findet man hier:

    Kartierung.pdf

    Navpoint Varianten.xlsx


    Fahrprogramm

    Das Fahrprogramm muss lediglich die Liste der ermittelten Kanten abarbeiten und vom jeweiligen Anfangspunkt zum Zielpunkt der Kante fahren. Dabei stehen in den Properties der Kante der Kompasswinkel und die Distanz zwischen den Punkten in cm zur Verfügung.


    Fahrprogramm.pdf

    Die Kompass Verwendung in Gebäuden erfordert besondere Massnahmen, ohne die nur Misserfolg entsteht

    Die Kompassverwendung in Gebäuden.pdf


    Code
    Unter GitHub ArduinoRobot
    im Modul Main.ino ist alles drin

    Code
    Unter GitHub RaspberryPiRobot

    Tests

    Für die ersten Tests wird der Roboter aufgebockt. Die Ketten sollten entfernt werden bis alle Antriebe bezüglich Drehrichtung getestet sind.

    Drehrichtung der Motoren

    • Kommando ForwardSlow
    • Alle Antrieb sollten jetzt laufen
    • Falls ein Antrieb in die falsche Richtung dreht ist sein Anschluss verpolt.
      (Anschluss Drähte z.B. am Stecker tauschen)
    • Falls die Antriebe einer Seite in die falsche Richtung drehen sind die Stecker am MC Board vertauscht
      (Stecker am MC Board tauschen)
    • Falls alle Antriebe in die falsche Richtung drehen ist das Chassis 180 Grad falsch montiert.
      (Das kann man leicht in der Software anpassen indem die Signale 1 und 0 für die Richtung getauscht werden)


    Jetzt ist der Roboter bereit für die erste Fahrstunde z.B. auf dem Tisch.


    Erkenntnisse aus den Tests

    • Der Kompass verhält sich nicht stabil, wenn er zusammen mit dem Arduino eingeschaltet wird
      (Abhilfe, er wird per Digital Ausgang, verzögert eingeschaltet)
    • Der US Sensor nach unten wird nun durch einen IR Sensor ersetzt.
      Ein 45Grad Winkel zum Boden erweist sich als zu flach für den US Sensor, die US Messung ist alle paar Messwerte völlig falsch und wird deshalb entfernt. Die Anordnung des IR Sensors muss abgeändert werden. Der IR Sensor wird ganz nach vorne gebracht, um Streulicht durch die Aufbauten zu vermeiden.
    • Die US Sensoren seitlich und vorwärts müssen etwas nach oben gebogen werden, um den Abstrahlwinkel (15 Grad) zu kompensieren, sonst wird zu früh der Fussboden als Reflektor erreicht.
    • Die Encoder links rechts ergeben seltsamerweise grob abweichende Impulszahlen. (Der Lieferant hat ein neues Chassis spendiert, das muss nun getestet werden)
    • Die Stromaufnahme eines Motors ist < 0.4 A unter Forward slow, < 0.8 A unter Forward half und <1.1 A unter Forward full.
      (Der Grenzwert für Stall wird auf dem Arduino entsprechend der gewählten Geschwindigkeit gewählt)
    • Die maximale USB Baudrate ist 38400, bei höheren Baudraten kommen die Befehle verstümmelt auf dem Arduino an und es kommen verstümmelte Messdaten auf dem Raspberry bzw. PC an.
    • Um auf dem Arduino testen zu können wurden in die Software drei Testpunkte als Statusmeldungen eingebaut. so kann mindestens erkannt werden, ob eine bestimmte Befehlsfolge durchlaufen wird oder nicht.
    • Die Befehle können über eine interne Meldung (I@Command: Kommando) nach oben gespiegelt werden. I@ Meldungen bringt das Main Programm auf die Konsole.
    • Die Zykluszeit des Arduino wurde gestoppt und es ergab sich eine Laufzeit von ca. 400ms/Zyklus bedingt durch die relativ niedrige Übertragungsrate an der USB Schnittstelle. Ich konnte noch etwas optimieren indem ich die statischen Werte nur im Anlaufteil hochsende.
    • Da mein Namensschema für Datenpunkte (ids) auf Eindeutigkeit in der DB aufbaut, ist es nicht möglich den selben Datenpunkt mit seiner id in verschiedenen Webseiten anzuzeigen. Die id muss in Javascript eindeutig im DOM sein. Ich verzichte deshalb auf die Darstellung der Betriebsart Manual Operation und Robot Stop in der Maske MAP.
    • Noch eine Sache in der Hardware. Ich werde die Batterieanzapfung aufgeben und durch einen Schaltregler ersetzten. Das lastet die Batterie gleichmässiger aus, sonst sind immer die letzten beiden Zellen nur teilentladen. Die Spannungsüberwachung der 9.6 V Batterie wird auf die Entladespannung für 8 Zellen also 8V eingestellt.
    • Der Kompass CMPS11 ist für Störungen genauso anfällig wie jeder Magnetkompass. Aus der Seemannschaft wissen wir dass für ein Fahrzeug (Schiff oder Flugzeug) eine Deviationstabelle erstellt werden muss um die fahrzeugbedingte Abweichung aufzuzeichnen, die je nach Richtung unterschiedlich ausfällt. Im Fall des Roboters kommt zusätzlich eine Störgrösse hinzu, die je nach Raum unterschiedlich sein kann (Armierungseisen im Fussboden, Metallmöbel...). Die Abweichungen sind derart gravierend, dass sie nicht vernachlässigbar sind. Es muss also pro Position eine Deviationstabelle für die 4 Himmelsrichtungen erstellt werden.
    • Die Geradeausfahrt des Chassis ist eine Katastrophe. pro m weicht das Fahrzeug mehr als 10cm vom Weg ab. ich werde das untersuchen müssen und bei konstanter Abweichung über die PWM Werte links rechts korrigieren.

    Ich habe mich nun entschlossen doch einen passiven USB Hub zu verbauen (siehe Fotos am Anfang. Das Gedrängel mit den Steckern am Raspberry Hub war mir doch zu gross. Der Stecker des Audio Sticks ist ausserdem nicht so schlank wie der Hub das vorsieht. Die Wahl des passiven Hub wurde vom Gedanken geleitet, dass sowohl Raspberry als auch der Arduino den Hub speisen. der Raspberry pi 2 ist gegen back powering immun.

    Softwarefehler suchen ist wie Pilze suchen. Wenn man erst einen gefunden hat, findet man meist mehrere.

    Bei Hardware ist es schlimmer, da findet man bereits Fehler wenn man gar keine sucht!

    Einmal editiert, zuletzt von Wolfgang Glück (4. Mai 2016 um 20:23)

  • Ein neuer Projektstand wurde veröffentlicht.

    • Die Anzeige von Stati und Messwerten erfolgt nun per Ajax im 1s bzw. 2s Takt. Auch 100ms Zykluszeit sind erfolgreich getestet worden.
    • Die Farben der Grafiken, Buttons und der Messwerte werden abhängig von Status bzw. Grenzwertüberschreitungen per CSS Klassen gesteuert.
    • Die Befehlsrichtung für die manuelle Robotersteuerung ist nun implementiert.

    Softwarefehler suchen ist wie Pilze suchen. Wenn man erst einen gefunden hat, findet man meist mehrere.

    Bei Hardware ist es schlimmer, da findet man bereits Fehler wenn man gar keine sucht!

    Einmal editiert, zuletzt von Wolfgang Glück (17. Februar 2016 um 23:28)

  • [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]Ein neuer Projektstand wurde veröffentlicht.[/font]

    • [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]Die Map mit der Darstellung der Wohnungs-Topologie (Räume, Flur, Türen) ist erstellt und die Relationen zwischen den Regionen sind abgebildet. Die Map wird bei Anwahl einmalig aktualisiert. Erste Navigationspunkte sind von der Topologie abgeleitet und ebenfalls dargestellt.[/font]

    Softwarefehler suchen ist wie Pilze suchen. Wenn man erst einen gefunden hat, findet man meist mehrere.

    Bei Hardware ist es schlimmer, da findet man bereits Fehler wenn man gar keine sucht!

    Einmal editiert, zuletzt von Wolfgang Glück (1. März 2016 um 17:51)

  • [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]Ein neuer Projektstand wurde veröffentlicht.[/font]

    • [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]Die Map mit der Darstellung der Wohnungs-Topologie (Räume, Flur, Türen) ist erstellt und die Relationen zwischen den Regionen sind abgebildet. Die Map wird bei Anwahl einmalig aktualisiert. [/font]
    • [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]Sämtliche Navigationspunkte sind von der Topologie abgeleitet und ebenfalls dargestellt.[/font]
    • [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]Die Verbindungen zwischen den Navigationspunkten wurden per [font="sans-serif"]breadth-first search Algorithmus [/font]abgeleitet und ebenfalls dargestellt[/font]

    Softwarefehler suchen ist wie Pilze suchen. Wenn man erst einen gefunden hat, findet man meist mehrere.

    Bei Hardware ist es schlimmer, da findet man bereits Fehler wenn man gar keine sucht!

  • [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]Ein neuer Projektstand wurde veröffentlicht.[/font]

    • [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]Mittels Breitensuche wird die kürzeste Verbindung zwischen Start und Ziel gefunden[/font]
    • [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]Falls ein Hindernis erkannt wird (Tag) wird wenn möglich eine Ersatzverbindung gefunden[/font]
    • Wenn das Ziel nicht erreichbar ist wird eine entsprechende Sprachmeldung ausgegeben

    Softwarefehler suchen ist wie Pilze suchen. Wenn man erst einen gefunden hat, findet man meist mehrere.

    Bei Hardware ist es schlimmer, da findet man bereits Fehler wenn man gar keine sucht!

  • [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]Ein neuer Projektstand wurde veröffentlicht.[/font]

    • Die Deviation für die Kompassverwendung wurde pro Baumkante (edge) implementiert
    • Das Fahrprogramm wurde mit minimaler Funktion, ohne Korrekturen, implementiert
    • Der Roboter fährt nun selbständig von einem gewählten Positionspunkt zu einem Zielpunkt
    • Leider ist die Mechanik des Chassis so ungenau dass ich mir weitere Schritte für die Stabilisierung der Geradeausfahrt überlegen muss

    Softwarefehler suchen ist wie Pilze suchen. Wenn man erst einen gefunden hat, findet man meist mehrere.

    Bei Hardware ist es schlimmer, da findet man bereits Fehler wenn man gar keine sucht!

  • [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]Ein neuer Projektstand wurde veröffentlicht.[/font]

    • ich werde das Projekt in dieser Form abbrechen, siehe Statement am Anfang des Projektes
    • Der Bau des Prototyps hat wertvolle Erkenntnisse geliefert und die erarbeitete Lösung ist beachtlich.
    • Möglicherweise versuche ich auf Basis neuer Hardware einen neuen Ansatz

    Softwarefehler suchen ist wie Pilze suchen. Wenn man erst einen gefunden hat, findet man meist mehrere.

    Bei Hardware ist es schlimmer, da findet man bereits Fehler wenn man gar keine sucht!

    Einmal editiert, zuletzt von Wolfgang Glück (2. Mai 2016 um 20:35)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!