January 23, 2022. by Manuel Rodriguez
The control element of a BEAM robot is the nv network, also known as bicore. It is realized with an analog circuit. The purpose of the nv network is to work as a central pattern generator. A CPG generates similar to an oscillating neural network a pattern for controlling flashing LEDs or servo motors over a longer time period. The CPG tells exactly which status 4 and more LED will have over the next 20 time steps in the future. This reduces the complexity of control tasks.
The following longer article explains in detail what BEAM robotics is, and why it is different to programmable robots.
Tags: BEAM, CPG, quadruped walking robot, bicore, nv net, bottom up robotics
Table of contents
1 Introduction into BEAM robotics
2 CPG for a hexapod walking robot
3 The inner working of a 5 motor bicore walker
4 What robotics can learn from BEAM robotics
5 Why BEAM Robotics has felt out of fashion
6 Sources
1 Introduction into BEAM robotics
Since the 1990s the idea of Bottom up robotics was published. Bottom up robotics was described as opposite to planning and means to program the behavior of the robot with Scripting AI. That means the robot has some built in procedures like walk(), rotate(), and sense() and these procedures are producing complex motions. What is not needed is a fast CPU or a solver.
On step further than normal bottom up robotics is the idea of BEAM robotics.[1][2] Similar to bottom up robotics described by Rodney brooks, BEAM robotics is a bottom up approach. The difference is that no computer program at all is needed. Instead the actions are triggered by analog circuits.[3]
Most programmers in the now are no longer familiar with analog circuits. The basic idea is to let let an LED flashing in a certain pattern. That means, the led is on from timestep 0 to 2 and it is off from timestep 3 to 8. Then the cycle starts again. If not one but 4 leds are flashing with different patters the core element of a BEAM Walking robot is available.
There is no need to built a BEAM robot in hardware, but the concept can be utilized in a simulator more easily. All what is a needed is a physics engine like Box2d and a for loop for the pattern generator. A common way to let an LED flashing in a python program is the modulo operator, but more complex waveforms can be realized with mathematical equations like sinus as well.
So let us analyze the principle from an AI perspective. Suppose the robot motor is controlled by a flashing LED pattern. It depends mostly on the mechanics if the robot moves forward. It is not a program which runs on a computer, but it is the same pattern repeated over and over again. Perhaps it can be compared with music notes which are played back in a loop and these pattern moves the robot (sometimes).
Let us try to simplify the information about BEAM Robots. To build a so called nv network the programmer needs to simulate an LED flashlight in software. And then he has to program the led so that it will flash in a certain pattern. This oscillator is the brain of the robot.
The reason why the analog circuit of a BEAM robot is formed in a certain way is to produce an inversely oscillating pattern. That means on frame step 0 the motor A is on while motor B is off. At framestep 10 the motor A is off while motor B is on and so on. This can be visualized with a drum editor from a music software. In the example screenshot there are two sounds available (clap and hihat) and they are making a sound at different positions in time.
 |
| Drum editor in a music sequencer |
Where is the world model?
Short answer: a CPG controlled robot has no world model. The only thing which was implemented is the robot movement itself. The nv neural network makes sure that the robot's legs are moving in a certain pattern but the robot is not aware if these actions are useful. What is missing in bottom up robotics is a virtual referee which is sometimes called a critic. Such a higher instance would monitor the current score of the robot during solving certain situations. Without a referee the robot isn't aware of any obstacles or wrong directions the pattern generates. Because of this reason, BEAM Robotics is seen as a non sense and chaotic discipline in Artificial Intelligence.
 |
