Using the framework modelled in Section 3.2, we now look to create a physical instanti- ation of the IDGP framework. This requires first choosing the device hardware which is described in Section 3.3.1. Upon deciding the hardware, Section 3.3.3specifics of how the framework is implemented (in software) on the specific architecture.
3.3.1
The Fleck3b Mote Platform
There are many WSN platforms available [2], however the CSIRO Fleck™3b platform [114] was readily available, and importantly, it meets the criteria identified inSection 3.1.5.
The Fleck™3b employs the Atmega1281 microprocessor running at 8 MHz with 4kB EEPROM, 8kB SRAM, 128kB program flash. The low power microcontroller is comple- mented with the Nordic NRF905 low power digital transceiver (<100mW during transmit, < 43mW during receive) which enables the Fleck™3bto communicate at 50kbps across 1 km using a 915 MHz quarter-wave whip antenna. The Fleck™3b can measure many external sensors though the ADC connector block and also measure onboard sensors such as the power used by the mote. The platform has features 3 onboard LEDs, a red, a green and a yellow, which are software controlled. An overview of the board layout and functionality is shown inFigure 3.4.
LEDs Fuse Power Switch SMA Antenna Connector 14 Pin Datamate • Power • Programming • 2 x RS232
Low Power Microcontroller • ATMega128L
• 8MHz clock • 4/8 Kb RAM • 4Kb EEPROM Solar Charge Input
3 x 10bit ADC
915MHz radio Nordic nrf905
4 x GPIO Pins
Battery connector
Real Time Clock
1-8 Mb Flash
Onboard Power Conditioning and Monitoring • Regulated 3.3V • Battery Voltage • Battery Current • Solar Voltage • Solar Current Onboard Temperature Sensor Daughterboard Bus • 2 x 20 Pin • Regulated 3.3V • Unregulated Vcc • Complete power off • SPI
• 2 x UARTs • 21 GPIO Pins • 4 x 10bit ADCs
Figure 3.5: Fleet of “Fleck cars” (circa 2008).
TheFleck™3bplatform has been used for numerous research and real-world applica- tions [20,39,47,48,99,101,115,120,137,139] though mainly for outdoor applications such as environmental monitoring and animal tracking/monitoring.
Preliminary testing of the IDGP framework was performed withFleck™3bdevices that were embodied in small remote control cars where the original motor controller circuitry was replaced by the mote platform. An infrared range sensor (Sharp GP2Y0A21YK) was attached to the front and connected into an ADC and the motors were controlled with a specific motor controller daughterboard. The initial implementation of IDGP was performed on these small robots and a number of behaviours were evolved. The “Fleck cars” (shown in Figure 3.5) were trained to avoid crashing into walls, however they also demonstrated online learning capability. This was achieved by using the range sensor as the fitness feedback. When the behaviour of the car was desirable, the trainer could place their hand in front of the range sensor to provide a level of fitness feedback including not putting the hand in front (lowest fitness). Through this, one could evolve a behaviour such as mostly driving forward, but then later retrain it to drive mostly in reverse by providing appropriate feedback when the desirable behaviour was displayed. This investigation was
not performed under experimental design and so have been omitted from this thesis. The maintenance, due to the cheap remote control car components frequently failing, was deemed too excessive. As such, the Fleck™3b devices had light sensors attached to the onboard ADCs to provide sensing input, while the onboard LEDs provided actuation capability that could affect the environment and also be sensed by the light sensors. This configuration (shown in Figure 3.7) provided a low maintenance mote-class device with sensing and actuating capability suitable for experimentation.
3.3.2
Program Representation
The current IDGP implementation employs a hybrid tree-based program representation as suggested in Section 3.2.2.2, and supports the int16 type and functions with up to 3 arguments (though is easily extensible to additional types and functions with more argu- ments). For ease of implementation each op code is passed to a switch statement and the corresponding code called. The Prefix, Jump-Table (PJT) approach suggested in [63] requires slightly more complexity in constructing a program, however the PJT approach is more modular and cleaner.
The op code representation differs from typical GP C++ representation such as that used in [63] in that variables and constants are not memory references. Instead, IDGP directly embeds variables and constants into the code as either the variable number or the actual constant value. The prefix notation implemented uses 1-byte instructions and an optional 2-byte datum field if required by the instruction. Constants (signed 16-bit integers) are currently the only instruction which use this datum field, and are therefore represented by 3 bytes. The advantage of the datum field is that constants are directly embedded in the program rather than pointing to an external reference which would have to be moved with the program when it is shared. Two bits of the instruction byte are reserved for a variable index which removes the need for the 2-byte datum field when the variable instruction is used. When only 1 byte is used for the op code, this approach limits programs to a maximum of 4 variables and a maximum instruction set of 64 instructions. The obvious advantage to this representation is however an extremely compact program
Table 3.3: Instruction Representation
Bits 0:1 2:7 8:23 (Optional)
Use VAR index Op Code Datum Field
with nearly all instructions using only a single byte. Table 3.3 shows how instructions are formatted.
3.3.3
Program Evaluation on Fleck OS
The Fleck Operating System (FOS) [21] is a small code footprint, cooperative threaded operating system designed for low power, embedded devices with limited ROM and RAM. FOS was originally implemented for theFleck™3bhardware previously described inSec- tion 3.3.1. FOS applications are written in C and support numerous high level functions such as routed radio messages, sensing of onboard sensors and external sensors and remote procedure calls via radio. The cooperative threading model allows complex pro- grams to be written in a compact and elegant manner which is easily understood. IDGP was implemented as a FOS application with each program running as a thread and su- pervised (spawned and killed) by the ’evaluation thread’. Since FOS is not preemptive threading, the evaluated programs have to explicitly yield to give control back to the ’eval- uation thread’. This was achieved by placing yield statements between each instruction (in the virtual machine program execution) and ensuring that all instructions either completed or yielded within a short period.
Programs that are distributed for the Island Model are broken into fragments and broadcast (single-hop). Once all fragments of a program are received, the program is reconstructed and pushed into the queue of immigrant programs where it can be used by the GP engine during construction of the next generation of programs.