Nicht mathematische Robotik

 Auf den ersten Blick klingt die Vorstellung absurd, künstliche Intelligenz ohne Mathematik zu realisieren. Mathematik gilt als Grundlagendisziplin welche wissenschaft überhaupt erst ermöglicht, ohne Statistik, Zahlen und Formeln könnte man keine Computer bauen oder die Biologie erforschen. Freiwillig auf Mathematik als Werkzeug zu verzichten bei der Erforschung denkender Maschinen scheint wie eine Sackgasse zu sein.

Von außen betrachtet besitzt Mathematik eine Reihe von Limitierungen die in der Vergangenheit unberücksichtigt blieben. Der Fokus auf Zahlen blendet eine zahlenmäßige Beschreibung der Welt aus, und der Fokus auf berechnungen blendet eine assoziative Sichtweise aus. Ein weiteres viel größeres Problem liegt darin begründet, dass Computer sehr schnelle Taschenrechner sind, also außerhalb der Mathematik nichts zu leisten im STande sind. Eine CPU ist vorwiegend ein mathematisches Instrument was zahlen addiert, subtrahiert und multipliziert gerne mit vielen Nackommastellen aber anstonsten nichts kann.

Wenn man auf Mathematik zur Beschreibung von Robotik verzichtet muss man ein besseres Hilfsmittel benennen können was dessen Rolle einnimmt. Dieses Hilfsmittel ist die Kommunikation zweier Systeme. Dies wird nicht von der Mathematik beschrieben sondern ist im Bereich Kybernetik und Kommunikation angesiedelt. Es geht im Kern darum eine Nachricht vom Sender zum Empfänger zu übertragen und sicherzustellen dass die Nachricht verstanden wird. Dieses Prinzip ist mächtig genug um als Ersatz für Mathematik zu dienen. Es lassen über das Paradigma "Kommunikation zwischen zwei systeme" Roboter bauen.

Im einfachsten Fall gibt es einen Roboter der von einer Umwelt umgeben ist. Die Frage ist weniger ob der Roboter intelligent ist sondern die Frage ist ob der Roboter auf die Umwelt reagiert. Die Wichtigkeit der Umwelt wurde erstmals von Rodney Brooks im Jahr 1990 beschrieben.  Zwar hat Brooks nicht ausgeführt wie genau der Roboter auf die Umwelt reagiert, sondern er hat lediglich die Notwendigkeit betont. Allein das war aber bereits ein Paradigmenwechsel zur Robotik wie sie davor erforscht wurde. Vor dem Jahr 1990 war Robotik stark auf das interne Funktionieren der Hardware und der Software orientiertiert, also wie ein Roboter mechanisch aufgebaut ist, und welche Programmiersprache verwendet wurde um ihn zu steuern.

Die interaktion zwischen einem Roboter mit seiner Umwelt erfolgt über Abstraktion. Genauer gesagt erfolgt eine Übersetzung zwischen zwei Systemen. Diese übersetzung ist erforderlich weil die umgebung eines Roboters anders funktioniert als der Roboter selber. Ein Beispiel:

- Roboter: besteht aus 2 rädern, wird mit 12 Volt betrieben, besitzt einen 32 bit microcontroller
- Umgebung: ist ein Labyrinth aus Pappe, hat einen Eingang und ein Ziel

Beide Systeme sind inkompatibel zueinder. Der Roboter ist ein mechatronisches Artefakt, während die Umgebung keine Elektronik besitzt sondern ein UNterhaltungsspiel darstellt

Künstliche Intelligenz ist das interface zwischen beiden Systemen, also jenes Modul was die Logik des Roboters in die Logik der Umgebung übersetzt. Sobald beide Systeme mit einander kommunizieren erscheint der Robotik intelligent. Er agiert in dem Labyrinth sinnvoll und findet den Weg zum Ziel.

AI as open system

 The last AI winter during the early 1990s was caused by the ignorance towards open systems namely Teleoperation for robot control. What the AI researchers have prefered instead were autonomous algorithm controlled AI systems. The goal was to program a large scale software similar to an operating system or a word processing software and make the software higly intelligent. Such bloat AI projects have failed, even a program written in 200k lines of code in C/C++ code isn't able to control a toy car in an obstacle course.

The reason why closed system failed is because existing programming languages like C/C++ can't grasp reality outside of a robot, existing algorithms like RRT pathplanning are too slow for realtime planning and the possible amount of trajectories for a robot in the reality is too large. This mixtures of challenges prevents that robot projects in the 1990s have become succesful. The written sourcecode was useless and the project doesn't make any sense.

The term AI winter is referencing to a situation in which the problems are known but no answer is available. This answer is maybe the transition from closed systems towards open systems. Open systems in robotics are equal to teleoperation which means that the human operator controls the robot. So its not longer an algorithm controlled robot but its an RC car. The main advantage is that such an open system can be realized easier with existing technology. The needed software is minimal and no true Artificial Intelligence is required.