| Mindmap for BEAM robotics |
Central pattern generator
On the first look, BEAM robotics seems to be a hard to grasp alternative approach in robotics. The reason is, that it's focused on analog circuits, is working bottom up and has no microprocessor nor a computer program. It's possible to explain in detail why this approach makes sense, but the more elaborated attempt in understanding BEAM is by asking what are the shared principle to conventional academic robotics. The same part is a central pattern generator (CPG). CPGs are researched in classical topdown AI and in BEAM Robotics as well.
In case of BEAM robotics, the abstract idea of a CPG is realized with nv networks. The analog circuit, including its components, is creating a central pattern generator.[4] And this is used to control the motors. The interesting situation is, that there is no need to do so in hardware. A central pattern generator can be created in software more easily. For example with mathematical equations like a sine function, with neural networks implemented with the sigmoid function or by using the modulo operator in a for loop. It's possible to build BEAM robots without creating them in physical hardware. Instead the idea of a CPG is put into the center and the robot is created around this building block.
From a programming perspective, a CPG is a black box which generates signals over a time axis. If the CPG has four outputs, it can control four flashing LED lights in parallel. Creating a CPG in Python or any other programming language is surprisingly easy. It can be realized with a random generator or with a pattern sequence which is repeated over the time. For example, in a 2d array some 1 and 0 values are stored and then the signal is printed on the screen according to the frame step in the game loop.
0 1 0 1
0 0 1 1
Here, the pattern was written in the matrix notation known from mathematics. This pattern is equal to the central pattern generator. A single column is shown on the screen, for example in timestep #0 the output of the CPG is 0\:0. This output is send to the flashing LED or to the motor of a walking robot and it will produce a certain result. Fine tuning a CPG means nothing else but changing the values in the pattern matrix.
 |
| Waveform as diagram |
nv network = Central pattern generator?
BEAM robotics is a large and complex domain which has many subproblems. There are tutorials available how to solder transistors, how to implement the circuit for a solar panel and also some ideas are given which sort of robots can be realized, for example walking robots and wheel driven robots. The perhaps most interesting element in BEAM robotics is the NV net, which stands for nv network. This element defines what the robot is doing at which moment.
After investigating the question what an nv network is and how to program it, the answer is surprisingly simple. An NV network is a central pattern generator, not more and not less. It's a CPG realized in an analog circuit. So the question is not how to build a BEAM robot which can walk but the more elaborated question is how to use a CPG to create walking robots in general. These robots can be realized with the BEAM concept which stands mostly for analog circuits, but they can be realized with micro-controllers for example Lego mindstorms and Arduino as well.
The idea of a central pattern generator seems to be even more esoteric than BEAM robotic itself. A CPG is described mostly in the context of biological systems. It is working different from a classical program. The dominant question is how to generate a trajectory for example for biped walking. A trajectory is not a single value, but it is a function over time. So a sinus function seems to be the natural Central pattern generator available.
There is a concept available which has much in common which are dynamic movement primitives.[5] Similar to a CPG the DMP approach tries to reduce complexity. Instead of defining for each time frame what the robot has to do with which servo motor the idea is to provide a general equation which is fine tuned with parameters. This equation creates a longer and repeating action trajectory over the time axis.
2 CPG for a hexapod walking robot
There is a reason why most mobile robots have been realized with a wheel based locomotion. The reason is that wheels are pretty easy to control. All what is need is an electromotor which powers the wheel and after putting a current on the circuit the robot will move forward. Even if the principle is improved by a gearbox and a steering wheel the overall design remains tractable. This allows to design more complex behaviors for example a robot mouse who can find the goal in a maze.
In contrast, leg based robots are much harder to control. Especially if the amount of legs is 4 and more the overall system is for sure np hard. For example if a hexapod robot has two motors for each leg then the overall amount of joints is 12. And in each time step a different position can be set so the overall complexity is endless. The interesting situation is, that with a central pattern generator the complexity can be reduced drastically. The only thing what is needed to control six and more legs at the same time, is a gait pattern and some sinus functions. The sinus function will take the gait pattern as input and are producing the joint rotation as output. The advantage is, that the robot isn't depending on million of possible gait positions, but there are only a handful gait patterns and some possible sinus functions for the central pattern generator. Most robots which have 4 and more legs are designed with a cpg in the loop because this is the best practice method to reduce the complexity. Instead of controlling the legs directly the task for the programmer is to fine tune the cpg. So it is some sort of black box for state space reduction.
 |
