any feedback will be appreciated

1. Aquila 2.0
Architecture proposal

2. Current limitations
• Modules are not available as separate,
reusable YARP processes
• Modules can only run on the host machine
• Growing number of modules introduces more
complexity and makes the compilation
process more difficult
• Linux-only support

3. Current benefits
• Easy to use user interface
• Simple to use by non-programmers (e.g.
psychology researchers, undergrads etc.)
• Provides several useful tools and also
interfaces for commonly used features in the
iCub repository
• GPU-accelerated processing

4. Current Aquila
Architecture
ITALK
Sequence Modi
Terminal MTRNN Demo
Recorder Experiment
(ERA)
Aquila 1.x Helper classes
SOM Vision Simulator ARA CUDA

5. New Aquila
Architecture
Control
panel Aquila 2.0 iCub
Sequence Modi ITALK
MTRNN
Recorder Experiment Demo
SOM Vision

6. Control
panel Aquila 2.0 iCub
• Aquila 2.0 will provide the control panel and the iCub modules
only.
• Control panel lets users to load different Aquila-compliant
YARP modules and provides information about CUDA and
visualises connected modules. Aquila should also detect if
any of the modules is already running, both on host and
remote machines.
• iCub module provides automated launching and/or
graphical interfaces for commonly used features e.g. face
expressions, force control, skin and robot motor GUIs
• This modules also contains the current simulator module

7. Control
panel Aquila 2.0 iCub
• This new user interface will be very light and will not need any additional dependencies,
just Qt for the GUI and YARP for the communication
• All other modules will be developed as separate YARP processes that will be usable
without Aquila. However, all these modules (so-called Aquila-compliant) will also contain
configuration files that will be used by Aquila to construct the required UIs for the
modules on the fly. Different modules will appear as separate tabs within Aquila
• Some modules, for example the MTRNN should be able to be executable on host and
remote machines and have several instances and therefore have unique port IDs. Aquila
can then provide UI for all the instances running on other computers and utilising different
GPUs for example.
• If some dependencies were not met during the iCub compilation process then Aquila will
load only the UIs for the modules that were compiled
• Aquila-compliant modules will communicate with Aquila via extra YARP ports e.g. /mtrnn/
aquila/ui:o,i and Aquila will receive commands through e.g. /aquila/module_id/ui:i,o

8. Control
panel Aquila 2.0 iCub
• Runs on Linux, Windows and OSX
• Decoupled Aquila-compliant yet Aquila-independent modules
• Modules can run on any machine with any compatible OS on the YARP
network
• Modules can have multiple instances with multiple Aquila UI tabs. (e.g.
Training of multiple MTRNNs at the same time on different GPUs and
different computers)
• Better platform for developers
• Easier to use and to debug
• Simpler, faster and more efficient

9. Aquila 2.0
Your thoughts and suggestions would be appreciated