Aldebaran NAOqi: Unterschied zwischen den Versionen
(→LEDs) |
|||
Zeile 10: | Zeile 10: | ||
Die Programmierung des NAOs ist auf verschiedene Arten möglich. Sollen die Programme direkt auf den Roboter geladen und von diesem ausgeführt werden, so kann man auf Choregraphe inkl. Python oder auf C++ setzen. Gibt man sich damit zufrieden, den Roboter per Fernzugriff zu steuern, so lässt sich zusätzlich noch auf Java, .NET, Matlab und Urbi zurückgreifen. Wichtig zu verstehen ist: Egal für welche Variante sich der Entwickler entscheidet, letztendlich arbeitet er stets gegen das Robotik-Framework NAOqi. | Die Programmierung des NAOs ist auf verschiedene Arten möglich. Sollen die Programme direkt auf den Roboter geladen und von diesem ausgeführt werden, so kann man auf Choregraphe inkl. Python oder auf C++ setzen. Gibt man sich damit zufrieden, den Roboter per Fernzugriff zu steuern, so lässt sich zusätzlich noch auf Java, .NET, Matlab und Urbi zurückgreifen. Wichtig zu verstehen ist: Egal für welche Variante sich der Entwickler entscheidet, letztendlich arbeitet er stets gegen das Robotik-Framework NAOqi. | ||
− | Dieses API wurde von Aldebaran Robotics geschaffen, um die Programmierung des NAOs auf ein vernünftiges Level zu heben. Sie stellt die zentrale Schnittstelle zur Nutzung und Erweiterung der Funktionalitäten des Roboters dar und ist modular aufgebaut. Dank NAOqi werden selbst komplexe Dinge wie Sprach- oder Objekterkennung zum Kinderspiel. Darüber hinaus lassen sich selbst implementierte Module mithilfe der zugrunde liegenden Broker-Architektur einfach hinzufügen. Sie können auch auf einem externen Rechner laufen und sind für den Entwickler dennoch genauso wie die lokal auf dem NAO laufenden Module nutzbar. Erreicht wird diese Transparenz durch Proxys, die für den Programmierer stets den | + | Dieses API wurde von Aldebaran Robotics geschaffen, um die Programmierung des NAOs auf ein vernünftiges Level zu heben. Sie stellt die zentrale Schnittstelle zur Nutzung und Erweiterung der Funktionalitäten des Roboters dar und ist modular aufgebaut. Dank NAOqi werden selbst komplexe Dinge wie Sprach- oder Objekterkennung zum Kinderspiel. Darüber hinaus lassen sich selbst implementierte Module mithilfe der zugrunde liegenden Broker-Architektur einfach hinzufügen. Sie können auch auf einem externen Rechner laufen und sind für den Entwickler dennoch genauso wie die lokal auf dem NAO laufenden Module nutzbar. Erreicht wird diese Transparenz durch Proxys, die für den Programmierer stets den Einsprungpunkt zur Modulnutzung darstellen. Klarerweise bietet NAOqi auch einen Eventmechanismus, durch den auf Ereignisse im klassischen Stile reagiert werden kann. |
+ | |||
+ | Die [http://doc.aldebaran.com/2-8/dev/naoqi/index.html Seite Key Concept] der Doku gibt einen guten Eindruck ueber die Zusamenhaenge der Begriffe: Broker(NAOqi), Libraries, Module, Methoden, ... | ||
+ | |||
+ | NAOqi als Broker ermoeglicht einen | ||
+ | * Directory services, welcher das Auffinden von Modulen und Methoden erlaubt und | ||
+ | * Network access, welcher es ermoeglicht Methoden von geladenen Modulen von auszerhalb aufzurufen (Remote) | ||
+ | |||
+ | In der Dokumentation wird von mehreren Brokern gesprochen (?). Sie arbeiten transparent im Hintergrund und ermoeglichen dem Entwickler, identische Methoden-Aufrufe zu lokalen- (gleicher Prozess) oder remote-Modulen (anderer Prozess oder andere Maschine) zu zu benutzen. | ||
=Kernmodule= | =Kernmodule= |
Version vom 22. Februar 2023, 11:22 Uhr
Inhaltsverzeichnis
Ueberblick
Erst mal eine lose Begriffssammlung.
Auch wenn das "Betriebssystem" NAOqi heiszt gilt es auch fuer Pepper, wohl auch fuer Romeo, Plato, ...
Zitate aus [[1]]
NAOqi als zentrale Programmierschnittstelle
Die Programmierung des NAOs ist auf verschiedene Arten möglich. Sollen die Programme direkt auf den Roboter geladen und von diesem ausgeführt werden, so kann man auf Choregraphe inkl. Python oder auf C++ setzen. Gibt man sich damit zufrieden, den Roboter per Fernzugriff zu steuern, so lässt sich zusätzlich noch auf Java, .NET, Matlab und Urbi zurückgreifen. Wichtig zu verstehen ist: Egal für welche Variante sich der Entwickler entscheidet, letztendlich arbeitet er stets gegen das Robotik-Framework NAOqi.
Dieses API wurde von Aldebaran Robotics geschaffen, um die Programmierung des NAOs auf ein vernünftiges Level zu heben. Sie stellt die zentrale Schnittstelle zur Nutzung und Erweiterung der Funktionalitäten des Roboters dar und ist modular aufgebaut. Dank NAOqi werden selbst komplexe Dinge wie Sprach- oder Objekterkennung zum Kinderspiel. Darüber hinaus lassen sich selbst implementierte Module mithilfe der zugrunde liegenden Broker-Architektur einfach hinzufügen. Sie können auch auf einem externen Rechner laufen und sind für den Entwickler dennoch genauso wie die lokal auf dem NAO laufenden Module nutzbar. Erreicht wird diese Transparenz durch Proxys, die für den Programmierer stets den Einsprungpunkt zur Modulnutzung darstellen. Klarerweise bietet NAOqi auch einen Eventmechanismus, durch den auf Ereignisse im klassischen Stile reagiert werden kann.
Die Seite Key Concept der Doku gibt einen guten Eindruck ueber die Zusamenhaenge der Begriffe: Broker(NAOqi), Libraries, Module, Methoden, ...
NAOqi als Broker ermoeglicht einen
- Directory services, welcher das Auffinden von Modulen und Methoden erlaubt und
- Network access, welcher es ermoeglicht Methoden von geladenen Modulen von auszerhalb aufzurufen (Remote)
In der Dokumentation wird von mehreren Brokern gesprochen (?). Sie arbeiten transparent im Hintergrund und ermoeglichen dem Entwickler, identische Methoden-Aufrufe zu lokalen- (gleicher Prozess) oder remote-Modulen (anderer Prozess oder andere Maschine) zu zu benutzen.
Kernmodule
- ALMemory
Key-Value Store Basis für den Eventmechanismus: subscribeToEvent() Callback-Methode raiseEvent()
- ALMotion
Einzelsteuerung der Koerperteile
- ALNavigation
Im Raum bewegen: Navigation
- ALRobotPosture
Audiomodule (10 Stueck)
- ALSpeechRecognition
- ALTextToSpeech
Video (24 Stueck)
- ALFaceDetection
- ALPhotoCapture
Abruf Standard-Positionen: Liegen, Sitzen, Stehen
Choregraphe
Die in der Version 2.8.6.23 mitgelieferte Box Library unterscheidet sich doch oft wesentlich von den Vorgaengerversionen. So sind aeltere Referenzen oft nur wenig hilfreich. Die aktuelle Dokumenation ist hier zu finden. Die Box Library teilt sich (derzeit) in 7 Bereiche (Folder):
- Animation
- Speech
- LEDs
- Multimedia
- Movement
- Sensing
- Programming
Ueber die Suchfunktion findet man recht schnell die gesuchte passende Box. Boxen koennen auch Makros sein. Z.B. ist Twinkle eine Abfolge von 'Wait' und 'Set LEDs'-Boxen.
Das Hauptfenster zur Boxmontage zeigt beim Ablauf zwar die aktuellen Transitionen, aber nur sehr kurz. Leider kann man nicht sehen, welche Box gerade ausgefuehrt wird.
Die Transitionen haben scheinbar auch Farbbedeutung:
- Bang schwarz
- Dynamix grau
- String blau
- Number orange
Python-Box
Die wichtigste Box ist aber vermutlich die Python-Box, da man mit ihr alle Funktionen in Choregraphe hinbekommt.
Die Funktionalitaeten der Boxen sind wohl hier hinterlegt.
/opt/aldebaran/lib/python2.7/site-packages/albehavior.py
Ohje, Python 2.7!
Aber eigentlich es dieser Pfad bei mir!?
/opt/Softbank Robotics/Choregraphe Suite 2.8/lib/python2.7/site-packages/albehavior.py
Aufbau:
z.B. je nach Notwendigkeit import time import sys, os import smtplib, email
- Platz fuer eigene Funktionen
Klassendefinition class MyClass(GeneratedClass):
def __init__(self): GeneratedClass.__init__(self) # ab hier werden die notwendigen Variablen auf ihre default-Werte gesetzt
oder
class MyClass(GeneratedClass): def __init__(self): GeneratedClass.__init__(self, False) # ab hier werden die notwendigen Variablen auf ihre default-Werte gesetzt
Nach __init__ kommen je nach Bedarf die Methoden der Verarbeitung
onLoad Konstruktor
onUnload Destruktor
onInput_<name>(self,p) p je nach Type "Bang", String, Number oder Dynamic und Nature onStart, onStop oder onEvent
LEDs
LEDs group
- AllLeds
- BrainLeds
- EarLeds
- FaceLeds
- FeetLeds
- LeftEarLeds
- LeftFaceLeds
- LeftFootLeds
- RightEarLeds
- RightFaceLeds
- RightFootLeds
TODO
Flussdiagramme Startknoten (Aktions-)Boxen Kontrollstrukturen Transitionen Verbindungen zwischen Boxen zur Token und Datenuebergabe Stimulus des Boxeingangs Tokenweitergabe Petrinetz
Autostart
/opt/naoqi/modules/lib/autoload.ini
Dateinamenerweiterungen
- CBL Choreographe Box Library (.clxb?) komprimiert
- XAL Box Library (<V1.10) nicht komprimiert
Box Inspektor
- General
Name, Description, Image
- Inputs (Anzahl)
- Outputs (Anzahl)
- Parameters (Anzahl)
- Set Parameter(s)
- Plugin
Datentypen/Events
- Type
Bang, String, Integer, Float
- Nature
onStart, onStop, onStopped, punctual, onEvent