Upload
others
View
5
Download
0
Embed Size (px)
Citation preview
10
20
Author: David Claridge
Supervisor: Dr Bernhard Hengst
Research Theme: The Digital Future
School of Computer Science & Engineering
A Software Architecture for the Nao Humanoid Robot
Background
RoboCup is an international robotics competition
founded in 1993. The aim is to develop autonomous
soccer robots with the intention of promoting research
and education in the field of artificial intelligence. The
official goal of the project is:
“By mid-21st century, a team of fully autonomous
humanoid robot soccer players shall win the soccer
game, complying with the official rule of the FIFA,
against the winner of the most recent World Cup.”
Since 2008 the Aldebaran Nao Humanoid Robot has
been the official platform used the Standard Platform
League of the Robocup competition.
Decoupling Logic & Actuation: libagentThe manufacturers of the Nao Humanoid Robot
provide an interface called NaoQi for reading sensor
values and writing actuation commands to the
hardware platform. They encourage developers to
implement their entire system as a ‘NaoQi Module’,
however this creates a number of problems:
•Robotic code cannot be run off-line or in simulation.
•Debugging requires stepping through the NaoQi
threads as well as our own.
•Flaws in the NaoQi system may mask or extenuate
bugs in our own software.
•Our code cannot be reloaded without restarting
NaoQi, slowing down development time.
To work around these limitations, we developed a
lightweight NaoQi module called ‘libagent’ that
provides a wrapper around NaoQi and communicates
with our main robotic software package through
shared memory, with synchronisation provided by a
kernel-level semaphore.
The ‘runswift’ executable is run as an independent
process, and communicates with ‘libagent’. As a
result our software package has no expectation of
actual robotic hardware being present, only that some
process receives and processes data in the shared
memory block. This makes it significantly simpler to
run code off-line or through a simulator. This
executable can be run using common debugging and
profiling tools such as gdb, valgrind or gprof, without
any interference from NaoQi.
This diagram shows the interaction between libagent
and NaoQi’s low-level control module.
Blackboard Shared-Memory InterfaceTo maximise the flexibility of this architecture, each
module must be independent of all others, and use a
common interface for sharing information. This
architecture utilises the ‘Adapter’ design pattern, in
which each module has only one class that may talk
to the shared memory. This adapter guarantees that
modules can make atomic reads/writes to/from the
Blackboard and that each module encapsulates all
data it needs to utilise.
High-Level Behaviours: PythonTo increase developer productivity, the high-level
behaviours are written in a scripting language, in this
case Python 2.5. The rest of the architecture is written
in C++ which provides excellent performance, but
Python, whilst slower, can be reloaded at runtime.
This allows developers to manipulate behaviours and
observe their effects in real time. The architecture
developed extends the libpython framework for
converting native C++ data types to and from Python.
Each cycle of Behaviour writes an ‘ActionCommand’
to the Blackboard, which is in turn read by the Motion
module, which actuates the joints, sensors and LEDs.
ENGINEERING @ UNSW
UNSW
Aim
•To design a robust software architecture, targeted for
us as the base of a soccer player on a Nao V3
Humanoid Robot.
•To implement this architecture, so that it may be used
by the UNSW Robocup team in the 2010 Robocup
World Championships in Singapore.
Conclusion
The robotic architecture developed will provide a
suitable base for future research in robotic vision,
localisation, motion and behaviour for users of the Nao
V3 Humanoid Robot. It is also sufficiently flexible that
it could be translated to work on a different robotic
platform with a reasonably small amount of effort.