Dies ist ein detailliertes Tutorial, wie Sie einen Roboter von Grund auf neu realisieren und ihm die Möglichkeit geben, in einer unbekannten Umgebung autonom zu navigieren.
Alle typischen Argumente, die mit Robotik zu tun haben, werden behandelt: Mechanik , Elektronik und Programmierung .
Der gesamte Roboter kann von jedem zu Hause ohne professionelle (d. H. Teure) Werkzeuge und Geräte hergestellt werden.
Das Brain Board (dsNav ) basiert auf einem Microchip dsPIC33 DSC mit Encoder- und Motorcontroller-Funktionen. Die Position wird mittels Kilometerzähler (Encoder) ohne externe Referenz berechnet (Dead Reckoning).
In der endgültigen Version werden einige andere Controller verwendet, um Sensoren (Arduino) zu steuern und analoge Sensoren (PSoC) zu verwalten.
Zubehör:
Schritt 1: Die Basisplattform
Ein Beispiel für den Aufbau einer sehr einfachen Roboterplattform mit Komponenten und Teilen, die überall leicht zu finden sind, ohne die Notwendigkeit professioneller Werkzeuge oder Geräte und ohne besondere Fähigkeiten bei mechanischen Arbeiten.
Die Größe der Basis ermöglicht den Einsatz in vielen verschiedenen Kategorien von Roboterwettbewerben: Explorer, Line Follower, Can Collector usw.
Schritt 2: Was möchten wir erhalten? und wie?
Dieser Roboter basiert, wie die meisten von Hobbysten gebauten Roboter, auf einem Differentiallenksystem, das es uns ermöglicht, die Positionskoordinaten des Roboters zu jedem Zeitpunkt zu kennen, indem wir einfach den von jedem Rad abgedeckten Raum regelmäßig mit ausreichender Genauigkeit kennen.
Dieses Navigationssystem ist von einem kumulativen Fehler betroffen. Die Messgenauigkeit muss hoch sein, um einen kleinen Fehlerkreis nach einem langen Weg zu gewährleisten. Nach einigen guten Ergebnissen mit hausgemachten Encodern entschied ich mich für etwas Besseres: ein paar 12-V-200-U / min-Getriebemotoren, die an ein paar 300-Count-Per-Revolution-Encoder (CPR) angeschlossen sind, die beide in vielen Internet-Robotikgeschäften erhältlich sind.
Grundprinzipien
Um alle vom 300-cpr-Encoder auf einem 3000-U / min-Motor im 4-fach-Decodierungsverfahren (120 kHz) erzeugten Impulse abzufangen, benötigen wir für jeden Encoder eine spezielle Hardware (QEI = Quadrature Encoder Interface). Nach einigen Experimenten mit einem doppelten PIC18F2431 stellte ich fest, dass das richtige Upgrade auf ein dsPIC vorliegt. Am Anfang waren es zwei dsPIC30F4012-Motorsteuerungen, die die Position und Geschwindigkeit der Räder kontrollierten, die Kilometerzählungen durchführten und die Daten der beiden Motoren an einen dsPIC30F3013 weitergaben. Diese Allzweck-DSC ist leistungsfähig genug, um Daten abzurufen, einige Trigonometrien durchzuführen, um Positionskoordinaten zu berechnen und Daten in Bezug auf den zurückgelegten Pfad zu speichern, um eine Karte des Feldes zu erhalten, und dies alles mit einer sehr hohen Rate.
Als das Board und die Programme fast abgeschlossen waren, brachte Microchip ein neues, leistungsstarkes 28-poliges SPDIP in der dsPIC33F-Serie für Motorcontroller- (MC) und Allzweckversionen (GP) heraus. Sie sind erheblich schneller als der dsPIC30F, verfügen über einen viel größeren verfügbaren Programmspeicher und RAM (nützlich für die Feldzuordnung), benötigen weniger Strom (gut für batteriebetriebene Roboter) und vereinfachen mit ihren DMA-Funktionen viele E / A-Vorgänge.
Dies sind vor allem die ersten Microchip-Motorcontroller mit zwei QEIs auf demselben Chip. Starten wir einen neuen Port! Das Das logische Blockdiagramm ähnelt dem der vorherigen Karte , aber die Hardware und Software sind seitdem viel einfacher Ich kann einen DSC verwenden, der nur aus drei besteht . Es ist keine Hochgeschwindigkeitskommunikation zwischen dem Supervisor und den Motorsteuerungen erforderlich, um Navigationsparameter auszutauschen. Jeder Prozess ist einfach zu synchronisieren, da er sich auf demselben Chip befindet. Die Auswahlmöglichkeit der Peripheriestifte der Serie dsPIC33F vereinfacht die Leiterplatte weiter und ermöglicht den internen Anschluss von Peripheriegeräten sowie eine größere Flexibilität.
Dies bringt uns zum "dsPIC based Navigation Control Board" oder dsNavCon kurz gesagt. Diese Platine ist als Teil eines komplexeren Systems konzipiert. In einem vollständigen Entdeckerroboter steuern andere Boards Schall-, Licht- und Gassensoren sowie Stoßfänger und Ultraschall-Entfernungsmesser, um Ziele zu finden und Hindernissen auszuweichen.
Als eigenständiges Board dsNavCon kann auch für einen einfachen "Line Follower" -Roboter verwendet werden, der komplexer ist als ein Roboter für einen Odometrie- und Dead-Reckoning-Wettbewerb oder ein sogenannter "Can Can Robot" (für Dosen-Sammelwettbewerbe). Es gibt noch viel freien Programmspeicher, um Code für solche Aufgaben hinzuzufügen. Mit geringfügigen oder keinen Änderungen an der Software kann sie auch für ein ferngesteuertes Fahrzeug verwendet werden, indem das bidirektionale RF-Modem mit einer Art intelligenter Fernbedienung verwendet wird. Diese Fernbedienung kann komplexe Befehle wie "FWD um 1 m verschieben", "15 ° nach links drehen", "FWD mit 50 cm / s ausführen", "Zu X-, Y-Koordinaten wechseln" oder ähnliches senden.
Das Board und der Roboter sind so konzipiert, dass sie von jedem zu Hause ohne professionelles Werkzeug und Gerät hergestellt werden können.
Schritt 3: Die Open Source Hardware
Blockdiagramm
Das Navigationssteuerungssubsystem besteht aus dsNav B. die „intelligente“ Platine des Systems und eine L298-basierte Dual-H-Bridge-Platine zur Steuerung der 12-V-Getriebemotoren (Hsiang Neng HN-GH12-1634TR). Das Bewegungsfeedback kommt von einigen 300 cpr Encodern (US digital e4p-300-079-ht).
Die Kommunikation mit der Außenwelt erfolgt über die beiden seriellen UART-Schnittstellen. eine für die Telemetrie und die andere zum Abrufen von Daten von der Sensorplatine. Das XBee-Modul kann über JP1- und JP2-Jumper an UART1 oder UART2 angeschlossen werden. Für andere Anschlussarten stehen die Buchsen J1 und J16 zur Verfügung. Der COMM1-Port (J16) kann dank der Auswahl der Peripheriestifte der dsPIC33F-Serie auch für eine I2C-Kommunikation verwendet werden.
Das Originalschaltbild im Eagle-Format finden Sie hier:
http://www.guiott.com/Rino/dsNavCon33/dsNavCon33_Eagle_project/DsPid33sch.zip
Wie Sie sehen, ist der Schaltplan so einfach, dass er wie ich auf einem Perfboard implementiert werden kann. Wenn Sie dieses System nicht verwenden und Ihre eigene Leiterplatte nicht realisieren möchten, finden Sie eine kommerzielle Leiterplatte, die auf meiner ursprünglichen Arbeit basiert und vollständig mit meiner Open Source-Software kompatibel ist, unter: http: //www.robot-italy .de / product_info.php? products_id = 1564
Schritt 4: Die Open Source Software
Die Software wurde mit MPLAB® free IDE entwickelt und mit dem MPLAB® C30-Compiler (auch in einer kostenlosen oder Studentenversion) geschrieben, beide (natürlich) von Microchip:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=81
Das gesamte Projekt ist als Open Source bei Google Code verfügbar
http://code.google.com/p/dspid33/
Dort finden Sie die neueste Version, Kommentare, Beschreibungen usw.
Das Programm wird Schritt für Schritt im Code beschrieben. Um ein hohes Maß an Kommentaren und einen besser lesbaren Code zu erhalten, steht an jeder wichtigen Stelle eine Zahl in Klammern (zB: 7) als Verweis auf eine externe Datei (dh: descrEng.txt) im MPLAB-Projekt .
Das Diagramm zeigt die Gesamtarchitektur der Steuerprozeduren von dsNav board und die Navigationsstrategien, die auf der Grundlage des Projekts angewendet werden.
Die Motorsteuerungen können als Black Boxes angesehen werden, die die Geschwindigkeit der Räder überwachen. Der Supervisor-Teil des Programms sendet ihnen die Referenzgeschwindigkeit (VeldDesX: gewünschte Geschwindigkeit). Die Input Capture-Module des Mikrocontrollers erhalten Impulse von den an die Motorachse angeschlossenen Encodern und leiten die Drehzahl der Motoren ab (VelMesX: gemessene Geschwindigkeit). Kombiniert man alle 1ms diese Werte im PID-Regler "Speed PID", erhält man den richtigen PWM-Wert, um die gewünschte Drehzahl jedes einzelnen Rades zu halten.
Die QEI-Module (Quadrature Encoder Interface) empfangen sowohl die A- als auch die B-Impulse von den Encodern und geben der Überwachungsfunktion die Laufrichtung und die Anzahl der Impulse im 4x-Modus zurück (Zählung der ansteigenden und abfallenden Flanken von Signal A und Signal B: 2 x 2 = 4).
Multipliziert man die Anzahl der Impulse mit einem K, das den zurückgelegten Raum für jeden einzelnen Encoderimpuls angibt, so erhält man alle 10 ms den Abstand, den das rechte und das linke Rad zurücklegen. Der Supervisor kombiniert diese Reiseinformationen und wendet das Dead-Reckoning-Verfahren an, um die gemessenen Positionskoordinaten des Bot zu erhalten: Xmes, Ymes, θMes (Orientierungswinkel).
Der Supervisor empfängt den Navigationsbefehl von außen über die serielle Schnittstelle (Telemetrie).
Verschiedene Strategien können angewendet werden:
EIN - Fahren Sie mit einer vorgegebenen Geschwindigkeit in einer vorgegebenen Richtung (VelDes, θDes).
B - Fahren Sie mit den Koordinaten XDes, YDes auf einen bestimmten Punkt zu.
C - eine bestimmte Strecke in einer bestimmten Richtung zurücklegen (DistDes, θDes).
Modus A : mit den "logischen Steuerschaltern" in Position 1 wird nur die PID-Steuerung "Winkel PID" von den Überwachungsfunktionen verwendet. Dieser kombiniert den gewünschten Winkel & thgr; Des mit dem gemessenen Winkel & thgr; Mes, der durch ein Odometrieverfahren berechnet wird, um den Wert der Drehwinkelgeschwindigkeit & ohgr; des Fahrzeugs um seine vertikale Achse zu erhalten, der zur Korrektur des Orientierungsfehlers benötigt wird.
Der Wert von DeltaV ist proportional zu ω. Es wird zu VelDes addiert, um die Geschwindigkeit des linken Rades zu erhalten, und zu VelDes subtrahiert, um die Geschwindigkeit des rechten Rades zu erhalten, damit der Steuerkurs dem θDes-Wert entspricht, während die Mitte des Roboters noch mit VelDes-Geschwindigkeit fährt.
Modus B : Wenn sich die "logischen Steuerschalter" in Position 2 befinden, wird die gewünschte Geschwindigkeit VelDes von der PID-Steuerung "Dist PID" berechnet und wie in Modus A verwendet. Der gemessene Eingang für diese PID (DistMes) wird in Abhängigkeit von berechnet die aktuellen Koordinaten und die Zielkoordinaten. Der gewünschte Orientierungswinkel θDes stammt ebenfalls aus der gleichen Prozedur und wird als Referenzeingabe für "Angle PID" verwendet. Der Referenzeingang für "Dist PID" ist 0, dh das Ziel ist erreicht. Mit ω und VelDes läuft die Geschwindigkeitsregelung der Räder wie in Modus A.
Modus C : Mit den "logischen Steuerschaltern" in Position 2 werden die Zielkoordinaten Xdes, Ydes zu Beginn einmalig in Abhängigkeit von den Eingangsparametern DistDes, θDes berechnet. Danach läuft alles wie im Modus B
Schritt 5: Details der Software: Geschwindigkeitsregelung und andere Grundfunktionen
Das Programm ist voll Interrupt getrieben . Beim Start tritt das Programm nach der Initialisierung in eine sehr einfache Hauptschleife ein, die als Zustandsmaschine fungiert. In der Hauptschleife prüft das Programm Flags, die von externen Ereignissen aktiviert wurden, und wechselt entsprechend ihrer Werte in den relativen Zustand.
Da es eine Art sehr einfache Genossenschaft ist "Echtzeit-Betriebssystem "Jede Routine muss in kürzester Zeit ausgeführt werden, um das System für die sehr häufigen Interrupts freizustellen.
Es gibt keine Wartezeiten und keine Verzögerungen im Code. Wann immer möglich, werden Interrupts verwendet, insbesondere für langsame Vorgänge wie das Senden oder Empfangen von Zeichenfolgen. Die UART-Kommunikation nutzt die DMA-Funktionen des dsPIC33F, um CPU-Zeit zu sparen und alle "schmutzigen" Aufgaben in der Hardware zu erledigen.
In dsPIC33FJ128MC802 verwendete Peripheriegeräte:
- QEIs zur Berechnung des zurückgelegten Weges.
- Input Capture (IC) zur Berechnung der Geschwindigkeit.
- A / D-Wandler zum Lesen des Motorstroms.
- Verbesserte PWMs zum Antreiben der Motoren.
- UARTs zur Kommunikation mit der Außenwelt
QEI-Module werden verwendet, um zu wissen, wie viel die Räder gefahren sind und in welche Richtung. Dieser Wert wird alle 1 ms in einer Variablen algebraisch kumuliert und auf Anforderung an die Supervisor-Funktionen gesendet. Nachdem der Wert gesendet wurde, werden die Variablen zurückgesetzt.
Die Geschwindigkeit wird bei jedem Geberimpuls wie unten beschrieben gemessen. Alle 1 ms berechnet es die mittlere Drehzahl durch Mitteln von Abtastwerten, führt den PID-Algorithmus aus und korrigiert die Motordrehzahl entsprechend dem Ergebnis, wobei das PWM-Tastverhältnis geändert wird. Eine detaillierte Beschreibung der C30-PID-Bibliotheksanwendung finden Sie unter Microchip-Codebeispiel: CE019 - Verwenden von PID-Reglern (Proportional Integral Derivative) in Regelungssystemen. http://ww1.microchip.com/downloads/en/DeviceDoc/CE019_PID.zip
Drehzahländerungen der Motoren werden ruckfrei ausgeführt, wobei mit einer ansteigenden oder abfallenden Schrägrampe beschleunigt oder abgebremst wird, um starke mechanische Beanspruchungen und Radschlupf zu vermeiden, die zu Fehlern bei der Kilometermessung führen können. Die Verzögerung ist schneller als die Beschleunigung, um beim Bremsen Stöße mit Hindernissen zu vermeiden.
IC werden Eingangserfassungsmodule verwendet, um die Zeit zu messen, die zwischen zwei vom Encoder erzeugten Impulsen verstrichen ist. Dies bedeutet, wenn die Räder eine bekannte feste Strecke zurücklegen (konstant) SPACE_ENC ). Sie sind parallel zu QEA geschaltet (DSC-intern dank der Peripheral Pin Select-Funktionen des dsPIC33F) und erfassen die verstrichene Zeit bei steigender Flanke der Encodersignale. TIMER2 wird im Freilaufmodus verwendet. Bei jedem IC-Interrupt wird der aktuelle Wert von TMR2 gespeichert und der vorherige Wert davon abgezogen. Dies ist die Pulsperiode. Dann wird der aktuelle Wert zum vorherigen Wert und wartet auf den nächsten Interrupt. Das TMR2-Flag muss überprüft werden, um festzustellen, ob im 16-Bit-Register ein Überlauf aufgetreten ist. Wenn ja, muss die Differenz zwischen 0xFFFF und dem vorherigen Sample zum aktuellen Wert addiert werden. Samples werden algebraisch hinzugefügt IcPeriod variabel nach _UPDN Bit, um auch die Geschwindigkeitsrichtung zu bestimmen. Dies ist eine der vorgeschlagenen Methoden in Anwendungshinweis für Mikrochips AN545 .
Die Variable IcIndx enthält die Anzahl der hinzugefügten Samples IcPeriod .
Alle 1ms berechnet sich die mittlere Geschwindigkeit zu V = Raum / Zeit
woher Leerzeichen = SPACE_ENC • IcIndx
(= in einem Encoder-Impuls abgedeckter Raum • Anzahl der Impulse)
und Zeit = TCY • IcPeriod
(= einzelne TMR-Periode • Summe der aufgetretenen Perioden).
Single_TMR_period = TCY = 1 / FCY (Taktfrequenz).
So V = Kvel • (IcIndx / IcPeriod)
woher Kvel = SPACE_ENC • FCY Geschwindigkeit in m / s haben.
15 Bit nach links verschieben Kvel const ( KvelLong = Kvel << 15 ) Die Geschwindigkeit wird bereits im Bruchformat berechnet (auch wenn nur ganzzahlige Variablen verwendet werden) und kann dann in der PID-Routine verwendet werden. Eine ausführlichere Beschreibung finden Sie in der Datei "descrEng.txt" im MPLAB-Projekt.
A / D-Wandler Kontinuierliche Messung des Motorstroms, Speicherung der Werte in den ADCBUF-Puffern mit 16 Positionen. Wenn die Puffer voll sind, tritt ein Interrupt auf und ein Durchschnittswert wird ungefähr alle 1 ms berechnet.
UARTs werden verwendet, um Befehle von außen zu empfangen und die Ergebnisse der Messungen zurückzusenden. Der Kommunikationsteil des Programms läuft als Zustandsmaschine. Mit Statusvariablen werden Aktionen nacheinander ausgeführt. Sehr einfache und schnelle Interrupt-Service-Routinen (ISR) holen oder legen jedes einzelne Byte aus oder in einen Puffer und setzen die richtigen Flags, damit die richtige Funktion ausgeführt werden kann.
Wenn während des Empfangs ein Fehler auftritt (UART, Prüfsumme, Analysefehler), wird die Statusvariable auf einen negativen Wert gesetzt und die rote LED wird eingeschaltet, um diesen Fehlerzustand extern zu kommunizieren. Eine vollständige Liste der möglichen Fehler finden Sie in der Datei "descrEng.txt" im MPLAB-Projekt.
Das Protokoll für den Handshake lautet physikalische Schicht unabhängig , und kann auch für die Kommunikation mit dem I2C- oder RS485-Bus verwendet werden.
Das erste Schicht wird von der dsPIC-Peripherieschnittstelle gesteuert. Frame- oder Overrun-Fehler (UART) oder Kollisionen (I2C) werden von der Hardware erkannt und setzen das entsprechende Flag.
Das zweite Schicht wird von ISR-Routinen behandelt. Sie füllen den Empfangspuffer mit den von den Schnittstellen empfangenen Bytes. Sie erkennen auch einen Pufferüberlauf und einen Befehlsüberlauf.
UartRx- oder UartRx2-Funktionen verwalten die dritte Schicht . Wie bereits beschrieben (siehe auch Flussdiagramme), fungieren diese Routinen als Zustandsmaschine, die Bytes aus dem Puffer abruft und die Befehlszeichenfolge decodiert.
Die Bytes werden zwischen der zweiten und dritten Schicht (ISR- und UartRx-Funktion) durch einen Umlaufpuffer ausgetauscht. ISR empfängt ein Byte, speichert es in einem Array und inkrementiert einen Zeiger auf das Array. Wenn der Zeiger das Ende des Arrays erreicht, wird er erneut am Anfang gestartet. Die UartRx-Funktion verfügt über einen eigenen Zeiger zum Lesen des gleichen Arrays, der (auch zirkulär) inkrementiert wird, sobald das Byte im aktuellen Empfangsstatus decodiert wurde. Die Hauptschleife ruft die UartRx-Funktion immer dann auf, wenn sich der "In" -Zeiger vom "Out" -Zeiger unterscheidet.
Jedes Befehlspaket besteht aus:
0 - Header @
1 - ID 0-9 ASCII
2 - Cmd A-Z ASCII
3 - CmdLen N = 1-MAX_RX_BUFF Anzahl der folgenden Bytes (Prüfsumme enthalten)
4 - Daten …
…
N-1 - Daten
N - Prüfsumme 0-255, erhalten durch einfaches Addieren in einer 8-Bit-Variablen, wobei alle die Nachricht bildenden Bytes (Prüfsumme selbst ausgeschlossen).
Diese Ebene steuert Timeout- und Prüfsummenfehler sowie die Paketkonsistenz (richtiger Header, richtige Länge). Wenn alles in Ordnung ist, wird die Parser-Routine aktiviert (vierte Schicht ), um die Nachricht zu dekodieren und die erforderliche Aktion auszuführen. Diese Routine setzt das entsprechende Fehlerflag, wenn der empfangene Nachrichtencode nicht bekannt ist.
TMR1 generiert einen 1000-Hz-Takt - der Herzschlag des Programms. Bei jedem TMR1-Interrupt werden interne Timer aktualisiert, der Watchdog gelöscht und ein Flag gesetzt, um die Funktion zu aktivieren, die nach dem Wert für den zurückgelegten Speicherplatz fragt. Alle 10 ms wird die Funktion "All_Parameters_Ask" (Geschwindigkeit, Position, Strom) aktiviert.
Schritt 6: Details der Software: Kilometerzähler und Feldzuordnung = Wo bin ich?
Sobald wir die Informationen über die von jedem Rad zurückgelegte Strecke in einer zeitdiskreten Aktualisierung (Kilometerzähler) haben, können wir die Positionskoordinaten des Roboters mit derselben Periodizität ohne externe Referenz schätzen (Dead Reckoning).
Einige theoretische Hintergründe zur Totenberechnung mittels Odometrie finden sich in dem Buch von Johann Borenstein:
"Wo bin ich? - Sensoren und Methoden zur mobilen Roboterpositionierung"
und auf folgenden Webseiten:
http://www.seattlerobotics.org/encoder/200010/dead_reckoning_article.html
Der mathematische Hintergrund und eine ausführliche Erläuterung der verwendeten allgemeinen Methode sind in G.W. Lucas 'Artikel Ein Tutorial und ein elementares Trajektorienmodell für das Differentiallenksystem von Roboterradaktuatoren, verfügbar im Internet:
http://rossum.sourceforge.net/papers/DiffSteer/DiffSteer.html
Einige vereinfachte Algorithmen finden Sie auch in derselben Dokumentation. Mit der mathematischen (trigonometrischen) Funktion der dsPIC33F-Serie können Sie also den richtigen Kompromiss zwischen Präzision und Verarbeitungsgeschwindigkeit finden.
Eine Beschreibung der zur Berechnung der Position verwendeten Mathematik finden Sie in den diesem Schritt beigefügten Bildern. Die erste zeigt die Bedeutung der Symbole, die zweite zeigt die mit diesen Symbolen verwendeten Formeln. Durch Klicken auf die Kästchen neben den einzelnen Rechenschritten wird eine kurze Beschreibung angezeigt.
Am Ende wissen wir, wie viel sich der Roboter in diesem Zeitintervall als Delta der Orientierung, als Delta auf der X-Achse und als Delta auf der Y-Achse im karthesischen Referenzfeld bewegt hat.
Kumuliert man jeden Delta-Wert in einer eigenen Variablen, so kennt man die aktuellen Koordinaten (Position und Orientierung) der Plattform.
Um Rechenfehler (Division durch Null) und Zeitverschwendung durch den Regler zu vermeiden, müssen die Variablen Sr und Sl im Voraus überprüft werden. Indem wir einen Quasi-Null-Wert definieren, der minimale mechanische und rechnerische Annäherungen berücksichtigt, können wir die Formeln vereinfachen, wenn der Roboter auf einer geraden Linie fährt (der Raum, den das rechte Rad zurücklegt, ist fast der gleiche wie der Raum, den das linke Rad zurücklegt). oder wenn es sich um seine vertikale Achse dreht (der Raum, den das rechte Rad zurücklegt, ist fast derselbe wie der Raum, den das linke Rad zurücklegt, jedoch in entgegengesetzter Richtung), wie im Flussdiagramm im letzten Bild dargestellt.
Dieses Video zeigt ein Beispiel für die Genauigkeit, die wir erzielen können:
http://www.youtube.com/watch?v=d7KZDPJW5n8
Feldzuordnung
Mit Daten, die durch vorherige Funktionen berechnet wurden, wird eine Feldzuordnung durchgeführt.
Alle Xms wird nach der Erarbeitung der aktuellen Position eine Feldzuordnung durchgeführt, die das unbekannte Feld in einem Zellenraster von 10 x 10 cm unterteilt. Wenn wir eine maximale Feldgröße von 5 x 5 m definieren, erhalten wir eine 50 x 50 = 2500 Zellenmatrix. Jede Zelle ist mit einem Nibble definiert, mit einer Gesamtspeicherbelegung von 1250 Bytes. Jeder Zelle können 16 verschiedene Werte zugewiesen werden:
n = 00 unbekannte Zelle
n = 01 - 10 Zelle besucht n-mal
n = 11 Hindernis gefunden
n = 12 Gastarget gefunden
n = 13 Lichtziel gefunden
n = 14 Schallziel gefunden
Der Roboter kann von jeder Position im Feld aus starten. Dies sind die Referenzkoordinaten (0,0) in ihrem Referenzsystem.
Die Feldzuordnung ist nützlich, um die beste Erkundungsstrategie in einem unbekannten Feld zu finden. Der Roboter kann sich auf den weniger erkundeten Teil des Feldes richten (niedrigerer „n“ -Wert), Zeit sparen, indem er nicht zweimal in einem bereits erkannten Ziel anhält, den besten Weg zum Erreichen einer bestimmten Koordinate finden und vieles mehr.
Schritt 7: Remote Console
Um in jedem Betriebssystem einfach zu entwickeln und gut zu laufen, wird es mit geschrieben wird bearbeitet Sprache:
http://www.processing.org/
Der Quellcode für dieses Programm ist auch als Open Source bei Google Code verfügbar:
http://code.google.com/p/dsnavconconsole/
Mit dem Hauptfeld (erste Bilder) Sie können die Telemetrie durchführen, indem Sie auf dem Raster den vom Roboter verfolgten Pfad (gemäß Schätzung durch die Kilometerzähler) in einem konfigurierbaren Größenfeld anzeigen und einige andere wichtige Werte auf dem Bildschirm ablesen dsNav .
Die Anzeigen zeigen die gemessenen Werte:
- MesSpeed in einem Bereich von +/- 500 mm / s, der Mittelwert der Geschwindigkeit der beiden Räder (die Geschwindigkeit der Plattformmitte).
- Gemessener Strom in mA (die Summe der Ströme der beiden Motoren).
- Gemessener Winkel, wie durch Kilometerzähler ermittelt.
Andere Panels werden verwendet, um die Parameter des Roboters zu konfigurieren und einen definierten Pfad im Roboter zu speichern (falls erforderlich). Ein wichtiges Panel, zumindest während der Entwicklung des Roboters, ist das Detailbereich (zweites Bild), das die Geschwindigkeit jedes Rads in Echtzeit anzeigt, sehr nützlich für die Kalibrierung aller Parameter.
Die zentrale Rasteransicht kann mit der Ansicht einer Webcam umgeschaltet werden, um den Pfad, dem der Roboter folgt, auch von der Ansicht aus zu steuern.
Ein praktisches Anwendungsbeispiel für diese Konsole finden Sie in diesem Video:
http://www.youtube.com/watch?v=OPiaMkCJ-r0
