Methods

Before we dive into current networking implementation in the RoFI platform we will focus on possible networking implementations in the metamorphic robot system.

Wireless

The first technique that comes to mind is wireless communication. Wireless communication shares the communication media. Therefore, it needs no routing and offers communication with low latency but limits effective bandwidth and concurrency.

Wireless communication has no requirements on the robot connector, and even disconnected parts of the assembly can communicate. However, the power consumption is significantly higher than any wired communication, which is a significant limiting factor for small-factor modules that cannot carry a large battery.

Bus

Another technique that uses shared medium, and thus has similar advantages and disadvantages, is the bus. The benefits of the bus are no need for routing, low latency, trivial broadcast and synchronization. The main disadvantage is the issue with long distances, as the connection needs a strong electrical signal, which can be complicated, expensive, or not realizable.

Packet-switching

On the other hand, packet-switching uses point-to-point communication over short distances. Thus it is much easier to implement and optimize. The main advantage of packet-switching is that it enables simultaneous communication. The disadvantages are overall complex implementation and increased latency. An algorithm can replace the physical implementation of broadcast, multicast and synchronization with data retransmission; therefore their absence in physical implementation is not an issue.

RoFI

The RoFI platform uses packet-switching. The main reason for packet-switching is that the shared bus has limited scalability. Packet-switching allows the usage of both wired and wireless connection, which results in much simpler interoperability with existing networks.

TCP/IP

The RoFICoMs represent the network access layer – L1 and L2 from ISO/OSI model. The RoFI platform uses only IPv6 as certain features provide an easier implementation. Each RoFICoM maps to a single network interface (netif) and has its own network address. For practical reasons, each module has a virtual address representing the module itself rather than its connectors. Also, the module has a netif that is bridged to all other module interfaces.

Addressing and routing

Global communication requires each module to serve as a router. Each netif has an IP address (six plus one addresses for single module). Each module has a unique identifier id, which is assigned a unique local address to the virtual module netif. The address constructed from the identifier is fc07::{id}:0:0:1/80 and is only valid within the robot’s network.

For the neighbor discovery protocol, each connector needs a unique address. This address is the link-local address in range fe80::/10. (This address is only valid within mating connectors.) The unique connector addresses are only for neighbor discovery. Other usages would lead to big routing tables and would not be suitable for efficient routing. New addresses are used for routing inside the robot’s network as this reflects topology and allows for prefix-based routing. (Large address space of IPv6 makes this possible and easy.)

There are also role-based addresses, i.e., the module can be assigned an address based on function. For example prefix for leg modules in spider configuration or sequential address in snake configuration. Changing the role is simply changing the address.

User application feedback

The robot’s reconfiguration is expected to change a lot and with it changes network’s topology. The user application should provide feedback of upcoming network changes to prevent communication delays while changing the shape. Thus, allowing the routing to choose better paths ahead of the change in topology that would be reflected after a delay otherwise.

Implementation

The main purpose of this solution is to use an existing TCP/IP implementation. RoFI uses the lwIP library, a widely used open-source TCP/IP stack designed for embedded systems. Because the library is designed for end devices, it is missing routing. Thus, a custom fork with routing of lwIP library is maintained, which adds new API that enables the integration of routing algorithms. (A custom fork must be maitained since the change cannot be merge to upstream due to licensing issues.)

Conclusion

The mentioned solution was implemented and tested. The results of the solution are comparable to the currently best solutions for metamorphic robots. Another benefit of this solution, besides using already well-established protocol, is the ease of implementation, i.e. under 2500 lines of code. (This accounts for the firmware, drivers and netifs implementation for RoFI’s connector, modification of lwIP and implementation of basic routing algorithm.) The whole TCP/IP stack consumes about 40~kB of microcontroller’s ROM and it requires 28~kB of RAM. However, most RAM (20~kB) is consumed by packet buffers, the rest is consumed mainly by routing tables. As a result, the solution is suitable for resource-limited systems and can be adapted into any metamorphic robots.