Effective methods for Simultaneous Localisation And Mapping (SLAM) are key to enabling autonomous robots to navigate unknown environments. While single-robot SLAM has been extensively researched, attention has shifted to multi-robot collaborative SLAM (C-SLAM) which offers the opportunity for higher performance thanks to parallel execution of mapping and localisation by a distributed team of robots. However, C-SLAM also introduces challenges in system scalability and consistent data aggregation, and exposes the system to potential security risks.
In particular Byzantine robots, which are robots that behave improperly or maliciously, can heavily disrupt the C-SLAM process. This paper discusses how different types of Byzantine robots can disrupt Swarm-SLAM, the state-of-the-art decentralised C-SLAM framework for swarm robotics.
We then propose a new approach based on blockchain technology to mitigate several of the identified security threats and improve the Byzantine fault tolerance of Swarm-SLAM. The proposed solution consists of a blockchain-based smart contract that manages robots' reputations to identify and neutralise Byzantine robots. Our multi-robot simulation results show the existence of a trade-off between fault tolerance and efficiency in terms of map generation speed. With this work, we also release a custom open-source blockchain software integrated into the ROS2 framework.
The Byzantine robots add 10 metres to each vector component at every loop closure calculation. (a-b) Comparison of the error in the aggregated robot trajectories after PGO for different numbers of Byzantine robots (x-axis) in a swarm of 8 robots using the original Swarm-SLAM (without smart contract) or the Byzantine fault tolerant Swarm-SLAM (with smart contract). The boxplots in (a) show the APE for one representative simulation experiment while in (b) the RMSE is computed over 10 simulation runs (in the same environment but with different starting conditions). (c) Reputation tokens at the end (minute 40) of one representative experiment for Byzantines and non-Byzantine robots. The red boxes (on the left of each green box) are always flat at zero. (d) Proportion of validated loop closures that are used in the Swarm-SLAM’s PGO (results for 10 simulation runs for each condition). The red line indicates that 100% of the proposed loop closures are used in PGO in the original Swarm-SLAM. The boxplots visually represent the distribution of the data using a box (showing the interquartile range or IQR), a median line, whiskers (extending from the box to show the range of data within 1.5 times the IQR above and below the upper and lower quartiles), and outliers (represented as individual points, positioned beyond the whiskers of the plot).
Implementing a higher security level means fewer loop closures are approved within the same time period, leading to a potential decrease in the speed of map creation. This trade-off is an essential consideration when applying the security protocol developed in this work. The accompanying figure illustrates this relationship, with the y-axis representing the percentage of inter-robot loop closures and the x-axis representing the applied security levels. These data points were collected after a 40-minute simulation run. Importantly, the simulation was stopped after 40 minutes when the initial set of loop closures reached level 3. With extended run times, higher security levels would likely be achieved.
The Byzantine robots add random value drawn from a uniform distribution between -9 and 9 metres to each vector component at every loop closure calculation.
The Byzantine robots add 1 metre to each vector component at every loop closure calculation.