RobuBOX White Paper

robuBOX software architecture

Robosoft’s robots are powered by the RobuBOX, a three-layer software architecture that benefits from state of the art technologies:

• robuBOX PURE is built on the windows CE real time operating system and is in charge of the low level control tasks ( feedback control loops + state machines).

• robuBOX SERVICES is an “extended robotic engine” built upon the Microsoft Robotic Developer Studio middleware (MRDS) that targets demanding service robots, where robustness of algorithms and quality of motion control are required. It comes with a large set of libraries, services and tools that extends/replace MRDS ones.

• robuBOX LOKARRIA is a suite of software services that provides remote access to robots over the Internet. It is also a web interface for managing robots: remote control with video and sensor feedback, monitoring (logs and alerts), updating robot software.

Note : LOKKARIA and ROBUBOX SERVICES come with a full REST API that exposes all the provided services to external clients using the HTTP protocol: i.e. a client on a mobile phone, a dedicated desktop application or a web application running on a tactile device, could be developed by robosoft’s customers. This is a common web 2.0 feature. Google’s or Youtube’s services all come with a REST API, making possible iphone clients, for example.

Introduction 

The robuBOX Services software layer is an “extended robotic engine” that targets demanding service robots, where robustness of algorithms and quality of motion control are required. These robots have computing power on-board, and sophisticated sensors allowing implementation of the most advanced robotic algorithms such as the ones in the robuBOX Services components. The robuBOX Services are suited to professional robots application development today, and next generation of domestic robots.  

Some other robotic engines are available on the market, however, robuBOX Services’ design is “modern” and extensible: it is based on an architecture of web services (with REST api and web interfaces) and are designed as a series of loosely connected middleware components that can be selectively combined to create a custom engine, instead of the more common approach of extending or customizing a flexible integrated solution.  

Extensibility remains a high priority in robotic engines due to the wide variety of uses for which they are going to be applied (in particular by robot integrator that will have to “tweak” and adapt the engine to their particular needs). Despite the specificity of the name, robotic engines may be also used for other kinds of interactive applications with real-time graphical requirements that do not always involve a “real robot”. robuBOX Services for example, come with several 3D simulators that can be used for marketing demos, architectural visualizations, training simulations, modelling environments, education, etc. 

Some robotic engines only provide a few core capabilities instead of the wide range of functionality required by robotic applications. Modern robotic engines are very complex applications, frequently featuring dozens of finely tuned systems interacting to ensure a finely controlled experience. The continued refinement of robotic engines such as the robuBOX has created a strong separation between real time control, scripting, sensing, simulating, etc. It is now common for example, for a typical robotic application development team to have several programmers dedicated to particular roles: specialist of robotic simulation, expert in navigation control, etc. 

Like other middleware solutions, the robuBOX provides platform abstraction, allowing the same application to be run on various platforms with few, if any, changes made to the application source code (robuBOX powers all the brand of robuBOX robots). robuBOX Services are also called "robotic middleware" because, as with the business meaning of the term, it comes with a flexible and reusable software platform which provides all the core functionality needed, right out of the box, to develop a robotic application while reducing costs, complexities, and time-to-market—all critical factors in the highly competitive robotic industry. 

A set of C# services 

robuBOX services address sensor data processing, cartography (see Figure 2), path planning, robotic arms, specific data types, high quality GUIs + dedicated widget set, etc. Most services come with web interfaces for debugging, targets demanding services robots, provides platform abstraction, etc.

The services can be combined together, complete applications are provided (with sources and detailed explanations) like: autonomous navigation or a highly configurable Dashboard.

Figure 2: the DSLAM service from robuBOX running together with the WebCam and LaservView services.

Tutorial and C# samples

The robubBox services come with a set of tutorials/samples that show how to perform motion control, how to compose services and use feedback from sensors, etc. and furthermore, all services are open source!

Tools and utilities

Some tools and utility services are included, like logging and debugging services, tools for calibrating sensors, a library for integrating the LUA scripting langage, a LUA powerful embeddable Integrated Development Environment, etc.

Graphical User Interfaces components

