ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 13.06.2025
Просмотров: 4215
Скачиваний: 0
12 Autonomous Vessels and Underwater Vehicles
AUV Competition The Association for Unmanned Vehicles International (AUVSI) organizes annual competitions for autonomous aerial vehicles and for autonomous underwater vehicles [AUVSI 2006]. Unfortunately, the tasks are very demanding, so it is difficult for new research groups to enter. Therefore, we decided to develop a set of simplified tasks, which could be used for a regional or entrylevel AUV competition (Figure 12.1).
We further developed the AUV simulation system SubSim (see Section 13.6), which allows to design AUVs and implement control programs for the individual tasks without having to build a physical AUV. This simulation system could serve as the platform for a simulation track of an AUV competition.
Figure 12.1: AUV competition tasks
The four suggested tasks to be completed in an olympic size swimming pool are:
1.Wall Following
The AUV is placed close to a corner of the pool and has to follow the pool wall without touching it. The AUV should perform one lap around the pool, return to the starting position, then stop.
2.Pipeline Following
A plastic pipe is placed along the bottom of the pool, starting on one side of the pool and terminating on the opposite side. The pipe is made out of straight pieces and 90 degree angles.
The AUV is placed over the start of the pipe on one side of the pool and has to follow the pipe on the ground until the opposite wall has been reached.
162
Dynamic Model
3.Target Finding
The AUV has to locate a target plate with a distinctive texture that is placed at a random position within a 3m diameter from the center of the pool.
4.Object Mapping
A number of simple objects (balls or boxes of distinctive color) are placed at the bottom of the pool, distributed over the whole pool area. The AUV has to survey the whole pool area, e.g. by diving along a sweeping pattern, and record all objects found at the bottom of the pool. Finally, the AUV has to return to its start corner and upload the coordinates of all objects found.
12.2Dynamic Model
The dynamic model of an AUV describes the AUV’s motions as a result of its shape, mass distribution, forces/torques exerted by the AUV’s motors, and external forces/torques (e.g. ocean currents). Since we are operating at relatively low speeds, we can disregarding the Coriolis force and present a simplified dynamic model [Gonzalez 2004]:
M v· D v v G W
with:
M mass and inertia matrix
v linear and angular velocity vector D hydrodynamic damping matrix
G gravitational and buoyancy vector
Wforce and torque vector (AUV motors and eternal forces/torques)
D can be further simplified as a diagonal matrix with zero entries for y (AUV can only move forward/backward along x, and dive/surface along z, but not move sideways), and zero entries for rotations about x and y (AUV can actively rotate only about z, while its self-righting movement, see Section 12.3, greatly eliminates rotations about x and y).
G is non-zero only in its z component, which is the sum of the AUV’s gravity and buoyancy vectors.
W is the product of the force vector combining all of an AUV’s motors, with a pose matrix that defines each motor’s position and orientation based on the AUV’s local coordinate system.
12.3 AUV Design Mako
The Mako (Figure 12.2) was designed from scratch as a dual PVC hull containing all electronics and batteries, linked by an aluminum frame and propelled by 4 trolling motors, 2 of which are for active diving. The advantages of this design over competing proposals are [Bräunl et al. 2004], [Gonzalez 2004]:
163
12 Autonomous Vessels and Underwater Vehicles
Figure 12.2: Autonomous submarine Mako
•Ease in machining and construction due to its simple structure
•Relative ease in ensuring watertight integrity because of the lack of rotating mechanical devices such as bow planes and rudders
•Substantial internal space owing to the existence of two hulls
•High modularity due to the relative ease with which components can be attached to the skeletal frame
•Cost-effectiveness because of the availability and use of common materials and components
•Relative ease in software control implementation when compared to using a ballast tank and single thruster system
•Ease in submerging with two vertical thrusters
•Static stability due to the separation of the centers of mass and buoyancy, and dynamic stability due to the alignment of thrusters
Simplicity and modularity were key goals in both the mechanical and electrical system designs. With the vehicle not intended for use below 5m depth, pressure did not pose a major problem. The Mako AUV measures 1.34 m long, 64.5 cm wide and 46 cm tall.
The vehicle comprises two watertight PVC hulls mounted to a supporting aluminum skeletal frame. Two thrusters are mounted on the port and starboard sides of the vehicle for longitudinal movement, while two others are mounted vertically on the bow and stern for depth control. The Mako’s vertical thruster diving system is not power conservative, however, when a comparison is made with ballast systems that involve complex mechanical devices, the advantages such as precision and simplicity that comes with using these two thrusters far outweighs those of a ballast system.
164
AUV Design Mako
Figure 12.3: Mako design
Propulsion is provided by four modified 12V, 7A trolling motors that allow horizontal and vertical movement of the vehicle. These motors were chosen for their small size and the fact that they are intended for underwater use; a feature that minimized construction complexity substantially and provided watertight integrity.
Figure 12.4: Electronics and controller setup inside Mako’s top hull
165
12 Autonomous Vessels and Underwater Vehicles
The starboard and port motors provide both forward and reverse movement while the stern and bow motors provide depth control in both downward and upward directions. Roll is passively controlled by the vehicle’s innate righting moment (Figure 12.5). The top hull contains mostly air besides light electronics equipment, the bottom hull contains heavy batteries. Therefore mainly a buoyancy force pulls the top cylinder up and gravity pulls the bottom cylinder down. If for whatever reason, the AUV rolls as in Figure 12.5, right, these two forces ensure that the AUV will right itself.
Overall, this provides the vehicle with 4DOF that can be actively controlled. These 4DOF provide an ample range of motion suited to accomplishing a wide range of tasks.
Buoyancy
Gravity
Figure 12.5: Self-righting moment of AUV
Controllers The control system of the Mako is separated into two controllers; an EyeBot microcontroller and a mini-PC. The EyeBot’s purpose is controlling the AUV’s movement through its four thrusters and its sensors. It can run a completely autonomous mission without the secondary controller. The mini PC is a Cyrix 233MHz processor, 32Mb of RAM and a 5GB hard drive, running Linux. Its sole function is to provide processing power for the computationally intensive vision system.
Motor controllers designed and built specifically for the thrusters provide both speed and direction control. Each motor controller interfaces with the EyeBot controller via two servo ports. Due to the high current used by the thrusters, each motor controller produces a large amount of heat. To keep the temperature inside the hull from rising too high and damaging electronic components, a heat sink attached to the motor controller circuit on the outer hull was devised. Hence, the water continuously cools the heat sink and allows the temperature inside the hull to remain at an acceptable level.
Sensors The sonar/navigation system utilizes an array of Navman Depth2100 echo sounders, operating at 200 kHz. One of these sensors is facing down and thereby providing an effective depth sensor (assuming the pool depth is known), while the other three sensors are used as distance sensors pointing forward, left, and right. An auxiliary control board, based on a PIC controller, has been designed to multiplex the four sonars and connect to the EyeBot [Alfirevich 2005].
166
AUV Design USAL
Figure 12.6: Mako in operation
A low-cost Vector 2X digital magnetic compass module provides for yaw or heading control. A simple dual water detector circuit connected to ana- logue-to-digital converter (ADC) channels on the EyeBot controller is used to detect a possible hull breach. Two probes run along the bottom of each hull, which allows for the location (upper or lower hull) of the leak to be known. The EyeBot periodically monitors whether or not the hull integrity of the vehicle has been compromised, and if so immediately surfaces the vehicle. Another ADC input of the EyeBot is used for a power monitor that will ensure that the system voltage remains at an acceptable level. Figure 12.6 shows the Mako in operation.
12.4 AUV Design USAL
The USAL AUV uses a commercial ROV as a basis, which was heavily modified and extended (Figure 12.7). All original electronics were taken out and replaced by an EyeBot controller (Figure 12.8). The hull was split and extended by a trolling motor for active diving, which allows the AUV to hover, while the original ROV had to use active rudder control during a forward motion for diving, [Gerl 2006], [Drtil 2006]. Figure 12.8 shows USAL’s complete electronics subsystem.
For simplicity and cost reasons, we decided to trial infrared PSD sensors (see Section 2.6) for the USAL instead of the echo sounders used on the Mako. Since the front part of the hull was made out of clear perspex, we were able to place the PSD sensors inside the AUV hull, so we did not have to worry about waterproofing sensors and cabling. Figure 12.9 shows the results of measurements conducted in [Drtil 2006], using this sensor setup in air (through the hull), and in different grades of water quality. Assuming good water quality, as can be expected in a swimming pool, the sensor setup returns reliable results up to a distance of about 1.1 m, which is sufficient for using it as a collision avoidance sensor, but too short for using it as a navigation aid in a large pool.
167
12 Autonomous Vessels and Underwater Vehicles
Figure 12.7: Autonomous submarine USAL
Figure 12.8: USAL controller and sensor subsystem
Figure 12.9: Underwater PSD measurement
168
AUV Design USAL
The USAL system overview is shown in Figure 12.10. Numerous sensors are connected to the EyeBot on-board controller. These include a digital camera, four analog PSD infrared distance sensors, a digital compass, a three-axes solid state accelerometer and a depth pressure sensor. The Bluetooth wireless communication system can only be used when the AUV has surfaced or is diving close to the surface. The energy control subsystem contains voltage regulators and level converters, additional voltage and leakage sensors, as well as motor drivers for the stern main driving motor, the rudder servo, the diving trolling motor, and the bow thruster pump.
Figure 12.10: USAL system overview
Figure 12.11 shows the arrangement of the three thrusters and the stern rudder, together with a typical turning movement of the USAL.
Figure 12.11: USAL thrusters and typical rudder turning maneuver
169
12 Autonomous Vessels and Underwater Vehicles
12.5 References
ALFIREVICH, E. Depth and Position Sensing for an Autonomous Underwater Vehicle, B.E. Honours Thesis, The Univ. of Western Australia, Electrical and Computer Eng., supervised by T. Bräunl, 2005
AUVSI, AUVSI and ONR's 9th International Autonomous Underwater Vehicle Competition, Association for Unmanned Vehicle Systems Internation-
al, http://www.auvsi.org/competitions/water.cfm, 2006
BRÄUNL, T., BOEING, A., GONZALES, L., KOESTLER, A., NGUYEN, M., PETITT,
J. The Autonomous Underwater Vehicle Initiative – Project Mako, 2004 IEEE Conference on Robotics, Automation, and Mechatronics (IEEE-RAM), Dec. 2004, Singapore, pp. 446-451 (6)
DRTIL, M. Electronics and Sensor Design of an Autonomous Underwater Vehicle, Diploma Thesis, The Univ. of Western Australia and FH Koblenz, Electrical and Computer Eng., supervised by T. Bräunl, 2006
GERL, B. Development of an Autonomous Underwater Vehicle in an Interdisciplinary Context, Diploma Thesis, The Univ. of Western Australia and Technical Univ. München, Electrical and Computer Eng., supervised by T. Bräunl, 2006
GONZALEZ, L. Design, Modelling and Control of an Autonomous Underwater Vehicle, B.E. Honours Thesis, The Univ. of Western Australia, Electrical and Computer Eng., supervised by T. Bräunl, 2004
170
SIMULATION SYSTEMS 13
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. . imulation is an essential part of robotics, whether for stationary manip-
Sulators, mobile robots, or for complete manufacturing processes in factory automation. We have developed a number of robot simulation sys-
tems over the years, two of which will be presented in this Chapter.
EyeSim is a simulation system for multiple interacting mobile robots. Environment modeling is 2½D, while 3D sceneries are generated with synthetic images for each robot’s camera view of the scene. Robot application programs are compiled into dynamic link libraries that are loaded by the simulator. The system integrates the robot console with text and color graphics, sensors, and actuators at the level of a velocity/position control (vZ) driving interface.
SubSim is a simulation system for autonomous underwater vehicles (AUVs) and contains a complete 3D physics simulation library for rigid body systems and water dynamics. It conducts simulation at a much lower level than the driving simulator EyeSim. SubSim requires a significantly higher computational cost, but is able to simulate any user-defined AUV. This means that motor number and positions, as well as sensor number and positions can be freely chosen in an XML description file, and the physics simulation engine will calculate the correct resulting AUV motion.
Both simulation systems are freely available over the Internet and can be downloaded from:
http://robotics.ee.uwa.edu.au/eyebot/ftp/ (EyeSim) http://robotics.ee.uwa.edu.au/auv/ftp/ (SubSim)
13.1 Mobile Robot Simulation
Simulators can be on different levels
Quite a number of mobile robot simulators have been developed in recent years, many of them being available as freeware or shareware. The level of simulation differs considerably between simulators. Some of them operate at a very high level and let the user specify robot behaviors or plans. Others operate at a very low level and can be used to examine the exact path trajectory driven by a robot.
171171
13 Simulation Systems
We developed the first mobile robot simulation system employing synthetic vision as a feedback sensor in 1996, published in [Bräunl, Stolz 1997]. This system was limited to a single robot with on-board vision system and required the use of special rendering hardware.
Both simulation systems presented below have the capability of using generated synthetic images as feedback for robot control programs. This is a significant achievement, since it allows the simulation of high-level robot application programs including image processing. While EyeSim is a multi-robot simulation system, SubSim is currently limited to a single AUV.
Most other mobile robot simulation systems, for example Saphira [Konolige 2001] or 3D7 [Trieb 1996], are limited to simpler sensors such as sonar, infrared, or laser sensors, and cannot deal with vision systems. [Matsumoto et al. 1999] implemented a vision simulation system very similar to our earlier system [Bräunl, Stolz 1997]. The Webots simulation environment [Wang, Tan, Prahlad 2000] models among others the Khepera mobile robot, but has only limited vision capabilities. An interesting outlook for vision simulation in motion planning for virtual humans is given by [Kuffner, Latombe 1999].
13.2 EyeSim Simulation System
All EyeBot programs run on EyeSim
The goal of the EyeSim simulator was to develop a tool which allows the construction of simulated robot environments and the testing of mobile robot programs before they are used on real robots. A simulation environment like this is especially useful for the programming techniques of neural networks and genetic algorithms. These have to gather large amounts of training data, which is sometimes difficult to obtain from actual vehicle runs. Potentially harmful collisions, for example due to untrained neural networks or errors, are not a concern in the simulation environment. Also, the simulation can be executed in a “perfect” environment with no sensor or actuator errors – or with certain error levels for individual sensors. This allows us to thoroughly test a robot application program’s robustness in a near real-word scenario [Bräunl, Koestler, Waggershauser 2005], [Koestler, Bräunl 2004].
The simulation library has the same interface as the RoBIOS library (see Appendix B.5). This allows the creation of robot application programs for either real robots or simulation, simply by re-compiling. No changes at all are required in the application program when moving between the real robot and simulation or vice versa.
The technique we used for implementing this simulation differs from most existing robot simulation systems, which run the simulation as a separate program or process that communicates with the application by some message passing scheme. Instead, we implemented the whole simulator as a collection of system library functions which replace the sensor/actuator functions called from a robot application program. The simulator has an independent main-pro- gram, while application programs are compiled into dynamic link-libraries and are linked at run-time.
172
EyeSim Simulation System
Real World
link at compile-time
robot |
interface |
||
applic. |
RoBIOS |
||
program |
library |
||
(user) |
stubs |
||
Simulationlink at run-time
robot |
interface |
||
applic. |
EyeSim |
||
program |
|||
(user) |
|||
EyeBot
load at run-time parameter file
environment file
Multi-Robot Simulation
link at run-time |
create threads at run-time |
||||||||||||
robot |
interface |
||||||||||||
robot |
|||||||||||||
applic. |
interface |
EyeSim |
|||||||||||
robot |
parameter file |
||||||||||||
program |
|||||||||||||
applic. |
interface |
||||||||||||
(user)program |
|||||||||||||
applic. |
|||||||||||||
(user)program |
|||||||||||||
(user) |
environment file |
||||||||||||
Figure 13.1: System concept
As shown in Figure 13.1 (top), a robot application program is compiled and linked to the RoBIOS library, in order to be executed on a real robot system. The application program makes system calls to individual RoBIOS library functions, for example for activating driving motors or reading sensor input. In the simulation scenario, shown in Figure 13.1 (middle), the compiled application library is now linked to the EyeSim simulator instead. The library part of the simulator implements exactly the same functions, but now activates the screen displays of robot console and robot driving environment.
In case of a multi-robot simulation (Figure 13.1 bottom), the compilation and linking process is identical to the single-robot simulation. However, at run-time, individual threads are created to simulate each of the robots concurrently. Each thread executes the robot application program individually on local data, but all threads share the common environment through which they interact.
The EyeSim user interface is split into two parts, a robot console per simulated robot and a common driving environment (Figure 13.2). The robot console models the EyeBot controller, which comprises a display and input buttons as a robot user interface. It allows direct interaction with the robot by pressing buttons and printing status messages, data values, or graphics on the screen. In the simulation environment, each robot has an individual console, while they all share the driving environment. This is displayed as a 3D view of the robot driving area. The simulator has been implemented using the OpenGL version Coin3D [Coin3D 2006], which allows panning, rotating, and zooming in 3D with familiar controls. Robot models may be supplied as Milkshape MS3D files [Milkshape 2006]. This allows the use of arbitrary 3D models of a
173