# An Edge Architecture Oriented Model Predictive Control Scheme for an
Autonomous UAV Mission

Achilleas Santi Seisa, Sumeet Gajanan Satpute, Björn Lindqvist, and George
Nikolakopoulos This work has been partially funded by the European Unions
Horizon 2020 Research and Innovation Programme AERO-TRAIN under the Grant
Agreement No. 953454. The Authors are with the Robotics and AI Team,
Department of Computer, Electrical and Space Engineering, Luleå University of
Technology, Luleå Corresponding Author’s email<EMAIL_ADDRESS>
###### Abstract

In this article the implementation of a controller and specifically of a Model
Predictive Controller (MPC) on an Edge Computing device, for controlling the
trajectory of an Unmanned Aerial Vehicle (UAV) model, is examined. MPC
requires more computation power in comparison to other controllers, such as
PID or LQR, since it use cost functions, optimization methods and iteratively
predicts the output of the system and the control commands for some determined
steps in the future (prediction horizon). Thus, the computation power required
depends on the prediction horizon, the complexity of the cost functions and
the optimization. The more steps determined for the horizon the more efficient
the controller can be, but also more computation power is required. Since
sometimes robots are not capable of managing all the computing process
locally, it is important to offload some of the computing process from the
robot to the cloud. But then some disadvantages may occur, such as latency and
safety issues. Cloud computing may offer ”infinity” computation power but the
whole system suffers in latency. A solution to this is the use of Edge
Computing, which will reduce time delays since the Edge device is much closer
to the source of data. Moreover, by using the Edge we can offload the
demanding controller from the UAV and set a longer prediction horizon and try
to get a more efficient controller.

###### Index Terms:

Edge Computing; UAV; Model Predictive Control

##  I Introduction

In the future robots will have to complete more complex tasks and the
requirements for an autonomous capability will increase. In that context,
robots will need to have more computational power that many times and based on
the mission’s complexity, this will not be possible to happen locally on-board
the robots’ processors. These cases are the exactly ones where edge oriented
control architectures are needed to provide the desired high computation power
and bandwidth, while retaining an overall low latency. In this article, we
propose an edge computing architecture for offloading the model predictive
controller from an UAV to the Edge. By offloading the MPC to the Edge we will
be able to use Edge resources and push MPC capabilities to the limits.

Edge Computing is an existing technology with tremendous upcoming
possibilities. The combination of Edge Computing and 5G can revolutionize the
world of robots. However, there are some limitation and challenges which
researchers try to solve in order to use these technologies universally, while
some examples from the state of the art in the field can be mentioned as in
[9] where a 4 layer architecture consisted of Robot, Edge, Fog and Cloud is
used for offloading the localization and mapping operations. A Search Planner
algorithm using Deep Learning is designed at the Edge for UAVs in [10]. In
[11] the computational and storage resources are moved to the Edge and the
Cloud for Deep Robot Learning including object recognition, grasp planning,
localization etc. Finally, in [12] a Fog architecture is proposed for
communicating and controlling robots.

In all the articles mentioned above, the Edge is used mainly for offloading
the demanding Artificial Intelligence, Machine or Deep Learning algorithms. On
the other hand, there are not many articles presenting attempts of offloading
controllers to the Edge from an automatic control systems approach. In [7] it
has been presented an application containing a remote controller that it is
able to run in a Mobile Edge server in a form of Docker Container. These
applications are controlling two robotic arms for a cooperation task in an
industrial environment. In [8] a switching multi-tier controller is presented.
The switcher is choosing between a local controller, which operates as a
safety controller and an Edge controller, which runs more sophisticated
algorithms with optimal performance. In the works in [1, 2, 3, 4, 5, 6]
researchers have suggested offloading the MPC on the Edge. However, these
articles focused mainly on evaluating the related latency times, the time
delays and the related uncertainty for several cases. The controller in [4]
and [3] is composed with the combination of a LQR (locally) and MPC (Edge)
control, while in [2] and [5] two MPCs are implemented, one on a local Edge
and one on a Cloud. In [6] a variable horizon strategy for a cloud-based MPC
is presented and in [1] a remote MPC is used to control a ball and bean
system.