Many services are associated with a set of GUI widgets for visualization, robot control, etc, that can be reused in custom applications or in the Dashboard GUI. See Figure 3.

A configurable Dashboard GUI is also provided, that can be used as a holder for other GUI components: no need to compile code: just edit a Manifest XML file. See Figure 4, 5, 6.

Figure 3: the set of Viewer services, i.e. powerful GUIs for monitoring most sensors or robot”s behaviors.

Figure 4: a Dashboard with path controller’s GUI (on top), a view from the laser sensors (bottom right), a motion controller view (bottom left).

Figure 5: another dashboard composition with a map view (in the center), and linear and angular speed views (bottom), a path recorder GUI (top left).

Some detailed examples of services GUIs

Figure 6: map Viewer GUI

Scripting with the LUA langage, the LUA Integrated Development Environment (IDE)

LUA is a powerful scripting language, used in many video games, in Adobe applications like Photoshop, in CISCO appliances, etc. Check Wikipedia for a complete description of LUA. More interesting: robots have already been programmed in LUA, and integrating LUA with the C# API of the robuBOX services is really easy. Furthermore, most robuBOX services have LUA bindings and can are ready to be used from scripts. LUA is extensible and embeddable, open source, under MIT license, fast, lightweight and simple!

Robosoft provides a powerful LUA editor (see Figures 7, 8 and 9)

• Auto documented (both LUA + RobuBOX bindings)
• Contains many example scripts,
• Provides syntax highlighting, infinite undos, etc .
• Intellisense (auto-completion),
• Comes as an application or as a reusable GUI component.

Figure 7: the LUA IDE running a script that controls a simulated Cybercar (running the robuBOX)

Figure 8: The LUA full-featured editor proposes auto-completion, error checking, etc.

Figure 9: the LUA Integrated Development Environment is auto-documented

Figure 10: The LUA IDE can be embedded into a robuBOX service’s GUI  !

Simulation services

When you buy a robot from Robosoft, it comes with the software layers described in this document (PURE, RobuBOX ans Lokkaria) but also with specific components like an accurate 3D model of the robot, specifically designed for the MRDS simulation system (the robot model includes physical data : weight, power of motors, contact surfaces, sensors, collision surfaces, etc). Simulating is particularly interesting in these use-cases:

