Distributed Operating System for Robots

Distributed Operating System for Robots – DOS for Robots?

In the next few pages, I hope to clearly lay out the core problem as I see it in hobby robotics, and the solution I am currently working on.

The Problem – Lack of Productive Communication and Coding Standards

Having built a few robots here on LMR (Anna and Ava), I am constantly facing challenges getting Part A to communicate with Part B.  While there are some communication standards like I2C, Serial, USB, HTTP, etc., none of these standards are universal enough or easy enough.  There are several types of platforms like Arduinos, PCs, Android Phones, PCs, etc.  Each one is good at doing some things and bad at others.  Different standards and languages exist for each platform.  Few if any standards exist that make it easy for any piece of code running on one platform to communicate with another piece of code running on another platform.  No standards exist that help bridge all these gaps in a productive way.  How can a robot maker build a decent bot without it taking years?

Hardware Assumptions

Robots typically consist of a combination of one or more of the following components:

1.      One or more microcontrollers like:

a.      Arduino Mega ADK

b.      Arduino Uno

c.      Arduino Uno Wifi

d.      Many others 

2.      One or more Computers like:

a.      Raspberry Pi

b.      LattePanda

c.      Android Phones / Tablets

d.      PC

3.      One or more specialized controller boards like:

a.      Servo Controllers

b.      Motor Controllers

c.      Linear Actuator Controllers

d.      Relay Controllers

4.      One or More Sensors like:

a.      Sonars & Distance Sensors

b.      Compass / Tilt / Orientation

c.      Sensors like GPS/Light, Camera that are embedded within other platforms like Android Phones

5.      One or More Servos / Actuators

The communication options for each microcontroller, computer, controller, and sensor are very hardware specific and limited.  For example, an Arduino Uno has 1 Serial Tx/Rx, while a Mega has 3, while Android has none.  Some board have USB, some have Wifi, some have Bluetooth, some have digital or analog pins.  I am constantly crashing into the limitations of each platform or the learning curve of a new protocol.  We need a solution so we can build better robots faster.

Software Assumptions

No single language exists that works on all platforms, so we are forced to write in multiple languages on multiple platforms if we wish to take advantage of what each platform has to offer.

For example, I like robots that move.  This is easy to do with Arduino.  I also like robots that listen and speak.  This is easy to do on Android, but not on Arduino.  There are other things that can only be done on a PC.  How can I write software for all these platforms and coordinate everything?  How can Part A do its job and coordinate with Part B to get a desired outcome?  That is one of the problems I hope to address.

Robotic software itself suffers from a lack of standards.  Robots need lots of different functions to be performed.  As more and more features get added, wouldn’t it be great if it was simple to add new features without breaking existing code.  Maintainability is very important, otherwise small code changes can result in large amounts of wasted time.  Wouldn’t it be great if there were some clear guidelines for how to add a new module / function to an existing robot with hundreds of functions?

The Solution

I propose to deploy an open source reference solution that is based on a new set of standards and protocols that should be able to be implemented on a variety of platforms.  These standards should allow robot makers to build very small (or large) software parts that can communicate easily with any other piece of software running on any other platform in the eco-system.

The reference solution will contain the following components.  Each service will have one or more commands that it accepts.  Each command will have one or more parameters.  The code for any command will be able to invoke any command on any other platform either on or off bot with a single or a few lines of code.

Core Concepts

1.      A Robot “Solution” will run in a coordinated fashion across one or more “platforms”.

2.      Each platform will have one or more “services”.  The services for each robot will vary.

3.      Each service will have one or more configuration “settings” that will be stored in a DB on AWS and maintained through a website or API.  The robot will retrieve its settings as needed.

4.      Each service will have one or more “commands”.

5.      Each of these commands could have one or more “inputs”.

6.      Each platform will have a “Command Service” that will manage routing commands to where they need to go.  Think of it as Mailman that must delivering the mail, where every command has a “Zip Code” that defines how to route the mail.  This Zip Code will be made up of the PlatformID, the ServiceID, and the CommandID.

