2 Requirements

Even if one operates a project only alone and therefore actually should know, what to build, is it nevertheless meaningful to define the total requirements at the beginning. The requirements make a better conception possible and help for the examination and estimate of the result at the end.

The general requirements and boundary conditions are:

• Use of a common model airplane
• Fly a given flight plan with waypoints, flight figures etc.
• Autonomous takeoffs and landings
• Switch to manual control at any time possible
• En-route flight, i.e. takeoff and landing at different places
• Night flight ability
• Reasonable total costs
• Expandability
• Reliability, redundant implementation of important components

Figure 1 describes the operational sequence desired of an autonomous flight. During the pre-flight phase the control system is started, a flight plan entered, the engine is started and manual adjustment made if necessary. Then the airplane processes the flight plan gradually through all phases, until it comes to a halt after the autonomous landing. Logged noted data can now be fetched if necessary.

Figure 1: Flight phases and autonomous part

2.1 Values to be measured

The following specified measured variables refer to a flight model with 1.5 - 2.5 meters span and a combustion engine with power of approx. 1 HP. All values necessary for autonomous flight are specified.

From the above mentioned I will examine GPS, sonar, IMU, ground contact and tachometers with a photodiode.

2.2 System Overview

From the requirements and the measured variables results a schematic structure of the control system, as shown in Figure 2. It consists of sensors, actuators, control blocks and interfaces for programming and monitoring. Primarily a GPS receiver, an IMU as well as ultrasonic sensor, engine speed sensor and ground contact switches come into consideration. If the data of these components should be not sufficient, possibly air speed sensor and altimeters are added. Usual servos are used as actuators. In order to comply with the requirement of a manual control fallback, a R/C receiver is further necessary; however it is no longer coupled directly to the servos. The Component called R/C relay is to switch between autonomous and manual control. Selected flight and status data are transmitted by telemetry to a ground station. Further a display is planned, which is to supply information about the condition or error situations particularly during the start preparation.

Figure 2: Overview of the components of the control system

The controller - as a central component of the system - reads and processes all sensor data, adjusts these with the flight attitude defaults and the flight plan and sends appropriate control pulses to the actuators. Both controller and R/C relay should be stationary in-circuit programmable. Further the controller is to have an interface, which makes change of flight plan and configuration data possible during the start preparation. Finally all measured data and log files are to be stored on a PC after the flight.

2.3 Sensor Requirements

GPS:

• Position accuracy < 5 meters for longitude, latitude und Altitude
• Update rate 2 cycles per second, better 4 or 5 cycles per second
• Small current consumption, low weight
• Serial interface with TTL level, alternatively similar interface without additional circuitry
• NMEA output format or well documented binary format
• WAAS support and / or equivalent correction system

IMU:

• Measurement of 6 degrees of freedom of flight attitude
• Supply stable reference over several minutes
• Natural stability of the airplane is considered thereby
• Vibration-absorbed
• Update rate min. 25 cycles per second, better 50 cycles per second (the corresponding servo update frequency)
• Signals via standardized interface

Ultrasonic sensor:

• Measurement of the height over ground during takeoff and landing
• Measuring range of 0 - 8 meters
• Measuring accuracy < 2 meters
• Accuracy and update rate better than GPS
• Good results of measurement also over grass or uneven area particularly for small heights (landing approach)

Tachometer:

• Feedback for the throttle servos (engine performance)
• Possible conclusions on wind velocity and / or overload during the start

Ground contact:

• Reliable feedback over ground contact at takeoff and landing
• Clearing of the measurement inaccuracies of GPS altitude data and ultrasonic sensor

2.4 Requirements to the controlling components

2.4.1 Servo Driver

• Change over switch between autonomous control and remote control
• The PPM signal of the RC receiver serves as input
• Switches to autonomous control at remote command or missing remote controlling signal. Optionally the remote command can be configured externally (channel 5, 6, 7 or 8)
• Electrically fed by the R/C battery and is thus independent of the current supply of the autonomous control system
• Communicates with the controller via I2C-Bus as Slave. The address can optionally be configured externally (e.g. 4 bits of the 7-Bit address)
• In autonomous mode servo values are received as 10-bits of values via the bus
• In the remote controlling mode the servo positions with 10-bit solution can be queried via the bus
• Update rate 50 cycles per second (corresponding servo update frequency), better 100 cycles per second in autonomous mode
• Emergency program for simultaneous loss of controller and remote control
• Small current consumption, small space requirement
• ISP connection for programming

2.4.2 Controller

The requirements to the controller are so far still not concrete. Existing robotic products and solutions give an orientation. The intention is a precise estimation of the necessary arithmetic performance on basis of the requirements made above. Due to inaccuracies of these requirements and the possibility of the later expandability it appears better to place the performance requirements generously.

Interfaces:

This requirement can be read off still relatively simply from Figure 2:

• 2 - 3 bi-directional serial interfaces min. 38400 Bit/s with TTL level, suitably the serial sensor components
• A periphery bus system, preferably I2C and / or CAN
• Comfortable interface to programming, e.g. Ethernet or WLAN
• binary I/O lines with the possibility of external interrupts
• 8 A/D Converters (ADC) with 10 bits resolution for simplified connection of the IMU sensors

Arithmetic performance:

Here only the arithmetic performance can be measured, which is needed for the processing of the sensor data. This would be in detail:

As the table shows, the estimated expenditure for the operation of the periphery hardly carries weight and could be probably mastered by a smaller 8-bit microcontroller. However the timing is not to neglect - the signals arrive on coincidental times and must be processed in real time if possible.

If one wants to increase therefore extrapolate the update rate of GPS item data artificially, and will it necessary to use a Kalman filter for the error correction from the sensor data the cost of computation increases again considerably. Unfortunately no exact data concerning it can be given at this time.

The first following requirements result:

• 16-bit or 32-bit processor
• Floating-point arithmetic support (FPU)

Memory:

This estimation is somewhat more easily. The collected sensor data and log files will probably need the largest portion of the memory.

This corresponds approx. to 310 kByte per minute. This is 3 MByte of sensor data for a 10 minute flight. If one estimates again 1 MByte for program and real time processing system, then a storage requirement of at least 4 MByte results.

Other requirements:

• Small size, e.g. credit card format
• Low current consumption
• Durably, insensitive to impacts
• Real time processing system and / or real time programming possible
• Uncomplicated connection, development board and development environment
• Support from a user community

2.5 Flight Plan

The flight plan consists of a batch of commands, which are sequentially processed by the controller. For the beginning are intended no loops, jumps, subroutines or the like. Conceivable is however a declaration part, which contains the definition of configuration parameters, waypoints or exception treatments. Such script could look as follows:

waypoint 1 50.1234N 10.4567E
waypoint 2 50.1200N 10.4580E

start 175
ascent 50
heading 180
straight 200
flyto waypoint 1
flyto waypoint 2
descent 50
approach 175
stop