1. Try the code you develop before deploying it on a real robot. Thanks to the service oriented architecture, you can run on simulation the same code that will be run on a real robot. Only the IP address needs to be changed (see Figure 14). The main advantages of this approach is 1) solve all problems that can occur due to software configuration, composition of services, etc. 2) The physical model in the simulation package is accurate enough even for testing control loops like the ones necessary for trajectory following. For example, Robosoft developed in simulations the entire road following software used on the robots deployed at the Vulcania theme park, in france, before testing with real robots on a real road (see for example the “simulation of cybercars in a city center” on YouTube: http://www.youtube.com/watch?v=tMErLj8uT7A).
2. Try robots on simulated environments. Bagdad? City traffic? The Moon? With realistic and accurate 3D environments, you can now test your robot behavior without the need to put it in real situation. Robosoft sells several ready to use 3D environments like in-house (figures 12 and 13), city, etc environments or develop environments on demand.
3. Use simulation tools for education purposes. One robot, 10 simulation boxes on student’s desktops…

Figure 11: The simulated roburoc with the GUI of the Dashboard service.

Figure 12: DSLAM service from robuBOX that controls a simulated robulab 10 in a “in house” 3D environment.

Figure 13: The “in house” environment.

How to customize your robots?

Today, RobuBOX has the following benefits: the application model is really powerful and generic, MRDS and C#/.Net have a good acceptance by the robotic community and users and developers of RobuBOX will use the same development environment and programming languages, it provides a lot of useful features (persistence, performance, simulation, RESTful web services architecture).

All the software in the RobuBOX Services’ layer is open source, under the LGPL license. This means that the code is easily customizable to any particular need. However, open source does not mean low quality: RobuBOX Services have been deeply tested and used in many real world situations since 2006, when Robosoft started to develop robots with Microsoft’s technologies. All services are documented, and tutorials show how to modify and recompile/redeploy some key services like the Dashboard Service that is useful for basic control of the robot (using an xbox gamepad or the mouse), for monitoring sensors’ inputs, etc.

RobuBOX Services are configurable using a manifest file. Editing this XML file is an easy way to customize the services and their GUIs, see Figure 14, 15 and 16.

Figure 14: the XML manifest used to configure the Dashboard service.

Figure 15: Example of some RobuBOX Services' GUIs.

Figure 16: The Manifest files that can be edited to customize services and their GUI.

If modifying C# code is too complicated, the RobuBOX also provides a LUA interface for most of the services. LUA is a powerful scripting language used in many famous applications (video games like World of Warcraft, Adobe applications, etc), a powerful LUA editor that can be embedded in any service GUI is also available among the tools that come with the RobuBOX. This editor provides color syntax highlighting, embedded help system, auto-completion, and sample scripts and tutorials that ease considerably the development of LUA scripts.

All RobuBOX Services come with a documented REST API, and can be used by clients written in any language, for example, dedicated clients that run on mobile phones, or web applications clients (the Lokkaria layer is just built using remotely RobuBOX Services’ REST APIs through an HTTP connexion). MRDS’s services also come with REST APIs, making Robosoft’s robots completely open to any HTTP client.

What is PURE?

RobuBOX is dedicated to the high-level development of robotic applications, where the difference between embedded and regular applications tends to disappear. This is made possible since all the low-level computations have been deported in a dedicated software layer called PURE.

Since 2006, Robosoft has been one of the pioneering users of MRDS. While this product provides pseudo real-time control for feedback control loops, two years of intensive use showed that it is not really suited for “low level” robot control; by “low level”, we mean interfacing hardware (actuators and sensors) and running feedback control loops with accuracy.

The limitations come from the architecture of MRDS and its underlying technology (.NET):

• The .NET platform provides a high level of abstraction, but we found that I/O operations with typical robot hardware are very costly, both in terms of performance and hardware price.
  
• Windows XP (or Vista, or 7) doesn't provide a real-time capable multi threading system. This is made even worse by the .NET architecture, were memory management can introduce serious delays in software operations.

In order to circumvent these limitations, Robosoft has developed a low-level layer called PURE, written in C++. In current robots, PURE runs on a dedicated embedded computer, based on a SH-4 processor. This computer is currently powered by a customized windows CE 6.0 runtime.

PURE has the following features:

• Supports commonly used hardware in Robotics (CAN, I2C, RS232/422, TCP/IP, USB)
  
• executes low level control tasks. ( feedback control loops + state machines),
• exhibits real time behavior, with respect to Robosoft applications (this has been fixed to 10 milliseconds, +/- 10%),
• exposes different interfaces to meet most of Robosoft customers needs.

A concrete example

A typical exemple of a PURE-based system is the robuRIDE. It is a four motorized wheel autonomous transportation system guided by a hybrid GPS navigation system.

This system is designed with two PURE computers:

• A slave computer, which implements the navigation system:
  • GPS acquisition
  • Gyroscope acquisition
  • Odometry acquisition
  • Data synchronization
  • Kalman filtering, providing a centimetric resolution solution at 100 Hertz
• A master computer, which implements the control system:
  • Speed / Steering control
  • Obstacle detection / anti-collision
  • Path following
  • System management and surveillance

This system exposes all the features necessary for a supervision application, without hard real-time constraints. The supervision system, for example based on robuBOX Services, can send high level commands, such as "go to this point", "follow this path at this speed", "open the doors", and let PURE handle all the low level stuff.

Integration within a complete system

PURE is not intended to be a MRDS/robuBOX like framework. It can be seen as a “super micro-controller”, providing powerful robotic primitives to high level applications.

All these primitives are accessible through a simple and consistent protocol, allowing interoperation with virtually any computer. By default, this protocol is available over an Ethernet network, usind UDP messaging.

The client side of this protocol is of course implemented in robuBOX Services, so MRDS users don't need to worry about it.

Figure 17: robuBOX services that interface with the PURE low-level layer.

However, if the application requires it, it is possible to interface directly with the PURE controller. Its protocol is documented and open to any Robosoft robot user.