Architecture diagram
This paragraph presents the overall NAOqi architecture.
1. Safe architecture
A broker named "NAOqi" is continuously running on the robot. However you can also run it on all the platforms. If this broker crashes, the robot falls and can fall badly. All the libraries dynamically linked to the mainbroker can make NAOqi crash. In a safer architecture, methods are called from another user broker. If the user broker crashes, the robot will be less likely to fall. Remote process/broker will not communicate under 100ms.
To implement this architecture, myBroker must be launched after mainbroker (NAOqi).
2. Unsafe architecture
In this architecture, a crash in a user module makes NAOqi crash and therefore, the robot might fall. However, calls are faster than in the remote solution.
3. Current NAO architecture
In this architecture, user's brokers or modules can be plugged in from anywhere.
Audioout
Executable or local module
- audioplayer: play file
- ALTextToSpeech: text to speech (english by default)
Telepathe
GUI that allows you to watch variables and offers GUI visualization on NAOqi.
- camera viewer: see camera on PC
- memory viewer
NAOqi mainbroker
Modules in NAOqi can be required (in [core] section of autoload.ini) or optional (in [extra] section of autoload.ini).
- ALLauncher: automatically loaded. Manage external library
- ALNetwork: automatically loaded. Manage remote network communication
- Framemanager: read Choregraphe project and use embedded python interpreter
- PythonBridge: embedded python interpreter
- ALPreferences: manage xml preference file. The module is in albase.so
- ALMemory: shared memory of robot. The module is in albase.so
- ALLogger: manage log. The module is in albase.so
- ALBonjour: Apple protocol that allow to find device on network
- ALFileManager: Manage robot files.
All core and optional modules are describe in API blue doc.