rUNSWift Infrastructure

The infrastructure is for our code base is based on the 2010 rUNSWift code release. Details can be found [here] (https://github.com/UNSWComputing/rUNSWift-2010-release). One major new piece since then is the Python-C++ Bridge for running our infrastructure. That is described below.

Python Infrastructure

We use python as a high level language for writing behaviour code. The reasons for this are discussed in depth at: Carl Chatfield Robocup Report 2012 - Chapter 3

In order to enable this, we use the boost python libraries to set up an embedded python interpreter within our runswift executable that has access to parts of our blackboard. In every perception cycle, an entry tick() function is called by our c++ code within the python interpreter instance with a reference to the blackboard. The expected return value is a BehaviourRequest object that contains any information to pass back into the C++ code (primarily actions for motors & leds).

Key directories relating to the python interface:

• robot/perception/behaviour/

  This folder contains the c++ parts of the behaviour chain. In BehaviourAdapter.cpp, it creates a PythonSkill (defined in the python subdirectory). On every tick, it executes the PythonSkill which returns a BehaviourRequest to it. This is then used to write actioncommands to the blackboard.

  • python/

    The important pieces here:

    • wrappers - Wrappers over some data types (see the report/code for details).
    • converters - Converters for arrays, etc (see the report/code for details).
    • PythonSkill.cpp - The PythonSkill class manages executing a python interpreter (setting up modules, paths, etc). It also watches files and reloads the interpreter if they change. This is useful for quick iteration on code (simply nao_sync your new code over and the robot runs the new code). It also handles python exceptions that are uncaught by flashing the Leds, saying "Python error", and reloading the code. This is useful because in game, if your python code reaches an untested state and crashes, you want the interpreter to restart and continue (but notify you that it failed).
    • RobotModule.cpp - This pulls all the wrappers in and gets compiled into a python module which can be imported within the interpreter as robot. You can then access parts of the wrapped cpp code. e.g

      # This is a simple behaviour.py
      import robot
      
      def tick(blackboard):
          req = robot.BehaviourRequest() # Creates a Behaviour Request instance.
          req.actions.leds.rightEye = robot.rgb(True, False, False) # Set right eye to red.
          return req

• image/home/nao/data/behaviours

  This is where the python files that run on the robot are kept. This folder gets synced to the robot by nao_sync. The highest level file here is behaviour.py. This file is run by PythonSkill at the top level. It calls the tick() function on this module, passing it a reference to the blackboard. The function must return a BehaviourRequest instance. Whatever else happens is up to your python architecture and can be customised to match some form of state machine / decision tree / other behaviour system implemented in python.