Yesterday Hung, Jayen & I started work on UNSW’s code base for the 2010 Robocup competition, and ended up with something quite neat that we didn’t have before. The Nao runs a piece of software from Aldebaran called ‘NaoQi’, which provides an abstraction layer over the Robot’s hardware, and also some sort of inter-process communication for each of the ‘brokers’ you are running. rUNSWift has previously had just one broker, which internally manages the communication between each of its modules. This has the benefit that it is very fast, when compared to using ALMemory, however it means that whenever we want to upload new code to the robot, we have to completely restart NaoQi to reload the librunswift.so shared-object library.
The new approach involves having two ‘brokers’: ‘loader’ and ’soccer’. The loader is loaded by the the NaoQi automatic loader on startup, using the same method that librunswift.so used to be loaded. The loader has methods called startSoccer() and stopSoccer(), which will load and unload libsoccer.so on demand. The loader can be communicated with over the network, and we hope to integrate this with our off-robot debugging utilities. With any luck this should greatly cut down on wait time between builds of the various rUNSWift modules.
We still have the performance advantage of having all the core components (vision, behaviour, localisation, locomotion, etc.) inside the ’soccer’ broker, avoiding ALMemory for everything except when we reload code through the loader.
No Comments Yet