wiki:Plugins/bbsync
Last modified 6 years ago Last modified on 18.06.2012 00:00:10

Synchronize Blackboard Interfaces

Synchronize Blackboard interfaces between multiple Fawkes instances/processes. You can sync the data to instances on the same host or remotely over the network. This allows for creating peer-to-peer exchange between Fawkes nodes. The plugin will monitor the network connection and will automatically try to recover if the connection is lost, for example if using an unstable wifi link. Links between hosts and interfaces are defined allowing for fine-grained control over what is synced to minimize overhead. The plugin will open writing instances if and only if there exists a writing instance for the source interface. This way calls to Interface::has_writer() remain meaningful.

Note that bbsync only needs to be loaded on one side, i.e. if your want to synchronize interfaces between hosts A and B, you need to run bbsync only on either A or B. You can, however, run bbsync on both hosts if you want to synchronize with other hosts, for example. For efficiency it is recommended not to sync one set of interfaces between two hosts A and B with bbsync running on host B, and a separate set with a bbsync loaded on host B. This would require two network connections instead of only one and reduces the efficiency, particularly on croweded wifi networks.

Interface names can also be remapped to other names on the remote side. This is useful, for instance, if syncing the same data instance, produced by separate instances. For example two robots may detect an object like a ball and want to share this information with each other. Since it is the same component on both hosts, it is written to the same interface ID and there would be a conflict if both wrote to the same ID. With bbsync remapping data from one host is written to a different ID on the other host resolving this conflict.

Requires

BlackBoard Interfaces

No particular interface is required, but all that exist can be synced.

Config Values

Multiple peers can be configured. For each peer the host and port must be defined, as well as interfaces to sync. Each peer can be enabled/disabled separately, therefore allowing to disable specific connections without removing the whole configuration.

PathTypeDescriptionDefaultR
/fawkes/bbsync/check_intervalunsigned intTime interval in miliseconds in which to check for aliveness and try to recover the connection if necessary.5000*
/fawkes/bbsync/<PEER>/activeboolEnable or disable synchronization with this peertrue*
/fawkes/bbsync/<PEER>/hoststringHostname of the synchronization peer.-*
/fawkes/bbsync/<PEER>/portunsigned intport of the synchronization peer.1911
/fawkes/bbsync/<PEER>/check_intervalunsigned intOverride for /fawkes/bbsync/check_interval for specific peer
/fawkes/bbsync/<PEER>/reading/<COMBO>stringReading interface combination, see below.*
/fawkes/bbsync/<PEER>/writing/<COMBO>stringWriting interface combination, see below.*

Synchronization Combos

A combo is defined by a unique name, and an interface to read from or write to, possibly with a remapping. The unique name is simply like a variable name, and described as <COMBO> in the configuration path.

The reading and writing of a synchronized interface is defined with respect to the remote host. A "reading" config entry will open the interface for reading on the remote host, and write locally. Similarly, a "writing" entry will cause the interface to be opened for writing remotely, and reading locally. So every combo has a reading and a writing end, the reading/writing path substring defines if the reading or writing end is at the remote. The writer is opened if and only if the reading end determines a writer for the particular interface.

In the simple form without remapping, the config value is a unique ID of an interface like ObjectPositionInterface::Ball. if remapping is to be performed, the entry has the form "FROM_UID=TO_ID", e.g. "ObjectPositionInterface::Ball=BallExtra". The entry is read as "read from FROM_UID and write to TO_ID (same type)". In our example we would read from ObjectPositionInterface::Ball (if that is local or remote cf. above for the reading/writing sub-path) and write to ObjectPositionInterface::BallExtra (again, local or remote is defined by the reading/writing sub-path).

Provides

BlackBoard Interfaces

Determined by the configuration.

Usage Instructions

Start by create a peer configuration. Setup at least one interface combination. For example:

ffconfig set /fawkes/bbsync/peers/myrobot/host myrobot.local string
ffconfig set /fawkes/bbsync/peers/myrobot/port 1910 "unsigned int"
ffconfig set /fawkes/bbsync/peers/myrobot/active true bool
ffconfig set /fawkes/bbsync/peers/myrobot/writing/test "TestInterface::Test"

replace myrobot.local with the remote hostname, and the interface with the one you want to sync. Then load the bbsync plugin on the host where you created the configuration entries. It will immediately establish the connection. Loading the plugin will fail if the connection cannot be established initially. If the connection dies later this is recognized and the plugin will try to reestablish the connection.

You can run multiple Fawkes instances on the same host by changing the Fawkes network port (/fawkes/mainapp/net/tcp_port config entry).