DE112011104644T5

DE112011104644T5 - Mobiles Roboter-System

Info

Publication number: DE112011104644T5
Application number: DE112011104644T
Authority: DE
Inventors: Robert Todd Pack; Timothy S. Farlow; Chikyung Won; Michael T. Rosenstein; Michael Halloran; Steven V. Shamlian; Mark Chiappetta
Original assignee: iRobot Corp
Current assignee: iRobot Corp
Priority date: 2010-12-30
Filing date: 2011-11-16
Publication date: 2013-10-10
Also published as: JP2014209381A; GB2519433A; EP2659321B1; JP2014505934A; GB2501209A; JP5629390B2; GB2501209B; US20150158182A1; CA2822980A1; US9902069B2; US9014848B2; EP2769809A1; JP6039611B2; GB201416267D0; AU2011353004A1; EP2659321A2; AU2011353004B2; US20110288684A1; JP2014197411A; GB2519433B

Abstract

Ein Robotersystem (1600) umfasst einen mobilen Roboter (100) mit einem Kontrollschaltkreis (500), der ein Kontrollsystem (510) ausführt, um damit den Betrieb des Roboters zu steuern, ein Cloudcomputing (1620) in Kommunikation mit dem Kontrollschaltkreis des Roboters und ein Fernrechengerät (310) in Kommunikation mit dem Cloudcomputing. Das Fernrechengerät kommuniziert mit dem Roboter über das Cloudcomputing.

Description

KREUZVERWEISE ZU VERWANDTEN ANMELDUNGEN
Diese US-Patentanmeldung beansprucht Priorität gemäß 35 U. S. C. §119(e) gegenüber der vorläufigen US-Anmeldung 61/428,717, eingereicht am 30. Dezember 2010, der vorläufigen US-Anmeldung 61/428,734, eingereicht am 30. Dezember 2010; der vorläufigen US-Anmeldung 61/428,759, eingereicht am 30. Dezember 2010 und der vorläufigen US-Anmeldung 61/429,863, eingereicht am 5. Januar 2011. Die Offenbarungen der früheren Anmeldungen werden als Teil der Offenbarung dieser Anmeldung erachtet und werden hiermit in ihrer Gesamtheit durch Verweisung mit einbezogen.
TECHNISCHES GEBIET
Diese Offenbarung bezieht sich auf mobile Robotersysteme, die Cloudcomputing einbeziehen.
HINTERGRUND
Ein Roboter ist allgemein eine elektromechanische Maschine, die von einem Computer oder durch elektronisches Programmieren geführt wird. Mobile Roboter besitzen die Fähigkeit, sich in ihrer Umgebung zu bewegen und nicht auf einen physikalischen Standort fixiert zu sein. Ein Beispiel für einen mobilen Roboter, der heute allgemein verwendet wird, stellt das fahrerlose Transportsystem (FTS) dar. Ein FTS ist im Allgemeinen ein mobiler Roboter, der Markierungen oder Drähten im Boden folgt, oder für die Navigation ein Visionssystem oder einen Laser verwendet. Mobile Roboter werden in industriellen, militärischen und sicherheitsrelevanten Umgebungen verwendet. Sie erscheinen auch als Konsumartikel zur Unterhaltung oder für die Erfüllung bestimmter Aufgaben, wie Staubsaugen oder zur Hilfe bei Hausarbeiten.
ZUSAMMENFASSUNG
Ein Aspekt der Offenbarung bietet ein Robotersystem, das einen mobilen Roboter umfasst, der einen Kontrollschaltkreis aufweist, der ein Kontrollsystem zur Steuerung des Betriebs des Roboters ausführt, ein Cloudcomputing in Kommunikation mit dem Kontrollschaltkreis des Roboters und ein Fernrechengerät in Kommunikation mit dem Cloudcomputing. Das Fernrechengerät kommuniziert mit dem Roboter über das Cloudcomputing.
Implementierungen der Offenbarung können ein oder mehrere der folgenden Funktionen umfassen. Bei manchen Implementierungen führt das Fernrechengerät eine Applikation aus, um damit eine Layoutlandkarte der Betriebsumgebung eines Roboters herzustellen. Das Fernrechengerät kann die Layoutlandkarte auf einem externen Cloud-Speicher unter Verwendung des Cloudcomputing speichern. Bei einigen Beispielen greift der Kontrollschaltkreis des Roboters über das Cloudcomputing zu auf die Layoutlandkarte, um Fahrbefehle an ein Fahrsystem des Roboters zu geben.
Das Fernrechengerät kann eine Applikation ausführen (z. B. ein Softwareprogramm oder eine Softwareroutine), um eine Teleoperation des Roboters auf Distanz herbeizuführen. Beispielsweise kann eine Applikation Steuerungen zur Verfügung stellen, wobei mindestens eine für den Antrieb des Roboters, für die Veränderung einer Pose des Roboters, für das Ansehen eines Videos von der Kamera des Roboters und für den Betrieb der Kamera des Roboters (z. B. Bewegen der Kamera und/oder Aufnahme von Schnappschüssen oder Fotographien mit der Kamera) dient.
Bei manchen Implementierungen führt das Fernrechengerät eine Applikation aus, die eine Videokonferenz zwischen einem Benutzer des Computergeräts und einem innerhalb dem Blickfeld der Kamera des Roboters befindlichen Dritten ermöglicht. Das Fernrechengerät kann ein Applikation für die Zeitplanung der Nutzung des Roboters ausführen. Des Weiteren kann das Fernrechengerät eine Applikation für die Überwachung der Nutzung und des Betriebs des Roboters ausführen. Das Fernrechengerät kann aus einem Tablet-Computer bestehen, der wahlweise einen Touchscreen aufweist.
Bei einem weiteren Aspekt der Offenbarung wird ein Robotersystem bereitgestellt, das einen mobilen Roboter umfasst, der einen Kontrollschaltkreis zur Ausführung eines Kontrollsystems zur Steuerung des Betriebs des Roboters, ein Computergerät, das in Kommunikation mit dem Kontrollschaltkreis ist, ein Cloudcomputing, das in Kommunikation mit dem Computergerät ist und ein Portal, das in Kommunikation mit dem Cloudcomputing ist, umfasst.
Implementierungen der Offenbarung können eine oder mehrere der folgenden Funktionen umfassen. Bei manchen Implementierungen umfasst das Portal ein webbasiertes Portal, das Zugriff auf Inhalte ermöglicht. Das Portal kann über das Cloudcomputing Roboterinformationen vom Roboter empfangen. Des Weiteren kann der Roboter über das Cloudcomputing Benutzerinformationen vom Portal empfangen.
Bei manchen Beispielen umfasst das Computergerät ein Touchscreen (wie das von einem Tablet-Computer). Das Computergerät kann ein Betriebssystem ausführen, das sich von dem Betriebssystem des Kontrollschaltkreises unterscheidet. Beispielsweise kann der Kontrollschaltkreis ein Betriebssystem für den Betrieb der Robotersteuerung ausführen, während das Computergerät ein Betriebssystem für ein Unternehmen ausführt. Bei manchen Beispielen führt das Computergerät mindestens eine Applikation aus, die Roboterinformationen vom Roboter sammelt und die Roboterinformationen zum Cloudcomputing sendet.
Der Roboter kann eine Basis umfassen, die eine vertikale Zentralachse definiert und den Kontrollschaltkreis sowie ein holonomes Fahrsystem trägt, das von der Basis getragen wird. Das Fahrsystem weist ein erstes, zweites und drittes Rad auf, die trilateral über die vertikale Zentralachse verteilt sind und jedes davon eine Laufrichtung aufweist, die senkrecht zur Radialachse in Bezug auf die vertikale Zentralachse verläuft. Sie können auch ein ausziehbares Bein, das sich von der Basis nach oben erstreckt und einen Körper, der vom Bein getragen wird, umfassen. Die Stellbewegung des Beins kann eine Änderung der Erhebung des Körpers verursachen. Das Computergerät kann abmontierbar oberhalb des Körpers befestigt sein. Bei manchen Beispielen umfasst der Roboter einen Hals, der vom Körper getragen wird und einen Kopf, der vom Hals getragen wird. Der Hals kann in der Lage sein, den Kopf in Bezug auf den Körper zu schwenken und zu neigen. Der Kopf kann abmontierbar das Computergerät tragen.
Ein weiterer Aspekt der Offenbarung sieht ein Robotersystem vor, das einen mobilen Roboter umfasst, der einen Kontrollschaltkreis umfasst, der ein Kontrollsystem zur Steuerung des Roboters, ein Computergerät in Kommunikation mit dem Kontrollschaltkreis, ein vermittelndes Sicherheitsgerät, das die Kommunikationen zwischen dem Kontrollschaltkreis und dem Computergerät steuert, ein Cloudcomputing in Kommunikation mit dem Computergerät, und ein Portal in Kommunikation mit dem Cloudcomputing umfasst.
Bei manchen Beispielen konvertiert das vermittelnde Sicherheitsgerät Kommunikationen zwischen einem Kommunikationsprotokoll eines Computergeräts und einem Kommunikationsprotokoll eines Roboters. Des Weiteren kann das vermittelnde Sicherheitsgerät ein Autorisierungschip für die Autorisierung des Kommunikationsverkehrs zwischen dem Computergerät und dem Roboter enthalten.
Das Computergerät kann drahtlos mit dem Roboterkontrollschaltkreis kommunizieren. Bei manchen Beispielen ist das Computergerät entfernbar an dem Roboter befestigt. Zu einem beispielhaften Computergerät gehört ein Tablet-Computer.
Das Portal kann ein webbasiertes Portal sein, das einen Zugriff auf Inhalte (z. B. Nachrichten, Wetter, Roboterinformationen, Benutzerinformationen etc.) ermöglicht. Bei manchen Beispielen empfängt das Portal über das Cloudcomputing Roboterinformationen vom Roboter. Bei weiteren Beispielen empfängt der Roboter über das Cloudcomputing Benutzerinformationen vom Portal. Das Computergerät kann mittels Cloudcomputing auf einen Cloudspeicher zugreifen. Das Computergerät kann mindestens eine Applikation ausführen, die Roboterinformationen vom Roboter sammelt und die Roboterinformationen zum Cloudcomputing sendet.
Ein Aspekt der Offenbarung stellt ein Verfahren zum Betrieb des mobilen Roboters vor, das ein Empfangen einer Layoutlandkarte in Einklang mit der Umwelt des Roboters beinhaltet, wobei der Roboter in der Umwelt zu einem Layoutlandkartenstandort auf der Layoutlandkarte bewegt wird, ein Aufzeichnen eines Roboterlandkartenstandortes auf einer Roboterlandkarte, das der Umwelt entspricht und vom Roboter produziert wurde, ein Bestimmen einer Verzerrung zwischen der Roboterlandkarte und der Layoutlandkarte unter Verwendung der aufgezeichneten Roboterlandkartenstandorte und der entsprechenden Layoutlandkartenstandorte und Anwenden der festgestellten Verzerrung auf einen Ziellayoutlandkartenstandort, um einen entsprechenden Zielroboterlandkartenstandort zu bestimmen, umfasst.
Zu Implementierungen der Offenbarung können auch eine oder mehrere der folgenden Eigenschaften gehören. Bei manchen Implementierungen umfasst das Verfahren ein Empfangen der Layoutlandkarte vom Cloudcomputing. Das Verfahren kann auch ein Produzieren der Layoutlandkarte auf einer Applikation, die auf einem Fernrechengerät ausgeführt wird und Speichern der Layoutlandkarte auf einem entfernten Cloudspeicher unter Verwendung von Cloudcomputing umfassen.
Bei manchen Beispielen umfasst das Verfahren ein Bestimmen einer Skalierungsgröße, Ursprungsabbildung und Rotation zwischen der Layoutlandkarte und der Roboterlandkarte unter Verwendung von bestehenden Layoutlandkartenstandorten und aufgezeichneten Roboterlandkartenstandorten und ein Klären eines Roboterlandkartenstandortes entsprechend des Ziellayoutlandkartenstandorts. Das Verfahren kann auch ein Anwenden einer affinen Transformation auf die bestimmte Skalierungsgröße, Ursprungsabbildung und Rotation umfassen, um den Zielroboterlandkartenstandort zu klären.
Bei manchen Implementierungen umfasst das Verfahren ein Bestimmen einer Triangulation zwischen Layoutlandkartenstandorten, die an den Ziellayoutlandkartenstandorten anliegen. Das Verfahren umfasst weiter ein Bestimmen eines Maßstabes, einer Rotation, einer Verschiebung und eines Bitversatzes zwischen dem Dreieck, das in der Layoutlandkarte dargestellt ist und einem entsprechenden Dreieck, das aus der Roboterlandkarte stammt und Anwenden des bestimmten Maßstabes, der Rotation, der Verschiebung und des Bitversatzes auf die Ziellayoutlandkartenstandort, um einen entsprechenden Roboterlandkartenpunkt zu bestimmen.
Das Verfahren umfasst bei manchen Beispielen ein Bestimmen der Entfernungen zwischen allen Layoutlandkartenstandorten und dem Ziellayoutlandkartenstandort, ein Bestimmen eines Schwerpunktes der Layoutlandkartenstandorte, Bestimmen eines Schwerpunktes von allen aufgezeichneten Roboterlandkartenstandorten und für jeden Layoutlandkartenstandort ein Bestimmen einer Rotation und Längenskalierung, um einen Vektor, der vom Layoutlandkartenschwerpunkt zum Ziellayoutstandort verläuft, in einen Vektor zu transformieren, der vom Roboterlandkartenschwerpunkt zu einem Zielroboterlandkartenstandort verläuft.
Das Verfahren kann auch ein Produzieren der Roboterlandkarte unter Verwendung eines Sensorsystems des Roboters umfassen. Bei manchen Implementierungen umfasst das Verfahren ein Ausstrahlen von Licht auf eine Szenerie der Umwelt, Empfangen von Reflektionen des ausgestrahlten Lichts von Oberflächen der Szenerie, Bestimmen der Entfernung von jeder reflektieren Oberfläche und Konstruieren einer dreidimensionalen Tiefenlandkarte der Szenerie. Das Verfahren kann ein Ausstrahlen eines Specklemusters von Licht auf die Szenerie und Empfangen der Reflektionen des Specklemusters von der Szenerie. Bei einigen Beispielen umfasst das Verfahren ein Speichern der Bezugsbilder von dem Specklemuster, wie es von dem Bezugsobjekt in der Szenerie reflektiert wird, wobei die Bezugsbilder bei unterschiedlichen Abständen vom Bezugsobjekt aufgenommen werden. Das Verfahren kann weiter ein Aufnehmen von mindestens einem Zielbild vom Specklemuster umfassen, wie es von einem Zielobjekt in der Szenerie reflektiert wird und ein Vergleichen des mindestens einen Zielbildes mit den Bezugsbildern zum Bestimmen eines Abstands von den reflektierenden Oberflächen des Zielobjekts. Bei manchen Beispielen umfasst das Verfahren ein Bestimmen eines primären Specklemusters auf dem Zielobjekt und ein Berechnen von mindestens einer entsprechenden Kreuzkorrelation und einer Dekorrelation zwischen dem primären Specklemuster und den Specklemustern von Bezugsbildern. Das Verfahren kann auch ein Manövrieren des Roboters in Bezug auf das Zielobjekt auf der Basis der festgestellten Entfernungen der reflektierenden Oberflächen des Zielobjekts umfassen.
Bei manchen Implementierungen umfasst das Verfahren ein Bestimmen der Laufzeit zwischen dem Ausstrahlen des Lichts und Empfangen des reflektierten Lichts und Bestimmen einer Entfernung zu den reflektierenden Oberflächen der Szenerie. Das Verfahren kann auch ein Ausstrahlen von Licht auf die Szenerie in unterbrochenen Pulsen umfassen. Des Weiteren kann das Verfahren ein Verändern der Frequenz der ausgestrahlten Lichtpulse umfassen.
Bei einem weiteren Aspekt umfasst das Robotersystem einen mobilen Roboter, der einen Kontrollschaltkreis aufweist, der ein Kontrollsystem für die Steuerung des Betriebs des Roboters ausführt sowie ein Sensorsystem in Kommunikation mit dem Kontrollschaltkreis. Das Robotersystem umfasst auch ein Cloudcomputing in Kommunikation mit dem Kontrollschaltkreis des Roboters. Das Cloudcomputing empfängt Daten vom Kontrollschaltkreis, verarbeitet die Daten und gibt die verarbeitete Resultante an den Kontrollschaltkreis zurück.
Bei manchen Implementierungen steuert das Cloudcomputing die empfangenen Daten mindestens temporär in einem Cloudspeicher und beseitigt wahlweise die gespeicherten Daten nach der Verarbeitung der Daten. Der Roboter kann in einigen Beispielen eine Kamera umfassen, die in Kommunikation mit dem Kontrollschaltkreis ist und in der Lage ist, Bilder von einer Szenerie um den Roboter herum zu empfangen und/oder ein volumetrisches Punktwolken-Abbildungsgerät in Kommunikation mit dem Kontrollschaltkreis, das in der Lage ist eine Pointcloud von einem Raumvolumen um den Roboter herum zu empfangen. Das Raumvolumen kann eine Bodenebene in einer Bewegungsrichtung des Roboters umfassen. Der Kontrollschaltkreis kommuniziert Bilddaten an das Cloudcomputing.
Die Daten können rohe Sensordaten umfassen und Daten, die dazugehörige Informationen vom Sensorsystem enthalten. Bei manchen Beispielen umfassen die Daten Bilddaten, die mindestens eine von Akzelerometerdatenzeilen, Odometriedaten und einen Zeitstempel umfassen.
Das Cloudcomputing kann Bilddaten vom Kontrollschaltkreis von einer Szenerie um den Roboter herum empfangen und die Bilddaten in eine 3-D-Landkarte und/oder Modell der Szenerie umwandeln. Des Weiteren kann das Cloudcomputing eine 2-D-Höhenlandkarte und/oder eine Modell dem Kontrollschaltkreis senden, wobei das Cloudcomputing eine 2-D-Höhenlandkarte von der 3-D-Landkarte erarbeitet. Bei einigen Beispielen empfängt das Cloudcomputing die Bilddaten regelmäßig und verarbeitet die erhaltenen Bilddaten nach Anhäufung von einem Schwellenwert von Datensätzen.
Bei manchen Implementierungen kommuniziert der Kontrollschaltkreis die Daten drahtlos an das Cloudcomputing über ein tragbares Computergerät (z. B. Tablet-Computer), das in Kommunikation mit dem Kontrollschaltkreis steht und wahlweise abmontierbar am Roboter angebracht ist. Der Kontrollschaltkreis kann Daten puffern und die Daten regelmäßig an das Cloudcomputing senden.
Das Sensorsystem kann mindestens eines der folgenden Geräte umfassen: eine Kamera, einen 3-D-Abbildungssensor, einen Sonarsensor, einen Ultraschallsensor, LIDAR, LADAR, einen optischen Sensor und einen Infrarotsensor umfassen.
Bei einem weiteren Aspekt der Offenbarung umfasst ein Verfahren zum Betrieb eines mobilen Roboters das Manövrieren des Roboters in einer Szenerie, Empfangen von Sensordaten, die die Szenerie darstellen und Kommunizieren der Sensordaten an ein Cloudcomputing, das die empfangenen Sensordaten bearbeitet und eine Prozessresultante an den Roboter überträgt. Das Verfahren umfasst weiter ein Manövrieren des Roboters in der Szenerie auf der Basis der empfangenen Prozessresultante.
Bei manchen Implementierungen umfasst das Verfahren Ausstrahlen von Licht auf die Szenerie um den Roboter herum und Aufnehmen von Bildern der Szenerie entlang einer Fahrtrichtung des Roboters. Die Bilder umfassen mindestens eines von (a) einem dreidimensionalen Tiefenbild, (b) einem aktiven Beleuchtungsbild und (c) und einem Umgebungsbeleuchtungsbild. Die Sensordaten umfassen die Bilder und die Prozessresultante umfasst eine Landkarte oder ein Modell von der Szenerie.
Das Verfahren kann auch ein Ausstrahlen von einem Specklemuster von Licht auf die Szenerie, Empfangen von Reflektionen des Specklemusters von einem Objekt in der Szenerie und Speichern von Bezugsbildern im Cloudspeicher des Cloudcomputing des Specklemusters, wie es von einem Bezugsobjekt in der Szenerie reflektiert wurde, umfassen. Die Bezugsbilder werden bei unterschiedlichen Entfernungen vom Bezugsobjekt aufgenommen. Das Verfahren umfasst auch ein Aufnehmen von mindestens einem Zielbild des Specklemusters, wie es vom Zielobjekt in der Szenerie reflektiert wird und Kommunizieren des mindestens einen Zielbildes an das Cloudcomputing. Das Cloudcomputing vergleicht das mindestens eine Zielbild mit den Bezugsbildern zur Bestimmung einer Entfernung der reflektierenden Oberflächen des Zielobjektes. Bei einigen Beispielen umfasst das Verfahren ein Bestimmen eines primären Specklemusters auf dem Zielobjekt und Berechnen von mindestens einer entsprechenden Kreuzkorrelation und einer Dekorrelation zwischen dem primären Specklemuster und den Specklemustern der Bezugsbilder.
Das Cloudcomputing kann mindestens temporär die empfangenen Sensordaten im Cloudspeicher speichern und wahlweise die gespeicherten Daten nach der Verarbeitung der Daten entfernen. Zu den Sensordaten können Bilddaten gehören, die dazugehörige Sensorsystemdaten aufweisen, die mindestens eine von Akzelerometerdatenzeilen, Odometriedaten und einen Zeitstempel umfassen können.
Bei manchen Implementierungen empfängt das Cloudcomputing Bilddaten vom Roboter und verarbeitet die Bilddaten in eine 3-D-Landkarte und/oder ein Modell von der Szenerie. Das Cloudcomputing kann auch eine 2-D-Höhenlandkarte und/oder das Modell an den Roboter senden. Das Cloudcomputing berechnet die 2-D-Höhenlandkarte aus der 3-D-Landkarte.
Das Verfahren kann auch ein regelmäßiges Kommunizieren der Sensordaten an das Cloudcomputing beinhalten, welches die empfangenen Bilddaten nach einer Anhäufung bis zum Schwellenwert des Sensordatensatzes verarbeitet. Bei einigen Beispielen umfasst das Verfahren ein drahtloses Kommunizieren der Sensordaten zum Cloudcomputing über ein tragbares Computergerät (z. B. Tablet-Computer), das in Kommunikation mit dem Roboter steht und wahlweise abmontierbar am Roboter befestigt ist.
Bei einem anderen Aspekt umfasst ein Verfahren zum Navigieren eines mobilen Roboters ein Aufnehmen einer Streamingsequenz von kompakten Bildern einer Szenerie um den Roboter herum entlang einer Ortslinie der Bewegung des Roboters bei einer Echtzeiterfassungsrate und dazugehörige Notierungen mit mindestens einigen der kompakten Bildern. Das Verfahren umfasst auch Senden der kompakten Bilder und Notierungen zu einem entfernten Server bei einer Senderate, die langsamer ist als die Echtzeiterfassungsrate, und Empfangen eines Datensatzes vom entfernten Server nach einem Verarbeitungszeitinterwall. Der Datensatz wird von mindestens einem Teil der Sequenz kompakter Bilder und entsprechenden Notierungen erstellt und repräsentiert diesen, schließt jedoch rohe Bilddaten der Sequenz kompakter Bilder aus. Das Verfahren umfasst Bewegen des Roboters in Bezug auf die Szenerie auf der Basis des empfangenen Datensatzes.
Das Verfahren kann auch ein Senden der kompakten Bilder und Notierungen an einen örtlichen Server und Puffer umfassen und dann ein Senden der kompakten Bilder und Notierungen an eine entfernten Server bei einer Senderate, die langsamer ist als die Echtzeitaufnahmerate. Der örtliche Server und Puffer kann sich in einer relativ kurzen Entfernung vom Roboter befinden (z. B. innerhalb von 7 bis 33 Meter oder einer drahtlosen Kommunikationsreichweite).
Bei manchen Implementierungen umfassen die Notierungen einen Zeitstempel wie etwa eine absolute Zeitreferenz entsprechend mindestens eines der kompakten Bilder und auf die Pose bezogene Sensordaten, zu denen mindestens Odometriedaten, Akzelerometerdaten, Neigungsdaten und winkelige Ratendaten gehören. Notierungen können mit den kompakten Bildern assoziiert werden, die Gefahrenvorfälle repräsentieren, die zu einem Zeitinterwall aufgenommen wurden, der in Bezug mit einer Gefahrenreaktionsfähigkeit des Roboters (z. B. Vermeiden einer Klippe, Fliehen aus einer eingeengten Situation etc.) steht. Bei weiteren Beispielen können dazugehörende Notierungen wichtige Einzelbildidentifizierer mit einem Untersatz von den kompakten Bildern umfassen. Mit den Einzelbildidentifizierern kann eine Identifikation eines kompakten Bildes auf der Basis der Eigenschaften der Einzelbildidentifizierer (z. B. Identifizierungssignal, Typ, Gruppe etc.) vorgenommen werden.
Die Notierungen können einen verstreuten Satz von 3-D-Punkten von den Struktur- und Bewegungsaufnahmen Merkmalen, die zwischen kompakten Bildern der Streamingsequenz von kompakten Bildern eingebettet sind, umfassen. Der verstreute Satz von 3-D-Punkten kann von einem volumetrischen Punktwolke-Abbildungsgerät auf dem Roboter stammen. Des Weiteren können die Notierungen Kameraparameter wie etwa eine Kamerapose in Bezug auf einzelne 3-D-Punkte des verstreuten Satzes von 3-D-Punkten umfassen. Markierungen von passierbaren und nicht-passierbaren Gebieten der Szenerie können Notierungen für die kompakten Bilder sein.
Der Datensatz kann eine oder mehrere Texturlandkarten wie etwa die 2-D-Höhenlandkarte, die aus den kompakten Bildern extrahiert wurde und/oder eine Terrainlandkarte umfassen, die Merkmale innerhalb der kompakten Bilder der Szenerie repräsentiert. Der Datensatz kann auch einen trainierten Klassifizierer für die Klassifizierung von Merkmalen innerhalb der neuen kompakten Bilder, die in der Szenerie aufgenommen werden, umfassen.
Bei einem weiteren Aspekt umfasst ein Verfahren des Abstrahierens von Umweltdaten des mobilen Roboters ein Empfangen einer Sequenz kompakter Bilder einer Roboterumwelt von einem mobilen Roboter bei einer Empfangsrate. Die kompakten Bilder werden entlang einer Ortlinie der Bewegung des mobilen Roboters zu einer Echtzeitaufnahmerate aufgenommen. Die Empfangsrate ist langsamer als die Echtzeitaufnahmerate. Das Verfahren umfasst weiter ein Empfangen von Notierungen, die mindestens mit einigen der kompakten Bilder in der Sequenz von kompakten Bildern verknüpft sind und Absenden eines Batchverarbeitungsarbeitsschrittes zur Verringerung der kompakten Daten innerhalb mindestens einiger der kompakten Bilder auf einen Datensatz, der mindestens einen Teil der Sequenz der kompakten Bilder repräsentiert. Das Verfahren umfasst auch ein Übertragen des Datensatzes zum mobilen Roboter. Der Datensatz schließt rohe Bilddaten von der Sequenz von kompakten Bildern aus.
Bei manchen Implementierungen umfasst der Batchverarbeitungsarbeitsschritt ein Verarbeiten der Sequenz von kompakten Bildern in eine kompaktes 3-D-Modell der Roboterumwelt und Verarbeiten des kompakten 3-D-Modells in ein Terrainmodell für ein Koordinatensystem von 2-D-Standorten und mindestens einer Höhe von einer Bodenebene. Bei einigen Beispielen dient das Terrainmodell für ein Koordinatensystem von einem 2-D-Standort und einer Vielzahl von besetzten und nicht-besetzten Höhengrenzen von einer Bodenebene. Beispielsweise würde ein Terrainmodell, wenn der Raum einen Tisch hat, obere und untere Höhen der Tischplatte angeben, so dass der Roboter bestimmen kann, ob er unter dem Tisch durchfahren kann.
Der Batchverarbeitungsarbeitsschritt kann auch Kompaktbildsequenzen umfassen, die eine Vielzahl an Roboterumwelten umfassen. (z. B. so dass die Cloud Klassifizierer für ein Identifizieren von wichtigen Merkmalen irgendeiner Umwelt bilden kann). Daher kann der Batchverarbeitungsarbeitsschritt eine Vielzahl von Klassifizierern umfassen und/oder ein Training von einem oder mehreren Klassifizierern über eine Kompaktbildsequenz bereitstellen. Beispielsweise kann der Batchverarbeitungsarbeitsschritt auch dazugehörige Notierungen umfassen, die Gefahrenvorfälle bei kompakten Bildern, die in einem Zeitintervall aufgenommen werden, der in Bezug zu der Gefahrenreaktionsfähigkeit des mobilen Roboters steht, reflektieren und Trainieren eines Klassifizierer hinsichtlich gefahrenbezogener kompakter Bilder unter Verwendung der dazugehörigen Notierungen von Gefahrenvorfällen und entsprechenden kompakten Bildern als Trainingsdaten, d. h. einen Datensatz von Modellparameter für den Klassifizierer zur Verfügung stellen. Der Klassifizierer kann mindestens eine Stützvektormaschine umfassen, die mindestens eine Hyperebene zur Klassifizierung produziert, und die Modellparameter definieren eine trainierte Hyperebene, die in der Lage ist, einen Datensatz in gefahrenbezogene Klassifizierungen zu verwandeln. Die Modellparameter können genügend Systemparameter umfassen, um einen Systemkern der Stützvektormaschine und einen weichen Randparameter zu definieren.
Bei einigen Beispielen kann der Batchverarbeitungsarbeitsschritt ein Instanziieren einer skalierbaren Pluralität von virtuellen Prozessen umfassen, die proportional zu einer Skala der kompakten Bildersequenz sind, um verarbeitet zu werden. Zumindest einige der virtuellen Prozesse werden nach der Übertragung des Datensatzes zum Roboter freigestellt. Ähnlicherweise kann der Batchverarbeitungsarbeitsschritt ein Instanziieren einer skalierbaren Pluralität von virtuellen Speicher umfassen, der proportional zu einer Skala der kompakten Bildersequenz ist, die gespeichert werden soll. Mindestens etwas von dem virtuellen Speicher wird nach der Übertragung des Datensatzes zum Roboter freigestellt. Des Weiteren kann der Batchverarbeitungsarbeitsschritt ein Verteilen einer skalierbaren Pluralität von virtuellen Servern gemäß einer der geografischen Nähe zum mobilen Roboter und/oder Netzwerkverkehr von einer Vielzahl von mobilen Robotern umfassen.
Genauere Informationen bezüglich einer oder mehreren Implementierungen der Offenbarung werden in den beigefügten Zeichnungen und in der folgenden Beschreibung gegeben. Andere Aspekte, Merkmale und Vorteile werden aus der Beschreibung, den Abbildungen und den Ansprüchen erkennbar.
BESCHREIBUNG DER ABBILDUNGEN
1 ist eine perspektivische Ansicht eines beispielhaften mobilen Roboters mit Mensch-Maschine-Schnittstelle.
2 ist eine schematische Ansicht eines beispielhaften mobilen Roboters mit Mensch-Maschine-Schnittstelle.
3 ist eine perspektivische Elevationsansicht eines beispielhaften mobilen Roboters mit Mensch-Maschine-Schnittstelle.
4A ist eine perspektivische Vorderansicht einer beispielhaften Basis von einem mobilen Roboter mit Mensch-Maschine-Schnittstelle.
4B ist eine perspektivische Rückenansicht der Basis von 4A.
4C ist eine Draufsicht der Basis von 4A.
5A ist eine schematische Vorderansicht einer beispielhaften Basis für einen mobilen Roboter mit Mensch-Maschine-Schnittstelle.
5B ist eine schematische Draufsicht einer beispielhaften Basis für einen mobilen Roboter mit Mensch-Maschine-Schnittstelle.
5C ist eine schematische Vorderansicht eines beispielhaften holonomen Rades für einen mobilen Roboter mit Mensch-Maschine-Schnittstelle.
5D ist eine Seitenansicht des Rades von 5C.
6A ist eine schematische Vorderansicht eines beispielhaften Körpers für einen mobilen Roboter mit Mensch-Maschine-Schnittstelle.
6B ist eine perspektivische Vorderansicht eines beispielhaften Körpers mit Berührungsempfindlichkeit für einen mobilen Roboter mit Mensch-Maschine-Schnittstelle.
6C ist eine perspektivische Unteransicht des Körpers von 6B.
7 ist eine perspektivische Vorderansicht eines beispielhaften Halses für einen mobilen Roboter mit Mensch-Maschine-Schnittstelle.
8A–8G sind schematische Ansichten von beispielhaften Schaltkreisen für einen mobilen Roboter mit Mensch-Maschine-Schnittstelle.
9 ist eine perspektivische Ansicht eines beispielhaften mobilen Roboters mit Mensch-Maschine-Schnittstelle mit abmontierbaren Webpads.
10A–10E sind perspektivische Ansichten von Menschen, die mit einem beispielhaften mobilen Roboter mit Mensch-Maschine-Schnittstelle umgehen.
11A ist eine schematische Ansicht eines beispielhaften mobilen Roboters mit Mensch-Maschine-Schnittstelle.
11B ist eine perspektivische Ansicht eines beispielhaften mobilen Roboters mit Mensch-Maschine-Schnittstelle mit mehrfachen Sensoren, die auf den Boden gerichtet sind.
12A ist eine schematische Ansicht eines beispielhaften Abbildungssensors, der ein Objekt in einer Szenerie aufspürt.
12B ist eine schematische Ansicht einer beispielhaften Anreihung von Arbeitsabläufen zum Betrieb eines Abbildungssensors.
12C ist eine schematische Ansicht einer beispielhaften dreidimensionalen (3D) Specklekamera, die ein Objekt in der Szenerie aufspürt.
12D ist eine schematische Ansicht einer beispielhaften Anreihung von Arbeitsabläufen zum Betrieb einer dreidimensionalen (3D) Specklekamera.
12E eine schematische Ansicht einer beispielhaften 3D-TOF-Kamera, die ein Objekt in der Szenerie aufspürt.
12F ist eine schematische Ansicht einer beispielhaften Anreihung von Arbeitsabläufen zum Betrieb einer 3D-TOF-Kamera.
13 ist eine schematische Ansicht eines beispielhaften Kontrollsystems, das von einem Kontrollschaltkreis eines mobilen Roboters mit Mensch-Maschine-Schnittstelle ausgeführt wird.
14 ist eine perspektivische Ansicht eines beispielhaften mobilen Roboters mit Mensch-Maschine-Schnittstelle, der einen Berührungsbefehl von einem Menschen empfängt.
15 zeigt eine beispielhafte Fernsprechschematik zum Veranlassen und Durchführen einer Kommunikation mit einem mobilen Roboters mit Mensch-Maschine-Schnittstelle.
16A–16E zeigen schematische Darstellungen von beispielhaften Robotersystem-Architekturen.
16F zeigt eine beispielhafte Anreihung von Arbeitsabläufen eines Verfahrens zum Navigieren eines mobilen Roboters.
16G zeigt eine beispielhafte Anreihung von Arbeitsabläufen eines Verfahrens zum Abstrahieren von Umweltdaten des mobilen Roboters.
16H zeigt eine schematische Ansicht einer beispielhaften Robotersystem-Architektur.
17A zeigt eine schematische Ansicht einer beispielhaften Belegungslandkarte.
17B zeigt eine schematische Ansicht eines mobilen Roboters, der ein Blickfeld auf eine Szenerie in einem Arbeitsbereich hat.
18A zeigt eine schematische Ansicht einer beispielhaften Layoutlandkarte.
18B zeigt eine schematische Ansicht einer beispielhaften Roboterlandkarte, die der Layoutlandkarte von 18A entspricht.
18C zeigt eine beispielhafte Anreihung von Arbeitsabläufen für den Betrieb eines mobilen Roboters, um in einer Umwelt mittels einer Layoutlandkarte und einer Roboterlandkarte zu navigieren.
19A zeigt eine schematische Ansicht einer beispielhaften Layoutlandkarte mit Triangulation von Layoutpunkten.
19B zeigt eine schematische Ansicht einer beispielhaften Roboterlandkarte, die der Layoutlandkarte von 19A entspricht.
19C ist eine beispielhafte Anreihung von Arbeitsabläufen für ein Bestimmen einer Zielroboterlandkarte mittels einer Layoutlandkarte und einer Roboterlandkarte.
20A zeigt eine schematische Ansicht einer beispielhaften Layoutlandkarte mit einem Schwerpunkt von engen Layoutpunkten.
20B zeigt eine schematische Ansicht einer beispielhaften Roboterlandkarte, die der Layoutlandkarte von 20A entspricht.
20C ist eine beispielhafte Anreihung von Arbeitsabläufen für ein Bestimmen eines Zielroboterlandkartenstandorts mittels einer Layoutlandkarte und einer Roboterlandkarte.
21A zeigt eine beispielhafte schematische Ansicht eines Wahrnehmungsraumes eines mobilen Roboters mit Mensch-Maschine-Schnittstelle, der stationär ist.
21B zeigt eine beispielhafte schematische Ansicht eines Wahrnehmungsraumes eines mobilen Roboters mit Mensch-Maschine-Schnittstelle, der sich bewegt.
21C zeigt eine beispielhafte schematische Ansicht eines Wahrnehmungsraumes eines mobilen Roboters mit Mensch-Maschine-Schnittstelle, der stationär ist.
21D zeigt eine beispielhafte schematische Ansicht eines Wahrnehmungsraumes eines mobilen Roboters mit Mensch-Maschine-Schnittstelle, der sich bewegt.
21E ist eine beispielhafte schematische Ansicht eines mobilen Roboters mit Mensch-Maschine-Schnittstelle mit einem entsprechenden sensorischen Sichtfeld beim Bewegen nahe um eine Ecke.
21F ist eine beispielhafte schematische Ansicht eines mobilen Roboters mit Mensch-Maschine-Schnittstelle mit einem entsprechenden sensorischen Sichtfeld beim Bewegen weit um eine Ecke.
Die gleichen Referenzsymbole in verschiedenen Abbildungen deuten auf die gleichen Elemente hin.
AUSFÜHRLICHE BESCHREIBUNG
Mobile Roboter können mit Menschen interagieren oder über eine Schnittstelle verbunden sein, um eine Reihe von Dienstleistungen zu erbringen, die sich von der häuslichen Unterstützung bis hin zur kommerziellen Unterstützung und mehr erstrecken können. Bei dem Beispiel der häuslichen Unterstützung kann ein mobiler Roboter ältere Menschen bei ihren täglichen Aufgaben unterstützen, einschließlich und nicht beschränkt auf Einhalten einer Medikationsverabreichung, Unterstützung bei der Mobilität, Kommunikation (z. B. Videokonferenzen, Telekommunikation, Zugriff auf das Internet etc.), Überwachung von einem Haus oder einer Anlage (innen oder außen), Überwachung einer Person und/oder Bereitstellen eines persönlichen Notfallhilfesystems. Hinsichtlich der kommerziellen Unterstützung kann der mobile Roboter Videokonferenzen (z. B. in einem Krankenhaus), bei einem Kassenterminal, interaktive Informationen/Marketingterminal etc. bereitstellen.
Bezugnehmend auf 1–2 umfasst ein mobiler Roboter 100 bei manchen Implementierungen einen Roboterkörper 110 (oder Fahrgestell), das eine Vorwärtsbewegung F definiert. Der Roboter 100 umfasst auch ein Fahrsystem 200, ein Schnittstellenmodul 300 und ein Sensorsystem 400, das jeweils vom Roboterkörper 110 getragen wird und in Kommunikation mit einem Kontrollschaltkreis 500 steht, der Betrieb und Bewegung des Roboters 100 koordiniert. Eine Stromquelle 105 (z. B. Batterie oder Batterien) kann von dem Roboterkörper 110 getragen werden und steht in elektrischer Kommunikation mit und liefert Strom an alle diese Komponenten, falls notwendig. Beispielsweise kann der Kontrollschaltkreis 500 einen Computer umfassen, der in der Lage ist eine Leistung von > 1000 MIPS (Million Instructions per Second) zu bringen und die Stromquelle 1058 stellt eine Batterie dar, die genügend Leistung hat, um den Computer für mehr als drei Stunden zu versorgen.
Der Roboterkörper 110 kann in den gezeigten Beispielen eine Basis 120, mindestens ein Bein 130, das sich von der Basis (120) nach oben erstreckt, und einen Körper 140, der durch das mindestens eine Bein (130) getragen wird, umfassen. Die Basis 120 kann mindestens Teile des Fahrsystems 200 tragen. Der Roboterkörper 110 umfasst auch einen Hals 150, der vom Körper 140 getragen wird. Der Hals 150 trägt einen Kopf 160, der mindestens Teile des Schnittstellenmoduls 300 trägt. Die Basis 120 hat genügend Gewicht (z. B. durch das Tragen der Stromquelle 105 (Batterien)), um einen niedrigen Schwerpunkt CG_B der Basis 120 zu ermöglichen und um einen allgemeinen niedrigen Schwerpunkt CG_R des Roboters 100 zu ermöglichen, um eine mechanische Stabilität beizubehalten.
Bezugnehmend auf 3 und 4A–4C definiert die Basis 120 bei manchen Implementierungen eine trilaterale symmetrische Form (z. B. eine dreieckige Form von der Draufsicht gesehen). Beispielsweise kann die Basis 120 ein Basisfahrgestell 122 umfassen, das den Basiskörper 124 trägt, der erste, zweite und dritte Körperteile 124a, 124b, 124c, entsprechend jedes Beins der trilateral geformten Basis 120 aufweist (vgl. dazu z. B. 4A). Jedes Körperteil 124a, 124b, 124c kann beweglich von dem Basisfahrgestell 122 getragen werden, so dass es sich in Bezug auf das Basisfahrgestell 122 unabhängig bewegen kann als Reaktion auf einen Kontakt mit einem Objekt. Die trilaterale symmetrische Form der Basis 120 ermöglicht die Entdeckung von Bodenwellen 360° um den Roboter 100 herum. Jeder Körperteil 124a, 124b, 124c kann eine entsprechenden Kontaktsensor haben, z. B. einen kapazitiven Sensor, Reedschalter etc.), der Bewegungen der entsprechenden Basiskörperteile 124a, 124b, 124c in Bezug auf das Basisfahrgestell 122 erkennt.
Bei manchen Implementierungen erzeugt das Fahrsystem 200 omnidirektionale und/oder holonome Bewegungssteuerungen des Roboters 100. Der hier verwendete Begriff „omnidirektional” bezieht sich auf die Möglichkeit, sich in im Wesentlichen jeder ebenen Richtung zu bewegen, d. h. von Seite zu Seite (lateral), vorwärts und rückwärts und drehend. Diese Richtungen werden allgemein als x, y bzw. θz bezeichnet. Des Weiteren wird der Begriff „holonom” im Wesentlichen konsistent mit der Literatur verwendet und bezieht sich auf die Fähigkeit, in einer ebenen Richtung mit drei ebenen Freiheitsgraden, d. h. zwei Verschiebungen und einer Rotation, zu bewegen. Dennoch kann ein holonomer Roboter sich in einer ebenen Richtung mit einer Geschwindigkeit bewegen, die im Wesentlichen aus jeder Proportion der drei ebenen Geschwindigkeiten (vorwärts und rückwärts, lateral, drehend) besteht, und auch die Fähigkeit besitzt, diese Proportionen in einer im Wesentlichen fortlaufenden Weise zu ändern.
Der Roboter 100 kann in Umwelten von Menschen (z. B. Umwelt, die vorwiegend für zweibeinige, zu Fuß gehende Bewohner entwickelt wurde) unter Anwendung einer Mobilität auf Rädern betrieben werden. Bei solchen Implementierungen hat das Fahrsystem 200 eine erstes, zweites und drittes Antriebsrad 210a, 210b, 210c, wobei diese gleichmäßig (d. h. trilateral symmetrisch) über die vertikale Zentralachse (Z) verteilt sind (z. B. 120 Grad voneinander entfernt); auch andere Anordnungen sind jedoch möglich. Bezugnehmend auf 5A und 5B können die Antriebsräder 210a, 210b, 210c eine querverlaufende bogenförmige Rollfläche haben (d. h. ein kurviges Profil in einer zur Fahrrichtung D_R querverlaufenden oder senkrechten Richtung), was zu einer besseren Manövrierbarkeit des holonomen Fahrsystem 200 führt. Jedes Antriebsrad 210a, 210b, 210c ist an einen entsprechenden Antriebsmotor 220a, 220b, 220c gekoppelt, der die jeweiligen Antriebsräder 210a, 210b, 210c unabhängig von den anderen Antriebsmotoren 220a, 220b, 220c vorwärts oder rückwärts antreibt. Jeder Antriebsmotor 220a–c kann einen entsprechenden Encoder 212 (8C) aufweisen, der ein Radrotationsfeedback an den Kontrollschaltkreis 500 abgibt. Bei einigen Beispielen ist jedes Antriebsrad 210a, 210b, 210c auf oder nahe an einem der drei Punkte auf einem gleichseitigen Dreieck montiert und weist eine Fahrtrichtung (vorwärts oder rückwärts) auf, die senkrecht zu einem Winkelbisektor des entsprechenden Dreiecksende ist. Beim Fahren der trilateral symmetrischen holonomen Basis 120 in einer Vorwärtsrichtung F kann der Roboter 100 für eine unabhängige Flucht aus Einengungen oder Hindernissen in nicht vorwärts laufende Richtungen übergehen und dann rotieren und/oder sich versetzen, um dann in die Vorwärtsrichtung F zu gehen, nachdem die Flucht erfolgreich war.
Bezugnehmend auf 5C und 5D kann jedes Antriebsrad 210 bei manchen Implementierungen innen und außen liegende Reihen 232, 234 von Rollen 230 aufweisen, wobei jede eine Rollrichtung D_r hat, die senkrecht zu der Rollrichtung D_R des Antriebsrades 210 ist. Die Reihen 232, 234 der Rollen 230 können versetzt sein (z. B. so dass eine Rolle 230 der Innenreihe 232 gleichmäßig zwischen zwei angrenzenden Rollen 230 der Außenreihe 234 positioniert ist. Die Rollen 230 ergeben einen unbegrenzten Schlupf senkrecht zu der Fahrtrichtung des Antriebsrades 210. Die Rollen 230 definieren eine bogenförmige (z. B. konvexe) Außenoberfläche 235 senkrecht zu deren Rollrichtungen D_r, so dass die Rollen 230 den kreisförmigen oder im Wesentlichen kreisförmigen Umfang des Antriebsrades 210 definieren. Das Profil der Rollen 230 beeinflusst das Gesamtprofil des Antriebsrades 210. Beispielsweise können die Rollen 230 bogenförmige Rollenaußenoberflächen 235 definieren, um so zusammen eine rundgezackte Rolloberfläche des Antriebsrades 210 zu definieren (z. B. als Profil für Bodenhaftung). Jedenfalls kann durch Konfigurieren der Rollen 230, damit sie Konturen aufweisen, die eine kreisförmige Gesamtoberfläche des Antriebsrades 210 erlauben, der Roboter 100 problemlos auf flachen Oberflächen fahren, ohne vertikal aufgrund der Radprofile zu vibrieren. Wenn in einem Winkel an ein Objekt herangefahren wird, können die versetzten Reihen 232, 234 der Rollen 230 (mit Radius r) als Profil verwendet werden, um auf Objekte hinaufzufahren, die so hoch oder beinahe so hoch wie der Radradius R des Antriebsrades 210 sind.
Bei den in 3–5B gezeigten Beispielen ist das erste Antriebsrad 210a als eine führendes Rad entlang der Vorwärtsrichtung F angebracht und die beiden übrigen zwei Antriebsräder 210b, 210c laufen hinterher. Bei dieser Anordnung kann der Kontrollschaltkreis 500 für ein Vorwärtsfahren einen Fahrbefehl ausgeben, der das zweite und dritte Antriebsrad 210b, 210c dazu veranlasst, in eine Vorwärtsrichtung im gleichen Tempo zu fahren, während das erste Antriebsrad 210a entlang der Vorwärtsrichtung F gleitet. Des Weiteren kann mit dieser Antriebsradanordnung der Roboter 100 plötzlich anhalten (z. B. eine schnelle negative Beschleunigung entgegen der Vorwärtsrichtung F erleben). Das passiert aufgrund der natürlichen dynamischen Instabilität des Designs mit drei Rädern. Falls die Vorwärtsrichtung F entlang eines Winkelbisektors zwischen zwei Vorwärtsantriebsrädern geht, würde ein plötzliches Anhalten ein Drehmoment schaffen, wodurch der Roboter 100 gezwungen wird, zu fallen, also sich über seine zwei „Vorderräder” zu drehen. Dagegen kann bei dem Fahren mit einem Antriebsrad 210a vorne auf natürliche Weise der Roboter 100 davor geschützt werden, nach vorne zu fallen, wenn ein plötzliches Anhalten notwendig wird. Bei der Beschleunigung nach einem Anhalten kann der Kontrollschaltkreis 500 jedoch auch einen Moment der Trägheit I des Roboters 100 von seinem Gesamtschwerpunkt CG_R berücksichtigen.
Bei manchen Implementierungen des Fahrsystems 200 hat jedes Antriebsrad 210a, 210b, 210 eine Rollrichtung D_R, die radial an der vertikalen Achse Z anliegt, welche orthogonal an der X- und Y-Achse des Roboters 100 verläuft. Das erste Antriebsrad 210a kann als führendes Antriebsrad entlang der Vorwärtsrichtung F angeordnet werden, wobei die verbleibenden zwei Antriebsräder 210b, 210c dahinter laufen. Bei dieser Anordnung kann der Kontrollschaltkreis 500 für ein Vorwärtsfahren einen Fahrbefehl ausgeben, der das erste Antriebsrad 210a dazu veranlasst in eine Vorwärtsrichtung F zu fahren und das zweite und dritte Antriebsrad 210b, 210c dazu veranlasst im gleichen Tempo wie das erste Antriebsrad 210a zu fahren, jedoch in entgegengesetzter Richtung.
Bei anderen Implementierungen kann das Fahrsystem 200 so angebracht sein, um ein erstes und ein zweites Antriebsrad 210a, 210b so zu positionieren, so dass ein Winkelbisektors des Winkels zwischen den beiden Antriebsrädern 210a, 210b der Vorwärtsrichtung F des Roboters 100 anliegt. Bei dieser Anordnung kann der Kontrollschaltkreis 500 für ein Vorwärtsfahren einen Fahrbefehl ausgeben, der das erste und zweite Antriebsrad 210a, 210b dazu veranlasst, in eine Vorwärtsrichtung im gleichen Tempo zu fahren, während das dritte Antriebsrad 210c in entgegengesetzter Richtung fährt oder still steht und hinter dem ersten und zweiten Antriebsrad 210a, 210b gezogen wird. Um beim Vorwärtsfahren nach links oder rechts abzubiegen, kann der Kontrollschaltkreis 500 einen Fahrbefehl ausgeben, der das erste und zweite Antriebsrad 210a, 210b dazu veranlasst, in einem relativ schnelleren/langsameren Tempo zu fahren. Andere Ausführungen des Fahrsystems 200 können auch verwendet werden. Die Antriebsräder 210a, 210b, 210c können auch zylinderförmige, kreisförmige, elliptische oder polygonale Profile aufweisen.
Wieder bezugnehmend auf 1–3 trägt die Basis 120 mindestens ein Bein 130, das sich von der Basis (120) nach oben in die Richtung Z erstreckt. Das Bein bzw. die Beine 130 können derart konfiguriert sein, dass sie eine variierbare Höhe haben, um damit den Körper 140 in Bezug auf die Basis 120 zu heben oder zu senken. Bei manchen Implementierungen umfasst jedes Bein 130 einen ersten und zweiten Bereich 132, 134, die sich im Verhältnis zueinander bewegen (z. B. mit einer teleskopischen, linearen und/oder winkeligen Bewegung). Anstatt einer Verdrängung von teleskopischen Teilen mit nachfolgend kleinerem Durchmesser in sich hinein und hinaus oder hinaus von einer relativ größeren Basisextrusion bewegt sich der zweite Beinbereich 134 bei den gezeigten Beispielen teleskopisch über den ersten Beinbereich 132, wodurch andere Komponenten entlang dem zweiten Beinbereich 134 angebracht werden können und möglicherweise mit dem zweiten Beinbereich 134 an eine relative Nähe zur Basis 120 bewegt werden können. Das Bein 130 kann eine Aktuatorbaugruppe 136 (8C) zum Bewegen des zweiten Beinbereichs 134 in Bezug auf den ersten Beinbereich 132 umfassen. Die Aktuatorbaugruppe 136 kann einen Motortreiber 138a aufweisen, der in Kommunikation mit einem Hebemotor 138b und einem Encoder 138c steht, welche Positionsfeedback an den Kontrollschaltkreis 500 ausgeben.
Allgemein umfassen teleskopische Einrichtungen Verdrängungen mit nachfolgend kleinerem Durchmesser, die in relativ größere Verdrängungen an der Basis 120 hinein- und hinausgehen, um damit den zentralen Schwerpunkt CG_L des ganzen Beins 130 so niedrig wie möglich zu halten. Des Weiteren können stärkere und/oder größere Komponenten an der Unterseite angebracht werden, um die größeren Drehmomente auszugleichen, die bei der Basis 120 entstehen, wenn das Bein 130 voll ausgestreckt ist. Dieser Ansatz bringt aber zwei Probleme. Ersten, wenn relativ kleinere Komponenten oben an dem Bein 130 angebracht werden, können Regen, Staub oder andere Partikel tendenziell in die Verdrängungen kommen und in den Raum zwischen den Verdrängungen eindringen und damit die Verschachtelung der Verdrängungen behindern. Dadurch wird ein sehr schwieriges Versiegelungsproblem kreiert, wobei immer noch eine völlige Mobilität/Gelenkverbindung des Beins 130 aufrechterhalten werden soll. Zweitens kann es erwünscht sein, eine Nutzlast oder Zubehör an den Roboter 100 zu montieren. Ein üblicher Ort für die Montage von Zubehör ist auf der Oberseite des Körpers 140. Wenn der zweite Beinbereich 134 teleskopisch rein und raus von dem ersten Beinbereich bewegt wird, können Zubehör und Komponenten dann nur oberhalb des gesamten zweiten Beinbereichs 134 montiert werden, wenn diese sich mit dem Körper 140 bewegen müssen. Andernfalls würden die Komponenten, die auf dem zweiten Beinbereich 134 angebracht sind, die teleskopische Bewegung des Beins 130 beschränken.
Indem der zweite Beinbereich 134 teleskopisch über den ersten Beinbereich 132 bewegt wird, stellt der zweite Beinbereich 134 zusätzliche Montierpunkte für die Nutzlast zur Verfügung, die sich vertikal in Bezug auf die Basis 120 bewegen können. Diese Art der Einrichtungen verursacht, dass Wasser oder luftübertragene Partikel am Körper 140 an der Außenseite von jedem Beinbereich 132, 134 (z. B. Verdrängung) herunter laufen und nicht in den Raum zwischen den Beinbereichen 132, 134 eindringen. Dadurch wird die Versiegelung der Gelenke des Beins 130 erleichtert. Des Weiteren können Montageeinrichtungen für Nutzlast oder Zubehör des Körpers 140 und/oder zweiten Beinbereichs 134 immer exponiert sein und zur Verfügung stehen, ungeachtet wie weit das Bein 130 ausgestreckt ist.
Bezugnehmend auf 3 und 6A tragen das Bein bzw. die Beine 130 den Körper 140, der eine Schulter 142 haben kann, die sich über und oberhalb der Basis 120 erstrecken kann. Bei dem gezeigten Beispiel hat der Körper 140 eine untere Oberfläche 144, die nach unten gerichtet ist (z. B. zur Basis hin), um zumindest einen Bereich der Schulter 142 zu formen, und eine gegenüberliegende nach oben gerichtete obere Oberfläche 146, mit einer Seitenoberfläche 148, die sich dazwischen erstreckt. Der Körper 140 kann verschiedene geometrische Formen annehmen, wie etwa eine kreisförmige oder eine elliptische Form mit einem zentralen Bereich 141, der durch das Bein bzw. die Beine 130 getragen wird, und einen Bereich 143 frei von Peripheriegeräten, der sich lateral über die laterale Erstreckung der Beine 130 erstreckt, und damit einen überhängenden Bereich herstellt, der die nach unten gerichtete Oberfläche 144 definiert. Bei einigen Beispielen definiert der Körper 140 eine polygonale oder andere komplexe Form, die eine Schulter definiert, die einen überhängenden Bereich herstellt, der sich über das Bein bzw. die Beine 130 hinaus über die Basis 120 erstreckt.
Der Roboter 100 kann einen oder mehrere Zubehörports 170 (z. B. mechanische und/oder elektrische Verbindungspunkte) zum Anbringen von Nutzlast aufweisen. Die Zubehörports 170 können so platziert sein, dass die angebrachte Nutzlast keine Sensoren des Sensorsystems 400 (z. B. auf der unteren Oberfläche 144 und/oder auf der oberen Oberfläche 146 des Körpers 140, etc.) behindert oder verschließt. Bei manchen Implementierungen, wie in 6A gezeigt, umfasst der Körper 140 einen oder mehrere Zubehörports 170 auf einem rückwärtigen Bereich 149 des Körpers 140, beispielsweise zum Anbringen von Nutzlast in dem Korb 360, um Sensoren an der Vorderseite 147 des Körpers 140 oder anderen Bereichen des Roboterkörper 110 nicht zu behindern.
Eine externe Oberfläche des Körpers 140 kann empfindlich auf Kontakt oder Berühren des Benutzers sein, und damit Berührungsbefehle vom Benutzer empfangen. Beispielsweise wenn der Benutzer die obere Oberfläche 146 des Körpers 140 berührt, reagiert der Roboter 100 durch Verringerung der Höhe H_T des Körpers in Bezug auf den Boden (z. B. durch Verringern der Höhe H_L der Beine 130, die den Körper 140 tragen). Ähnlich reagiert der Roboter 100, wenn der Benutzer die untere Oberfläche 144 des Körpers 140 berührt, mit Erheben des Körpers 140 in Bezug auf den Boden (z. B. durch Erhöhen der Höhe H_L der Beine 130, die den Körper 140 tragen). Weiter reagiert der Roboter 100 nach Erhalt einer Benutzerberührung an den vorderen, hinteren oder linken und rechten Bereichen der Oberfläche 148 des Körpers 140, indem er sich in die entsprechende Richtung des empfangenen Berührungsbefehls bewegt (z. B. jeweils rückwärts, vorwärts und nach recht oder links). Die externe(n) Oberfläche(n) des Körpers 140 kann bzw. können einen Kapazitätssensor in Kommunikation mit dem Kontrollschaltkreis 500 aufweisen, der den Benutzerkontakt erkennt.
Bezugnehmend auf 6B and 6C umfasst der Körper 140 bei manchen Implementierungen einen Körperteil 145 mit einer oberen Schalttafel 145t, einer unteren Schalttafel 145b, einer vorderen Schalttafel 145f, einer hinteren Schalttafel 145b, einer rechten Schalttafel 145r und einer linken Schalttafel 145l. Jede Schalttafel 145t, 145b, 145f, 145r, 145r, 145l kann individuell in Bezug auf die anderen Schalttafeln bewegt werden. Des Weiteren kann jede Schalttafel 145t, 145b, 145f, 145r, 145r, 145l einen dazugehörigen Bewegungs- oder Kontaktsensor 147t, 147b, 147f, 147r, 147r, 147l in Kommunikation mit dem Kontrollschaltkreis 500 aufweisen, der Bewegungen erkennt und/oder in Kontakt mit der entsprechenden Schalttafel steht.
Bezugnehmend wieder auf 1–3 und 7 trägt der Körper 140 den Hals 150, der ein Schwenken und Neigen des Kopfes 160 in Bezug auf den Körper 140 möglich macht. Bei den gezeigten Beispielen umfasst der Hals 150 einen Rotator 152 und eine Kippvorrichtung 154. Der Rotator 152 kann eine Reihe von schrägen Bewegungen ☐_R (z. B. um die Z-Achse) zwischen ungefähr 90° und 360° durchführen. Andere Winkelbereiche sind ebenfalls möglich. Des Weiteren umfasst der Rotator 152 bei einigen Beispielen elektrische Anschlüsse oder Kontakte, die eine fortdauernde Rotation des Kopfes 160 in Bezug auf den Körper 140 um 360°, bei einer unbegrenzten Anzahl von Rotationen, möglich macht, während die elektrische Kommunikation zwischen dem Kopf 160 und dem Rest des Roboters 100 aufrecht gehalten wird. Die Kippvorrichtung 154 kann auch gleiche oder ähnliche elektrische Anschlüsse oder Kontakte umfassen, die eine Rotation des Kopfes 160 in Bezug auf den Körper 140 erlauben, während die elektrische Kommunikation zwischen dem Kopf 160 und dem Rest des Roboters 100 aufrecht erhalten wird. Der Rotator 152 kann auch einen Rotatormotor 152m umfassen, der mit einem Ring 153 verbunden ist oder in diesen eingreift (z. B. eine gezackte Ringschiene). Die Kippvorrichtung 154 kann den Kopf in einem Winkel ☐_T (z. B. um die Y-Achse) in Bezug auf den Körper 140, unabhängig vom Rotator 152, drehen. Bei einigen Beispielen umfasst die Kippvorrichtung 154 einen Kippmotor 155, der den Kopf 160 zwischen einem Winkel ☐_T von ±90° in Bezug auf die Z-Achse dreht. Andere Winkelbereiche sind ebenfalls möglich, wie etwa ±45° etc. Der Roboter 100 kann derart konfiguriert sein, dass die Beine 130, der Körper 140, der Hals 150 und der Kopf 160 in einem Umfang der Basis 120 verbleiben, um dem Roboter 100 eine stabile Mobilität zu verleihen. Bei dem beispielhaften Schaltkreis in 8F umfasst der Hals 150 eine Schwenk-Kippvorrichtung 151, die den Rotator 152 und eine Kippvorrichtung 154 zusammen mit entsprechenden Motortreibern 156a, 156b und Encoder 158a, 158b umfasst.
Der Kopf 160 kann auf Kontakt oder Berühren des Benutzers empfindlich sein und damit Berührungsbefehle vom Benutzer empfangen. Wenn beispielsweise der Benutzer den Kopf 160 nach vorne zieht, beugt sich der Kopf 160 nach vorne mit passivem Widerstand und hält diese Position. Des Weiteren, wenn der Benutzer den Kopf 160 vertikal nach unten zieht/drückt, kann der Körper 140 (durch Reduktion der Beinlänge 130) den Kopf 160 senken. Der Kopf 160 und/oder Hals 150 können Dehnungsmesser oder Kontaktsensoren 165 (7) umfassen, die Benutzerkontakt oder -manipulation erkennen.
8A–8G zeigen beispielhafte Schemen von Schaltkreisen für den Roboter 100. 8A–8C zeigen beispielhafte Schemen von Schaltkreisen für die Basis 120, welche auch die Umgebungssensoren, wie die Sonarumgebungssensoren 410 und die Klippenumgebungssensoren 420, Kontaktsensoren 430, den Laserscanner 440, den Sonarscanner 460 und das Fahrsystem 200 umfassen. Die Basis 120 kann auch den Kontrollschaltkreis 500, die Stromquelle 105 und die Beinaktuatorbaugruppe 136 umfassen. Der Körper 140 kann einen Mikrokontrollschaltkreis 140c, Mikrophon(e) 330, Lautsprecher 340, den abtastenden 3-D-Bildsensor 450a und ein Körperberührungssensorsystem 480 umfassen, wodurch der Kontrollschaltkreis 500 Benutzerkontakt oder Berührungen (z. B. durch Bewegen des Körpers 140 in Bezug auf die Basis 120, Schwenken oder Kippen des Halses 150 und/oder Ausgeben von Fahrbefehlen an das Fahrsystem 200 als Reaktion dazu) empfangen oder darauf reagieren kann. Der Hals 150 kann eine Schwenk-Kippvorrichtung 151 umfassen, die einen Schwenkmotor 152 umfasst, der einen entsprechenden Motortreiber 156a und Encoder 158a umfasst und einen Kippmotor 154, der einen entsprechenden Motortreiber 156b und Encoder 158b umfasst. Der Kopf 160 kann ein oder mehrere Webpads 310 und eine Kamera 320 umfassen.
Bezugnehmend auf 1–3 und 9 trägt der Kopf 160 bei manchen Implementierungen ein oder mehrere Bereiche des Schnittstellenmoduls 300. Der Kopf 160 kann ein Dock 302 für Anbringen von einem oder mehreren Tablet-Computer(n) 310 umfassen, die auch Webpads oder Tablet-PCs genannt werden, wobei alle einen Sensorbildschirm 312 aufweisen können. Das Webpad 310 kann nach vorne, hinten, und nach oben gerichtet sein. Bei manchen Implementierungen umfasst das Webpad 310 einen Sensorbildschirm, optionale Eingaben/Ausgaben (z. B. Schaltflächen und/oder Anschlüsse, wie etwa Mikro-USB etc.), einen Prozessor und einen Speicher, der in Kommunikation mit dem Prozessor steht. Ein beispielhaftes Webpad 310 ist ein iPad von Apple, Inc. Bei einigen Beispielen fungiert das Webpad 310 als Kontrollschaltkreis 500 oder unterstützt den Kontrollschaltkreis 500 und steuert den Roboter 100. Bei einigen Beispielen umfasst das Dock 302 einen ersten Tablet-Computer 310a, der fest montiert ist (z. B. eine verdrahtete Schnittstelle für Datentransfer mit relativ höherer Bandbreite im Gigabit-Bereich) und einen zweiten Tablet-Computer 310b, der entfernbar angebracht ist. Das zweite Webpad 310b kann über dem ersten Webpad 310a aufgenommen werden, wie es in 9 gezeigt wird, oder das zweite Webpad 310b kann auf der gegenüberliegenden Seite des Kopfes 160 in Bezug auf das erste Webpad 310a aufgenommen werden. Bei weiteren Beispielen trägt der Kopf 160 ein einziges Webpad 310, das fest oder abmontierbar angebracht ist. Der Sensorbildschirm 312 kann Punkte von Benutzerberührungen für den Erhalt von Benutzereingaben erkennen, überwachen und/oder reproduzieren und eine grafische Benutzerschnittstelle bereitstellen, die interaktiv auf Berührung reagiert. Bei einigen Beispielen umfasst das Webpad 310 ein Anrufgerät für den Sensorbildschirm, damit der Benutzer ihn finden kann, wenn er vom Roboter 100 entfernt wurde.
Bei manchen Implementierungen umfasst der Roboter 100 mehrfache Webpaddocks 302 auf einem oder mehreren Bereichen des Roboterkörpers 110. Bei dem in 9 gezeigten Beispiel umfasst der Roboter 100 ein Webpaddock 302, das wahlweise an dem Bein 130 und/oder am Körper 140 angebracht ist. Damit kann der Benutzer ein Webpad 310 bei verschiedenen Höhen auf dem Roboter 100 andocken, beispielsweise um sich für Benutzer von verschiedenen Größen für ein Aufnehmen eines Videos mit der Kamera auf dem Webpad 310 bei verschiedenen Blickwinkeln anzupassen und/oder mehrfache Webpads 310 auf dem Roboter 100 zu empfangen.
Das Schnittstellenmodul 300 kann eine Kamera 320 umfassen, die auf dem Kopf 160 (vgl. dazu 2) angebracht ist, die für ein Aufnehmen eines Videos bei erhöhtem Blickwinkel des Kopfes 160 (z. B. für Videokonferenzen) verwendet werden kann. Bei dem in 3 gezeigten Beispiel ist die Kamera 320 am Hals 150 angebracht. Bei einigen Beispielen wird die Kamera 320 nur dann betrieben, wenn das Webpad 310, 310a vom Kopf 160 entfernt wird oder dort nicht eingedockt ist. Wenn das Webpad 310, 310a am Kopf 160 im Dock 302 befestigt oder eingedockt ist (und wahlweise die Kamera 320 bedient), kann der Roboter 100 eine Kamera vom Webpad 310a für die Aufnahme von einem Video verwenden. Bei solchen Fällen kann die Kamera 320 hinter dem eingedockten Webpad 310 gestellt werden und wird aktiv, wenn das Webpad 310 vom Kopf 160 entfernt oder dort nicht eingedockt ist und nicht aktiv, wenn das Webpad 310 am Kopf 160 befestigt oder eingedockt ist.
Der Roboter 100 kann Videokonferenzen (z. B. bei 24 Bildern pro Sekunde) über das Schnittstellenmodul 300 (z. B. mit dem Webpad 310, der Kamera 320, den Mikrophonen 320 und/oder den Lautsprechern 340) ermöglichen. Das Videokonferenzen kann viele Parteien einschließen. Der Roboter 100 kann einen Augenkontakt zwischen beiden Parteien der Videokonferenz herstellen, indem der Kopf 160 hin zum Gesicht des Benutzers bewegt wird. Des Weiteren kann der Roboter 100 einen Blickwinkel < 5 Grad haben (z. B. einen Winkel weg von der Achse, die normal an der Vorderansicht des Kopfes 160 liegt). Mindestens ein 3-D-Bildsensor 450 und/oder die Kamera 320 auf dem Roboter 100 kann lebensgroße Bilder inklusive Körpersprache aufnehmen. Der Kontrollschaltkreis 500 kann Audio und Video synchronisieren (z. B. mit dem Unterschied von < 50 ms).
Bei dem in 10A–10E gezeigt Beispiel kann der Roboter 100 Videokonferenzen für stehende und sitzende Personen durchführen, indem die Höhe des Webpads 310 auf dem Kopf 160 und/oder die Kamera 320 angepasst wird (indem der Körper 140 erhöht oder gesenkt wird) oder durch Schwenken und Neigen des Kopfes 160. Die Kamera 320 kann innerhalb mindestens eines Freiheitsgrads getrennt vom Webpad 310 beweglich sein. Bei einigen Beispielen hat die Kamera 320 ein Objektiv, das mehr als einen Meter vom Boden positioniert ist, aber nicht mehr als 10 Prozent der Webpadhöhe vom oberen Ende des Anzeigebereichs des Webpads 310. Des Weiteren kann der Roboter 100 die Kamera 320 zoomen, um eine Nahaufnahme eines Bildes oder Videos um den Roboter 100 herum zu erhalten. Der Kopf 160 kann einen oder mehrere Lautsprecher 340 umfassen, so dass Ton vom Kopf 160 nahe dem Webpad 310, das die Videokonferenz anzeigt, erzeugt wird.
Bei einigen Beispielen kann der Roboter 100 Benutzereingaben in dem Webpad 310 empfangen (z. B. über einen Sensorbildschirm), wie es in 10E gezeigt wird. Bei manchen Implementierungen ist das Webpad 310 eine Anzeige oder ein Bildschirm, während bei anderen Implementierungen das Webpad 310 ein Tablet-Computer ist. Das Webpad 310 kann einfache und intuitive Steuerungen aufweisen, wie etwa ein Sensorbildschirm, um eine hohe Interaktivität zu gewährleisten. Das Webpad 310 kann eine Bildschirmanzeige 312 (z. B. Sensorbildschirm) aufweisen, die ein Anzeigefeld von 30 Quadratzentimeter oder mehr umfasst, und mit mindestens einem Freiheitsgrad beweglich ist.
Der Roboter 100 kann eine EMR-Integration bereitstellen und kann bei einigen Beispielen Videokonferenzen von einem Arzt und Patient und/oder mit anderen Ärzten oder Krankenschwestern bereitstellen. Der Roboter 100 kann Durchreiche-Instrumente der Untersuchung umfassen. Beispielsweise kann der Roboter 100 ein Stethoskop umfassen, das derart konfiguriert ist, ein Abhören an den Benutzer der Videokonferenzen (z. B. ein Arzt) zu leiten. Bei anderen Beispielen umfasst der Roboter Anschlüsse 170, die einen direkten Anschluss an medizinische Geräte der Klasse II erlauben, wie etwa ein elektronisches Stethoskop, Otoskop und Ultraschall, um medizinische Daten an einen entfernten Benutzer (Arzt) zu leiten.
In dem in 10B gezeigten Beispiel kann ein Benutzer das Webpad 310 vom Webpaddock 302 auf dem Kopf 160 für einen entfernten Betrieb des Roboters 100, Videokonferenzen (z. B. unter Verwendung der Kamera und dem Mikrofon des Webpads 310) und/oder Verwendung einer Softwareapplikation auf dem Webpad 310 entfernen. Der Roboter 100 kann eine erste und zweite Kamera 320a, 320b auf dem Kopf 160 haben, um verschiedene Blickwinkel für Videokonferenzen, Navigation etc. zu haben, während das Webpad 310 vom Webpaddock 302 entfernt ist.
Interaktive Applikationen, die mit dem Kontrollschaltkreis 500 und/oder in Kommunikation mit dem Kontrollschaltkreis 500 ausfahrbar sind, können mehr als eine Anzeige auf dem Roboter 100 erfordern. Multiple Webpads 310, die mit dem Roboter 100 verbunden sind, können unterschiedliche Kombinationen von „FaceTime”, Telestration, „HD look at this-cam” (z. B. für Webpads 310 mit integrierter Kamera) zur Verfügung stellen, können als eine Steuerungseinheit auf Distanz (OCU) zur Steuerung des Roboters 100 auf Distanz funktionieren und/oder als Schnittstelle für einen örtlichen Benutzer dienen.
Wieder bezugnehmend auf 6A kann das Schnittstellenmodul 300 ein Mikrofon 330 (z. B. Mikrofonarray) zum Empfangen von Toneingängen und einen oder mehrere Lautsprecher 340, die am Roboterkörper 110 angebracht sind, zur Ausgabe von Tönen aufweisen. Das Mikrofon 330 und die Lautsprecher 340 können jeweils mit dem Kontrollschaltkreis 500 kommunizieren. Bei einigen Beispielen kann das Schnittstellenmodul 300 eine Korb 360 umfassen, der zum Aufbewahren von Broschüren, Notfallinformationen, Haushaltsgeräten und andere Artikeln konfiguriert ist.
Bezugnehmend auf 1–4C, 11A und 11B, um zuverlässige und robuste autonome Bewegungen zu sichern, kann das Sensorsystem 400 verschiedene Arten von Sensoren aufweisen, die in Verbindung miteinander stehen, um eine Sichtweise der Umwelt des Roboters zu schaffen, die es dem Roboter 100 erlaubt, intelligente Entscheidungen hinsichtlich der Handlungen, die in der Umwelt durchzuführen sind, zu treffen. Das Sensorsystem 400 kann eine oder mehrere Arten von Sensoren aufweisen, die vom Roboterkörper 110 getragen werden, welche Sensoren zum Erkennen und Vermeiden von Hindernissen (ODOA), Kommunikationssensoren, Navigationssensoren etc. umfassen. Beispielsweise können diese Sensoren ohne Einschränkung Umgebungssensoren, Kontaktsensoren, dreidimensionale (3D) Abbildungs-/Tiefenlandkarte-Sensoren, eine Kamera (z. B. für wahrnehmbares Licht und/oder Infrarot-Kamera), ein Sonargerät, ein Radargerät, LIDAR (Light Detection And Ranging, was optische Wahrnehmung auf Distanz beinhaltet, die Eigenschaften von gestreutem Licht misst, um eine Reichweite und/oder andere Informationen eines entfernten Zielobjekts zu bestimmen), LADAR (Laser Detection and Ranging) etc. umfassen. Bei manchen Implementierungen umfasst das Sensorsystem 400 Sonarsensoren 410 (z. B. neun um einen Umfang der Basis 120 herum), Klippenumgebungssensoren 420, Kontaktsensoren 430, einen Laserscanner 440, einen oder mehrere 3-D-Abbildungs-/Tiefensensoren 450 und eine abbildendes Sonargerät 460.
Es gibt verschiedene Schwierigkeiten bei der Platzierung von Sensoren auf einer Roboterplattform. Erstens müssen die Sensoren derart plaziert werden, dass sie eine maximale Abdeckung der Gebiete von Interesse um den Roboter 100 herum bieten können. Zweitens müssen die Sensoren derart plaziert werden, dass der Roboter 100 selbst ein absolutes Minimum an Verdeckung für die Sensoren gewährleistet; im Wesentlichen können die Sensoren nicht so plaziert werden, dass sie aufgrund des Roboters „blind” werden. Drittens darf die Platzierung und Montage der Sensoren nicht zu aufdringlich für den Rest der industriellen Entwicklung der Plattform sein. Bezüglich der Ästhetik kann davon ausgegangen werden, dass ein Roboter mit Sensoren, die unauffällig angebracht sind, „attraktiver” erscheint als anderweitig. Bezüglich der Nützlichkeit sollten die Sensoren derart angebracht werden, dass sie den normalen Roboterbetrieb nicht stören (an Hindernissen hängen bleiben etc.).
Bei manchen Implementierungen umfasst das Sensorsystem 400 einen Satz oder ein Array von Umgebungssensoren 410, 420, die in Kommunikation mit dem Kontrollschaltkreis 500 stehen und in einer oder mehreren Zonen oder Bereichen des Roboters 100 (z. B. auf oder nahe am Basiskörperbereich 124a, 124b, 124c des Roboterkörpers 110) angebracht sind, um störende Hindernisse in der Nähe zu entdecken. Die Umgebungssensoren 410, 420 können konvergente Infrarot-Emittersensorelemente, Sonarsensoren, Ultraschallsensoren und/oder Abbildungssensoren (z. B. 3D-Tiefenlandkarte-Sensoren) sein, die ein Signal an den Kontrollschaltkreis 500 abgeben, wenn ein Objekt innerhalb einer gegebenen Reichweite des Roboters 100 liegt.
Bei dem in 4A–4C gezeigten Beispiel umfasst der Roboter 100 ein Array von Sonar-Umgebungssensoren 410, die (z. B. im Wesentlichen gleich weit entfernt) um den Basiskörper 120 herum angeordnet sind und zwar derart, dass sie ein nach oben gerichtetes Blickfeld haben. Erster, zweiter und dritter Sonar-Umgebungssensor 410a, 410b, 410c befinden sich auf oder in der Nähe des ersten (vorderen) Basiskörperbereichs 124a, wobei mindestens einer der Sonar-Umgebungssensoren in der Nähe einer radial am weitesten außen gelegenen Ecke 125a des ersten Basiskörperbereichs 124a liegt. Vierter, fünfter und sechster Sonar-Umgebungssensor 410d, 410e, 410f befinden sich auf oder in der Nähe des zweiten (rechten) Basiskörperbereichs 124b, wobei mindestens einer der Sonar-Umgebungssensoren in der Nähe einer radial am weitesten außen gelegenen Ecke 125b des zweiten Basiskörperbereichs 124b liegt. Siebter, achter und neunter Sonar-Umgebungssensor 410g, 410h, 410i befinden sich auf oder in der Nähe des dritten (linken) Basiskörperbereichs 124c, wobei mindestens einer der Sonar-Umgebungssensoren in der Nähe einer radial am weitesten außen gelegenen Ecke 125c des dritten Basiskörperbereichs 124c liegt. Bei dieser Konfiguration werden mindestens drei Zonen für Entdeckung bereitgestellt.
Bei einigen Beispielen wird der Satz an Sonar-Umgebungssensoren 410 (z. B. 410a–410i) um den Basiskörper 120 herum derart arrangiert, um nach oben zu zeigen (z. B. im Wesentlichen in der Richtung Z) und wahlweise nach außen weg von der Z-Achse geneigt, um damit einen Erkennungsbereich 412 um den Roboter 100 herum zu schaffen. Jeder Sonar-Umgebungssensor 410a–410i kann eine Blende oder Emissionsführung 414 umfassen, womit die Sonarausgabe nach oben oder zumindest nicht in Richtung der anderen Bereiche des Roboterkörpers 110 gelenkt wird (z. B. so dass die eigenen Bewegungen des Roboterkörpers 110 nicht erkannt werden). Die Ausgabeführung 414 kann eine Form einer Schale oder Halbschale haben. Bei dem gezeigten Beispiel erstreckt sich der Basiskörper 120 lateral über das Bein 130 hinweg und die Sonar-Umgebungssensoren 410 (z. B. 410a–410i) werden am Basiskörper 120 (z. B. im Wesentlichen entlang eines Umfangs des Basiskörpers 120) um das Bein 130 herum angebracht. Des Weiteren werden die nach oben zeigenden Sonar-Umgebungssensoren 410 derart versetzt, um einen fortdauernden oder im Wesentlichen fortdauernden Sonarerkennungsbereich 412 um das Bein 130 herum zu schaffen. Der Sonarerkennungsbereich 412 kann derart verwendet werden, damit Hindernisse mit erhöhten Vorsprüngen wie Tischplatten, Regale etc. erkannt werden.
Die nach oben zeigenden Sonar-Umgebungssensoren 410 sind in der Lage, Objekte, die sich hauptsächlich in der horizontalen Ebene befinden, wie etwa Tischplatten, zu erkennen. Diese Objekte können wegen ihrer Erstreckung von anderen Sensoren des Sensorsystems wie dem Laserscanner 440 oder den Abbildungssensoren 450 nicht erkannt werden, und das kann für den Roboter 100 problematisch sein. Die nach oben zeigenden Sonar-Umgebungssensoren 410, die um den Basiskörper 120 herum arrangiert sind, ermöglichen das Erkennen von diesen Arten von Objekten/Hindernissen. Des Weiteren können die Sonar-Umgebungssensoren 410 um die weitesten Punkte des Basisumfangs herum angebracht und leicht nach außen geneigt werden, so dass sie nicht vom Körper 140 oder Kopf 160 des Roboters 100 bedeckt oder behindert werden, und daher keine falschen Signale gegeben werden, indem Bereiche des Roboters 100 selbst erkannt werden. Bei manchen Implementierungen werden die Sonar-Umgebungssensoren 410 so arrangiert (nach oben und nach außen), um das Volumen des Körpers 140 außerhalb des Blickfeldes der Sonar-Umgebungssensoren 410 zu halten, damit sie für die Aufnahme von Nutzlast und Zubehör bereit sind, wie etwa der Korb 360. Die Sonar-Umgebungssensoren 410 können in den Basiskörper 124 eingelassen werden, damit sie visuell versteckt werden und keinen externen Bereich haben, mit dem sie sich festhaken oder gegen Hindernisse stoßen können.
Das Sensorsystem 400 kann einen oder mehrere Sonar-Umgebungssensoren 410 (z. B. einen hinteren Sonar-Umgebungssensor 410j) umfassen, die nach hinten gerichtet sind (z. B. im Gegensatz zu der Vorwärtsfahrtrichtung F), um Hindernisse bei der Rückwärtsfahrt zu erkennen. Der hintere Sonar-Umgebungssensor 410j kann eine Ausgabeführung 414 haben, um das Sonar-Erkennungsfeld 412 zu lenken. Des Weiteren kann der hintere Sonar-Umgebungssensor 410j zur Reichweitenerkennung verwendet werden, um eine Entfernung zwischen dem Roboter 100 und einem erkannten Objekt im Blickfeld des hinteren Sonar-Umgebungssensors 410j (z. B. als „Rückwärtsfahrt-Warnung”) verwendet werden. Bei einigen Beispielen ist der hintere Sonar-Umgebungssensor 410j vertieft im Basiskörper 120 montiert, so dass er keine visuelle oder funktionelle Unregelmäßigkeit des Gehäuses erzeugt.
Bezugnehmend auf 3 und 4B umfasst der Roboter 100 bei manchen Implementierungen auch Klippenumgebungssensoren 420, die in der Nähe der Antriebsräder 210a, 210b, 210c, angebracht sind, um eine Klippe zu erkennen, bevor die Antriebsräder 210a, 210b, 210c auf die Klippe (z. B. Treppe) treffen. Beispielsweise kann der Klippenumgebungssensor 420 sich auf oder in der Nähe von den radial am weitesten außen gelegenen Ecken 125a–c der Basiskörper 124a–c und auf Orten dazwischen befinden. Bei manchen Fällen wird ein Klippenerkennen durch Abtasten mit Infrarot oder der tatsächlichen Reichweite mittels Infrarotemitter 422 und einem Infraroterkennungssystem 424 durchgeführt, die zueinander geneigt sind, damit sie sich überlappende Ausgabe- und Erkennungsfelder haben, was eine Erkennungszone ergibt, und zwar an einem Ort, wo ein Boden angenommen wird. IR-Umgebungsabtasten kann ein relativ kleines Blickfeld aufweisen die Zuverlässigkeit kann von dem Rückstrahlvermögen der Oberfläche abhängen und kann je nach Oberfläche unterschiedliche Werte der Genauigkeit haben. Daher können mehrfache allein stehende Sensoren um den Umfang des Roboters 100 herum angebracht werden, um adäquat Klippen von verschiedenen Punkten auf dem Roboter 100 zu erkennen. Des Weiteren können IR-Umgebungssensoren typischerweise nicht zwischen einer Klippe und einem ungefährlichen Ereignis unterscheiden, wenn etwa der Roboter 100 gerade eine Schwelle erstiegen hat.
Die Klippenumgebungssensoren 420 können erkennen, wenn der Roboter 100 auf eine fallende Flanke auf dem Boden trifft, oder wenn er einer Treppe begegnet. Der Kontrollschaltkreis 500 (der ein Steuersystem ausführt) kann Verhaltensweisen ausführen, wodurch der Roboter 100 eine Handlung ausführen muss, wie etwa die Fahrtrichtung zu verändern, wenn eine Ecke erkannt wird. Bei manchen Implementierungen umfasst das Sensorsystem 400 einen oder mehrere sekundäre Klippenumgebungssensoren (z. B. andere Sensoren, die für ein Klippenabtasten und wahlweise andere Abtastarten konfiguriert sind). Die Klippenumgebungssensoren 420 können derart arrangiert sein, um eine Früherkennung einer Klippe durchzuführen, Daten zur Unterscheidung von tatsächlichen Klippen und ungefährlichen Ereignissen (wie das Steigen auf eine Schwelle) bereitzustellen, und unten und außen positioniert werden, so dass ihr Blickfeld mindestens einen Bereich des Roboterkörpers 110 und ein Gebiet weg vom Roboterkörper 110 abdeckt. Bei manchen Implementierungen führt der Kontrollschaltkreis 500 eine Klippenerkennungsroutine aus, die eine Ecke in der Arbeitsfläche (z. B. Boden), ein Erhöhen der Entfernung nach der Ecke auf der Arbeitsfläche und/oder eine Erhöhung der Entfernung zwischen dem Roboterkörper 110 und der Arbeitsfläche erkennt. Diese Implementierung erlaubt: 1) Früherkennung von möglichen Klippen (wodurch eine schnellere Bewegungsgeschwindigkeit in einer unbekannten Umwelt erlaubt ist), 2) erhöhte Zuverlässigkeit von autonomer Beweglichkeit, da der Kontrollschaltkreis 500 Klippenabbildungsinformationen von den Klippenumgebungssensoren 420 erhält, um zu wissen, ob die Klippe wirklich gefährlich ist oder ungefährlich überschritten werden kann (z. B. Ersteigen und Überqueren einer Schwelle); 3) eine Verringerung falscher Meldungen von Klippen (z. B. aufgrund einer Eckenerkennung gegenüber der mehrfachen unabhängigen IR-Umgebungssensoren mit einem engen Blickfeld). Zusätzliche Sensoren, die als Sensoren für „Radabfall” arrangiert sind, können für Redundanz und für das Erkennen von Situationen verwendet werden, wenn eine Kamera zur Abtastung der Reichweite eine bestimmte Art von Klippe nicht zuverlässig erkennen kann.
Mit einer Erkennung von Schwellen und Stufen kann der Roboter 100 effektiv planen, entweder eine überquerbare Schwelle zu überqueren oder eine Stufe zu vermeiden, die zu steil ist. Das kann auch so sein bei zufälligen Objekten auf der Arbeitsfläche, die der Roboter 100 gefahrlos überqueren kann oder nicht. Bei solchen Hindernissen oder Schwellen, die der Roboter 100 als solche erachtet, die er ersteigen kann, indem er die Höhenmaße kennt, kann der Roboter 100 sich entsprechend verlangsamen, falls notwendig, um einen problemlosen Übergang zu erleben, um die Problemlosigkeit zu maximieren und jegliche Instabilität aufgrund plötzlicher Beschleunigungen zu minimieren. Bei manchen Implementierungen basiert eine Erkennung von Schwellen und Stufen auf der Objekthöhe über der Arbeitsfläche zusammen mit geometrischer Erkennung (z. B. Unterscheiden zwischen einer Schwelle oder einem elektrischen Kabel oder einem unbestimmten Stïck wie etwa eine Socke). Schwellen können mittels Eckenerkennung erkannt werden. Der Kontrollschaltkreis 500 kann Abbildungsdaten von den Klippenumgebungssensoren 420 (oder anderen Abbildungssensoren auf dem Roboter 100) empfangen, eine Eckenerkennungsroutine ausführen und einen Fahrbefehl auf der Basis der Ergebnisse der Eckenerkennungsroutine abgeben. Der Kontrollschaltkreis 500 kann ebenfalls eine Mustererkennung zur Identifizierung von Objekten verwenden. Mit einer Erkennung von Schwellen kann der Roboter 100 seine Orientierung in Bezug auf die Schwelle ändern, um eine problemlose Stufenersteigungsfähigkeit zu maximieren.
Die Umgebungssensoren 410, 420 können allein eingesetzt werden, oder alternativ in Kombination mit einem oder mehreren Kontaktsensoren 430 (z. B. Bodenwellenumschalter) für Redundanz verwendet werden. Beispielsweise können ein oder mehrere Kontakt- oder Bodenwellensensoren 430 auf dem Roboterkörper 110 erkennen, ob der Roboter 100 physisch ein Hindernis antrifft. Derartige Sensoren verwenden eine physische Eigenschaft wie etwa Kapazität oder physischen Versatz innerhalb des Roboters 100, um festzustellen, wenn er ein Hindernis antrifft. Bei manchen Implementierungen hat jeder Basiskörperbereich 124a, 124b, 124c der Basis 120 einen entsprechenden Kontaktsensor 430 (z. B. kapazitiver Sensor, Reedschalter etc.), der Bewegung des entsprechenden Basiskörperbereichs 124a, 124b, 124c in Bezug auf das Basisfahrwerk 122 (vgl. z. B. 4A) erkennt. Beispielsweise kann sich der Basiskörperbereich 124a–c radial in Bezug auf die Z-Achse des Basisfahrwerks 122 bewegen, um damit eine 3-Wege-Bodenwellenerkennung zu schaffen.
Wieder bezugnehmend auf 1–4C, 11A und 11B umfasst das Sensorsystem 400 bei manchen Implementierungen einen Laserscanner 440, der auf einem vorderen Bereich des Roboterkörpers 110 montiert und in Kommunikation mit dem Kontrollschaltkreis 500 ist. Bei den gezeigten Beispielen ist der Laserscanner 440 auf dem Basiskörper 120 nach vorne sehend angebracht (z. B. mit einem Blickfeld in der Vorwärtsbewegungsrichtung F) auf oder über dem ersten Basiskörper 124a (z. B. um einen maximalen Abbildungsbereich entlang der Bewegungsrichtung F des Roboters zu erhalten). Des Weiteren bedeutet die Platzierung des Laserscanners auf oder in der Nähe der vorderen Spitze der dreieckigen Basis 120, dass der externe Winkel der Roboterbasis (z. B. 300 Grad) größer ist als das Blickfeld 442 des Laserscanners 440 (z. B. ~285 Grad), und daher kann die Basis 120 das Erkennungsfeld 442 des Laserscanners 440 nicht behindern oder versperren. Der Laserscanner 440 kann soweit wie möglich zurückversetzt im Basiskörper 124 montiert sein, ohne das Blickfeld zu versperren und damit keine Bereiche des Laserscanners aus dem Basiskörper 124 herausragen (z. B. für Ästhetik und das Minimieren der Möglichkeit, sich an Hindernissen festzuhaken).
Der Laserscanner 440 tastet einen Bereich um den Roboter 100 herum ab und der Kontrollschaltkreis 500 kreiert unter Verwendung der vom Laserscanner 440 empfangenen Signale eine Umweltlandkarte oder Objektkarte des abgetasteten Bereichs. Der Kontrollschaltkreis 500 kann die Objektkarte für die Navigation, Erkennung und Vermeidung von Hindernissen verwenden. Des Weiteren kann der Kontrollschaltkreis 500 die Sensoreneingaben von anderen Sensoren des Sensorsystems 400 zur Erstellung einer Objektkarte und/oder für die Navigation verwenden.
Bei einigen Beispielen ist der Laserscanner 440 ein abtastendes LIDAR, das einen Laser verwendet, der schnell den Bereich in einer Dimension als eine „Hauptabtastlinie” abtastet, sowie ein Flugzeit-Abbildungselement, das eine Phasenverschiebung oder ähnliche Technik verwendet, um jedem generierten Pixel auf der Linie eine Tiefe zuzuschreiben (Wiedergabe einer zweidimensionalen Tiefenlinie auf der Abtastebene). Um eine dreidimensionale Landkarte zu erstellen, kann LIDAR eine „Hilfsabtastung” in einer zweiten Richtung (beispielsweise durch Neigen des Scanners) durchführen. Diese mechanische Abtasttechnik kann durch Technologien wie etwa LIDAR/LADAR „Flash” und „Swiss Ranger” in Form von Fokalebenen-Abbildungssensoren ergänzt oder sogar ersetzt werden, also Techniken, die Halbleiterstapel verwenden, um Flugzeitberechnungen für eine volle 2-D-Matrix von Pixeln zu berechnen, um eine Tiefe für jeden Pixel bestimmen zu können, oder sogar eine Serie von Tiefen für jeden Pixel bestimmen zu können (mit einem kodierten Beleuchter oder Beleuchtungslaser).
Das Sensorsystem 400 kann einen oder mehr dreidimensionale Bildsensoren 450, die in Kommunikation mit dem Kontrollschaltkreis 500 stehen, umfassen. Wenn der 3-D-Bildsensor 450 ein beschränktes Blickfeld hat, kann der Kontrollschaltkreis 500 oder das Sensorsystem 400 den 3-D-Bildsensor 450a für ein Abtasten von einer Seite zur anderen Seite aktivieren, um eine relativ größeres Blickfeld zum Erkennen und Vermeiden von Hindernissen (ODOA) zu erhalten. Bezugnehmend auf 1–3 und 10B umfasst der Roboter 100 bei manchen Implementierungen einen abtastenden 3-D-Bildsensor 450a, der auf dem vorderen Bereich des Roboterkörpers 110 montiert ist und ein Blickfeld entlang der Vorwärtsbewegungsrichtung F hat (z. B. um einen maximalen Abbildungsbereich entlang der Fahrtrichtung F des Roboters zu erhalten). Der abtastende 3-D-Bildsensor 450a kann vornehmlich zum Erkennen und Vermeiden von Hindernissen (ODOA) verwendet werden. Bei dem gezeigten Beispiel ist der abtastende 3-D-Bildsensor 450a unterhalb der Schulter 142 auf der unteren Oberfläche 144 auf dem Körper 140 montiert und in den Körper 140 versenkt (z. B. gleich oder tiefer als die untere Oberfläche 144), wie in 3 gezeigt wird, um beispielsweise einen Kontakt des Benutzers mit dem abtastenden 3-D-Bildsensor 450a zu vermeiden. Der abtastende 3-D-Bildsensor 450 kann so arrangiert sein, dass er hauptsächlich nach unten und weg vom Roboterkörper 110 gerichtet ist, damit er ein Blickfeld 452 nach unten und vor dem Roboter 100 hat zum Erkennen und Vermeiden von Hindernissen (ODOA) (z. B. Blockierung durch die Basis 120 oder andere Bereiche des Roboterkörpers 110). Die Platzierung des abtastenden 3-D-Bildsensors 450a auf oder nahe an einem vorderen Rand des Körpers 140 ermöglicht, dass das Blickfeld des 3-D-Bildsensors 450 (z. B. ~285 Grad) kleiner als der externe Oberflächenwinkel des Körpers 140 (z. B. 300 Grad) in Bezug auf den 3-D-Bildsensor 450 ist, wodurch verhindert wird, dass der Körper 140 das Blickfeld 452 des abtastenden 3-D-Bildsensors 450a blockiert oder behindert. Des Weiteren kann der abtastende 3-D-Bildsensor 450a (und der damit verbundene Aktuator) so weit wie möglich im Körper 140 versenkt montiert werden, ohne das Blickfeld zu blockieren (z. B. für Ästhetik und das Minimieren der Möglichkeit, sich an Hindernissen festzuhaken). Die störende Abtastbewegung des abtastenden 3-D-Bildsensors 450a kann vom Benutzer nicht gesehen werden, was eine weniger störende Interaktion ermöglicht. Im Gegensatz zu einem herausragenden Sensor wird der versenkte abtastende 3-D-Bildsensor 450a keine unbeabsichtigte Interaktionen mit der Umwelt haben (gegen Personen oder Hindernisse fahren etc.), insbesondere wenn er sich bewegt oder beim Abtasten, da praktisch kein beweglicher Teil aus der Hülle des Körpers 140 hinausragt.
Bei manchen Implementierungen umfasst das Sensorsystem 400 weitere 3-D-Bildsensoren 450, die am Körper 120, am Bein 130, am Hals 150 und/oder am Kopf 160 angebracht sind. Bei dem Beispiel in 1 weist der Roboter 100 3-D-Bildsensoren 450 auf dem Basiskörper 120, dem Körper 140 und dem Kopf 160 auf. Bei dem Beispiel in 2 umfasst der Roboter 100 3-D-Bildsensoren 450 auf dem Basiskörper 120, dem Körper 140 und dem Kopf 160. Bei dem Beispiel in 11A umfasst der Roboter 100 3-D-Bildsensoren 450 am Bein 130, am Körper 140 und am Hals 150. Andere Konfigurationen sind auch möglich. Ein 3-D-Bildsensor 450 (z. B. am Hals 150 und über dem Kopf 160) kann für die Erkennung von Personen, Gesten, und/oder Videokonferenzen benützt werden, wobei ein anderer 3-D-Bildsensor 450 (z. B. an der Basis 120 und/oder am Bein 130) für die Navigation und/oder das Erkennen und Vermeiden von Hindernissen verwendet wird.
Ein auf dem Hals 150 und/oder dem Kopf 160 angeordneter, nach vorne gerichteter 3D-Bildsensor 450 kann für Personen-, Gesichts- und/oder Gestenerkennung von Personen um den Roboter 100 verwendet werden. Unter Verwendung von Signaleingaben vom 3D-Bildsensor 450 auf dem Kopf 160 kann die Steuerung 500 einen Benutzer erkennen, indem eine dreidimensionale Karte des angesehenen/aufgenommen Benutzergesichts erzeugt wird und die erzeugte dreidimensionale Karte mit bekannten 3D-Bildern von Gesichtern von Personen verglichen wird und eine Übereinstimmung mit einem der bekannten 3D-Gesichtsbilder bestimmt wird. Gesichtserkennung kann zur Bestätigung von Benutzern als zugelassene Benutzer des Roboters 100 verwendet werden. Ferner kann/können einer oder mehrere der 3D-Bildsensoren 450 verwendet werden, um Gesten einer im Sichtfeld des Roboters 100 befindlichen Person zu bestimmen und optional basierend auf der/den bestimmten Geste(n) (z. B. Zeigen mit der Hand, Winken und/oder Handsignale) zu reagieren. Zum Beispiel kann die Steuerung 500 als Reaktion auf ein erkanntes Zeigen mit der Hand in eine bestimmte Richtung einen Antriebsbefehl ausgeben.
Die 3D-Bildsensoren 450 können in der Lage sein, die folgenden Datentypen zu erzeugen: (i) eine Tiefenkarte, (ii) ein auf Reflexionsgraden basierendes Intensitätsbild und/oder (iii) ein reguläres Intensitätsbild. Die 3D-Bildsensoren 450 können derartige Daten durch Bildmusterzuordnung, Messen der Laufzeit und/oder Phasenverschiebung für von einer Quelle ausgestrahltes und von einem Ziel reflektiertes Licht erhalten.
In einigen Ausführungen verwendet Argumentation- oder Steuerungssoftware, die auf einem Prozessor (z. B. der Robotersteuerung 500) ausgeführt werden kann, eine Kombination an Algorithmen, die unter Verwendung von verschiedenen durch das Sensorsystem 400 erzeugte Datentypen ausgeführt wird. Die Argumentations-Software verarbeitet die vom Sensorsystem 400 gesammelten Daten und gibt Daten aus, um Navigationsentscheidungen darüber zu treffen, wohin sich der Roboter 100 bewegen kann, ohne zum Beispiel mit einem Hindernis zu kollidieren. Durch das Sammeln von Bildgebungsdaten der Umgebung des Roboters im Laufe der Zeit kann die Argumentation-Software im Gegenzug effektive Verfahren auf ausgewählte Segmente des erkannten Bilds/der erkannten Bilder anwenden, um Tiefenmessungen der 3D-Bildsensoren 450 zu verbessern. Dies kann das Verwenden von geeigneten temporären und räumlichen Durchschnittstechniken beinhalten.
Die Zuverlässigkeit des Ausführen von kollisionsfreien Bewegungen des Roboters kann auf Folgendem basieren: (i) einem Konfidenzniveau, das im Laufe der Zeit durch Argumentation auf hohem Niveau aufgebaut wurde und (ii) einem tiefenwahrnehmenden Sensor, der drei Hauptarten von Daten zur Analyse sammelt – (a) ein Tiefenbild, (b) ein aktives Beleuchtungsbild und (c) ein Umgebungsbeleuchtungsbild. Algorithmen mit drei verschiedenen Datentypen können auf jedem der durch den tiefenwahrnehmenden Bildgebungssensor 450 erhaltenen Bilder ausgeführt werden. Die Gesamtdaten können das Konfidenzniveau im Vergleich zu einem System, das nur einen Datentyp verwendet, verbessern.
Die 3D-Bildsensoren 450 können Bilder erfassen, die Tiefen- und Helligkeitsdaten von einer Szene um den Roboter 100 (z. B. einen Sensorsichtabschnitt eines Zimmers oder Arbeitsbereichs) enthalten, die ein oder mehrere Objekt(e) enthält. Die Steuerung 500 kann konfiguriert sein, um basierend auf dem aufgenommenen, reflektierten Licht von der Szene Belegungsdaten für das Objekt zu bestimmen. Ferner gibt die Steuerung 500 in einigen Beispielen einen wenigstens teilweise auf den Belegungsdaten basierenden Antriebsbefehl an das Antriebssystem 200 aus, um Hindernisse (d. h. das Objekt in der Szene) zu umfahren. Die 3D-Bildsensoren 450 können zur Echtzeit-Entscheidungsfindung durch die Steuerung 500 wiederholt Szenentiefenbilder aufnehmen, um den Roboter 100 durch die Szene zu navigieren, ohne dabei mit Objekten in der Szene zu kollidieren. Zum Beispiel kann die Geschwindigkeit oder Frequenz, mit der die Tiefenbilddaten von den 3D-Bildsensoren 450 erhalten werden, durch eine Verschlusszeit der 3D-Bildsensoren 450 gesteuert werden. Zudem kann die Steuerung 500 einen Ereignisauslöser (z. B. von einer anderen Sensorkomponente des Sensorsystems 400, wie den Näherungssensor 410, 420) empfangen, der die Steuerung 500 auf ein nahe gelegenes Objekt oder eine Gefahr hinweist. Die Steuerung 500 kann als Reaktion auf den Ereignisauslöser die 3D-Bildsensoren 450 veranlassen, eine Frequenz, mit der Tiefenbilder aufgenommen und Belegungsinformationen erhalten werden, zu erhöhen.
Mit Bezugnahme auf 12A beinhaltet der 3D-Bildgebungssensor 450 in einigen Ausführungen eine Lichtquelle 1172, die Licht auf eine Szene 10, wie den Bereich um den Roboter 100 (z. B. einen Raum), ausstrahlt. Der Bildgebungssensor 450 kann außerdem einen Bildgeber 1174 (z. B. ein Array an lichtempfindlichen Pixeln 1174p) beinhalten, der von der Szene 10 reflektiertes Licht aufnimmt, einschließlich reflektiertes Licht, das von der Lichtquelle 1172 ausgeht (z. B. als ein Szenentiefenbild). In einigen Beispielen beinhaltet der Bildgebungssensor 450 ein Lichtquellenobjektiv 1176 und/oder ein Detektorobjektiv 1178 zum Manipulieren (z. B. Speckling oder Fokussieren) des ausgestrahlten bzw. reflektierten Lichts. Die Robotersteuerung 500 oder eine Sensorsteuerung (nicht dargestellt), die mit der Robotersteuerung 500 in Kommunikation steht, empfängt Lichtsignale vom Bildgeber 1174 (z. B. die Pixel 1174p), um basierend auf Bildmusterzuordnung und/oder einer Laufzeiteigenschaft des reflektierten, durch den Bildgeber 1174 aufgenommenen Lichts Tiefeninformation für ein Objekt 12 in der Szene 10 zu bestimmen.
12B stellt eine beispielhafte Anordnung 1200 von Handlungen für den Betrieb des Bildgebungssensors 450 bereit. Mit zusätzlicher Bezugnahme auf 12A beinhalten die Handlungen das Ausstrahlen 1202 von Licht auf eine Szene 10 um den Roboter 100 und das Empfangen 1204 von Reflexionen des ausgestrahlten Lichts von der Szene 10 zu einem Bildgeber (z. B. einem Array an lichtempfindlichen Pixeln). Die Handlungen beinhalten ferner das Empfangen 1206 von Lichterfassungssignalen vom Bildgeber durch die Steuerung 500, das Erkennen 1208 eines oder mehrerer Merkmals/e eines Objekts 12 in der Szene 10 unter Verwendung von aus den Lichterfassungssignalen abgeleiteten Bilddaten und das Verfolgen 1210 einer Position des/der erkannten Merkmals/e des Objekts 12 in der Szene 10 unter Verwendung der von den Lichterfassungssignalen abgeleiteten Bildtiefendaten. Die Handlungen können das Wiederholen 1212 der Handlungen des Ausstrahlens 1202 von Licht, des Empfangen 1204 von Lichtreflexionen, des Empfangen 1206 von Lichterfassungssignalen, des Erfassens 1208 von Objektmerkmal(en) und des Verfolgens 1210 einer Position des/der Objektmerkmals/e beinhalten, um eine Auflösung der Bilddaten oder Bildtiefendaten zu erhöhen und/oder ein Konfidenzniveau bereitzustellen.
Die Wiederholungshandlung 1212 kann mit einer relativ langsamen Rate (z. B. einer langsameren Bildrate) für relativ hohe Auflösung, einer mittleren Rate oder einer hohen Rate mit einer relativ hohen Auflösung durchgeführt werden. Die Frequenz der Wiederholungshandlung 1212 kann von der Robotersteuerung 500 angepasst werden. In einigen Ausführungen kann die Steuerung 500 die Frequenz der Wiederholungshandlung 1212 nach Empfangen eines Ereignisauslösers anheben oder senken. Zum Beispiel kann ein erkannter Gegenstand in der Szene ein Ereignis auslösen, das eine erhöhte Frequenz der Wiederholungshandlung 1212 verursacht, um ein möglicherweise kurz bevorstehendes Objekt 12 (z. B. eine Tür, Schwelle oder Klippe) in der Szene 10 zu erkennen. In zusätzlichen Beispielen kann ein abgelaufenes Zeitereignis zwischen erfassten Objekten 12 veranlassen, dass die Frequenz der Wiederholungshandlung 1212 verlangsamt oder für eine Zeitspanne ausgesetzt wird (z. B. in den Ruhezustand schalten, bis sie von einem weiteren Ereignis aufgeweckt wird). In einigen Beispielen löst die Erfassungshandlung 1208 eines Merkmals oder mehrerer Merkmale eines Objekts 12 in der Szene 10 ein Merkmalserfassungsereignis aus, das eine im Verhältnis höhere Frequenz der Wiederholungshandlung 1212 zum Erhöhen der Rate, mit der Bildtiefendaten erhalten werden, auslöst. Eine im Verhältnis höhere Erfassungsrate von Bildtiefendaten kann eine verhältnismäßig zuverlässigere Merkmalsverfolgung in der Szene ermöglichen.
Die Handlungen beinhalten außerdem die Ausgabe 1214 von Navigationsdaten zum Umfahren des Objekts 12 in der Szene 10. In einigen Ausführungen verwendet die Steuerung 500 die ausgegebenen Navigationsdaten, um Antriebsbefehle an das Antriebssystem 200 auszugeben, um den Roboter 100 auf eine Weise zu bewegen, die eine Kollision mit dem Objekt 12 verhindert.
In einigen Ausführungen erfasst das Sensorsystem 400 mehrere Objekte 12 in der Szene 10 um den Roboter 100 und die Steuerung 500 verfolgt die Positionen jedes der erkannten Objekte 12. Die Steuerung 500 kann eine Belegungskarte der Objekte 12 in einem Bereich um den Roboter 100, wie dem begrenzten Bereich eines Raums, erstellen. Die Steuerung 500 kann die Bildtiefendaten des Sensorsystems 400 verwenden, um eine Szene 10 mit einem Abschnitt der Belegungskarte zu vergleichen und die Belegungskarte mit dem Standort verfolgter Objekte 12 zu aktualisieren.
Mit Bezugnahme auf 12C beinhaltet der 3D-Bildgebungssensor 450 in einigen Ausführungen eine dreidimensionale (3D) Specklekamera 1300, die eine Bildkartierung durch Speckledekorrelation ermöglicht. Die Specklekamera 1300 beinhaltet einen Speckleemitter 1310 (z. B. von infrarotem, ultraviolettem und/oder sichtbarem Licht), der ein Specklemuster in die Szene 10 (wie einen Zielbereich) ausstrahlt, und einen Bildgeber 1320, der Bilder vom Specklemuster auf den Oberflächen eines Objekts 12 in der Szene 10 aufnimmt.
Der Speckleemitter 1310 kann eine Lichtquelle 1312, wie einen Laser, beinhalten, die einen Lichtstrahl in einen Diffusor 1314 und auf einen Reflektor 1316 ausstrahlt, damit dieser als Specklemuster in die Szene 10 reflektiert und somit projiziert wird. Der Bildgeber 1320 kann objektive Optik 1322 beinhalten, die das Bild auf einen Bildsensor 1324 fokussiert, der ein Array an Lichtdetektoren 1326, wie einen CCD- oder CMOS-basierten Bildsensor aufweist. Wenngleich die optischen Achsen des Speckleemitters 1310 und des Bildgebers 1320 als kollinear dargestellt sind, wie zum Beispiel in einem Dekorrelationsmodus, können die optischen Achsen des Speckleemitters 1310 und des Bildgebers 1320 auch nicht kollinear sein, zum Beispiel wenn sie in einem Kreuzkorrelationsmodus sind, sodass eine Bildgebungsachse von einer Ausstrahlungsachse verschoben ist.
Der Speckleemitter 1310 strahlt ein Specklemuster in die Szene 10 aus und der Bildgeber 1320 nimmt Vergleichsbilder des Specklemusters in der Szene 10 in einem Bereich verschiedener Objektabstände Z_n vom Speckleemitter 1310 auf (wobei z. B. die Z-Achse durch die optische Achse des Bildgebers 1320 definiert sein kann). Im dargestellten Beispiel werden die Vergleichsbilder des projizierten Specklemusters in einer Folge von Ebenen mit verschiedenen jeweiligen Abständen vom Ausgangspunkt aufgenommen, wie an den fiduziellen Standorten, die mit Z₁, Z₂, Z₃ und so weiter gekennzeichnet sind. Der Abstand ΔZ zwischen den Vergleichsbildern kann in einem Grenzabstand (z. B. 5 mm) eingestellt oder durch die Steuerung 500 verstellbar (z. B. als Reaktion auf ausgelöste Ereignisse) sein. Die Specklekamera 1300 archiviert und katalogisiert die aufgenommenen Vergleichsbilder mit jeweiligen Ausstrahlungsabständen, um Dekorrelation des Specklemusters mit Abständen vom Speckleemitter 1310 zu ermöglichen, um Abstandmessungen für Objekte 12, die in aufeinanderfolgenden Bildern aufgenommen wurden, durchzuführen. Wenn angenommen wird, dass ΔZ grob dem Abstand zwischen angrenzenden fiduziellen Abständen Z₁, Z₂, Z₃, ... entspricht, kann das Specklemuster auf dem Objekt 12 an Standort Z_A zum Beispiel mit dem Vergleichsbild des an Z₂ aufgenommenen Specklemusters korreliert werden. Andererseits kann das Specklemuster auf dem Objekt 12 an Z_B zum Beispiel mit dem Vergleichsbild an Z₃ korreliert werden. Diese Korrelationsmessungen liefern den ungefähren Abstand des Objekts 12 vom Ausgangspunkt. Um das Objekt 12 in drei Dimensionen zu kartieren, kann die Specklekamera 1300 oder die Steuerung 500, die Informationen von der Specklekamera 1300 empfängt, lokale Kreuzkorrelation mit dem Vergleichsbild, das die größte Übereinstimmung gezeigt hat, verwenden.
Andere Einzelheiten und Merkmale von 3D-Bildkartierung anhand von Speckle-Ranging, zum Beispiel durch Specklekreuzkorrelation unter Verwendung von Triangulation oder Dekorrelation, die mit den hierin beschriebenen kombinierbar sind, finden sich in PCT-Patentanmeldung PCT/IL2006/000335 ; deren Inhalt hiermit in ihrer Gesamtheit durch Verweis eingeschlossen ist.
12D stellt eine beispielhafte Anordnung 1400 von Handlungen für den Betrieb der Specklekamera 1300 bereit. Die Handlungen beinhalten das Ausstrahlen 1402 eines Specklemusters in die Szene 10 und das Aufnehmen 1404 von Vergleichsbildern (z. B. eines Vergleichsobjekts 12) in verschiedenen Abständen vom Speckleemitter 1310. Die Handlungen beinhalten ferner das Ausstrahlen 1406 eines Specklemusters auf ein Zielobjekt 12 in der Szene 10 und das Aufnehmen 1408 von Zielbildern des Specklemusters auf dem Objekt 12. Die Handlungen beinhalten ferner das Vergleichen 1410 der Zielbilder (des gespeckelten Objekts) mit verschiedenen Vergleichsbildern, um ein Vergleichsmuster zu identifizieren, das am meisten mit dem Specklemuster auf dem Zielobjekt 12 übereinstimmt, und das Bestimmen 1412 eines geschätzten Abstandbereichs des Zielobjekts 12 in der Szene 10. Das kann das Bestimmen eines primären Specklemusters auf dem Objekt 12 und das Finden eines Vergleichsbildes mit einem Specklemuster, das am meisten mit dem primären Specklemuster auf dem Objekt 12 übereinstimmt, beinhalten. Der Abstandsbereich kann vom entsprechenden Abstand des Vergleichsbildes bestimmt werden.
Die Handlungen beinhalten optional das Erstellen 1414 einer 3D-Karte der Oberfläche des Objekts 12 durch lokale Kreuzkorrelation zwischen dem Specklemuster auf dem Objekt 12 und dem identifizierten Vergleichsmuster, um zum Beispiel einen Standort des Objekts 12 in der Szene zu bestimmen. Das kann das Bestimmen eines primären Specklemusters auf dem Objekt 12 und das Finden von jeweiligen Abweichungen zwischen dem primären Specklemuster auf verschiedenen Bereichen des Objekts 12 im Zielbild und dem primären Specklemuster im identifizierten Vergleichsbild beinhalten, um eine dreidimensionale (3D) Karte des Objekts abzuleiten. Die Verwendung von Festkörperkomponenten für die 3D-Kartierung einer Szene stellt eine relativ kostengünstige Lösung für Roboternavigationssysteme bereit.
Typischerweise sind wenigstens einige der verschiedenen jeweiligen Abstände axial durch mehr als eine axiale Länge des primären Specklemusters in den jeweiligen Abständen getrennt. Das Vergleichen des Zielbildes mit den Vergleichsbildern kann das Errechnen einer jeweiligen Kreuzkorrelation zwischen dem Zielbild und jedem der wenigstens einigen Vergleichsbilder und das Auswählen des Vergleichsbildes mit der größten jeweiligen Kreuzkorrelation mit dem Zielbild beinhalten.
Die Handlungen können das Wiederholen 1416 der Handlungen 1402–1412 oder der Handlungen 1406–1412 und optional der Handlung 1414 (z. B. kontinuierlich) beinhalten, um die Bewegung des Objekts 12 in der Szene 10 zu verfolgen. Zum Beispiel kann die Specklekamera 1300 zum Vergleich mit den Vergleichsbildern eine Folge von Zielbildern aufnehmen, während sich das Objekt 12 bewegt.
Andere Einzelheiten und Merkmale von 3D-Bildkartierung anhand von Speckle-Ranging, die mit den hierin beschriebenen kombinierbar sind, finden sich in US-Patent 7,433,024 ; US-Patentanmeldung Nr. 2008/0106746, mit dem Titel „Depth-varying light fields for three dimensional sensing”; US-Patentanmeldung Nr. 2010/0118123, mit dem Titel „Depth Mapping Using Projected Patterns”; US-Patentanmeldung Nr. 2010/0034457, mit dem Titel „Modeling Of Humanoid Forms From Depth Maps”; US-Patentanmeldung Nr. 2010/0020078, mit dem Titel „Depth Mapping Using Multi-Beam Illumination”; US-Patentanmeldung Nr. 2009/0185274, mit dem Titel „Optical Designs For Zero Order Reduction”; US-Patentanmeldung Nr. 2009/0096783, mit dem Titel „Three-Dimensional Sensing Using Speckle Patterns”; US-Patentanmeldung 2008/0240502, mit dem Titel „Depth Mapping Using Projected Patterns”; und US-Patentanmeldung Nr. 2008/0106746, mit dem Titel „Depth-Varying Light Fields For Three Dimensional Sensing”; deren Inhalte hiermit in ihrer Gesamtheit durch Verweis hierin eingeschlossen sind.
Mit Bezugnahme auf 12E beinhaltet der 3D-Bildgebungssensor 450 in einigen Ausführungen eine 3D-Laufzeitkamera 1500 zum Aufnehmen von Tiefenbilddaten. Die 3D-Laufzeitkamera 1500 beinhaltet eine Lichtquelle 1510, einen komplementären Metalloxid-Halbleitersensor (engl.: Complementary Metal Oxide Semiconductor, CMOS) 1520 (oder ein ladungsgekoppeltes Gerät, engl.: Charge-Coupled Device (CCD)), ein Objektiv 1530 und eine Steuerungslogik oder eine Kamerasteuerung 1540 mit Verarbeitungsressourcen (und/oder der Robotersteuerung 500), die mit der Lichtquelle 1510 und dem CMOS-Sensor 1520 in Kommunikation stehen. Die Lichtquelle 1510 kann ein Laser oder eine lichtemittierende Diode (LED) mit einer Intensität, die durch ein periodisches Signal mit hoher Frequenz moduliert wird, sein. In einigen Beispielen beinhaltet die Lichtquelle 1510 ein fokussierendes Objektiv 1512. Der CMOS-Sensor 1520 kann ein Array an Pixeldetektoren 1522 oder andere Anordnungen an Pixeldetektoren 1522 beinhalten, wobei jeder Pixeldetektor 1522 die Intensität und Phase von auf ihn auftreffender photonischer Energie erfassen kann. In einigen Beispielen weist jeder Pixeldetektor 1522 eine zweckbestimmte Detektorschaltung 1524 zum Verarbeiten der Erfassungsladungsausgabe des zugehörigen Pixeldetektors 1522 auf. Das Objektiv 1530 fokussiert das von einer Szene 10, die ein oder mehrere Objekt(e) 12 von Interesse enthält, reflektierte Licht auf den CMOS-Sensor 1520. Die Kamerasteuerung 1540 stellt eine Handlungssequenz bereit, die vom CMOS-Sensor 1520 erhaltene Pixeldaten in eine Tiefenkarte und ein Helligkeitsbild formatiert. In einigen Beispielen beinhaltet die 3D-Laufzeitkamera 1500 außerdem Eingaben/Ausgaben (IO) 1550 (die z. B. mit der Robotersteuerung 500 in Kommunikation stehen), einen Speicher 1560 und/oder eine Uhr 1570, die mit der Kamerasteuerung 1540 und/oder den Pixeldetektoren 1522 (z. B. der Detektorschaltung 1524) in Kommunikation steht.
12F stellt eine beispielhafte Anordnung 1600f von Handlung für den Betrieb der 3D-Laufzeitkamera 1500 bereit. Die Handlungen beinhalten das Ausstrahlen 1602 eines Lichtimpulses (z. B. von infrarotem, ultraviolettem und/oder sichtbarem Licht) in die Szene 10 und Messen 1604f einer Laufzeit des Lichtimpulses (z. B. durch Zählen der Uhrimpluse der Uhr 1570). Die Handlungen beinhalten das Empfangen 1606f von Reflexionen des ausgestrahlten Lichts von einer oder mehreren Oberfläche(n) eines Objekts 12 in der Szene 10. Die Reflexionen können von Oberflächen des Objekts 12 zurückgeworfen werden, die in verschiedenen Abständen Z_n von der Lichtquelle 1510 liegen. Die Reflexionen werden durch das Objektiv 1530 und auf Pixeldetektoren 1522 des CMOS-Sensors 1520 empfangen. Die Handlungen beinhalten das Empfangen 1608f der Laufzeit für jede Lichtimpulsreflexion, die auf jedem zugehörigen Pixeldetektor 1522 des CMOS-Sensors 1520 empfangen wird. Während der Laufzeit der Hin- und Rückreise eines Lichtimpulses addiert ein Zähler der Detektorschaltung 1523 jedes jeweiligen Pixeldetektors 1522 Uhrenimpulse. Eine größere Anzahl an addierten Uhrenimpulsen steht für eine längere Laufzeit und demnach einen größeren Abstand zwischen einem Lichtreflexionspunkt auf dem dargestellten Objekt 12 und der Lichtquelle 1510. Die Handlungen beinhalten ferner das Bestimmen 1610f eines Abstands zwischen der reflektierenden Oberfläche des Objekts 12 für jede empfangene Lichtimpulsreflexion und optional das Konstruieren 1612f einer dreidimensionalen Objektoberfläche. In einigen Ausführungen beinhalten die Handlungen das Wiederholen 1614f der Handlungen 1602f–1610f und optional 1612f zum Nachverfolgen der Bewegung des Objekts 12 in der Szene 10.
Andere Einzelheiten und Merkmale von 3D-Laufzeitbildgebung, die mit den hierin beschriebenen kombinierbar sind, finden sich in US-Patent Nr. 6,323,942 mit dem Titel „CMOS Compatible 3-D Image Sensor”; US-Patent Nr. 6,515,740 mit dem Titel „Methods for CMOS-Compatible Three-Dimensional Image Sensing Using Quantum Efficiency Modulation”; und PCT-Patentanmeldung PCT/US02/16621 mit dem Titel „Method and System to Enhance Dynamic Range Conversion Usable with CMOS Three-Dimensional Imaging”, deren Inhalte hiermit in ihrer Gesamtheit durch Verweis hierin eingeschlossen sind.
In einigen Ausführungen stellt der 3D-Bildgebungssensor 450 drei Arten von Informationen bereit: (1) Tiefeninformationen (z. B. von jedem Pixeldetektor 1522 des CMOS-Sensors 1520 zu einem entsprechenden Standort auf der Szene 12); (2) Umgebungslichtintensität an jedem Pixeldetektorstandort; und (3) die aktive Beleuchtungsintensität an jedem Pixeldetektorstandort. Durch die Tiefeninformationen kann die Position des erkannten Objekts 12 im Laufe der Zeit verfolgt werden, insbesondere im Verhältnis zu der Nähe des Objekts zum Standort des Robotereinsatzes. Die aktive Beleuchtungsintensität und Umgebungslichtintensität sind verschiedene Arten von Helligkeitsbildern. Die aktive Beleuchtungsintensität wird durch Reflexionen eines aktiven Lichts (wie durch die Lichtquelle 1510 bereitgestellt), das vom Zielobjekt 12 reflektiert wird, aufgenommen. Das Umgebungslichtbild zeigt vom Zielobjekt 12 reflektiertes Umgebungslicht. Die zwei Bilder stellen zusammen zusätzliche Robustheit bereit, insbesondere wenn die Beleuchtungsbedingungen schlecht sind (z. B. zu dunkle oder übermäßige Umgebungsbeleuchtung).
Bildsegmentierungs- und Klassifizierungsalgorithmen können verwendet werden, um die Position von Objekten 12 in der Szene 10 zu klassifizieren und zu erfassen. Von diesen Algorithmen bereitgestellte Informationen sowie die durch den Bildgebungssensor 450 erhaltenen Abstandsmessungsinformationen können von der Robotersteuerung 500 oder anderen Verarbeitungsressourcen verwendet werden. Der Bildgebungssensor 450 kann mit dem Laufzeitprinzip arbeiten und insbesondere mit erkennbaren Phasenverschiebungen in einem modulierten Lichtmuster, das von der Szene 10 reflektiert wird, einschließlich Techniken zum Modulieren der Sensibilität von Photodioden für das Filtern von Umgebungslicht.
Der Roboter 100 kann den Bildsensor 450 zu den folgenden Zwecken einsetzen: 1) Mapping, Ortsbestimmung und Navigation; 2) Objektfeststellung und Objektvermeidung (ODOA); 3) Objektsuche (z. B. Finden einer Person); 4) Gestenerkennung (z. B. für Begleitroboter); 5) Menschen- und Gesichtserkennung, 6) Personenortung; 7) Überwachung der Handhabung von Objekten vonseiten des Roboters 100 und andere geeignete Anwendungen für den autonomen Betrieb des Roboters 100.
In manchen Ausführungen kann mindestens einer der 3D-Bildsensoren 450 ein Aufnahmegerät volumetrischer Punktwolken (wie eine Speckle- oder Laufzeitkamera) sein, das am Roboter 100 in einer Höhe von mehr als 30,5 oder 61 cm (1 oder 2 Fuß) über dem Boden angeordnet und so ausgerichtet ist, dass es eine Punktwolke aus einem Raumvolumen erfassen kann, einschließlich einer Bodenfläche in einer Bewegungsrichtung des Roboters (mittels des omnidirektionalen Antriebssystems 200). In den in 1 und 3 gezeigten Beispielen kann der erste 3D-Bildsensor 450a auf dem Fuß 120 in einer Höhe von mehr als 30,5 oder 61 cm (1 oder 2 Fuß) über dem Boden (oder in einer Höhe von ungefähr 30,5 oder 61 cm (1 oder 2 Fuß) über dem Boden) angeordnet und entlang der Fahrtrichtung F nach vorne gerichtet sein, um während der Fahrt Bilder (z. B. volumetrische Punktwolke) eines Volumens einschließlich des Bodens zu erfassen (z. B. zum Erkennen und Vermeiden von Hindernissen). Der zweite 3D-Bildsensor 450b ist in einer Anordnung am Kopf 160 gezeigt (z. B. in einer Höhe von mehr als 91,5 oder 122 cm (3 oder 4 Fuß über dem Boden), so dass er in der Lage ist, Punktwolken zur Skeletterkennung und -definition aus einem Raumvolumen neben dem Roboter 100 zu erfassen. Der Kontrollschaltkreis 500 kann Skelett-/Digitalerkennungssoftware ausführen, um Daten von den erfassten volumetrischen Punktwolken zu analysieren.
Es kann wichtig sein, Objekte 12 mithilfe des Bildsensors 450 trotz der Umgebungslichtbedingungen richtig wahrzunehmen. In vielen Umgebungen umfassen die Lichtbedingungen einen weiten Bereich von direktem Sonnenlicht über helle Leuchtstoffbeleuchtung bis zu schwach beleuchteten Schatten und können zu großen Schwankungen in der Oberflächenstruktur und dem allgemeinen Reflexionsgrad von Objekten 12 führen. Die Beleuchtung kann innerhalb eines gegebenen Standorts und auch von Szene 10 zu Szene 10 variieren. In manchen Ausführungen kann der Bildsensor 450 dazu verwendet werden, Personen und Objekte 12 in allen Situationen mit relativ wenig Einfluss der Umgebungslichtbedingungen (z. B. Umgebungslichtablehnung) zu erkennen und aufzulösen.
In manchen Ausführungen liegt die VGA-Auflösung des Bildsensors 450 bei 640 horizontalen mal 480 vertikalen Pixeln, jedoch sind auch andere Auflösungen möglich, wie 320 × 240 (z. B. für Nahbereichssensoren).
Der Bildsensor 450 kann einen Pulslaser und eine Kamerablende als Bandbreitenfilter im Zeitbereich umfassen, um nur Objekte 12 in einem spezifischen Bereich anzuschauen. Eine veränderliche Blende des Bildsensors 450 kann verwendet werden, um Objekte 12 in unterschiedlichen Entfernungen festzustellen. Darüber hinaus kann ein Pulslaser mit höherer Leistung für Anwendungen im Freien verwendet werden.
In manchen Ausführungen umfasst der Roboter einen Sonarscanner 460 zur akustischen Bildgebung eines den Roboter 100 umgebenden Bereichs. In den in 1 und 3 gezeigten Beispielen ist der Sonarscanner 460 auf einem nach vorne gerichteten Teil des Fußkörpers 120 angeordnet.
Bezugnehmend auf 1, 3B und 11B verwendet der Roboter 100 in einigen Ausführungen den Laserscanner oder Laserentfernungsmesser 440 zur redundanten Abtastung, sowie einen nach hinten gerichteten Sonar-Annäherungssensor 410j zur Sicherheit, die beide parallel zum Boden G ausgerichtet sind. Der Roboter 100 kann erste und zweite 3D-Bildsensoren 450a, 450b (Tiefenkameras) umfassen, um eine robuste Abtastung der Umgebung um den Roboter 100 bereitzustellen. Der erste 3D-Bildsensor 450a ist am Torso 140 befestigt und mit einem festen Winkel nach unten auf den Boden G gerichtet. Durch den Winkel des ersten 3D-Bildsensors 450a nach unten empfängt der Roboter 100 dichte Sensorabdeckung in einem Bereich direkt vor oder neben dem Roboter 100, die für die kurzfristige Fortbewegung des Roboters 100 nach vorne relevant ist. Der nach hinten gerichtete Sonar 410j stellt Objekte fest, wenn sich der Roboter nach hinten bewegt. Wenn die Fortbewegung nach hinten für den Roboter 100 typisch ist, kann der Roboter 100 einen dritten 3D-Bildsensor 450 umfassen, der nach unten und hinten gerichtet ist, um in einem Bereich direkt hinter oder neben dem Roboter 100 dichte Sensorabdeckung bereitzustellen.
Der zweite 3D-Bildsensor 450b ist am Kopf 160 angeordnet, der mittels des Nackens 150 schwenken und abkippen kann. Der zweite 3D-Bildsensor 450b kann zum remoten Fahren verwendet werden, da er dem menschlichen Bediener ermöglicht zu sehen, wohin sich der Roboter 100 fortbewegt. Der Nacken 150 ermöglicht dem Bediener, den zweiten 3D-Bildsensor 450b abzukippen und/oder zu schwenken, um sowohl nahe als auch entfernte Objekte sehen zu können. Schwenken des zweiten 3D-Bildsensors 450b vergrößert ein zugehöriges horizontales Sichtfeld. Bei schneller Fortbewegung kann der Roboter 100 den zweiten 3D-Bildsensor 450b leicht nach unten abkippen, um ein gesamtes oder kombiniertes Sichtfeld von beiden 3D-Bildsensoren 450a, 450b zu vergrößern und dem Roboter 100 genügend Zeit zu erlauben, ein Hindernis zu vermeiden (da bei höheren Geschwindigkeiten die Reaktionszeit auf Hindernisse im Allgemeinen geringer ist). Bei langsameren Geschwindigkeiten kann der Roboter 100 den zweiten 3D-Bildsensor 450b nach oben oder im Wesentlichen parallel zum Boden G kippen, um eine Person zu orten, der der Roboter 100 folgen soll. Darüber hinaus kann der Roboter 100 bei relativ langsamen Geschwindigkeiten den zweiten 3D-Bildsensor 450b schwenken, um dessen Sichtfeld um den Roboter 100 zu vergrößern. Der erste 3D-Bildsensor 450a kann fixiert bleiben (z. B. im Verhältnis zum Fuß 120 nicht bewegt werden), wenn sich der Roboter fortbewegt, um den Wahrnehmungsbereich des Roboters zu erweitern.
In manchen Ausführungen kann mindestens einer der 3D-Bildsensoren 450 ein Aufnahmegerät volumetrischer Punktwolken (wie eine Speckle- oder Laufzeitkamera) sein, das am Roboter 100 in einer Höhe von mehr als 30,5 oder 61 cm (1 oder 2 Fuß) über dem Boden (oder einer Höhe von ungefähr 30,5 oder 61 cm (1 oder 2 Fuß) über dem Boden) angeordnet und so ausgerichtet ist, dass es eine Punktwolke aus einem Raumvolumen erfassen kann, einschließlich einer Bodenfläche in einer Bewegungsrichtung des Roboters (mittels des omnidirektionalen Antriebssystems 200). In den in 1 und 3 gezeigten Beispielen kann der erste 3D-Bildsensor 450a auf dem Fuß 120 in einer Höhe von mehr als 30,5 oder 61 cm (1 oder 2 Fuß) über dem Boden angeordnet und entlang der Fahrtrichtung F nach vorne gerichtet sein, um während der Fahrt Bilder (z. B. volumetrische Punktwolke) eines Volumens einschließlich des Bodens zu erfassen (z. B. zum Erkennen und Vermeiden von Hindernissen). Der zweite 3D-Bildsensor 450b ist in einer Anordnung am Kopf 160 gezeigt (z. B. in einer Höhe von mehr als 91,5 oder 122 cm (3 oder 4 Fuß über dem Boden), so dass er in der Lage ist, Punktwolken zur Skeletterkennung und -definition aus einem Raumvolumen neben dem Roboter 100 zu erfassen. Der Kontrollschaltkreis 500 kann Skelett-/Digitalerkennungssoftware ausführen, um Daten von den erfassten volumetrischen Punktwolken zu analysieren.
Noch einmal bezugnehmend auf 2 und 4A–4C kann das Sensorsystem 400 eine inertiale Messeinheit (IMU) 470 in Verbindung mit dem Kontrollschaltkreis 500 umfassen, um ein Trägheitsmoment des Roboters 100 in Bezug auf den allgemeinen Schwerpunkt CG_R des Roboters 100 zu messen und zu überwachen.
Der Kontrollschaltkreis 500 kann im Feedback von der IMU 470 alle Abweichungen von einem Schwellensignal überwachen, das einem normalen lastenfreien Betrieb entspricht. Wenn sich der Roboter beispielsweise aus der aufrechten Position zu neigen beginnt, kann er am Nacken „gefangen” oder auf andere Weise behindert sein, oder es wurde plötzlich eine schwere Traglast hinzugefügt. In diesen Fällen kann es notwendig sein, sofort zu handeln (einschließlich, jedoch ohne Einschränkung, Ausweichmanöver, Neukalibrierung und/oder Ausgeben eines hörbaren/sichtbaren Warnsignals), um den sicheren Betrieb des Roboters 100 zu gewährleisten.
Da der Roboter 100 in menschlichen Umgebungen eingesetzt werden kann, kann er mit Menschen interagieren und in Bereichen betrieben werden, die für Menschen vorgesehen sind (ohne Berücksichtigung der Einschränkungen des Roboters). Der Roboter 100 kann seine Fahrtgeschwindigkeit und Beschleunigung einschränken, wenn er sich in überfüllten, beengten oder hochdynamischen Umgebungen befindet, beispielsweise auf einer Cocktail-Party oder in einem geschäftigen Krankenhaus. Es kann jedoch Situationen geben, in denen der Roboter 100 gefahrlos relativ schnell fahren kann, wie beispielsweise in einem langen leeren Gang, jedoch in der Lage sein muss, plötzlich abzubremsen, wenn sein Bewegungspfad z. B. von etwas gekreuzt wird.
Beim Beschleunigen aus dem Halten kann der Kontrollschaltkreis 500 ein Trägheitsmoment des Roboters 100 von seinem allgemeinen Schwerpunkt CG_R berücksichtigen, um das Umkippen des Roboters zu verhindern. Der Kontrollschaltkreis 500 kann ein Modell seiner Haltung verwenden, einschließlich des aktuellen Trägheitsmoments. Werden Traglasten unterstützt, kann der Kontrollschaltkreis 500 eine Lastwirkung auf den allgemeinen Schwerpunkt CG_R messen und die Bewegung des Trägheitsmoments des Roboters überwachen. Beispielsweise können der Torso 140 und/oder der Nacken 150 Belastungsmesser umfassen, um die Belastung zu messen. Ist dies nicht möglich, kann der Kontrollschaltkreis 500 einen Test-Drehmomentbefehl auf die Antriebsräder 210 ausüben und anhand der IMU 470 die tatsächliche Linear- und Winkelbeschleunigung des Roboters messen, um experimentell sichere Grenzwerte festzustellen.
Während eines plötzlichen Abbremsen wird eine befohlene Last auf das zweite und dritte Antriebsrad 210b, 210c (die Hinterräder) herabgesetzt, während das erste Antriebsrad 210a (das Vorderrad) in Fahrtrichtung nach vorne gleitet und den Roboter 100 unterstützt. Ist die Last auf das zweite und dritte Antriebsrad 210b, 210c (die Hinterräder) asymmetrisch, kann der Roboter 100 vom Kurs abweichen, wodurch die dynamische Stabilität reduziert wird. Die IMU 470 (z. B. ein Gyroskop) kann dazu verwendet werden, diese Abweichung festzustellen und dem zweiten und dritten Antriebsrad 210b, 210c zu befehlen, den Roboter 100 wieder auszurichten.
Bezugnehmend auf 3–4C und 6A umfasst der Roboter 100 in einigen Ausführungen mehrere Antennen. In den gezeigten Beispielen umfasst der Roboter 100 eine erste Antenne 490a und eine zweite Antenne 490b, die beide am Fuß 120 angeordnet sind (obwohl die Antennen an einem beliebigen anderen Teil des Roboters 100, z. B. dem Bein 130, dem Torso 140 dem Nacken 150 und/oder dem Kopf 160 angeordnet sein können). Der Einsatz mehrerer Antennen gewährleistet robuste(n) Signalempfang und -übertragung. Die Verwendung mehrerer Antennen stattet den Roboter 100 mit Multiple Input Multiple Output oder MIMO aus, nämlich der Verwendung mehrerer Antennen für einen Transmitter und/oder einen Empfänger, um die Kommunikationsleistung zu verbessern. MIMO bietet einen signifikanten Anstieg im Datendurchsatz und Verbindungsbereich ohne zusätzliche Bandbreite oder Übertragungsleistung. Dies wird durch die höhere spektrale Effizienz (mehr Bits pro Sekunde pro Hertz Bandbreite) und Verbindungszuverlässigkeit oder -vielfalt erzielt (weniger Fading). Aufgrund dieser Eigenschaften ist MIMO ein wichtiger Teil moderner drahtloser Kommunikationsnormen wie IEEE 802.11n (Wifi), 4G, 3GPP Long Term Evolution, WiMAX und HSPA+. Darüber hinaus kann der Roboter 100 als Wi-Fi-Brücke, Hub oder Hotspot für andere nahegelegene elektronische Geräte dienen. Die Mobilität und Verwendung vom MIMO des Roboters 100 kann den Roboter zu einer relativ zuverlässigen Wi-Fi-Brücke machen.
MIMO kann in drei Hauptkategorien unterteilt werden, Vorkodierung, Raummultiplexing oder Spatial Multiplexing (SM) und Diversitätscodierung. Vorkodierung ist eine Art des Multistream-Beamformings und gilt als vollständig räumliche Verarbeitung, die am Transmitter stattfindet. Beim (einschichtigen) Beamforming wird von jeder Sendeantenne das gleiche Signal mit der geeigneten Phasen-(und manchmal Verstärkungs-)Gewichtung ausgesendet, so dass die Signalstärke am Empfängereingang maximiert ist. Die Vorteile des Beamformings sind eine höhere empfangene Signalverstärkung, indem von verschiedenen Antennen ausgegebene Signale konstruktiv aufaddiert werden, und ein reduzierter mehrpfadiger Fadingeffekt. Ohne Zerstreuung kann Beamforming zu einem gut definierten gerichteten Muster (ihren. Wenn der Empfänger über mehrere Antennen verfügt, kann das Sende-Beamforming die Signalstärke nicht gleichzeitig an allen Empfangsantennen maximieren und es kann eine Vorkodierung mit mehreren Strömen verwendet werden. Vorkodierung kann Kenntnis des Kanalzustands (CSI) am Transmitter erfordern.
Raummultiplexing erfordert eine MIMO-Antennenkonfiguration. Beim Raummultiplexing wird ein hochratiges Signal in mehrere niedrigratige Ströme aufgeteilt und jeder Strom wird von einer verschiedenen Sendeantenne im gleichen Frequenzkanal gesendet. Kommen diese Signale mit ausreichend unterschiedlichen räumlichen Signaturen an der Empfängerantennengruppe an, kann der Empfänger diese Ströme in (fast) parallele Kanäle trennen. Raummultiplexing ist eine sehr leistungsstarke Methode zur Steigerung der Kanalkapazität bei höheren Signal-Rausch-Verhältnissen (SNR). Die Höchstzahl der räumlichen Ströme ist durch die jeweils kleinere Antennenzahl am Transmitter oder Empfänger begrenzt. Raummultiplexing kann mit oder ohne Sendekanalkenntnis verwendet werden. Raummultiplexing kann auch zum gleichzeitigen Senden an mehrere Empfänger verwendet werden, bekannt als Raummultiplex-Vielfachzugriff. Durch das Terminieren von Empfängern mit unterschiedlichen räumlichen Signaturen kann gute Trennbarkeit gewährleistet werden.
Diversitätscodierungsmethoden können verwendet werden, wenn am Transmitter keine Kanalkenntnis besteht. Bei Diversitätsverfahren wird ein einziger Strom gesendet (ungleich den mehreren Strömen beim Raummultiplexing), das Signal wird jedoch anhand von Methoden codiert, die Raum-Zeit-Codierung genannt werden. Das Signal wird von jeder Sendeantenne mit vollständig oder annähernd orthogonaler Codierung gesendet. Diversitätscodierung nutzt das unabhängige Fading bei Mehrantennenverbindungen zur Erhöhung der Signaldiversität. Da keine Kanalkenntnis vorhanden ist, bewirkt die Diversitätscodierung kein Beamforming und keinen Gruppengewinn. Raummultiplexing kann, wenn der Kanal am Transmitter bekannt ist, auch mit Vorkodierung oder, wenn eine Beeinträchtigung der Decodierzuverlässigkeit möglich ist, mit Diversitätscodierung kombiniert werden.
In manchen Ausführungen beinhaltet der Roboter 100 eine dritte Antenne 490c und/oder eine vierte Antenne 490d und jeweils den Torso 140 und/oder den Kopf 160 (siehe z. B. 3). In solchen Fällen kann der Kontrollschaltkreis 500 eine Antennenanordnung bestimmen (z. B. durch das Bewegen der Antennen 490a–d, wie durch das Heben oder Senken des Torsos 140 und/oder Drehen und/oder Abkippen des Kopfs 160), die eine Schwellensignalstärke für robuste Kommunikation erzielt. Beispielsweise kann der Kontrollschaltkreis 500 einen Befehl ausgeben, die dritte und vierte Antenne 490c, 490d zu heben, indem die Höhe des Torsos 140 angehoben wird. Darüber hinaus kann der Kontrollschaltkreis 500 einen Befehl ausgeben, den Kopf 160 zu drehen und/oder um ferner die vierte Antenne 490d im Verhältnis zu den anderen Antennen 490a–c auszurichten.
Bezugnehmend auf 13 führt der Kontrollschaltkreis 500 in manchen Ausführungen ein Kontrollsystem 510 aus, das ein Kontrollarbitrationssystem 510a und ein Verhaltenssystem 510b umfasst, die miteinander in Verbindung stehen. Das Kontrollarbitrationssystem 510a ermöglicht das dynamische Hinzufügen und Entfernen von Anwendungen 520 zu oder vom Kontrollsystem 510 und erleichtert es, jeder Anwendungen 520 zu erlauben, den Roboters 100 zu steuern ohne dass eine Kenntnis über die anderen Anwendungen 520 erforderlich ist. Mit anderen Worten bietet das Kontrollarbitrationssystem 510a einen einfachen priorisierten Kontrollmechanismus zwischen den Anwendungen 520 und den Ressourcen 530 des Roboters 100. Die Ressourcen 530 können das Antriebssystem 200, das Sensorsystem 400 und/oder beliebige Traglasten oder steuerbare Geräte umfassen, die mit dem Kontrollschaltkreis 500 in Verbindung stehen.
Die Anwendungen 520 können im Speicher des Roboters 100 gespeichert oder an diesen kommuniziert werden, um gleichzeitig auf dem Roboter 100 ausgeführt zu werden (z. B. einem Prozessor) und gleichzeitig dazu diesen zu steuern. Die Anwendungen 520 können Zugriff auf Verhaltensmuster 600 des Verhaltenssystems 510b haben. Die unabhängig eingesetzten Anwendungen 520 werden beim Betrieb dynamisch kombiniert und nutzen gemeinsam die Roboterressourcen 530 (z. B. Antriebssystem 200, Arm(e), Kopf (Köpfe) usw.) des Roboters 100. Eine Low-Level-Regel ist zur dynamischen gemeinsamen Nutzung der Roboterressourcen 530 durch die Anwendungen 520 beim Betrieb eingerichtet. Diese Regel bestimmt, welche Anwendung 520 die Roboterressourcen 530 steuern kann, die von dieser Anwendung 520 benötigt werden (z. B. eine Prioritätshierarchie unter den Anwendungen 520). Die Anwendungen 520 können dynamisch beginnen und enden und werden völlig unabhängig voneinander ausgeführt. Das Kontrollsystem 510 ermöglicht auch komplexe Verhaltensmuster 600, die miteinander kombiniert werden können, um einander zu helfen.
Das Kontrollarbitrationssystem 510a umfasst einen oder mehrere Ressourcen-Kontrollschaltkreis(e) 540, einen Robotermanager 550 und einen oder mehrere Kontrollarbiter 560. Diese Komponenten benötigen keinen gemeinsamen Prozess oder Computer und müssen in keiner bestimmten Reihenfolge gestartet werden. Die Ressourcen-Kontrollschaltkreiskomponente 540 stellt den Anwendungen 520 eine Schnittstelle mit dem Kontrollarbitrationssystem 510a zur Verfügung. Für jede Anwendung 520 ist eine Instanzierung dieser Komponente vorhanden. Der Ressourcen-Kontrollschaltkreis 540 zieht die Komplexitäten der Authentifizierung, verteilten Ressourcenkontrollarbiter, Befehlspuffer und dergleichen ab und verkapselt sie. Der Robotermanager 550 koordiniert die Prioritätensetzung von Anwendungen 520, indem er steuert, welche Anwendung 520 zu einem beliebigen Zeitpunkt die exklusive Kontrolle über eine der Roboterressourcen 530 hat. Da dies der zentrale Informationskoordinator ist, gibt es nur eine Instanzierung des Robotermanagers 550 pro Roboter. Der Robotermanager 550 richtet eine Prioritätsregel ein, die eine lineare priorisierte Reihenfolge der Ressourcen-Kontrollschaltkreise 540 aufweist und die Ressourcen-Kontrollarbiter 560, die die Hardwaresteuerung bereitstellen, nachverfolgt. Der Kontrollarbiter 560 empfängt die Befehle von jeder Anwendung 520 und erstellt aufgrund der Anwendungsprioritäten einen einzigen Befehl und gibt diesen für die ihm zugeordneten Ressourcen 530 weiter. Der Kontrollarbiter 560 empfängt von den ihm zugeordneten Ressourcen 530 auch Feedback über deren Zustand und sendet es zurück an die Anwendungen 520. Die Roboterressourcen 530 können ein Netzwerk von Funktionsmodulen (z. B. Aktoren, Antriebssysteme und Gruppen davon) mit einem oder mehreren Hardware-Kontrollschaltkreis(en) sein. Die Befehle des Kontrollarbiters 560 sind spezifisch für die Ressource 530 um spezifische Handlungen durchzuführen.
Ein Dynamikmodel 570, das auf dem Kontrollschaltkreis 500 ausgeführt werden kann, kann so konfiguriert sein, dass es den Schwerpunkt (CG), Trägheitsmomente und Kreuzprodukte der Trägheit verschiedener Teile des Roboters 100 berechnet, um den aktuellen Zustand des Roboters zu beurteilen. Das Dynamikmodell 570 kann auch die Formen, das Gewicht und/oder die Trägheitsmomente dieser Komponenten modellieren. In manchen Beispielen kommuniziert das Dynamikmodell 570 mit der inertialen Messeinheit 470 (IMU) oder Teilen einer solchen (z. B. Akzelerometern und/oder Gyroskopen), die am Roboter 100 angeordnet sind und in Verbindung mit dem Kontrollschaltkreis 500 stehen, um die verschiedenen Schwerpunkte des Roboters 100 zu berechnen. Das Dynamikmodell 570 kann vom Kontrollschaltkreis 500 zusammen mit anderen Programmen 520 oder Verhaltensmustern 600 dazu verwendet werden, Einsatzgrenzen des Roboters 100 und seiner Komponenten festzustellen.
Jede Anwendung 520 weist eine Handlungsselektionsmaschine 580 und einen Ressourcen-Kontrollschaltkreis 540, eine oder mehrere mit der Handlungsselektionsmaschine 580 verbundene Verhaltensmuster 600 und ein oder mehrere mit der Handlungsselektionsmaschine 580 verbundene Handlungsmodell(e) 590 auf. Das Verhaltenssystem 510b stellt Predictive Modelling bereit und bewirkt, dass die Verhaltensmuster 600 gemeinschaftlich über die Handlungen des Roboters entscheiden, indem mögliche Ergebnisse der Roboterhandlungen beurteilt werden. In manchen Beispielen ist ein Verhaltensmuster 600 eine Plugin-Komponente, die eine hierarchische, zustandsbehaftete Beurteilungsfunktion bereitstellt, die Sensor-Feedback von mehreren Quellen mit apriorischen Grenzen und Informationen in ein Beurteilungs-Feedback über die zulässigen Handlungen des Roboters verbindet. Da die Verhaltensmuster 600 ansteckbar an die Anwendung 520 sind (sich z. B. in oder außerhalb der Anwendung 520 befinden), können sie entfernt und hinzugefügt werden ohne die Anwendung 520 oder andere Teile des Kontrollsystems 510 ändern zu müssen. Jedes Verhaltensmuster 600 ist eine eigenständige Regel. Um Verhaltensmuster 600 leistungsstärker zu machen, kann die Ausgabe mehrerer Verhaltensmuster 600 zusammen in die Eingabe eines anderen eingefügt werden, so dass komplexe Kombinationsfunktionen entstehen können. Die Verhaltensmuster 600 sollen handhabbare Teile der Gesamtzuständigkeit der Roboters 100 umsetzen.
Die Handlungsselektionsmaschine 580 ist das koordinierende Element des Kontrollsystems 510 und führt einen schnellen, optimierten Selektionszyklus (Vorhersage/Korrektur-Zyklus) auf der Suche nach der besten Handlung unter Berücksichtigung der Eingaben aller Verhaltensmuster 600 aus. Die Handlungsselektionsmaschine 580 weist drei Phasen auf: Aufstellung, Handlungsselektionssuche und Ausführung. In der Aufstellungsphase wird jedes Verhaltensmuster 600 davon unterrichtet, dass der Handlungsselektionszyklus begonnen hat, und mit der Zyklusstartzeit, dem aktuellen Zustand und Grenzen des Aktorraums des Roboters beliefert. Aufgrund interner Regeln oder externer Eingaben entscheidet jedes Verhaltensmuster 600 ob es an diesem Handlungsselektionszyklus teilnehmen möchte. Während dieser Phase wird eine Liste aktiver Verhaltensmusterstammfunktionen erstellt, deren Eingabe die Selektion der Befehle beeinflusst, die auf dem Roboter 100 ausgeführt werden.
In der Handlungsselektions-Suchphase erstellt die Handlungsselektionsmaschine 580 mögliche Ergebnisse aus dem Raum verfügbarer Handlungen, der auch Handlungsraum genannt wird. Die Handlungsselektionsmaschine 580 verwendet Handlungsmodelle 590, um ein Pool möglicher Befehle (innerhalb von Grenzen) und aufgrund der Handlungssimulation für jeden Befehl an unterschiedlichen Zeitschritten mit einem Zeithorizont in der Zukunft entsprechende Ergebnisse bereitzustellen. Die Handlungsselektionsmaschine 580 berechnet ein bevorzugtes Ergebnis aufgrund der Ergebnisbeurteilungen der Verhaltensmuster 600 und sendet den entsprechenden Befehl an das Kontrollarbitrationssystem 510a und benachrichtigt das Handlungsmodell 590 des gewählten Befehls als Feedback.
In der Ausführungsphase werden die Befehle, die einem gemeinschaftlich am besten beurteilten Ergebnis entsprechen, miteinander zu einem allgemeinen Befehl kombiniert, der dem Ressourcen-Kontrollschaltkreis 540 zur Durchführung an den Roboterressourcen 530 bereitgestellt wird. Das beste Ergebnis wird den aktiven Verhaltensmustern 600 als Feedback bereitgestellt, um in zukünftigen Beurteilungszyklen verwendet werden zu können.
Empfangene Sensorsignale vom Sensorsystem 400 können Interaktionen mit einem oder mehreren Verhaltensmuster(n) 600 zur Durchführung von Handlungen verursachen. Beispielsweise wählt der Kontrollschaltkreis 500 unter Verwendung des Kontrollsystems 510 eine Handlung (oder Bewegungsbefehl) für jede Roboterkomponente (z. B. Motor oder Aktor) aus einem entsprechenden Handlungsraum (z. B. Sammlung möglicher Handlungen oder Bewegungen für diese bestimmte Komponente), um eine koordinierte Bewegung jeder Roboterkomponente auf effiziente Weise zu bewirken, die Kollisionen mit sich selbst und allen Objekten in der Umgebung des Roboters 100 vermeidet, deren sich der Roboter 100 gewahr ist. Der Kontrollschaltkreis 500 kann über ein Roboternetzwerk, wie ein EtherIO-Netzwerk wie in US-Serien-Nr. 61/305,069, eingereicht am 16. Februar 2010, dessen gesamter Inhalt hiermit durch Bezugnahme hierin aufgenommen wird, einen koordinierten Befehl ausgeben.
Das Kontrollsystem 510 kann adaptive Geschwindigkeit/Beschleunigung des Antriebssystems 200 (z. B. über ein oder mehrere Verhaltensmuster 600) bereitstellen, um die Stabilität des Roboters 100 in unterschiedlichen Konfigurationen/Positionen zu maximieren, wenn sich der Roboter 100 in einem Bereich bewegt.
In manchen Ausführungen gibt der Kontrollschaltkreis 500 Befehle an das Antriebssystem 200, das den Roboter 100 gemäß einer Kurseinstellung und einer Geschwindigkeitseinstellung antreibt. Ein oder Verhaltensmuster 600 können Signale verwenden, die vom Sensorsystem 400 empfangen werden, um vorhergesagte Ergebnisse möglicher Befehle zu beurteilen, von denen eines zur Ausführung gewählt werden kann (allein oder in Kombination mit anderen Befehlen als allgemeiner Roboterbefehl), um Hindernisse zu berücksichtigen. Beispielsweise können Signale von den Annäherungssensoren 410 das Kontrollsystem 510 veranlassen, die befohlene Geschwindigkeit oder den befohlenen Kurs des Roboters 100 zu ändern. Zum Beispiel kann ein Signal von einem Annäherungssensor 410 aufgrund einer nahen Wand dazu führen, dass das Kontrollsystem 510 einen Befehl zum Abbremsen gibt. In einem anderen Fall kann ein Kollisionssignal vom/von den Kontaktsensor(en) aufgrund eines Zusammenstoßes mit einem Stuhl das Kontrollsystem 510 veranlassen, einen Befehl zur Kursänderung zu geben. In anderen Fällen wird die Geschwindigkeitseinstellung des Roboters 100 als Reaktion auf den Kontaktsensor eventuell nicht reduziert und/oder die Kurseinstellung des Roboters 100 wird als Reaktion auf den Annäherungssensor 410 eventuell nicht geändert.
Das Verhaltenssystem 510b kann ein Geschwindigkeitsverhalten 600 beinhalten (z. B. eine Verhaltensroutine, die auf einem Prozessor ausgeführt werden kann), das so konfiguriert ist, dass es die Geschwindigkeitseinstellung des Roboters 100 abpasst, und ein Kursverhaltensmuster 600, das so konfiguriert ist, dass es die Kurseinstellung des Roboters 100 ändert. Die Geschwindigkeits- und Kursverhaltensmuster 600 können so konfiguriert sein, dass sie gleichzeitig und unabhängig voneinander ausgeführt werden. Beispielsweise kann das Geschwindigkeitsverhaltensmuster 600 so konfiguriert sein, dass es einen der Sensoren (z. B. den Satz/die Sätze Annäherungssensoren 410, 420) abfragt, und das Kursverhaltensmuster 600 kann so konfiguriert sein, dass es einen anderen Sensor (z. B. den kinetischen Stoßsensor) abfragt.
Bezugnehmend auf 13 und 14 kann das Verhaltenssystem 510b ein Teleoperationsverhalten durch Torsoberührung 600a (z. B. eine Verhaltensroutine, die auf einem Prozessor ausgeführt werden kann) beinhalten, das so konfiguriert ist, dass es auf die Berührung des Torsos 140 durch einen Benutzer 15 zur Teleoperation (z. B. Führen des Roboters 100) reagiert. Das Teleoperationsverhalten durch Torsoberührung 600a kann aktiv werden, wenn das Sensorsystem 400 feststellt, dass der Torso mindestens einen Schwellenzeitraum lang (z. B. 0,25 Sekunden) Kontakt empfing (z. B. menschlichen Kontakt). Beispielsweise können der Bewegungs- und/oder Kontaktsensor 147t, 147b, 147f, 147r, 147r, 147l in Verbindung mit dem Kontrollschaltkreis 500 und entsprechend der Deckplatte 145t, einer Bodenplatte 145b einer Frontplatte 145f, einer Rückplatte 145b, einer rechten Platte 145r und einer linken Platte 154l des Torsokörpers 145 zugeordnet, Bewegung und/oder Kontakt mit der jeweiligen Platte feststellen, wie in 6B und 6C gezeigt. Nach der Aktivierung empfängt das Teleoperationsverhalten durch Torsoberührung 600a eine Kontaktkraftrichtung (wie sie z. B. von einer Ellipsenposition der Berührung wahrgenommen und berechnet wird) und gibt einen Geschwindigkeitsbefehl an das Antriebssystem 200 in örtlichen X/Y-Koordinaten (wobei die holonome Mobilität genutzt wird). Die Verhaltensmuster Hindernisfeststellung und Hindernisvermeidung können eine Zeit lang abgeschaltet werden, während das Teleoperationsverhalten durch Torsoberührung 600a aktiv ist. Wenn sich die wahrgenommene Berührungsstelle, -kraft oder -richtung ändert, ändert das Teleoperationsverhalten durch Torsoberührung 600a den Geschwindigkeitsbefehl entsprechend der wahrgenommenen Kontaktkraftrichtung. Das Teleoperationsverhalten durch Torsoberührung 600a kann eine Stopp-Routine ausführen, wenn das Sensorsystem 400 über einen Schwellenzeitraum (z. B. 2 Sekunden) keinen Kontakt mehr mit dem Roboter 100 wahrnimmt. Die Stopp-Routine kann nach ungefähr 0,5 Sekunden das Anhalten des Antriebssystems 200 bewirken, wenn das Sensorsystem 400 keinen Kontakt mehr mit dem Roboter 100 (z. B. mit dem Torso 140) wahrnimmt. Das Teleoperationsverhalten durch Torsoberührung 600a kann eine Verzögerung beim Anhalten des Roboters 100 bereitstellen, um eine Änderung des Berührungspunkts zu ermöglichen ohne auf eine Auslösezeit warten zu müssen.
Das Teleoperationsverhalten durch Torsoberührung 600a kann unterstützte Antriebsbefehle an das Antriebssystem 200 geben, die es dem Benutzer ermöglichen, den Roboter 100 zu schieben, während Antriebsunterstützung vom Antriebssystem 200 empfangen wird (z. B. partielle Geschwindigkeitsbefehle, die den Roboter 100 allein nicht bewegen können, das Bewegen des Roboters 100 durch den Benutzer jedoch unterstützen).
Das Teleoperationsverhalten durch Torsoberührung 600a kann Sensorsignale vom Berührungssensorsystem 480 (z. B. Knöpfen, kapazitiven Sensoren, Kontaktsensoren usw.) empfangen, von denen ein Teil am Torso 140 (und an anderen Stellen des Roboters 100, wie z. B. am Kopf 160) angeordnet sein kann. Das Teleoperationsverhalten durch Torsoberührung 600a kann den Torso 140 in einer Höhe H_T von zwischen 91,5 und 152,5 cm (3 und 5 Fuß) vom Boden G positionieren, um mindestens einen Teil des Berührungssensorsystems 480 in einer für den typischen Benutzer zugänglichen Höhe anzuordnen.
In manchen Ausführungen erkennt das Teleoperationsverhalten durch Torsoberührung 600a Benutzerberührung, um den Roboter 100 zu platzieren und in eine bestimmte Haltung zu bringen. Drückt der Benutzer 15 beispielsweise auf den Torso 140 nach unten, stellt das Sensorsystem 400 die Kraft auf den Torso 140 nach unten fest und sendet entsprechende Signale an den Kontrollschaltkreis 500. Das Teleoperationsverhalten durch Torsoberührung 600a empfängt Anzeichen für die Kraft auf den Torso nach unten 140 und veranlasst das Kontrollsystem 510 zur Ausgabe eines Befehls, durch den die Länge H_L des Beins 130 reduziert und somit die Höhe des Torsos 140 H_T vermindert wird. Ähnlich empfängt, wenn der Benutzer 15 den Torso nach oben drückt/zieht, das Teleoperationsverhalten durch Torsoberührung 600a vom Sensorsystem 400 Anzeichen für die Kraft auf den Torso 140 nach oben und veranlasst das Kontrollsystem 510 zur Ausgabe eines Befehls, durch den die Länge H_L des Beins 130 ausgedehnt und somit die Höhe des Torsos 140 H_T vergrößert wird.
Wenn der Benutzer 15 den Kopf 160 drückt, zieht und/oder dreht, kann das Teleoperationsverhalten durch Torsoberührung 600a vom Sensorsystem 400 (z. B. von Belastungsmessern/Bewegungs-/Kontaktsensoren 165 am Nacken 150) Anzeichen für die Benutzerhandlung empfangen und kann als Reaktion veranlassen, dass das Kontrollsystem 510 einen Befehl gibt, den Kopf 160 entsprechend zu bewegen und die Haltung danach beizubehalten.
In manchen Ausführungen bietet der Roboter 100 der Handhabung des Roboters 100 durch den Benutzer passiven Widerstand und/oder aktive Unterstützung. Beispielsweise bieten die Motoren 138b, 152, 154, die das Bein 130 und den Nacken 150 betätigen, der Handhabung des Roboters 100 durch den Benutzer passiven Widerstand und/oder aktive Unterstützung, um dem Benutzer der Handhabung Feedback sowie Unterstützung beim Bewegen relativ schwerer Komponenten wie dem Heben des Torsos 140 bereitzustellen. Auf diese Weise kann der Benutzer verschiedene Roboterkomponenten bewegen ohne das Gesamtgewicht der entsprechenden Komponenten tragen zu müssen.
Das Verhaltenssystem 510b kann ein Antipp-Wahrnehmungsverhalten 600 (z. B. eine Verhaltensroutine, die auf einem Prozessor ausgeführt werden kann) umfassen, das so konfiguriert ist, dass es die Aufmerksamkeit des Roboters 100 auf den Benutzer richtet. Das Antipp-Wahrnehmungsverhalten 600b kann aktiv werden, wenn das Sensorsystem 400 feststellt, dass der Torso 140 (oder ein anderer Teil des Roboters 100) weniger als einen Schwellenzeitraum lang (z. B. 0,25 Sekunden) Kontakt empfing (z. B. menschlichen Kontakt). Darüber hinaus kann das Antipp-Wahrnehmungsverhalten 600b nur dann aktiv werden, wenn das Teleoperationsverhalten durch Torsoberührung 600a nicht aktiv ist. Beispielsweise löst eine wahrgenommene Berührung am Torso 140 von 0,2 Sekunden nicht das Teleoperationsverhalten durch Torsoberührung 600a sondern das Antipp-Wahrnehmungsverhalten 600b aus. Das Antipp-Wahrnehmungsverhalten 600b kann eine Kontaktstelle am Torso 140 einsetzen und ein Abkippen und/oder Schwenken des Kopfes 160 bewirken (über Betätigung des Nackens 150), um den Benutzer anzuschauen. Ein Stopp-Kriterium für das Verhaltensmuster 600b kann erreicht werden, wenn der Kopf 160 eine Position erreicht, in der er in die Richtung der Berührungsstelle schaut.
In manchen Ausführungen umfasst das Verhaltenssystem 510b ein Antipp-Stoppverhalten 600c (z. B. eine Verhaltensroutine, die auf einem Prozessor ausgeführt werden kann), das so konfiguriert ist, dass es das Antreiben des Antriebssystem 200 stoppt (z. B. den Roboter 100 zum Halten bringt). Das Antipp-Stoppverhalten 600c kann aktiv werden, wenn das Sensorsystem 400 feststellt, dass der Torso 140 Kontakt (z. B. menschlichen Kontakt) empfing, und gibt einen Nullgeschwindigkeitsbefehl an das Antriebssystem 200, der alle vorherigen Antriebsbefehle aufhebt. Wenn der Roboter fährt und der Benutzer ihn anhalten möchte, kann der Benutzer den Torso 140 (oder einen anderen Teil des Roboters 100) oder einen Berührungssensor antippen. In manchen Beispielen kann das Antipp-Stoppverhalten 600c nur aktiviert werden, wenn Verhaltensmuster mit höherer Priorität, wie z. B. das Teleoperationsverhalten durch Torsoberührung 600a und das Antipp-Wahrnehmungsverhalten 600b nicht aktiviert sind. Das Antipp-Stoppverhalten 600c kann enden, wenn das Sensorsystem 400 keine Berührung mehr am Torso 140 (oder an einer anderen Stelle des Roboters 100) feststellt.
In manchen Ausführungen umfasst der Roboter 100 eine vermittelnde Sicherheitsvorrichtung 350 (9), die auch als Brücke bezeichnet wird, um die Kommunikation zwischen einem Webpad 310 und dem Kontrollschaltkreis 500 (und/oder anderen Komponenten des Roboters 100) zu ermöglichen. Beispielsweise kann die Brücke 350 Kommunikationen des Webpads 310 von einem Webpad-Kommunikationsprotokoll an ein Roboter-Kommunikationsprotokoll (z. B. Ethernet mit Gigabit-Kapazität) umwandeln. Die Brücke 350 kann das Webpad 310 authentisieren und Kommunikationsumwandlung zwischen dem Webpad 310 und dem Kontrollschaltkreis 500 bereitstellen. In manchen Beispielen umfasst die Brücke 350 einen Autorisation-Chip 352, der allen Kommunikationsverkehr zwischen dem Webpad 310 und dem Roboter 100 autorisiert/validiert. Die Brücke 350 kann den Kontrollschaltkreis 500 benachrichtigen, wenn sie ein autorisiertes Webpad 310 geprüft hat, das versucht, mit dem Roboter 100 zu kommunizieren. Darüber hinaus kann die Brücke 350 das Webpad 310 nach der Autorisierung von der Autorisierung der Kommunikation benachrichtigen. Die Brücke 350 kann am Nacken 150 oder Kopf (wie in 2 und 3 gezeigt) oder an einer anderen Stelle des Roboters 100 angebracht sein.
Das Session Initiation Protocol (SIP) ist ein IETF-definiertes Signalisierungsprotokoll, das häufig zur Steuerung von Multimedia-Kommunikationssitzungen wie Audio- oder Video-Anrufen über ein Internetprotokoll (IP) verwendet wird. Das Protokoll kann zum Erstellen, Ändern und Beenden von Sitzungen mit zwei Parteien (Unicast) oder mehreren Parteien (Multicast) verwendet werden, einschließlich eines oder mehrerer Medienstreams. Die Änderung kann das Ändern von Adressen oder Ports, das Einladen von mehr Teilnehmern und das Hinzufügen oder Löschen von Medienstreams umfassen. Andere mögliche Anwendungsbeispiele umfassen Videokonferenzen, die Verbreitung von Streaming-Multimedien, Instant Messaging, Anwesenheitsinformationen, Dateitransfer usw. Voice over Internet Protocol (Voice over IP, VoIP) ist Teil einer Familie von Methodologien, Kommunikationsprotokollen und Übertragungstechniken zur Lieferung von Sprachkommunikationen und Multimediensitzungen über Internet Protocol(IP)-Netzwerke, wie dem Internet. Andere häufig vorkommende und oft synonym mit VoIP verwendete Begriffe sind IP-Telefonie, Internet-Telefonie, Voice over Broadband (VoBB), Breitbandtelefonie und Breitbandtelefon.
15 zeig ein Telefonie-Beispiel, das Interaktion mit der Brücke 350 zur Einleitung und Durchführung von Kommunikation durch den Roboter 100 umfasst. Ein SIP von Telefon A tätigt einen Anruf mit dem SIP-Anwendungsserver. Der SIP aktiviert eine Wählfunktion des VoIP, wodurch ein HTTP-Post-Request an einen VoIP-Webserver gesendet wird. Der HTTP-Post-Request kann sich wie eine Rückruffunktion verhalten. Die SIP-Anwendung sendet ein Rufzeichen an Telefon A, wodurch angezeigt wird, dass der Anruf eingeleitet wurde. Ein VoIP-Server leitet einen Anruf über ein PSTN an eine Rückrufnummer ein, die im HTTP-Post-Request enthalten ist. Die Rückrufnummer endet an einem SIP DID-Provider, der so konfiguriert ist, dass er Anrufe zurück an den SIP-Anwendungsserver leitet. Der SIP-Anwendungsserver paart einen eingehenden Anruf mit dem ursprünglichen Anruf von Telefon A und beantwortet beide Anrufe mit einer OK-Antwort. Zwischen dem Telefon A und dem SIP DID-Provider ist eine Mediensitzung hergestellt. Das Telefon A hört u. U. ein vom VoIP erzeugtes künstliches Rufzeichen. Nachdem das VoIP bestätigt hat, dass der Rückruf beantwortet wurde, leitet es den PSTN-Anruf an den Bestimmungsort, wie den Roboter 100 (über die Brücke 350), ein. Der Roboter 100 beantwortet den Anruf und der VoIP-Server schaltet die Brücke von den Medien vom SIP DID-Provider zu den Medien vom Roboter 100.
16A–16D zeigen schematische Ansichten beispielhafter Robotersystemarchitekturen 1600, 1600a–d, die den Roboter 100 (oder einen Teil davon, wie z. B. den Kontrollschaltkreis 500 oder das Antriebssystem 200), eine Rechnervorrichtung 310 (abnehmbar oder fest am Kopf 160 angebracht), eine Cloud 1620 (zum Cloud-Computing) und ein Portal 1630 umfassen.
Der Roboter 100 kann verschiedene Roboterkernfunktionen bereitstellen, die Folgendes umfassen können: Mobilität (z. B. das Antriebssystem 200), ein zuverlässiges, sicheres Roboterintelligenzsystem, wie einen Kontrollsystem 510 (13), das auf dem Kontrollschaltkreis 500 ausgeführt wird, die Stromquelle 105, das Sensorsystem 400 und optional Handhabung mithilfe eines Manipulators, der mit dem Kontrollschaltkreis 500 in Verbindung steht. Das Kontrollsystem 510 kann Kurs- und Geschwindigkeitssteuerung, Körperhaltungssteuerung, Navigation und Roboterkernanwendungen bereitstellen. Das Sensorsystem 400 kann Sicht (z. B. über eine Kamera 320), Tiefenkartenbildgebung (z. B. über einen 3D-Bildsensor 450), Kollisionserkennung, Hinderniserkennung und Hindernisvermeidung und/oder Trägheitsmessung (z. B. über eine inertiale Messeinheit 470) bereitstellen.
Die Rechnervorrichtung 310 kann ein Tablet-Computer, ein tragbares elektronisches Gerät wie ein Telefon oder ein Personal Digital Assistant oder ein Dumb-Tablet oder Display (z. B. ein Tablet, das als Bildschirm für einen Atom-Scale-PC im Roboterkörper 110 dient) sein. In manchen Beispielen kann der Tablet-Computer einen Tastbildschirm zur Anzeige einer Benutzerschnittstelle und zum Empfangen von Eingaben durch den Benutzer aufweisen. Die Rechnervorrichtung 310 kann eine oder mehrere Roboteranwendungen 1610 ausführen, die Software-Anwendungen (z. B. im Speicher gespeichert und auf einem Prozessor ausführbar) zur Sicherheit, Medizin-Compliance, Telepräsenz, zum Verhaltenscoaching, Sozialen Networking, Alarm aktivieren, Home-Management usw. beinhalten. Die Rechnervorrichtung 310 kann Kommunikationsfunktionen (z. B. sichere drahtlose Konnektivität und/oder Mobilkommunikation), verbesserte Anwendungsentwicklungstools, Spracherkennung und Personen- oder Objekterkennungsfunktionen bereitstellen. Die Rechnervorrichtung 310 verwendet in manchen Beispielen ein Betriebssystem mit Interaktion/COMS-Qualifikation, wie Android von Google, Inc., iPadOS von Apple, Inc., andere Smartphone-Betriebssysteme oder spezialisierte Roboterbetriebssysteme wie RSS A2.
Die Cloud 1620 stellt Cloud-Computing und/oder Cloud-Speicherfunktionen bereit. Cloud-Computing kann internetbasiertes Computing bereitstellen, wobei gemeinsam genutzte Server Computer und anderen Geräten auf Abruf Ressourcen, Software und Daten bereitstellen. Beispielsweise kann die Cloud 1620 ein Cloud-Computing-Service sein, der mindestens ein Server-Computing-Gerät umfasst, das eine Service-Abstraktionsschicht und einen Hypertext Transfer Protocol Wrapper über einer virtuellen Maschine beinhalten kann, die darauf instanziiert ist. Die Server-Rechnervorrichtung kann so konfiguriert sein, dass sie HTTP-Requests parst und HTTP-Antworten sendet. Cloud-Computing kann eine Technologie sein, die das Internet und zentrale remote Server verwendet, um Daten und Anwendungen aufrechtzuerhalten. Cloud-Computing kann Benutzern den Zugriff und die Verwendung von Anwendungen 1610 ermöglichen, ohne dass persönliche Dateien auf einem Computer mit Internetzugang installiert und abgerufen werden müssen. Cloud-Computing ermöglicht ein relativ effizienteres Computing, indem Speicherung, Abspeichern, Verarbeitung und Bandbreite zentralisiert werden. Die Cloud 1620 kann skalierbare Computingleistung auf Abruf, Abspeicherung und Bandbreite bereitstellen, während die Anforderungen an die Roboterhardware reduziert werden (z. B. durch das Freistellen von CPU- und Speichernutzung). Roboterkonnektivität mit der Cloud 1620 ermöglicht die automatische Datensammlung vom Roboterbetrieb und Nutzungsverläufen, ohne dass der Roboter 100 zu einer Basisstation zurückkehren muss. Darüber hinaus kann das Sammeln von Daten über einen Zeitraum reichhaltige Daten ergeben, die zum Marketing sowie zur Produktentwicklung und für den Support ausgewertet werden können.
Der Cloud-Speicher 1622 kann ein Modell für vernetzte Computerdatenspeicherung sein, wobei die Daten auf mehreren virtuellen Servern gespeichert werden, die gewöhnlich von Dritten gehostet werden. Durch das Bereitstellen von Kommunikation zwischen dem Roboter 100 und der Cloud 1620 können Informationen, die vom Roboter 100 gesammelt werden, von autorisierten Benutzern über ein webbasiertes Informationsportal sicher angezeigt werden.
Das Portal 1630 kann ein webbasiertes Benutzerportal zum Sammeln und/oder Bereitstellen von Informationen sein, wie z. B. persönlichen Informationen, Informationen zum Home-Status und Informationen zum Roboterstatus. Informationen können mit Informationen Dritter integriert werden, um dem Benutzer und/oder Roboter 100 zusätzliche Funktionalität und Ressourcen bereitzustellen. Die Robotersystemarchitektur 1600 kann das proaktive Sammeln von Daten erleichtern. Beispielsweise können Anwendungen 1610, die von der Rechnervorrichtung 310 ausgeführt werden, Daten sammeln und über Handlungen, die vom Roboter 100 durchgeführt werden, und/oder über eine Person oder eine Umgebung, die vom Roboter 100 gesehen wird (unter Verwendung des Sensorsystems 400), berichten. Diese Daten können eine eindeutige Eigenschaft des Roboters 100 sein.
In manchen Beispielen ist das Portal 1630 eine persönliche Website im World Wide Web. Das Portal 1630 kann personalisierte Funktionen und einen Pfad zu anderen Inhalten bereitstellen. Das Portal 1630 kann verbreitete Anwendungen, verschiedene Anzahl und Typen von Middleware und Hardware verwenden, um Services von einer Anzahl verschiedener Quellen bereitzustellen. Außerdem können Geschäftsportale 1630 Kollaboration in Arbeitsplätzen gemeinsam nutzen und Inhalte bereitstellen, die auf mehreren Plattformen wie Personal Computers, Personal Digital Assistants (PDAs) und Mobiltelefonen verwendbar sind. Informationen, Neuigkeiten und Aktualisierungen sind Beispiele für Inhalte, die durch das Portal 1630 geliefert werden können. Persönliche Portale 1630 können auf ein beliebiges spezifisches Thema bezogen sein, wie Bereitstellung von Informationen über Freunde in einem sozialen Netzwerk oder Bereitstellung von Links zu externen Inhalten, die anderen helfen können.
In Bezug auf räumliche Datensätze wird hierin auf ,dichte Daten' im Vergleich zu ,schwach besetzten Daten' und ,dichte Funktionen' im Vergleich zu ,schwach besetzten Funktionen' Bezug genommen. Ohne die Bedeutung einzuschränken oder einzuengen, die den Begriffen gemäß der Auslegung durch einen Fachmann zukommt, bedeutet ,dicht' im Vergleich zu ,schwach besetzt' im Allgemeinen viele Datenpunkte pro räumlicher Darstellung im Vergleich zu wenigen Datenpunkten und kann speziell Folgendes bedeuten:

(i) im Kontext von 2D-Bilddaten oder 3D-,Bildern' einschließlich 2D-Daten und -Bereich beinhalten ,dichte' Bilddaten solche Bilddaten, die im Wesentlichen vollständig mit Pixeln eingepflegt sind oder praktisch ohne Verluste und/oder Artefakte von der ursprünglichen Bilderfassung (einschließlich im Wesentlichen unkomprimierte, rohe oder verlustfrei komprimierte Bilder) zu Pixeln gerastert werden können, während sich ein ,schwach besetztes' Bild dadurch auszeichnet, dass das Bild quantifiziert, abgetastet, verlustbehaftet komprimiert, vektorisiert, segmentiert (z. B. in Superpixel, Knoten, Kanten, Oberflächen, Punkte von Interesse, Voxel) oder auf andere Weise von der ursprünglichen Erfassung an Treue erheblich reduziert wird oder zur Rasterung zu Pixeln interpoliert werden muss, um wieder ein Bild darzustellen;
(ii) im Kontext mit 2D- oder 3D-Funktionen können ,dichte Funktionen' Funktionen sein, die auf im Wesentlichen uneingeschränkte Weise zu der Auflösung des Erkennungsansatzes aufgefüllt werden – alle, die festgestellt und aufgenommen werden können und/oder Funktionen, die von Detektoren erkannt werden, um viele Funktionen (HOG, Wavelets) über einem Teilbild zu sammeln; ,schwachbesetzte Funktionen' können gezielt in der Anzahl, der Anzahl der Funktionseingaben, der lateralen Hemmung und/oder Funktionswahl beschränkt sein und/oder können von Detektoren erkannt werden, um eine begrenzte Anzahl isolierter Punkte in einem Bild zu erkennen (Harris Corner, Edges, Shi-Tomasi).

Bezüglich der 3D-Umgebungsstruktur kann der Roboter 100 Bilder, wie z. B. dichte Bilder 1611, einer Szene 10 um den Roboter 100 beschaffen, während er auf einer Arbeitsfläche 5 manövriert. In manchen Ausführungen verwendet der Roboter 100 eine Kamera 320 und/oder einen Bildsensor 450 (z. B. ein volumetrisches Punkt-Cloud-Bildgebungsgerät), um die dichten Bilder 1611 zu beschaffen. Der Kontrollschaltkreis 500, der in Verbindung mit der Kamera 320 und/oder dem Bildsensor 450 steht, kann Informationen 1613 mit den dichten Bildern 1611 verknüpfen (z. B. die dichten Bilder 1611 mit Daten annotieren oder kennzeichnen), wie Akzelerometer-Datenspuren, Odometriedaten und/oder andere Daten aus dem Sensorsystem 400 zusammen mit Zeitstempeln. In manchen Beispielen erfasst der Roboter 100 eine Streaming-Sequenz 1615 dichter Bilder 1615 und annotiert die dichte Bildfrequenz 1615 mit Anmerkungsdaten 1613 und stellt eine annotierte dichte Bildsequenz 1615a bereit. Der Roboter 100 kann regelmäßig Bilddaten 1601 an den Cloud-Speicher 1622 senden (z. B. über den Kontrollschaltkreis 500 oder das Webpad 310), der über einen Arbeitszeitraum einen potentiell sehr großen Bilddatensatz 1603 ansammeln kann. Die Bilddaten 1601 können Rohsensordaten (z. B. ein(e) Punktcloud oder -signal oder die dichte Bildsequenz 1615) oder gekennzeichnete Daten wie die annotierte dichte Bildsequenz 1615a sein (z. B. ein Datenobjekt mit Eigenschaften oder Attributen, wie mit Java Script Object Notation(JSON)-Objekten). Der Cloud-Service 1620 kann die empfangenen Bilddaten 1601 (z. B. dichte Bildsequenz 1615 oder annotierte dichte Bildsequenz 1615a) bearbeiten und einen bearbeiteten Datensatz 1617 an den Roboter 100 zurückleiten, z. B. an den Kontrollschaltkreis 500 und/oder das Webpad 310. Der Roboter 100 kann Antriebsbefehle 1619 an das Antriebssystem 200 aufgrund des empfangenen bearbeiteten Datensatzes 1617 zum Manövrieren in der Szene 10 geben (z. B. über den Kontrollschaltkreis 500 oder das Webpad 310).
Nachdem sich ein Schwellenzeitraum oder eine Schwellenmenge an Bilddaten 1601, 1603 im Cloud-Speicher 1622 angesammelt hat, kann der Cloud-Service 1620 eine von mehreren offline Verfahren ausführen, um den Bilddatensatz 1603 in eine dichte 3D-Karte oder ein Modell 1605 der Szene 10 (Umgebung) zu verarbeiten und diese dichte 3D-Karte oder das Modell 1605 dann in eine 2D-Höhenkarte 1607 vereinfachen, die eine 2D-Karte mit Höhendaten an jedem Punkt sein kann (z. B. ähnlich einer topographischen 2D-Karte). In manchen Beispielen ist die 2D-Höhenkarte 1607 eine topographische Karte mit X- und Y-Koordinaten mit Z-Daten. Jede X, Y-Koordinate kann eine oder mehrere Z-Punkte aufweisen (d. h. Höhendaten). Ungleich der dichten 3D-Karte, die zahlreiche Z-Punkte für jede X, Y-Koordinate aufweisen kann (z. B. hunderte oder tausende von Z-Punkten), kann die 2D-Höhenkarte 1607 weniger als die Schwellenanzahl von Z-Punkten für jede X, Y-Koordinate aufweisen, wie zwischen 2 und 20 (z. B. 10) Punkte. Eine 2D-Höhenkarte 1607, die aus einer 3D-Karte eines Tischs in einem Raum abgeleitet ist, kann einen ersten Z-Punkt für die untere Oberfläche einer Tischplatte und einen zweiten Z-Punkt für die obere Oberfläche der Tischplatte für jede X, Y-Koordinate entlang des Tischs zeigen. Anhand dieser Informationen kann der Roboter 100 feststellen, ob er unter der Tischplatte hindurch passt. Durch das Reduzieren der Z-Punkte von einem dichten Datensatz eines kontinuierlichen Bereichs von Z-Punkten für jede X, Y-Koordinate in einen schwach besetzten Datensatz mit einer gewählten Anzahl von Z-Punkten, die für ein festgestelltes Objekt 12 indikativ sind, kann der Roboter 100 eine 2D-Höhenkarte 1607 empfangen, die eine relativ geringere Größe als die 3D-Karte aufweist, die vom Cloud-Service 1620 verwendet wird. Dies wiederum ermöglicht dem Roboter 100 das Speichern der 2D-Höhenkarte 1607 auf einem örtlichen Speicher von praktischer und kosteneffizienter Größe im Vergleich zur skalierbaren Speicherkapazität, die dem Cloud-Service 1620 zur Verfügung steht. Der Roboter 100 empfängt die 2D-Höhenkarte 1607 von der Cloud 1620, wodurch dem Roboter 100 und dem damit verbundenen Kontrollschaltkreis 500 Navigationsdaten für zukünftige Arbeit in der Szene 10 bereitgestellt werden.
Zusätzliche Verfahren und Funktionen der Datenkompression von 3D-Karten sind in „Multi-Level Surface Maps For Outdoor Terrain Mapping and Loop Closing" von R. Triebel, P. Pfaff und W. Burgard; IEEE/RSJ International Conference on Intelligent Robots and Systems, 2006, offengelegt, die hiermit in ihrer Gesamtheit durch Bezugnahme hierin aufgenommen werden.
Die Cloud 1620 stellt dem Roboter 100 auf Abruf Scaling von Ressourcen (z. B. Rechner, Verarbeitung, Speicher usw.) bereit, die andernfalls auf dem Roboter 100 nicht praktisch oder kosteneffektiv wären. Beispielsweise kann die Cloud 1620 skalierbare Cloud-Speicherung 1622 bereitstellen, die bis zu einer ersten Größe zum Speichern und/oder Verarbeiten einer relativ großen Datenmenge 1601 skaliert, die nur für eine kurze Zeit verwendet und dann verworfen werden kann, und dann zurück auf eine zweite Größe skaliert. Darüber hinaus kann die Cloud 1620 Computerrechenleistung zur Ausführung relativ komplexer Berechnungen oder ,Brute-Force'-Algorithmen bereitstellen, die andernfalls auf dem Roboter nicht unbedingt möglich wären. Durch das Ersetzen von Computerrechenleistung und -speicher auf eine skalierbare Cloud 1620, kann der Roboter 100 einen Kontrollschaltkreis 500 verwenden, der relativ weniger Rechnungsleistung und -speicher aufweist und somit eine kosteneffiziente Lösung bereitstellt. Darüber hinaus kann der Roboter 100 Echtzeitaufgaben ausführen (auf dem Kontrollschaltkreis 500 oder dem Webpad 310), wie das Vermeiden von Hindernissen, während Aufgaben in Nicht-Echtzeit oder nicht zeitempfindliche Aufgaben zur Verarbeitung und zum späteren Abrufen an die Cloud 1620 geleitet werden.
Die Cloud 1620 kann einen oder mehrere Filter (z. B. eine Bündelausgleichung, RANSAC, Expectation Maximization (EM), SAM oder andere 3D-Strukturschätzalgorithmen) zur Verarbeitung des Bilddatensatzes 1603 in 3D-Darstellung ausführen. Nachdem der Bilddatensatz 1603 verarbeitet und eine dichte 3D-Karte 1605 erstellt oder aktualisiert wurde, kann er aus dem Cloud-Speicher 1622 verworfen werden, um Ressourcen freizusetzen und der Cloud 1620 ein entsprechendes Skalieren zu ermöglichen. Das führt dazu, dass der Roboter 100 aufgrund der Cloud-basierten Ressourcen weder den robotereigenen Speicher noch die Verarbeitung benötigt, um das Speichern und Verarbeiten des Bilddatensatzes 1603 handzuhaben. Die Cloud 1620 kann verarbeitete Navigationsdaten 1601 oder eine Karte 1607 (z. B. eine komprimierte 2D-Höhenkarte) an den Roboter 100 zurücksenden, der sie dann für relativ einfachere Ortsbestimmungs- und Navigationsverarbeitung verwenden kann.
Zusätzliche Verfahren und Funktionen der 3D-Rekonstruktion sind in „3D Models From Extended Uncalibrated Video Sequences: Addressing Key-frame selection and projective drift" von J. Repko und M. Pollefeys; Fifth International Conference on 3-D Digital Imaging and Modeling, 2005, offengelegt, die hiermit in ihrer Gesamtheit durch Bezugnahme hierin aufgenommen werden.
Bezüglich der Fußbodeneinteilung kann der Roboter 100 Bilder von der Arbeitsfläche 5 erfassen, während er sich darauf über Szene 10 bewegt. Der Kontrollschaltkreis 500 kann die Bilder empfangen und eine Objekterkennungsroutine zur Erkennung des Objekts und Vermeidung von Hindernissen (ODOA) ausführen. In gewissen Ausführungsformen assoziiert der Kontrollschaltkreis 500 Informationen mit den Bildern (z. B. markiert er die Bilder mit Daten), wie beispielsweise Akzelerometerdatenspuren, Odometriedaten, und/oder sonstige von dem Sensorsystem 400 gelieferte Daten einher mit Zeitstempeln. Die Bilder können Abfälle, Teppichfransen, Socken auf Teppichen, usw. erfassen. Wie auch in dem vorherigen Beispiel kann der Roboter 100 die Bilddaten 1601 zur Cloudspeicherung 1622 streamen, während er gleichzeitig an einer späteren Batchverarbeitung arbeitet. Ein besonderes 'Gefahr'-Kennzeichen wird in den Datensatz eingefügt, damit die Daten über die Momente vor der Gefahr für die Lernalgorithmen ermittelt werden können, wenn der☐Roboter auf ein unerwünschtes Ereignis stößt (d. h. unbeabsichtigter Zusammenstoß). Nachdem der annotierte Bilddatensatz und die dazugehörigen Kennzeichen 1603 angesammelt wurden (eventuell mitsamt den Datensätzen vieler anderer Roboter 100), kann ein paralleler Cloud-Host 1620 zur Bearbeitung des annotierten Bilddatensatzes 1603 unter Einsatz eines überwachten Lernalgorithmus eingesetzt werden, der beispielsweise ”Gefahr-Bild”-Klassen auf der Grundlage der vielen Bilder einer echten Umgebung berechnet, die den Gefahr-Kennzeichen zeitlich vorangehen. Nach Abschluss des Trainings eines Gefahr-Bild-Klassen-Modells 1609 können die Parameter für dieses Modell 1609 (eine kleine Datenmenge) wieder zurück auf viele verschiedene Roboter 100 heruntergeladen werden. So kann eine komplette Flotte von Robotern 100 die Elemente einer Umgebung adaptiv online erlernen. Die für diese Methode anwendbaren Learnmmethoden umfassen genetische Algorithmen, neurale Netzwerke und Supportvektor-Maschinen. All dies kann zu komplex sein und zu viel Speicher zur Ausführung online (d. h., auf einem lokalen Roboter-Prozessor) in einem kostengünsten Roboter 100 belegen; jedoch bietet die Cloud 1620 einen Zugriff durch Roboterflotten auf ”gut ausgebildete” Klassifikatoren 1625.
Ein 'Klassifikator' 1625 ist ein Maschinen-Lernalgorithmus, der in der Regel einen iterativen Trainings-Algorithmus z. B. zur Minimierung einer Fehlerfunktion, Optimierung/Minimierung einer Kostenfunktion oder zur anderweitigen Leistungsverbesserung unter Einsatz der Trainingsdaten einsetzt. Normalerweise enthält der Algorithmus eine Reihe an Parameter, deren Werte von den Trainingsdaten erlernt wurden. Die drei Arten umfassen überwachte Rückwärtsbewegung, überwachte Klassifizierung, und nicht überwachte Klassifizierung über Clustering oder Dimensionalitätsreduzierung. Beispiele der Klassifikatoren 1625 wären Supportvektormachinen (SVM) verschiedener Arten und Kernels (mit Gradientabfall oder sonstiger Minimierungsmethode für die Kostenfunktion), naive Bayes-Klassifikator, logistische Rückwärtsbewegung, AdaBoost, k-nächster Nachbar (”K-NN”) und/oder K-NN Regression, neurale Netzwerke, Random Forests und lineare Modelle. Ein 'Klassifikator' klassifiert die 'Merkmale', die durch Vektoren, Matrixen, ”Deskriptoren”, oder sonstige Datensätze dargestellt werden und durch verschiedene Algorithmen ermittelt, wie zum Beispiel durch das Histogramm orientierter Gradienten (HOG), Shape-Context-Histogramme (SCH), Farbfelder, Texturfelder, Luminanzfelder, skaleninvariante Merkmalstransformationsdeskriptoren von SIFT, SURF, o. ä., affine Invarianzdetektoren, wie z. B. MSER, markierte Super Pixel oder Segmente innerhalb der Bilder, Hough Transformation oder RANSAC-Linienerkennung und sonstige damit kombinierbare Merkmale.
Die Klassifikatoren 1625 können online zur Unterstützung der Robotersysteme bei der Gefahrenvermeidung in ihrer Umgebung von nur einem Bild ausgeführt werden. Nach Festlegung der Modellparameter kann der in der Cloudspeicherung 1622 gespeicherte Bilddatensatz 1603 gelöscht werden. Dieses Beispiel kann mit dem vorherigen Beispiel zusammengelegt werden, in dem die Festlegung einer 3-D Struktur der Umgebung die Ermittlung überquerbarer Regionen zum Training des Einordnungsalgorithmus erlauben. Eine beispielhafte Lernmethode wurde in "Long-Term Learning Using Multiple Modells For Outdoor Autonomous Robot Navigation," von Michael J. Procopio, Jane Mulligan und Greg Grudic, IEEE Internationale Tagung 2007 über Intelligente Roboter und Systeme offenbart, die hiermit durch Verweis vollständig mit aufgenommen wird.
Streaming bezieht sich in der Regel auf die Übertragung einer Bildsequenz, die in einer gewissen Beziehung zu einer Reihenfolge und einer Rate steht, zu der die Bildsequenz in Echtzeit erfasst wurde, und zwar mit oder ohne Pufferung, wobei es gleich ist, ob die Pakete zwischen Sender und Empfänger wieder geordnet wurden, und zwar im Unterschied zur Absendung einer Batchverarbeitungsaufgabe (die bei sehr hohen Datenübertragungsraten stattfinden kann), oder auf verzögert tropfende Bilder. Der Begriff 'Streaming' wird von 'Versendung einer Batchverarbeitungsaufgabe' unterschieden, um die Übertragungsraten auseinanderzuhalten, zu denen die verschiedenen Daten innerhalb von und unter den Einheiten eines Robotersystems auf der Grundlage der tatsächlichen Bandbreiten-, Verarbeitungs- und Speicherbegrenzungen bewegt werden.
Bezugnehmend auf 16D und 16E, kann Roboter 100 bei konkreten Kostenstufen hinsichtlich der Roboterbandbreite, Berechnung und Speicherung eingeschränkt sein. Durch eine Annotierung der Bilder 1611 mit lokal verarbeiteten Daten 1613 (d. h. Daten vom Roboter Sensorsystem 400), kann der Roboter 100 Bilder 1611, dichte Bildsequenzen 1615, 1615a oder Bilddaten 1601 relativ selten (z. B. einmal alle paar Sekunden anstelle von viele Male pro☐Sekunde) hochschicken und somit die Aufwärtsbandbreite im Vergleich zum fortlaufenden Streaming von Daten erheblich verringern. Des Weiteren kann der Kontrollschaltkreis 500 und/oder das Web-Pad 310 ein lokales Cache (Speicher) umfassen, in dem Bilder 1611 und Annotationsdaten 1613 im Roboter 100 gespeichert werden können, sollte eine drahtlose Konnektivität nicht verfügbar sein, und die dann übertragen werden, wenn eine drahtlose Konnektivität zur Verfügung steht. Die Pufferung erlaubt dem Roboter 100 Daten eines gesamten Zimmers beispielsweise in einem Zimmer zu sammeln, in dem das Empfangssignal schlecht ist, und dennoch einen vollständigen Datensatz 1601, 1603 zu übertragen, nachdem eine Konnektivität wieder zur Verfügung steht, wie beispielsweise in einem danebenliegenden Zimmer. Eine Datenverwaltung auf Roboter 100 kann daher zwecks Anpassung an verschiedene Kommunikationsumgebungen erforderlich sein.
Wenn der mobile Roboter gesteuert, ausgerichtet oder selbständig durch eine Szene 10 (z. B. zuhause, im Büro, usw.) navigiert, können eine oder mehrere Kameras 320 und/oder Bildsensoren 450 eine oder mehrere Sequenzen 1615 der Bilder 1611 erhalten, die jeweils einer Ansicht entsprechen, die von einer Pose (Position und Richtung) von Roboter 100 entlang seiner Bewegungsbahn erhalten wurden. Ein Zeitnehmer (z. B. des Kontrollschaltkreises 500) liefert einen Referenz-Zeitstempel für jedes Bild 1611, wobei der Zeitstempel mit Annotationen 1613 verbunden sein kann, die einer Position, Lokalisation, Bewegungsgeschwindigkeit oder Beschleunigung, sensor-basierten Orientierung, usw. entsprechen. Zumindest einige der Bilder 1611 werden mit Informationen versehen, und alle Bilder 1611 können mit Zeitstempeln oder sonstigen Metadaten annotiert sein, die den Robotererstatus, Bildstatus, o. ä. widerspiegeln. Die Bilder 1611 können zu irgendeiner Erfassungsrate in Echtzeit erfasst werden, die nicht zyklisch sein muss (z. B. können Bilder 1611 zu einer adaptiven Übertragungsrate erfasst werden, die beispielsweise auf der Verarbeitungsverfügbarkeit, Bandbreitenverfügbarkeit, Tageszeit, Aufgabe, Dichte der Merkmale von Interesse in den laufenden Bildern, o. ä. basiert).
Die Kamera 320 und/oder der Bildsensor 450 können zur Speicherung und Sammlung der erfassten Bilder 1611 bei einer relativ hohen Übertragungsrate mit einem Hardware-Encoder, einem dem Speicher zur Verfügung stehenden Highspeed-Bus sowie auch mit einem On-Board-Prozessor und Speicher (z. B. ein Flash-Speicher oder ein Festplattenlaufwerk) in Verbindung stehen. Ein oder mehrere Maschinenvisionsalgorithmen können auf die gespeicherten Bilder 1611 zur Erstellung von Modellen angewandt werden, wie beispielsweise ein Parametersatz für Bildklassifikatoren 1625, die selbst nicht mehr Ressourcen verbrauchen, als von Roboter 100 unterstützt werden können. Dabei sind jedoch bestimmte Hindernisse zu überwinden.

(1) Typischerweise sollte die Ermittlung von mindestens einigen die zu modellierenden Merkmale beschreibenden Trainingsdaten (z. B. Bilder 1611) oder Annotationen 1613 vor einer maßgeblichen Bildkompression angewandt werden.
(2) Zur Ausführung der Modellierung in kürzerer Zeit können viele Algorithmen und Heuristiken skaliert und relativ großen, verteilten, in Cloud-Dienste instanzierten Computer-Infrastrukturen angepasst werden. Zu diesem Zweck müssen jedoch Bilder 1611 zur Zielcomputer-Infrastruktur im ganzen öffentlichen Internet gelangen.
(3) Die für den Transport relativ großer Datensätze verfügbare Bandbreite ist durch (i.) den Roboter 100, der mobil ist, und dessen drahtlose Bandbreite typischerweise mit sonstigem Verkehr belegt ist, und (ii.) der bandbreitentechnischen Beschränkung des Internetzugriffs in einer vorgeschalteten Richtung, eingeschränkt.

Zur Überwindung dieser Hindernisse können die dichten Bilder 1611 von Roboter 100 auf einen lokalen Server 1640 (z. B. drahtlos) übermittelt werden, der ein drahtgebundenes Netzwerk mitsamt Speicherung sein kann, und zwar zu einer Senderate vor Ort, die relativ niedriger als die Erfassungsrate in Echtzeit ist. Der lokale Server 1640 kann die dichten Bilder 1611 mit Annotationen 1613 puffern und annotatieren. Überdies kann der lokale Server 1640 annotierte dichte Bildsequenzen 1615a für spätere Datenübertragungen zum Cloud-Dienst 1620 ansammeln. Der lokale Server 1640 kann Bilddaten 1601 (z. B. dichte Bilder 1611, dichte Bildsequenzen 1615, und/oder annotierte dichte Bildsequenzen 1615a) zum Cloud-Dienst 1620 zu einer Cloud-Senderate, die langsamer als die Erfassungsrate in Echtzeit ist, oder zu einer Rate übertragen, die der Bedienung einer Cloud-Computer-Infrastruktur mit hoher Geschwindigkeit entspricht.
Der Cloud-Dienst 1620 kann die empfangenen Bilddaten 1601, z. B. durch das elastische Abschicken eines ausreichend schnellen parallelen und/oder großen Bildsatz-Klassifikators 1625 Verarbeitungsinstanzen zum Training der Klassifikatoren 1625 hinsichtlich der Bilddaten 1601 (z. B. der dichten Bilder 1611 samt dazugehöriger Annotationen 1613) zur Bereitstellung eines vereinfachten Datensatzes 1617 verarbeiten, der beispielsweise von der annotierten dichten Bildsequenz 1615a abgeleitet wurde und diese darstellt, jedoch☐Rohbilddaten absondert. Der Cloud-Dienst 1620 kann den vereinfachten Datensatz 1617 auf den lokalen Server 1640 übertragen, der mit dem Roboter 100 oder direkt mit den Roboter 100 nach beispielsweise einem Verarbeitungsintervall kommuniziert. Die Elemente des Datensatzes 1617 können von dem Roboter 100 zur Ausstellung von Befehlen an das Antriebssystem 200 zur Manövrierung des Roboters 100 in Bezug auf die Szene/Umgebung 10 eingesetzt werden. Zum Beispiel kann ein 'Kordel'- oder 'Socken'- oder 'einnehmbarer Unrat'-Klassifikator 1625, der mit den Bilddaten 1601 eines oder vieler Roboter trainiert wurde mit Parameter eingesetzt werden, die an den Roboter 100 zur Ermittlung von Bildmustern zurückgeschickt wurden, und den Roboter 100 entweder von der Gefahr weg oder in Richtung eines anderen Bereichs von Interesse steuern.
Falls eine Bandbreitenbeschränkung bei einem drahtlosen Anschluss oder einem Verbraucher/kommerziellem asymmetrischem Breitbanddienst in Übertragungsrichtung bestehen, kann die dichte Bildsequenz 1615 in einer großen Speicherungsvorrichtung gepuffert werden und über einen Zeitraum hinweg, der relativ länger als die Sammlungszeit ist (d. h., ein Zeitraum zur Sammlung der dichten Bildsequenz 1615) hochgeladen werden, um somit die Datenpaketvermittlung, Neuordnung, Berichtigung, Servicequalität, usw. zu nutzen. So kann beispielsweise der Upload übernacht, im Laufe eines Zeitraums von Stunden, wenn der Bewegungsablauf des Roboters in Minuten stattfand, und in Tagen stattfinden, wenn der Bewegungsablauf des Roboters in Stunden stattfand, usw.
Auf dem lokalen Server 1640 oder dem Cloud-Dienst 1620 können die dichten Bilder 1611, die die Sequenz der Ansichten der Umgebung entlang einer Bewegungsbahn des mobilen Roboters 100, die zu einer Echtzeiterfassungsrate erfasst werden, von einem Service 1623 empfangen werden, der mit einer Robotersoftwareplattform des Roboters 100 verbunden ist. Der Service 1623, auf den sich auch als den Cloud Gateway bezogen wird, kann ein Agent der Robotersoftwareplattform sein oder unabhängig von Dritten gesteuert werden. Der Cloud Gateway 1623 kann die dichte Bildsequenz 1615 einem Algorithmus, Klassifikator 1625 und einer Anwendungsplattfominstanz anpassen, die als ein oder mehrere virtuelle Server 1621 in dem Cloud-Dienst 1620 (z. B. je nach dem Annotationsinhalt) zu instantaniieren/bereitzustellen sind, und die dichte Bildsequenz 1615 mitsamt der Annotationen 1613 als Trainingsdaten für den Klassifikator 1625 verpacken. Wahlweise kann der Cloud Gateway 1623 dieselben wie die vorgepackten Informationen von dem Roboter 100, der lokalen Basisstation, usw., bearbeiten und dann einfach mit dem Versand ausreichend vorbestimmter, virtueller Serverinstanzen 1621 beginnen, die sonstige Instanzen elastisch hinzufügen, welche konform mit der adaptiven und elastischen Anwendungsprogrammierungs-Schnittstelle (API) des Cloud-Diensts (z. B. Amazon EC2) sind. Der lokale Server 1640, der Cloud-Dienst Manager Cloud Gateway 1623 oder eine initiale virtuelle Prozessorinstanz 1621 schickt eine in der Verringerung dichter Daten in jedem von mindestens einigen der dichten Bilder 1611 in der empfangenen dichten Bildsequenz 1615, 1615a bestehenden Batchverarbeitungsaufgabe zu dem die dichte Bildsequenz 1615, 1615a darstellenden Datensatz 1617. Erforderlichenfalls können neue virtuelle Prozessorinstanzen 1621 bereitgestellt/instantiiert werden (entweder alle auf einmal oder wenn die Trainingsaufgabe zunehmend komplexer wird). Die dichten Bilder 1611 und trainierten Modelle 1609 können in langzeitigen Speicherungsinstanzen aufbewahrt werden. Die Parameter des trainierten Klassifikators 1625 oder des Modells 1609 werden zum Roboter 100 (z. B. direkt oder über einen Agenten des Roboters 100) zurückgeschickt. Dabei wird die Sequenz der Rohbilder 1611 abgesondert.
16F stellt eine beispielgebende Anordnung 1600f der Abläufe für ein Verfahren zur Navigation des Roboters 100 dar. Das Verfahren umfasst die Erfassung 1602f, eine Streamingsequenz 1615 der dichten Bilder 1611 einer Szene 10 um den Roboter 100 entlang des Locus einer Bewegung des Roboters 100 zu einer Erfassungsrate in Echtzeit sowie auch die Assoziation 1604f von Annotationen 1613 mit mindestens einigen der dichten Bilder 1611. Das Verfahren umfasst ebenfalls das Senden 1606f der dichten Bilder 1611 mitsamt der Annotationen 1613 an einen Remote-Server 1620 zu einer Senderate, die langsamer als die Erfassungsrate in Echtzeit ist, und den Empfang 1608f eines Datensatzes 1607, 1617 von dem Remote-Server 1620 nach einem Bearbeitungszeitintervall. Der Datensatz 1607, 1617 wird von der dichten Bildsequenz 1615, 1615a abgeleitet und stellt mindestens einen Teil derselben dar sowie auch von den entsprechenden Annotationen 1613, sondert jedoch Rohbilddaten von der Sequenz 1615, 1615a der dichten Bilder 1611 ab. Die Verfahren umfasst das Bewegen 1610f des Roboters 100 in Bezug auf die Szene 10 auf der Grundlage des empfangenen Datensatzes 1607, 1617.
Das Verfahren kann das Senden der dichten Bilder 1611 mitsamt der Annotationen 1613 an einen lokalen Server und Puffer 1640 (16D und 16E) sowie das darauffolgende Senden der dichten Bilder 1611 mitsamt Annotationen 1613 an den Remote-Server 1620 zu einer Senderate umfassen, welche langsamer als die Erfassungsrate in Echtzeit ist. Der lokale Server und Puffer 1640 kann sich innerhalb einer relativ kurzen Entfernung vom Roboter 100 (z. B. zwischen 20 bis 100 Fuß oder einer drahtlosen Kommunikationsreichweite) befinden. Zum Beispiel kann der Ort und Puffer 1640 ein Personal Computer in der Wohnung des Nutzers, in der der Roboter 100 untergebracht ist, oder auch der lokale Server eines☐Gebäudes sein, in dem der Roboter 100 untergebracht ist.
In einigen Ausführungsformen umfassen die Annotationen 1613 einen Zeitstempel, wie beispielsweise eine absolute Zeitreferenz, die mindestens einigen der dichten Bilder 1611 entsprechen, und auch posen-bezogene Sensordaten, die mindestens entweder Odometrie-Daten oder Akzelerometer-Daten oder Kipp-Daten oder Anstoß- oder Winkelratendaten umfassen können. Die Annotationen 1613 können mit den dazugehörigen, die Gefahrereignisse widerspiegelnden, dichten Bildern 1611 assoziiert werden, die in einem von der Reaktion auf die Gefahr des Roboters 100 abhängigen Zeitintervall erfasst wurden (z. B. Vermeiden einer Klippe, Entkommen aus einer begrenzenden Situation, usw.). In zusätzlichen Beispielen kann die Assoziation 1604f der Annotationen 1613 die Assoziation von Schlüsselbild-Identifikatoren mit einem Teilsatz der dichten Bilder 1611 umfassen. Die Schlüsselbild-Identifikatoren können die Ermittlung dichter Bilder 1611 auf der Grundlage von Eigenschaften der Schlüsselbild-Identifikatoren (z. B. Flag, Typ, Gruppe, bewegt sich, steht still, usw.) ermöglichen.
Die Annotationen 1613 können einen dünn bestückten von der Struktur- und Bewegungsrückgewinnung von Merkmalen abgeleiteten Satz an 3-D Punkten umfassen, die zwischen den dichten Bildern 1611 von der Streamingsequenz 1615 der dichten Bilder 1611 verfolgt wurden. Der dünn bestückte Satz von 3-D Punkten kann von einer volumetrischen Punkt-Imaging-Vorrichtung 450 auf dem Roboter 100 stammen. Des Weiteren können die Annotationen 1613 Kamera-Parameter, wie beispielsweise eine Kamera-Pose in Bezug auf einzelne 3-D Punkte des dünn bestückten Satzes von 3-D Punkten, umfassen. Die Annotationen 1613 für die dichten Bilder 1611 können Bezeichnungen überquerbarer und nicht-überquerbarer Bereiche der Szene 10 sein.
Der Datensatz 1607, 1617 kann ein oder mehrere Texturabbildungen, wie beispielsweise die von den dichten Bildern 1611 extrahierte 2-D Höhenabbildung 1607 und/oder eine die Merkmale innerhalb der dichten Bilder 1611 von der Szene 10 darstellende Geländeabbildung 1607 umfassen. Der Datensatz 1607, 1617 kann einen trainierten Klassifikator 1625 zur Klassifizierung der Merkmale innerhalb der neuen, dichten, von der Szene 10 erfassten Bilder 1611 umfassen.
16G liefert eine beispielgebende Anordnung 1600g der Abläufe für ein Verfahren zur Abstrahierung der Umgebungsdaten mobiler Roboter. Das Verfahren umfasst den Empfang 1602g einer Sequenz 1615 dichter Bilder 1611 von einer Roboter-Umgebung 10 von einem mobilen Roboter 100 zu einer Empfangsrate. Die dichten Bilder 1611 werden entlang eines Locus der Bewegung des mobilen Roboters 100 zu einer Erfassungsrate in Echtzeit erfasst. Die Empfangsrate ist langsamer als die Erfassungsrate in Echtzeit. Das Verfahren umfasst ebenfalls den Empfang 1604g von Annotationen 1613, die mit mindestens einigen der dichten Bilder 1611 in der Sequenz 1615 der dichten Bilder 1611 assoziiert sind, und die Absendung 1606g einer Batchverarbeitungsaufgabe zur Verringerung der dichten Daten innerhalb von wenigstens einiger der dichten Bilder 1611 an den Datensatz 1607, 1617, der mindestens einen Teil der Sequenz 1615 der dichten Bilder 1611 darstellt. Des Weiteren umfasst das Verfahren die Übertragung 1608g des Datensatzes 1617 an den mobilen Roboter 100. Der Datensatz 1607, 1617 schließt Rohbilddaten von der Sequenz 1615 dichter Bilder 1611 aus.
In einigen Ausführungsformen umfasst die Batchverarbeitungsaufgabe die Verarbeitung der Sequenz 1615 der dichten Bilder 1611 in ein dichtes 3-D Modell 1609 der Roboter-Umgebung 10, und die Verarbeitung des dichten 3-D Modells 1609 in ein Gelände-Modell 1607 für ein Koordinatensystem eines 2-D Orts und mindestens einer Höhe der Bodenebene G. In einigen Beispielen dient das Gelände-Modell 1607 dem Koordinatensystem eines 2-D Orts und mehreren belegten und nicht belegten Höhengrenzen von einer Bodenebene G. So würde beispielsweise das Gelände-Modell 1607 in einem Raum mit einem Tisch Daten liefern, die die unteren und oberen Höhen einer damit verbundenen Tischplatte anzeigen, damit der Roboter 100 bestimmen kann, ob er unter dem Tisch durchfahren kann.
Die Batchverarbeitungsaufgabe kann die Ansammlung dichter Bildsequenzen 1615, 1615a umfassen, die einer mehrerer Roboter-Umgebungen 10 entsprechen (z. B. damit die Cloud 1620 Klassifikatoren 1625 zur Ermittlung der Merkmale von Interesse in jeder Umgebung erstellen kann). Als solche kann die Batchverarbeitungsaufgabe viele Klassifikatoren 1625 und/oder das Trainieren eines oder mehrere Klassifikatoren 1625 auf die Sequenz 1615 der dichten Bilder 1611 umfassen. Zum Beispiel kann die Batchverarbeitungsaufgabe Assoziations-Annotationen 1613 umfassen, die die Gefahr-Ereignisse mit den in einem Zeitintervall erfassten dichten Bildern 1611 widerspiegeln, das von einer Gefahr-Rückmeldung von dem mobilen Roboter 100 abhängig ist sowie auch das Training eines Klassifikators 1625 mit gefahr-bezogenen dichten Bildern 1611 unter Einsatz der dazugehörigen Gefahr-Ereignis-Annotationen 1613 und den entsprechenden dichten Bildern 1611 als Trainingsdaten, um z. B. einen Datensatz 603, 1607, 1617 der Modell-Parameter für den Klassifikator 1625 zu liefern. Die Klassifikator 1625 kann mindestens eine Supportvektor-Machine enthalten, die mindestens eine Hyperebene für eine Klassifizierung erstellt, und die Modell-Parameter definieren die trainierte Hyperebene, die fähig zur Einordnung des Datensatzes 1603, 1607, 1617 in gefahr-bezogene Klassifizierungen ist. Die Modell-Parameter können genügend Parameter zur Definition eines Kernels der Supportvektor-Machine und eines Soft Margin Parameters umfassen.
In einigen Beispielen umfasst die Batchverarbeitungsaufgabe die Instanziierung vieler skalierbarer virtueller Prozesse 1621, die proportional zu einem Maßstab der dichten, zu verarbeitenden Bildsequenz 1615, 1615a sind. Mindestens einige der virtuellen Prozesse 1621 werden nach der Übertragung des Datensatzes 1607, 1617 an den Roboter 100 freigegeben. Ähnlicherweise kann die Batchverarbeitungsaufgabe die Instanziierung vieler skalierbarer virtueller Speicher 1622 einschließen, die proportional zum Maßstab der dichten, zu speichernden Bildsequenz 1615, 1615a sind. Mindestens einige der virtuellen Speicher 1622 werden nach der Übertragung des Datensatzes 1607, 1617 an den Roboter 100 freigegeben. Überdies kann die Batchverarbeitungsaufgabe die Verteilung vieler skalierbarer virtueller Server 1621 in Abhängigkeit von der geographischen Nähe zum mobilen Roboter 100, und/oder den Netzwerkverkehr vieler mobiler Roboter 100 umfassen.
Das am 29. Sept. veröffentlichte U.S. Patent 2011/0238857 , ”Committed Processing Rates für Shared Resources” (Festgelegte Verarbeitungsraten für Geteilte Ressourcen), Certain et al., wird hiermit durch Verweis vollständig mit aufgenommen. Die beschriebene Cloud-Verarbeitungsinfrastruktur in Certain et al. ist eine Spezie, die hiermit verbunden werden kann. So sind beispielsweise das Verwaltungssystem 202 oder das Knoten-Manager-Modul 108 Spezien oder Teile des Cloud Gateway 1623, des Programmausführungssservice (PES), und/oder die virtuelle Maschinen 110 sind Spezien oder Teile des elastischen Verarbeitungsservers 1621, und die archivarische Speicherung 222 oder der Blockdatenservice (BDS) 204 oder der archivarische Manager 224 sind Spezien oder Teile der langzeitigen Speicherungsinstanz 1622.
16H ist eine schematische Ansicht einer beispielgebenden mobilen menschlichen Schnittstelle-Robotersystemarchitektur 1600d. In dem dargestellten Beispiel können Anwendungsentwickler 1602 auf die Anwendungsentwicklungtools 1640 zugreifen und diese zur Erzeugung von Anwendungen 1610 benutzen, die auf einem Web-Pad 310 oder einer mit der Cloud 1620 kommunizierenden Rechnervorrichtung 1604 (z. B. Desktop Computer, Tablet Computer, mobile Vorrichtung, usw.) ausführbar sind. Beispielgebende Anwendungsentwicklungstools 1640 können eine integrierte Entwicklungsumgebung 1642, einen Softwareentwicklungssatz (SDK) Bibiliotheken 1644, Entwicklungs- oder SDK-Tools 1646 (z. B. Module eines Softwarecodes, einen Simulator, eine Cloud Verwendungsüberwachung und einen Service Konfigurator, und ein Erweiterungs-Uploader/Deployer des Cloud-Dienst), und/oder Quellcode 1648 enthalten, sind jedoch nicht darauf beschränkt. Die SDK Bibliotheken 1644 können Unternehmensentwicklern 1602 wirksam eingesetzte Mapping-, Navigations-, Planungs- und Konferenz-Technologien des Roboters 100 in den Anwendungen 1610 ermöglichen. Beispielgebende Anwendungen 1610 können eine Kartenerstellung 1610a, eine Mapping- und Navigationsanwendung 1610b, eine Video-Konferenz-Anwendung 1610c, eine Planungs-Anwendung 1610d, und eine Usage-Anwendung 1610e umfassen, sind jedoch nicht darauf beschränkt. Die Anwendungen 1610 können auf einem oder mehrere Anwendungsservern 1650 (z. B. Cloudspeicherung 1622) in der Cloud 1620 gespeichert werden und es kann auf sie durch eine Anwendungen-Programmierungsschnittstelle (API) des Cloud-Diensts zugegriffen werden. Die Cloud 1620 kann eine oder mehrere Datenbanken 1660 und einen Simulator 1670 enthalten. Ein Web Services API kann die Kommunikation zwischen dem Roboter 100 und der Cloud 1620 (z. B. und dem/den Anwendungserver(n) 1650, der/den Datenbank(en) 1660 und dem Simulator 1670) ermöglichen. Externe Systeme 1680 können ebenfalls mit der Cloud 1620 zusammenwirken, wie beispielsweise zum Zugriff auf Anwendungen 1610.
In einigen Beispielen kann die Kartenerstellungsanwendung 1610a eine Karte 1700 (17A) von der Umgebung um den Roboter 100 erstellen, indem von der Kamera 320 oder dem 3-D Bildsensor 450 erfasste Bilder oder Video unter Einsatz der Referenz-Koordinaten, die von der Odometrie, einem Satellitennavigationssystem, und/oder Way-Point Navigation geliefert wurden, miteinander verknüpft werden. Die Karte kann eine Ansicht von innen oder außen einer Straße oder eines Pfads der Umgebung liefern. Für Einkaufszentren oder Ladenstraßen kann die Karte eine Pfadrundfahrt in dem gesamten Einkaufszentrum durchführen, wobei jedes Geschäft als ein Referenz-Ort markiert wird und zusätzliche verknüpfte Bilder oder Video und/oder Werbeinformationen geliefert werden. Die Karte und/oder einzelnen Bilder oder Video können in der Datenbank 1660 gespeichert werden.
Die Anwendungen 1610 können nahtlos mit dem Cloud-Dienst kommunizieren, der je nach Benutzerbedarf individuell angepasst und verlängert werden kann. Unternehmensentwickler 1602 können cloud-seitige Erweiterungen in die Cloud 1620 hochladen, die Daten von externen firmeneigenen Systemen für den Gebrauch durch die Anwendung 1610 abrufen. Der Simulator 1670 erlaubt dem Entwickler 1602 die Erstellung unternehmensweiter Anwendungen ohne den Roboter 100 oder dazugehörige Roboter-Hardware. Anwender können die SDK Tools 1646 (z. B. Usage Monitor und Service Konfigurator) zum Hinzufügen oder Deaktivieren des Cloud-Diensts verwenden.
Bezugnehmend auf 17A und 17B empfängt der Roboter 100 unter bestimmten Umständen die Belegungskarte 1700 von Objekten 12 in einer Szene 10 und/oder Arbeitsbereich 5, oder der Roboter Kontrollschaltkreis 500 erzeugt (und aktualisiert u. U.) die Belegungskarte 1700 auf der Grundlage der Bilddaten und/oder Bildtiefendaten, die von dem Bildsensor 450 (z. B. der zweite 3-D Bildsensor 450b) im Laufe der Zeit empfangen wurden. Die simultane Lokalisierung und Kartierung (SLAM) ist eine Methode, die von dem Roboter 100 zur Ausgestaltung einer Karte 1700 innerhalb einer unbekannten Umgebung oder Szene 10 (ohne a priori-Wissen), oder zur Aktualisierung einer Karte 1700 innerhalb einer unbekannten Umgebung (mit a priori-Wissen einer bereitgestellten Karte) eingesetzt wird, während gleichzeitig der laufende Ort im Auge behalten wird. Karten 1700 können zur Festelegung eines Orts innerhalb einer Umgebung und zur Darstellung einer Umgebung zum Planen und Navigieren verwendet werden. Die Karten 1700 unterstützen die Abschätzung des laufenden Orts durch eine Aufzeichnung der Informationen, die von einer Wahrnehmungsform erhalten wurden, und vergleichen sie mit einem laufenden Satz an Wahrnehmungen. Der Vorteil einer Karte 1700 bei der Unterstützung der Abschätzung eines Orts erhöht sich, während die Präzision und Qualität der laufenden Wahrnehmungen abnimmt. Karten 1700 stellen in der Regel den Zustand zu dem Zeitpunkt dar, zu dem die Karte 1700 geliefert oder erstellt wird. Dies stimmt nicht unbedingt mit dem Zustand der Umgebung zum Zeitpunkt überein, zu dem die Karte 1700 benutzt wird. Andere Lokalisierungsmethoden umfassen MonoSLAM (monokulares visuelles SLAM) und Ausführungsformen, die einen erweiterten Kalman Filter (EKF) für MonoSLAM Lösungen einsetzen.
Der Kontrollschaltkreis 500 könnte ein Scale-invariant Feature Transform (SIFT) zum Erkennen und Beschreiben der lokalen Merkmale in erfassten Bildern ausführen. Zur Lieferung der ”Merkmalsbeschreibung” eines Objekts 12 in einen Bild können interessante Punkte des Objekts 12 extrahiert werden. Diese von einem Trainingsbild extrahierte Beschreibung kann dann zum Erkennen des Objekts 12 verwendet werden, wenn versucht wird, das Objekt 12 in einem viele andere Objekte enthaltendem Testbild zu finden. Zur Durchführung einer zuverlässigen Erkennung ist es wichtig, dass die von dem Trainingsbild extrahierten Merkmale erkennbar sind, und zwar auch bei veränderten Bildausmaßen, Rauschen und Beleuchtung. Diese Punkte liegen generell in Hochkontrastbereichen des Bildes, wie beispielsweise Objektkanten. Zur Erkennung und Entdeckung von Objekten kann der Roboter 100 einen SIFT verwenden, um markante Schlüsselpunkte zu finden, die invariant in☐Bezug auf Orte, Skalen und Drehungen sind und robust bleiben, um Veränderungen (Änderung des Maßstabs, der Drehung, Scherung und Position) und Beleuchtungsveränderungen zu affinieren. In einigen Ausführungsformen erfasst der Roboter 100 mehrere Bilder (unter Einsatz der Kamera 320 und/oder des Bildsensors 450) von einer Szene 10 oder einem Objekt 12 (z. B. unter verschiedenen Bedingungen, aus verschiedenen Blickwinkeln, usw.) und speichert die Bilder beispielsweise in einer Matrix. Der Roboter 100 kann auf die gespeicherten Bilder zur Erkennung eines neues Bilds durch einen Vergleich, Filter, usw. zugreifen. So können SIFT Merkmale zum Beispiel von einem Eingabebild erhalten und mit einer SIFT Merkmalsdatenbank verglichen werden, die von den (zuvor erfassten) Trainingsbildern erhalten wurde. Der Merkmalsvergleich kann durch einen euklidischen distanzbasierten nächster Nachbar-Ansatz vorgenommen werden. Die Hough Transform kann zur Erhöhung der Objekt-Ermittlung durch ein Clustering der Merkmale verwendet werden, die zum gleichen Objekt gehören und die Übereinstimmungen ablehnen, die aus dem Clustering-Prozess ausgelassen wurden. SURF (Speeded Up Robust Feature) kann ein robuster Bilderkennungs und -Descriptor sein.
Zusätzlich zur Lokalisierung des Roboters 100 in der Szene 10 (z. B. die Umgebung um den Roboter 100), kann sich der Roboter 100 zu sonstigen Punkten in einem angeschlossenen Raum (z. B. der Arbeitsbereich 5) unter Einsatz des Sensorsystems 400 begeben. Der Roboter 100 kann eine Bildsensorart 450a für kurze Reichweiten (z. B. an der Unterseite des Torso 140, wie in 1 und 3 abgebildet, befestigt) zum Mapping eines naheliegenden☐Bereichs um den Roboter 110 enthalten und relativ nahe Objekte 12 wahrnehmen, und eine Bildsensorart 450b für längere Reichweiten (z. B. am Kopf 160, wie in 1 und 3 dargestellt, befestigt) zum Mapping eines relativ größeren Bereichs über dem Roboter 100 enthalten und relativ entfernt liegende Objekte 12 wahrnehmen. Der Roboter 100 kann die Belegungskarte 1700 zum Erkennen bekannter Objekte 12 in der Szene 10 sowie auch Okklusionen 16 verwenden (z. B. wo ein Objekt 12 sein sollte oder nicht, was jedoch nicht von dem derzeitigen Blickwinkel bestätigt werden kann). Der Roboter 100 kann eine Okklusion 16 oder ein neues Objekt 12 in der Szene 10 registrieren und versuchen, zur Bestätigung des Orts des neuen Objekts 12 oder sonstiger Objekte 12 in der Okklusion 16 um die Okklusion 16 oder das neue Objekt 12 herumzufahren. Außerdem kann der Roboter 100 unter Einsatz der Belegungskarte 1700 die Bewegung eines Objekts 12 in der Szene 10 festlegen und verfolgen. So kann der Bildsensor 450, 450a, 450b beispielsweise eine neue Position 12' des Objekts 12 in der Szene 10 erkennen, während er eine gemappte Position von dem Objekt 12 in der Szene 10 nicht erkennt. Der Roboter 100 kann die Position des alten Objekts 12 als eine Okklusion 16 registrieren und versuchen, zur Bestätigung des Orts des Objekts 12 um die Okklusion 16 herumzufahren. Der Roboter 100 kann neue Bildtiefedaten mit vorherigen Bildtiefedaten (z. B. die Karte 1700) vergleichen und eine Vertrauensstufe für den Ort des Objekts 12 in der Szene 10 festsetzen. Innerhalb der Szene 10 kann für die Vertrauensstufe des Orts der Objekte 12 nach dem Zeitraum, für den ein Schwellwert gesetzt wurde, ein Zeitlimit bestehen. Das Sensorsystem 400 kann die Vertrauensstufe des Orts eines jeden Objekts 12 nach jedem Imaging-Zyklus des Sensorsystems 400 aktualisieren. In einigen Beispielen kann eine erkannte neue Okklusion 16 (z. B. ein fehlendes Objekt 12 von der Belegungskarte 1700) innerhalb eines Zeitraums zur Okklusionserkennung (z. B. weniger als zehn Sekunden) ein ”lebendes” Objekt 12 (z. B. ein sich bewegendes Objekt 12) in der Szene 10 bedeuten.
In einigen Ausführungsformen kann ein zweites Objekt 12b von Interesse, das sich hinter dem ersten Objekt 12a in der Szene 10 befindet, anfänglich nicht als eine Okklusion 16 in der Szene 10 erkannt werden. Eine Okklusion 16 kann der Bereich in der Szene 10 sein, der noch nicht von dem Bildsensor 450, 450a, 450b ohne weiteres erkannt oder gesehen werden kann. In dem dargestellten Beispiel verfügt das Sensorsystem 400 (z. B. oder ein Teil davon, wie beispielsweise Bildsensor 450, 450a, 450b) von dem Roboter 100 über ein Blickfeld 452 mit einem Sichtwinkel θ_V (der ein beliebiger Winkel zwischen 0 Grad und 360 Grad sein kann) zur Ansicht der Szene 10. In einigen Beispielen enthält der Bildsensor 450 eine omnidirektionale Optik für einen 360 Grad Sichtwinkel θ_V; während in anderen Beispielen der Bildsensor 450, 450a, 450b einen Sichtwinkel θ_V von weniger als 360 Grad (z. B. zwischen ca. 45 Grad und 180 Grad) hat. In Beispielen, in denen der Sichtwinkel θ_V kleiner als 360 Grad ist, kann sich der Bildsensor 450, 450a, 450b (oder diesbezügliche Bestandteile) in Bezug auf den Roboterkörper 110 drehen, um einen Sichtwinkel θ_V von 360 Grad zu erhalten. In einigen Ausführungsformen kann der Bildsensor 450, 450a, 450b oder diesbezügliche Teile sich in Bezug auf den Roboterkörper 110 und/oder das Antriebssystem 200 bewegen. Außerdem kann der Roboter 100 zum Erkennen der zweiten Objekts 12b den Bildsensor 450, 450a, 450b bewegen, indem er über die Szene 10 in eine oder mehrere Richtungen fährt (z. B. durch eine Umsetzung und/oder Drehung auf der Arbeitsfläche 5), um einen Aussichtspunkt zu erhalten, der ihm ein Erkennen des zweites Objekts 10b gestattet. Die Roboterbewegung oder unabhängige Bewegung des Bildsensors 450, 450a, 450b, oder diesbezüglicher Teile können auch eine Lösung bei monocularen Schwierigkeiten bieten.
Den erkannten Orten oder verfolgten Bewegungen der Objekte 12 kann in dem Arbeitsbereich 5 eine Vertrauensstufe zugeteilt werden. Zum Beispiel kann der Kontrollschaltkreis 500 nach der Erstellung oder Aktualisierung der Belegungskarte 1700 eine Vertrauensstufe für jedes Objekt 12 auf der Karte 1700 zuteilen. Die Vertrauensstufe kann direkt proportional zur Wahrscheinlichkeit sein, dass dieses Objekt 12 sich effektiv in dem Arbeitsbereich 5 wie auf der Karte 1700 angegeben befindet. Die Vertrauensstufe kann durch mehrere Faktoren festgelegt werden, wie beispielsweise die Anzahl und Art der zum Erkennen des Objekts 12 eingesetzten Sensoren. So kann der der Kontaktsensor 430 zum Beispiel die höchste Vertrauensstufe bieten, da der Kontaktsensor 430 den tatsächlichen Kontakt mit dem Objekt 12 durch den Roboter 100 wahrnimmt. Der Bildsensor 450 kann eine unterschiedliche Vertrauensstufe liefern, die höher als der Näherungssensor 430 ist. Die von mehr als einem Sensor von dem Sensorsystem 400 empfangenen Daten können hinzugefügt oder gesammelt werden, um eine relativ höhere Vertrauensstufe über alle einzelnen Sensoren zu liefern.
Die Odometrie ist der Gebrauch von aus der Bewegung der Aktuatoren gewonnenen Daten zum Schätzen der im Laufe der Zeit stattfindenden Änderung der Position (zurückgelegte Entfernung). In einigen Beispielen wird ein Encoder auf dem Antriebssystem 200 zur Messung der Raddrehungen angeordnet, d. h., die von Roboter 100 zurückgelegte Entfernung. Der Kontrollschaltkreis 500 kann die Odometrie zur Abschätzung einer Vertrauensstufe für einen Objekt-Ort verwenden. In einigen Ausführungsformen umfasst das Sensorsystem 400 ein Odometer und/oder einen Drehratensensor (z. B. Gyroskop oder den IMU 470) zum Abtasten der von dem Roboter 100 zurückgelegten☐Strecke. Ein Gyroskop ist eine Vorrichtung zum Messen oder zur Wahrung der Orientierung, die sich auf die konservatorischen Prinzipien des Drehimpulses stützt. Der Kontrollschaltkreis 500 kann die Odometrie und/oder die von dem Odometer bzw. dem Drehratensensor empfangenen Gyro-Signale zur Festlegung eines Orts des Roboters 100 in einem Arbeitsbereich 5 und/oder an einer Belegungskarte 1700. verwenden. In einigen Beispielen setzt der Kontrollschaltkreis 500 eine Koppelnavigation ein. Die Koppelnavigation ist ein Prozess zur Schätzung einer aktuellen Position, wobei sich auf eine zuvor festgelegte Position gestützt wird, die Vorwärtsbewegung dieser Position auf der Grundlage bekannter oder geschätzter☐Geschwindigkeiten über eine verstrichene Zeit, und zurückgelegte Entfernung. Durch das Kennen eines Roboter-Orts in dem Arbeitsbereich 5 (z. B. über die Odometrie, das Gyroskop, usw.) sowie auch eines abgetasteten Orts eines oder mehrerer Objekte 12 in dem Arbeitsbereich 5 (über das Sensorsystem 400) kann der Kontrollschaltkreis 500 eine relativ höhere Vertrauensstufe eines Orts oder einer Bewegung eines Objekts 12 auf der Belegungskarte 1700 und im Arbeitsbereich 5 abschätzen (im Vergleich zu keinem Gebrauch von Odometrie oder eines Gyroskops).
Die auf der Radbewegung basierte Odometrie kann elektrisch geräuschvoll ausfallen. Der Kontrollschaltkreis 500 kann Bilddaten von dem Bildsensor 450 von der Umgebung oder der Szene 10 um den Roboter 100 für die Berechnung der Roboterbewegung, unabhängig von der radbasierten Odometrie des Antriebssystems 200 durch visuelle Odometrie empfangen. Die visuelle Odometrie kann den Gebrauch eines optischen Flusses zur Festlegung der Bewegung des Bildsensors 450 erfordern. Der Kontrollschaltkreis 500 kann die berechnete Bewegung auf der Grundlage der Imaging-Daten des Bildsensors 450 zur Berichtigung irgendwelcher Fehler in der radbasierten Odometrie verwenden, was somit zu einer verbesserten Mapping- und Bewegungssteuerung führt. Die visuelle Odometrie ist mit Einschränkungen bei Szenen 10 mit geringer Textur oder niedriger Lichtstärke behaftet, wenn der Bildsensor 450 die Merkmale nicht innerhalb des/der erfassten Bilds/Bilder verfolgen kann.
Sonstige Einzelheiten und Merkmale über die Odometrie und Abbildungssysteme, die mit denen hier beschriebenen kombinierbar sind, sind im U.S. Patent 7.158.317 angegeben (Beschreibung eines ”Tiefenschärfe” Abbildungssystems) sowie auch in U.S. Patent 7.115.849 (Beschreibung von Wellenfront Coding Interferenz Kontrast Abbildungssystemen), deren Inhalte hiermit durch Verweis vollständig mit aufgenommen werden.
Wenn ein Roboter neu in einem Gebäude ist in welchem er arbeiten wird, muss ihm zur Gewährleistung einer autonomen Navigation u. U. die Umgebung gezeigt oder eine Gebäudekarte bereitgestellt werden (z. B. Zimmer und Flurstandorte). In einem Krankenhaus muss der Roboter zum Beispiel den Ort eines jeden Patientenzimmers, die Schwesternstationen, usw. kennen. In gewissen Ausführungsformen empfängt der Roboter 100 eine Karte der Anlage 1810, wie beispielsweise die in 18A abgebildete Karte, und kann auf eine Erlernung des Lageplans 1810 trainiert werden. Wenn der Roboter 100 zum Beispiel um das Gebäude geführt wird, kann er dabei spezifische Orte aufzeichnen, die den Orten auf dem Lageplan 1810 entsprechen. Der Roboter 100 kann den Lageplan 1810 auf dem Web-Pad 310 anzeigen. Wenn ein Anwender den Roboter 100 zu einen spezifischen Ort führt, kann der Nutzer diesen Ort auf dem Lageplan 1810 kennzeichnen (z. B. auf einem Berührungsbildschirm oder sonstigem Zeigegerät des Web-Pads 310). Der Nutzer kann eine Beschriftung für einen gekennzeichneten Ort, wie beispielsweise ein Zimmername oder eine Zimmernummer eingeben. Zum Zeitpunkt der Kennzeichnung kann der Roboter 100 das Kennzeichen mit einem Punkt auf dem Lageplan 1810 und einem entsprechenden Punkt auf dem Roboterplan 1820, wie beispielsweise der in 18B abgebildete Plan, speichern.
Mit dem Sensorsystem 400 kann der Roboter 100 den Roboterplan 1820 während des Herumbewegens erstellen. Zum Beispiel kann das Sensorsystem 400 Informationen darüber liefern, wie weit der Roboter 100 sich bewegt hat und über seine Fahrtrichtung. Zusätzlich zu den im Lageplan 1810 gelieferten Wanden kann der Roboterplan 1820 auch feste Hindernisse enthalten. Der Roboter 100 kann den Roboterplan 1820 zur Durchführung einer autonomen Navigation verwenden. In dem Roboterplan zu 1820 sehen die ”Wände” zum Beispiel wegen einer erkannten Verdichtung, die in der Wand im entsprechenden Flur besteht und/oder aufgrund von in verschiedenen Zellenbüros erkannten Möbeln u. U. nicht völlig gerade aus. Außerdem können Dreh- und Auflösungsunterschiede zwischen dem Lageplan 1810 und dem Roboterplan 1820 vorhanden sein.
Nach dem Plantraining, wenn ein Nutzer den Roboter 100 an einen Ort schicken möchte, kann der Nutzer sich entweder auf eine Beschriftung bzw. ein Kennzeichen (z. B. man gibt eine Beschriftung oder ein Kennzeichen in ein Ort-Textfeld ein, das auf dem Web-Pad 310 angezeigt wurde) beziehen oder der Roboter 100 kann den Lageplan 1810 dem Nutzer auf dem Web-Pad 310 anzeigen, woraufhin der Nutzer dann den Ort auf dem Lageplan 1810 auswählen kann. Wenn der Nutzer einen gekennzeichneten Lageplanort auswählt, kann der Roboter 100 mühelos den Ort auf dem Roboterplan 1820 festlegen, der dem ausgewählten Ort auf dem Lageplan 1810 entspricht und dann mit der Navigation zu dem ausgewählten Ort fortfahren.
Wenn der ausgewählte Ort auf dem Lageplan 1810 kein gekennzeichneter Ort ist, legt der Roboter 100 einen entsprechenden Ort auf dem Roboterplan 1820 fest. In einigen Ausführungsformen berechnet der Roboter 100 die Skalierungsgröße, das Ursprungsmapping und die Drehung zwischen dem Lageplan 1810 und dem Roboterplan 1820 unter Einsatz bestehender gekennzeichneten Orte, und wendet dann die berechneten Parameter zur Feststellung des Roboterplanorts an (z. B. unter Einsatz einer affinen Transformation oder von Koordinaten).
Der Roboterplan 1820 kann nicht die gleiche Orientierung und Maßstab wie der Lageplan 1810 sein. Außerdem ist der Lageplan u. U. nicht maßstabsgerecht und kann Verzerrungen enthalten, die je nach Planbereich variieren. Zum Beispiel kann ein Lageplan 1810, der durch das Einscannen eines Fluchtwegplans im Falle eines Brands, die man üblicherweise in Hotels, Büros und Krankenhäusern sieht, generell nicht maßstabsgerecht sein und kann sogar verschiedene Maßstäbe in verschiedenen Bereichen des Plans haben. Der Roboterplan 1820 kann seine eigenen Verzerrungen haben. So können zum Beispiel Orte auf dem Roboterplan 1820 durch ein Zählen der Raddrehungen als Abstandsmesser berechnet worden sein, und falls der Fußboden etwas rutschig war oder das um die Ecken fahren eine zusätzliche Raddrehung bewirkte, können ungenaue Umdrehungsberechnungen dazu führen, dass der Roboter 100 ungenaue Orte gemappter Objekte festlegt.
Ein Verfahren zur Abbildung eines vorgegebenen Punkts 1814 auf dem Lageplan 1810 auf einen entsprechenden Punkt 1824 auf dem Roboterplan 1820 kann die Verwendung vorhandener gekennzeichneter 1812 Punkte zur Berechnung einer lokalen Verzerrung zwischen dem Lageplan 1810 und dem Roboterplan 1820 in einem Bereich (z. B. innerhalb eines Schwellradius), der den Lageplan-Punkt enthält, umfassen. Die Verfahren umfasst weiterhin eine Verzerrungsberechnung für den Lageplan-Punkt 1814 zur Ermittlung eines entsprechenden Roboterplan-Punkts 1824. Dies kann auch umgekehrt durchgeführt werden, wenn man mit einem vorgegebenen Punkt auf dem Roboterplan 1820 beginnt und einen entsprechenden Punkt auf dem Lageplan 1810 ermitteln möchte, um beispielsweise den Roboter zur Angabe seines jetzigen Standorts aufzufordern.
18C liefert eine beispielgebende Anordnung 1800 von Abläufen zum Betrieb des Roboters 100 zur Navigation in einer Umgebung mit Hilfe des Lageplans 1810 und des Roboterplans 1820. Bezugnehmend auf 18B und 18C umfassen die Abläufe den Empfang 1802c eines Lageplans 1810, der einer Umgebung des Roboters 100 entspricht, die Bewegung 1804c des Roboters 100 in der Umgebung zu einem Lageplan-Ort 1812 auf dem Lageplan 1810, die Aufzeichnung 1806c eines Roboterplan-Orts 1822 auf dem Roboterplan 1820, die der Umgebung entspricht und von dem Roboter 100 erstellt wurde, die Festlegung 1808c einer Verzerrung zwischen dem Roboterplan 1820 und dem Lageplan 1810 unter Einsatz der aufgezeichneten Roboterplan-Orte 1822 und den entsprechenden Lageplan-Orten 1812, und die Anwendung 1810c der festgelegten Verzerrung auf einen Zielort auf dem Lageplan 1814 zur Bestimmung eines entsprechenden Zielorts auf dem Roboterplan 1824, was somit dem Roboter die Navigation zu dem ausgewählten Ort 1814 auf dem Lageplan 1810 gestattet. In gewissen Ausführungsformen umfassen seine Abläufe die Festlegung einer Skalierungsgröße, Ursrpungsabbildung, und Drehung zwischen dem Lageplan und dem Roboterplan unter Einsatz vorhandener gekennzeichneter Orte und die Bestimmung eines Roboterplan-Orts, der dem ausgewählten Zielort des Lageplans 1814 entspricht. Die Abläufe können die Anwendung einer affinen Transformation auf die festgelegte Skalierungsgröße, Ursrpungsabbildung und Drehung zur Bestimmung des Roboterplan-Orts umfassen.
Bezugnehmend auf 19A–19C umfasst das Verfahren in einigen Ausführungsformen den Gebrauch gekennzeichneter Lageplan-Punkte 1912 (auf die sich auch als die aufgezeichneten Lageplan-Orte bezogen wird) zur Ableitung einer Triangulation von einem Bereich innerhalb einer begrenzenden Form, welche die gekennzeichneten Lageplan-Punkte 1912 enthält, und zwar so, dass alle Bereiche auf dem Lageplan 1810 von mindestens einem Dreieck 1910 erfasst werden, dessen Eckpunkte in den gekennzeichneten Lageplan-Punkten 1912 enthalten sind. Das Verfahren umfasst weiterhin eine Ermittlung des Dreiecks 1910, das den ausgewählten Lageplan-Punkt 1914 enthält sowie auch die Festlegung des Maßstab, der Drehung, Umsetzung und des Bildversatzes zwischen dem Dreieck 1910, das auf dem Lageplan 1810, und einem entsprechenden Dreieck 1920, das auf dem Roboterplan 1820 abgebildet ist (d. h., das Roboterplan-Dreieck mit denselben gekennzeichneten Eckpunkten). Die Verfahren umfasst die Anwendung des festgelegten Maßstabs, Drehung, Umsetzung und des Bildversatzes auf den ausgewählten Lageplan-Punkt 1914 zur Ermittlung eines entsprechenden Roboterplan-Punkts 1924.
19C liefert eine beispielgebende Anordnung 1900 von Abläufen zur Festlegung des Zielorts des Roboterplans 1924. Die Abläufe umfassen die Festlegung 1902 einer Triangulation zwischen den Lageplan-Orten, die den Zielort des Lageplans begrenzen, die Festlegung 1904 eines Maßstabs, Drehung, Umsetzung und eines Bildversatzes zwischen dem im Lageplan abgebildeten Dreieck und eines entsprechenden im Roboterplan abgebildeten Dreiecks sowie auch die Anwendung 1906 des festgelegten Maßstabs, Drehung, Umsetzung und des Bildversatzes auf den Zielort des Lageplans zur Bestimmung des entsprechenden Roboterplan-Punkts.
Bezugnehmend auf 20A und 20B umfasst das Verfahren in einem anderen Beispiel die Festlegung der Entfernungen von allen gekennzeichneten Punkten 1912 in dem Lageplan 1810 zu dem ausgewählten Lageplan-Punkt 1914, und die Festlegung eines Schwerpunkts 2012 der gekennzeichneten Punkte des Lageplans 1912. Das Verfahren umfasst ebenfalls die Festlegung eines Schwerpunkts 2022 aller gekennzeichneten Punkte 1922 auf dem Roboterplan 1820. Für jeden gekennzeichneten Lageplan-Punkt 1912 umfasst das Verfahren die Festlegung einer Drehung und einer Längenskalierung, welche zur Umwandlung des Vektors 2014 erforderlich ist, der auf dem Lageplan-Schwerpunkt 2012 zu dem ausgewählten Anlagen-Punkt 1914 in einen Vektor 2024 verläuft, der von dem Roboterplan-Schwerpunkt 2022 zu dem Roboterplan-Punkt 1924 verläuft. Unter Einsatz dieser Daten umfasst das Verfahren weiterhin die Festlegung einer durchschnittlichen Drehung und eines Maßstabs. Für jeden gekennzeichneten Lageplan-Punkt 1912 umfasst das Verfahren weiterhin die Festlegung eines ”idealen Roboterplan Koordinaten”-Punkts 1924i durch die Anwendung der Umsetzungen des Schwerpunkts, der durchschnittlichen Drehung und des durchschnittlichen Maßstabs auf den ausgewählten Lageplan-Punkt 1914. Außerdem umfasst das Verfahren für jeden gekennzeichneten Lageplan-Punkt 1912 die Festlegung einer Entfernung von diesem Lageplan-Punkt 1912 zu dem ausgewählten Lageplan-Punkt 1914 und die Sortierung der gekennzeichneten Lageplan-Punkte 1912 nach diesen Entfernungen, und zwar von der kürzesten zur längsten Entfernung. Das Verfahren umfasst die Festlegung eines ”Einflussfaktors” für jeden gekennzeichneten Lageplan-Punkt 1912, wobei entweder das inverse Quadrat von der Entfernung zwischen jedem gekennzeichneten Lageplan-Punkt 1912 oder der ausgewählte Lageplan-Punkt 1914 verwendet wird. Danach umfasst das Verfahren für jeden gekennzeichneten Lageplan-Punk 1912 die Festlegung eines Vektors, der den Unterschied zwischen dem ”idealen Roboterplan-Koordinaten”-Punkt 1924i und dem Roboterplan-Punkt 1924 darstellt, der von den Einflussfaktoren der gekennzeichneten Lageplan-Punkte 1912 anteilsmäßig zugeordnet wurde. Das Verfahren umfasst die Summierung der anteilsmäßig zugeordneten Vektoren und deren Hinzufügung zum ”idealen Roboterplan-Koordinaten”-Punkt 1924i für der ausgewählten Lageplan-Punkt 1914. Das Ergebnis ist der entsprechende Roboterplan-Punkt 1924 auf dem Roboterplan 1820. In einigen Beispielen umfasst dieses Verfahren bzw. dieser Algorithmus nur den nächstliegenden N gekennzeichneten Lageplan-Punkt 1912 anstelle aller gekennzeichneten Lageplan-Punkte 1912.
20C liefert eine beispielgebende Anordnung 2000 von Abläufen zur Festlegung eines Zielorts des Roboterplans 1924 mit Hilfe des Lageplans 1810 und des Roboterplans 1820. Die Abläufe umfassen die Festlegung 2002 von Entfernungen zwischen allen Lageplan-Orten und dem Zielort des Lageplans, die Festlegung 2004 eines Schwerpunkts der Lageplan-Orte, die Festlegung 2006 eines Schwerpunkts aller aufgezeichneten Roboterplan-Orte, und für jeden Lageplan-Ort die Festlegung 2006 einer Drehung und Längenskalierung zur Umwandlung eines Vektors, der von dem Lageplan-Schwerpunkt zum Zielort des Lageplans in einen Vektor verläuft, der von dem Roboterplan-Schwerpunkt zu dem Zielort des Roboterplans verläuft.
Wiederum bezugnehmend auf 16C könnte der Nutzer es wünschen, den Roboter 100 durch die Anwendung 1610 zu steuern und zu verwalten, obwohl der Roboter 100 sich selbständig bewegen und agieren kann. So könnte ein Nutzer zum Beispiel die Bewegung des Roboters 100 innerhalb einer Umgebung oder Szene 10 beispielsweise dadurch steuern oder definieren wollen, indem er Navigationspunkte auf einer Karte bereitstellt. In einigen Ausführungsformen erlaubt die Kartenerstellunganwendung 1610a dem Nutzer die Erstellung einer Belegungskarte 1700 (17A) oder eines Lageplans 1810 (18A) von einer Szene 10 auf der Grundlage von Sensordaten, die von dem Sensorsystem 400 eines oder mehrerer Roboter 100 in der Szene 10 erzeugt wurden. In einigen Beispielen können Roboterkarten 1810 zur Erstellung eines oder mehrerer vektor-basierter Anlagenpläne 1810 nachverarbeitet werden. Die Kartenerstellunganwendung 1610a kann dem Nutzer eine individuelle Anpassung der Karten 1700, 1810 ermöglichen (z. B. Ausrichtung der Wände, die parallel aussehen sollten, usw). Außerdem können Annotationen, die vom Roboter 100 und der Anwendung 1610a (und/oder sonstigen Anwendungen 1610) erkannt werden können, den Karten 1700, 1810 hinzugefügt werden. In einigen Ausführungsformen der Kartenerstellunganwendung 1610a können Roboterplandaten, Lageplandaten, anwenderdefinierte Objekte und Annotationen in der Cloudspeicherung 1622 in der Cloud 1620 durch einen Cloud-Dienst sicher gespeichert werden. Der Cloud-Dienst schiebt die relevanten Datensätze zu den entsprechenden Robotern 100 bzw. Anwendungen 1610.
In einigen Ausführungsformen erlaubt die Abbildungs- und Navigations-Anwendung 1610b (16C) dem Nutzer, einen Zielort auf dem Lageplan 1810 zu bestimmen und den Roboter 100 aufzufordern, zu diesem Zielort zu fahren. Zum Beispiel kann ein Nutzer die Abbildungs- und Navigations-Anwendung 1610b auf einer Rechnervorrichtung, wie beispielsweise einem Computer, Tablet-Computer, einer mobilen Vorrichtung, usw. ausführen, die mit der Cloud 1620 in Verbindung steht. Der Nutzer kann auf einen Lageplan 1810 der Umgebung des Roboters 100 zugreifen, einen Zielort markieren oder auf sonstige Weise auf dem Lageplan 1810 einstellen und den Roboter 100 dazu auffordern, sich an den Zielort zu begeben. Der Roboter 100 kann dann autonom zum Zielort mithilfe des Lageplans 1810 und/oder des entsprechenden Roboterplans 1820 navigieren. Für die Navigation zum Zielort kann der Roboter 100 sich auf seine Fähigkeit verlassen, seinen Wahrnehmungsraum zu erkennen (d. h., den Umgebungsraum des Roboters 100, den er durch das Sensorsystem 400 wahrnimmt), und eine Strategie zur Objekterkennung Hindernisvermeidung (ODOA) ausführen.
Bezugnehmend auf 11B und 21A–21D unterteilt der Roboter 100 in einigen Ausführungsformen (z. B. das in 13 dargestellte Steuerungssystem 510) seinen lokalen Wahrnehmungsraum in drei Kategorien: Hindernisse (schwarz) 2102, unbekannt (grau) 2104, und als frei bekannt (weiß) 2106. Die Hindernisse 2102 sind beobachtete (d. h., abgetastete) Punkte über dem Boden G, die unter der Höhe des Roboters 100 liegen und der beobachteten Punkte under dem Boden G (z. B. Löcher, absteigende Stufen, usw.). Als frei bekannt 2106 entspricht Bereichen, wo die 3-D Bildsensoren 450 den Boden G sehen können. Die Daten aller Sensoren im Sensorsystem 400 können in einem diskretisierten 3-D Voxelgitter kombiniert werden. Die 3-D Gitter können daraufhin analysiert und in das 2-D Gitter 2100 mit den drei lokalen Einteilungen des Wahrnehmungsraums umgewandelt werden. 21A liefert eine beispielgebende schematische Ansicht des lokalen Wahrnehmungsraums des Roboters 100, während er ruht. Die Informationen in dem 3-D Voxelgitter sind beständig, jedoch wird ein im Laufe der Zeit stattfindender Verfall nicht wieder herstellt. Während sich der Roboter 100 bewegt, verfügt er zur Navigation über einen größeren als frei bekannten Bereich 2106 aufgrund seiner BeständigkeitPersistenz.
Die Navigationsstrategie Objekterkennung Hindernisvermeidung (ODOA) für das Steuerungssystem 510 kann entweder die Annahme oder Ablehnung potenzieller Roboterpositionen mit sich führen, die sich infolge der Befehle ergeben würden. Die potenziellen Roboterpfade 2110 können viele Ebenen tief mit verschiedenen Befehlen und den sich daraus ergebenden Roboterpositionen auf jeder Ebene erzeugt werden. 21B liefert eine beispielgebende schematische Ansicht des lokalen Wahrnehmungsraums von Roboter 100, während er sich bewegt. Das ODOA Verhalten 600b (13) kann jeden vorhergesagten Roboterpfad 2110 auswerten. Diese Auswertungen können von der Vorrichtung zur Handlungsauswahl 580 zur Bestimmung eines bevorzugten Ergebnisses und eines entsprechenden Roboterbefehls verwendet werden. Zum Beispiel kann das ODOA Verhalten 600b für jede Roboterposition 2120 auf dem Roboterpfad 2110 ein Verfahren zur Objekterkennung und Hindernisvermeidung ausführen, das das Erkennen jeder Zelle in dem Gitter 2100 umfasst, das ein begrenzender Kasten um eine entsprechende Position des Roboters 100 darstellt, und eine Klassifizierung von jeder Zelle empfängt. Für jede als ein Hindernis gewertete oder unbekannte Zelle, Abfrage eines der Zelle entsprechenden Gitterpunkts, und Durchführung einer Kollisionsprüfung, indem festgelegt wird, ob der Gitterpunkt sich innerhalb eines Kollisionskreises über dem Ort des Roboters 100 befindet. Sollte der Gitterpunkt sich innerhalb des Kollisionskreises befinden, umfasst das Verfahren weiterhin die Durchführung einer Dreieck-Prüfung, um herauszufinden, ob der Gitterpunkt sich innerhalb eines Kollisions-Dreiecks befindet (z. B. der Roboter 100 kann als ein Dreieck gestaltet sein). Sollte der Gitterpunkt sich innerhalb des Kollisions-Dreiecks befinden, umfasst das Verfahren ein Ablehnen des Gitterpunkts. Sollte sich die Roboterposition innerhalb eines Ansichtsfelds eines Sensorsystems von Ausgangsgitterpunkten auf dem Roboterpfad 2110 befinden, werden die ”unbekannten” Gitterpunkte außer Acht gelassen, da angenommen wird, dass diese Gitterpunkte zu dem Zeitpunkt bekannt sind, wenn der Roboter 100 sie erreicht.
Das Verfahren kann die Festlegung umfassen, ob Hinderniskollisionen im Roboterpfad-Bereich (z. B. als Rechteck gestaltet) zwischen aufeinanderfolgenden Roboterpositionen 2120 auf dem Roboterpfad 2110 vorliegen, um Kollisionen des Roboters während des Übergangs von einer Roboterposition 2120 zur nächsten zu verhindern.
21C liefert eine schematische Ansicht des lokalen Wahrnehmungsraums von Roboter 100 und ein Ansichtsfeld des Sensorsystems 405 (das Steuerungssystem 510 kann nur gewisse Sensoren zur Festlegung des Roboterpfads verwenden, wie beispielsweise die ersten und zweiten 3-D Bildsensoren 450a, 450b). Der Roboter 100 bedient sich der holonomen Beweglichkeit des Antriebssystems 200, und setzt die Beständigkeit des bekannten Bodens G ein, um sich ein Fahren in Richtungen zu ermöglichen, wo das Ansichtsfeld des Sensorsystems 405 keine effektive Erfassung liefert. Wenn der Roboter 100 beispielsweise ruht, während die ersten und zweiten 3-D Bildsensoren 450a, 450b nach vorne gerichtet sind, wird das Steuerungssystem 510 die vorgeschlagene Bewegung ablehnen – obwohl der Roboter 100 seitwärts fahren kann –, da der Roboter 100 nicht weiß, was sich auf seiner Seite befindet, wie in dem in 21C veranschaulichten Beispiel erkenntlich ist, wo ein als unbekannt klassifizierter Bereich an der Seite des Roboters 100 dargestellt wird. Sollte der Roboter 100 vorwärts fahren, während die ersten und zweiten 3-D Bildsensoren 450a, 450b nach vorn gerichtet sind, kann der Boden G neben dem Roboter 100 als als frei bekannt 2106 eingestuft werden, da die ersten und zweiten 3-D Bildsensoren 450a, 450b den Boden G als frei sehen können, während der Roboter 100 vorwärts fährt und die Beständigkeit der Klassifizierung noch nicht verfallen ist. (Siehe z. B. 21B.) In diesen Situationen kann der Roboter 100 seitwärts fahren.
Bezugnehmend auf 21D kann das ODOA Verhalten 600b angesichts vieler möglicher Bewegungsbahnen mit holonomer Beweglichkeit in einigen Beispielen dazu führen, dass der Roboter Bewegungsbahnen auswählt, wo er sieht, wohin er fährt (obwohl dies zur Zeit noch nicht möglich ist). Zum Beispiel kann der Roboter 100 die Ansichtsfeldorientierungen des Sensors voraussehen, die dem Steuerungssystem 510 die Erkennung von Objekten erlauben. Der Roboter kann das Ansichtsfeld des Sensors 405 während der Fahrt erweitern, da er sich während der Umsetzung drehen kann.
Wenn man das Ansichtsfeld 405 des Sensorsystems 400 versteht und was es bei verschiedenen Positionen sehen kann, kann der Roboter 100 Bewegungsbahnen auswählen, die ihm dabei helfen, seine Fahrtrichtung zu sehen. Wenn der Roboter 100 zum Beispiel um eine Ecke fährt, kann er Bewegungsbahnen ablehnen, die eine scharfe Kurve um die Ecke vorschlagen, da der Roboter 100 in eine Roboterposition 2120 geraten könnte, die nicht das Ansichtsfeld des Sensorsystems 405 der Ausgangsroboterposition 2120 darstellt, und die er zur Zeit nicht kennt, wie in 21E dargestellt. Stattdessen kann der Roboter 100 eine Bewegungsbahn auswählen, die abbiegt, um einer gewünschten Bewegungsrichtung rechtzeitig gegenüberzustehen und um die holonome Beweglichkeit von Antriebssystem 200 für eine Seitwärtsbewegung und ein anschließendes gerades Fahren um die Ecke zu nutzen, wie in 21F dargestellt.
In einigen Beispielen enthält die Abbildungs- und Navigations-Anwendung 1610b (16C) eine Fernbedienung. So kann der Nutzer den Roboter 100 zum Beispiel mithilfe einer Video Wegpunktfahrt (z. B. mithilfe einer oder mehrere der Kameras oder Bildsensoren 320, 450) fahren. Der Nutzer kann die Höhe H_L des Beins 130 ändern, um die Höhe H_T des Torsos 140 (14) zu erhöhen bzw. zu verringern, um somit das Ansichtsfeld einer der Bildsensoren 450 zu ändern und/oder den Roboterkopf 160 zu schwenken und/oder zu kippen, um das Ansichtsfeld einer/s unterstützten Kamera 320 oder Bildsensors 450, 450b zu ändern (siehe z. B. 11A und 11B). Außerdem kann der Nutzer den Roboter über seine z-Achse mithilfe des Antriebssystems 200 drehen, um sonstige Ansichtsfelder von den Kameras oder Bildsensoren 320, 450 zu erhalten. In einigen Beispielen gestattet die Abbildungs- und Navigationsanwendung 1610b dem Nutzer zwischen mehreren Anlagenplänen 1810 hin- und herzuwechseln (z. B. für verschiedene Umgebungen oder verschiedene Roboter 100) und/oder mehrere Roboter 100 auf nur einem Lageplan 1810 zu manipulieren. Die Abbildungs- und Navigationsanwendung 1610b kann mit dem Cloud-Dienst API kommunizieren, um den Richtlinien über den ordnungsgemäßen Gebrauch von Robotern Nachdruck zu verleihen, die von den Besitzern oder Organisationen des Roboters 100 dargelegt wurden.
Wiederum bezugnehmend auf 16C erlaubt die Videokonferenz-Anwendung 1610c dem Nutzer in einigen Ausführungsformen die Eröffnung von und/oder Teilnahme an einer Videokonferenzsitzung mit anderen Nutzern. In einigen Beispielen erlaubt die Videokonferenz-Anwendung 1610c dem Nutzer die Eröffnung von und/oder Teilnahme an einer Videokonferenzsitzung mit einem Nutzer des Roboters 100, einem Fernnutzer an einer mit der Cloud 1620 verbundenen Rechnervorrichtung und/oder einem weiteren Fernnnutzer, der am Internet mittels eines mobilen Endgeräts angeschlossen ist. Die Videokonferenz Anwendung 1610c kann ein elektronisches Whiteboard für den Informationsaustausch bereitstellen sowie auch ein Bildbetrachtungsprogramm und/oder einen PDF-Betrachter.
Die Planungsanwendung 1610d erlaubt dem Nutzer den Einsatz von einem oder mehrere Robotern 100 zu terminieren. Sollte es weniger Roboter 100 als Personen geben, die sie nutzen möchten, wird der Roboter 100 zu einer knappen Ressource und eine Terminplanung müsste u. U. in Betracht gezogen werden. Die Terminplanung hilft bei der Lösung von Konflikten bei der Ressourcenverteilung und ermöglicht einen höheren Ressourceneinsatz. Die Planungsanwendung 1610d kann auf Roboter fixiert sein und kann mit Kalendersystemen Dritter, wie beispielsweise Microsoft Outlook oder Google Calendar integriert werden. In einigen Beispielen kommuniziert die Planungsanwendung 1610d mit der Cloud 1620 durch einen oder mehrere Cloud-Dienste, um den Roboter 100 zu im Vorfeld anberaumten Zeiten zu entsenden. Die Planungsanwendung 1610d kann zeit-bezogene Daten (z. B. Instandhaltungskalender, usw.) mit sonstigen Roboterdaten (z. B. Roboterorte, Gesundheitszustand, usw.) integrieren, um eine Auswahl an Robotern 100 von den Cloud-Diensten für von dem Nutzer bestimmte Aufgaben auszuwählen.
So könnte ein Arzt in einem Szenario auf die Planungsanwendung 1610d auf einer Rechnervorrichtung (z. B. ein tragbarer Tablet-Computer oder ein Handgerät) zugreifen, die mit der Cloud 1620 verbunden ist, um seine Visiten in einem entfernt liegenden Krankenhaus zu terminieren. Die Planungsanwendung 1610d kann Roboter 100 genauso ähnlich terminieren, wie man ein Konferenzzimmer auf einem elektronischen Kalender reservieren würde. Der Cloud-Dienst verwaltet die Terminpläne. Sollte der Arzt mitten in der Nacht einen Anruf erhalten, um einen kritisch kranken Patienten in einem entfernt liegenden Krankenhaus zu untersuchen, kann der Arzt einen Roboter 100 mithilfe der Planungsanwendung 1610d anfordern und/oder einen Roboter 100 zu dem Patientzimmer mithilfe der Abbildungs- und Navigationsanwendung 1610b schicken. Der Arzt kann dann auf die Behandlungsunterlagen auf seiner Rechnervorrichtung (z. B. durch Zugriff auf die Cloudspeicherung 1622) sowie auch auf das Video oder Patientenbilder mithilfe der Videokonferenz-Anwendung 1610c zugreifen. Der Cloud-Dienst kann mit der Roboterverwaltung, einem elektronischen Patientenaktensystem und medizinischen Bildgebungssystemen integriert werden. Der Arzt kann die Bewegung des Roboters 100 fernsteuern und mit dem Patienten sprechen. Sollte der Patient nur Portuguiesisch sprechen, kann die Videokonferenz-Anwendung 1610c automatisch Sprachen übersetzen oder ein Dolmetscher könnte an der Videokonferenz mithilfe einer anderen Rechnervorrichtung teilnehmen, die mit der Cloud 1620 (z. B. über das Internet) verbunden ist. Die Dolmetscherdienstleistungen können mithilfe des Cloud-Diensts angefordert, erbracht, aufgezeichnet und in Rechnung gestellt werden.
Die Gebrauchs-/Statistik-Anwendung 1610e kann eine Mehrzweck-Anwendung für Nutzer zur Überwachung des Robotereinsatzes, der Erstellung von Robotereinsatzberichten und/oder zur Verwaltung einer Roboter 100 Flotte darstellen. Des Weiteren kann diese Anwendung 1610e allgemeine Betriebs- und Fehlersucheinformationen für den Roboter 100 liefern. In einigen Beispielen der Gebrauchs-/Statistik-Anwendung 1610e wird dem Nutzer erlaubt, mit dem Roboter 100 in Verbindung stehende Dienste hinzuzufügen bzw. zu deaktivieren, den Gebrauch von einem oder mehrere Simulatoren 1670 anzumelden, die Nutzungsrichtlinien für den Roboter abzuändern, usw.
In einem anderen Szenario könnte ein Unternehmen über eine Flotte an Robotern 100 für mindestens eine Telepräsenz-Anwendung verfügen. Ein Standortmanager könnte den Status eines oder emehrerer Roboter 100 (z. B. Ort, Gebrauch und Wartungspläne, Akku-Info, Ortshistorie, usw.) mithilfe der Gebrauchs-/Statistik-Anwendung 1610e überwachen, was auf einer mit der Cloud 1620 (z. B. über das Internet) verbundenen Rechnervorrichtung ausgeführt werden kann. In einigen Beispielen kann der Standortmanager einen Nutzer mit einer Roboter-Frage per Teilnahme an einer Nutzersitzung unterstützen. Der Standortmanager kann Befehle an die anderen Roboter 100 mithilfe der Anwendung 1610 zum Navigieren der entsprechenden Roboter 100 erteilen, durch der Roboter 100 (d. h., Telepräsenz sprechen), in den Stromsparmodus eintreten (z. B. Verringerung der Funktionalität), ein Ladegerät finden, usw. Der Standortmanager oder ein Nutzer können Anwendungen 1610 zur Verwaltung der Nutzer, Sicherheit, Anlagenpläne 1810, Ansichtsfelder der Videos, Hinzufügen/Entfernen der Roboter zu/von der Flotte, und mehr verwenden. Die Fernbediener des Roboters 100 können einen Robotertermin anberaumen/verlegen/absagen (z. B. mithilfe der Planungsanwendung 1610d) und einen Trainingslehrgang mithilfe eines simulierten Roboters besuchen, der sich in einem simulierten Bereich bewegt (z. B. mithilfe eines Simulators 1670, der auf einem Cloud Server ausgeführt wird).

Die SDK Bibliotheken 1644 können eine oder mehreree Quellcode-Bibliotheken für den Gebrauch der Entwickler 1602 der Anwendungen 1610 umfassen. Zum Beispiel kann eine visuelle Komponentenbibliothek eine graphische Nutzer-Schnittstelle oder visuelle Komponenten mit Schnittstellen zum Zugriff auf die gekapselte Funktionalität liefern. Beispielgebende visuelle Komponenten umfassen Codeklassen zur Zeichnung von Lageplanziegeln und Robotern, Videokonferenzen, Betrachtungen von Bildern und Dokumenten und/oder die Anzeige von Kalendern oder Terminplänen. Eine Roboter Kommunikationsbibliothek (z. B. ein Web-Services-API) kann einen RESTful (Representational State Transfer), JSON(JavaScript Object Notation)-basierten API für eine direkte Verbindung mit dem Roboter 100 liefern. Die Roboter-Kommunikationsbibliothek kann Objective-C Binding (z. B. für die iOS-Entwicklung) und Java Binding (z. B. für die Android-Entwicklung) anbieten. Diese Objekt-orientierten APIs gestatten den Anwendungen 1610, mit dem Roboter 100 zu kommunizieren, während gleichzeitig von den Entwicklern 1602 ein zugrundeliegendes Datenübermittlungsprotokoll bzw. -protokolle des Roboters 100 gekapselt werden. Eine Person, die die Routinen der Roboter-Kommunikationsbibliothek befolgt, kann eine Videobildschirm-Koordinate, die einer von dem Roboter 100 verfolgten Person entspricht zurückschicken. Eine Gesichtserkennungsroutine der Roboter-Kommunikationsbibliothek kann die Koordinate eines Gesichts auf eine Kameraansicht der Kamera 320 zurückschicken sowie auch auf Wunsch den Namen der erkannten verfolgten Person. Tabelle 1 liefert eine beispielgebende Liste von Roboter-Kommunikationdienstleistungen.

Dienstleistung	Beschreibung
Datenbankservice	Liste aller verfügbaren Kartendatenbanken im Roboter 100.
Datenbankservice erstellen	Roboterplan-Datenbank erstellen
Datenbankservice löschen	Roboterplan-Datenbank löschen
Listenservice abbilden	Eine Liste der Karten einer Kartendatenbank zu Roboter 100 zurückschicken.
Kartenservice	Zurücksenden einer spezifischen Roboterkarte.
Kartenservice erstellen	Roboterplan in einer Datenbank erstellen.
Kartenservice löschen	Roboterplan von einer Datenbank löschen.
Verschlagwortungsservice erstellen	Ein Kennzeichen für eine Karte in einer Datenbank erstellen (z. B. durch die Bereitstellung von x, y und z Koordinaten der Kennzeichnungsposition eines Orientierungswinkels des Roboters, in Radianten und eine Kurzbeschreibung der Kennzeichen).
Verschlagwortungsservice löschen	Ein Kennzeichen für eine Karte in einer Datenbank löschen.
Verschlagwortungsservice auflisten	Kennzeichen für eine spezifische Karte in einer bestimmten Datenbank auflisten.
Kameraservice	Verfügbare Kameras 320, 450 im Roboter 100 auflisten.
Kamerabildservice	Ein Schnappschuss von einer Kamera 320, 450 auf dem Roboter 100 machen.
Roboter-Positionsservice	Eine aktuelle Position des Roboters 100 wiedergeben. Die Position kann wie folgt wiedergegeben werden: • x – die Entfernung entlang einer x-Achse von einem Ausgangspunkt (in Metern). • y – die Entfernung entlang einer y-Achse von einem Ausgangspunkt (in Metern). • Theta – ein Winkel von der x-Achse, der gegen den Uhrzeigersinn in Radianten gemessen wird.
Roboter-Zielortservice	Setzt einen Zielort des Roboters 100 und befiehlt dem Roboter 100, sich in Richtung dieses Orts zu bewegen.
Fahre-Zu-Verschlagwortungsservice	Fährt den Roboter 100 zu einem gekennzeichneten Ziel auf einer Karte.
Roboter-Service einstellen	Befiehlt dem Roboter 100, sich nicht mehr zu bewegen.
Roboter-Info-Service	Liefert grundlegende Roboter-Informationen (z. B. schickt ein Verzeichnis der im Roboter gespeicherten Informationen zurück).

Tabelle 1

Eine Cloud-Dienst Kommunikations-Bibliothek kann APIs umfassen, die Anwendungen 1610 gestatten, mit der Cloud 1620 (z. B. mit Cloudspeicherung 1622, Anwendungs-Servern 1650, Datenbanken 1660 und dem Simulator 1670) und/oder mit mit der Cloud 1620 verbundenen Robotern 100 zu kommunizieren. Die Cloud-Dienst Kommunikations-Bibliothek kann in Objective-C sowie auch in Java Bindings bereitgestellt werden. Beispiele der Cloud-Dienst APIs umfassen einen Navigations-API (z. B. zur Abfrage von Positionen, Zielsetzung, usw.), eine Kartenspeicherung und Abfrage PAI, ein Kamera-Speisungs API, ein Fernbedienungs API, ein Gebrauchsstatistik API, und sonstiges.
Die Erweiterbarkeitsschnittstelle des Cloud-Diensts ermöglicht den Cloud-Diensten das Zusammenspiel mit den Web-Services externer Quellen. Zum Beispiel kann der Cloud-Dienst einen Satz an Erweiterbarkeitsschnittstellen definieren, die dem Unternehmensentwickler 1602 die Anwendung der Schnittstellen für externe firmeneigene Systeme gestatten. Die Erweiterungen können hochgeladen und in der Infrastruktur der Cloud eingesetzt werden. In einigen Beispielen kann der Cloud-Dienst eine Standard Erweiterungsschnittstelle übernehmen, die von verschiedenen Industriekonsortiums definiert wurde.
Der Simulator 1670 kann die☐Behebung von Programmfehlern und die Prüfung der Anwendungen 1610 ermöglichen, ohne, dass dabei eine Konnektivität mit dem Roboter 100 erforderlich wäre. Der Simulator 1670 kann den Betrieb des Roboters 100 gestalten oder simulieren, ohne dabei mit dem Roboter 100 kommunizieren zu müssen (z. B. für die Pfadplanung und den Zugriff auf die Kartendatenbanken). Zur Durchführung der Simulationen erzeugt der Simulator 1670 in einigen Ausführungsformen eine Kartendatenbank (z. B. von einem Lageplan 1810) ohne die Hilfe des Roboters 100. Dies kann die Bildverarbeitung (z. B. Kantenerkennung) umfassen, sodass Merkmale (wie z. B. Wände, Ecken, Säulen, usw) automatisch erkannt werden. Der Simulator 1670 kann die Kartendatenbank zur☐Simulierung einer Pfadplanung in einer Umgebung einsetzen, die von dem Lageplan 1810 vorgeschrieben wird.
Ein Erweiterungs-Uploader/Deployer des Cloud-Diensts kann dem Nutzer das Hochladen von Erweiterungen in die Cloud 1620 gestatten sowie auch eine Verbindung mit externen Authentifikierungssystemen von Drittnutzern, den Zugriff auf externe Datenbanken oder die Speicherung (z. B. Patienteninformationen zum Durchlesen vor und nach der Sprechstunde), den Zugriff auf Bilder zur Veranschaulichung in Videokonferenzsitzungen, usw. Die Erweiterungsschnittstelle des Cloud-Diensts kann eine Integration der firmeneigenen Systeme in die Cloud 1620 ermöglichen.
Verschiedene Ausführungsformen der hier beschriebenen Systeme und Methoden können in einer digitalen elektronischen Schaltung, integrierten Schaltung, speziell entwickelten ASICs (Anwendung spezifischen integrierten Schaltungen), Computer-Hardware, Firmware, Software und/oder Kombinationen davon durchgeführt werden. Diese verschiedenen Ausführungsformen können die Umsetzung eines oder mehrerer in einem programmierbaren System ausführbarer und/oder interpretierbarer Computerprogramme umfassen, und zwar einschließlich von mindestens einem programmierbaren Sonder-Mehrfachzweckprozessors, der für den Daten- und Anweisungsempfang angeschlossen wurde sowie auch für die Daten- und Anweisungsübertragung an ein Speicherungssystem, an mindestens eine Eingabevorrichtung und an mindestens eine Ausgabevorrichtung.
Diese Computerprogramme (auch als als Programme, Software, Software-Anwendungen oder Code bekannt) umfassen Maschinenanweisungen für einen programmierbaren Prozessor und können in einer verfahrensorientierten und/oder Objekt-orientierten Programmierungssprache auf hoher Ebene, und/oder in einer Assembler-/Maschinensprache eingesetzt werden. Die hier benutzten Begriffe ”maschinenlesbares Medium” und ”computerlesbares Medium” beziehen sich auf Computerprogrammprodukte, Geräte und/oder Vorrichtungen (z. B. magnetische Platten, optische Platten, Speicher, programmierbare logische Vorrichtungen (PLDs)), die zur Lieferung von Maschinenanweisungen und/oder Daten an einen programmierbaren Prozessor, einschließlich eines maschinenlesbaren Mediums, das Maschinenanweisungen als ein maschinenlesbares Signal empfängt, eingesetzt werden. Der Begriff ”machinenlesbares Signal” bezieht sich auf ein beliebiges Signal, das zur Lieferung von Maschinenanweisungen und/oder Daten an einen programmierbaren Prozessor verwendet wird.
Die Ausführungen des Gegenstands und die funktionellen in dieser Patentschrift beschriebenen Arbeitsweisen können in einer digitalen elektronischen Schaltung oder in Computer-Software, Firmware oder Hardware, einschließlich der in diversen Patentschriften offengelegten Strukturen und in deren strukturellen Gegenstücken oder in Kombinationen einer oder mehrerer derselben umgesetzt werden. Die Ausführungsformen des in dieser Patentschrift beschriebenen Gegenstands können als ein oder mehrere Computerprogrammprodukte, d. h., als ein oder mehrere Module von Computerprogrammbefehlen implementiert werden, die in einem computerlesbaren Medium zur Ausführung von oder zur Steuerung des Betriebs der Datenverarbeitungsgeräte kodiert werden. Das computerlesbare Medium kann eine maschinenlesbare Speicherungsvorrichtung, ein maschinenlesbares Speicherungssubstrat, eine Speicherungsvorrichtung, eine Zusammensetzung aus Material, dass ein maschinenlesbares propagiertes Signal bewirkt, oder eine Kombination einer oder mehrerer derselben sein. Der Begriff ”Datenverarbeitungsgerät”☐umfasst alle Geräte, Vorrichtungen und Maschinen zur Datenverarbeitung, einschließlich beispielshalber eines programmierbaren Prozessors, eines Computers oder emehrerer Prozessor oder Computer. Die Geräte können zusätzlich zu der Hardware, dem Code, der diese Ausführungsumgebung für das in Frage kommende Computerprogramm erstellt, z. B. der Code, der eine Prozessor-Firmware, einen Protokollstapel, ein Datenbankverwaltungssystem, ein Betriebssystem oder eine Kombination eines/m oder mehreren von ihnen darstellt, umfassen. Ein fortgeleitetes Signal ist ein künstlich erzeugtes Signal, z. B. ein maschinenerzeugtes, elektrisches, optisches oder elektromagnetisches Signal, das zur Encodierung von Informationen zur Übertragung an ein geeignetes Gerät erzeugt wird.
Ein Computerprogramm (das auch als Programm, Software, Softwareanwendung, Skript oder Code bekannt ist) kann in einer beliebigen Programmierungssprache, einschließlich kompilierter oder gedolmetschter☐Sprachen geschrieben werden, und es kann in beliebiger Form, einschließlich als ein eigenständiges Programm oder als ein Modul, eine Komponente, ein Unterprogramm oder sonstige Einheit eingesetzt werden, das/die für die Verwendung in einer Computerumgebung geeignet ist. Ein Computerprogramm entspricht nicht unbedingt einer Datei in einem Dateisystem. Das Programm kann in einem Teil einer Datei gespeichert werden, die andere Programme oder Daten enthält (z. B. ein oder mehrere in einem Markup Language Dokument gespeicherte Skripts) sowie auch in einer für das betreffende Programm dedizierten Einzeldatei oder in mehreren koordinierten Dateien (z. B. ein oder mehrere Module speichernde Dateien, Unterprogramme oder Teile eines Codes). Ein Computerprogramm kann für den Einsatz in einem Computer oder in mehreren Computer verwendet werden, die sich an einem Standort befinden oder über mehrere Standorte verteilt sind und mittels eines Kommunikationsnetzwerks miteinander verbunden sind.
Die in dieser Patentschrift beschriebenen Prozesse und logischen Flüsse können mit einem oder mehrere programmierbaren Prozessoren durchgeführt werden, der/die ein oder mehrere Computerprogramme zur Durchführung von Funktionen ausführt/en, indem er/sie sich auf Inputdaten stützen und eine Ausgabe erzeugen. Des Weiteren können die Prozesse und logischen Flüsse auch von einem logischen Sonderzweckschaltkreis, z. B. einem FPGA (Field Programmable Gate Array) oder einer ASIC (anwenderspezifische oder kundenspezifische integrierte Schaltung) durchgeführt und das Gerät kann von dieser Schaltung zur Anwendung gebracht werden.
Die für die Ausführung eines Computerprogramms in Frage kommenden Prozessoren wären beispielshalber Allgemeinzweck- und Sonderzweck-Mikroprozessoren und ein oder mehrere beliebige Prozessoren jeglicher Art von Digitalrechnern. In der Regel empfängt ein Prozessor Anweisungen und Daten entweder von einem Nurlese- oder Arbeitsspeicher oder beiden zugleich. Die wesentlichen Elemente eines Computers sind der Prozessor zur Durchführung von Anweisungen und ein oder mehrere Speichergeräte zur Speicherung der Anweisungen und Daten. Ein Computer umfasst im Allgemeinen, oder ist funktionell verbunden, um Daten zu empfangen oder um Daten zu übertragen oder um beides durchzuführen von oder an eine oder mehrere Massenspeicherungsvorrichtungen zur Speicherung von Daten, z. B. auf magnetischen, magneto-optischen Datenträgern oder optischen Datenträgern. Es ist jedoch nicht erforderlich, dass ein Computer über diese Vorrichtungen verfügen muss. Außerdem kann ein Computer in einer anderen Vorrichtung eingebettet sein, z. B. in einem Mobiletelefon, einem Minicomputer (PDA), einem mobilen Audio-Player, dem Empfänger eines Satellitennavigationssystems (GPS), um nur einige zu nennen. Computerlesbare zur Speicherung von Computerprogrammanweisungen und Daten geeignete Medien umfassen sämtliche Formen nichtflüchtiger Datenspeicher, Medien- und Speichervorrichtungen, einschließlich von beispielsweise Halbleiterspeichervorrichtungen, z. B. EPROM, EEPROM, und Flashspeichervorrichtungen; Magnetplattenspeicher, z. B. interne Festplatten oder Wechselfestplatten; magneto-optische Datenträger; und CD ROMs und DVD-ROMs. Der Prozessor und Speicher können von einem logischen Sonderzweckschaltkreis ergänzt oder in diesen integriert werden.
Die Ausführungsformen des in dieser Patenschrift beschriebenen Gegenstands können in einem Rechnersystem angewendet werden, dass eine Backend-Komponente umfasst, z. B. als ein Datenserver, oder das eine Middleware-Komponente umfasst, z. B. einen Anwendungsserver, oder das eine Frontend-Komponente umfasst, z. B. ein Client-Rechner mit einer graphischen Benutzerschnittstelle, oder ein Webbrowser, mit dem der Nutzer mit einer Ausführungsform des in dieser Patenschrift beschriebenen Gegenstands oder einer beliebigen Kombination eines oder mehrere dieser Backend-, Middleware-, oder Frontend-Komponenten interagieren kann. Die Komponenten des Systems können durch eine beliebige Form oder beliebige Medien der digitalen Datenkommunikation, z. B. einem Kommunikationsnetzwerk, miteinander verbunden sein. Beispiele von Kommunikationsnetzwerken umfassen ein lokales Datennetz (”LAN”) und ein Fernnetz (”WAN”), z. B. das Internet.
Das Rechnersystem kann Clients und Server umfassen. Ein Client und Server sind in der Regel entfernt voneinander aufgestellt, und sie wirken typischerweise durch ein Kommunikationsnetzwerk zusammen. Die Beziehung zwischen Client und Server ergibt sich aufgrund der auf den jeweiligen Rechnern ausgeführten Computerprogrammen und der miteinander bestehenden Client-Server Beziehung.
Obwohl dieses Patentschrift viele Details enthält, sollten diese nicht als Einschränkungen des Schutzumfangs der Erfindung oder des Beanspruchten ausgelegt werden, sondern eher als Beschreibungen von Merkmalen, die spezifisch für bestimmte Ausführungsformen der Erfindung sind. Gewisse in diese Patentschrift im Rahmen separater Ausführungsformen beschriebene Merkmale können auch zusammen in einer Einzelausführung durchgeführt werden. Im GegenzugAndererseits können verschiedene im Rahmen einer Einzelausführung beschriebene Merkmale auch in mehreren Ausführungsformen getrennt oder in jeder beliebigen angemessenen Unterkombination umgesetzt werden. Außerdem können ein oder mehrere Merkmale einer beanspruchten Kombination in einigen Fällen aus der Kombination entfernt werden, und die beanspruchte Kombination kann auf eine Unterkombination oder Variante einer Unterkombination ausgerichtet werden, obwohl die Merkmale weiter oben als in gewissen Kombinationen agierend beschrieben wurden und anfangs sogar als solche beansprucht wurden.
Ähnlicherweise sollten in den Zeichnungen in einer gewissen Reihenfolge dargestellte Abläufe nicht so ausgelegt werden, dass diese Abläufe in dieser bestimmten dargestellten Reihenfolge oder sequenziellen Reihenfolge auszuführen sind, oder dass zur Erziehlung der gewünschen Ergebnisse alle dargestellten Abläufe auszuführen sind, obwohl die Abläufe in den Zeichnungen in einer gewissen Reihenfolge dargestellt wurden. Unter gewissen Umständen kann das Multitasking und die parallele Verarbeitung vorteilhaft sein. Außerdem sollte die Trennung verschiedener Systemkomponenten in den beschriebenen Ausführungsarten nicht so ausgelegt werden, dass diese Trennung in allen Ausführungsarten erforderlich ist, und es sollte klar sein, dass die beschriebenen Programmkomponenten und Systeme in der Regel miteinander in ein einzelnes Softwareprodukt integriert oder in mehreren Softwareprodukten verpackt werden können.
Viele Ausführungsformen sind beschrieben worden. Dennoch sollte es klar sein, dass verschiedene Änderungen vorgenommen werden können, ohne dabei von dem Geist und Umfang der Offenbarung abzuweichen. Dementsprechend liegen sonstige Ausführungsformen im Rahmen der folgenden Ansprüche. So können beispielsweise die in den Ansprüchen vorgetragenen Handlungen in einer anderen Reihenfolge ausgeführt werden und immer noch zu den gewünschten Ergebnissen führen.
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

IL 2006/000335 [0154]
US 7433024 [0159]
US 6323942 [0162]
US 6515740 [0162]
US 2011/0238857 [0241]
US 7158317 [0252]
US 7115849 [0252]

Zitierte Nicht-Patentliteratur

35 U. S. C. §119(e) [0001]
IEEE 802.11n [0179]
„Multi-Level Surface Maps For Outdoor Terrain Mapping and Loop Closing” von R. Triebel, P. Pfaff und W. Burgard; IEEE/RSJ International Conference on Intelligent Robots and Systems, 2006 [0217]
„3D Models From Extended Uncalibrated Video Sequences: Addressing Key-frame selection and projective drift” von J. Repko und M. Pollefeys; Fifth International Conference on 3-D Digital Imaging and Modeling, 2005 [0220]
”Long-Term Learning Using Multiple Modells For Outdoor Autonomous Robot Navigation,” von Michael J. Procopio, Jane Mulligan und Greg Grudic, IEEE Internationale Tagung 2007 über Intelligente Roboter und Systeme [0223]

Claims

Ein Robotersystem (1600) Folgendes umfassend: einen mobilen Roboter (100) mit einem Kontrollschaltkreis (500), der ein Kontrollsystem (510) zur Steuerung des Roboters (100) ausführt; ein Cloudcomputing (1620), das in Kommunikation mit dem Kontrollschaltkreis (500) des Roboters (100) ist; und ein Fernrechengerät (310, 1604), das in Kommunikation mit dem Cloudcomputing (1620) ist, wobei das Fernrechengerät (310, 1604) mit dem Roboter (100) über das Cloudcomputing (1620) kommuniziert.
Robotersystem (1600) nach Anspruch 1, wobei das Fernrechengerät (310, 1604) eine Applikation (1610, 1610a) für die Produktion eines Layoutplans (1700, 1810) der Betriebsumwelt (10) des Roboters ausführt.
Robotersystem (1600) nach Anspruch 2, wobei das Fernrechengerät (310, 1604) den Layoutplan (1700, 1810) im externen Cloudspeicher (1622) mittels Cloudcomputing (1620) speichert.
Robotersystem (1600) nach Anspruch 3, wobei der Kontrollschaltkreis (500) des Roboters (100) auf den Layoutplan (1700, 1810) über das Cloudcomputing (1620) für die Abgabe von Fahrbefehlen an ein Fahrsystem (200) des Roboters (100) zugreift.
Robotersystem (1600) nach einem der Ansprüche 1–4, wobei das Fernrechengerät (310, 1604) eine Applikation (1610, 1610b) ausführt, um eine dezentralisierte Teleoperation des Roboters (100) herbeizuführen, wobei die Applikation (1610, 1610b) vorzugsweise Steuerungen bereitstellt, mindestens für das Fahren des Roboters (100), eine für die Veränderung einer Pose des Roboters (100), eine für das Ansehen eines Videos von einer Kamera (320, 450) des Roboters (100) und eine zum Betrieb der Kamera (320, 450) des Roboters (100).
Robotersystem (1600) nach einem der Ansprüche 1–5, wobei das Fernrechengerät (310, 1604) eine Applikation (1610, 1610c) ausführt, die eine Videokonferenz zwischen einem Benutzer des Fernrechengeräts (310, 1604) und einem innerhalb des Blickfelds einer Kamera (320, 450) des Roboters (100) befindlichen Dritten bereitstellt.
Robotersystem (1600) nach einem der Ansprüche 1–6, wobei das Fernrechengerät (310, 1604) eine Applikation (1610, 1610d) für die Zeiteinteilung der Nutzung des Roboters und/oder einer Applikation (1610, 1610e) für die Überwachung der Nutzung und des Betriebs des Roboters (100) ausführt.
Robotersystem (1600) nach einem der Ansprüche 1–7, wobei das Fernrechengerät (310, 1604) einen Tablet-Computer umfasst.
Robotersystem (1600) Folgendes umfassend: einen mobilen Roboter (100) mit einem Kontrollschaltkreis (500), der ein Kontrollsystem (510) für die Steuerung des Betriebs des Roboters (100) ausführt; ein Computergerät (310, 1604), das in Kommunikation mit dem Kontrollschaltkreis (500) ist; ein Cloudcomputing (1620), das in Kommunikation mit dem Computergerät (310, 1604) ist und ein Portal (1630), das in Kommunikation mit dem Cloudcomputing (1620 ist.
Robotersystem (1600) nach Anspruch 9, wobei das Portal (1630) ein webbasiertes Portal (1630) umfasst, das Zugriff auf Inhalte bereitstellt.
Robotersystem (1600) nach Anspruch 9 oder 10, wobei das Portal (1630) Roboterinformationen vom Roboter (100) über das Cloudcomputing (1620) erhält und/oder der Roboter (100) Nutzerinformationen vom Portal (1630) über das Cloudcomputing (1620) empfängt.
Robotersystem (1600) nach einem der Ansprüche 9–11, wobei das Computergerät (310) einen Sensorbildschirm (312) umfasst.
Robotersystem (1600) nach einem der Ansprüche 9–12, wobei das Computergerät (310, 1604) ein Betriebssystem ausführt, das sich von dem Betriebssystem des Kontrollschaltkreises (500) unterscheidet.
Robotersystem (1600) nach einem der Ansprüche 9–13, wobei das Computergerät (310, 1604) mindestens eine Applikation (1610) ausführt, die Roboterinformationen vom Roboter (100) sammelt und die Roboterinformationen an das Cloudcomputing (1620) sendet.
Robotersystem (1600) nach einem der Ansprüche 9–14, wobei der Roboter (100) Folgendes umfasst: eine Basis (120), die eine vertikale Zentralachse (Z) definiert und den Kontrollschaltkreis (500) unterstützt; ein holonomes Fahrsystem (200), das von der Basis (120) unterstützt wird, wobei das Fahrsystem (200) ein erstes, zweites und drittes Antriebsrad (210a–c) aufweist, wobei jedes trilateral über die vertikale Zentralachse (Z) verteilt ist und jedes davon eine Fahrtrichtung (D_R, Drive) aufweist, die perpendikular zu einer Radialachse (X, F, Slip) in Bezug auf die vertikale Zentralachse (Z) verläuft; ein ausziehbares Bein (130), das sich von der Basis (120) nach oben erstreckt; und einen Rumpf (140), der durch das Bein (130) getragen wird, wobei die Stellbewegung des Beins (130) eine Veränderung in der Höhe (H_T) des Rumpfs (140) und des Computergeräts (310), das lösbar oberhalb des Rumpfs (140) befestigt ist, verursacht.
Robotersystem (1600) nach Anspruch 15, wobei der Roboter (100) Folgendes umfasst: einen Hals (150), der vom Rumpf (140) getragen wird und einen Kopf (160), der vom Hals (150) getragen wird, wobei der Hals (150) in der Lage ist, den Kopf (160) relativ zum Rumpf (140) zu schwenken und zu neigen und das Computergerät (310) lösbar vom Kopf (160) getragen wird.
Robotersystem (1600) Folgendes umfassend: einen mobilen Roboter (100), der einen Kontrollschaltkreis (500) aufweist, der ein Kontrollsystem (510) zur Steuerung des Betriebs des Roboters (100) ausführt; ein Computergerät (310), das in Kommunikation mit dem Kontrollschaltkreis (500) steht; ein vermittelndes Sicherheitsgerät (350), das die Kommunikationen zwischen dem Kontrollschaltkreis (500) und dem Computergerät (310) steuert; ein Cloudcomputing (1620), das in Kommunikation mit dem Computergerät (310) steht; und ein Portal (1630), das in Kommunikation mit dem Cloudcomputing (1620) ist.
Robotersystem (1600) nach Anspruch 17, wobei das vermittelnde Sicherheitsgerät (350) Kommunikationen zwischen einem Kommunikationsprotokoll des Computergeräts (310) und einem Roboterkommunikationsprotokoll des Roboters (100) konvertiert.
Robotersystem (1600) nach Anspruch 17 oder 18, wobei das vermittelnde Sicherheitsgerät (350) ein Autorisierungschip (352) für die Autorisierung des Kommunikationsverkehrs zwischen dem Computergerät (310) und dem Roboter (100) umfasst.
Robotersystem (1600) nach einem der Ansprüche 17–19, wobei das Computergerät (310) drahtlos mit dem Roboterkontrollschaltkreis (500) kommuniziert, wobei das Computergerät (310) vorzugsweise einen Tablet-Computer umfasst und/oder auf dem Roboter (100) lösbar montiert ist.
Robotersystem (1600) nach einem der Ansprüche 17–20, wobei das Portal (1630) ein webbasiertes Portal (1630) umfasst, das Zugriff auf Inhalt gewährleistet.
Robotersystem (1600) nach einem der Ansprüche 17–21, wobei das Portal (1630) Roboterinformationen vom Roboter (100) über das Cloudcomputing (1620) empfängt und/oder der Roboter (100) Benutzerinformationen von dem Portal (1630) über das Cloudcomputing (1620) empfängt.
Robotersystem (1600) nach einem der Ansprüche 17–22, wobei das Computergerät (310) auf den Cloudspeicher (1622) mittels Cloudcomputing (1620) zugreift.
Robotersystem (1600) nach einem der Ansprüche 17–23, wobei das Computergerät (310) mindestens eine Applikation (1610) ausführt, die Roboterinformationen vom Roboter (100) sammelt und die Roboterinformationen zum Cloudcomputing (1620) sendet.
Verfahren zum Betrieb eines mobilen Roboters (100), wobei das Verfahren Folgendes umfasst: Empfangen eines Layoutplans (1810), das einer Umwelt (10) des Roboters (100) entspricht; Bewegen des Roboters (100) in der Umwelt (10) zu einem Layoutplanstandort (1812, 1814) auf dem Layoutplan (1810); Aufnehmen eines Roboterlayoutplanstandortes (1822) auf einem Roboterlayoutplan (1820), der der Umwelt (10) entspricht und vom Roboter (100) produziert wurde; Bestimmen einer Verzerrung zwischen dem Roboterlayoutplan (1820) und dem Layoutplan (1810) unter Verwendung der aufgezeichneten Roboterlayoutstandorte (1822) und der entsprechenden Layoutplanstandorte (1812) und Anwenden der bestimmten Verzerrung auf einen Ziel-Layoutplanstandort (1814), um einen entsprechenden Zielroboter-Layoutplanstandort (1824) zu bestimmen.
Verfahren nach Anspruch 25, weiter umfassend ein Empfangen des Layoutplans (1810) vom Cloudcomputing (1620).
Verfahren nach Anspruch 26, weiter umfassend ein Produzieren des Layoutplans (1810) auf einer Applikation (1610), ein Ausführen auf einem Fernrechengerät (310, 1604) und Speichern des Layoutplans (1810) auf einer entfernten Cloudspeichergerät (1622) mittels Cloudcomputing (1620).
Verfahren nach einem der Ansprüche 25–27, weiter umfassend: Bestimmen einer Skalierungsgröße, Ursprungsabbildung, und Rotation zwischen des Layoutplans (1810) und der Roboterlandkarte (1820) unter Verwendung bestehender Layoutplanstandorte (1812) und aufgezeichnete Roboter-Layoutplanstandorte (1822) und Auflösung eines Roboter-Layoutplanstandortes (1824) entsprechend des Ziel-Layoutplanstandorts (1814).
Verfahren nach Anspruch 28, weiter umfassend Anwenden einer affinen Transformation auf die bestimmte Skalierungsgröße, Ursprungsabbildung und Rotation, um den Zielroboter-Layoutplanstandort aufzulösen (1824).
Verfahren nach einem der Ansprüche 25–29, weiter umfassend Bestimmen einer Triangulation (1910) zwischen Layoutplanstandorten (1812, 1912), die an den Ziel-Layoutplanstandorten (1814, 1914) anliegen.
Verfahren nach Anspruch 30, weiter umfassend ein Bestimmen eines Maßstabes, einer Rotation, einer Verschiebung und eines Bitversatzes zwischen einem Dreieck (1910) das in dem Layoutplan (1810) abgebildet ist und einem entsprechenden Dreieck (1920) das in der Roboterlandkarte (1820) abgebildet ist und Anwenden des bestimmten Maßstabes, der Rotation, der Verschiebung und des Bitversatzes auf den Ziel-Layoutplanstandort (1814, 1914), um den entsprechenden Zielroboterlandkartenstandort (1824, 1924) zu bestimmen.
Verfahren nach einem der Ansprüche 25–31, weiter umfassend: Bestimmen der Entfernungen zwischen allen Layoutplanstandorten (1812, 1912) und dem Ziel-Layoutplanstandort (1814, 1914); Bestimmen eines Schwerpunktes (2012) der Layoutplanstandorte (1812, 1912); Bestimmen eines Schwerpunktes (2022) von allen aufgezeichneten Roboter-Layoutstandorten (1822, 1922) und Bestimmen für jeden Layoutplanstandort (1812, 1912) eine Rotation und eine Längenskalierung, um einen ersten Vektor (2014), der vom Layoutplanschwerpunkt (2012) zum Ziel-Layoutstandort (1814, 1914) in einen zweiten Vektor (2024), der vom Roboterlayoutplanschwerpunkt (2022) zum Zielroboterlayoutplanstandort (1824, 1924) verläuft, zu transformieren.
Verfahren nach einem der Ansprüche 25–32, weiter umfassend ein Produzieren der Roboterlandkarte (1810) unter Verwendung eines Sensorsystems (400) des Roboters (100).
Verfahren nach Anspruch 33, weiter umfassend ein Ausstrahlen von Licht auf eine Szenerie (10) der Umwelt; Empfangen von Reflexionen des ausgestrahlten Lichts auf den Oberflächen der Szenerie (10); Bestimmen einer Entfernung von jeder reflektierenden Oberfläche und Erarbeiten einer dreidimensionalen Tiefenlandkarte (1700) von der Szenerie (10).
Verfahren nach Anspruch 34, weiter umfassend Ausstrahlen eines Flecken-Lichtmusters auf die Szenerie (10) und Empfangen von Reflektionen des Fleckenmusters von der Szenerie (10), vorzugsweise Speichern von Bezugsbildern des Fleckenmusters, wie es von einem Bezugsobjekt (12) in der Szenerie (10) reflektiert wird und die Bezugsbilder bei unterschiedlichen Entfernungen (Z_n) vom Bezugsobjekt (12) aufgenommen werden.
Verfahren nach Anspruch 35, weiter umfassend das Aufnehmen von mindestens einem Zielbild des Fleckenmusters, wie es von dem Zielobjekt (12) in der Szenerie (10) reflektiert wird und Vergleichen des mindestens einen Zielbilds mit dem Bezugsbild zum Bestimmen einer Entfernung von den reflektierenden Oberflächen des Zielobjekts (12).
Verfahren nach Anspruch 36, weiter umfassend ein Bestimmen eines primären Fleckenmusters auf dem Zielobjekt (12) und Berechnen von mindestens einer entsprechenden Kreuzkorrellation und einer Dekorrelation zwischen den primären Fleckenmustern und den Fleckenmustern der Bezugsbilder.
Verfahren nach Anspruch 36 oder 37, weiter umfassend ein Manövrieren des Roboters (100) in Bezug auf das Zielobjekt (12), basierend auf den festgestellten Entfernungen der widerspiegelnden Oberflächen des Zielobjekts (12).
Verfahren nach Anspruch 34, weiter umfassend ein Bestimmen der Laufzeit zwischen dem Ausstrahlen des Lichts und Empfangen des reflektierten Lichts und Bestimmen einer Entfernung zu den reflektierenden Oberflächen der Szenerie (10).
Verfahren nach einem der Ansprüche 34–39, weiter umfassend ein Ausstrahlen von Licht auf die Szenerie (10) in intermittierenden Pulsen, vorzugsweise unter Veränderung einer Frequenz der ausgestrahlten Lichtpulse.
Robotersystem (1600) Folgendes umfassend: einen mobilen Roboter (100) umfassend: einen Kontrollschaltkreis (500), der ein Kontrollsystem (510) für die Steuerung des Betriebs des Roboters (100) ausführt und ein Sensorsystem (400), das in Kommunikation mit dem Kontrollschaltkreis (500) steht und ein Cloudcomputing (1620), das in Kommunikation mit dem Kontrollschaltkreis (500) vom Roboter (100) steht; wobei das Cloudcomputing (1620): Daten (1601) vom Kontrollschaltkreis (500) empfängt; die Daten (1601) verarbeitet und die verarbeitete Resultante (1607, 1609) an den Kontrollschaltkreis (500) zurück sendet.
Robotersystem (1600) nach Anspruch 41, wobei das Cloudcomputing (1620) zumindest temporär die empfangenen Daten (1601, 1603) im Cloudspeicher (1622) speichert und die gespeicherten Daten (1601, 1603) nach Verarbeitung der Daten (1601, 1603) optional beseitigt.
Robotersystem (1600) nach Anspruch 41 oder 42, wobei der Roboter (100) Folgendes umfasst: eine Kamera (320), die in Kommunikation mit dem Kontrollschaltkreis (500) steht und in der Lage ist, Bilder von einer Szenerie (10) um den Roboter (100) herum zu erhalten und/oder ein volumetrisches Punktwolken-Abbildungsgerät (450), das in Kommunikation mit dem Kontrollschaltkreis (500) ist und in der Lage ist, eine Punktwolke von einem Raumvolumen um den Roboter (100) herum zu empfangen, vorzugsweise ein Raumvolumen, das eine Bodenebene (5) in einer Bewegungsrichtung (F) des Roboters (100) umfasst; wobei der Kontrollschaltkreis (500) Bilddaten (1601) zum Cloudcomputing (1620) kommuniziert.
Robotersystem (1600) nach einem der Ansprüche 41–43, wobei die Daten (1601) rohe Sensordaten und/oder Daten, die dazugehörige Informationen vom Sensorsystem (400) enthalten, umfassen, wobei die Daten (1601) vorzugsweise Bilddaten umfassen, die mindestens eine der Akzelerometerdatenspuren, Odometriedaten und einen Zeitstempel umfassen.
Robotersystem (1600) nach einem der Ansprüche 41–44, wobei das Cloudcomputing (1620) Bilddaten (1601) vom Kontrollschaltkreis (500) von einer Szenerie (10) um den Roboter (100) herum empfängt und die Bilddaten (1601) in eine 3-D-Landkarte (1605) und/oder ein Modell (1609) von der Szenerie (10) einarbeitet.
Robotersystem (1600) nach Anspruch 45, wobei das Cloudcomputing (1620) eine 2-D-Höhenlandkarte (1607) und/oder das Modell (1609) an den Kontrollschaltkreis (500) ausgibt, wobei das Cloudcomputing (1620) eine 2-D-Höhenlandkarte (1607) von der 3-D-Landkarte (1605) berechnet.
Robotersystem (1600) nach Anspruch 45 oder 46, wobei das Cloudcomputing (1620) Bilddaten (1601) regelmäßig empfängt und die erhaltenen Bilddaten (1601) nach Akkumulieren eines Schwellenwert Bilddatensatzes (1603) bearbeitet.
Robotersystem (1600) nach einem der Ansprüche 41–47, wobei der Kontrollschaltkreis (500) die Daten (1601) an das Cloudcomputing (1620) drahtlos mittels eines tragbaren Computergerät (310) das in Kommunikation mit dem Kontrollschaltkreis (500) kommuniziert und vorzugsweise lösbar am Roboter (100) befestigt ist.
Robotersystem (1600) nach einem der Ansprüche 41–48, wobei der Kontrollschaltkreis (500) die Daten (1601) puffert und die Daten (1601) periodisch an das Cloudcomputing (1620) sendet.
Robotersystem (1600) nach einem der Ansprüche 41–49, wobei das Sensorsystem (400) mindestens eines von einer Kamera (320), einen 3-D-Abbildungssensor (450), einen Sonarsensor, einem Ultraschallsensor, LIDAR, LADAR, einen optischen Sensor und einen Infrarotsensor umfasst.
Verfahren zum Betrieb eines mobilen Roboters (100), wobei das Verfahren Folgendes umfasst: Manövrieren des Roboters (100) um eine Szenerie (10) herum; Empfangen von Sensordaten (1601), die die Szenerie (10) darstellen, Kommunizieren der Sensordaten (1601) an ein Cloudcomputing (1620), das die empfangenen Sensordaten (1601) verarbeitet und die Prozessresultante (1607, 1609) an den Roboter (100) weitergibt und Manövrieren des Roboters (100) in der Szenerie (10) basierend auf der empfangenen Prozessresultante (1607, 1609).
Verfahren nach Anspruch 51, weiter Folgendes umfassend: Ausstrahlen von Licht auf die Szenerie (10) um den Roboter (100) herum und Aufnehmen von Bildern der Szenerie (10) entlang einer Fahrtrichtung (F) des Roboters (100), wobei die Bilder mindestens eines von (a) einem dreidimensionalen Tiefenbild, (b) einem aktiven Beleuchtungsbild und (c) und einem Umgebungsbeleuchtungsbild umfassen; wobei die Sensordaten (1601) die Bilder umfassen und die Prozessresultante (1607, 1609) eine Landkarte (1607) oder ein Modell (1609) von der Szenerie (10) umfassen.
Verfahren nach Anspruch 52, weiter Folgendes umfassend: Ausstrahlen eines Fleckenmusters von Licht auf die Szenerie (10); Empfangen von Reflexionen des Fleckenmusters von einem Objekt (12) in der Szenerie (10); Speichern von Bezugsbildern im Cloudspeicher (1622) vom Cloudcomputing (1620) von den Fleckenmustern, wie sie von einem Bezugsobjekt (12) in der Szenerie (10) reflektiert werden, wobei die Bezugsbilder bei unterschiedlichen Entfernungen (Z_n) vom Bezugsobjekt (12) aufgenommen werden und Aufnehmen von mindestens einem Zielbild des Fleckenmusters, das von einem Zielobjekt (12) in der Szenerie (10) reflektiert wird; und Kommunizieren des mindestens einen Zielbildes zum Cloudcomputing (1620); wobei das Cloudcomputing (1620) mindestens das eine Zielbild mit den Bezugsbildern zur Bestimmung einer Entfernung (☐Z) der reflektierenden Oberflächen des Zielobjektes (12) vergleicht.
Verfahren nach Anspruch 53, weiter umfassend ein Bestimmen eines primären Fleckenmusters auf dem Zielobjekt (12) und Berechnen von mindestens einer entsprechenden Kreuzkorrelation und einer Dekorrelation zwischen dem primären Fleckenmuster und den Fleckenmustern der Bezugsbilder.
Verfahren nach einem der Ansprüche 51–54, wobei das Cloudcomputing (1620) die empfangenen Sensordaten (1601) zumindest temporär im Cloudspeicher (1622) speichert und wahlweise die gespeicherten Sensordaten (1601) nach Bearbeitung der Daten (1601) beseitigt.
Verfahren nach einem der Ansprüche 51–55, wobei die Sensordaten (1601) Bilddaten umfassen, die dazugehörige Sensorsystemdaten haben, wobei die Sensorsystemdaten vorzugsweise mindestens eines von Akzelerometerdatenspuren, Odometriedaten und einen Zeitstempel umfassen.
Verfahren nach einem der Ansprüche 51–56, wobei das Cloudcomputing (1620) Bilddaten (1601) vom Roboter (100) empfängt und die Bilddaten (1601) in eine 3-D-Landkarte (1605) und/oder ein Modell (1609) der Szenerie (10) einarbeitet.
Verfahren nach Anspruch 57, wobei das Cloudcomputing (1620) eine 2-D-Höhenlandkarte (1607) und/oder ein Modell (1609) dem Roboter (100) bereitstellt und das Cloudcomputing (1620) eine 2-D-Höhenlandkarte (1607) von der 3-D-Landkarte (1605) berechnet.
Verfahren nach einem der Ansprüche 51–56, weiter umfassend ein periodisches Kommunizieren der Sensordaten (1601) an das Cloudcomputing (1620), wobei das Cloudcomputing (1620) die empfangenen Bilddaten (1601) nach einer Akkumulierung bis eines Schwellenwerts des Sensordatensatzes (1603) bearbeitet.
Verfahren nach einem der Ansprüche 51–59, weiter umfassend ein drahtloses Kommunizieren der Sensordaten (1601) zum Cloudcomputing (1620) über das tragbare Computergerät (310), das in Kommunikation mit dem Roboter (100) und vorzugsweise lösbar am Roboter (100) befestigt ist.
Verfahren zum Navigieren eines mobilen Roboters (100), wobei das Verfahren Folgendes umfasst: Aufnehmen einer Streamingsequenz (1615) von dichten Bildern (1611) einer Szenerie (10) um den Roboter (100) herum entlang einer Ortslinie der Bewegung des Roboters (100) mit einer Echtzeitaufnahmerate; Assoziieren von Notierungen (1613) bei mindestens einigen der dichten Bilder (1611); Senden der dichten Bilder (1611) und Notierungen (1613) an einen entfernten Server (1620) mit einer bestimmten Senderate, wobei die Senderate langsamer ist als die Echtzeitaufnahmerate; Empfangen eines Datensatzes (1607, 1617) vom entfernten Server (1620) nach einem Verarbeiten der Zeitspanne, wobei der Datensatz (1607, 1617) mindestes von einem Teil der Sequenz (1615) der dichten Bilder (1611) und entsprechenden Notierungen (1613) erhalten wurde und diesen repräsentiert, wobei der Datensatz (1607, 1617) rohe Bilddaten der Sequenz (1615) der dichten Bilder (1611) ausschließt. Bewegen des Roboters (100) in Bezug auf die Szenerie (10) auf Grundlage des empfangenen Datensatzes (1607, 1617).
Verfahren nach Anspruch 61, weiter umfassend ein Senden der dichten Bilder (1611) und Notierungen (1613) an einen örtlichen Server und Puffer (1640) und dann ein Senden der dichten Bilder (1611) und Notierungen (1613) an den entfernten Server (1620) mit einer Senderate die langsamer ist als die Echtzeitaufnahmerate.
Verfahren nach Anspruch 61 oder 62, wobei die Notierungen (1613) Folgendes umfassen: einen Zeitstempel, vorzugsweise von der absoluten Zeitreferenz, die mindestens einigen der dichten Bilder (1611) entspricht; und auf die Pose bezogene Sensordaten, wobei vorzugsweise die mit der Pose verbundenen Sensordaten mindestens eines von Odometriedaten, Akzelerometerdaten, Neigungsdaten und winkelige Ratendaten enthalten.
Verfahren nach einem der Ansprüche 61–63, wobei die dazugehörigen Notierungen (1613) dazugehörige Notierungen (1613) umfassen, die Gefahrenvorfälle mit dichten Bildern (1611) enthalten, die in einer Zeitspanne aufgenommen wurden, die relativ zur Gefahrenreaktionsfähigkeit des Roboters (100) ist.
Verfahren nach einem der Ansprüche 61–64, wobei dazugehörige Notierungen (1613) dazugehörige Schlüsselbildidentifizierer mit einer Teilmenge der dichten Bilder (1611) umfasst.
Verfahren nach einem der Ansprüche 61–65, wobei die Notierungen (1613) einen verstreuten Satz von 3-D-Punkten von Struktur- und Bewegungsaufnahmen von Merkmalen, die zwischen dichten Bildern (1611) der Streamingsequenz (1615) von dichten Bildern (1611) ausgeführt wurden, umfassen.
Verfahren nach Anspruch 66, wobei die Notierungen (1613) Kameraparameter umfassen, wobei die Kameraparameter vorzugsweise eine Kamerapose in Bezug auf die individuellen 3-D-Punkte des verstreuten Satzes von 3-D-Punkten umfassen.
Verfahren nach einem der Ansprüche 61–67, wobei die Notierungen (1613) Markierungen von passierbaren und nicht-passierbaren Gebieten der Szenerie (10) umfassen.
Verfahren nach einem der Ansprüche 61–68, wobei der Datensatz (1607, 1617) eine oder mehrere Textur-Maps (1607) umfassen, die von den dichten Bildern (1611) extrahiert werden und/oder eine Terrainlandkarte (1607) die Merkmale innerhalb der dichten Bilder (1611) der Szenerie (10) repräsentiert.
Verfahren nach einem der Ansprüche 61–69, wobei der Datensatz (1607, 1617) einen trainierten Klassifizierer (1625) für die Klassifizierung der Merkmale innerhalb neuer dichter Bilder (1611), die von der Szenerie (10) aufgenommen werden, umfasst.
Verfahren zur Abstraktion von Umweltdaten des mobilen Roboters, wobei das Verfahren Folgendes umfasst: Empfangen einer Sequenz (1615) von dichten Bildern (1611) einer Roboterumwelt (10) von einem mobilen Roboter (100) zu einer Empfangsrate, wobei die dichten Bilder (1611) entlang einer Ortslinie der Bewegung des mobilen Roboters (100) zu einer Echtzeitaufnahmerate aufgenommen werden, wobei die Empfangsrate langsamer ist als die Echtzeitaufnahmerate; Empfangen von Notierungen (1613), die mindestens mit einigen der dichten Bilder (1611) der Sequenz (1615) von dichten Bildern (1611) assoziiert sind; Absenden einer Stapelverarbeitungsaufgabe zur Reduzierung dichter Daten innerhalb mindestens einiger der dichten Bilder (1611) zu einem Datensatz (1607, 1617), der mindestens einen Teil der Sequenz (1615) der dichten Bilder (1611) repräsentiert; Übertragen des Datensatzes (1617) an den mobilen Roboter (100), wobei der Datensatz (1607, 1617) rohe Bilddaten aus der Sequenz (1615) von dichten Bildern (1611) ausschließt.
Verfahren nach Anspruch 71, wobei die Stapelverarbeitungsaufgabe Folgendes umfasst: Verarbeiten der Sequenz (1615) von dichten Bildern (1611) in ein kompaktes 3-D-Modell (1609) der Roboterumwelt (10); und Verarbeiten des dichten 3-D-Modells (1609) in ein Terrainmodell (1607) für ein Koordinatensystem von 2-D-Standorten und mindestens einer Höhe von einer Bodenebene (G).
Verfahren nach Anspruch 72, wobei das Terrainmodell (1607) für ein Koordinatensystem von 2-D-Standorten und eine Vielzahl von besetzten und nicht-besetzten Höhegrenzen von einer Bodenebene (G) ist.
Verfahren nach einem der Ansprüche 71–73, wobei die Stapelverarbeitungsaufgabe die Akkumulierung dichter Bildsequenzen (1615, 1615a) umfasst, die einer Vielzahl von Roboterumwelten (10) entsprechen.
Verfahren nach einem der Ansprüche 71–74, wobei die Stapelverarbeitungsaufgabe eine Vielzahl von Klassifizierern (1625) und/oder das Training eines oder mehreren Klassifizierer (1625) auf der Sequenz der dichten Bilder (1611) umfasst.
Verfahren nach einem der Ansprüche 71–75, wobei die Stapelverarbeitungsaufgabe Folgendes umfasst: Assoziieren von Notierungen (1613), die Gefahrenvorfälle mit dichten Bildern (1611) reflektieren, die in einem Zeitraum aufgenommen werden, der relativ zur Gefahrenreaktionsfähigkeit des mobilen Roboters (100) steht; und Trainieren eines Klassifizierer (1625) von gefahrenbezogenen dichten Bildern (1611) unter Verwendung der dazugehörigen Notierungen von Gefahrenvorfällen (1613) und entsprechenden dichten Bildern (1611) als Trainingsdaten, vorzugsweise um einen Datensatz (1603, 1607, 1617) von Modellparametern für den Klassifizierer (1625) zur Verfügung zu stellen.
Verfahren nach Anspruch 76, wobei der Klassifizierer (1625) mindestens eine Stützvektormaschine umfasst, die mindestens eine Hyperebene zur Klassifizierung konstruiert und die Modellparameter eine trainierte Hyperebene, die in der Lage ist einen Datensatz (1603, 1607, 1617) in gefahrenbezogenen Klassifizierungen zu verwandeln, definieren.
Verfahren nach Anspruch 77, wobei die Modellparameter genügend Systemparameter umfassen, um einen Systemkern der Stützvektormaschine und einen weichen Grenzparameter zu definieren.
Verfahren nach einem der Ansprüche 71–78, wobei die Stapelverarbeitungsaufgabe ein Einleiten einer skalierbaren Pluralität von virtuellen Prozessen (1621) umfasst, die proportional zu einer Skala der dichten Bilderfolge (1615, 1615a) sind, um verarbeitet zu werden, wobei zumindest einige der virtuellen Prozesse (1621) nach der Übertragung des Datensatzes (1607, 1617) freigestellt werden.
Verfahren nach einem der Ansprüche 71–79, wobei die Stapelverarbeitungsaufgabe ein Einleiten einer skalierbaren Pluralität von virtueller Speicherung (1622) umfasst, die proportional zu einer Skala der dichten Bilderfolge (1615, 1615a) ist die gespeichert werden soll, wobei mindestens etwas der virtuellen Speicherung (1622) nach der Übertragung des Datensatzes (1607, 1617) freigestellt wird.
Verfahren nach einem der Ansprüche 71–80, wobei die Stapelverarbeitungsaufgabe ein Verteilen einer skalierbaren Pluralität von virtuellen Servern (1621) gemäß einer der geografischen Nähe zum mobilen Roboter (100) und/oder Netzwerkverkehr von einer Vielzahl von mobilen Robotern (100) umfasst.