Embedded Robotics (Thomas Braunl, 2 ed, 2006)
.pdf
Flight Program
Figure 11.3: EyeBox and multiplexer unit
11.3 Flight Program
There are two principal techniques for designing a flight program and user interface of the flight system, depending on the capabilities of the GPS unit used and the desired capability and flexibility of the flight system:
A.Small and lightweight embedded GPS module
(for example Rojone MicroGenius 3 [Rojone 2002])
Using a small embedded GPS module has clear advantages in model planes. However, all waypoint entries have to be performed directly to the EyeCon and the flight path has to be computed on the EyeCon controller.
B.Standard handheld GPS with screen and buttons (for example Magellan GPS 315 [Magellan 1999])
Standard handheld GPS systems are available at about the same cost as a GPS module, but with built-in LCD screen and input buttons. However, they are much heavier, require additional batteries, and suffer a higher risk of damage in a rough landing. Most handheld GPS systems support recording of waypoints and generation of routes, so the complete flight path can be generated on the handheld GPS without using the embedded controller in the plane. The GPS system also needs to support
155
11 Autonomous Planes
the NMEA 0183 (Nautical Marine Electronics Association) data message format V2.1 GSA, a certain ASCII data format that is output via the GPS’s RS232 interface. This format contains not only the current GPS position, but also the required steering angle for a previously entered route of GPS waypoints (originally designed for a boat’s autohelm). This way, the on-board controller only has to set the plane’s servos accordingly; all navigation is done by the GPS system.
Program 11.1 shows sample NMEA output. After the start-up sequence, we get regular code strings for position and time, but we only decode the lines starting with $GPGGA. In the beginning, the GPS has not yet logged on to a sufficient number of satellites, so it still reports the geographical position as 0 N and 0 E. The quality indicator in the sixth position (following “E”) is 0, so the coordinates are invalid. In the second part of Program 11.1, the $GPRMC string has quality indicator 1 and the proper coordinates of Western Australia.
Program 11.1: NMEA sample output
$TOW: |
0 |
|
$WK: |
1151 |
0 |
$POS: |
6378137 0 |
|
$CLK: |
96000 |
|
$CHNL:12
$Baud rate: 4800 System clock: 12.277MHz $HW Type: S2AR
$GPGGA,235948.000,0000.0000,N,00000.0000,E,0,00,50.0,0.0,M,,,,0000*3A $GPGSA,A,1,,,,,,,,,,,,,50.0,50.0,50.0*05 $GPRMC,235948.000,V,0000.0000,N,00000.0000,E,,,260102,,*12 $GPGGA,235948.999,0000.0000,N,00000.0000,E,0,00,50.0,0.0,M,,,,0000*33 $GPGSA,A,1,,,,,,,,,,,,,50.0,50.0,50.0*05 $GPRMC,235948.999,V,0000.0000,N,00000.0000,E,,,260102,,*1B $GPGGA,235949.999,0000.0000,N,00000.0000,E,0,00,50.0,0.0,M,,,,0000*32 $GPGSA,A,1,,,,,,,,,,,,,50.0,50.0,50.0*05
...
$GPRMC,071540.282,A,3152.6047,S,11554.2536,E,0.49,201.69,171202,,*11 $GPGGA,071541.282,3152.6044,S,11554.2536,E,1,04,5.5,3.7,M,,,,0000*19 $GPGSA,A,2,20,01,25,13,,,,,,,,,6.0,5.5,2.5*34 $GPRMC,071541.282,A,3152.6044,S,11554.2536,E,0.53,196.76,171202,,*1B $GPGGA,071542.282,3152.6046,S,11554.2535,E,1,04,5.5,3.2,M,,,,0000*1E $GPGSA,A,2,20,01,25,13,,,,,,,,,6.0,5.5,2.5*34 $GPRMC,071542.282,A,3152.6046,S,11554.2535,E,0.37,197.32,171202,,*1A $GPGGA,071543.282,3152.6050,S,11554.2534,E,1,04,5.5,3.3,M,,,,0000*18 $GPGSA,A,2,20,01,25,13,,,,,,,,,6.0,5.5,2.5*34 $GPGSV,3,1,10,01,67,190,42,20,62,128,42,13,45,270,41,04,38,228,*7B $GPGSV,3,2,10,11,38,008,,29,34,135,,27,18,339,,25,13,138,37*7F $GPGSV,3,3,10,22,10,095,,07,07,254,*76
In our current flight system we are using approach A, to be more flexible in flight path generation. For the first implementation, we are only switching the rudder between autopilot and remote control, not all of the plane’s surfaces.
156
Flight Program
Motor and elevator stay on remote control for safety reasons, while the ailerons are automatically operated by a gyroscope to eliminate any roll. Turns under autopilot therefore have to be completely flown using the rudder, which requires a much larger radius than turns using ailerons and elevator. The remaining control surfaces of the plane can be added step by step to the autopilot system.
The flight controller has to perform a number of tasks, which need to be accessible through its user interface:
Pre-flight
•Initialize and test all sensors, calibrate sensors.
•Initialize and test all servos,
enable setting of zero positions of servos, enable setting of maximum angles of servos.
•Perform waypoint download – (only for technique A).
In-flight (continuous loop)
•Generate desired heading – (only for technique A).
•Set plane servos according to desired heading.
•Record flight data from sensors.
Post-flight
•Perform flight data upload.
These tasks and settings can be activated by navigating through several flight system menus, as shown in Figure 11.4 [Hines 2001]. They can be displayed and operated through button presses either directly on the EyeCon or remotely via a serial link cable on a PDA (Personal Digital Assistant, for example Compaq IPAQ).
The link between the EyeCon and the PDA has been developed to be able to remote-control (via cable) the flight controller pre-flight and post-flight, especially to download waypoints before take-off and upload flight data after landing. All pre-start diagnostics, for example correct operation of all sensors or the satellite log-on of the GPS, are transmitted from the EyeCon to the handheld PDA screen.
After completion of the flight, all sensor data from the flight together with time stamps are uploaded from the EyeCon to the PDA and can be graphically displayed. Figure 11.5 [Purdie 2002] shows an example of an uploaded flight path ([x, y] coordinates from the GPS sensor); however, all other sensor data is being logged as well for post-flight analysis.
A desirable extension to this setup is the inclusion of wireless data transmission from the plane to the ground (see also Chapter 6). This would allow us to receive instantaneous data from the plane’s sensors and the controller’s status as opposed to doing a post-flight analysis. However, because of interfer-
157
11 Autonomous Planes
Figure 11.4: Flight system user interface
|
|
50.05 |
|
|
|
|
|
|
|
31S) |
|
Airstrip |
|
|
|
|
|
|
50.1 |
|
|
|
|
|
|
|
Latitude |
of |
|
|
|
|
|
|
|
(minutes south |
50.15 |
|
|
|
|
|
|
|
50.2 |
|
|
|
|
|
|
||
|
|
|
|
100m |
|
|||
|
|
|
|
|
|
|
||
|
|
50.25 |
|
|
|
|
|
|
|
|
55.4 |
55.45 |
55.5 |
55.55 |
55.6 |
55.65 |
55.7 |
Longitude (minutes east of 115E)
Figure 11.5: Flight path
ence problems with the other autopilot components, wireless data transmission has been left until a later stage of the project.
158
References
11.4 References
AEROSONDE, Global Robotic Observation System Aerosonde, http://www. aerosonde.com, 2006
AUVS, International Aerial Robotics Competition, Association for Unmanned
Vehicle Systems, |
http://avdil.gtri.gatech.edu/AUVS/ |
IARCLaunchPoint.html, 2006
HENNESSEY, G. The FireMite Project, http://www.craighennessey.com/ firemite/, May 2002
HINES, N. Autonomous Plane Project 2001 – Compass, GPS & Logging Subsystems, B.E. Honours Thesis, The Univ. of Western Australia, Electrical and Computer Eng., supervised by T. Bräunl and C. Croft, 2001
MAGELLAN, GPS 315/320 User Manual, Magellan Satellite Access Technology, San Dimas CA, 1999
MICROPILOT, MicroPilot UAV Autopilots, http://www.micropilot.com, 2006
PURDIE, J. Autonomous Flight Control for Radio Controlled Aircraft, B.E. Honours Thesis, The Univ. of Western Australia, Electrical and Computer Eng., supervised by T. Bräunl and C. Croft, 2002
ROJONE, MicroGenius 3 User Manual, Rojone Pty. Ltd. CD-ROM, Sydney Australia, 2002
159
AUTONOMOUS VESSELS 12
AND UNDERWATER VEHICLES
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. . The design of an autonomous vessel or underwater vehicle requires one
additional skill compared to the robot designs discussed previously: watertightness. This is a challenge especially for autonomous underwater vehicles (AUVs), as they have to cope with increasing water pressure
when diving and they require watertight connections to actuators and sensors outside the AUV’s hull. In this chapter, we will concentrate on AUVs, since autonomous vessels or boats can be seen as AUVs without the diving functionality.
The area of AUVs looks very promising to advance commercially, given the current boom of the resource industry combined with the immense cost of either manned or remotely operated underwater missions.
12.1 Application
Unlike many other areas of mobile robots, AUVs have an immediate application area conducting various sub-sea surveillance and manipulation tasks for the resource industry. In the following, we want to concentrate on intelligent control and not on general engineering tasks such as constructing AUVs that can go to great depths, as there are industrial ROV (remotely operated vehicle) solutions available that have solved these problems.
While most autonomous mobile robot applications can also use wireless communication to a host station, this is a lot harder for an AUV. Once submerged, none of the standard communication methods work; Bluetooth or WLAN only operate up to a water depth of about 50cm. The only wireless communication method available is sonar with a very low data rate, but unfortunately these systems have been designed for the open ocean and can usually not cope with signal reflections as they occur when using them in a pool. So unless some wire-bound communication method is used, AUV applications have to be truly autonomous.
161161
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