Enabling an autonomous robot to transparently access local, edge and cloud services

Several companies and research groups are nowadays investigating the potential of autonomous driving and the improvements that it could bring to our lives. Not all of them, though, are focusing on large and fast vehicles like cars, as some have been concentrating their efforts in much slower and smaller ones, which is the case of ALBA Robot and their SEDIA project. Their focus has been shifted to wheelchairs, with much lower size and speed than other kinds of vehicles. Despite having less strict requirements, there is still the need of leveraging a lot of computational effort in these kinds of autonomous driving applications, which would be best suited for small edge data centers. Unloading the application’s burdens to a close cloud server will bring to sensible improvements in the system’s performance, but it also brings new problems. Indeed, all the data internally exchanged in the application have strict latency requirements: if the network infrastructure cannot sustain the workload at every moment, some malfunctioning surely occurs in the navigation process and that will no longer be considered safe. The focus of this thesis is therefore on two main goals: the first one is to find a way of making the components of the ALBA Robot autonomous driving system work in a cloud server, by finding a way of allowing remote nodes to communicate. Indeed, the navigation architecture presented is based on ROS2, which has no spontaneous way of making its nodes talk over different L2 networks. The second goal will address the malfunctioning of the navigation process in case the network cannot sustain the internal messages exchange’s requirements. One way of achieving resiliency is to guarantee the same service also locally, rather than only in cloud. The final architecture will eventually be composed by both local and cloud nodes, which are their exact copies; cloud nodes will be leveraged when the network connection lives up to the latency requirements, and the local ones otherwise. To reach this condition, a switching mechanism has been designed and implemented, namely an additional architecture thank to whom a switch from local to cloud and vice versa can be triggered, when considered necessary: this architecture is in fact only logical, as it is based on the same navigation mechanisms already existing. An important part of the switching is also the development of some logical criteria to establish when it must be triggered, regardless of how it actually works. A possible way of implementing these criteria was also explored in this work. It consists in monitoring the status of the network at every moment and taking a decision according to how the current connection will affect the navigation’s performances: if using the cloud would mean a substantial loss of navigation performance, a switch to the local nodes is triggered, until network is up again and a switch back to local can be performed. This mechanism is overall independent of the previous problem as well, because it assumes that all the ROS2 nodes present in the autonomous driving architecture can freely communicate, regardless of their physical location in space. Once built this system, the next step will be to execute the cloud nodes inside containers and add some orchestration technology as well: this thesis has chosen Kubernetes, as it is the most commonly used and practical one. The final autonomous driving system will be resilient and capable of avoiding the occurrence of safety critical issues.