The main contribution of this work is to establish an edge architecture
oriented Model Predictive Control scheme for enabling a fully autonomous UAV
mission. As the need of autonomous capability increases, algorithms get more
and more complex and computational heavy, more hardware on board may be
required and UAVs need to be lighter in order to operate longer and more
efficient. Under these requirements, we were motivated to implement a platform
that will meet some of these needs and will offer new capabilities. By using
the Edge not only we can offload the computational demanding operations there
and use lighter processors on UAVs, but also we can use the great Edge
resources for computational and storage purposes. In this article we will
present a novel Edge architecture to offload the MPC to the Edge and to
evaluated this architecture’s capabilities in terms of latency and
computational power as well as overall tracking of the desired trajectories
for the UAV. Towards this novel implementation, for the Edge we have used a
local machine where the MPC is deployed inside a Docker container and is
sending the command signals to the UAV model, the architecture of which is
shown in Fig. 1

Figure 1: System Architecture using Docker Image on the Edge

The rest of the article is structured as it follows. In Section II the Model
Predictive Control scheme is presented and in Section III the overall system’s
edge architecture is established, while we also provide a detailed analysis
through the parameters of the controller and we explain the need of offloading
the controller to the Edge. In Section IV multiple experimental results, with
a hardware in the loop approach, are presented that prove the overall efficacy
of the proposed scheme, while we analyse and evaluate the usage of the Edge in
matters of latency and computation capabilities. Finally, in Section V, the
future research directions and the conclusions are derived.

##  II Model Predictive Control

###  II-A UAV Kinematics

Model Predictive Control has been widely used in both research and industrial
environments. In this article MPC is implemented for following the desired
trajectory of a UAV, where the platform is considered as a six Degree of
Freedom robot with a fixed body frame and its kinematic model can be described
by Eq. 1 in body frame as in [13, 14].

$\displaystyle\dot{p}(t)=v_{z}(t)$
$\displaystyle\dot{v}(t)=R_{x,y}(\theta,\phi)\begin{bmatrix}0\\\ 0\\\
T\end{bmatrix}+\begin{bmatrix}0\\\ 0\\\
-g\end{bmatrix}-\begin{bmatrix}A_{x}&0&0\\\ 0&A_{y}&0\\\
0&0&A_{z}\end{bmatrix}u(t)$ (1)
$\displaystyle\dot{\phi}(t)=\frac{1}{\tau_{\phi}}(K_{\phi}\phi_{d}(t)-\phi(t))$
$\displaystyle\dot{\theta}(t)=\frac{1}{\tau_{\theta}}(K_{\theta}\theta_{d}(t)-\theta(t))$

In Eq. 1 $p=[p_{x},p_{y},p_{z}]^{T}$ is the position and
$v=[v_{x},v_{y},v_{z}]^{T}$ is the linear velocity referenced in the global
frame. $R(\phi(t),\theta(t))\in SO(3)$ is the rotation matrix that describes
the attitude in Euler form. $\phi$ and $\theta\in[-\pi,\pi]$ are the roll and
pitch angles along the $x^{\mathbb{W}}$ and $y^{\mathbb{W}}$ axes
respectively, while $\phi_{d}$ and $\theta_{d}\in R$ and $T\geq 0$ are the
desired inputs values to the system in roll, pitch and the total thrust. The
above model assumes that the acceleration is only dependant on the magnitude
and angle of the thrust vector, produced by the motors, as well as the linear
damping terms $A_{x},A_{y},A_{z}\in R$ and the gravity of earth $g$. The
attitude terms are modeled as a first-order system between the attitude
(roll/pitch) and the desired $\phi_{d}$ and $\theta_{d}\in R$, with gains
$K_{\phi}$ and $K_{\theta}\in R$ and time constants $\tau_{\phi}$ and
$\tau_{\theta}\in R$. It is also assumed that the UAV is equipped with a
lower-level attitude controller that takes thrust, roll and pitch commands and
provides motor commands for the UAV.

###  II-B Cost Function

