A little more detail on what the Robby Framework has to offer.
Robotic Device Communities
With Robby, it’s simple for robots and robotic devices to communicate and collaborate.
You’ll build communities of robotic devices working together on a peer-to-peer basis,
able to share resources and to provide multi-leveled command and control for all the
devices in the community.
Disparate devices can easily be shared and controlled by any member(s) of the community
you choose. Robby provides the “connective tissue” that allows all devices in the group
to communicate with one another on a level playing field, in the same language. Whether
it’s a central computer orchestrating the behaviors of a group of robots or independent
robots collaborating with each other to jointly accomplish tasks, Robby makes it simple.
Our “freeform networks of networks” allows for amorphous groups of robotic or IoT devices
that can connect and communicate in pretty much any fashion you can imagine.
The holy grail of any robotics control software is the ability to use and optionally,
record the output of multiple sensing devices simultaneously. The Robby Framework’s
powerful device connector system makes sensor fusion virtually free. Each device connected
to your robot can operate on its own “worker thread” completely independent of other
devices and services used by the robot.
Sensor fusion can easily be tested and proved using the “Temporal Data Storage Engine”
included with the Robby Framework. This simple, but fast and powerful data storage
system records the output of sensors with a time resolution of 0.0000001/Second
(one ten-millionth of a second), or roughly equivalent to one “tick” of the
The Robby Framework’s user interface includes the “Temporal Data Storage Manager”
feature which allows for managing the data contained in the system’s repository as
well as the ability to view data from multiple devices for a given time-slice, side
by side. This makes it easy to understand if sensors are operating freely and
independently as expected and necessary. The time-slice viewer will also show if
sensors are interfering with each other in any way which may be otherwise difficult
or virtually impossible to detect.
At its core, the Robby Framework is a relatively simple messaging system for passing communication
between a “Master Control Program” or “MCP” running on a Windows 10+ device and external devices or
services to which it is connected. The MCP device can be any Windows 10+ platform ranging from a simple,
one card computer such as a “Latte” board to a tablet device or ultimately to a
remote PC using peer-to-peer communication.
All this communication is in the form of formatted JSON strings. Message Schemas allow you to control
the content of those JSON messages. The framework’s user interface includes a “Message Schema Builder”
dialog which makes it simple and fast to create detailed schemas for all messages to be passed through
your project’s “network”.
Messages are validated against schemas any time they are passed through a connector or channel.
This ensures that all messages received by the MCP or connected devices will be in the
proper form necessary for successful data communication.
First, a quick word about the name, "Master Control Program". For the benefit of non-80's sci-fi movie fans,
in addition to "Master Control Program" being a truly appropriate name for the intention behind this component
of the framework, we must confess the name is also a shameless homage to the original "TRON" movie from 1982.
In it the main villain was the evil "Master Control Program", lovingly called "the MCP"
by its bad guy, human programmer.
As the name implies, the intention of the MCP is to (to one degree or another) orchestrate everything
its connected devices do. It communicates with its devices through a "Network" of "Channels". Each
instance of an MCP is associated at runtime with an instance of a single network. The network
manages a collection of channels. Each channel manages collections of "Connectors" which connect
the channel to external devices and services.
Another key point to understand about the MCP is that it’s the "touchpoint" between the Robby Framework and
programs you build that utilize it. The framework is exposed to programmers as a standard, .Net Framework
(version >= v4.6.1) class library (DLL) named MasterControlProgramLib. The library exposes an abstract
base class named “MasterControlProgramBase".
This base class exposes a network's channels to derived MCP classes in the form of thread-safe
collections of event handlers and invokers. This brings all the functionality of the framework
into your C# project simply and quickly.
Connectors are polymorphic plugin components used by the Robby Framework to
connect your “Master Control Program” to external devices and services via network
channels. Among other benefits, polymorphism ensures all connectors interact with
channels (and thus, your MCP) in exactly the same manner.
The initial release of the framework will include connectors which implement
TCP/IP over Ethernet, HTTP and Serial Communication in addition to more specialized
connectors including one to collect data from popular RP Lidar sensors as well as
speech recognition and voice connectors which provide a simple means to add speech
recognition and text-to-speech capabilities to your robotics projects.
The beta release of the framework will also include a connector for accessing Microsoft’s
“Azure AI” service supporting object and facial recognition from your robot.
Connectors for other popular cloud AI services are also currently under development.
In addition to data connectors, the framework will also include a “WPF” control
library providing user interface support for the popular Intel D4XX series of depth
cameras as well as generic Lidar 2D point cloud rendering. Support for the
Microsoft Kinect depth camera is also currently under development.
These controls are open-source components you can drop into your MCP project
if it supports a WPF user interface. Controls for other data visualization
capabilities and supporting other user interface languages and types are either
under active development or included on our “product roadmap”.
The possibilities for future data connectors and UI gadgets and controls are virtually endless.
Channels manage all message communication between an MCP and the devices to which it’s connected.
Channels are made up of three types of components, "Connectors", "Message Schemas" and "Gadget Connectors".
All messages are passed as JSON strings. Each channel includes two “Message Schemas” used
to validate the model structure of messages passed through it. One schema is used to validate
messages moving from the MCP to connected devices and the other to validate messages passing
from devices, back to the MCP.
Connectors create a bridge between external devices or services and channels. The beta
version of the framework will include 8 protocol, device or service specific connectors
ranging from simple serial and TCP/IP connectors to one for collecting data from popular
RP Lidar sensors and another for connecting to Azure AI services (use of this connector
requires appropriate Microsoft Azure subscription). Several other connectors are currently
under development or on our product roadmap.
Gadget Connectors support viewing channel communication using the powerful, multi-threaded
“Testing Console” dialog included in the framework’s user interface. Any gadget connector
“dropped” onto a channel at design time will automatically be displayed in the testing
console if the framework UI is connected to a network which includes the channel.
Each gadget will display raw JSON data received from the connector for which it’s configured
to monitor on the Testing Console dialog.