| Sine oscillator in Libreoffice calc with the equation value=(SIN(A2)+1)/2 |
3 The inner working of a 5 motor bicore walker
BEAM robotics has become popular because it has demonstrated how to constructed walking robots. This problem was recognized as hard to solve because many degree of freedoms are available. A possible attempt to solve it, is to design first an oscillating walk pattern. This is equal to assign all the motors a value over a time axis.[6]
From an abstract perspective this assignment problem contains of motors from 1 to 5 which have a value over the time from timecode 0 to timecode 100. For example, on timecode 20 the motor M2 can have the value On. On means, that the motor is doing something. Biped walking with many legs is equal to activate the motors in a coordinated fashion. Even if the problem seems hard to understand it will become much easier if a sine wave function is used. A sine function takes a framestep as input and determines the output at this moment. If the sine function is adjusted for each motor a certain pattern can be generated.
The interesting element is how a BEAM robot walker is created from scratch. In most cases the prototype has no servo motors but instead LEDs are used to test the oscillator. The question to answer is, if the correct LED is on at the correct moment in time. If the LED are flashing with the desired pattern, then they are replaced by servo motors which make the robot walk.
Walk pattern generator
Before it makes sense to explain in detail what a sinusoidal Oscillator is, there is a need to give a reason why such tool is needed. In most case the idea is to create a walk pattern generator. That is a software module or a hardware box which is producing the gait pattern for a biped robot. The walk pattern generator defines at which position each leg is, and in which direction the motor has to run at each moment.
The interesting situation is that it is possible to create a walk pattern generator which doesn't work. That means, a sinus function is producing a signal but this signal isn't not optimal. For example the robot can't walk over an obstacle or it will loose the balance. Then, the signal has to be modulated. But in all the cases the problem is located in the walk pattern generator. This focus on a certain subproblem allows to understand how to create such generators. The goal is, that the walk pattern generator fulfills certain needs so it can be asked how to change the parameters.
4 What robotics can learn from BEAM robotics
The most interesting element in BEAM robotics is the nv network for controlling the servo motors. This principle is similar to a central pattern generator realized in analog hardware. Even if more common robots are controlled with micro-controllers it is possible to use such pattern generators in such environment as well. The only difference is that all BEAM robots are controlled by nv networks while not all micro controller robots are based on this principle.
The difference has to do with the programming paradigm. Microcontroller based robots are mostly programmed in one of the larger programming languages like C, C++ or Python. Game programming and microcontroller programming is working with some paradigm which are seldom discussed. In such a paradigm it is difficult or even impossible to generate complex motions. Let me give an example for the famous micromouse robot. Suppose the idea is to control such a robot with python autonomously. Most programs are dividing the tasks in subproblems like “moveforward()” and moveleft()”. And these functions are executed on the program. During the runtime the main program calls one of the routines, this routine is producing a movement and then the next routine is executed. The principle can be summarized as behavior driven robotics. Even it is a bottom up approach in robot control it is working quite different from oscillator based control.
An oscillator or a central pattern generator is some sort of macro. The routine CPG() is executed and in this routine all the movements are generated. The interesting situation is that such a routine works internally with a mathematical equation which is often equal to a sine function. The idea is not that every situation is now for the robot but it is repeating the same actions.
A general description is, that robot programming works with a program flow while central pattern generators are based on fixed pattern which are repeated. It is a bit hard to imagine how pattern oriented control can move a robot towards the goal:
quote: “While CPG approaches have been used extensively to control legged, serpentine and worm like robots, it has not been widely explored in the context of wheeled robots.[7]
CPG
CPG (Central pattern generators) can be realized as oscillators. An oscillator is an analog circuit which has much in common with a timer. The electronics term is “Wave form generator”. That means an oscillator can produce a sine function. This signal is send to an LED which makes them flashing or to a servo motor which moves it back and forth. If the servo motor is built into a robot, the robot will walk forward.[8] The interesting situation is that such a control technique is very different from classical high level computer programming. In a computer program trajectories are usually planned by a solver or they are the result of for loops which are executed. In contrast, a cpg based locomotion is created mostly with sine functions. It needs little or no computational power and at the same time it produces an interesting pattern.
The interesting feature of an oscillator based waveform generator is, that the output signal can be modulated. That means, it can be fine tuned by selecting different parameters. These parameters will make the robot move faster, slower and even left and right movements are possible.Garcia-Saura, Carlos. "Central pattern generators for the control of robotic systems." arXiv preprint arXiv:1509.02417 (2015).
5 Why BEAM Robotics has felt out of fashion
In the late 1990s, BEAM Robotics was some kind of Internet hype. Lots of websites were published which explained to the audience what BEAM is and how to build such robots from scratch. Even dedicated robotics challenges were created in which different bicore walkers were compared how fast they will reach a goal. The hype was only available for around 10 years, and since the mid 2000s BEAM has felt out of fashion.
The reason why is simple to answer. Because BEAM is a bit too much of bottom up robotics. A capacitor and a transistor is not an example for low cost robotics but it is the opposite. Such analog device were common ingredients in the 1950s but today the well known personal computer and modern microcontrollers are low cost electronics components.
BEAM robotics was replaced by lego mindstorms challenges. This single product can be programmed and there is no need to rewire the circuit first. Lego Mindstorms allows more easily to explore what robotics is about. And very important it is possible to create with mindstorms and Arduino based hardware as well more easily a robot which is doing something, for example play soccer or travel in a maze.
BEAM Robotics emphasizes the use of analog devices for creating lifelike robots, while Lego mindstorms has a focus on programming a microcontroller. From a technical perspective, Lego mIndstorms is not bottom up robotics but it goes into the direction of top down. Top down means, that not the robot stands in the focus and his ability to walk over rough terrain but the first step is to formulate a plan which is then programmed on the robot.
Let us take a look into a typical Lego mindstorm project. There are some soccer playing robots which are remote controlled with smartphones, and an intelligent software determines which team has won the match. Such a task is the opposite of what BEAM robotics is about. First thing to mention is, that the robots are not autonomous, they are programmed in Java and AI is hidden in the referee which counts how often the ball hits the goal.
We can say, that analog driven BEAM robotics which has no clear objective is the past, while Lego mindstorms based top down robotics which includes virtual referees and remote control is the future. This description sounds a bid harsh against the BEAM movement. But the idea of bottom up robotics has too many weakness which makes it hard to understand what AI is about.
Let us compare BEAM robotics with a manual controlled Lego Mindstorm bot. Both are very different so it is easy to recognize the difference. In BEAM robotics the assumption is/was, that it is important to understand on a hardware level who electric current is transformed. A BEAM robot consists of an analog circuit and has much in common with a circuit for ann AM radio. There is a battery, some electronic components, which are wired together. Also a strong emphasize is put on the idea that the robot is autonomous. The internal nv network determines what the robot is doing next. So it is an example for artificial life.
in contrast, a remote controlled Lego mindstorms bot hides the internal working from the user. The servo motors are put in a plastic case and the only interface to the outside world is the Java API which gets programmed in the IDE on the laptop. Also, the bot is not autonomous but it is controlled by a script or with a joystick.
6 Sources
- [1] Hasslacher, Brosl, and Mark W. Tilden. "Living machines." Robotics and autonomous systems 15.1-2 (1995): 143-169.
- [2] Mokhtar, Natasha Binti. "BEAM ROBOTIC." (2009).
- [3] Harris, Adam, and James M. Conrad. "Hybrid control of a simple walking autonomous robot." Proceedings of the IEEE SoutheastCon 2010 (SoutheastCon). IEEE, 2010.
- [4] Wu, Dongrui, Woei Wan Tan, and Prahlad Vadakkepat. "A Comparison of Several Hardware-Realized Central Pattern Generators (CPGs)." Department of Electrical and Computer Engineering, National University of Singapore (2005): 1-23.
- [5] Pitchai, Matheshwaran, et al. "CPG driven RBF network control with reinforcement learning for gait optimization of a dung beetle-like robot." International Conference on Artificial Neural Networks. Springer, Cham, 2019.
- [6] Elner, T., S. Fraser, and P. Rimmer. "6 Legged Walking Heat Seeking Robot." (2006)
- [7] Urziceanu, IonuĊ£, et al. "Central pattern generator control of a differential wheeled robot." 15th International Conference on System Theory, Control and Computing. IEEE, 2011.
- [8] Garcia-Saura, Carlos. "Central pattern generators for the control of robotic systems." arXiv preprint arXiv:1509.02417 (2015).