For the cost function, the UAV’s state vector is represented as
$x=[p,v,\phi,\theta]^{T}$ and the control input as
$u=[T,\phi_{d},\theta_{d}]^{T}$. The system has a sampling time of
$\delta_{t}\in\mathbb{Z}^{+}$ using forward Euler method for each time
instance $(k+1|k)$, while this discrete model is used as the prediction model
of the MPC. The prediction considers the specified number of steps into the
future, which is called prediction horizon and it is represented as $N$. An
related optimizer is tasked with finding an optimal set of control actions,
defined by the cost minimum of this cost function, by associating a cost to a
configuration of states and inputs at the current time and in the prediction.
The predicted states at the time step $k+j$, produced at the time step $k$ are
represented as $x_{k+j|k}$. The corresponding control actions are represented
as $u_{k+j|k}$. Also $x_{k}$ and $u_{k}$ represent the full predicted states
and corresponding control inputs along the prediction horizon correspondingly.
The objective of the controller is to navigate to the desired position and
deliver smooth control inputs. The cost function is presented in Eq. 2.

$\displaystyle
J=\sum_{j=1}^{N}\underbrace{(x_{d}-x_{k+j|k})^{T}Q_{x}(x_{d}-x_{k+j|k})}_{state\quad
cost}$
$\displaystyle+\underbrace{(u_{d}-u_{k+j|k})^{T}Q_{u}(u_{d}-u_{k+j|k})}_{input\quad
cost}$ (2) $\displaystyle+\underbrace{u_{k+j|k}-u_{k+j-1|k})^{T}Q_{\delta
u}(u_{k+j|k}-u_{k+j-1|k})}_{control\quad actions\quad smoothness\quad cost}$

Figure 2: Block Diagram of the Edge Architecture for the UAV-MPC System

where $Q_{x}\in\mathbb{R}^{8x8}$ is the matrix for the state weights, $Q_{u}$
is the matrix for the input weights and $Q_{\delta u}\in\mathbb{R}^{3x3}$ is
the matrix for the input rate weights. In Eq. 2 the first term describes the
state cost, which is the cost associated with deviating from a certain desired
state $x_{d}$. The second term describes the input cost that penalizes a
deviation from the steady-state input $u_{d}=[g,0,0]$ and represent the inputs
that describe hovering. The final term is added to guarantee that the control
actions are smooth. That is achieved by comparing the input at $(k+j-1|k)$
with the input at $(k+j|k)$ and penalizing the changing of the input from one
time step to the next one, with $N\in N^{+}$ to denote the control Horizon of
the MPC. In this case, we evaluate the overall behavior of the MPC scheme by
changing the values of the horizon and the execution rate and measuring the
overall latency times from the proposed edge architecture. while the
motivation of experimenting with these parameters is described in Sections
II-B1 and II-B2.

####  II-B1 MPC Horizon

MPC is optimizing a finite prediction horizon but is using only the next time-
slot, while this process is executed again, repeatedly at every step. By
utilizing the MPC, we optimize the current step, while keeping the future
time-slots in account. By increasing the finite number of the prediction
horizons the process becomes more computational heavy, thus more resources are
required. On the other hand, since MPC can predict the change of dependent
variables, an increased prediction horizon can make better predictions and
predict changes faster. The limited computational capability of UAVs’ on-board
processors are setting some boundaries on how much we can increase the number
of steps for the prediction horizon. To overcome this constrains, we use the
computational power of the Edge, where we are able to increase the horizon and
evaluate the results in Section IV.

####  II-B2 MPC Rate

Another parameter’s value that we were able to increase on the Edge was the
value of the MPC Rate. That is how fast the MPC is executed. A faster MPC
means a faster control system that can generate commands, to be send to the
UAV rotors, faster. This would be handful in situations where we want the
system to respond rapidly. This characteristic is of great importance
especially in the case of aerial vehicle systems. As in the previous cases,
the computational capabilities of the UAVs’ processors set some limits that we
were able to overcome since we used the Edge for these processes. The
processors of some UAVs that we use have the capability to run the MPC at
20Hz, but by using the Edge we were able to increase the rate up to 100Hz. The
results of increasing the MPC Rate are shown in Section IV.

