Low-Cost Robots in IoT Controlled via Info-Centric Networking

Low-Cost Robots in IoT Controlled via Info-Centric Networking

Minibots

Miniature robots or minibots are small robots of different types (wheeled, legged, airborne etc) capable of communicating through microcontrollers and sensors installed in them. One such minibot, Zooid, is based on a small microcontroller packing a an 8 kB RAM and a 64 kB ROM operates with far less power than a robot operated by Raspberry Pi. There are other examples of such small robots such as the drone, Cheerson CX-150, or the legged robot MetaBot. Minibots are getting more and more popular in the market.

A current trend bases software embedded in minibots on open source frameworks. The Robot Operating System (ROS) is a software framework for robot application development which has become a de facto standard for most areas in robotics.

Minibots and Low-End IoT Devices

Minibots have a number of characteristics in common with low-end devices found in the Internet of Things (IoT). Compared to low-end IoT devices, minibots are based on similar hardware and their software follows similar trends.

For instance, an IoT-enabled actuator based on a System-on-Chip (SoC) embarking a small microcontroller, and a radio communicating with a remote server, is very similar to a simple radio-controlled robot. Low-end IoT devices use similar radio modules, and software embedded in IoT devices is more and more based on a variety of open source, lightweight operating systems.

Similarly, as for IoT embedded systems, the network component of minibots represents by itself in important part of the software. In fact, a wide variety of radio modules and communication protocols are used on minibots.

The authors of the article clearly define their goals and approach using which they move towards meaningful integration of IoT with miniature robots.

Control Systems

Generally, low-end of robots are based on programmable SoC, with a microcontroller running at almost 50 MHz, with around 10kB RAM, 100kB Flash, and a low-power radio.

In general, to achieve an acceptable open-loop control on such robot, the required performance is on the order of transmitting 10 commands per second. For a closed-loop control, however, an additional 10 position data per second should be sent to the computer due to the feedback controls involved.

Portability

Both ROS2 and RIOT are designed with portability in mind, allowing very convenient changing or maintenance of the microcontroller installed at low costs.

Configurability

Any ROS2 node that does not rely on the hardware is able to be executed on any connected hardware, preserving some flexibility in the final application design. This allows the nodes of RSO2 to be offloaded to desktop computers if the task being performed on that node is too intensive for RSO2.

Interoperability

The same system is ported on several platforms. This, implicitly, allows the nodes of different systems to be able to communicate together, independently of their location. The interoperability over different interfaces is usually a complicated task in robotics when using ROS.

Network Layer Flexibility

“Design choices should be agnostic to communication protocols – as much as possible.”

Design of minibots should be independent of protocol stacks used. Where ROS2 defines API plugged in various communication layers; the low level API’s are called ROS MiddleWare (RMW), whilst RIOT uses different types of IoT communication protocols stacks. Based on RMW, the researchers provided communication primitives needed ROS2 by combining the NDN protocol stack provided by RIOT and serialization of data using CBOR.

ROS2 Basics

The concepts for communications of ROS2 are:

Nodes: They correspond to one module (of the user application, typically run in one thread or one process).

Topics: Communication channels used to distribute data from producers (Publishers) to consumers (Subscribers).

IoT Communication Primitives for ROS2

ROS2 operates by sending and receiving messages on named channels, instead of IP addresses. The messages are typed messages with a well defined structure (such as in CDR) and are serialized typically by the RMW. The default communication middleware of ROS2 is an implementation of DDS the middleware interface of ROS2 is agnostic to DDS and as such different middleware implementations are possible.

The main benefits of RTPS compared to the initial protocols in ROS are:

abstraction of the IP addresses, using only names for endpoints

multicast can be used to deliver data to several subscribers

no requirements for a central server for discovery

NDN-Based ROS2 Communication Middleware

NDN is an Information-Centric networking architecture that enables to address data instead of hosts. NDN communication is driven by data consumers: instead of sending an IP packet, in NDN, a data consumer will send an “Interest” packet to the network, containing a structured name corresponding to the desired content.

RIOT-ROS2 Measurements

The setup used is simple in nature as it utilizes one publisher and one subscriber node for creating an ROS2 application. The memory allocation of the system is programmed such that at least 70% of the Ram and Flash memory is available for extra functionality during normal operation.

To evaluate the delay between the response from the publisher and the subscriber, the data flow was tracked finely, from the production by one ROS2 node on one board to its reception on the ROS2 consumer node, by recording the precise time of the data in all software.