Aldebaran NAOqi

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, ...

Ein 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.

Ein Proxy ist ein Objekt, das sich wie sein Modul verhaelt. Ich wuerde mal behaupten, dass ein Proxy (Instanz, Objekt)ein instanziiertes Modul (Klasse) ist. Wenn man einen Proxy erzeugt muss man zwei Arten, naemlich Locals Calls und Remote Calls, unterscheiden.

Module

Ein Modul ist eine Klasse(ndefintion) in einer Library. Wenn eine Library in der autoload.ini geladen wird wird, werden alle darin enthaltenen Methoden instanziiert.

Ein Modul kann sowohl

• local als Library kompiliert und auf dem Robot laufend (effizienter)
• remote als Programm kompiliert und auf einem externen PC laufend (langsamer, aber besser zu debuggen)

sein.

Hinweise:

• Lokale Module laufen alle im gleichen Prozess. Sie kommunizieren ueber ein und denselben Broker. Sie koennen Variablen gemeinsam nutzen und gegenseitig Methoden ohne Datenserialisierung und Netzwerkkommunikation benutzen.
• Remote Module nutzen eine Netzwerkverbindung zur Kommunikation.
• Remote Module unterhalten sich ueber einen Broker in SOAP. (langsam!)
• Remote Module an verschiedenen Broker benoetigen eine Broker zu Broker Verbindung.
• Eine Brocker2Brocker-Connection ist bidirektional.
• Eine Proxy2Broker-Connection ist unidirektional.

Kern

• ALMemory

Ist die Representation des Speichers. Das Modul bietet keine Echtzeitsynchronisation! Bietet ein Array ALValue an. Es gibt 3 Arten von Datentypen:

1. Daten von Aktuatoren und Sensoren
2. Events
3. Mikro-Events

Basis für den Eventmechanismus: subscribeToEvent() Callback-Methode raiseEvent()

• ALMotion

Einzelsteuerung der Koerperteile

• ALNavigation

Im Raum bewegen: Navigation

• ALRobotPosture

Audio (10 Stueck)

• ALSpeechRecognition
• ALTextToSpeech

Video (24 Stueck)

• ALFaceDetection
• ALPhotoCapture

Abruf Standard-Positionen: Liegen, Sitzen, Stehen

(?)Key-Value Store

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):

1. Animation
2. Speech
3. LEDs
4. Multimedia
5. Movement
6. Sensing
7. 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

1. 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

Um eine simple LED-Animation in Choregraphe zu "programmieren" holt man sich allerdings schnell das Leben.

LEDs group

1. AllLeds
2. BrainLeds
3. EarLeds
4. FaceLeds
5. FeetLeds
6. LeftEarLeds
7. LeftFaceLeds
8. LeftFootLeds
9. RightEarLeds
10. RightFaceLeds
11. 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

Links

[2]