Файл: Embedded Robotics (Thomas Braunl, 2 ed, 2006).pdf

11 Autonomous Planes

A

4

Controller 5 5

GPS Receiver

B

Controller Receiver

GPS

Figure 11.1: System design options

A.The embedded controller drives the plane’s servos at all times. It receives sensor input as well as input from the ground transmitter.

B.A central (and remote controlled) multiplexer switches between ground transmitter control and autopilot control of the plane’s servos.

Design option A is the simpler and more direct solution. The controller reads data from its sensors including the GPS and the plane’s receiver. Ground control can switch between autopilot and manual operation by a separate channel. The controller is at all times connected to the plane’s servos and generates their PWM control signals. However, when in manual mode, the controller reads the receiver’s servo output and regenerates identical signals.

Design option B requires a four-way multiplexer as an additional hardware component. (Design A has a similar multiplexer implemented in software.) The multiplexer connects either the controller’s four servo outputs or the receiver’s four servo outputs to the plane’s servos. A special receiver channel is used for toggling the multiplexer state under remote control.

Although design A is the superior solution in principle, it requires that the controller operates with highest reliability. Any fault in either controller hardware or controller software, for example the “hanging” of an application pro-

152

Application

gram, will lead to the immediate loss of all control surfaces and therefore the loss of the plane. For this reason we opted to implement design B. Although it requires a custom-built multiplexer as additional hardware, this is a rather simple electro-magnetic device that can be directly operated via remote control and is not subject to possible software faults.

Figure 11.2: Autonomous model plane during construction and in flight

Figure 11.2 shows photos of the construction and during flight of our first autonomous plane. This plane had the EyeCon controller and the multiplexer unit mounted on opposite sides of the fuselage.

153

11 Autonomous Planes

11.2 Control System and Sensors

An EyeCon system is used as on-board flight controller. Before take-off, GPS waypoints for the desired flight path are downloaded to the controller. After the landing, flight data from all on-board sensors is uploaded, similar to the

Black box operation of a “black box” data recorder on a real plane.

The EyeCon’s timing processor outputs generate PWM signals that can directly drive servos. In this application, they are one set of inputs for the multiplexer, while the second set of inputs comes from the plane’s receiver. Two serial ports are used on the EyeCon, one for upload/download of data and programs, and one for continuous GPS data input.

Although the GPS is the main sensor for autonomous flight, it is insufficient because it delivers a very slow update of 0.5Hz .. 1.0Hz and it cannot determine the plane’s orientation. We are therefore experimenting with a number of additional sensors (see Chapter 2 for details of these sensors):

•Digital compass

Although the GPS gives directional data, its update rates are insufficient when flying in a curve around a waypoint.

•Piezo gyroscope and inclinometer

Gyroscopes give the rate of change, while inclinometers return the absolute orientation. The combined use of both sensor types helps reduce the problems with each individual sensor.

•Altimeter and air-speed sensor

Both altimeter and air-speed sensor have been built by using air pressure sensors. These sensors need to be calibrated for different heights and temperatures. The construction of an air-speed sensor requires the combination of two sensors measuring the air pressure at the wing tip with a so-called “Pitot tube”, and comparing the result with a third air pressure sensor inside the fuselage, which can double as a height sensor.

Figure 11.3 shows the “EyeBox”, which contains most equipment required for autonomous flight, EyeCon controller, multiplexer unit, and rechargeable battery, but none of the sensors. The box itself is an important component, since it is made out of lead-alloy and is required to shield the plane’s receiver from any radiation from either the controller or the multiplexer. Since the standard radio control carrier frequency of 35MHz is in the same range as the EyeCon’s operating speed, shielding is essential.

Another consequence of the decision for design B is that the plane has to remain within remote control range. If the plane was to leave this range, unpredictable switching between the multiplexer inputs would occur, switching control of the plane back and forth between the correct autopilot settings and noise signals. A similar problem would exist for design A as well; however, the controller could use plausibility checks to distinguish noise from proper remote control signals. By effectively determining transmitter strength, the controller could fly the plane even outside the remote transmitter’s range.

154

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

$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

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

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