##  III Edge Architecture

The Container is a unit of software that runs code and all the dependencies so
the application deployed on the container will run quickly and reliably from
any computer. In our case, the application Docker container runs the MPC on
the Edge, while the UAV model is implemented on a local computer. The local
machine used as an Edge server and the local computer running the UAV model
must share the same network. In the propose architecture we have utilized an
Ubuntu 20.04 Container Image running ROS Noetic for deploying the MPC on the
Edge, and the same operating system and software on our local computer.

In this architecture, MPC commands are sent from the Edge to a local computer,
which runs a simulation of a UAV, as shown in Fig. 1 that represents the basic
structure of the system. Furthermore, in this implementation, we have utilized
the TCP protocol for the communication between the Edge and the local
computer, which are under the same network, while we ran RosMaster, MPC and
Optimizer ROS Nodes on the Edge. The simulation node ran on Gazebo environment
on our local computer. The architecture and the block diagram of the system
are shown in Fig. 2, while the ROS operation is shown in Fig. 3.

The parameters of the system are depicted in Fig. 2, where $r(k)$ is the
reference input signal for the desired trajectory and $x(k)$ is the states
signal generated by the UAV dynamics. In the proposed architecture, we
feedback the states signal to the MPC. Since there is latency from the time
instance that the UAV dynamics, on the local computer, generate the states
signal to the time instant that the signal gets to the MPC, on the Edge (round
trip delay), the states signal arriving to the MPC is delayed and denoted as
$x(k-d_{1})$, where $d_{1}$ represents the time delay. The reference and the
states signal describe the desired pose and the real pose of the UAV
respectively. $u(k-d_{2})$ is the command signal generated by the MPC. The
value $d_{2}$ represents the MPC execution time that is depending on the MPC
rate and the computational process. Again, since the command signal has to
travel from the Edge to the local computer, where the UAV model is
implemented, the command signal arriving to the UAV can be denoted as is
$u(k-d_{1}-d_{2})$, while the command signal is the necessary thrust for each
one of the rotors for the desired trajectory. Finally, $y(k)$ is the output of
the system which denotes the $x,~{}y,~{}z,~{}yaw$ values of the real pose of
the UAV.

##  IV Simulation Results and Evaluation

In this Section we evaluate the system and present the simulation results with
a hardware in the loop approach (edge architecture and software model for the
aerial platform. In more details, we used an Edge Server located in Luleå,
Sweden. The Edge Server is providing the needed computational resources with
low latency. In Fig. 3 the ROS structure is depicted, where we import the
Optimizer into the MPC Node, which subscribes to the odometry topic (measured
position depended on UAV real position) and reference topic (reference
position depended on desired trajectory) and publishes the commands to the
thrust topic (MPC output value of thrust for desired trajectory), while the
UAV simulation subscribes to the thrust topic to receive the commands and
publishes its position to the odometry topic. In order for the MPC and the UAV
dynamics Nodes to exchange data by publishing and subscribing to topics, they
have to register to the RosMaster, which is running on the Edge.

Figure 3: ROS Architecture showing: a)ROS nodes in blue, and b)ROS topics in
yellow. The lines point out the relationship between topics and nodes

The sequence of the operation is described in Alg. 1, where the MPC controller
is taking care of the UAV to follow the desired trajectory with an Error
Tolerance of $0,4m$.

Algorithm 1 Algorithmic Sequence of Operations

1\. Start RosMaster Node
2\. Run Optimizer
3\. Start UAV Dynamics Node
4\. UAV Reads Real Position $[x,y,z]^{T}$ from Sensors
5\. Start UAV MPC Node
6\. UAV Start Take Off
7\. UAV Hovering at $[x,y,z]^{T}=[0,0,1]^{T}$
8\. Load Desired Trajectory
9\. Calculated Way Points ($x_{ref},\quad y_{ref},\quad z_{ref}$)
10\. UAV Follow the Way Points

$k=0$

