# Wireless Remote Control for Underwater Vehicles
## 3 Requirements and Definition of Working Modes for ROV Control
### Raw Data Streams Analysis  
The control station sends, on average, 4.5 kbps to BlueROV to control the vehicle's position through a joystick-based console as well as the sensors (lighting, cameras, and a small gripper) mounted on board the ROV. The maximum expected control bit rate is 5 kbps. For working-class ROVs, such as the Etain ROV owned by CRIS, the control stream requires higher traffic: a working-class ROV equipped with several sensors, cameras, as well as two heavy manipulators with 7 degrees of freedom each requires a control bit rate up to 100 kbps. BlueROV mounts an HD video camera with a maximum resolution of 1920 \(\times\) 1080 px at 30 fps, resulting in an average video bit rate of 11.5 Mbps. According to the results we presented in [61], the video bit rate depends on the number of details and items present on the frames and on the level of motion: in general, low-motion quasi-static videos require a lower bit rate than a dynamic video with fast movements, and a video representing only one simple object with a white background requires a lower bit rate than a video showing lots of complex objects and many people with a background composed of mountains, trees, and lakes. For this reason, in the subsea raw video sample considered in [61], the maximum bit rate is related to the moment when the ROV performs quick movements in an environment with complex details. The peak bit rate is 24 Mbps, while the average video bit rate is 16.5 Mbps. In a real-time video transmission, in order to avoid the video buffering and causing an undesired delay, we must consider the maximum video bit rate as the bit rate to be transmitted. Maintaining the same proportion obtained in [61], given that BlueROV streams a video with an average bit rate of 11.5 Mbp, we expect a maximum bit rate of 16.5 Mbps. In addition to video streams, the ROV needs to also send information about its status, its estimated position, and the status of its manipulator and of each of its sensors to the control station. In general, the traffic requirements for monitoring feedback depend on the types of sensors installed in the ROV and vary from few tens of bits per sensor (such as CTD, turbidity sensors [110], and single beam sonars) up to a few megabits per second, such as the monitoring control required by a 3D laser imaging system [2], the bathymetry data collected from a multibeam sonar [111], or the video feedback from a heavy manipulator for working-class ROVs. An inspection-class ROV usually mounts small and light sensors with low rate requirements, as more sophisticated tools are often quite heavy (e.g., multibeam sonars) or require carrying by working-class ROVs able to maintain a very stable position and move with very high accuracy (e.g., 3D scanners). In this work, we consider a periodic monitoring traffic, where the ROV sends information about its position, speed, and rotation angles as well as a compressed code-word representing the overall status of each component of the system to the control station. Given the resolution of the positioning sensors, the fact that the maximum operational range of our system is below 12 km and the fact that the maximum speed of most underwater vehicles is less than 4 m/s, we assume that each component of position (x, y, and depth), speed (u, v, and w), and rotation angles (roll, pitch, and yaw) requires 3 bytes of information. The status code word requires 2 bits per component to indicate whether a certain tool is, for instance, disabled, enabled, working under a warning condition, or disabled due to damages. By considering a total number of components equal to 16, the code word requires 4 bytes in total. The monitoring information also includes the last value measured by conductivity, pressure, temperature, turbidity, and pollution sensors. Considering 3 bytes of data for each sensor and a timestamp of 4 bytes, the size of the monitoring packet is therefore equal to 56 bytes, while considering a monitoring traffic period of 6 s, the monitoring traffic rate is 75 bps.