"E-Ger" (short for Edger) is a servo-powered, differential-drive robot designed to run around a table-top without falling off (fingers-crossed), as well as avoid obstacles and test various sensor-based behavioral protocols. E-Ger is built on a MarkIII mini-sumo platform.
E-Ger is driven by 2 servos modified for continuous rotation, and has the following complement of sensing devices:
E-Ger can be programmed with up to 126 different behavioral repertoires, and was specifically built as a testing platform for the OricomTech WMC12 Walking Machine Controller.
<| BEHAVIORAL STATE MACHINE ARCHITECTURE
The figures at the right show a representative logic diagram used for sensor-controller testing of the robot E-Ger. In this case, there are 11 different states, each representing one of the possible 126 behavioral blocks that can be stored in eeprom.
Setup. Each state is constructed by entering a list of servo movements into a Behavioral Block Table of the WMC chip, in addition to setting up an associated Alarm Table. The functions performed by each block are indicated, eg move forward, move backwards, left-turn, right-turn, send a message in Morse code (eg, 'eger'),etc.
Each state is executed a specified #times, and then linked automatically to a follow-on state, as indicated by the 'K' pathways. Alternately, a state transition can occur if an alarm is triggered, as indicated by the pathways marked by 'Axx' and 'Dxx'. These represent various analog and digital alarm channels triggered by the various sensors - drop-off, proximity, etc. The '+Axx' and '-Axx' symbols under the state boxes indicate individual alarm enabling and disabling when in the given state.
Behavior. The state diagram here allows the robot to run around the top of a table, and respond to the table edges by taking evasive action, including backing up and turning. The robot can also respond to obstacles in its path using the IR-proximity detectors to sense them, and then turning and / or spinning out of the way. In the scheme shown here, E-Ger starts up in State S09, beeps its name in Morse code 4 times, and then enters State S00, which has been selected as the central state to which all behavioral pathways (except low-battery shutdown) eventually return. In State S00, the robot moves straight forward, with all sensors enabled, until one of the sensors detects a drop-off or an obstacle in its path. It then takes the evasive action specified by the triggered alarm, after which it loops back into State S00, and proceeds to go forward again.
Storage and I/O. Once the various Block and Alarm Tables are defined, they are stored in eeprom, and loaded as required, whenever one of the links is activated or an alarm is triggered. Each of the Block Tables can be very simple, or can include up to 44 individual servo operations. This allows a single behavioral block to produce very complicated movement sequences, such as multiple turns, spins, several forward+backward movements, pauses, a dance, etc. Table entries can also be used to activate various output devices. It's not shown in the diagram, but the various block tables were also programmed to beep the state #'s in Morse code, and also blink a group of Leds connected to I/O pins not used by the servos.
Complex Behavioral Repertoires. The diagram here shows only one small behavioral repertoire involving 11 behavioral block tables, and longest pathway of only 2 states, before returning to State 00. However, up to 126 block tables total can be stored in eeprom, and set up as a number of separate behavioral repertoires, with repretoires acting alone or linked together in a large state machine. Behavioral repertoires can have long sequences with a large number of linked states.
For example, the bot can be going along performing a certain behavior involving a number of linked states, as above, and then when a certain alarm triggers, such as a low-battery indication, it can branch to a latent behavioral sequence involving a number of linked blocks which directs it towards a charging station. Note that this can all be done autonomously by the WMC chip, without need for a higher-level host processor.