while $x_{ref}(k)-x,\quad y_{ref}(k)-y,\quad z_{ref}(k)-z\geq 0.4m$ do

$goto\quad x_{ref}(k),\quad y_{ref}(k),\quad z_{ref}(k)$

end while

$k=k+1$

For the simulation of the UAV model we used the Gazebo simulation software,
while we were able to visualize the behavior of the system for each one of the
different MPC horizon and rate values. Furthermore, we recorded the data from
the odometry, reference and thrust topics and we evaluated the system by using
the MATLAB environment of MathWorks to extract useful data and plots.

To evaluate our proposed architecture, we completed a series of simulation
tests. Our goal was to evaluate the system in terms of latency and
computational capacity. To achieve that we choose two different desired
trajectories, a circular and a spiral. We determined different MPC horizons
and rates and we run several tests. For each test we measured the time delays
and we evaluated the responses. The objective were to increase the MPC horizon
and rate in values that the local processor would not be able to handle. In
Fig. 4 and Fig. 5 we depict the latencies for different values of horizons and
rates respectively. The Table I and Table II present some information
regarding the latencies.

Figure 4: Frequency distribution for different MPC Horizon values TABLE I: Latency in milliseconds for different horizon steps and fixed rate at 40 Hz $HorizonSteps$ | $20$ | $40$ | $60$ | $80$ | $100$
---|---|---|---|---|---
$Minimum$ | 21.518 | 14.583 | 10.647 | 12.691 | 12.362
$LowerAdjacent$ | 49.348 | 49.158 | 48.582 | 48.054 | 47.217
$25^{th}Percentile$ | 49.843 | 49.785 | 49.642 | 49.511 | 49.363
$Median$ | 50.002 | 49.998 | 50.008 | 50.010 | 50.033
$75^{th}Percentile$ | 50.175 | 50.208 | 50.349 | 50.492 | 50.796
$UpperAdjacent$ | 50.658 | 50.840 | 51.397 | 51.946 | 52.927
$Maximum$ | 86.705 | 83.665 | 82.910 | 86.629 | 82.007

As we can observe from Fig. 4 and Table I, by increasing the value of the MPC
horizon, the median time delay remains almost the same, but we have more
deviation. This was expected, since longer horizon means more computations so
the execution of the MPC might get slower in some cases. The difference of
deviation between the shorter and longer chosen horizon is in single digit
millisecond.

Figure 5: Frequency distribution for different MPC Rate values TABLE II: Latency in milliseconds for different rates and fixed horizon at 20 steps $Rate(Hz)$ | $20$ | $40$ | $60$ | $80$ | $100$
---|---|---|---|---|---
$Minimum$ | 14.583 | 4.878 | 4.931 | 3.003 | 3.062
$LowerAdjacent$ | 49.158 | 24.071 | 15.847 | 11.933 | 9.463
$25^{th}Percentile$ | 49.785 | 24.768 | 16.465 | 12.359 | 9.869
$Median$ | 49.998 | 25.006 | 16.682 | 12.503 | 10.000
$75^{th}Percentile$ | 50.208 | 25.240 | 16.868 | 12.650 | 10.141
$UpperAdjacent$ | 50.840 | 25.939 | 17.464 | 13.080 | 10.545
$Maximum$ | 83.665 | 42.261 | 25.299 | 30.854 | 19.809

In Fig. 5 and Table II we can see that by increasing the MPC Rate, the
controller gets much faster and we do not suffer from standard deviations.
This means that we can take advantage of the Edge resources and we can
implement a much faster controller. As we already mentioned, this is essential
for the UAV because with a fast controller, the system can respond faster. The
importance of a fast controller can be shown in the case of collision
avoidance, where the UAV have to respond fast in order to prevent the
collision. The combination of a fast controller with a predictive behavior can
help the system avoid the collision in an optimal way.

Figure 6: 3D view of the circular trajectory. Red line: reference signal. Blue
line: real trajectory Figure 7: Responses of the circular trajectory for each
axis. a)x axis response, b)y axis response and c)z axis response Figure 8:
Error between reference and real position on X, Y and Z axis during circular
trajectory Figure 9: Latency for each signal step of the circular trajectory

