Operation DB-AI


I think we need a Relational DB in order to offer a full suite of manipulation facilities for the outputted parameters & objective functions. This pretty much means going with PostgresSQL.

http://wiki.ros.org/database_interface – Here is an older package that incorporated a PostgresSQL DB into ROS.

  • Exceptions
  • SMACC Events
  • AI Reactor Events
  • ROS Messages

Controller Manager Concept – (from ros_control)


  • Provides a structured On/Off functionality
  • Simplifies Testing

Central Question

The central question, is whether A. There is one state machine that runs on a robot at one time OR if B. there is just one state machine for the robot ever.

If we go with A., then State Machines become more mission focused, which is interesting. I’m imagining 3-4 SM’s/robot.

Benefits could be…

  • More complex behavior possible by division of SMs (Think Code & Viewer)
  • Better performance (faster) due to less state nesting (State Construction/Destruction)

AI Loop

AI on deployed robots needs to be thought of as a circuit. Where the robot records events (events, exceptions, logs, etc.), writes that data somewhere (an RDB), then operations are performed with the new data, which is then reloaded by the robot (via parameters, modified objective functions, etc.) that modify the behavior of the robot.

AI-Reactor Library

Create new folder AI Behaviors, for a state machine level version of state reactors….

First implementation (in AI Behavior library) would be a counter, that counts the number of times some certain event happens, over the running of a state machine, then records that to some type of logfile.

The Case of AlphaStar – StarCraft2