The universal module is supposed to be the primary building block of RoFI systems. It should provide enough versatility to build a broad range of systems.

Universal Module Shape

The universal RoFI module occupies two adjacent cells of the grid as can be seen in figure below. Please note that this drawing gives a simplified model in which many technical details are omitted. The module arrangement is inspired by M-TRAN. Unlike M-TRAN, the universal module is grid-aware. The module composes of four parts: body A, body B, shoe A, and shoe B – see figure below. Bodies are supposed to encapsulate actuators, electronics, and accumulators; shoes are meant to provide connection to other modules and provide movement.

The universal RoFI module. The lines specify the grid, dotted lines mark spheres in which the module is inscribed. Note that we show the module with the Z-axis facing right as it better fits the page layout.
Parts of the universal module.

There are 3 degrees of freedom:

  • shoe A rotates against body A along the \(\alpha\)-axis in range \(\langle -90^\circ; +90^\circ\rangle\),
  • shoe B rotates against body B along the \(\beta\)-axis in range \(\langle -90^\circ; +90^\circ\rangle\), and
  • body A rotates against body B along the \(\gamma\)-axis in range$ \(\langle -180^\circ; +180^\circ\rangle\) with an overflow
Degrees of freedom of the universal module. The figure represents neutral position of each joint.

There are 3 docks on each shoe – dock \(X+, X-\) and \(Z-\). The position of the docks is captured in figure below.

Docks on the universal module. The arrow on each dock specifies its orientation.

Such module arrangement is more versatile than the M-TRAN arrangement. Addition of the third axis, the \(\gamma\)-axis, overcomes two limitations of M-TRAN-like arrangement:

  • given a chain configuration with all joints parallel to each other, the system can span only in two dimensions; it cannot expand into the third dimension.
  • Also, given a roller configuration (figure below) which can roll forward, the M-TRAN module cannot steer and only moves forward.
Roller configuration

Universal Module Sensors

We design the universal module to be sensor-impecunious rather than sensor-rich. We suppose there will be various RoFI systems with various sensor needs. Therefore, we find more useful to implement in the universal module only sensors that can be beneficial in nearly all systems. The special sensors for concrete systems should be implemented as separate modules.

There are two types of sensors in each universal module:

  • a inertial measurement unit (IMU) and
  • a distance sensors in the middle of each dock.

The IMU provides a basic notion of the module orientation in the space. Data from IMU can be used in algorithms to, e.g., determine a common direction in space among all modules using the Earth’s gravitational force.

We plan to use the VL53L1X time-of-flight distance sensor in each dock. The sensors allow the universal module to detect obstacles in front of the module, help to establish a correct alignment of two docks when connecting and can also be used to scan the environment. The scanning of the environment is performed by moving a shoe and building a depth map. The depth map can be used as a simple input for computer vision. For example, when a RoFI system is supposed to climb stairs, it can measure their geometry by this procedure.

Intra-module Architecture

Each universal module is an autonomous unit. A single control unit controls the module. This unit controls all the other components of the module as can be seen in figure below. The unit controls smart servomotors over a bus built on top UART, docks over SPI bus and directly controls charging and power management circuits.

Block diagram of internal architecture of the module.

Control Unit

The control unit is designed to be powered by the ESP32 microcontroller. This microcontroller provides enough computational power, provides rich peripherals including Bluetooth 4 Low Energy and WiFi 802.11 b/g/n, and most importantly, the vendor provides excellent software support. We are mainly concerned by three aspects of the software support:

  • there is support for modern C/C++ compilers with full support for the C++ standard library (including exception handling and concurrency),
  • the development framework provides POSIX compatible interface, and
  • there is a vendor maintained port of the lwIP library.

First two aspects are crucial for easy development of software. From a practical perspective, the ESP32 is nearly indistinguishable from a desktop POSIX environment while it still preserves real-time nature and easy access to low-level peripherals. The POSIX compatibility allows the developers to leverage existing libraries and port them to the universal module without a significant effort. The support for lwIP is a benefit as the control unit serves as a network switch and therefore, we can use it. The only necessary part of implementing is the custom device driver for the docks.

The control unit is not supposed to provide any sensors except the IMU since the placement of IMU in the robot is not crucial. The distance sensors on the docks are controlled by a microcontroller on the dock and the control unit.

Motors

We decided to use so-called smart servomotors (servos) to power the universal module. These servos are similar to their hobby counterparts. Just like the hobby servo, the smart servo is a DC motor with a gearbox combined with a driver and a feedback loop controller in a single compact package. The main difference between these two is that smart servos provide a digital bus for sending commands (unlike pulse-width modulation communication used in hobby servos) and offer several advanced features. The hobby servo can be controlled only in a position mode without any feedback to the control system. The smart servos usually allow for multiple control modes (torque, speed, and position), allow continuous rotation and also provide feedback to the control system. Therefore, the system can detect when the motor reaches a commanded position or if the motor is overloaded.

The usage of smart servos simplifies both, the mechanical construction and the control unit, as we can omit motor driver, custom gearing and encoders. In our design, we use HerkuleX DRS-0101 servos. These servos are designed to be powered directly from a two cell li-ion accumulator and provide 1.2 N\(\cdot\)m of torque at the maximal speed of one turn per second. The servos communicate over UART bus, where the control unit serves as a master and the servos are slaves. The servos can be daisy-chained and therefore, only two wires are required for the communication. The command set provides means to perform a synchronized movement.

We choose the DRS-0101 servos for several reasons: they feature slightly smaller mechanical size compared to the Dynamixel AX-12A (a comparable servo), they are mechanically compatible with DRS-0201 servos, which feature twice the power. The servo is also mechanically compatible with Lewansoul LX-16A, which is a low-cost alternative for possible future mass production.

Power Management

The module is supposed to be powered from a two cell li-ion accumulator pack. The motors can directly operate from the accumulator at their rated voltage and can drain sufficient current. The control unit is also powered from the accumulator.

The internal connection of power rails is captured in figure above. There is a charger circuit to allow for charging from the INT line. The charger is controlled by the control unit – it can be either disabled or it can charge the accumulator with given power limit. There is also a step-up convertor used to source power to other modules. The used step-up convertors must be parallelizable (denoted by a diode in the block diagram). The step-up module is also controlled by the control unit and can be disabled when not needed. Having this power sharing setup, the module can operate in four modes:

Self-powered mode The module runs on its own accumulator (a charger is disabled and a convertor is disabled).

Power sourcing mode The module provides energy to the network (a charger is disabled and a convertor is enabled).

Power draining mode The module charges its accumulator and drains power from other modules.

Survivor mode The module disables motors, disables converter and limits the charging power roughly to cover energy consumption of the control module. Therefore, no charging occurs and the charger acts as a step-down converter for the control unit.

The communication in the RoFI platform requires an activity from the control unit as it routes packets between the docks. If a module shuts down due to a discharged accumulator, there cannot be any communication across the module. A dead module might lead to a separation of the system into two independent networks in some configurations. Therefore, survivor mode can be applied to keep the communication going without waisting power on charging the dead module.