The round-trip for the MPC execution for each step is shown in Fig. 9. These
measurements are from the circular trajectory shown in Fig. 7 where the
duration of the circular trajectory was 100 seconds and for the spiral
trajectory was 130 seconds. The MPC rate is set at 20Hz and the MPC Horizon
steps are set to 20. The mean execution time is 49.95 milliseconds, which is
almost the same to the MPC Rate 20Hz, which is equal to 50 milliseconds. In
Fig. 6, 7, 10 and 11 the responses of the circular and spiral trajectories are
depicted, where the red line represents the reference signal and the blue line
the real trajectory, while in Fig. 9 and Fig. 13 we can observe the latencies
for each time step of the two different trajectories, respectively.

In Fig. 6 we are presenting the 3D responses of the UAV model when receiving
the commands, for following a circular trajectory, from the Edge MPC. The blue
line represents the desired trajectory and the red line represents the real
trajectory of the UAV model. The real trajectory is following the desired one
under the requirements with an error $\in[0,0.4m]$. The same principals are
applied for the spiral trajectory in Fig. 10.

Moreover, we are presenting the responses in each axe in Fig. 6 and 7 for the
circular and the spiral trajectory respectively. In these figures it is easy
to observe the steady state error, which is reasonable since we applied an
error tolerance of $0.4m$.

Furthermore, the errors between the reference and real position on X, Y and Z
axis during circular and spiral trajectories are depicted in Fig 8 and 12
respectively. The controller tends to keep the error under the tolerance of
0.4m.

Finally, in Fig. 9 and Fig. 13 we are presenting the overall latency of each
time step. We calculated the latency by extracting the frequency distribution
between two sequential commands. The latency as we explained in Section III,
depends on two parameters, the MPC execution time, based on the MPC rate and
computational needs, and the round trip delay. So the latency in Fig. 9 and 13
is the sum of the latencies for each time step as shown in Eq. 3.

$L_{total}=L_{rtd}+L_{exec}$ (3)

where $L_{total}$ is the total latency, $L_{rtd}$ is the round-trip latency
(RTL) and $L_{exec}$ is the MPC execution time latency.

Figure 10: 3D view of the spiral trajectory. Red line: reference signal. Blue
line: real trajectory Figure 11: Responses of the spiral trajectory for each
axis. a)x axis response, b)y axis response and c)z axis response Figure 12:
Error between reference and real position on X, Y and Z axis during spiral
trajectory Figure 13: Latency for each signal step of the spiral trajectory

##  V Conclusion

We were able to successfully control the trajectory of an UAV with a MPC
operating on the Edge, but still there are some improvements that can be
applied. Our next step would be to deploy our Docker Containers as PODs on a
Cluster and use Kubernetes for orchestration. POD is the group of containers
sharing storage and network resources and Kubernetes is an orchestration
system for automatic application deployment, scaling and management [15],
while this would be helpful in terms of deploying and managing our containers
and it will be also possible to assign the desired resources and create
services for better and more efficient management.

Over and above that, there are some further directions for potential
improvements. The major issues with our system’s architecture is the latency
and the lack of a backup controller running locally on UAV’s on-board
processor. We will be able to challenge these throwbacks by using 5G network
capabilities for reducing the latency by reducing the signals’ travel time.
Additionally, 5G will provide us more bandwidth for huge amount of data
streaming. Moreover, we can have a backup computation light controller locally
on the UAV that will operate only in case of network connection lost.

Some interesting future direction will be to operate in challenging
environments and scenarios where the long MPC horizon and the high MPC rate
will come in use. These scenarios can be an obstacle or collision avoidance
missions and in environments where the UAVs navigation is rather difficult.
Additionally, we can use the capabilities of Edge for UAVs’ operations for
more complex tasks. Offloading these complex tasks on the Edge and having a
multi agent systems cooperation in real time will be a fascinating future
direction. With the development of the relevant technologies, the capabilities
on the field are expected to expand tremendously.

