Behavioral Logic

Fetchbot Software

Behavioral Logic Architecture is a very high level and theoretical specification of how an intelligent system might work. Fetchbot is a working implementation of that. Visit the public GitHub to get a copy of the software so far (it is a long way from completed.) While writing, I have discovered some useful specifics about file and folder structure and tool integration. I would like to document the major ones in the article.

Folder and Main File Structure

My first implementation is in Node.js so my files will have the .js extension, but a similar structure should be applicable for most programming languages.

πŸ“ action
πŸ“ behavior
πŸ“ sense
   Actions.js
   Behaviors.js
   brain.js
   Senses.js

The main file is called brain. Many applications would name it main but this is behavioral logic so it's special. Executing this script initializes and connects the main modules: Actions, Behaviors, and Senses, plus integrate with any programming tools you are going to use. (I am capitalizing some files because they contain objects with constructors as is the convention in JavaScript. Use appropriate capitalization for your chosen platform.) Sub-components and other digital assets for each of those modules should be kept in their respective folders.

This is a simple application structure that reflects the behavioral logic architecture, but it is not easy to work with. In the spec document I rigidly declared how different modules are allowed to communicate and affect each other. And as much as I still believe that is correct, it makes the software too locked down to connect valuable programming tools into. Designing complex behavior is hard so we should take advantage of whatever utilities we can that make the job easier.

Development Tool: Viewer

A key behavior programming tool is a UI for visualizing senses, behaviors, and actions in real time. My current version can add, edit, and remove behaviors, update tunables (on the fly) and take manual control of all actions.

This is an extremely valuable tool, but it is also a powerful vulnerability. If a robot integrated with a tool like this was in the wild and an attacker gained access to it, he would have total control. I am not sure what good solutions are to this problem, but I am at least aware of it and that's a start.

Development Tool: Games

The ability run a brain in a simulated environment is the second essential tool. Even simple simulations grant the ability to hone sensor perceptions and check that your latest code changes did not break the entire system. In our world, young creatures that need to learn good habits play games: practicing in an artificial environment that mimic challenges they may need to handle in the future in a safe and repeatable fashion. When our robot runs in in game mode, all actions and senses completely disconnect from all hardware. This gives programmers the ability to work on behaviors, even if they are not yet able to get that infernal robot assembled and working. Thorough tests should be written to to be run while in game mode. Though even complex game environments are no guarantee your behaviors will work in the real world, it is best to do as much as you can in a faster and easier game environment before deploying to a robot and setting it loose on the world.

Full File Structure

This is very close to the file and folder structure of my current implementation after adding the viewer and game tools, plus any files and folders specific to the platform. (In Node.js, this includes npm components such as a node_modules directory for external libraries and a package.json file for dependency management configuration.)

πŸ“ action
πŸ“ behavior
πŸ“ games
πŸ“ node_modules
πŸ“ sense
πŸ“ viewer
   Actions.js
   Behaviors.js
   brain.js
   Games.js
   Senses.js
   package.json
   Viewer.js
The computing scientist’s main challenge is not to get confused by the complexities of his own making.

β€” E. W. Dijkstra

Managing complexities is even more relevant to AI because a human-level intelligent program will be one of the most complicated applications ever developed. We won't be able to accomplish this without vigilantly maintaining a clear and organized structure.

In-Module Structures

Let's a take look at the finer structure inside the main folders and code files.

brain

The brain executable should have as little logic as possible and only initialize and connect the Actions, Senses, Behaviors, and development tools. A key responsibility of the brain script is to determine if the main modules should be running in game or real-world mode. Typically it parses a command-line flag to initialize execution in the proper mode.

Senses

My implementation of the Senses module is very close the the spec structure. It initializes observers (for raw sensory input) perceivers (for processing raw sensor data) and detectors for pattern recognition. It also has extra code to send data to the view tool. Lastly, it starts the attention loop. The senses directory has code files for gathering visual and temporal sensory input.