Componentization & distributed software architecture

HBot grows, and use cases get more complex. It thus becomes necessary to introduce mechanisms to support a distributed architecture, in the sense: multiple machines control different parts of the robot or the AI, and communicate together.

HBot is already components-based, to a large extent. In a first phase, it would be doable to separate it into 2 components, as shown on the following picture. One component controls the robot hardware, the other component takes care of mapping, directions, and interfacing with a remote controller.

Extending signals&slots

As HBot is already based on a signal/slot mechanism, classes are not tightly coupled. Although, very large changes will be necessary in the infrastructure to support remote calls through signal/slots. The same system would ideally be used for the legacy usage of signal/slots (i.e. within the same thread), and for remote procedure calls. More than that, this change could be the opportunity to introduce C++/Lua communication, by generically convert signals (with their payloads) from C++ to Lua, and from Lua to C++ (this more ambitious goal may have to wait a little…).

Another item is multi-threaded environment on the same machine. Signal/slots could cross a thread boundary, in the fashion of Qt signal/slots. This means that each thread is actually built around an event loop, and sending a signal from one thread to the other means posting a message to the other thread's event loop. The ideal behavior of signal/slots is illustrated in the following diagrams:

Technical studies

Here is a step-by-step plan to get to a distributed architecture:

  • Introduce an event loop, integrate all the timers and I/O events [done]
  • Change the signal/slot mechanism from a generic void* type of payload to a templated payload [done]
  • Get all hbot to run on a unique event loop for player/stage [done]
  • Make signal/slots capable of posting events to another eventloop/thread
  • Split hbot in two eventloops/threads (as in the top diagram)
  • Implement a system to marshall/unmarshall event payloads (if possible with a code generator)
  • Introduce an RPC mechanism for signal/slots
  • Split hbot in two processes communicating locally via RPC
  • Introduce a discovery mechanism for hbots to automatically discover and connect themselves
  • Split hbot on two machines discovering each other and communicating remotely via RPC
  • Try this with a real robot
  • Re-use the marshalling/unmarshalling code generator, get it to generate C++ to Lua (and back) translation code
  • Write some lua signal/slots
  • Rewrite a GUI using RPCs

Event loop could be done using libevent or Boost Asio. In the end, Boost Asio has been chosen. Code generation for marshalling/unmarshalling could be Google's Protocol Buffers.

Status of the signals/slots in HBot

new_architecture.txt · Last modified: 2013/02/17 09:34 by hadrien
Recent changes RSS feed Creative Commons License Donate Powered by PHP Valid XHTML 1.0 Valid CSS La rache Driven by DokuWiki