What is used instead for remote controlled robots is a sender/receiver device which is an interface between human and machine. Such a device has multiple tasks:
1. it receives radio waves over the air
2. it parses natural language commands
3. it receives sensor signals
4. it transmits radio waves to the remove control
5. it transmits natural language status information to the human operator

In one word, the transceiver connects the robot with the environment.



The picture on the left shows the older paradigm. A robot in enclosed by a box and forms a closed system. The robot's AI is a turing machine executed on the CPU and the goal is to invent a sophisticated algorithm which makes the robot intelligent.

The picture on the right shows the modern paradigm which assumes two different systems connected by a sender/receiver. THese two systems are the robot and the environment around the robot. Both systems need to communicate. Communication doesn't require an autonomous algorithm but a protocol.

The transition from older closed systems into modern open systems is equal to discard algorithm oriented AI in favor of a communication perspective.

A review of bottom up robotics

In the late 1980s there was a fundamental paradigm shift available in the domain of Artificial Intelligence, called bottum up robotics or subsumption architecture. It wasn't a new algorithm but at first it was a criticism of AI in the past. Bottom up robotics is mostly the description that program controlled top down robotics until the year 1990 has failed. Instead Brooks recommended to build simple sensor driven robots in the style of William Walter's turtle robot in the 1940s.

In a single sentence, Brooks argued, that its unclear how to program robots and instead of trying it harder, the answer is to give up and build instead Analog beam robots with a single sensor and a single motor. Of course, such a robot doesn't make sense because the goal is to build high complex machines which can do practical tasks and not to build a light following bug which can't do anything.

Despite of this step backward, bottom up robotics had become a great success. Many other researchers have agreed to Brooks, and similar architectures like Tilden's BEAM robots were popular.

Let us describe bottom up robotics from a birds eye perspective. These robots or artificial bugs are mostly controlled by its environment and by a random generator but not by an internal program. This paradigm shift was the real novelty of Brooks. It introduced a concept in which the former program oriented approach in robotics was dismissed in favor of external control.

Brooks identified correctly what sort of technology can't be realized. Its not possible to program a robot similar to a computer program. It doesn't make sense to write a C program and compile it for a microcontroller which is doing something with a robot because such a C program will provide a reality gap to the environment. A high complex task will require a high complex computer program and nobody knows who to write down the source code.

Let me give an example. Before the advent of bottom up robotics, the shared assumption in artificial intelligence was, that a robot who should grasp an objects needs to be programmed first. There are 5000 lines of code which are planning the grasping, solving the mathematical equation to determine the trajectory of the gripper and monitor if the robot is successful. Its impossible to write and improve such a C program.

AI after the year 2010

There was a paradigm shift available how AI researchers have discussed about the shared goal of building intelligent robots. Until the year 2010 the untold assumption was to program a closed system. The robot was seen as a machinery which consists of software, hardware and algorithm and the goal was to optimize this machinery. For example to create more advanced grippers or improve a path planning algorithm. It was assumed that this was the only way to think about robotics, because the goal was to build autonomous self sufficient systems which was seen as equal to artificial intelligence.

After the year 2010 there was a different approach available which has started with bottom up robotics invented by Rodney Brooks and has evolved into modern Vision language action models, see the right figure. The idea is to use teleoperation between a robot and an external instance which can be a computer program, a human or a large language model. Such kind of distributed AI generates a new problem. Instead of discussing how a robot is working internally, for example with an algorithm, the new question is how to design the ocmmunication between the robot and the external instance.

This simple modification has created a very different bias in Artificial intelligence. Former autonomous and closed systems are rejected in favor of a natural language communication preference. An early example for open systems in robotics was the Shrdlu project, later more complex attempts were the Poeticon++ dataset and the Rocco Robocup commentator. These early attempts were not using advanced LLMs but they have anticipated a speaker to hearer communication pipeline.

Classical AI until the year 2010 was limited by the np hard challenge. A certain motion planning algorithm needs a large amount of CPU resources. Planning the steps for a complex robot task e.g. biped walking and grasping objects was beyond the capabilities of computer hardware. Even with highly optimized programming language and advanced model predictive control algorithms, this np hard bottleneck can't be solved.

In recent AI after the year 2010 the np hard problem can be ignored because there is no need for motion planning algorithms anymore. The robot gets its instruction from an external instance. And this external instance can generate a trajectory much easier than the robot itself. What is available instead is the problem how to program a text parser. If the external instance gives the command "move to left corner in the maze" this command needs to be translated into action by the robot. For doing so, a dedicated parser is needed which can be implemented as context free grammar, as large language model or a handcoded computer program. This parser is the new limitation in robotics.

BEAM robotics as central pattern generator

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).