||During the underwater vehicle R&D process, a crucial task in the beginning phase is to decide the specifications of sensors and actuators. The designers need to make decisions if an off-the-shelf product will meet the requirement, or more efforts should be devoted to the development of a component. The communication format undertaken between the controller and the subsystems is another important design issue worth of close attention. Once these specifications are settled, it will be very troublesome to change them afterwards in case a design flaw is discovered. It will be even worse if the problems are found after the prototype vehicle is constructed. In order to ensure the flexibility and shorten the development time, this paper proposes an architecture for general-purpose low level controller suitable for underwater vehicles. |
We suggest using the idea of “tiers” to construct a vehicle controller with multiple layers. Generally speaking, there are many different paths of information flow in a vehicle control system. It can be high-level tier and abstractive intention of the human operator interpreted by the man-machine interface; or the mid-level tier control commands to maneuver the vehicle to a specific direction; down to the low -level tier as the raw commands fed to the thrusters. The performance and the reliability of the system deeply depend on the flow of these information and commands. High- and mid-level tiers information can be modeled mathematically, but the low-level tier is product-dependent. In other words, once a new sensor or actuator is installed, the control software related to these components need to be revised accordingly. The modification of the software might exist at multiple places if the structure is not organized as tiers. In order to maintain full flexibility of the vehicle controller structure throughout the R&D period, the high- and mid-level will be implemented in the man-machine interface for ROV case, and in the mission planner in the AUV case. The low-level tier is implemented in the onboard computer. The onboard low-level controller covers a variety of communication format of physical ports, such as serial line, D/A, A/D, D/IO and PWM. Port setting parameters, such baud-rate or DA range, can be specified remotely on the surface. The physical connecting ports of the sensors can be changed freely without rewiring or reprogramming.
Taking the stability of the controller as the top priority, we used DOS operating system as the platform to implement our concepts. DOS has been in the market for more than two decades, but it has the merits of fast in booting, highly stable, efficient in computation. We use its timer interrupt service INT 0X1C to construct a realtime thread to poll the readiness of sensory channels, and uploads the data to the surface via a channel-driven packet. The packets delivered to the surface are split into channels and reconstructed back to their original raw data format. The other necessary service routines, such as DA, AD and DIO, are also embedded inside this thread for its promptitude.
We constructed an experimental platform with this low-level controller to verify if the vehicle alitude control can be accurate enough as the carrier of the Seafloor Laser Scanner developed by our lab. Prior to the experiments, issues, such as whether the bouyancy of the system is pro or con for driving the vechile, were studied with Simulink. The poorness of altitude control caused by the deadzone effect of the thruster failed to be duplicated as in the simulation, while the alitude control gave a tracking error within ± 5cm.