## 4 Applying the CM Framework to a Case Study  
The CM framework presented above in this section was adapted to a case study using the Omron TM5-900 cobot, manufactured by Techman Robot Inc. Taiwan, and marketed by Omron Corp., Kyoto, Japan (Figure 6). Cobot specification is listed in Table 1. The motion commands to the cobot can be sent using a Programmable Logic Controller (PLC) or through the Python API motion library available in the Omron TM robots ROS package [3]. Giving too much detailed information regarding how to define motion commands using ROS and a trajectory planners library is out of the scope of this work; however, detailed information can be found in the GitHub read me file regarding the usage of our repository. As a case study, we proposed to test the presented CM architecture in a palletizing application scenario using the Omron TM5-900 cobot. The program running on the cobot is a working cycle that comprises different motion commands to send the cobot to pick objects in a certain location and place them by filling a hypothetical pallet (in Figure 7, it is possible to see a schematic view of this application). In this program, the cobot starts from a \begin{table}
\begin{tabular}{c c} \hline \hline
**Field** & **Data** \\ \hline Reach (mm) & 900 \\ Maximum payload (Kg) & 4 \\ Typical speed (m/s) & 1.4 \\ Angle of the joint 1, 6 (degree) & \(\pm\)270 \\ Angle of the joint 2, 4, 5 (degree) & \(\pm\)180 \\ Angle of the joint 3 (degree) & \(\pm\)155 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Specifications of collaborative manipulator TM5-900. Figure 6: Image of the Omron TM5-900 collaborative robot used for the case study. home position and reaches a \"Target1\" position. Then, it goes down vertically (TCP \(z\) axis) to grab the object and up to the previous position. From \"Target1\", the cobot moves to a second target position \"Target2\" and places the object in a certain pallet location repeating the sequence to build the pallet with a certain number of objects defined by the user. This application can be considered quite a standard in industrial scenarios and is interesting to study since we have different motion commands, positions, and load conditions that require defining a precise strategy to automatically detect faults in the data. The only assumption used under the testing phase is to palletize objects of approximately the same weight, picked every time in the same position. The robot states that we collect to monitor cobot conditions are the following, proceeded by the labels defined in Section 3.3:  
1. Joint torques;
2. Joint positions;
3. Joint speeds. The joint positions and speeds are collected to check whether the joint movements are correct, while the joint torques are used to monitor the system conditions. Using the proposed ROS-based CM architecture, we send motion commands to execute the program while collecting controller data to monitor cobot states. Figure 8 shows a simplification of the whole interaction between ROS nodes. The graph algebra used is based on the rqt tool which is helpful to obtain a visual representation of the ROS nodes' interactions. The nodes are circled, while inside the rectangle is specified on the top the nodes name with relative topics or services. In this schematic figure, not all the nodes running are shown, as indeed the secondary nodes are omitted because these are not relevant to understanding the application. However, using the function on the terminal \"\(rqtgraph\)\" (while the entire program is running), it is possible to visualize the representation of the entire connections. Figure 7: Schematic view of a basic palletizing application with the relative coordinating system on the top right of image (**a**). Image (**b**) shows the program workflow executed. The \"Omron TM driver\" node is the one responsible for managing the communication between the controller and the Linux system in which the ROS master is running (a schematic view of the connection was represented in Figure 1).