# Design of a Generic Wearable-Robot Monitoring System (GWRMS) for Patients with Lower Limb Paralysis
## 2 Related Work  
Several previous studies have examined optimisation of the performance of embedded systems [5,6]. The most general and straightforward way to improve their limited performance is through code analysis and optimisation. Most robots are based on specific platforms, such as Linux-based robot-control middleware systems, including the ROS open-source project [7,8] and the i platform provided by IBM [9]. Energy-monitoring systems that operate only on certain processor architectures, such as ARM or MIPS, have also been reported [10,11].  
With the exception of Windows, which is not widely used in robot-embedded systems [12], most operating systems follow POSIX standards, but there have been no reports on general resource-monitoring systems that can be used with multiple operating systems and processors. The GWRMS reported in this paper consists only of components that can be used in operating systems conforming to POSIX standards, unlike previous research based on specific platforms with a limited range of operating-system choices.  
The GWRMS discussed in this paper supports status monitoring by supporting machine-learning through component parameters generated by the wearable robot, as well as resource monitoring supported by other systems.  
Table 1 compares the GWRMS with existing systems.  
The GWRMS is compatible with a wider range of operating systems than other approaches, and it uses basic TCP/IP communication to reduce network overhead as much as possible and minimise system overhead. Unlike Overseer or Robot Console, the GWRMS supports multiple platforms and is designed to use fewer resources. The GWRMS also has lower CPU and memory requirements tha  
\begin{table}
\begin{tabular}{c c c c c} \hline \hline  & **GWRMS** & **Overseer** & **Drums** & **Robot Console** \\ \hline
**Supported OS** & All POSIX based OS & ROS and Nagios & ROS & IBM i platform \\ \hline
**Visualisation** & WPF (Server) & Nagios Dashboard & Graphite & Unknown \\ \hline
**Server Type** & TCP/IP & Apache HTTP & HTTP & Unknown \\ \hline
**CPU Architecture** & Non-dependent & Non-dependent & Non-Dependent & Dependent \\ \hline \multirow{3}{*}{**Other**} & Extremely Lightweight & \multirow{3}{*}{Lightweight} & \multirow{3}{*}{Feature-rich} & Feature-rich \\  & Cross-platform & Module-based & & & Paid service \\ \hline \hline \end{tabular}
\end{table}
Table 1: Comparison between previous systems and the GWRMS.  
The GWRMS is not dependent on CPU architecture or operating system, so it can be used by many types of embedded system. In many cases, monitoring systems cannot be used because operating systems and underlying CPU architectures differ.  
Compared to Overseer, the GWRMS is not dependent on specific frameworks, such as ROS and Nagios, and it has low resource usage due to its use of simple programs that run on performance-constrained hardware. In comparison to Drums, the GWRMS has better support for embedded systems because Drums is also dependent on the ROS framework, as is Overseer.  
The GWRMS is also lighter because it uses TCP/IP, which is a core component of HTTP, rather than an HTTP server for communication. The overhead required for data visualisation is also smaller because the GWRMS does not implement cloud-server-based visualisation on embedded hardware, unlike previous systems.