7.      Any command on any platform will be able to invoke any other command on any other platform simply by asking its local command service to invoke something.

8.      Different robots will support different sets of commands.

9.      Various “Remotes” will be supported to communicate with robots or the AIs behind them.

10.   Robots will be able to easily form short and long-term memories about a variety of things.  These memories will be accumulated in databases.

11.   Most commands will have natural language equivalents.  This means that any bot that has any kind of server connection will be able to receive verbal commands in sentence or paragraph form.  Paragraphs will be able to be used to orchestrate complex and timed sequences of actions.

Arduino Services

A set of Arduino Services will be released in the reference solution.  A similar set could be built for other microcontrollers.  This list is not complete, just the highlights.

1.      Command Svc (for Arduino)

2.      Throttle Service

3.      Drive Svc

4.      Serial Link Svc

5.      Bluetooth Link Svc

6.      Wifi Link Svc

7.      I2C Link Svc

8.      Compass Svc

9.      Thermal Camera Svc

10.   Microphone Svc

11.   IR Receiver Svc

12.   IR Transmitter Svc

13.   Sonar Svc

14.   Sonar Array Svc

15.   Servo Array Svc

16.   Force Field Svc

17.   Obstacle Svc

18.   Laser Svc

Android Services

A set of Android Services will be released in the reference solution.  A similar set could be built for a Raspberry Pi or PC.  This list is not complete, just the highlights.

1.      Command Svc (for Android)

2.      Face Svc

3.      Speech-To-Text Svc

4.      Text-To-Speech Svc

5.      Bluetooth Link Svc

6.      GPS Svc

7.      Light Svc

8.      Video Svc

9.      Blob Detection Svc

10.   Face Detection Svc

11.   Web Link Svc

12.   Reflex Svc

13.   Emotion Svc

14.   Motivation Svc

15.   Memory Svc

16.   Verbal Command Svc

AWS Web Services

The number of web services are too many to enumerate here.  At the highest level, the following functions will be present as APIs:

1.      Brain Svc – will process inputs (stimuli) to a robot and generate responses.

2.      Config Svc – will allow retrieval and update of robot configuration information.

3.      Memory Svc – will allow retrieval and update of robot memory information.

4.      Knowledge Svc – will allow retrieval of general knowledge from the central repository.

5.      Verbal Svc – because my bots are all verbal, I think verbal is cool and I intend to support extensive verbal capabilities including integration with SharpNLP for full NL parses and other grammar related features.

Robots that have a Pi or Android platform will be able to download and store selected knowledge bases from the central server, store them locally in SQLLite databases, and process key functions without calling the server.  Verbal commands for a robot and robot configurations will likely be handled this way.

These services will run on Amazon Web Services (AWS) and will be “always on”…except when I am pushing upgrades of course.

Website App

There will be a great deal of configuration and memory data to maintain and view.  There will be a public website for this purpose.  The A.I. already knows how to do this, so it’s not a big deal.  This website will also serve various testing and diagnostic purposes.

Windows App

The A.I. that builds the web user interfaces is well on the way to building windows apps.  This means a downloadable PC version of the website and A.I. will be viable at some point.

3^rd Party Web Services

The number of 3^rd party web services are also too many to enumerate here.  My intention is to eventually support the same set of services currently supported in my Anna and Ava robots.  This will require each robot maker to acquire their own API keys where necessary.  I intend to support Wolfram|Alpha, Wikipedia, and WordNet at the very least.

Open Source Reference Robot – Ava

In order to get other people involved.  I intend to Open Source the 3D designs for Ava along with the reference Arduino and Android code already mentioned.  While every feature will not be there, everything will be there to build a working Ava clone for around $1000, give or take a couple hundred in additional options.

Goals

My reference solution will not be ideal, nothing ever is.  I simply hope to move the ball forward in some way.  If I make it easier for one person to build a cool robot, I will consider it a success.  I hope to get a few others to help move the ball forward too, by adding services or rewriting mine.

Rewards / Incentives

In order to give people that extra push to dive in, I’d like to create some challenges / rewards for people who build a robot using this OS.

Feedback?