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 computer’s processor.
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.
