DE112006003007T5

DE112006003007T5 - Systeme und Verfahren zum Vermeiden von Hindernissen

Info

Publication number: DE112006003007T5
Application number: DE112006003007T
Authority: DE
Inventors: James Newton Allard; Kathleen A. Arlington Weinhold; William Robert Norris; Anthony Francis Davenport Catalfano
Original assignee: Deere and Co; iRobot Corp
Current assignee: Deere and Co; iRobot Corp
Priority date: 2005-10-21
Filing date: 2006-10-20
Publication date: 2008-10-16
Anticipated expiration: 2026-10-21
Also published as: US20070219666A1; US8473140B2; US20150301532A1; AU2006304838A1; US8874300B2; AU2006306523A1; WO2007048003A3; DE112006002894B4; AU2006304812A1; WO2007050406A1; US7894951B2; IL191001A; GB2445507B; US20070193798A1; DE112006003044T5; US20120046820A1; AU2006306522A1; US20070198144A1; AU2006306522B2; DE112006003007B4

Abstract

Ein robotergesteuertes Fahrzeug mit:
einer Robotersteuereinheit mit einer Steueranwendung;
einem Sensor zum Erkennen von Objektdaten, die erkannte Hindernisse oder Objekte repräsentieren, die außerhalb des Roboterfahrzeugs erkannt worden sind, und zum Übertragen der Objektdaten an die Robotersteuereinheit;
wobei die Robotersteuereinheit eine Karte basierend auf den Objektdaten erzeugt, die Karte Kartierungsdaten aufweist und die Kartierungsdaten Positionsdaten der erkannten Hindernisse oder Objekte aufweist; und
wobei die Steueranwendungseinheit basierend wenigstens teilweise auf den Kartierungsdaten Fahrzeugaktionen bestimmt und einen Steuerbefehl an eine Fahrzeugsteuereinheit ausgibt, der die Fahrzeugaktionen repräsentiert.

Description

