Differences between the physical systems and Digital Twin

When building the Digital Twin using the AGX software, we could not recreate the instability we experienced with the physical ROV. This is because of the limitations of the AGX software. AGX does not consider the physics of flow2.12.4and turbulence2.12.1.2in its calculation3.5.2.5[6].

Therefore turbulence and laminar flow does not affect the simulation in the same way it affects the physical ROV.

During the testing of the physical ROV, we found that the system’s stability regarding pitch was relatively low. Especially in the earlier sea trails before we added the tail (see5.11.2,5.11.4and 5.11.4). In addition, the wing’s ability to control the depth of the ROV was relatively limited.

When simulating the system, the stability of the ROV seemed to be completely different com-pared to that of the physical system as seen in5.25and5.44.

This is because of how hydrodynamics is calculated in the physics simulation. When AGX Dy-namics calculates hydrodyDy-namics, it considers the effect of water as a constant field. The dis-turbances caused by the ROV on the water are not considered [6].

This means that the AGX Dynamics simulation cannot calculate any turbulence and other dis-turbing forces. Therefore, it is important to build a ROV body that minimises turbulence if the simulation is to be accurate. By having sharp edges and edges perpendicular to the towing di-rection, the drag and turbulence of the ROV are increased2.12.1, so these should be minimised to make the simulation more accurate and make the ROV perform better.

The original version of the ROV had large perpendicular angles relative to the towed direction and had sharp edges. These sharp edges and large surfaces will cause Vortex sheering behind the ROV2.12.1.2, which might be what caused the instability of the physical systems.

Because of these reasons, it might be advantageous to instead use a simulation software more suited to this kind of simulation.

6.1.6 Communication

To retrieve the camera feed from the ROV, we used a TCP server/client pattern that worked quite well. Since we wanted to save the images from the ROV, we did not want to create validation checks before saving the image to the database. Therefore we used TCP from the start, which allowed for a reliable transfer of images without any problems. As we tested various resolution, we found that 640x480 pixels were enough to see what was going on. The bandwidth using this resolution was approximately 10-15% of the 74.6 Mbits/s network bandwidth (from Figure

5.3.1), which allows for more sensor data to be sent from the ROV. The FPS difference between using TCP and UDP was identical, capping on around 30 FPS. The camera TCP server in the ROV allowed only one connection by the TCP client in the REST-API. Whenever a sudden crash hap-pened due to unforeseen actions, the TCP server just discarded the current client and allowed new camera TCP clients to connect without crashing.

As we planned the project initially, we started using ZMQ, which we slowly scaled and devel-oped into the software system for handling communication between the REST-API and the three entities: Surface Unit, ROV and the Sonar API. As most of the data was coming from the ZMQ Publishers to ZMQ Subscribers inside the REST-API, we could easily collect the data through multiprocessing queues that worked quite well. When allowing the sensor data publishing fre-quency to freewheel from the ROV, various problems occurred, which was the primary explana-tion for predefining the publishing frequency on the various systems.

Another positive contribution of using ZMQ is its popularity and reputation. Creating a software system that relies on this protocol has turned out to work without any significant problems. By not trying to reinvent the wheel by creating our implementation of low-level TCP servers and clients, we based our implementations on top of ZMQ. This measure allowed the group to focus on the actual functionality of the software systems.

6.1.7 Camera and lights

From the result (Section5.9) of the camera test at Runde, we can assume that an adjusted focus for this depth will provide a good photo of the seafloor with enough lighting. Daylight is essen-tial. The lack of daylight is clearly shown when the camera is tested at night in Voldsdalsvågen Marina. Even though the lights are at full brightness, the length of vision is not as far as in day-light at lower brightness. In total, the day-lights should be enough for getting decent images as long as the daylight gives a considerable amount of light.

For the camera, on the other hand, we are not so sure that it is sufficient enough. We take out the factor of the quality that all image is out of focus. At the night test, the camera does not

perform any better than our own eyes. Therefore we do not believe that the camera is suited for the greater depths, where the amount of daylight is reduced. On the other hand, for this project, future groups should be able to cope with the quality of the current camera.