## References

  * [1] Per Skarin, William Tärneberg, Karl-Erik Årzén, and Maria Kihl, “Towards Mission-Critical Control at the Edge and Over 5G,” presented at 2018 IEEE International Conference on Edge Computing (EDGE), San Francisco, CA, USA, Jul. 2-7, 2018
  * [2] Karl-Erik Årzén, Per Skarin, William Tärneberg, Maria Kihl, “Control over the Edge Cloud - An MPC Example,” presented at 1st International Workshop on Trustworthy and Real-time Edge Computing for CyberPhysical Systems, Nashville, Tennessee, United States, Dec. 11-14, 2018
  * [3] Per Skarin, Johan Eker, Maria Kih, Karl-Erik Årzén, “An assisting Model Predictive Controller approach to Control over the Cloud,” presented at May 15, 2019
  * [4] Per Skarin, Johan Eker, Maria Kihl, Karl-Erik Årzén, “Cloud-Assisted Model Predictive Control,” presented at 2019 IEEE International Conference on Edge Computing (EDGE), Milan, Italy, Jul. 8-13, 2019
  * [5] Per Skarin, Johan Eker, Karl-Erik Årzén, “A Cloud-Enabled Rate-Switching MPC Architecture,” presented at 2020 59th IEEE Conference on Decision and Control (CDC), Jeju Island, Republic of Korea, December 14-18, 2020
  * [6] Per Skarin, Johan Eker, Karl-Erik Årzén, “Cloud-based model predictive control with variable horizon,” published in International Federation of Automatic Control World Congress 2020
  * [7] Ievgenii A. Tsokalo, Huanzhuo Wu, Giang T. Nguyen, Hani Salah, Frank H.P. Fitzek, “Mobile Edge Cloud for Robot Control Services in Industry Automation,” presented at 2019 16th IEEE Annual Consumer Communications and Networking Conference (CCNC)
  * [8] Yehan Ma, Chenyang Lu, Bruno Sinopoli, Shen Zeng, “Exploring Edge Computing for Multitier Industrial Control,” published in IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, Vol. 39, No. 11, Nov. 2020
  * [9] V. K. Sarker, J. Peña Queralta, T. N. Gia, H. Tenhunen, T. Westerlund, “Offloading SLAM for Indoor Mobile Robots with Edge-Fog-Cloud Computing, ” presented at 2019 1st International Conference on Advances in Science, Engineering and Robotics Technology (ICASERT), Dhaka, Bangladesh, May 3-5, 2019
  * [10] A. Barnawi, M. Alharbi and M. Chen, ”Intelligent Search and Find System for Robotic Platform Based on Smart Edge Computing Service,” published in IEEE Access, vol. 8, May 2020
  * [11] Ajay Kumar Tanwani, Nitesh Mor, John Kubiatowicz, Joseph E. Gonzalez, Ken Goldberg, “A Fog Robotics Approach to Deep Robot Learning: Application to Object Recognition and Grasp Planning in Surface Decluttering,” presented at IEEE International Conference on Robotics and Automation, ICRA, 2019
  * [12] Siva Leela Krishna Chand Gudi, Suman Ojha, Benjamin Johnston, Jesse Clark, Mary-Anne Williams, “Fog Robotics for Efficient, Fluent and Robust Human-Robot Interaction,” presented at 17th IEEE International Symposium on Network Computing and Applications (NCA 2018), Cambridge, USA
  * [13] Björn Lindqvist , Sina Sharif Mansouri, Ali-akbar Agha-mohammadi , and George Nikolakopoulos, “Nonlinear MPC for Collision Avoidance and Control of UAVs With Dynamic Obstacles,” published in IEEE Robotics and Automation Letters, vol. 5, No. 4, Oct. 2020
  * [14] Björn Lindqvist, Sina Sharif Mansouri and George Nikolakopoulos, “Non-linear MPC based Navigation for Micro Aerial Vehicles in Constrained Environments,” presented at 2020 European Control Conference (ECC), Saint Petersburg, Russia, May 12-15, 2020
  * [15] kubernetes “Production-Grade Container Orchestration,” available at https://kubernetes.io/ [Accessed: Dec 15, 2021]