Bezogene Anmeldungen
Diese Erfindung beansprucht die Priorität der U.S. Provisional Patent Application Nr. 60/729,445 vom 21. Oktober 2005, U.S. Provisional Patent Application Nr. 60/729,388 vom 21. Oktober 2005, U.S. Provisional Patent Application No. 60/780,389 vom 08. März 2006 und U.S. Provisional Patent Application Nr. 60/838,704 vom 18. August 2006, die hier alle durch Bezugnahme vollständig einbezogen werden.
Diese Erfindung bezieht sich auf die PCT-Patentanmeldung mit der Bezeichnung „System und Verfahren zum Umschalten zwischen einem autonomen und einem manuellen Betrieb eines Fahrzeugs" [Anwaltsaktenzeichen Nr. 56516/336357], die PCT-Patentanmeldung mit der Bezeichnung „System und Verfahren zum Vermeiden von Hindernissen" [Anwaltsaktenzeichen Nr. 56516/336401] und die PCT-Patentanmeldung mit der Bezeichnung „Vernetztes Mehrfunktions-Roboterfahrzeug" [Anwaltsaktenzeichen Nr. 56516/336403], die gleichzeitig eingereicht werden und hier durch Bezugnahme vollständig einbezogen werden.
GEBIET DER ERFINDUNG
Diese Erfindung bezieht sich allgemein auf Systeme und Verfahren zur autonomen Steuerung von Fahrzeugen und Fahrzeugsensoren, Aktuatoren und/oder Kommunikationen. Insbesondere beziehen sich Ausführungsbeispiele dieser Erfindung auf ein vielseitiges Robotersteuermodul und Systeme und Verfahren zum Vermieden von Hindernissen unter Verwendung von zwei- und dreidimensionaler Information.
HINTERGRUND DER ERFINDUNG
Roboterfahrzeuge oder autonome Fahrzeuge (manchmal als mobile Roboterplattformen bezeichnet) haben im Allgemeinen ein Robotersteuersystem, das die operativen Systeme des Fahrzeugs steuert. Bei einem Fahrzeug, das auf eine Transportfunktion begrenzt ist, können die operativen Systeme die Steuer-, Brems-, Getriebe- und Drosselsysteme beinhalten. Im Oktober 2005 haben fünf derartige autonome Fahrzeuge (von dreiundzwanzig an der Endrunde teilnehmenden Fahrzeugen) die „Grand Challenge" des United States Defense Advanced Research Projects Administration (DARPA) erfolgreich beendet, ein Wettbewerb, der von vollständig autonome Fahrzeuge fordert, eine Strecke, die mehr als einhundert Meilen beträgt, zu bewältigen. Diese Fahrzeuge waren mit Robotersteuersystemen ausgebildet, wobei eine Reihe von Computern alle operativen Systeme des Fahrzeugs steu erten, wie das Lenken, das Bremsen, die Kraftübertragung und das Drosseln in Abhängigkeit von autonomen Entscheidungen, die von Programmen an Bord des Fahrzeugs in Antwort auf einen Sensoreingang ausgeführt werden, ohne eine menschliche Intervention auf der Strecke selbst.
Robotersteuersystem-Sensoreingaben können Daten aufweisen, die mit dem Zielort des Fahrzeugs, vorprogrammierter Weginformation und Information über erfasste Hindernisse assoziiert sind. Basierend auf einem Datensatz oder mehreren Datensätzen, die mit der oben genannten Information assoziiert sind, werden die Fahrzeugbewegungen gesteuert. Das Erfassen von Hindernissen jedoch kann falsche Datenpunkte erzeugen, unvollständige Hindernisdaten und/oder große Mengen an elektronischer Speicherkapazität und Rechnerleistung zum Berechnen der relevanten Datenpunkte erfordern. Zusätzlich kann das Kombinieren von Hindernisdaten mit Weg- oder Richtungsinformation in Fahrzeugbewegungen resultieren, die als ruckartige oder unsachgemäße Fahrzeugbewegungen charakterisiert werden können.
ZUSAMMENFASSUNG
Bestimmte Ausgestaltungen der Erfindung stellen ein Roboterfahrzeug bereit mit einer Robotersteuereinheit und einem Sensor zum Erfassen von Objektdaten, die erfasste Hindernisse oder Objekte darstellen, die außerhalb des Roboterfahrzeugs angeordnet sind und übertragen Objektdaten an die Robotersteuereinheit. Die Robotersteuereinheit kann eine Karte erzeugen, basierend auf den Objektdaten mit Kartendaten. Die Kartendaten können Positionsdaten der erfassten Hindernisse oder Objekte aufweisen. Die Robotersteuereinheit kann über Fahrzeugbewegungen basierend auf den Kartendaten entscheiden.
In einigen Ausgestaltungen ist ein Roboterfahrzeug bereitgestellt, das eine vordere Sensoranordnung, eine hintere Sensoranordnung und eine Robotersteuereinheit umfasst. Die vordere Sensoranordnung kann einen vorderen Bereichsscan ausführen, um vorwärts gerichtete Daten, die Hindernisse oder Objekte wenigstens vor dem Fahrzeug repräsentieren, zu erhalten. Die hintere Sensoranordnune kann einen nach hinten gerichteten Bereichsscan ausführen, um nach hinten gerichtete Daten zu erhalten, die Hindernisse oder Objekte wenigstens hinter dem Fahrzeug repräsentieren. Die Robotersteuereinheit kann die nach vorne und nach hinten gerichteten Daten empfangen und eine Hinderniskarte basierend auf den nach vorne und nach hinten gerichteten Daten erzeugen. Die Robotersteuereinheit kann einen Prozessor und einen Speicher umfassen. Der Speicher kann eine Hinderniskarte und ausführbaren Code aufweisen, wie etwa eine Range Guard Anwendung und eine Steueranwendung. Die Range Guard Anwendung kann Unterbrechungen in den nach vorne und nach hinten gerichteten Daten erfassen und die Daten wenigstens auf den Unterbrechungen basierend in den nach vorne gerichteten und nach hinten gerichteten Daten, die die Anwesenheit von Hindernissen in nach vorne und nach hinten gerichteten Scanbereich anzeigen, ersetzen. Die Steuereinheit kann einen Weg basierend auf wenigstens einem Teil auf der Hinderniskarte bestimmen und Steuerbefehle an eine Fahrzeugsteuereinheit wenigstens teilweise basierend auf dem Weg ausgeben.
In einigen Ausgestaltungen der vorliegenden Erfindung kann eine Laserscannerbaugruppe vorgesehen sein, die angepasst ist an ein Roboterfahrzeug angeschlossen zu werden. Die Laserscannerbaugruppe kann einen Laserscanner, einen Scannermechanismus und ein Schutzschild aufweisen. Der Laserscanner kann einen Laserstrahl zum Erfassen der Anwesenheit eines Hindernisses aussenden. Der Scannermechanismus kann die Position des Laserscanners beeinflussen. Das Schutzschild kann den Laserscanner vor Beschädigung schützen und dem Laserstrahl ermöglichen, die Anwesenheit eines Hindernisses zu erfassen. Der Schutzschild kann eine Basis, wenigstens zwei Stützelemente und eine Mehrzahl von Stützlamellen aufweisen. Die Basis kann die Laserscannerbaugruppe mit dem Roboterfahrzeug verbinden. Die wenigstens zwei Stützelemente können mit der Basis verbunden sein. Die Mehrzahl von Stützrippen kann mit den wenigstens zwei Stützelementen verbunden sein.
In einigen Ausgestaltungen der vorliegenden Erfindung kann das Roboterfahrzeug gesteuert werden, um einem Objekt zu folgen. Das Objekt kann für das Roboterfahrzeug zum Folgen identifiziert sein. Die Position des Roboterfahrzeugs relativ zu einer vorhergehenden Position und eine Bewegung des Objekts können bestimmt werden. Die Bereichsposition des Objekts kann geschätzt werden. Die Position des Objekts kann empfangen werden. Es kann bestimmt werden, ob sich das Objekt innerhalb der geschätzten Bereichsposition befindet. Ein Satz von Wegen, teilweise auf der Objektposition basierend kann berechnet werden. Der Satz von Wegen kann eine Mehrzahl von Wegen aufweisen. Ein Vorrangswert für jeden der Wege kann zugeordnet werden. Der Satz von Wegen kann für einen Fahrvermittler bereitgestellt werden.
In einem Ausführungsbeispiel der vorliegenden Erfindung kann ein Roboterfahrzeug unter Verwendung einer Hinderniskarte gesteuert werden. Eine Mehrzahl von Punkten, die Teil eines Hindernisses und eine Position des Hindernisses zu einer bestimmten Zeit darstellen, können erhalten werden. Ein Zeitstempel kann mit jedem Punkt assoziiert sein. Die Punkte können in einer Zelle kartiert sein, die in Gitter unterteilt ist. Die Mehrzahl von Punkten kann unterteilt sein in alte, aktuelle und neue Punkte, basierend auf dem assoziierten Zeitstempel. Das Zentrum von wenigstens einem der alten Punkte und der aktuellen Punkte kann bestimmt werden. Das Zentrum des neuen Punkts kann bestimmt werden. Eine Positionsdifferenz zwischen dem Zentrum der neuen Punkte und dem Zentrum von wenigstens einem der alten Punkte und der aktuellen Punkte kann erhalten werden. Eine Geschwindigkeit eines Objekts, basierend auf der Positionsdifferenz, kann bestimmt werden. Das Roboterfahrzeug kann unter Verwendung der Objektgeschwindigkeit gesteuert werden.
In einem Ausführungsbeispiel der vorliegenden Erfindung kann eine dreidimensionale Karte zur Benutzung in einem robotergesteuerten Fahrzeug erzeugt werden. Ein Laserscanner kann verwendet werden, um einen ersten Scan eines Scanbereichs auszuführen. Zweidimensionale Hindernisdatenpunkte können erhalten werden, die Hindernisse repräsentieren, die sich im Scanbereich befinden. Scandaten können mit den Hindernisdatenpunkten assoziiert werden. Die Scandaten können Scanbereichsdaten aufweisen, die den Scanbereich, darstellen, Scannerwinkeldaten, die den Winkel des Laserscanners repräsentieren, Fahrzeugsgeschwindigkeitsdaten und einen Laserscannersynchronisationspuls. Die Scandaten und die Hindernisdatenpunkte können an eine Robotersteuereinheit gesendet werden. Die Hindernisdatenpunkte können mit einem Zeitstempel versehen werden. Eine Hinderniskarte kann teilweise basierend auf den zeitcodierten Hindernisdatenpunkten und Scandaten erzeugt werden.
In einer Ausgestaltung der vorliegenden Erfindung können dreidimensionale Hindernisdaten in zweidimensionale Hindernisdaten zum Steuern eines Roboterfahrzeugs umgewandelt werden. Eine Mehrzahl von dreidimensionalen zeitcodierten Hindernisdaten kann von einem Laserscanner erhalten werden. Die Hindernisdaten können den Ort der Hindernisse repräsentieren. Zeitcodierte Fahrzeugdaten des Roboterfahrzeugs können empfangen werden. Die Hindernisdaten können mit voreingestellten Kriterien verglichen werden, um die Hindernisdaten in relevante Hindernisdaten und irrelevante Hindernisdaten zu unterteilen. Die relevanten Hindernisdaten entsprechen nicht den voreingestellten Kriterien und werden verworfen. Die relevanten Hindernisdaten können mit einer zweidimensionalen Punktewolke korreliert werden, die einen Index einer Punkteansammlung entspricht. Hindernisdaten mit Zeitstempeln, die älter als ein voreingestellter Schwellwert sind, können verworfen werden. Eine Hinderniskarte kann aus der Punktanordnung erzeugt werden.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Diese und andere Merkmale, Gesichtspunkte und Vorteile dieser Erfindung werden besser verstanden, wenn die folgende detaillierte Beschreibung mit Bezug auf die beigefügten Zeichnungen gelesen wird, wobei:
1 ein Blockdiagramm ist, das ein Robotersteuersystem gemäß einer Ausgestaltung der vorliegenden Erfindung darstellt;
2A–C Blockdiagramme sind, die das Robotersteuersystem gemäß Ausgestaltungen der vorliegenden Erfindung darstellen.
3 eine Draufsicht eines beispielhaften Fahrzeugs ist, das Robotersteuermodule gemäß einem Ausführungsbeispiel der vorliegenden Erfindung aufweist;
4 eine Draufsicht des beispielhaften Fahrzeugs aus 3 ist, das eine Maschine und Robotersteuermodule gemäß einem Ausführungsbeispiel der vorliegenden Erfindung aufweist;
5A–B einen Laserscanner zeigen, mit einem schützenden Schutzschild gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
6 ein Blockdiagramm des Laserscanners ist, der mit einer RCU gemäß einem Ausführungsbeispiel der vorliegenden Erfindung kommuniziert;
7 ein Blockdiagramm eines Fahrervermittleralgorithmus gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ist;
8 ein Blockdiagramm eines Objektbewegungserfassungssystems gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ist;
9 Pfade und Zonen zeigt, die die Bewegungen eines robotergesteuerten Fahrzeugs gemäß einem Ausführungsbeispiel der vorliegenden Erfindung betreffen;
10 Cluster und benachbarte Punkte darstellt, die das Objektbewegungserfassungssystem gemäß einem Ausführungsbeispiel der vorliegenden Erfindung betreffen;
11A–B Gitterzellen darstellen, die mit Punkteclustern assoziiert sind, die das Objektbewegungserfassungssystem gemäß einem Ausführungsbeispiel der Erfindung betreffen;
12 ein Flussdiagramm eines 2D zu 3D Umwandlungssystems zum Erfassen von Hindernissen gemäß einem Ausführungsbeispiel der Erfindung ist;
13A–B 3D-2D Datenpunkte darstellen, die mit dem 3D zu 2D Datenumwandlungssystem gemäß einem Ausführungsbeispiel der Erfindung assoziiert sind;
14 ein Flussdiagramm eines 3D zu 2D Umwandlungssystems zum Erfassen von Hindernissen ist;
15 ein Sensorerfassungssystem gemäß einem Ausführungsbeispiel der Erfindung darstellt;
16 einen Laserscan zeigt, der Löcher oder Negativhindernisse gemäß einem Ausführungsbeispiel der Erfindung erfasst;
17 einen Laserscan zeigt, der Daten eines möglichen Hindernisses aufgrund einer Diskontinuität der Daten gemäß einem Ausführungsbeispiel der vorliegenden Erfindung erhält;
18 einen Laserscan zeigt, der Punkte erhält, die auf einen 2D Scanbereich gemäß einem Ausführungsbeispiel der Erfindung abgebildet werden;
19 eine Single Board Computer Software Architektur für eine RCU gemäß einem Ausführungsbeispiel der Erfindung darstellt;
20 eine Hinderniskarten/Erkennungsfunktion darstellt, die in einer RCU Softwarearchitektur gemäß einem Ausführungsbeispiel der Erfindung ausgeführt wird;
21 eine Teleoperationsfunktion darstellt, die in eine RCU Softwarearchitektur gemäß einem Ausführungsbeispiel der Erfindung ausgeführt wird;
22 eine Folgemodusfunktion darstellt, die in einer RCU Softwarearchitektur gemäß einem Ausführungsbeispiel der Erfindung ausgeführt wird;
23 eine Wegpunktsnavigationsfunktion darstellt, die in einer RCU Softwarearchitektur gemäß einem Ausführungsbeispiel der Erfindung ausgeführt wird;
24 eine Hindernisvermeidungsfunktion darstellt, die in einer RCU Softwarearchitektur gemäß einem Ausführungsbeispiel der Erfindung ausgeführt wird;
25 eine Fahrervermittlungsfunktion darstellt, die in einer RCU Softwarearchitektur gemäß einem Ausführungsbeispiel der Erfindung ausgeführt wird;
26 eine Pfadaufnahmefunktion darstellt, die in einer RCU Softwarearchitektur gemäß einem Ausführungsbeispiel der Erfindung ausgeführt wird;
27 eine Pfadabspielfunktion darstellt, die einer RCU Softwarearchitektur gemäß einem Ausführungsbeispiel der Erfindung ausgeführt wird;
28 eine VCU Schnittstellenfunktion darstellt, die in einer RCU Softwarearchitektur gemäß einem Ausführungsbeispiel der Erfindung ausgeführt wird.
DETAILLIERTE BESCHREIBUNG
Ausführungsbeispiele der Erfindung schaffen Systeme und Verfahren zur Vermeidung von Hindernissen. Bei einigen Ausführungsbeispielen kann ein robotergesteuertes Fahrzeug geschaffen werden, das in einer oder mehreren Betriebsweisen arbeitet. Beispiele solcher Betriebsweisen weisen eine Fernbedienung, eine Wegpunktnavigation, eine Folgebetrieb und einen manuellen Betrieb auf. DAS Fahrzeug kann ein Hinderniserkennung und -vermeidungssystem aufweisen, das dazu in der Lege ist, mit einem oder mehreren der Fahrzeugbetriebsweisen implementiert zu werden. Ein Steuersystem kann vorgesehen sein, um das Fahrzeug in einer oder mehreren Betriebsweisen oder anderes zu betreiben und zu steuern.
Illustratives Steuersystem
1 ist ein Blockdiagramm auf hohem Niveau eines Fahrzeugsteuersystems 100 nach einem Ausführungsbeispiel der vorliegenden Erfindung. Das Fahrzeugsteuersystem 100, das in 1 gezeigt ist, weist ein Robotersteuersystem 104 auf, bei dem das dargestellte Ausführungsbeispiel die vielseitigen Robotersteuermodule 106A–106N aufweisen. Die Robotersteuermodule können miteinander verbunden sein und können miteinander und anderen Steuersystemen und Fahrzeugkomponenten über ein Kontroller Area Network (CAN) Bus 108 und ein verschaltetes Paketnetz 110, wie etwa ein Ethernetnetz kommunizieren. Bei einigen Ausführungsbeispielen wird lediglich ein geschaltetes Paketnetz 110 verwendet.
Das Fahrzeugsteuersystem, das in 1 gezeigt ist, weist weiter verschiedene Betriebssysteme 102A–102N auf. Jedes Betriebssystem 102A–102N kann in demselben Ausführungsbeispiel in direkter oder indirekter Kommunikation mit einem Robotersteuermodul 106A–106N sein. Diese Betriebssysteme 102A–102N können zum Steuern der Bewegung des Fahrzeugs verwendet werden und können, beispielsweise, das Lenksystem, das Bremssystem, das Drosselsystem und das Lenksystem aufweisen. Jedes Betriebssystem kann einen Aktuator aufweisen, etwa, beispielsweise, einen Motor, es kann den Betrieb des bestimmten Betriebssystems steuern. Beispielsweise kann das Bremssystem einen Aktuator beinhalten, der den Einsatz der Bremse für das Fahrzeug steuert.
Die Robotersteuermodule oder Robotersteuereinheiten 106A–106N können weiter verbunden sein mit oder auf andere Weise Eingangssignale von Scannern 12A–B empfangen bzw. weitergeben, etwa Laserscannern, Kameras 114A–B, Funkeinheiten 116A–B und ein Global Positioning System (GPS) 118. Die Robotersteuermodule 116A–N können auch mit anderen geeigneten Nutzlasten verbunden sein und können mit einer oder mehreren CAN Einheiten 122 verbunden sein. Eine CAN Einheit kann, beispielsweise, Dachleuchten oder ähnliche Merkmale des Fahrzeugs steuern. Die Robotersteuermodule 106A–N kön nen Eingänge von diesen verschiedenen Einheiten empfangen, beispielsweise, Scanner 112A–B, Kameras 114A–B und die GPS 118 und kann das geeignete Steuerverhalten für das Fahrzeug bestimmen. Die vielseitigen Robotersteuermodule 106A–N können eine Steuerinformation oder -signale an die Betriebssysteme liefern zum Ausführen des geeigneten Steuerverhaltens. Wenn, beispielsweise, das geeignete Steuerverhalten das Stoppen des Fahrzeugs ist, kann das Robotersteuermodul 106A eine Steuerinformation aussenden, um einen Bremsaktuator des Bremsbetriebssystems 102A zu betätigen und den Einsatz der Fahrzeugbremsen verursachen.
Das Fahrzeug kann weiter eine Fahrzeugsteuereinheit (VCU) aufweisen. Die Fahrzeugsteuereinheit empfängt Eingänge und verwendet den Eingang zum Bestimmen, wie die Steuerung eines oder mehrere Betriebssysteme 102A–N gesteuert wird. Die Fahrzeugsteuereinheit kann, beispielsweise, einen Eingang von einem Robotersteuermodul aufnehmen, das angibt, dass das Fahrzeug nach rechts abbiegen soll. In Antwort auf dieses Signal kann die Fahrzeugsteuereinheit ein Steuersignal an das Lenksystem ausgeben, um den Aktuator zu veranlassen, die Lenkwelle zu drehen.
Sowohl die Fahrzeugsteuereinheit (VCU) als auch die Robotersteuermodule können jeweils einen Prozessor beinhalten. Eine Roboterfahrzeugsteuereinheit mit einem Prozessor ist in weiteren Einzelheiten in 19 beschrieben. Der Prozessor kann ein von einem Computer lesbares Medium aufweisen, etwa einen Speicher mit wahlfreiem Zugriff (RAM), der mit dem Prozessor gekoppelt ist. Der Prozessor führt von einem Rechner ausführbare Programmbefehle, die in dem Speicher gespeichert sind aus, etwa Robotersteueralgorithmen. Derartige Prozessoren können einen Mikroprozessor, einen ASIC und Statusmaschinen aufweisen. Die Prozessoren weisen auf oder können in Kombination mit Medien, beispielsweise computerlesbare Medien, die Befehle speichern, die bei ihrer Ausführung von dem Prozessor den Prozessor dazu veranlassen, die hier beschriebenen Schritte auszuführen. Ausführungsbeispiele von computerlesbaren Medien schließen ein, ohne darauf begrenzt zu sein, eine elektronisch, optische, magnetische oder andere Speicher- und Über tragungsgerät, das dazu in der Lage ist, einen Prozessor mit computerlesbaren Befehlen zu versorgen, etwa einem ausführbaren Code. Andere Beispiele von geeigneten Medien weisen, ohne darauf begrenzt zu sein, eine Floppydisk, eine DVD, eine Magnetscheibe, einen Speicher, einen ROM, RAM einen ASIC, einen konfigurierten Prozessor, alle optischen Medien, alle Magnetband- oder andere magnetische Medien oder irgend ein anderes geeignetes Medium, aus dem ein Computerprozessor Befehle lesen kann. Auch können andere Formen von computerlesbaren Medien Befehle zu einem Computer übersenden oder tragen, einschließlich einen Router, ein privates oder öffentliches Netzwerk, eine andere Übertragungseinheit oder -kanal, sowohl verdrahtet als auch drahtlos. Die Befehle können einen ausführbaren Code aufweisen in jeder geeigneten Computerprogrammiersprache, einschließlich, C, C++, C#, Visual Basic, Java, Python, Perl, und JavaScript.
2A–B sind funktionelle schematische Diagramme eines illustrativen Steuersystems nach einem Ausführungsbeispiel der vorliegenden Erfindung. Das gezeigte Robotersteuersystem weist vier vielseitige Robotersteuermodule oder Roboter Control Units (RCU) und verschiedene Sensoren auf. Das Robotersteuersystem empfängt verschiedene Eingangssignale von Scannern, erzeugt eine Hinderniskarte, bestimmt die Steuerung des Fahrzeugs und sendet Steuerinformation an die Vehicle Control Unit (VCU), die verschiedene Betriebssysteme des Fahrzeugs steuert. Das Ausführungsbeispiel, das in den 3A–B gezeigt ist, weist ein Fahrzeugsteuersystem, etwa ein Fahrzeuglevelsteuerabschnitt 202 auf, der mit einem Robotersteuersystem kommunizieren kann, etwa einem Roboterebenensteuerabschnitt 204. Die beiden Abschnitte 202, 204 arbeiten als eine Hierarchie. Der Fahrzeuglevelsteuerabschnitt 202 behält die Einzigartigkeit des Fahrzeugs, für die es konfiguriert ist, bei.
Die Fahrzeuglevelsteuerung 202 weist eine externe Schnittstelle, einen CAN Diagnoseanschluss auf. Die Fahrzeuglevelsteuerung 202 weist weiter ein elektronisches Spannungszentrum 208 auf. Das elektronische Leistungszentrum liefert Leistung an einen Getriebe motor 210 und einen Bremsmotor 212. Der Getriebemotor 210 und der Bremsmotor 212 sind Aktuatoren für das Schaltungs- bzw. Bremssystem.
Der Fahrzeuglevelsteuerabschnitt 202 weist weiter eine überwachende Levelsteuereinheit (VCU 1) 214 auf. Deren Rolle könnte durch einen zusätzlichen RCU erfüllt werden. Beispielsweise kann die VCU 214 ersetzt werden durch eine zusätzliche RCU (beispielsweise die RCU #5), oder eine Kombination einiger RCUs kann ersetzt werden durch zusätzliche VCUs, obwohl eine VCU nicht alle Funktionen der hier beschriebenen RCUs haben. Der überwachende Levelkontroller 214 ist in Kommunikation mit verschiedenen Systemen des Fahrzeugs. Beispielsweise ist der überwachende Levelkontroller 214 in Kommunikation mit der Schüttmulde, Hilfslichtern und einer Hupe 216. Der überwachende Levelkontroller 214 ist weiter in Kommunikation mit dem Getriebemotor 210 und dem Bremsmotor 212.
Der Fahrzeuglevelsteuerabschnitt 202 weist weiter ein APECS^TM Kontroller 218 zur Drosselsteuerung und zur Diagnose auf. Deren Aufgabe könnte von einer zusätzlichen RCU erfüllt werden. Die APECS^TM Kontroller 218 ist in Kommunikation mit dem Drosselaktuator 220. Die APECS^TM Kontroller 218 liefert Aktuatorsignale zu und empfängt eine Rückkopplung von dem Drosselaktuator 220.
Der Fahrzeuglevelsteuerabschnitt 202 weist weiter einen Armaturenbrettkontroller 222 auf. Der Armaturenbrettkontroller 222 sorgt für eine Steuerung eines Betriebsweiseschalters 224 und für Scheinwerferleuchten und Standlichtleuchten 226. Der Fahrzeuglevelsteuerabschnitt 202 weist weiter den Steuerungsaktuator 228 auf.
Der Roboterlevelsteuerabschnitt 204 weist externe Schnittstellen auf. Die externen Schnittstellen des Robotersteuerabschnitts 204, die in 3A gezeigt ist, weist eine rückwärtige Nutzlast CAN Schnittstelle 230 und eine rückwärtige Nutzlast Ethernet-Schnittstelle 232 auf. Die externen Schnittstellen weisen weiter eine vordere Nutzlast CAN Schnittstelle 234 und eine Ethernetschnittstelle 236 auf.
Der Roboterlevelsteuerabschnitt 204 entsprechend dem in 2A gezeigten Ausführungsbeispiel weist vier Robotersteuermodule auf: ein Überwachungsrobotersteuermodul 238, ein rückwärtiges Wahrnehmungsrobotersteuermodul 244, ein nach vorne gerichtetes Wahrnehmungssteuermodul 254 und eine Kamera und ein Lenkrobotersteuermodul 262 auf. Die Robotersteuermodule 238, 244, 254 und 262 können identisch konfiguriert sein und können für bestimmte Funktionen konfiguriert sein. Wenn die Robotersteuermodule identisch konfiguriert sind, können die Robotersteuermodule basierend auf dem Ort, in dem System oder die Verbindung bestimmen, welche Funktion oder Rolle sie auszuführen haben. Beispielsweise kann ein Widerstand in Verbindung mit einem Robotersteuermodul angeordnet sein und basierend auf dem Widerstand bestimmt das Robotersteuermodul seine jeweilige Funktion. Andere Wege zum Identifizieren der Funktion der Rolle eines Robotersteuermoduls können verwendet werden.
Verschiedene Elemente des Fahrzeuglevelsteuerabschnitts 202 sind in Kommunikation mit Elementen des Roboterpegelsteuerabschnitts 204. Beispielsweise ist das Überwachungsroboterlevelsteuermodul (RCU #1) 238 in Kommunikation mit dem elektronischen Leistungszentrum 208, dem APECS^TM Kontroller 218 und dem Armaturenbrettkontroller 222. Das Überwachungsroboterlevelsteuermodul 238 empfängt Eingangssignale von verschiedenen Sensoren und erzeugt Befehle zur Operation eines Fahrzeugs in einer autonomen Weise. Die US Patentanmeldung Nr. 10/972,082; 10/971,718 und 10/98'71,724 beschreiben beispielhafte autonome Weisen und deren Steuerung.
Bei dem in 2A gezeigten Ausführungsbeispiel empfängt das Überwachungsroboterlevelsteuermodul 238 ein Signal von einer GPS Navigation/Kommunikationsmodul oder -einheit 240 (von, zum Beispiel, NAVCOM Technologie, Torrance, Kananda) und von einem Kompass 242. Diese Sensoren liefern Positions- und Kopfinformation zu dem Kontroller 238 für Navigationszwecke. Ausführungsbeispiele der vorliegenden Erfindung können auch andere Sensoren aufweisen. Beispielsweise weist ein Ausführungsbeispiel eine Trägheitsmessungseinheit (IMU) auf, die die Beschleunigung des Fahrzeugs in jeder Rich tung misst. Das Überwachungsroboterlevelsteuermodul 238 ist ebenfalls in Kommunikation mit dem rückwärtigen Wahrnehmungssteuerungsmodul (RCU #3) 244. Das rückwärtige Wahrnehmungssteuermodul 2224 kann Sensoreingänge von, beispielsweise, einem Laserscanner 252, etwa einem SICK Laserscanner, über eine RS422 Verbindung empfangen.
Das rückwärtige Wahrnehmungssteuermodul 244 ist auch in Kommunikation mit einem Paar von Radioempfängern, einem Nova Roam^TM EH 900, einem Radio 1 246 und einem 802.11b-kompatiblen Radio, Radio 248. Diese Radios erlauben es, dem rückwärtigen Wahrnehmungssteuermodul 244 Befehle von einer Operatorsteuereinheit (OCU) 250 aufzunehmen. Die OCU kann, beispielsweise, für eine Fernbedienung des Fahrzeugs in einer autonomen Weise verwendet werden.
Das Überwachungsroboterlevelsteuermodul 238 in dem in 2A gezeigten Ausführungsbeispiel ist weiter in Kommunikation mit dem nach vorne gerichteten Wahrnehmungssteuermodul 254. Das nach vorne gerichtete Wahrnehmungssteuermodul 254 ist in Kommunikation mit einer Armaturbrettbetriebssteuereinheit (OCU) 256. In dem dargestellten Ausführungsbeispiel weist die Armaturbrett OCU 256 ein TDS Recon IPAQ^TM auf, eine Art eines Personal Digital Assistant. Das nach vorne gerichtete Wahrnehmungssteuermodul 254 ist auch in Kommunikation mit einem nach vorne gerichteten Laserscanner 260. Bei einem Ausführungsbeispiel ist der nach vorne gerichtete Laserscanner 260 ein Laserscanner vom nickenden Typ und weist einen Laserscannermotor 258 auf, der die Bewegung des Scanners 260 steuert. Das nach vorne gerichtete Wahrnehmungssteuermodul 254 sendet Steuersignale zum Steuern des Laserscannermotors 258 aus.
Das überwachende Roboterlevelsteuermodul 238 ist weiter in Kommunikation mit einem Kamera- und Steuerungskontroller (RCU #4) 262. Der Kamera- und Lenkungskontroller 262 ist in Kommunikation mit einer Rückwärtsfahrbetriebskamera 264 und einer Vorwärtsfahrbetriebskamera 268. Der Kamera- und Lenkungskontroller 262 ist weiterhin Zweiweg Kommunikation mit dem Lenkungsaktuator 228 und dem überwachenden Fahrzeuglevelkontroller 214 des Fahrzeugsteuerabschnitts 202.
Das Layout der verschiedenen Kontroller und Sensoren, die in den 3A–B gezeigt sind, können in einer Vielzahl von Art und Weisen in Ausführungsbeispielen der vorliegenden Erfindung implementiert sein. Beispielsweise können die verschiedenen Kontroller kombiniert sein oder aufgeteilt sein in verschiedener Art und Weise Abhängigkeit von der Anzahl und der Typen der verwendeten Sensoren und Abhängigkeit von der Konfiguration des Fahrzeugs. Auch können verschiedene Sensoren und Instrumente auf unterschiedliche Weise verwendet werden. So können Ausführungsbeispiele der vorliegenden Erfindung eine Sensorvereinigung verwenden, um effizient zu arbeiten. Eine Sensorvereinigung erlaubt ein Betrieb des Fahrzeugs auch dann, wenn bestimmte Sensoren nicht arbeiten.
2C zeigt ein weiteres Ausführungsbeispiel einer Fahrzeuglevelsteuerung 150 in Kommunikation mit einer Roboterlevelsteuerung 204 von 2C. Bei diesem Ausführungsbeispiel ist eine Überwachungssteuereinheit (VCU) 154 vorgesehen, die der Überwachungsfahrzeuglevelsteuerung (VCU 1) von 2B entspricht. Die Überwachungs VCU 154 kann Steuersignale aussenden, auch als „Digital with Direction" in anderen Ausführungsbeispielen bezeichnet, an die Schüttmulde, den Signalgeber und die Signallichter 156 bezeichnet. Ein Überwachungs VCU 154 kann Steuersignale von dem Betriebsschalter 158 empfangen. Die Überwachungs VCU 154 empfängt weiter Rückkopplungssignale, bezeichnet als „Rückkopplungsschleife" in anderen Ausführungsbeispielen, von jedem der Odometriesensoren 160, dem Gangschaltungsaktuator 164, dem Bremsaktuator 166 und der Kraftstoffpumpe 172. Bei dem Ausführungsbeispiel von 2C ist ein gesonderter Odometriesensor 160 vorgesehen. Bei anderen Ausführungsbeispielen werden der Gangschaltungsaktuator 164, der Bremsaktuator 166 und die Kraftstoffpumpe 172 als austauschbar als Getriebemotor, Bremsmotor bzw. Drosselaktuator bezeichnet. Die Fahrzeuglevelsteuerung 150 hat ein Lastzentrummodul 162, als „Leistungszentrum" in anderen Ausführungsbeispielen bezeichnet wird. Das Lastzentrummodul 162 ist an einer CAN Kom munikation mit der Roboterlevelsteuerung 204 und sendet weiter Steuersignale an den Gangschaltungsaktuator 164, den Bremsaktuator 166 und den Scheinwerfer/Standlicht-Leuchten 168. Schließlich kann die Fahrzeuglevelsteuerung 150 eine Maschinenkontrollereinheit oder eine ECU 170 aufweisen, in anderen Ausführungsbeispielen auch als „Drosselsteuerung" bezeichnete. Die ECU 170 ist in CAN Kommunikation mit der Roboterlevelsteuerung 204 und steuert die Kraftstoffpumpe 172 zum Liefern von Kraftstoff zu der Maschine.
Bei einem Ausführungsbeispiel ist das Fahrzeug mit einem Hindernisserkennungs/Hindernissvermeidungs(ODOA)-System ausgerüstet, von dem Ausführungsbeispiele im Folgenden beschrieben werden, das dazu ausgebildet ist, zu dem Fahrzeug externe Hindernisse zu erkennen und richtige Steuerungsaktionen zu initiieren, um diese zu vermeiden.
Robotersteuermodul
Bestimmte Robotersteuermodule entsprechend Ausführungsbeispielen der vorliegenden Erfindung können einen oder mehrere Prozessoren und zugehörige Speicher aufweisen, etwa einen einzigen Bordcomputer mit einem Mikroprozessor, einem Netzwerkschalter wie einen Ethernetschalter, einen Aktuatorcontroller, etwa einen umprogrammierbaren Motorcontroller, einen Aktuatorverstärker, etwa einen Motorverstärker, und eine Spannungsversorgung in einem einzigen montierbaren Gehäuse.
Wie im Folgenden anhand der 19–28 gezeigt, kann ein ausführbarer Code in dem Speicher des Robotersteuermoduls gespeichert sein, der von einer CPU ausgeführt werden kann, um das Robotersteuermodul dazu in die Lage zu versetzen, Robotersteuerverläufe auszuführen und diese zu lenken. Jedes Robotersteuermodul in dem Robotersteuersystem kann mit mehreren ausführbaren Codeteilen für unterschiedliche modulare Aufgaben innerhalb des Steuersystems ausgebildet sein. Zum Beispiel kann jedes Robotersteuermodul einen ausführbaren Code für eine Überwachungsaufgabe für eine Aktuatorsteuerung, für ein Sensorbeobachten usw. einschließen. Das Steuermodul kann konfigurierbar sein um nur einen ausgewählten Teil des geeigneten Codes auszuführen, das für die Aufgabe des bestimmten Robotersteuermoduls geeignet ist.
Beispiele der Teile des ausführbaren Codes können ein Verlauflenkungscode, ein Verlaufscode, ein Sensorantriebscode, ein Antriebssteuercode, ein Aktuatrosteuercode, ein Datenmanagementcode, ein Datenbasiscode und ein Datenkonvertercode sein. Jedes Robotersteuermodul kann die Funktion oder die Aufgabe, die es ausführen will, bestimmen und welcher ausführbare Code basierend auf dem Ort, den Verbindungen und anderen geeigneten Verfahren, wie oben beschrieben, es ausführen will. Dies erlaubt eine Austauschbarkeit der Robotersteuermodule.
19 zeigt ein Ausführungsbeispiel einer einzigen Bordcomputer (SBC) Softwarearchitektur für eine Robotersteuereinheit. Die SBC 1900 weist einen Prozessor 1902 und eine Netzwerkverbindung 1904 auf. Die Netzwerkverbindung 1904 kann eine oder mehrere Netzwerkverbindungen sein. Beispiele derartiger Netzwerkverbindungen 1904 weisen Ethernet TCP/IP, USB und CAN Verbindung auf wie J1939.
Die Netzwerkverbindungen 1904 sind zum Verbinden mit einer Mehrzahl von Geräten außerhalb des SBC 1900 eingerichtet, so dass das SBC 1900 eine Mehrzahl von Arten von Daten und/oder Steuersignalen empfangen und aussenden kann. Die RCU kann weiter ein computerlesbares Medium aufweisen, etwa ein Speicher 1906. Der Speicher 1906 kann jede Art eines Speichers sein. Beispiele des Speichers 1906 weisen einen Speicher mit wahlfreiem Zugriff („RAM") einen Nur-Lese-Speicher („ROM") einen optischen Speicher und einen magnetischen Speicher auf. Der Speicher 1906 kann eine Datenspeicherung und/oder eine dauerhafte Datenspeicherung aufweisen zum Speichern von verschiedenen empfangenen oder berechneten Daten und einem ausführbaren Code. Beispiele derartiger Daten und/oder Steuersignale, die von dem SVC 1900 empfangen worden sind, weisen Laserscannerbereichsdaten GPS Positionsdaten, Kompassausrichtungsdaten, Fernbedienungsbefehle von einer entfernten Operatorsteuereinheit (OCU), Armaturenbrettdisplaystatus und -eingang, Softwareupgrades, Fahrzeugstatusinformation, Fahrzeugbetriebsartschalter und Diagnosekommandos von CAN Diagnoseanschlüsse auf. Beispiele derartiger Daten und/oder Steuersignale, die von dem SBC 1900 übertragen worden sind, weisen telemetrische Daten an einen entfernten OCU, Armaturenbrettdisplaybefehle, Softwareupdates zu anderen RCUs, Dateien, Antriebsbefehle an eine Fahrzeugsteuereinheit und Diagnoseantworten an einen CAN Diagnoseanschluss auf.
Wie in weiteren Einzelheiten unten unter Bezugnahme auf die 20–28 beschrieben werden wird, weisen Beispiele eines ausführbaren Codes, ein Betriebssystem, wie beispielsweise BlueCat Linux, einen Datentransport, der eine Software aufweist, wie beispielsweise iRobot AWARE^TM zum Unterstützen des SBC 1900 bei dem Kommunizieren mit äußeren Einheiten und/oder Anwendungen 1908 auf. Die Applikationen 1908 können einen oder mehrere RCU funktionelle Codes und Betriebsverhalten aufweisen. Beispielsweise können die Applikationen 1908 einen Konfigurationscode 1910 aufweisen, der Konfigurationsdaten von einer Speicherung, etwa einer dauerhaften Speicherung, liest, und diese Werte in geeignete Orte in den Datentransport einbringt.
Die Applikationen 1908 können weiter eine Hinderniskarte, Erkennungs- und/oder Vermeidungscode 1912 aufweisen. Die Hinderniskarte und der Erkennungscode können Eingangsbereich- oder Odometriedaten empfangen und eine zweidimensionale Hinderniskarte konstruieren. Der Hindernisvermeidungscode kann Bahnen von einem Betriebslenker 1920 aufnehmen und Hindernisdaten von der zweidimensionalen Hinderniskarte und diese Bahnen entsprechend den Hindernisvermeidungsregeln bewerten.
Andere Applikationen 1908 können einen Fernbedienungscode 1914 aufweisen, der Eingangsbefehle von einer entfernten OCU empfängt und einen Bahnsatz zur Verwendung durch einen Betriebslenker 1920 und verschiedene diskrete Werte ausgibt. Die Applikatio nen 1908 können weiter einen Folgebetrieb 1916 oder halbautonomen Betrieb aufweisen, der Hindernisdaten von der Hinderniskarte zum Orten eines Zieles oder eines Objekts, dem zu folgen, empfängt ist und einen Bahnsatz zur Verwendung durch den Betriebslenker 1920 ausgibt. Ein Wegpunktnavigationscode 1918 kann weiter in die Applikation 1908 eingebunden sein. Der Wegpunktnavigationscode 1918 kann Eingabewegpunktwerte von einem gewählten Pfad einer Ausgabe eines Bahnsatzes zur Verwendung durch den Betriebslenker 1920 empfangen. Der Betriebslenker 1920 kann mit Applikationen 1908 versehen sein zum Empfangen von Eingangsbahnsätzen und Prioritäten von verschiedenen Betriebsverläufen, Hindernisdaten von der Hinderniskarte und Konfigurationsdaten von verschiedenen Konfigurationspublikationen. Der Betriebslenker 1920 kann auch ausgewählte Bahndaten zu Aktuatoren oder anderen Geräten außerhalb des SBC 1900 ausgeben.
Die Applikationen 1908 können weiter einen Datenloggingcode 1922 aufweisen, der Statusdaten von Fahrzeugsensoren aufnimmt und Daten in einen Datenspeicher schreibt, etwa einen dauerhaften Datenspeicher. Nach dem Empfangen eines Operatorbefehls kann der Datenloggingcode 1922 Daten drahtlos oder über eine Drahtleitung an ein OCU oder eine entfernbare Datenspeichereinheit kopieren. Diese Applikationen können eine Wegaufzeichnung und einen Wegrückspielcode 1924 aufweisen. Der Bahnaufzeichnungscode kann Fahrzeugsensoren und Eingaben von einem Operator empfangen und diese Daten, etwa Wiedergaben von Fahrtwegpunkten, zur Datenspeicherung einschreiben, etwa einem dauerhaften Datenspeicher. Der Pfadrückspielcode kann einen Pfad empfangen, wie er von einem Operator vorgegeben worden ist und kann die Wegpunkte, die in diesen Weg eingeschlossen sind, an die Wegpunktnavigation abspielen.
Die Applikation 1908 kann weiter einen Telemetriecode 1926 aufweisen, der Statusdaten von Fahrzeugsensoren empfangen und Pakete an eine entfernte ODU aussenden kann. Eine Armaturenbrettdisplaysteuerung 1928 kann weiter an der Applikation eingeschlossen sein, die Statusdaten von Fahrzeugsensoren und Eingaben von einem Tastaturdisplay empfangen kann und Displaybefehle an das Armaturenbrettdisplay ausgeben kann.
Diese Applikationen 1908 können auch einen Versionsupgrademanager 1930, eine VCU-Schnittstelle 1932 und eine Bereichsschutzapplikation 1934 aufweisen. Der Versionsupgrademanager 1930 kann Softwareupgrades empfangen und Softwareupgrades über andere RCUs verteilen. Die VCU Schnittstelle 1932 kann Betriebs- und Diagnosebefehle empfangen und Betriebsbefehle an die VCU an geeignete CAN Botschaften aussenden und Diagnosebotschaften an andere RCUs aussenden und deren Berichte an die VCU zurückgeben. Die Bereichsschutzapplikation 1934 kann Unterbrechungen der Hindernisdaten von dem Laserscanner erkennen und Ersatzdaten ausgeben, die in jede Richtung nah sind, die von den Laserscannern erkannt werden können.
Die 20–28 zeigen bestimmte Ausführungsbeispiele einer RCU softwarearchitektur die Applikationsebenenfunktionen ausführen und Softwaremodule für den gegenwärtigen Applikationsbereich aufweisen und Softwaremodule für andere Applikationsbereiche. 20 zeigt eine Hinderniskarte/Erkennung RCU Softwarearchitektur 2000. Die RCU Softwarearchitektur weist eine Applikationsebene 2002 auf, die eine oder mehrere Applikationen aufweisen kann, etwa eine Hinderniskarte/Detektionsapplikation 2004, eine Datentransportebene 2006, eine Betriebssystemebene 2008 und eine Datenspeicher/Netzwerkverbindungsebene 2010. Das Betriebssystem 2008 kann ein Betriebssystem aufweisen, etwa ein Linux Betriebssystem. Die Datenspeicherungs/Netzwerkverbindungsschicht 2010 kann eine Datenspeicherung wie eine dauerhafte Datenspeicherung aufweisen und eine oder mehrere Netzwerkkonnektoren wie CAN, USB und Ethernet.
Bei dem in 20 dargestellten Ausführungsbeispiel wird die Hinderniskarten/Detektionsapplikation 2004 durch Empfangsbereichsdaten von einem vorderen Laserscanner 2012 und einem rückwärtigen Laserscanner 2014 über eine TCP Verbindung ausgeführt. Die Bereichsdaten werden durch einen 3D-zu-2D Hindernisdetektor 2018 über eine FIFO Flusskontrolle empfangen. Ein 3D-zu-2D-Hindernisdetektor 2018 empfängt weiter Odometriedaten von einer VCU Schnittstelle 2016 über einen geteilten Speicher. Die Odometriedaten können Geschwindigkeitsdaten aufweisen, die dem Fahrzeug zugehörig sind.
Der 3D-zu-2D-Hindernisdetektor 2018 empfängt die Bereichsdaten und die Odometriedaten zur Erzeugung eine 2D Hinderniskarte 2020.
21 zeigt ein Ausführungsbeispiel einer Fernbedienung die ausgeführt wird in einem RCU 2100. Die Fernbedienungsapplikation 2104 kann Eingangsdaten von einem entfernten OCU aufnehmen und einen Bahnsatz für einen Betriebsarbiter ausgeben und verschiedene diskrete Werte. Die Fernbedienungsapplikation 2104 kann durch Empfangen von Fernbedienungsbefehlen diskrete Daten von einem entfernten OCU über einen Ethernetkonnektor und ein Protokoll ausführen, etwa ein Verwendetdatagrammprotokoll (UDP) bei einer diskreten Fernbedienung 2116. Die diskrete Fernbedienung 2116 kann Befehle von dem OCU empfangen und diese als Daten für diskrete Befehle wie Gänge, Folgeverhalten, Ein/Aus, Starter, Brennstoffunterbrechung, Hupe, Missachten der Hindernisvermeidung, Umkehrwegaufzeichnung Ein/Aus, Hinzufügen von Punkten zu gegenwärtigem Pfad, Auswählen Pfad zum Rückspielen und Rückspielpfad in umgekehrter Reihenfolge. Ein Fernbedienungsverlauf 2118 empfängt einen Fernbedienungsbefehlstrom von einer entfernten RCU 2114 über einen Ethernetverbinder und UDP. Das Fernbedienungsverhalten 2118 gibt einen Bahnsatz basierend auf dem Kommandostrom 2114 an einen Betriebsarbiter 2120 aus.
22 zeigt ein Ausführungsbeispiel eines folgenden (halb-autonomer Betrieb) Ausführung in einer RCU Softwarearchitektor 2200. Die RCU Architektur 2200 weist eine Applikationsebene 2202 auf, die eine folgende (halb-autonomer Betrieb) 2204 Applikation hat, die Hindernisdaten von der Hinderniskarte aufnehmen kann, um einen Leiter zu lokalisieren und einen Bahnsatz zur Verwendung von dem Betriebsarbiter zu verwenden. Das Folgen (halb-autonomer Betrieb) 2204 führt durch Einschließen eines Folgeverhaltens 2216 eine Funktion aus, die Daten von einer Antriebskonfiguration 2212 und einer 2D Hinderniskarte 2214 über einen geteilten Speicher aufnimmt. Das Folgeverhalten 2216 empfängt weiter ein Folgeverhalten, etwa von einem Betriebssystem 2208 oder von einem außen liegenden Gerät, etwa einem OCU. Das Folgeverhalten 2216 erzeugt einen Bahnsatz basierend auf den empfangenen Daten und erzeugt einen Bahnsatz für den Betriebsarbiter 2218.
23 zeigt ein Ausführungsbeispiel einer Wegpunktnavigation (autonomer Betrieb), die ausgeführt wird in eine RCU Softwarearchitektur 2300. Die RCU Softwarearchitektur 2300 weist eine Applikationsebene 2302 auf, die eine Wegpunktnavigation (autonomer Betrieb) Applikation 2304 aufweist, die Eingangswegpunktwerte von einem ausgewählten Weg aufnehmen kann und einen Bahnsatz zur Verwendung von einem Betriebsarbiter 2322 ausgeben kann. Die Wegpunktnavigationsausführung nimmt Wegpunkte von einem entfernten OCU 2312 über eine Ethernetverbindung und einem TCP Verbindungsprotokoll zu einer Wegpunktlistenmanager 2320 über ein FIFO auf und GPS Daten von einem GPS 2314 über die Ethernetverbindung und ein UDP Protokoll zu einem Wegpunktverlauf. Der Wegpunktlistenmanager 2316 empfangt weiter Wegpunkte von einem Pfadmanager 2316 über das FIFO. Der Wegpunktlistenmanager 2316 nach einigen Ausführungsbeispielen weist nur einen Eingabe FIFO auf und sowohl der Manager 2316 als auch der entfernte OCU 2312 schreiben in den FIFO Eingang. Der Wegpunktlistenmanager 2320 schafft Wegpunktdaten zu einem Wegpunktverlauf 2322 über das TCP. Der Wegpunktverlauf 2322 empfängt Odometriedaten von einer VCU Schnittstelle 2318 über UDP und erzeugt einen Bahnsatz der an einem Antriebsarbiter vorgesehen ist.
24 zeigt ein Ausführungsbeispiel einer Hindernisvermeidung, ausgeführt in einer RCU Softwarearchitektur 2340. Die RCU Softwarearchitektur 2400 weist eine Applikationsebene 2402 auf, die eine Hindernisvermeidungsapplikation 2404 aufweist. Die Hindernisvermeidungsapplikation 2404 kann Eingangsbahnen von einem Antriebsarbiter 2418 und Hindernisdaten von einer 2D Hinderniskarte 2414 aufnehmen und die Bahnen entsprechend den Hindernisvermeidungsregeln bewerten. Die Hindernisvermeidungsapplikation 2404 weist einen Hindernisvermeidungsverhaltenscode 2416 auf, der Daten von einer 2D Hinderniskarte 2414, Konfigurationsdaten von einer Antriebskonfiguration 2412, ein Hindernisvermeidungsverhalten von einem Betriebssystem 2408 und/oder einer außenliegenden Einheit, etwa einem RCU und einen Eingangsbahnensatz von dem Antriebsarbiter 2418 empfangt. Der Hindernisvermeidungsverhaltenscode 2416 bewertet die Bahnsätze basie rend auf den Konfigurationsdaten, den Hinderniskartendaten und dem Hindernisvermeidungsverhalten und liefert den Bahnsatz an den Antriebsarbiter 2418.
25 zeigt ein Ausführungsbeispiel eines Antriebsarbiters der eine RCU Softwarearchitektur 2500 ausführt. Die RCU Softwarearchitektur 2500 weist eine Applikationsebene 2502 auf mit Applikationen, etwa einem Antriebsarbiter 2504. Der Antriebsarbiter 2504 kann Bahnsätze und Prioritäten von verschiedenen Verläufen, Hindernisdaten aus der Hinderniskarte und Konfigurationsdaten aus verschiedenen publizierten und ausgegebenen ausgewählten Bahnsätzen beinhalten. Ausführungsbeispiele des Antriebsarbiters können zwischen 10 und 100 Hz arbeiten. Bei einem Ausführungsbeispiel arbeitet der Betriebsarbiter bei 20 Hz. Die Betriebsarbiterapplikation 2504 weist einen Antriebsarbitercode 2520 auf, der Bahnsätze von einer Mehrzahl von Funktionen empfängt wie einem Hindernisvermeidungsverhalten 2512, Wegpunktnavigation (autonomer Betrieb) Verhalten 2516, Folgeverhalten (halb-autonomer Betrieb) Verhalten 2514 und Fernbedienungsverhalten 2518 über gemeinsame Speicher oder anders. Der Antriebsarbiter 2520 empfängt weiter Plattformdaten über den gemeinsamen Speicher von einem Betriebssystem 2508 oder einem außenseitigen Gerät. Basierend auf den empfangenen Daten kann der Antriebsarbiter 2520 Geschwindigkeits- oder andere Befehle erzeugen und den Befehl an eine VCU Schnittstelle 2520 anlegen. Die VCU Schnittstelle 2522 kann die Befehle über ein VCU oder anders kommunizieren.
26 zeigt ein Ausführungsbeispiel einer Pfadaufzeichnungsausführung in einer RCU Softwarearchitektur 2600. Die RCU Softwarearchitektur 2600 weist eine Applikationsebene 2620 auf mit einer Pfadaufzeichnungsapplikation 2604. Die Pfadaufzeichnungsapplikation 2604 kann Ortsdaten von den Fahrzeugsensoren aufnehmen und Eingaben von einem Operator und Daten in einen dauerhaften Datenspeicher einschreiben, der die Wegpunkte für einen Pfad darstellt. Beispielsweise kann der Pfadmanagercode 2618 vorgesehen sein, der Befehle von einem entfernten OCU 2612 und/oder Armaturenbrettdisplay 2614 über eine Ethernetverbindung aufnehmen kann. Die Befehle können neue Pfade aufzeichnen, Wegpunkt aufzeichnen, neue Pfade löschen und neue Pfade sichern. Der Pfadmanagercode 2616 kann weiter GPS Daten von einem GPS 2612 und Datennamen und Typen von dauerhaften Datenspeicherungen einschließlich Datenspeicher/Netzwerkverbindungsschicht 2610 aufnehmen. Der Wegmanager 2518 kann Daten aussenden wie eine Anzahl von existierenden Pfadwegen, Namen von existierenden Pfaddateien, Namen einer Pfaddatei, die gegenwärtig verwendet wird und einen Pfadmanagerzustand zu einer Datentransportebene 2606. Der Pfadmanager 2618 kann weiter Wegpunktdaten über einen Filter 2622 an einen dauerhaften Datenspeicher aussenden.
27 zeigt ein Ausführungsbeispiel einer Pfadrückspielung, die in einer RCU Softwarearchitektur 2700 ausgeführt wird. Die RCU Softwarearchitektur 2700 weist eine Applikationsebene 2702 auf, die Applikationen aufweisen kann, etwa eine Pfadrückspielapplikation 2704. Die Pfadrückspielapplikation 2704 kann einen Pfad empfangen, der durch einen Operator ausgebildet wird und die Wegpunkte, die den Weg zu einer Wegpunktnavigation einschließen, abspielen. Beispielsweise kann der Pfadmanagercode 2716 Befehle empfangen, wie einen abgespielten Pfad und Pfadnamen von einem entfernten OCU 2712 und/oder Armaturenbrett OCU, wie einem Armaturenbrettdisplay 2714. Der Pfadmanager 2716 kann auch Dateinamen und -typen von einem dauerhaften Speicher empfangen. Der Datenmanager 2716 kann Wegpunkte zu einem Armaturenbrettlistenmanager 2718 erzeugen, der mit einer Wegpunktnavigationsapplikation (nicht gezeigt) kommunizieren kann.
27 zeigt ein Ausführungsbeispiel einer VCU Schnittstelle, die in einer RCU Softwarearchitektur 2800 ausgeführt wird. Die RCU Architektur 2800 kann eine Applikationsebene 2802 aufweisen mit Applikationen, etwa einer VCU Schnittstelle 2804. Die VCU Schnittstellenarchitektur 2804 kann Betriebs- und Diagnosebefehle empfangen und Betriebskommandos über ein VCU über eine geeignete CAN Botschaft aussenden, Diagnosebotschaften zu anderen RCUs aussenden und Berichte an den VCU zurückgeben. Die VCU Schnittstellenapplikation 2804 kann einen VCU Treiber 2816 beinhalten, der Konfigurationsdaten von einer Konfiguration 2812 aufnimmt und Geschwindigkeits- oder andere Fahrzeugbe fehle von einem Betriebsarbiter 2814 und Odemetriedaten und/oder andere Statusdaten an eine Datentransportebene 2806 und CAN Befehle an einen VCU über einen CAN Konnektor und eine Datenspeicher/Netzwerkverbindungsschicht 2810 aussenden. Der VCU Treiber 2816 kann weiter Statusinformationen von der VCU über die CAN Konnektion empfangen.
Illustratives Fahrzeug
Ausführungsbeispiele der vorliegenden Erfindung können in einer Vielzahl von Fahrzeugen verwendet werden, etwa Automobilen, Lastwagen, Lieferwagen und jedem anderen geeigneten autonomen Fahrzeug. Wie oben beschrieben, können mehrere Robotersteuermodule in einem Robotersteuersystem eines Fahrzeugs oder einer mobilen Plattform verwendet werden. Die Robotersteuermodule können gemeinsam arbeiten, beispielsweise, wie unter Bezugnahme auf die 1 und 2A–B gezeigt, um die Verarbeitung und das Rechnen des Robotersteuersystems zu verteilen.
Die 3 und 4 sind Draufsichten auf ein illustratives Fahrzeug nach einem Ausführungsbeispiel der vorliegenden Erfindung. Das Fahrzeug 300, das in den 3 und 4 gezeigt ist, ist ein sechsrädriges, mit Diesel betriebenes Gebrauchsfahrzeug, etwa ein John Deere^TM Gator^TM (www.deere.com). Es ist zu beachten, dass die 3 und 4 das Fahrzeug 300 zeigen mit einer Maschine 316 und mit einer Schüttmulde am rückwärtigen Teil, wobei die Schüttmulde am rückwärtigen Teil des Fahrzeugs 300 entfernt ist. Ausführungsbeispiele der vorliegenden Erfindung schaffen ein verteiltes Robotersteuersystem für ein Roboterfahrzeug, etwa das Fahrzeug 300 oder eine mobile Plattform, die eine Roboterplattform beinhaltet mit einem Körper und einer Maschine oder Motor 316, die mit einem Antrieb versehen ist, einen definierten Satz von Robotersteuerroutinen, die ausgewählt sind aus einer Verhaltensarbitration und Verläufen; Sensortreibern, Antriebs/Aktuatorcontrollern, Datenbasismanagement und Datenbasis oder Datenwandlern. Das Fahrzeug kann auch eine Mehrzahl von austauschbar montierbaren Modulen 238, 244, 254, 262 haben, jedes aus tauschbar montierbare Modul 238, 244, 254, 262 weist einen Spannungseingang, eine Mehrzahl von Netzwerkkonnektoren und einen Mehrstift-Konnektor auf, der von außerhalb des austauschbar montierbaren Moduls zugänglich ist und jedes austauschbar montierbare Modul weist eine Mikroprozessorplatine auf mit einem einen Code ausführenden dynamischen Speicher (beispielsweise SDRAM). Die Mikroprozessorplatine kann weiter eine Mehrzahl von Protokolltransceivern aufnehmen. Der Mehrstift-Konnektor kann in der Lage sein zum Kommunizieren mit der Mehrzahl von Protokolltransceiversensoren. Die Mikroprozessorplatine kann weiter einen nicht-flüchtigen Speicher mit einem ausführbaren Code aufweisen. Jede Mikroprozessorplatine eines austauschbar montierbaren Moduls kann konfigurierbar sein, um einen ausgewählten Teil eines ausführbaren Codes auszuführen. Ein Paketnetzwerkschalter kann auch vorgesehen sein. Jeder aus der Mehrzahl von Netzwerkkonnektoren kann in der Lage sein zum Verbinden eines Paketnetzwerks, das über den Körper verteilt ist und mit dem Paketnetzwerkschalter kommuniziert. Das Paketnetzwerk kann dazu in der Lage sein Befehle zu oder von einer Mikroprozessorplatine weiter zu geben. Die Mehrzahl von Mikroprozessorplatinen kann mit Befehlen zum Laden und Ausführen von diskreten aus einer Mehrzahl von definierten Sätzen von Robotersteuerroutinen versehen sein, wie in unterschiedlichen Softwarearchitekturen unterschiedlicher RCUs in den 19–28 gezeigt, derart, dass der definierte Satz von Robotersteuerroutinen unter der Mehrzahl von austauschbar montierbaren Modulen ausgeführt wird.
Die Robotersteuermodule, Systeme und Verfahren, wie sie hier beschrieben werden, sind jedoch allgemein angewendet durch eine einfache Mechanik von einer RCU 238, 244, 254 oder 262 pro Aktuator unter Verwendung der verfügbaren RCUs 238, 244, 254, 262 sodann für Sensoren, Berechnung und Kommunikationen. Zusätzliche RCUs können hinzugefügt werden für zusätzliche Sensoren, Berechnungen oder Kommunikationen ohne Betreiben eines Aktuators. Die RCUs 238, 244, 254, 262 können zum Steuern lediglich von Sensoren, Berechnung und/oder Kommunikationen verwendet werden. Dies gilt für jedes Fahrzeug jeder Größe oder Konfiguration, einschließlich kleiner elektrischer Fahrzeuge mit lediglich einem oder zwei Aktuatoren, (d. h., rahmengesteuert) und landwirtschaftlichen oder Baufahrzeugen mit viel mehr (beispielsweise einem Aktuator für jede Steuerung bei einem Fahrzeug mit komplexer Konstruktion). Die RCUs 238, 244, 254, 262 sind vernetzt und arbeiten auf dieselbe Weise wie hier diskutiert.
Das illustrative Fahrzeug 300 weist ein Robotersteuersystem mit einer Anzahl von Robotersteuermodulen 238, 244, 254, 262 auf, die jeweils in einem montierbaren Gehäuse beinhaltet sind, das verwendet werden kann zum Steuern des Betriebssystems, etwa einem Drosselsystem, einem Lenksystem, einem Bremssystem und einem Schaltsystem. Bei diesem Ausführungsbeispiel sind die Robotersteuermodule 238, 244, 254, 262 in Leerräumen in dem Fahrzeug über das Fahrzeug verteilt. Räume können existieren als Fahrgasträume, die nicht verwendet werden in dem Fahrzeug vor der Installation des Robotersteuersystems (wie in den 3–4 gezeigt). Auf diese Weise wird wertvoller Raum für Personen oder Nutzlast nicht von den Elektroniken des Robotersteuersystems beansprucht. Das Robotersteuermodul 1 238 ist beispielsweise in dem Maschinenraum 302 des Fahrzeugs 300 positioniert. Ein Wärmeschild 304 kann verwendet werden, um das Robotersteuermodul 1 238 und andere Elektroniken 306, 308 vor der Wärme der Maschine zu schützen. Bei einem Ausführungsbeispiel kann das Wärmeschild 304 eine Dichtung an seiner oberen Fläche haben, so dass es eine Dichtung mit der oberen Fläche der Schüttmulde bilden kann (nicht gezeigt).
Die Robotersteuermodule 238, 244, 254, 262 kann jeweils drei unterschiedliche Funktionen haben. Beispielsweise kann ein Robotersteuermodul eine Betriebssystemsteuer (beispielsweise ein System zum Betrieb eines Fahrzeugs) und ein anderes Robotersteuermodul kann Überwachungsfunktionen ausführen. Bei einem Ausführungsbeispiel ist jedes Robotersteuermodul dazu in der Lage, jede von unterschiedlichen Funktionen abhängig von der Anordndung in dem Fahrzeug auszuführen. Andere Ausführungsbeispiele desselben oder eines anderen Fahrzeugs kann mehr oder weniger Steuerrobotermodule haben.
Das Robotersteuermodul 2 254 kann an der vorderen Laserscanneranordnung 310 positioniert sein. Das Robotersteuermodul 3 244 kann auf der rückwärtigen Laserscanneranordnung 312 angeordnet sein. Das Robotersteuermodul 4 262 kann in der Motorhaube 314 des Fahrzeugs angeordnet sein. Die Position der Robotersteuermodule in den Leerräumen, gezeigt in den 3 und 4, ist illustrativ und eine Vielzahl von anderen Konfigurationen sind möglich. Das Positionieren und Montieren der Robotersteuermodule nahe der Einrichtungen, an die sie Steuersignale aussenden und von denen sie Steuersignale empfangen, kann die Rauschstörung mit diesen Signalen reduzieren. 4 zeigt das Layout verschiedener anderer elektronischer Komponenten des Robotersteuersystems des Fahrzeugs 300 nach einem Ausführungsbeispiel der vorliegenden Erfindung. Beispiele solcher anderer Komponenten weisen einen Batterieequalizer 30, eine GPS 352, VCU 354, Kameras 358, einen Kompass 360, Radios 362, Spannungszentrum 364 und einen Kontroller 366 auf.
Hinderniserkennungs/Hindernisvermeidungssystem
Wie oben erwähnt, ist das Fahrzeug mit einem Hindernisvermeidungs (ODOA) System versehen, das ausgebildet ist zum Erkennen von Hindernissen außerhalb des Fahrzeugs und zum Initiieren von geeigneten Steueraktionen um diese zu vermeiden. Das ODOA System des Fahrzeugs weist sowohl Hardware – als auch Softwarekomponenten auf und ist ausgebildet, um ausfallsicher zu sein, ohne die Fähigkeit für externe Operatoren zu begrenzen, das Fahrzeug vollständig zu beherrschen, falls dies militärisch notwendig ist. Bei einem solchen Ausführungsbeispiel weist das Fahrzeug die folgenden Komponenten auf: (i) eine vordere Neigungslaserscanneranordnung; (ii) eine rückwärtige Laserscanneranordnung; (iii) eine Robotersteuereinheit unter Verwendung eines Speichers mit einem ausführbaren Code, etwa einer Bereichsschutzanwendung und einer Kontrolle (oder einem Antriebsarbiter) Applikation; und (iv) einer Hinderniskarte. Andere Typen von Scannern, andera als Laser, und Sensoren können ebenfalls in dem System verwendet werden, etwa solche, die in der Lage sind zum Erzeugen einer besonderen Karte oder eines Konus von Bereichsvek toren (beispielsweise Wahrnehmung). Beispiele solcher Sensoren und Scanner schließen LIDAR, Stereovision, Radar und Sonar ein.
Es wird jetzt auf die 5A–B Bezug genommen. Hier ist ein vorderer Neigungslaserscanner 400 nach einem Ausführungsbeispiel der vorliegenden Erfindung gezeigt. Der vordere Neigungslaserscanner 400 ist allgemein auf der Frontseite des Fahrzeugs angeordnet und weist einen Laserscanner 402 zum Aussenden eines Laserstrahles 403 zum Erkennen des Vorhandenseins eines Hindernisses, einen Scannermechanismus 404 zum Manipulieren der Position des Laserscanners 402 und damit der Richtung des Laserstrahles 403, eine Schutzführung 406 zum Verhindern einer Zerstörung des Frontneigungslaserscanners 400 auf. Ein Beispiel eines derartigen Laserscanners 402 ist ein LMS-291 Laserscanner, der von SICK Minneapolis, MN hergestellt wird. Zusätzlich oder alternativ zu dem Laserscanner 402 kann ein LADAR/LIDAR erzeugt werden, der eine Punktwolke oder eine Tiefenkarte erzeugt. Der LADAR/LIDAR kann auch Radar, Steroscope sichten oder andere Sensorfunktionalitäten schaffen, die verwendet werden können zum Erzeugen einer Punktwolke und/oder Tieferkarte. Bei einigen Ausführungsbeispielen kann das LADAR/LIDAR mit dem Laserscanner 402 austauschbar sein.
Eine nach vorne gerichtete Neigungslaserscanneranordnung nach einigen Ausführungsbeispielen der vorliegenden Erfindung kann „wahre" oder interpolierte 3D Daten über Hindernisse vor dem Fahrzeug geben und führt diese Daten zu Bordcomputern, etwa einem einzigen Bordcomputer, der mit einer Robotersteuereinheit zur Verarbeitung zugehörig ist. Die nach vorne weisende Laserscannereinheit 400 nickt mit einer 2 Hz Rate, erreicht seinen maximalen Blickwinkel 15 Grad unterhalb der Horizontalen (auf den Erdboden blickend) und erreicht seinen maximalen Blickwinkel von 25 Grad nach oben (in den Himmel blickend). Die Laserscannereinheit 400 erzeugt 181 Bereichslesungen pro Abtastung (jede Abtastung schließt in 26 Millisekunden) ab aus einem maximalen Bereich von 50 Metern von 50 Grad rechts (der Steuerbordseite des Fahrzeugs) bis 90 Grad nach links (der Backbordseite des Fahrzeugs).
In dem besonderen in den 5A–B gezeigten Ausführungsbeispiel weist die Schutzführung 406 zwei Tragelemente 408, 410 auf, die mit einer Laserscannerbasis 412 verbinden. Eine Anzahl von Stützrippen 414, 416, 418 kann zwischen den beiden Stützelementen 408, 410 vorgesehen sein und ist positioniert zum Schützen des vorderen Neigungslaserscanners 408 vor einer Zerstörung und erlaubt es dem Laserscanner 402, Hindernisse zu erkennen unter Verwendung des Laserstrahls 403, wobei keine Hindernisse von dem Laserstrahl 403 unentdeckt bleiben. Beispielsweise können die Tragrippen 416, 418 derart positioniert sein, dass der Querschnittsbereich, der innerhalb des winkligen Fensters des Laserstrahls 403 begrenzt ist, so dass die Stützrippen 416, 418 die Erkennung von Gegenständen nicht verhindert. Alternativ können die Stützrippen 416, 418 außerhalb des Winkelfensters des Laserstrahls 403 angeordnet sein. Zusätzlich können die Stützelemente 408, 410 außerhalb des winkligen Fensters des Laserstrahls 403 angeordnet sein, wenn der Laserstrahl in einer neigenden Betriebsweise ist. Alternativ können die Stützelemente 408, 410 derart positioniert sein, dass ein Querschnittsbereich der Stützelemente 408, 410 in dem Winkelfenster des Laserstrahls 403 ist.
Ein rückwärtiger Laserscanner kann auf der Rückseite des Fahrzeugs angeordnet sein zum Erkennen von Hindernissen und kann, ähnlich dem Frontlaserscanner, eine Schutzführung aufweisen, um den rückwärtigen Laser daran zu hindern, zerstört zu werden. Die Schutzführung kann eine beliebige Anzahl von Stützrippen oder Stützelementen aufweisen, die positioniert sind, um zu verhindern, dass der rückwärtige Laserscanner zerstört wird und es dem Laserscanner erlaubt, Hindernisse zu erkennen. Der rückwärtige Laserscanner kann dieselbe Ausbildung wie der Frontneigungslaserscanner haben, der in den 5A–B gezeigt ist. Der rückwärtige Laserscanner kann ebenfalls einen Laserscanner aufweisen wie einen LMS-291, der von SICK, Minneapolis, MN hergestellt wird.
Wie in 6 gezeigt, kann der Neigungslaserscanner 400 mit einem RCU 502 verbunden sein und drei-dimensionale Daten an die RCU 502 übertragen. Die RCU 502 kann Daten empfangen, die von dem Laserscanner 400 übertragen werden und kann mit anderen RCUs und einer Überwachungs RCU durch, beispielsweise, eine Ethernetverbindung 504 kommunizieren. Die RCU 502 kann weiter einen Motor steuern, der mit dem Laserscanner 400 verbunden ist, um die Position des Laserstrahles zu verhindern. Bei einem Ausführungsbeispiel des Laserscanners ist der Motor ein Maxon Motor EC40 mit einem GP52C Getriebe versehen.
Die rückwärtige feste Laserscanneranordnung kann 2D Daten über Hindernisse hinter dem Fahrzeug gewinnen und diese Daten an Bordrechner zur Verarbeitung übermitteln. Die rückwärtige Laserscannereinheit kann in einer festen horizontalen Position montiert sein. Die Laserscannereinheit kann 181 Bereichslesungen pro Abtastung erzeugen (jeder Scan schließt in 26 Millisekunden ab) aus einem maximalen Bereich von 50 Meter von 90 Grad nach rechts bis 90 Grad nach links.
Die Bereichsführungssoftware kann Unterbrechungen der Hindernisdaten von den Laserscannern erkennen und gibt Ersatzdaten aus, die angeben, ob Hindernisse in jeder Richtung, die abgetastet werden kann („Halbmonde") vorliegen. Dies verhindert, dass das Fahrzeug sich in eine Richtung bewegt, die durch die Bordsoftware wenig zuverlässig als frei von Hindernissen erkannt worden sind.
Eine Hinderniskarte gibt die Relativposition von Hindernissen bezüglich des Fahrzeugs an und ist im Allgemeinen von einer Robotersteuereinheit in dem Robotersteuersystem über den Eingang, der von den Sensoren empfangen worden ist, etwa dem vorderen und dem rückwärtigen Laserscannern erzeugte. Die Steuersoftware bestimmt die richtige Bahn durch das Hindernisfeld unter Verwendung der Hinderniskarte und befiehlt das Steuersystem geeignet (Steuerung, Drossel, Bremse, Schaltung) um diese Bahn zu erreichen.
Nach dem Empfangen von sich auf Hindernisse, die gewünschte Richtung, sich bewegende Gegenstände usw. beziehende Informationen kann die Robotersteuereinheit in dem robotisch gesteuerten Fahrzeugaktionen basierend auf diese Information entscheiden. Aktionen können, beispielsweise, eine Änderung der Geschwindigkeit des Fahrzeugs eine Änderung der Fahrzeugrichtung usw. anschließen. Ein Antriebsarbitersystem kann vorgesehen sein, um basierend auf empfangenden und/oder bekannte Information die bevorzugten Aktionen, die das Fahrzeug ausführen soll, zu entscheiden. Der Arbiter verwendet einen Algorithmus zum Bestimmen dieser Aktionen. Insbesondere empfängt der Arbiter eine Information, etwa Bestimmungs- oder Hindernisdaten von Sensoren und erzeugt Sätze von möglichen Aktionen. Beispielsweise können Sätze oder Bahnsätze vorgesehen sein durch einen oder alle liefernden oder projizierenden Komponenten. Projizierte Komponenten erzeugen Aktiionen und können eine Fernbedienungskomponente, „Follow Me" Betriebsinformation, odometrische Wegpunkte und GPS Wegpunkte einschließen. Projizierende Komponenten begrenzend die Aktion und können Hindernisse einschließen, die von den Sensoren erkannt worden sind oder andere Information.
7 zeigt einen Betriebsarbiteralgorithmus 600 nach einem Ausführungsbeispiel der vorliegenden Erfindung. Wie in 7 gezeigt, werden Aktionssätze bei 602 derart erzeugt, dass ein erster Satz von möglichen Aktionen 604 von einer Fernbedienungsbetriebsart und einem zweiten Satz von möglichen Aktionen 606 in einer GPS Wegpunktbetriebsart. Der Arbiter wählt sodann einen Aktionssatz bei 608 aus basierend auf dem Prioritätswert, der an dem Datensatz angebracht ist. Der ausgewählte Aktionssatz wird dann bewertet und jedwede Projektoren können auf den Aktionssatz bei 610 angewendet werden, beispielsweise das Begrenzen von individueller Aktionen in einem Aktionssatz. Ein Element des Aktionssatzes wird bei 612 ausgewählt und kann verwendet werden bei einer Präferenz, die jeder Bahn in dem Satz zugehörig ist. Der Arbiter kann sodann das ausgewählte Element ausgeben 614.
Jeder Aktionssatz oder jeder Bahnsatz kann eine Prioritätsinformation aufweisen, die von der Providerkomponente gesetzt ist und ein Feld von Bahnen, die von der Providerkomponente erzeugt worden ist. Der Aktionssatz kann weiter einen Informationssatz von der Projektorinformation aufweisen, etwa das Vorhandensein und der Ort eines Hindernisses, die die Aktion, die von der Betreiberkomponente gesetzt worden ist, begrenzt. Die Bahnen können einen Geschwindigkeitsbefehl, einen Richtungsbefehl und einen Präferenzwert zwischen 0 und 1 aufweisen, dessen Wert von dem Geschwindigkeitsbefehl und der bekannten Information, die von den Sensoren gewonnen worden ist, beinhalten. Eine Bahn mit einem Präferenzwert von 1,0 kann identifiziert werden als die bevorzugte Aktion, während die Bahnen mit einem Präferenzwert von 1,0 zulässig sein können, jedoch weniger bevorzugte Aktionen sind. Der Antriebsarbiter spielt sodann den Aktionssatz mit der höchsten Priorität aus.
Providerkomponenten
Das robotergesteuerte Fahrzeug kann unter unterschiedlichen Betriebsarten arbeiten. Beispielsweise kann das Fahrzeug in einer „Follow Me" Betriebsart arbeiten, einer fernbedienten Weise, einer lernenden Rückspiel-Betriebsweise oder einer GPS Wegpunktbetriebsweise arbeiten.
Follow Me Betriebsweise: Unter der „Follow Me" Betriebsweise werden ein oder mehrere Gegenstände identifiziert und das robotergesteuerte Fahrzeug wird dazu gesteuert, dem Objekt zu folgen. Die sich bewegende Objektinformation kann verwendet werden zum Erzeugen und Manipulieren des Fahrzeugbewegungsverhaltens. Bei einigen Ausführungsbeispielen der vorliegenden Erfindung kann die Information über das sich bewegende Objekt verwendet werden zum Löschen oder Auslaufenlassen von Datenpunkten, die dem sich bewegenden Objekt zugehörig sind, wenn sie in dem „Heck" sind oder einer vorangehenden Position des Objekts zugehörig sind, um es dem Fahrzeug zu erlauben, sich näher an ein sich bewegendes Objekt zu bewegen, ohne die Datenpunkte zu verbergen, die der vorangehenden Position des Objekts zugehörig sind.
Wie in 8 gezeigt, bestimmt ein System, ob ein Gegenstand als einem zu folgenden Gegenstand (700) identifiziert wird. Wenn kein gesetztes Objekt vorhanden ist, kann das System erkennen (702) und auswählen (704) das nächste Objekt innerhalb der Detektionszone, das definiert werden kann durch einen Bereich, in dem der Laserstrahl die Fähigkeit hat, Objekte zu detektieren und/oder zu identifizieren. Bei einigen Ausführungsbeispielen kann das System die gegenwärtige Position des sich bewegenden Objekts gewinnen und die Position des nahesten Objekts zu einem gegebenen Punkt und Auswählen dem nahesten Objekt zu folgen. Der „Follow Me" Betriebsweisenalgorithmus kann eine Bibliothek von Befehlen verwenden, um eine Bahn zu dem Objekt zu erzeugen und kann Richtungs- und Geschwindigkeitskomponenten einschließen, die nicht eine vorgewählte zusätzliche Maximalgeschwindigkeit überschreiten und eine Richtung beinhalten zum Stoppen mit einem vorgegebenen Abstand von dem Objekt.
Nachdem das Objekt anfänglich ausgewählt oder aber das Fahrzeug bereits dem Objekt folgt, kann die Position des Fahrzeugs relativ zu der vorherigen Position und der Bewegung des Objekts (706) abgeschätzt werden. Zusätzlich wird das Objekt abgeschätzt oder die erwartete Position wird auch berechnet (708). Wenn kein sich bewegendes Objekt in dem abgeschätzten Positionsbereich innerhalb eines vorbestimmten Zeitraums erkannt wird, wird das Fahrzeug nicht länger nach dem sich bewegenden Objekt suchen und wird versuchen, ein anderes sich bewegendes Objekt zu lokalisieren, um diesem unter Verwendung des oben beschriebenen Prozesses (712) zu folgen.
Nach dem Erkennen des sich bewegenden Objekts, wird ein Bahnsatz zum Beliefern des Fahrzeugs mit Bewegungsbefehlen (714) berechnet. Die Bahn kann durch Berechnen von Vektoren in einen Bahnsatz aufgeteilt sein, die durch einen vorgegebenen Winkel getrennt sind (beispielsweise um 5 Winkelgradzeichen nach rechts und nach links der Bahn des sich bewegenden Objekts. Zusätzliche Bahnen können zwischen den Vektoren zum Schaffen von zusätzlichen Bahnen oder Bahnsätzen eingeschlossen sein. Jeder Bahn kann eine Präferenz zugeordnet sein (716). Beispielsweise kann die Bahn, die in der Mitte des Bahnsatzes angeordnet sein, einem Wert zugeordnet sein, der die höchste Präferenz hat, während die Vektoren, die am weitesten von dem Mittelvektor entfernt sind, einen Präferenzwert haben, denen der am wenigsten bevorzugte Vektor zugeordnet ist. Der Bahnsatz wird sodann an die Betriebsarbiterkomponente als ein Aktionssatz geliefert (718). Eine Hinderniskarte kann berechnet werden basierend auf einer Information, die von den Sensoren gewonnen wird, etwa dem vorderen oder dem rückwärtigen Laserstrahl einschließlich dem Vorhandensein und Ort von Hindernissen. Die Hinderniskarte kann geliefert sein an die Betriebsarbiterkomponente an eine Begrenzung der Bahnsätze. Unter der „Follow Me" Betriebsweise können Hindernisvermeidungsinformation, Erkennung oder Antwortverhalten wie hier beschrieben, von dem Robotersteuersystem interpretiert werden, um die Bahnen in dem Bahnsatz zu ändern oder eine Präferenz zwischen den Bahnen zu ändern, um (1) Hindernisse zu vermeiden (2) Bahnen weiter weg von der mittleren Bahn zu bevorzugen, wenn die mittlere Bahn als Hindernisse beinhaltend interpretiert wird, etwa negative Hindernisse einschließlich Löchern oder Neigungsabfällen oder positiven Hindernissen, die eine Struktur oder ein Baum oder das Ausschließen von möglichen zu folgenden Objekten; (3) Ändern oder Verringern der maximalen zulässigen Geschwindigkeit; (4) Ändern oder erhöhen des vorgewählten Bremsweges; und (5) ansonsten das Ändern von Instruktionen, die ausgeführt werden in einer „Follow Me" Betriebsweise, um Hindernissen zu entsprechend.
GPS Wegpunktbetriebsweise: Nach einigen Ausführungsbeispielen der vorliegenden Erfindung wird das Fahrzeug basierend auf einer GPs Wegpunktinformation unter Verwendung eines GPS Bestimmungssystems geleitet. Beispiele eines GPS Bestimmungssystems weist das Navcom SF-2050M auf, das von Navcom Technologies, Torrance, CA erhältlich ist. Beispielsweise wird die GPS Wegpunktinformation kontinuierlich von einer Wegpunktliste upgedated und Bahnsätze werden basierend auf dem nächsten Wegpunkt relativ zu dem gegenwärtigen und/oder dem letzten Wegpunkt entwickelt. Zunächst wird eine gegenwärtiger Wegpunkt entsprechend der Position, an der ein Fahrzeug als angeordnet angenommen wird, berechnet. Eine Headingcontrollerbibliothek erzeugt eine Bahn in Richtung auf die jeweilige Position mit einer Geschwindigkeit und Richtungsinformation, die verhindert, dass das Fahrzeug eine vorgegebene Geschwindigkeit überschreitet, um die gegenwärtige Position zu erreichen. Die Fahrzeugposition wird dann berechnet um zu bestimmen, ob das Fahrzeug innerhalb des Wegpunktradius ist oder ob das Fahrzeug bei der Fahrt eine senkrechte Ebene, die dem bestimmten Wegpunkt zugeordnet ist, passiert hat.
Ein „nächster" Wegpunkt wird dann bestimmt und eine Bahn wird dann berechnet basierend auf dem gegenwärtigen und dem nächsten Wegpunkt. Basierend auf der Bahninformation wird ein Bahnsatz durch Berechnen von Vektoren mit einem vorgegebenen Abstand von, beispielsweise, 5 Grad erzeugt, wobei die Bahn des sich bewegenden Objekts die Bahn in der Mitte des Satzes zugewiesen ist. Zusätzliche Bahnen können zwischen den erzeugten Bahnen und der Bahn, die einem bevorzugten Wert zugewiesen ist, eingeschlossen sein, wobei weniger bevorzugte Werte den Bahnen zugeordnet sind, die weiter weg von der mittleren Bahn sind.
Weiter kann ein Verwendet einen vorgegebenen GPS Pfad aufzeichnen und die Information an ein RCU liefern durch Sichern der Information in einem RCU Flashspeicher. Der Verwender kann sodann ein GPS Pfadplaybacksystem initiieren durch Verwenden der Armatursteuereinheit. Der Verwender kann die GPS Information durch anfängliches Aufzeichnen de GPS Höhen- und Längslesungen aufzeichnen, wobei die GPS Information durch entfernt liegender GPS Information komprimiert wird. Der Wegpunktlistenmanager kann Wegpunkte, die als zu folgen ausgewählt worden sind, in einer Schlange anordnen. Bei manchen Ausführungsbeispielen der vorliegenden Erfindung können die Pfadsegmente zwischen den Wegpunkten bestimmt werden und verwendet werden zum Erzeugen eines gekrümmten Weges, dem das Fahrzeug zu folgen hat. Alternativ wird ein Mittelwegtracker zum Erzeugen eines Pfades verwendet, der für konsistente oder sanfte Fahrzeugbewegungen sorgt. Der Bahnsatz wird sodann an den Antriebsarbiter geliefert, der die geeignete Bahn basierend auf dem Spursatz bestimmen wird und eine Information, die sich auf das Vorhandensein und/oder dem Ort von Hindernissen bezieht. Bei einigen alternativen Ausführungsbeispielen werden die Bahnsätze basierend auf den von einem Kompass gewonne nen Daten erzeugt statt einem GPS System und relativen Orten von Gegenständen Destinationspunkten und/oder vorangehenden Positionsdaten. Beispiele von verwendeten Kompasssystemen weisen einen elektronischen Kompass TCM2-20 auf.
In der „GPS Wegpunkt" Betriebsart können Hindernisvermeidungsinformation, Detektion oder entsprechendes Verhalten wie beschrieben in dem Robotersteuersystem interpretiert werden um: (1) die Bahn in dem Satz, oder Pfad oder Pfadsegmente zu ändern oder Präferenzen zwischen den Bahnen in dem Satz oder Wegpunkten in der Liste zur Vermeidung von Hindernissen zu ändern; (2) Bahnen die weiter entfernt von der mittleren Bahn sind zu bevorzugen, wenn die mittlere Bahn als Hindernisse aufweisen interpretiert wird, etwa negative Hindernisse, einschließlich Löchern oder Neigungsabfällen oder positiven Hindernissen wie eine Struktur oder ein Baum oder für ein Folgen in Betracht kommende Objekte auszuschließen; (3) Ändern oder Verringern der maximalen zulässigen Geschwindigkeit; (4) Ändern der Erhöhung des vorgewählten Bremsabstandes; und (5) ansonsten Ändern von Befehlen, die in der „GPS Wegpunkt" Betriebsart ausgeführt werden unter Berücksichtigung von Hindernissen.
Fernbedienungsbetriebsart: Bei einigen Ausführungsbeispielen der vorliegenden Erfindung wird der Weg des Fahrzeugs durch eine Fernbedienung bestimmt. Ein Empfänger, der mit dem Fahrzeug verbunden ist, ist dazu eingerichtet, Befehle zu empfangen. Beispielsweise kann die Fernbedienungskomponente eine Aufnahme öffnen, etwa durch Erzeugen eines Kommunikationsendpunkts und Rückgeben einer Dateibeschreibung, mit der der Zugriff zu einer Aufnahme, die einer Aufnahmeadresse zugehörig ist, einschließlich einer Anschlussnummer einer Netzwerkadresse eines lokalen Hosts. Befehle werden von einer Verwendersteuerschnittstelle basierend auf Information, die der Verwenderschnittstelle übertragen worden ist, übertragen, d. h., oder diese zugehörig ist, Daten, die von einer Kamera, die an dem Fahrzeug angeordnet ist, werden über ein Kommunikationslink oder Netzwerk übertragen. Beispiele derartiger Radionetzwerke weist die Verwendung eines 2,4 GHz Netgate Funksystems oder ein Novaroam EH900 900 MHz Radiosystem auf. Das Novaroam EH900 900 MHz System kann kombiniert werden mit einem Netgate 802.22b System zum Schaffen einer überlegenen Kommunikation über relativ kurze und lange Entfernungen. Beispiele solcher Kamerasysteme weisen ein 10/100 Base T Fast Internet Konnektion und eine Sony SNC-CS3N Kamera auf.
Das Fernbedienungssystem kann einen Befehl empfangen, der entweder eine Null- oder eine Nicht-Null Geschwindigkeitsinformation aufweist. Wenn der Geschwindigkeitsbefehls Null ist, wird eine Befehlsgeschichte konsultiert um zu bestimmen, ob eine vorgegebene Anzahl von früheren Befehlen auch einen Nullgeschwindigkeitsbefehl beinhalten. Wenn der gegenwärtige Bahnsatz auf irgendwelcher Richtungsinformation beruht, die mit dem jeweiligen Befehl zugehörig ist, wird kein Bahnsatz erzeugt. Wenn das Geschwindigkeitskommando nicht-null ist oder eines oder mehrere der vorangehenden Befehle nicht-null Geschwindigkeitsbefehle beinhaltet haben, wird ein Bahnsatz erzeugt. Ein Bahnsatz wird erzeugt durch Berechnen von Vektoren mit einem vorgegebenen Abstand zwischen diesen, beispielsweise 5 Grad, wobei der Bahn des bewegenden Objekts die Bahn in der Mitte des Satzes zugewiesen ist. Weitere Bahnen können zwischen den erzeugten Bahnen eingeschlossen sein und jeder Bahn ist ein Präferenzwert zugeordnet, wobei weniger präferierte Werte den Bahnen zugeordnet sind, die weit von der Mittelbahn entfernt sind. Der Bahnsatz wird sodann an die Antriebsarbiter geliefert, die die geeignete Bahn basierend auf dem Bahnsatz und der Information, die sich auf das Vorhandensein und/oder den Ort von Hindernissen beziehen. Während der „Fernbedienungs" Betriebsart können die Hindernisvermeidungsinformation, die Detektion und der die Antwortverhalten, wie hier beschrieben, von dem Robotersteuersystem interpretiert werden zum: (1) Ändern der Bahnen in dem Satz oder Ändern von Präferenzen unter den Bahnen in dem Satz zum Vermeiden von Hindernissen; (2) Bevorzugen von Bahnen die weiter von der Mittelbahn entfernt sind, wenn die Mittelbahn als Hindernisse beinhaltend interpretiert wird, etwa negative Hindernisse einschließlich Löchern oder Neigungsabfällen, oder positiven Hindernissen, etwa Strukturen oder Bäumen, oder ein Aufschließen des Folgens von möglichen Objekten; (3) Ändern oder Verringern einer maximal zulässigen Geschwindigkeit; (4) Ändern oder erhöhen des vorgewählten Bremsweges; und (5) anderes Ändern von Befehlen, die in der „Fernbedienung" Betriebsweise ausgeführt worden sind, um Hindernisse zu berücksichtigen.
Teach and Playback Betriebsart: Bei einigen Ausführungsbeispielen der vorliegenden Erfindung kann das Fahrzeug in einer Teach and Playback Betriebsart betrieben werden. Eine Verwenderschnittstelle kann vorgesehen sein als eine Armaturenbrettsteuereinheit, die an dem Fahrzeug angebracht ist oder in einem Fernbetriebssystem eingebracht ist (oder anderen geeigneten Verwenderschnittstellen). Das Teach and Playback System kann an ein Fahrzeug mit einem Befehl zum Aufzeichnen von Bewegungen, Antriebssignalen und anderen sich auf den Pfad beziehenden Informationen liefern, etwa GPS Wegpunkten, Ort von Hindernissen usw., und der aufgezeichneten Information folgen, wenn ein Pfad zurück zu dem Ausgangspunkt gefolgt wird. Beispielsweise wird das Fahrzeug die Geschwindigkeits- und Richtungsinformation speichern und die Information mit besonderen GPS Daten und/oder zeitlichen Informationen korrigieren. Bei einer Rückfahrt ruft das System Daten wieder auf, um das Fahrzeug mit Geschwindigkeits-, Richtungs- oder anderen zugehörigen Informationen zu beliefern, um einem Rückweg zu folgen. Das Fahrzeug kann dazu in der Lage sein, der Playbackbewegungsinformation und Daten entweder vorwärts oder rückwärts folgen. Zusätzlich kann die Datenaufzeichnung wiederholt werden für zusätzliche Fahrten entlang des Pfades. Unter der „Teach and Playback" Betriebsart, der Hindernisvermeidungsinformation, der Erkennung oder die Antwortverläufe, wie sie hier beschrieben worden sind, können von dem Robotersteuersystem interpretiert werden zum: (1) Ändern der Bahn in dem Satz oder Pfaden oder Pfadsegmenten oder Ändern von Präferenzen entlang der Pfade in dem Satz oder Wegpunkten in der Liste zum Vermeiden von Hindernissen; (2) Bevorzugen von Bahnen, die von der Mittelbahn weit entfernt sind, wenn die Mittelbahn als Hindernisse aufweisen interpretiert wird, etwa negative Hindernisse einschließlich Löchern oder geneigten Absenkungen, oder positiven Hindernissen, wie Strukturen oder Bäumen und ein Ausschließen eines möglicherweise zu folgenden Objekts; (3) Ändern einer unteren maximal zulässigen Geschwindigkeit; (4) Ändern oder Erhöhen des vorgewählten Bremsweges; und (5) ein anderes Ändern von Befehlen, die in der „Teach and Playback" Betriebsart ausgeführt worden sind, um Hindernisse zu berücksichtigen.
Hindernisvermeidung
Wie oben erwähnt, wird die Hindernisinformation gewonnen von Sensoren mit, beispielsweise, Laserstrahlen, die manipuliert worden sind in nützliche Information und an das Antriebsarbitersystem geliefert worden sind als „Projektions"-Verläufe, um den Satz von Bahnen zu modifizieren, um schließlich das Fahrzeug zur Vermeidung der erkannten Hindernisse zu steuern. Beispielsweise modifiziert das Hindernisvermeidungssystem die Bahnen und/oder Präferenzbewertungen in einer Weise, die mit einem vorbestimmten Satz von Kriterien konsistent sein kann. Diese Kriterien können sich auf Fahrzeugzonen beziehen, wie in 9 gezeigt, die sich auf Gebiete um das Fahrzeug 8 herum und/oder den Ort der erkannten Hindernisse beziehen. Wie in 9 gezeigt, können diese Zonen einen Körperpfad 802, einen gefährlichen Pfad 804, einen Vorsichtspfad 806 und, abhängig von der Bahn, eine nachlaufende Körperzone 808, eine nachlaufende Gefahrzone 810, eine nachlaufende Vorsichtszone 812 und einen führenden Körper 814, eine Gefahr 816 und einen Vorsichtsnachlauf 818 aufweisen. Die Kriterien können einen Stoppbefehl aufweisen, der an das überwachende RCU gesendet wird, wenn Hindernisse in dem führenden Körper 814 erkannt werden, etwa ein Hindernis 820 oder eine Gefahrenzone wie ein Hindernis 824. Zusätzlich wird geprüft, ob Hindernisse, etwa ein Hindernis 822, in der nachlaufenden Zone 808 oder der nachlaufenden Gefahrenzone 804, etwa ein Hindernis 826, erkannt werden, ein Befehl zum Begrenzen der Fahrzeuggeschwindigkeit auf einen vorgegebenen Wert wird an das RCU ausgesendet und die verfügbaren Bahnen werden begrenzt auf eine vorbestimmte Anzahl, beispielsweise auf einen Gefahrbahnenpräferenzsatz. Zusätzliche Kriterien können für das System vorgesehen sein zum Bestimmen des nahesten Hindernisses in dem Gefahrweg 804, etwa das Hindernis 828 relativ zu den Hindernissen 830 und 832 und zum Begrenzen der Geschwindigkeit auf einen bestimmten Wert, beispielsweise auf weniger als 25% der maximalen Entschleunigungsgeschwindigkeit, Manipulieren des Bahnsat zes auf einen Gefahrpfadpräferenzsatz durch Eliminieren einer vorgegebenen Anzahl von Bahnen und Reduzieren der Bahnpräferenzlevel, die dem Gefahrweg 804 oder nahe dem Gefahrweg 804 zugehörig sind. Weiter wird, wenn Hindernisse in der vorlaufenden Gefahrzone 818 angeordnet sind, etwa ein Hindernis 834, ein Befehl ausgegeben zum Begrenzen der Geschwindigkeit auf einen vorgegebenen Vorsichtsgeschwindigkeitswert. Schließlich wird, wenn Gegenstände in dem Vorsichtsweg 806 erkannt werden, etwa das Hindernis 836, ein Befehl vorgesehen zum Begrenzen der Geschwindigkeit auf einen größeren Wert zwischen der vorgegebenen maximalen Vorsichtsgeschwindigkeit und der minimalen Vorsichtsgeschwindigkeit oder 10% über dem maximalen Sicherheitswert und einem Wert, der der maximalen Sicherheitsgeschwindigkeit zugehörig ist, die Vorsichtsgeschwindigkeit kann skaliert sein durch das Verhältnis des Vorsichtspfadspiels auf die Vorsichtszonenbreite und die Präferenz zwischen der Vorsichtsmaximalpräferenz und der Vorsichtsminimalpräferenz durch das Verhältnis des Spielbereichs zu der Vorsichtszonenbreite. Basierend auf der Hindernisinformation und der Bahn, beispielsweise wie oben diskutiert, wird die gesetzte Bahn von dem Antriebsarbiter manipuliert zum Befehlen des Fahrzeugs, in einer Weise fortzuschreiten, um die Hindernisse zu vermeiden.
Hinderniskartenerzeugung
Das oben beschriebene System bezieht sich auf die Erkennung von Hindernissen, sich bewegenden Objekten und die Entwicklung einer Hinderniskarte. Die Erkennung von Hindernissen kann das Erkennen von Gruppen von Hindernissen einschließen in der Hinderniskarte, die neu sind, Gruppen von Hindernissen, die innerhalb eines zeitlichen Ausschlussintervalls vorliegen und Gruppen von Hindernissen, die kürzlich ausgelaufen sind. Eine Hinderniskarten wird von Datenpunkten und Information entwickelt, die gewonnen worden ist von dem Laserscanner und eine Schnittstelle zum Analysieren möglicher Aktionen durch das Fahrzeug schafft. Die Datenpunkte können zeitlich bestimmt sein zum Beliefern des Detektionssystems mit der Möglichkeit des Klassifizierens von Datenpunkten in neue, gegenwärtige und alte Datenpunkte. Die Hinderniskarte kann weiter eine Information beinhalten wie die seit dem vorangehende Laserstrahl abgetasteten Zeitintervalle zum Erkennen des Vorhandenseins des sich bewegenden Objekten. Wie in 10 gezeigt, werden die sich bewegenden Objekte erkannt durch das Vorhandensein von benachbarten Punkten 900, die von dem Laserscanner gewonnen werden. Jeder Punkt ist zeitlich definiert und in einer Gatterzelle kartiert. Die zeitbestimmten Punkte 900 können werden in alte Punkte 904, gegenwärtige Punkte 906 und neue Punkte 908 eingeteilt. Wie in den 11A–B gezeigt, können die detektierten Punkte 900 auf einem Raster 904 aufgelegt sein, das mit dem Scanfenster 902 korreliert. Die Zellen sind in Untersetze von benachbarten Rasterzellen 906 aufgeteilt. Jede Gruppe von benachbarten besetzten Rasterzellen 906 repräsentieren ein mögliches Objekt. Wenn das mögliche Objekt unterschiedliche neue und alte Punkte beinhaltet, hat sich das mögliche Objekt wahrscheinlich bewegt. Ein Objekt ist wahrscheinlich ortsfest, wenn der alte und der neue Punkt derselbe sind. Jede Gruppe von benachbarten Punkten, die Mitte der neu erkannten benachbarten Gruppe und die ältere erkannte benachbarte Gruppe werden berechnet. Unter Verwendung der Differenzen zwischen den beiden Bitpunkten können, gemeinsam mit der Abtastrate, die Geschwindigkeit des sich bewegenden Objekts, seine Richtung und sein Radius berechnet werden. Das Auswärtssignal dieser Erkennung kann Inhalte von sich bewegenden Objektdaten als auch eine Identifikation, den Mittelpunkt alter Punkte, den Mittelpunkt neuer Punkte, eine Richtung, Geschwindigkeit, Radius und eine Liste von alten Punkten beinhalten. Das sich bewegende Objektverhalten wird verwendet zum Steuern des Fahrzeugs in dem „Follow Me" Betrieb und zum Erlauben der Datenpunkte in dem Gatter auszulaufen durch Erkennen, ob die Punkte dem Ende des sich bewegenden Objekts zugehörig sind (d. h., die vorangehende Position des sich bewegenden Objekts oder Satz von Positionen) und es dem Fahrzeug erlauben, dem sich bewegenden Objekt näher zu folgen.
Die Hinderniskarte nach einem Ausführungsbeispiel der vorliegenden Erfindung erzeugt einen Hindernisreport, der die beste Abschätzung der Hinderniseigenschaften der Hinderniskarte angibt. Für konsistente Hindernisreporte und eine schnelle Bestimmung des nahesten Hindernisses innerhalb eines bestimmten Pfads um das Fahrzeug, wie in 9 gezeigt, kann die Hindernisdichte gewonnen werden in jeder bestimmten Zone um das Fahrzeug. Der Hindernisreport kann daher Hindernisdichten und den Bereich des nahesten Hindernisses in Bezug auf jeden Pfad, der dem Fahrzeug zugeordnet ist, einschließen. Das Hindernisvermeidungssystem wird den Hindernisreport verwenden, um die individuellen Bahnen, die dem Betriebsarbiter vorgeschlagen werden, zu bewerten.
In einigen Ausführungsbeispielen der vorliegenden Erfindung kann ein 2D Sensor, etwa ein vorderer oder hinterer Laserscannermechanismus, als ein 3D Sensor verwendet werden. Die Systemkomponenten integrieren Bereichsdaten, Wickeldaten und Fahrzeuggeschwindigkeitsdaten, um eine Hinderniskarte unter Verwendung von vier Dimensionen von Daten zu erzeugen. Die sich ergebende Karte kann eine genaue Repräsentation eines Hindernisses bei einer relativ hohen Geschwindigkeit sein. Wie in 12 gezeigt, wird eine Hinderniskarte gewonnen durch Aussenden von Laserbereichsdaten 1002, Scannerwinkeldaten 1004, Fahrzeuggeschwindigkeitsdaten 1006, einem Synchronisierungsimpuls 1008 und Hindernisdatenpunkten 1010, die von einer ersten Abtastung des Lasers gewonnen worden sind zu einer Hinderniskarte RCU 1012. Die RCU 1012 versieht die Daten mit der Zeit und erzeugt den Winkel des Lasers, wenn der Laser eine Abtastung durchführt oder den Neigungswinkel. Die mit einer Zeit versehenen Datenpunkte, die Synchronisationsimpulsdaten und der Neigungswinkel werden an den Überwachungs RCU 1014 gesendet, um die Überwachungs RCU mit vier Dimensionen von Daten der Hindernisse zu versorgen, um die Hinderniskarte zu erzeugen.
Ein Ausführungsbeispiel der Verwendung eines 2D Scanners zur Schaffung von 3D Daten schließt einen Laserscanner RCU ein, der Konfigurationsdaten manuell von einem Verwender empfängt über ein Telekommunikationsnetzwerk oder von anderen Komponenten in dem Fahrzeugsteuersystem. Basierend auf der Konfigurationsinformation konfiguriert der Scanner RCU den Betrieb zum Ausgeben von Bereichsdaten 1002 und zum Lesen der Bereichsdaten 1002 und das Versehen mit der Zeit. Ein Neigungsbewegungscontroller liest Konfigurationsdaten, empfängt Befehle zum Steuern der Laserneigung und des Abtastver haltens und manipuliert die Abtastparameter in Übereinstimmung mit den Befehlen. Zusätzlich kann der Neigungsbewegungscontroller einen horizontalen Synchronisierungsimpuls von dem Treiber als eine Unterbrechung erhalten und beachtet die Zeit der letzten Unterbrechung. Eine oder mehrere Neigungsbotschaften können von einer Nickbewegungscontrollerplatine empfangen werden und der Nickbewegungscontroller berechnet den Startzeitpunkt der letzten Abtastung basierend auf einem empirisch bestimmten festen Offset von dem horizontalen Synchronisierungsimpuls. Der Controller verwendet dann die Zeit zum Bestimmen des Zeitpunkts der Elevationsdaten. Diese mit einer Zeitangabe versehenen Elevationsdaten werden sodann an einen 3D Kartengenerator gesendet. Der 3D Kartengenerator kann Konfigurationsdaten lesen, aus dem Treiber abtasten und die Elevationsdaten zeitstempeln. Der 3D Kartengenerator berechnet sodann die Neigung des Nickmechanismus an dem Beginn der letzten Bereichsabtastung basierend auf der sinusförmigen Bewegung des Nickens. Jede Abtastung wird sodann mit der berechneten Neigung bei dem Beginn der Abtastung markiert. Der 3D Kartengenerator erzeugt sodann Bereichsdaten, die versehen sind mit der Elevationsinformation an eine Botschaftsschleife zur Verwendung als eine Überwachungs RCU. Weiter erkennt der 3D Kartengenerator ein Verlust an Synchronisation aufgrund, beispielsweise, Fehlern in dem Eingang/Ausgang und resynchronisiert durch Verwerfen von Daten, bis eine Übereinstimmung zwischen den Zeitangaben erreicht werden kann.
Das Hindernisvermeidungssystem, das in manchen Ausführungsbeispielen der Erfindung vorhanden ist, kann das Wandeln von 3D Hindernisinformation in 2D Daten aufweisen, um bei dem Ausrichten des Fahrzeugs zur Vermeidung von Hindernissen zu unterstützen. Wie in 13A dargestellt, weisen Sensordaten, etwa Daten, die von dem vorderen nickenden Laser und dem rückwärtigen Laser gewonnen worden sind, eine relativ große Zahl von 3D Datenpunkte auf, die ein 3D Objekt 1050 repräsentieren. Wie in 13B gezeigt, sind jedoch nur eine relativ kleine Anzahl von 2D Punkten 1052 über manchen Systemen erforderlich, um das Vorhandensein von Hindernissen geeignet zu kartieren. Ausführungsbeispiele der Erfindung erzeugen eine Hinderniskarte, die die 3D Sensordaten in einen Satz von 2D Punkten wandelt, die Hindernisse oder andere Objekte repräsentieren. Wie in 14 gezeigt, weist die Wandlung von 3D Daten in 2D Daten das Gewinnen von Sensorpunkten ein, die zeitgestempelt sein können und einen 3D Punktsatz beinhalten und die Ausrichtung des Sensors bezüglich des Fahrzeugs (1100). Die zeitgestempelte Geschwindigkeit des Fahrzeugs wird, kontrolliert mit den zeitgestempelten Punkten, zum Erzeugen einer 2D Karte (1102) verwendet. Beispielsweise ist, wie in 15 gezeigt, wenn die Ausrichtung 1152 des Sensors, etwa des Sensors 1154, bekannt ist, die Hindernispunkte 1150 kartiert relativ zu der Ausrichtung 1152 des Sensors und korreliert mit der jeweiligen Zeitangabe. Sodann werden die Daten verglichen mit vorgegebenen Kriterien (1104) und Datenpunkte werden als überflüssig identifiziert, da sie, beispielsweise, „zu weit", „zu hoch", oder „zu tief" sind relativ zu dem Fahrzeug werden erkannt als außerhalb des Kriteriums (1106). Datenpunkte, die „zu tief" sind, schließen Datenpunkte nicht ein, die Löcher, Spalten oder andere Tiefen beinhalten können, die als Hindernisse betrachtet werden müssen. Wenn, beispielsweise, eine Diskontinuität von Datenpunkten in einer Abtastung erkannt wird, wie in den 16 und 17 gezeigt und im Folgenden eingehender diskutiert werden wird, können die Datenabtastungen das Vorhandensein von Löchern oder ähnlichen Hindernissen angeben. Nach dem Vernachlässigen der irrelevanten Datenpunkte, können die Datenpunkte, die in einer 2D Punktwolke korrelieren für einen einzelnen Satz von Datenpunkten (1104) verwendet werden. In 18 dargestellt, werden Punkte der Bereichsdaten 1400, die nach dem Filtern als „zu weit weg", „zu hoch" und „zu tief, aber kein Loch" gekennzeichnet werden, in 2D kartiert 1402.
Die sich ergebende 2D Punktwolke weist Datenpunkte auf mit Positionsinformation in der Form (x, y) und ist der mit einer Zeitangabe versehenen Information zugehörig. Die Punktwolkendatenpunkte werden weiter gefiltert zum Entfernen unnötiger Datenpunkte (1110). Zum Beispiel können nur Datenpunkte innerhalb von 25 Meter vor dem Fahrzeug mit einer Auflösung von 10 Zeichen vorgesehen sein. Das Punktraster kann einen Index eines Punktfeldes repräsentieren (1112). Das Punktfeld hält die Daten an individuellen Punkten, die während einer bestimmten Laserabtastung gewonnen worden sind. Jedes Mal, wenn die Punkte zu dem Raster zugefügt werden, werden Datenpunkte zunächst von dem Raster entfernt. Ähnlich zu dem Raster werden die Punktfelddatenpunkte bei bestimmten Bedingungen gelöscht. Wenn, beispielsweise, der Zeitstempel, der den Daten zugehörig ist, als „zu alt" bestimmt werden, um relevant zu sein, werden die Punktfelddatenpunkte vernachlässigt (1114). Weiter wird, wenn der Abstand von dem bestimmten Punkt zu dem Ursprung des Fahrzeugs außerhalb eines vorbestimmten Bereichs liegt, der Punktfelddatenpunkt vernachlässigt (1116). Schließlich werden die meisten, wenn nicht alle, Datenpunkte basierend auf diesen Kriterien vernachlässigt. Nachfolgend wird das jeweilige Punktfeld, das die Punkte beinhaltet, die aus den vorigen Sensordaten ausgewählt worden sind, in dem Raster verrechnet (1118). Wenn ein Rasterindex bereits einen gespeicherten Punkt hat, werden die Datenpunkte vernachlässigt und der neue Datenpunkt wird in dem bestimmten Indes gespeichert (1120). Wenn das Fahrzeug noch aktiv ist, kann ein anderer Laserabtastdatensatz gewonnen werden und der Vorgang beginnt erneut (1122).
Wie oben erwähnt, zeigen die 16–17 eine Diskontinuität während einer Laserabtastung. In 16 tastet ein Laserscanner 1200 mit einer Laserscannerausrichtung 1202 einen Scanbereich 1204 ab unter Verwendung, beispielsweise eines Laserstrahls. Ein Laserscanner 1200 kann einen Laserstrahl über den Abtastbereich 1204 ausrichten in, beispielsweise, einer halbmond- oder kreisförmigen Form. Die Laserstrahlpunkte 1206, die einen Bereich repräsentieren, in dem der Laserstrahl erkannt worden ist, sind, beispielsweise, im Wesentlichen halbkreisförmig ausgerichtet. Der Laserabtaster 1200 kann eine Diskontinuität 1208 der Laserstrahldatenpunkte unter Verwendung einer Abtastung erkennen. Die Diskontinuität 1208 kann durch eine Abnahme des Scanabtastbereichs 1205 oder als ein Loch in dem Abtastbereich 1204 gebildet sein.
17 zeigt Diskontinuität 1300 unter Verwendung einer Vielzahl von Laserstrahldatenpunkten die erkannt worden sind. Die Datenpunkte können gewonnen werden durch Vektorstrahlen 1302, einen halbmondförmigen oder halbkreisförmigen Laserstrahlabtastung 1304 oder durch Erkennen von zwei Datenpunkten 1306 mit unterschiedlichen Muster oder erwarteten Eigenschaften wie anderen Datenpunkten. Die Diskontinuität 1300 kann dann zum Begrenzen oder einem sonstigen Bestimmen der Fahrzeugaktion verwendet werden.
Allgemeines
Die vorangehende Beschreibung des Ausführungsbeispiels einschließlich bevorzugter Ausführungsbeispiele, der Erfindung wurde lediglich zum Zweck der Illustration und der Beschreibung präsentiert und soll nicht als die Erfindung einschränken oder begrenzend verstanden werden, auf die hier offenbarten diskreten Ausbildungen. Verschiedene Modifikationen und Adaptionen ergeben sich dem Fachmann, ohne sich von dem Grundgedanken oder Schutzbereich dieser Erfindung zu lösen.
ZUSAMMENFASSUNG
Ausführungsbeispiele der Erfindung schaffen Systeme und Verfahren zur Hindernisvermeidung. Bei einigen Ausführungsbeispielen wird ein robotergesteuertes Fahrzeug geschaffen, das dazu in der Lage ist, in einen oder mehreren Betriebsarten zu arbeiten. Beispiele derartiger Betriebsarten weisen Fernbedienung, Wegpunktnavigation, Folgen und einen manuellen Betrieb auf. Das Fahrzeug kann ein Hinderniserkennungs- und -vermeidungssystem beinhalten, das dazu in der Lage ist, mit einem oder mehreren der Fahrzeugbetriebsarten implementiert zu werden. Ein Steuersystem kann zum Betreiben und Steuern des Fahrzeugs in der einen oder den mehreren Betriebsarten vorgesehen sein. Das Steuersystem kann eine Robotersteuereinheit und eine Fahrzeugsteuereinheit aufweisen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

- US 60/729445 [0001]
- US 60/729388 [0001]
- US 60/780389 [0001]
- US 60/838704 [0001]

Zitierte Nicht-Patentliteratur

- www.deere.com [0086]

Claims

Ein robotergesteuertes Fahrzeug mit: einer Robotersteuereinheit mit einer Steueranwendung; einem Sensor zum Erkennen von Objektdaten, die erkannte Hindernisse oder Objekte repräsentieren, die außerhalb des Roboterfahrzeugs erkannt worden sind, und zum Übertragen der Objektdaten an die Robotersteuereinheit; wobei die Robotersteuereinheit eine Karte basierend auf den Objektdaten erzeugt, die Karte Kartierungsdaten aufweist und die Kartierungsdaten Positionsdaten der erkannten Hindernisse oder Objekte aufweist; und wobei die Steueranwendungseinheit basierend wenigstens teilweise auf den Kartierungsdaten Fahrzeugaktionen bestimmt und einen Steuerbefehl an eine Fahrzeugsteuereinheit ausgibt, der die Fahrzeugaktionen repräsentiert.
Das robotergesteuerte Fahrzeug nach Anspruch 1, wobei die Fahrzeugaktionen wenigstens die Geschwindigkeit des Fahrzeugs oder die Richtung des Fahrzeugs beinhalten.
Das robotergesteuerte Fahrzeug nach Anspruch 1, wobei der Sensor ein Laserscanner ist.
Das robotergesteuerte Fahrzeug nach Anspruch 1, wobei die Robotersteuereinheit einen Prozessor und einen Speicher mit einem ausführbaren Code aufweist, wobei der ausführbare Code einen Betriebsarbiter beinhaltet, der zweidimensionale Kartierungsdaten und Fahrzeugbestimmungsdaten empfängt und einen Satz von Fahrzeugaktionen basierend wenigstens teilweise auf Kartierungsdaten und den Fahrzeugbestimmungsdaten erzeugt.
Das robotergesteuerte Fahrzeug nach Anspruch 4, wobei der Satz von Fahrzeugaktionen Providerkomponenten aufweist, die Fahrzeugaktionen und Projektorkomponenten erzeugen, die die Fahrzeugaktionen begrenzen.
Das robotergesteuerte Fahrzeug nach Anspruch 1, wobei die Providerkomponenten wenigstens eine Fernbedienungskomponente, eine „Follow Me"-Betriebsartinformation, Odometerwegpunkte und GPS-Wegpunkte beinhalten, und wobei die Projektorkomponenten Kartierungsdaten aufweisen.
Das robotergesteuerte Fahrzeug nach Anspruch 1, weiter mit einer Fahrzeugsteuereinheit, die Fahrzeugaktionen von der Robotersteuereinheit empfängt und Steuersignale an einen Fahrzeugaktuator ausgibt.
Das robotergesteuerte Fahrzeug nach Anspruch 1, wobei die Robotersteuereinheit Steuersignale an einen Fahrzeugaktuator ausgibt.
Das robotergesteuerte Fahrzeug nach Anspruch 1, wobei die Objektdaten dreidimensionale Daten sind und die Kartierungsdaten zweidimensionale Daten sind.
Das robotergesteuerte Fahrzeug nach Anspruch 1, wobei der Sensor eine Laserscanneranordnung ist, die angepasst ist zum Verbinden mit einem Roboterfahrzeug, wobei die Laserscanneranordnung aufweist: einen Laserscanner zum Aussenden eines Laserstrahls zum Erkennen des Vorhandenseins eines Hindernisses; einen Scannermechanismus zum Manipulieren der Position des Laserscanners; und einen Schutz zum Schützen des Laserscanners vor einer Beschädigung und zum Ermöglichen eines Erkennens des Vorhandenseins eines Hindernisses durch den Laserstrahl, wobei der Schutz aufweist: eine Basis zum Verbinden der Laserscanneranordnung mit dem Roboterfahrzeug; wenigstens zwei Stützelemente, die mit der Basis verbunden sind; und eine Mehrzahl von Stützrippen, die mit den wenigstens zwei Stützelementen verbunden sind.
Das robotergesteuerte Fahrzeug nach Anspruch 10, wobei die Mehrzahl von Stützrippen außerhalb eines Winkelfensters des Laserstrahls positioniert ist.
Das robotergesteuerte Fahrzeug nach Anspruch 10, wobei die Mehrzahl von Stützrippen einen ersten Querschnittsbereich und einen zweiten Querschnittsbereich haben, der größer als der erste Querschnittsbereich ist; und wobei die Mehrzahl von Stützrippen derart positioniert ist, dass der erste Querschnittsbereich aus der Mehrzahl von Stützrippen ein Winkelfenster des Laserstrahls ist.
Ein Verfahren zum Veranlassen eines Roboterfahrzeugs, einem Objekt zu folgen, wobei das Verfahren aufweist: Identifizieren eines Objekts, dem das Roboterfahrzeug zu folgen hat; Abschätzen einer Roboterfahrzeugposition relativ zu einer vorgegebenen Position und einer Bewegung des Objekts; Abschätzen einer Bereichsposition des Objekts; Empfangen einer Position des Objekts; Bestimmen, ob das Objekt in der abgeschätzten Bereichsposition ist; Berechnen eines Bahnsatzes basierend teilweise auf der Objektposition, wobei der Bahnsatz eine Mehrzahl von Bahnen aufweist; Zuordnen eines Präferenzwerts zu jeder der Bahnen; und Schaffen eines Bahnsatzes für den Betriebsarbiter.
Das Verfahren nach Anspruch 13, wobei das Identifizieren eines Objekts, dem das Roboterfahrzeug zu folgen hat, aufweist: Empfangen einer Identifikation eines zu folgenden Objekts, wobei die Identifikation den Objektort beinhaltet, und Erkennen des zu folgenden Objekts.
Das Verfahren nach Anspruch 13, wobei das Identifizieren eines Objekts, dem das Roboterfahrzeug zu folgen hat, aufweist: Empfangen von Daten von einem Laserscanner, wobei die Daten eine Identifikation einer Mehrzahl von Objekten innerhalb einer Detektionszone aufweisen; und Auswählen des nahesten identifizierten Objekts als zu folgendem Objekt.
Das Verfahren nach Anspruch 13, wobei der Bahnsatz eine Bahn aufweist mit einem Mittelvektor und einer Mehrzahl von Bahnen, die einen Bahnvektor haben, wobei der Mittelvektor und der Bahnvektor für jede Bahn voneinander um einen vorgegebenen Winkel beabstandet sind.
Das Verfahren nach Anspruch 16, wobei das Zuordnen eines Präferenzwerts für jede der Bahnen aufweist: Zuordnen eines bevorzugten Werts für die Bahn, die den Mittelvektor hat; und Zuordnen wenigstens eines bevorzugten Werts für die Bahn, die den Bahnvektor hat, der am weitesten von dem Mittelvektor entfernt ist.
Das Verfahren nach Anspruch 13, weiter mit: Empfangen von Hindernisdaten, wobei die Hindernisdaten den Ort der Hindernisse beinhalten; Liefern der Hindernisdaten an den Betriebsarbiter; und Auswählen einer Bahn basierend wenigstens teilweise auf den Hindernisdaten.
Ein Verfahren zum Steuern eines Robotersteuerfahrzeugs unter Verwendung einer Hinderniskarte, mit: Gewinnen einer Mehrzahl von Punkten, wobei jeder Punkt wenigstens einen Teil eines Hindernisses und eine Position des Hindernisses zu einem bestimmten Zeitpunkt repräsentiert; Zuordnen einer Zeitangabe zu jedem Punkt; Kartieren der Punkte zu einer Zelle, wobei die Zelle in Raster partitioniert ist; Separieren der Mehrzahl von Punkten in alte, gegenwärtige und neue Punkte basierend wenigstens teilweise auf den zugehörigen Zeitangaben; Bestimmen der Mitte wenigstens eines der alten Punkte und der gegenwärtigen Punkte; Bestimmen der Mitte der neuen Punkte; Gewinnen einer Positionsdifferenz zwischen der Mitte der neuen Punkte und der Mitte der wenigstens einen der alten Punkte und der gegenwärtigen Punkte; Bestimmen einer Geschwindigkeit eines Objekts basierend wenigstens teilweise auf der Positionsdifferenz; und Verwenden der Objektgeschwindigkeit zum Steuern des Roboterfahrzeugs.
Das Verfahren nach Anspruch 19, weiter mit: Empfangen einer Abtastrate, die dem Gewinnen der Mehrzahl von Punkten zugehörig ist; Bestimmen der Richtung und des Radius des Objekts basierend wenigstens teilweise auf der Positionsdifferenz und der Abtastrate; und Verwenden der Richtung und des Radius zum Steuern des Roboterfahrzeugs.
Das Verfahren nach Anspruch 19, weiter mit: Erzeugen eines Bahnsatzes, der eine Mehrzahl von Bahnen beinhaltet, wobei jede Bahn Befehle für die Roboterfahrzeugbewegung aufweist; Erzeugen eines Hindernisberichts mit Hinderniseigenschaften, wobei der Hindernisbericht eine Dichte der Objekte, die einem Roboterfahrzeugzeug zugehörig sind, umfasst; und Verwenden des Hindernisberichts zum Zuordnen einer Präferenz zu jeder Bahn.
Ein Verfahren zum Erzeugen einer dreidimensionalen Hinderniskarte zur Verwendung in einem Robotersteuerfahrzeug, mit: Verwenden eines Laserscanners zum Ausführen einer ersten Abtastung eines Abtastbereichs; Gewinnen von zweidimensionalen Hindernisdatenpunkten, die Hindernisse repräsentieren, die in dem Abtastbereich angeordnet sind; Zuordnen von Abtastdaten zu den Hindernisdatenpunkten, wobei die Abtastdaten wenigstens Abtastbereichsdaten, die den Abtastbereich repräsentieren, Scannerwinkeldaten, die den Winkel des Laserscanners repräsentieren, Fahrzeuggeschwindigkeitsdaten oder einen Laserscannersychronisationsimpuls beinhalten; Senden der Abtastdaten- und Hindernisdatenpunkte an eine Robotersteuereinheit; Versehen der Abtastdatenpunkte mit Zeitangaben; und Erzeugen einer dreidimensionalen Hinderniskarte basierend wenigstens teilweise auf den mit einer Zeitangabe versehenen Hindernisdatenpunkten und Abtastdaten.
Das Verfahren nach Anspruch 22, wobei das Aussenden der Abtastdaten und der Hindernisdatenpunkte an eine Robotersteuereinheit das Aussenden von Abtastdaten und Hindernisdatenpunkten an eine Hinderniskarte-Robotersteuereinheit aufweist; und wobei die Hinderniskarte-Robotersteuereinheit die Hindernisdatenpunkte mit Zeitangaben versieht.
Das Verfahren nach Anspruch 23, weiter mit: Schaffen einer Überwachungs-Robotersteuereinheit zum Erzeugen der Hinderniskarte.
Das Verfahren nach Anspruch 22, wobei die Hinderniskarte verwendet wird zum Steuern des robotergesteuerten Fahrzeugs.
Ein Verfahren zum Wandeln dreidimensionaler Hindernisdaten in zweidimensionale Hindernisdaten zum Steuern eines Roboterfahrzeugs, mit: Gewinnen einer Mehrzahl von dreidimensionalen mit Zeitangaben versehenen Hindernisdaten von einem Laserscanner, wobei die Hindernisdaten den Ort eines Hindernisses repräsentieren; Empfangen von mit einer Zeitangabe versehenen Geschwindigkeitsdaten des Roboterfahrzeugs; Vergleichen der Hindernisdaten zum Vorbestimmen von Kriterien zum Trennen der Hindernisdaten in relevante Hindernisdaten und irrelevante Hindernisdaten, wobei die irrelevanten Hindernisdaten außerhalb der vorbestimmten Kriterien liegen; Vernachlässigen der irrelevanten Hindernisdaten; Korrelieren der relevanten Hindernisdaten mit einer zweidimensionalen Punktwolke, die einen Index von Punktfeldern repräsentiert; und Erzeugen einer zweidimensionalen Hinderniskarte basierend wenigstens teilweise auf dem Punktfeld.
Das Verfahren nach Anspruch 26, weiter mit: Vernachlässigen von Hindernisdaten mit Zeitangaben, die älter sind als ein vorgegebener Schwellenwert.
Das Verfahren nach Anspruch 26, weiter mit: Filtern der Punktwolke zum Entfernen relevanter Hindernisdaten mit einer Position jenseits einer vorgegebenen Entfernung von dem robotergesteuerten Fahrzeug; und Überschreiben von Hinderniskartendaten mit einer Zeitangabe, die außerhalb eines vorgegebenen Schwellenwerts ist mit zusätzlichen Hinderniskartendaten.
Ein Roboterfahrzeug mit: einer vorderen Sensoranordnung zum Ausführen einer Abtastung des vorne gelegenen Bereichs zum Gewinnen von vorderen Daten, die Hindernisse oder Objekte repräsentieren, die wenigstens vor dem Fahrzeug liegen; einer hinteren Sensoranordnung zum Ausführen einer rückwärtigen Bereichsabtastung zum Gewinnen von rückwärtigen Daten, die Hindernisse oder Objekte, die wenigstens teilweise hinter dem Fahrzeug liegen, repräsentieren; und einer Robotersteuereinheit zum Empfangen der vorderen und rückwärtigen Daten und Erzeugen einer Hinderniskarte basierend auf vorderen und rückwärtigen Daten, wobei die Robotersteuereinheit aufweist: die Hinderniskarte; eine Bereichsschutzanwendung zum Erkennen von Unterbrechungen in den vorderen und rückwärtigen Daten und Ersetzen, basierend wenigstens teilweise auf den Unterbrechungen, von Daten, die das Vorhandensein von Hindernissen in dem vorderen und rückwärtigen Abtastbereich angeben; und eine Steueranwendung zum Bestimmen einer Bahn basierend wenigstens teilweise auf der Hinderniskarte und Ausgeben von Steuerbefehlen an eine Fahrzeugsteuereinheit basierend wenigstens teilweise auf der Bahn.
Das Roboterfahrzeug nach Anspruch 29, wobei die vordere Sensoranordnung wenigstens einen Scanner aufweist.
Das Roboterfahrzeug nach Anspruch 29, wobei die rückwärtige Sensoranordnung einen Laserscanner aufweist.
Das Roboterfahrzeug nach Anspruch 29, wobei das Roboterfahrzeug angepasst ist zum Betrieb in einer Betriebsart, wobei die Betriebsart wenigstens einen GPS-Wegpunkt, eine Fernbedienung, ein „Follow Me" und ein teach und playback aufweist.
Das Roboterfahrzeug nach Anspruch 32, wobei die Robotersteuereinheit eingerichtet ist zum Ändern einer robotergesteuerten Fahrzeuggeschwindigkeit und -richtung, wie sie angegeben ist durch die Betriebsart basierend auf der Hinderniskarte.