Architecture Overview

When we talk about “programming of RoFIs” we mean writing a user program which is uploaded to each module of the system. Currently, the platform does not offer a way to write a program for the whole RoFIBot. Writing programs for RoFIBots is left up to the user.

For the sake of simplicity, we assume each module in a system runs the same firmware (or there is very few categories of firmware). If user wants to customize the behavior between modules, it can do so based on the module IDs when the firmware starts. When all the modules run the same firmware, it is easy to distribute new firmware among the modules.

The figure below show an overview of the software architecture of RoFIs:

The software architecture of the platform. The items above the thick line belong to user-land – software provided by the user. The higher in the diagram, the higher abstraction. The modules depend on the modules below them.

Hardware Abstraction Layer

Hardware abstraction layer (HAL for short) provides the basic abstraction of the RoFI hardware. You can view it as a device driver on a common PC. HAL serves two purposes:

  • it allows the modules use, e.g., various type of sensors or motors without affecting user firmware and
  • to define the basic interface on top which is the simulator built.

Building the simulator on such a low level of abstraction is actually an advantage as:

  • the HAL interface does not change often, therefore it is much easier to keep the simulator up-to-date with current version of the physical robots,
  • HAL interface is rather small, so it is easy to implement,
  • the same RoFI OS code runs on both, hardware and simulator. It is easier to maintain a single instance of such code and also, unit testing of the firmware is easy due to the presence of simulator (no need to write many mocking code).

See the simulator page for more details about it.

Note that the HAL interface is work-in-progress. You can check the progress at the project repository.

RoFI OS

The main purpose of the OS is to provide essential functionality which is common to all use cases of the modules. Note that RoFI OS is not an operating system as such – it does not provide process isolation. It is more like an RTOS on bare metal systems.

The RoFI OS provides:

  • networking (address management, routing, etc.) so traditional TCP/IP sockets are available.
  • event system which allows the user programs to be notified,
  • sensor and actuator interface (including remote calls) and
  • debug logging and firmware update.

Note that the RoFI OS is work-in-progress. You can check the progress at the project repository.

User Programs and Libraries

The users can write their programs in C, C++ or Python. Currently we are working on providing several libraries the user can use to write rather high-level programs. We expect to provide:

  • library for configuration and descriptor representation,
  • building reconfiguration plans,
  • controlling RoFIBots,
  • basic distributed algorithms (e.g., leader election, voting).

We also try our best to port many commonly used libraries (e.g., OpenMPI) which mich be relevant for our project.