## 4 Results
### Threshold-Based--Experimental Results
#### 4.1.1 Sorting Results  
Two primary testable setups, designated CS1 and CS2, were developed in this preliminary sorting study employing the given surface. Both of the proposed experiments are displayed in Figure 6. Specifically, Figure 5(a) introduces CS1, where the two packages with different _AprilTags_, i.e., Box A (white box) with ID = 1 and Box B (red box) with ID = 0, are, respectively, meant to pass straight on, or to be sorted to the left. In the figure, only the red package, Box B, is reported, but the different coloured arrows indicate the intended paths of the two boxes: red arrow = Box B (red), white arrow = Box A (white). The same applies to Figure 5(b), illustrating CS2, where only Box A (white) is depicted, but both arrows are shown. In CS2 (Figure 5(b)), both packages are meant to be sorted, but at different stages along the line of modules: Box B is sorted early, while Box A is sorted afterward. The control mechanism used to apply these types of sorting works as follows: The camera, operating at its own frequency (59.6 fps), sends the captured frames to _Matlab_. For each frame, a region of interest (ROI: blue square in Figure 6) located after the starting position of the package and before the actuating modules is analyzed in _Matlab_. In this ROI, _Matlab_ continuously looks for a tag using the _ReadAprilTag_ function. The signal (an integer) to be delivered via the serial port to _Arduino_, which will activate the preset modules for the intended task, is decided by the tag's ID if one is available. Specifically, for CS1, with ID = 0  
Figure 5: Feedback loop scheme. Figure 6: Sorting objective for the two types of boxes during CS1 (**a**) and during CS2 (**b**). (Box B), the modules are all oriented with axes at 135\({}^{\circ}\), while with ID = 1 (Box A), they are at 90\({}^{\circ}\). In the case of CS2, with ID = 0 (Box B), the modules are all oriented with axes at 135\({}^{\circ}\), whereas with ID = 1 (Box A), only the last 6 modules (the last 3 columns on the right side in Figure 6) along the line are oriented at 135\({}^{\circ}\). These angular values define the rotor axis's orientation from this point on. Measurements are made counterclockwise, beginning with the \(x\) axis in Figure 6. In addition to the box types, the following tests with the surface setup have the mass of the box (m = 7.5 kg) and the surface inclination (\(\gamma\) = 8\({}^{\circ}\)) as input conditions. To evaluate the system's response readiness, even with packages already in motion, an ROI that lies halfway between the initial location and the modules was selected. As supplementary data, Table 1 shows the timing of the different recognition and actuation phases. As illustrated in Figure 4, the reaction times obtained depend on the stated system, its connections, and communication. More in detail, in Table 1, the following terms are reported: **tm1** is the time _Matlab_ requires to access a frame from the camera, i.e., the time needed to take a picture using the _Matlab_ function _getsnapshot_. **tm2** is the time required for **tm1** plus the image processing time, which includes correcting image distortions (using the _undistorImage_ function), cropping the ROI (using the _incorop_ function), and detecting and reading the tag (using the _readAprilTag_ function). **tm3** is the time taken to send an integer value from _Matlab_ to _Arduino_ via the serial port and receive a response (also an integer via the same port) after executing the actuation command. The response from _Arduino_ is not necessary, but it was used to estimate the actuation time. Finally, **tm4** describes the total time that elapses from immediately before the image is captured to the moment _Matlab_ receives the actuation response from _Arduino_. This is not precisely the total of the earlier times since it contains extra values associated with the code and, in particular, the _tic_ and _toc_ functions that _Matlab_ uses to estimate the timings.