An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to...

39

Transcript of An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to...

Page 1: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

An Approach to UAV Controller Prototyping with

Linux

Student research project (Studienarbeit)

Humboldt-Universitaumlt zu BerlinMathematisch-Naturwissenschaftliche Fakultaumlt II

Institut fuumlr InformatikLehrstuhl fuumlr Kognitive Robotik

Oswald Bertholdltobertholdinformatikhu-berlindegt

Supervisor Prof Dr Verena V Hafner

Berlin 15 August 2011

Contents

1 Abstract 2

2 Introduction 321 Flying robots 322 Navigation problem 323 Bio-inspired robotics 324 What is a Controller 425 What is altitude control 426 About this text 4

3 Systems 531 Airframes 532 Quadrotor systems overview 933 HUCH Sytem 11

4 Experiments 1641 Basic structural design through simulation 1642 MKcom2 2043 Heuristically tuned altitude control software 2144 Alternatives 2845 Camera experiments 29

5 Results and future work 2951 Results 2952 Overall performance 3053 Timing 3154 Graceful degradation 3155 Conclusion 31

6 Acknowledgements 31

7 List of Abbreviations 31

1 Abstract

Architectures for autonomous control of Flying Robots (FR) are currently exposed to intense re-search activity Very much facilitated by advances in battery sensor and computing technology ithas become increasingly possible to construct sophisticated ying sensing machines of small sizewith appropriate amounts of onboard computing power

In this text rst an overview will be given of several systems suitable for FR research This willthen be complemented by the description of a hardware-independent prototyping setup for high-

2

level control This setup comprises of a basic quadrotor kit augmented with an embedded Linuxsystem with an eye on self-suciency

2 Introduction

21 Flying robots

Architectures for autonomous control and navigation on ying robots or Unmanned Aerial Vehicles(UAV) as they are more commonly referred to currently are a very active area of research in roboticsMostly enabled by advances in battery technology and miniaturised sensor and computing hardware[5] or in other words by an aordability boost resulting mostly from developments in the mobilecommunication market it has been increasingly possible in recent years to construct ever moresophisticated ying machines in low-budget settings and of very small sizes whereby following moreor less diverging design strategies Various civilian applications and devices are being investigated bythe research and hobbyist communities FR also generally add to the arsenal of vehicles employablein basic research in robotics while posing some particular challenges for stabilisation and navigationbecause of increased timing constraints for realtime performance payload constraints and generalvehicle dynamics

22 Navigation problem

All mobile autonomous agents have to somehow cope with the problem of navigation In small yingrobots it becomes particularly acute because of static instability and with some morphologies thenecessity of motion for remaining aloft While the basic attitude control problem for quadrotors (andother types of FR) seems adequately solved both theoretically [6 20 21] and practically (see thesystems listed) below position and egomotion estimation and related capabilities that do not relyon external reference systems such as Global Positioning System (GPS) or indoor optical trackingare not available o the shelf

23 Bio-inspired robotics

Since robust autonomous navigation on mobile robots in uncontrolled environments already is ahard problem on the ground it makes sense methodologically to draw inspiration from how naturalorganisms solve some of the relevant problems which obviously they do While it is clear thatcurrent technology cannot produce the type of hardware used in the self-reproducing organismsthat populate the environment it is still possible to glean relevant solutions with respect to sensorymodalities motori-sensor arrangements and models of cognition founded on top of the former two Aside-import of this approach is the possibility to verify models from theoretical biology [1 p32] [18]Bio-inspired robotics is a methodological approach in robotics and has successfully been applied inwork with ground-based [18] aquatic and ying robots [34] [9] Indeed this approach can be tracedback to the beginnings of electronic computing in the 20th century which approximately coincidewith the inception of cybernetics and information theory in the 1940ies [27 30 28] Anotherrelated point of view is the discipline of bionics in general engineering The work presented in hereis part of an eort to establish an open ying platform for experiments with bio-inspired navigationstrategies and the experiments presented serve as examples for a general approach to prototypingsuch strategies by covering some of the relevant componentry procedures and problems

3

24 What is a Controller

A controller is a well dened term in control theory [16] In this work the term controller designatesthe overall hardware and software aggregate which generates real-time behaviour on the robot Incontrast to concerns of control theory a good part of this aggregate is used up by sensor acquisitionand preprocessing to realise endemic onboard state estimation capabilities with an adequate degreeof correlation to environmental conditions

25 What is altitude control

Altitude here is used as some sort of measure for the distance of the robot from the ground Forvehicles that are able to hover this is the most important variable to be controlled It enables therobot to take o from the ground and either maintain a certain distance to the ground or to maintaina certain rate of ascent and more generally keep clear of a large object or bounding surface

In a simulated environment with a perfectly at oor the question hardly arises On a physicalsystem travelling over fractally ragged ground the question does become more intricate Severalfactors are interacting such as overall type of desired behaviour desired speed relative to theenvironment to objects in the environment and the spatiotemporal dynamics of sensor responses

Several dierent behaviours have been investigated and some of them prototyped These areterrain following absolute altitude stabilisation see Figure 1 and vertical rate control The formertwo emerge from the sensor reponse dynamics Depending on wether the robot is within rangeabledistance of an object or surface a valid range measurement overrides and resets the absolute altitudeinformation Vertical rate on the other hand can be directly extracted from an onboard camerausing optic ow estimation Some notable work has been done on purely optic-ow based autopilotsby N Franceschini Franck Ruer and others [24]

A purely egocentric sensory setup is used in contrast to many other approaches in FR work whichrely on GPS for outdoor deployment and optical tracking in indoor scenarios While the resultsclearly justify a third person approach to robotics the importance of reliable endemic sensing isprobably underestimated

26 About this text

The rest of the text is organised as follows In the systems section basic aspects and components ofFRs in general will be described and some of the existing low-cost UAV system are dissected andpresented in more detail

The consequent section will present the details of some experimental controller modules for aquadrotor implemented on an onboard Linux system This includes discussion of an approach tosimulation as well as the presentation of particular controllers on real hardware The terminal partof the text will summarise the results and sketch some possible routes for further development ofthe system

The work was being conducted in 201011 within the bio-inspired navigation project under thesupervision of Prof Verena Hafner of the Cognitive Robotics group at the Department of ComputerScience of the Humboldt-Universitaumlt zu Berlin

4

(a) Absolute altitude

(b) Terrain following obstacle avoidance

Figure 1 In 1(a) the robot maintains and absolute altitude The range sensors are either surpressedor the robot is too far away from the ground to be able to measure the distance In 1(b) the robotfollows the contour of the terrain

3 Systems

31 Airframes

There are many dierent types of FR only some examples of which can be seen in Figure 2 andFigure 3 Fixed wing apping wing and rotary wing yers have emerged as the most frequentlyused classes of motor powered yers on large and small scales All of these generate lift throughtheir whole body- or component-dynamics (rotors) Dynamic lift is contrasted by balloons airshipsand blimps which are statically buoyant but generally suer from reduced maneuverability andwind susceptibility In between there are all sorts of hybrids which are not easily classied forexample robots capable of hybrid modes of locomotion such as the MMALV [2 9] or VerticalTakeO and Landing (VTOL) vehicles with pivoting rotors or airfoil elements [33 Tail sitter]The remaining part of this work is concerned exclusively with multirotor helicopters (multicopters)although regarding the framework there are many commonalities across all types of yers

Helicopters in general have the advantage of being capable of near-holonomic motion and hov-ering which gives them a certain edge in indoor or constrained-space applications and hence makesthem an overall attractive research platform The main structural advantage of the bare-bonesmulticopter is the omission of all movable parts except for n motors which signicantly reducesmechanical complexity and thereby increases mechanical robustness and maintainability

311 Multicopter ight principle

The vehicle possesses 6 degrees of freedom for movement in space and n actuators On the quadrotortwo rotors are turning clockwise or counter-clockwise respectively Equal rotation rates result inoverall equalisation of torque Changing the rate of one set of co-rotating rotors relative to the othera torque about the vehicle vertical axis is induced and it turns (yaw) Changing the rate relation

5

(a) Quadrotor helicopter (b) Coaxial helicopter

(c) Fixed wing yer (d) Flapping wing yer

Figure 2 Dierent possible airframe types for ying robots a) experimental workhorse Horst b)E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c) Multiplex FunJetphotograph from Paparazzi Wiki by Matthew Currie d) Flapping wing platform photograph byHenryk Ploumltz also with permission

among two co-rotating rotors induces a torque about the perpendicular horizontal axis Both pitchand roll movements are eected in this way in a symmetrical manner By pitching or rolling thethrust vector is deected from the pure vertical direction and the vehicle accelerates laterally Formore details on the working principle and modelling of multirotors see for example [5] [14] or [11]At the level of the individual acutators the system is not manually controllable For this reasonInertial Measurement Units (IMU) are used to realise electronic control of the vehicle attitude AnIMU is a set of sensors that provides information about orientation in space by measuring angularrates acceleration and magnetic forces over three orthogonal axes The attitude control setpointsin turn can be aected by manual or high-level autonomous control input The control vector thusis given by

uT = (pitch roll yaw thrust) (1)

While the principles of inertial navigation have been applied for decades in control of aerial vehi-

6

(a) MMALV 1 (b) MMALV 2

(c) Paparazzi dual airfoil quadrotor taking o (d) Dual airfoil quad after transition to forwardight

Figure 3 Some less prevalent airframe congurations a) and b) Morphing Micro Air and LandVehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobots LLC and Roger Quinnof Case Western Reserve University and c) and d) a Paparazzi based quadrotor with two airfoils(tail sitter design) The pictures are two frames extracted from a video by Antoine Drouin JobyRobotics with kind permission

cles with both analog and digital implementations of the control schemes [12] the use of lightweightlow-cost-and-quality inertial sensors at the same time enables the construction of Micro AerialVehicles (MAV) and poses challenges for the accuracy of the resulting solutions The general ap-proach is to use a complementary system of high-frequency angular rate sensing (gyroscopes) andlow-frequency compensation via acceleration measurements (acceleromoters) In addition informa-tion from magnetic measurements can be incorporated into the attitude estimation if a 9-Degressof Freedom (DoF) IMU is available

312 The robot body

The airframes cited above are examples of FR bodies A brief consideration of some consequencesof the specic conguration is in order The relevant aspects are geometry surface and propulsionGeometry and surface as well as motion type relate to where and how the sensors can actually bemounted In xed winged platforms there is a prefered direction of motion whereas the quadrotordisplays a four-fold structural symmetry and the vehicle front needs to be arbitrarily set Mounting

7

a forward-pointing camera clearly breaks the symmetry in regards to vision based navigation Apossible solution is downward orientation or the use of panoramic lenses see Figure 23

In order to measure the distance to the ground only the downward pointing body surface needsto be considered for sensor mounts (although see GDC below) Obviously acoustic and optical rangesensors need to be unobstructed by other body parts Deviations in range measurements due to non-zero pitch and roll angles during ight are regarded as disturbances in the controller sketched belowThis is in part justied by the nite beam-width of the sonar sensor which intrinsically measuresthe shortest path to a reecting surface Since the absolute error grows linearly with range and theinfrared sensors used here only have very limited range (lt 1m) the deviation is not compensatedeither The scenario is illustrated in Figure 4 the theoretical error for dierent angles and aboslutedistances is plotted in Figure 5 Some more dynamic types of interactions are considered below

θ

e

Figure 4 Distance measurement depending on the angle θ to the ground surface

0 10 20 30 400

200

400

600

Angle [deg]

Error

[mm]

Alt 05 mAlt 1 mAlt 15 mAlt 2 m

Figure 5 Theoretical error over angle for several dierent distances from ground

8

32 Quadrotor systems overview

The quadrotor was conceived in the 1920ies bei Etienne Oehmichen and purportedly ew onlya couple of meters at the time probably due to the manual control problem The concept washibernating for most of the 20th century to resurface as an electronic toy in 1996 The Roswellyer of Area51 Technologies seems to be the earliest appearance of a working miniature quadrotorRC yer [13] Since then development of similar systems has picked up momentum considerablyBy now (2011) there exist a number of projects that are suitable (if not specically designed) asrobotics research platforms of which this section provides an overview The projects backgroundsvary from robotics and remote sensing to hobbyist RC model-ying and electronic toys

While not exclusively targeted at multicopters one of the oldest eorts to develop a versatileand open UAV system (airborne and ground segments) for model yers is the Paparazzi (PPZ)1 project of the Ecole Nationale de lAviation Civile (ENAC) The project was founded in about2003 2 and consists of an extensive set of both hardware and software components The airbornehardware consists of a variety of base processor boards (Tiny TWOG LisaLM) sensor modulesand communication devices The control software consists of a stack of PID control loops whichare executed on the microcontroller boards The overall approach reects a certain outdoor anityConsequently one of the architectures distinctive features is the use of IR thermophiles for absoluteorientation sensing (warm earth cold sky) in outdoor environments Complementing the airbornepart of the project is a comprehensive set of ground segment software and simulation modules Thiscomprises tools for tasks such as logging plotting map-supported on-screen trajectory trackingas well as eg vehicle tracking for servo-controlled directional antennas Communication amongcomponents is realised via the text- and subscription-based IVY software bus 3 which serves as thepoint of entry for component reuse from foreign systems Paparazzi also supports a high-level XMLbased ight-plan description and airframe conguration language Overall the PPZ system oersa mature codebase and a great amount of exibility through open source licensing and a modulardesign

Founded in 2006 the MikroKopter (MK) 4 project quickly gathered momentum in Germany asan RC model-ying vehicle and aerial photography system It is the system used for all experi-ments described in this work The MK architecture is a modular system that can be bought as a kitfrom the producer and consists of a combined IMU and microprocessor board called FlightCtrl (FC)which runs the attitude control software (also FlightCtrl) In fact there are several versions of theFC featuring dierent processors and sensors In addition the project has brought forth specialElectronic Speed Controllers (ESC) which interface control output on a TWI with brushless motorscalled MK-BL The distinctive feature of these controllers is the particularly high update-rate com-pared other other ESCs Consequently the MK-BL are used across many of the other projects seealso Table 1 Optional sensor modules include a compass and GPS components The main factorsfor choosing this particular system were its ready availability at the time of project initiation in2008 cost and source code access The ground and support software for the MikroKopter on theother hand is not ideally suited to demands in robot prototyping There have been attempts atdeveloping open-source and cross-platform alternatives to the vendors MikroKopter Tool althoughin the experiments described below yet other tools were used

1Paparazzi Wiki httppaparazzienacfrwikiMain_Page2httpwwwnongnuorgpaparazzigallery_v0html3Ivy Bus httpwww2tlscenafrproductsivy4MikroKopter httpwwwmikrokopterde

9

Published in late 2008 (according to the Internet Archive) the PIXHAWK (PXH) 5 project ofthe Computer Vision and Geometry Lab at the ETH Zuumlrich is an example of a system designedfrom the ground up as a robotic research platform in this case specically targeted towards visionexperiments PXH also has its own integrated processorIMU module as well as adapter hardwarefor using miniature yet high-capacity computing hardware sometimes referred to as Computer onModule (COM) The software part of the system features a comprehensive groundstation softwarecalled QGroundControl (QGC) and a low overhead communication protocol calledMAVLink 6 Sev-eral other components are provided or are in development The systems components are publishedunder open licenses and the software parts can easily be reused and adapted

Another interesting addition from around 2010 to the growing family of quadrotor systems is theArduCopter (AC) 7 which is designed on top of a more generic autopilot for both xed-wing androtary-wing platforms the ArduPilotMega (APM) 8 which in turn is based on the popular Arduino9 meta-platform The ArduPilot software already makes use of PXHs groundstation QGC throughthe MAVLink protocol In distinction to the projects mentioned so far ArduCopter uses standardunmodied low-cost ESCs for motor control which reects the general low-cost approach of theentire system This approach is most promising in terms community engagement Other relevantprojects in this category are the Unmanned Aerial Video Platform Next Generation (UAVP-NG)10 and OpenPilot 11 projects Both feature co-designed hardware and software but both have notbeen considered more closely due to their state of development during 2010 12

Among the straightforwardly commercial vendors there are two types those targeting profes-sional use outside the RC model community and those attending to the electronic toy marketThe former are mainly used for standard security and surveillance related activities In europethese are Ascending Technologies (AscTec) and microdrones AscTec models also appear in roboticsresearch but require much higher budgets The prominent representatives from the latter categoryare the DraganFlyer of RCToys whose ancestry goes back to the Roswell yer mentioned earlierand most recently the Parrot ARDrone released in 2010 featuring onboard Linux two camerasstabilisation with optical ow and an SDK for custom extensions

321 Systems summary

All these systems dier with regards to sophistication and extendability and clearly none of themprovides out-of-the-box the type of onboard computing system desired for a robotic experimentalframework targeting high-bandwidth signal processing In heterogenous multi-vehicle systems is-sues of interoperability and code-reusability can be expected to become more salient Often easeof use in terms of development and prototyping is traded o for eciency and compact hardwarewhich makes the implementations quite idiomatic

By taking a modularised approach as regards the hardware and employing in the sense ofreusability and ease of programming more powerful Single Board Computers (SBC) or COMscapable of running an operating system dierent systems providing the basic attitude control

5Pixhawk httpwwwethzchpixhawk6MAVLink httpwwwqgroundcontrolorgmavlinkstart7Arducopter httpcodegooglecomparducopter8ArduPilotMega httpcodegooglecompardupilot-mega9Arduino httpwwwarduinocc10UAVP-NG httpnguavpch11OpenPilot httpopenpilotorg12By 2011-06-09 Thu both projects status has considerably advanced

10

such as those mentioned above can be used and wired up with more capable hardware to conductexperiments with a wide range of sensors and algorithms This necessitates the integration of severaldierent downlink and communication frameworks that are in use across dierent systems

One practical option for this part of the system while keeping reusability ease of developmentand energy requirements in mind are ARM-based Linux packages such as the Gumstix or Beagle-board families or similar devices which are available at reasonable prices In summary these werethe considerations that are accumulated in the current state of the HUCH setup described belowThe diverse FR projects can be categorised along an axis indicating the level of targeted behaviourranging from low-level actuator control up to high-level navigation and high performance signalprocessing functionality Table 1 is a graphical representation showing the projects hardware andsoftware components coverage along that axis

Motor Attitude GPS Ground High-perf

UnspecStd PWM ESCs

AscTecDragoncopter

MK MK-BL Flight-Ctrl MKNAV MK-ToolPXH pxIMU via COM QGC COMPPZ TWOG Tiny Lisa GCS COM w LisaAC ArduPilot AC-GS

HUCH COMs

Table 1 Systems overview Of course it is almost always possible to attach a COM to low-levelattitude control platform such as the MK-FC ArduPilotMega or PPZ autopilots over a serialinterface Both PXH and PPZ are designed for use with Gumstix COMs

33 HUCH Sytem

331 Basics

The HUCH project was started to test bio-inspired navigation strategies on ying robots Theproject was initially equipped with basic MK kits The MK is mainly being used for RC modelying and aerial photography but the user community is also active with various other experimentsregarding extentions and modications The platforms distinctive advantages are its price readyavailability and sucient openness for research uses 13 Several academic projects have made orstill make use of the MikroKopter platform

The core component of the MK setup is the FlightCtrl (FC) comprising of both a Printed CircuitBoard (PCB) featuring an IMU a microcontroller and the rmware implementing the attitudestabilisation RC interface telemetry and more The MK architecture also features ESCs (MK-BL) capable of receiving the actuating variable via a TWI interface at a rate of 500 Hz which marksa dierence to other ESCs available on the RC market For that reason the MK-BL is also widelybeing used in many other projects

13Although with recent versions of the FlightCtrl rmware this has started to change

11

Direction Code Command Arguments

Inb Submit external control extctrl structc GyroBaro neutral Noned Request debug vector Update interval or None for one-om Start motors Nonen Kill motors None

OutD Debug vector 32 int16 values

Table 2 Five most important HUCH commands for external control of the modied MK-FC

332 Modications

Software The HUCH group has developed various extensions and modications to the platformOne of these is an expansion of the external control interface see Table 2 via the UART a corre-sponding groundstation (mcut) and control software (mktool) These are the basis for most of thework described in the remaining part of this text

The FlightCtrl microcontroller rmware was modied (HUCH variant) initially based on killa-gregs rewrite of the original rmware and implements among other things the extended communi-cation protocol higher UART baudrates TWI sensor integration and several more items 14 Thereexists a tool 15 to realise realtime display and plotting of debug variables ashing of MikroKopterrmware with embedded avrdude code parameter editing and motor testing The MKcom pro-gramm was initially developed for using a CMUcam to control the MikroKopter from vision inputIt features the basic FC communication stack and a control console This last item served as thebasis of the rst prototype of a Linux based altitude control At the time of writing develop-ment of these tools has been abandoned in favor of Micro Aerial Vehicle Humboldt Universitaumlt zuBerlin (MAVHUB) which is described in more detail elsewhere [25]

Computing hardware To overcome the severe restrictions of the Atmel ATMega644 being usedon the FC it is necessary to attach additional processing hardware Stating it more simply a singlemicrocontroller clearly is not suitable for any kind of slightly more demanding processing For thispurpose to date dierent single board systems have been used the Gumstix Verdex Pro 16 andBeagleboard variants 17 as can be seen in the gures 6 and 7 Several other options are availableand could be utilised in the future as our approach is construed exible in this regard Working ona Linux system provides a huge advantage in abstracting the algorithms from the hardware TheLinux system is connected to the FlightCtrl via the UART port In order to achieve a sampling rateof 100 Hz a baudrate of 230400 kbaud needs to be set on this connection The DebugOut messagestructure counts 95 bytes on the wire The motor command takes up 22 bytes giving 117 bytes forone sense-act cycle At the given channel capacity (25600 bytes per second) this gives approximately

14HUCH FlightCtrl 071i httpkoroinformatikhu-berlindeqkdownloadsV071i_huch-code_motodrone09targz

15mcut httpkoroinformatikhu-berlindeqkdownloadsmcuttargz16Gumstix Verdex Pro httpwwwgumstixcomproductverdex-pro17Beagleboard httpwwwbeagleboardorg

12

218 full cycles per second under optimal conditions and should be sucient for processing at 100Hz There are problems with nding higher baudrates that are supported on both sides of theconnection due to the 20 MHz clocking of the microcontroller

(a) Verdex View 1 (b) Verdex View 2

Figure 6 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below andthe expansion board on above On top is a USB WiFi dongle

A custom ATMega based ADC expansion board is acting as a generic analog data aqcisitiondevice Analog measurements are multiplexed and transmitted down a Two Wire Interface (TWI)link to the main control COM In a dierent setup an Arduino Mini was substituted for the customboard

Sensors For altitude measurement three dierent sensors were added to the setup A barometricpressure sensor is already provided for in the vendor board design This sensor is quite noisy butcovers a large range of measurement When close to the ground range sensors can be used tomeasure the distance Of this type we used a Devantech SRF02 sonic range nder This sensorhas an integrated microcontroller that does time-of-ight calculations for an ultrasonic pulse andtransmits the result digitally over a two wire interface (TWI) The speed of sound vs the actualdistance determine the maximum update frequency In our experiments these were xed at a rateof approximately 50 Hz In addition we attached two Sharp type infrared rangers (GP2Y0A02YKGP2D120) to the robot These output an analog voltage inversely proportional to the distancemeasured They are connected to the expansion board which also transmits updates via TWI butat a rate of 100 Hz The physical conguration of the range sensors is depicted in Figure 8

13

Figure 7 The electronic stack on this copter consists of (in ascending order) FC Power and UARTbreakout Beagle breakout and Arduino Mini mount BeagleBoard and USB WiFi Dongle

333 Physical system

As has been described above the FC can be given actuation commands via both the RC and UARTinterfaces in the form of the four-element vector 1 The SBC used in this particular conguration isthe Gumstix Verdex Pro X6LP The gumstix receives its power supply of 5V DC from the FC andtalks to it over the FFUART without additional level converters The hardware component setupis depicted schematically in Figure 9 On the left hand side of the diagram the base MikroKoptersetup is seen with the FlightCtrl RC receiver and the four ESCs On the right hand side theVerdex and custom sensor board are situated realising highlevel control and UDPIP link to thegroundstation over WiFi For the operation of a second onboard SBC the Beagleboard in Figure 9an additional voltage controller had to be used between the 12V DC rail and the Beagleboard powersupply socket

OpenEmbedded The current gumstix system software is provided via the Aringngstroumlm 18 distri-bution which is based on OpenEmbedded 19 The gumstix overlay provides Linux kernel versions2621 and 2631 Unfortunately the driver for the gumstix onboard WLAN hardware (netvx boardw a Marvell cf25 chip) changed between those versions and the one in 2631 refuses to actually

18Angstrom Distribution httpwwwangstrom-distributionorg19OpenEmbedded httpwwwopenembeddedorg

14

Figure 8 Range sensors attached to frame

RC receiver Onboard electronics

BL1 Expansion Board

BL4 FlightCtrl BL3

BL2 Gumstix

Camera BeagleBoard

TWI

UART

TWI

Wi

LAN

USB

Figure 9 Basic HUCH onboard electronics The left hand region of the picture consisting of receiverFC and brushless motor controllers BL1minus4 represents the standard MK setup while the right handregion represents HUCH additions

work with our hardware so a dierent solution had to be found Fortunately here the USB sub-system works well out of the box and standard USB WLAN hardware could be used to set up thelink Running the system o an SD-card as well as TWI (I2C) support in Linux work well Onemore aspect of the WLAN setup is worth noting though It was desired to realise the wireless linkto the onboard Linux in Ad-Hoc mode for two reasons The rst is reduced startup time when usingAd-Hoc mode the second is independence of access point infrastructure In this way the minimalFR groundstation conguration can be operated in a more mobile manner In principle one of thenodes could be operated in Master mode but this is not supported by all hardware

Once the live Linux system and cross-compilation environment was up and running the MKcom

15

software provided the basis for further work on controller implementation Looking at the Linuxsystem at this point the following view presents itself in Figure 10

Gumstix

AringngstroumlmLinux 2631 SD

UIShell mktool wlan0

devttyS1 devi2c-0

FC Exp Groundstation

RxTx wires

Wireless link

Figure 10 Basic Linux setup

4 Experiments

41 Basic structural design through simulation

Initially the problem of altitude control was analysed in simulation To that end a simple con-troller was realised within the crrcsim 20 RC model simulator There are basically two possiblemethodological approaches to setting up a simulation for a model helicopter One is the derivationof the model from rst principles and implementation from scratch The other is building uponexisting if simplifying solutions that are practically usable and open for modication

A moderately physically realistic model of a quadrotor aerial system is governed by a nontrivialnonlinear dierential equation [3 pg 155] [4] Much microscopic detail can be added for furtherrenement as the need arises Such details are discussed to some extent in [14] and [8] In the near-hover ight regime the system behaves quasi-linearly but at more extreme velocities and attitudesthe increasing impact of several nonlinear eects such as blade apping vortex ring states orforward translational lift would have to be considered For our purposes these eects have so farbeen neglected but could in princpiple be incorporated into the model

Circumventing the necessity of model derivation and implementation the second approach waschosen In particular the existing real-time ready crrcsim [7] RC-model simulator software wasmodied to conduct the initial experiments This was particularly facilitated by the prior work ofJens W Wulf who implemented a quadrotor model and internal controller substructures for thissimulation framework [32] A screenshot of the Wulf-model ying in the modied simulation in canbe seen in Figure 11 crrcsim comes with an internal controller architecture that realises dierent

20Charles River Radio Controllers Simulation httpcrrcsimberliosde

16

attitude controllers The software originally is designed to interface manual control hardware suchas RC transmitters joysticks and such to the simulation engine It was modied to implementadditional controllers detailed state information output for plotting and analysis and networkedcontrol of the simulation engine A drawback of crrcsim is its monolithic architecture For futurework the core simulation engine would have to be separated from the render engine Alternativelythe PPZ approach could be used as a drop-in replacement

Figure 11 Simulation screenshot The helicopter model landscape and text console are part ofcrrcsim The actual debugging output that can be seen in the console is part of custom modications

411 Closed loop

The basic structure of the full control loop is displayed in Figure 12 The control module embeddedin the loop is a Single-Input Single-Output (SISO) type controller The actuating variable undercontrol is thrust which eects overall lift (see above) while the other three components are mostlycontrolled manually during the experiments The input to the controller is the current altitudeestimate The estimation process potentially has to consider multiple measurements which have tobe fused into a single representation

412 Measurements

In simulation global knowledge of the world- (and agent-) state is available and all system variablesare immediatly accessible This allows to use a simplied signal-ow structure which is depicted in

17

Measurements

z0

z1 Kalman lter Controller

Fusion Estimate PID System

znminus1

zn

throttle

Behaviour

setpoint

Figure 12 Controller structure with measurement branch

gure 13 In order for the controller to be structurally transferable to the real hardware system thespecic sensor conguration has to be modelled within the simulator This included preparationof IMU data by tapping the Flight Dynamics Model (FDM) module and basic modelling of therespective characteristics of the barometric and ultrasonic range sensors which were in use on thehelicopter at that time In the case of the barometer this meant the addition of white gaussiannoise A slow drift which can be observed on the real sensor due to slow air-pressure changes wasneglected For the ultrasonic range sensor the timing characteristic that is the maximum updaterate dependent on distance measured was emulated The information thus synthesized was fed intoa Kalman lter for further processing

Controller

PID Systemthrottle

Flight dynamics model

setpoint

Figure 13 Simplied controller structure

413 Sensor fusion

Sensor fusion is a problem class on its own The base intent is to derive an estimate of a systemstate variable from multiple measurements that is more reliable than it would be by using only asingle measurement There are several approaches which have been developed over the last decadesand which could be employed for this task The complementary lter approach can be chosen if the

18

sensors are aected by suciently dierent kinds of noise and thus eg spectrally complementarylters can be used on dierent measurement channels which are then linearily combined into a singlevalue Probably the most commonly used techniques are the linear Kalman lter and its nonlinearvariants Other methods are nonexhaustively Bayesian strategies such as Particle lters H-infinlters or neural networks A linear Kalman lter was chosen in the current setup for the reasonthat the lter and its characteristics are well documented and the implementation is straightforwardboth from scratch and even more so using matrix algebra libraries such as OpenCV The basic ltertask is to estimate the state xk isin Rn of a discrete time system governed by the linear stochasticequation [29] [15]

xk = Axkminus1 +Bukminus1 + wkminus1 (2)

based on a measurement zk isin Rm given as

zk = Hxk + vk (3)

where wk vk are random variables which represent process noise and measurement noise and arenormally distributed with zero mean p(wk) sim N(0 Q) p(vk) sim N(0 R) Q and R are the processand measurement noise covariance matrices The model used here consists of two state variablesx = (a dadt) with a the altitude (above ground) Later the model was extended to include d2adtso as to facilitate incorporation of accelerometer measurements One problem with the real sensorswas a clear deviation of the measurement noise from the assumed normal distribution and had tobe corrected for in preprocessing

414 PID controller

The Kalman lter state estimate can nally be used as the input to a PID throttle controller ThePID model used is a FOPDT integrating model The second input to the controller module is thesetpoint which can be set in the simulation via keyboard- or network-input to the application Therst working PID parametrisation was arrived at through manual tuning which is cumbersome andgives suboptimal results

415 Evolutionary parameter tuning

To prove the concept of using online learning within simulation at least the PID parameters wereoptimised using evolutionary strategies [22] [26] The tness function for this experiment wasconceivably simple chosen as

f(i) =

Nsum0

|xset minus xik| (4)

with individual i (a tuple (P ID)) setpoint xset the experiments duration in time steps N andthe altitude xik at time step k resulting from execution of controller i This stage involved setting upthe system so that simulation state and model parametrisation (the P I and D coecients) could

19

be controlled programmatically It was realised over a UDPIP connection between crrcsim andthe external simctrl control shell 21 implemented in the Python language 22 The results of theexperiment have been presented in [10]

42 MKcom2

MKcom short for MikroKopter communication tool was designed as a minimal software layer tosit on top of the UART communication link to the main ight board It provides a console baseduser interface for activation and conguration of a set of thin control functions and can act as agateway between the FC and a CMUcam MKcom functions can send commands to the FC andincoming UART packets are dispatched to the appropriate message handler This tool implementedthe modied MK message set

The setup was used as the basis for prototyping several versions of the control loop structureoutlined in Figures 12 and 13 The internal organisation of these implementations can be seenin Figure 14 Three dierent controller cores were realised which incrementally incorporated moremeasurement channels heuristic detail and safety hooks The detailed ow structure of the controllerdesign will be outlined below The update rate and execution timings are dictated by the arrivalof the measurement vector from the FC Auxiliary sensors were integrated asynchronously into themain loop A custom groundstation for state logging and realtime plotting was connected to thenetwork downlink indicated in the diagram

421 MKcom2 Flow structure

On startup a request for debug structure emission is sent manually from the mkcom shell to the FCwith the debug n command where n is the desired sampling interval in milliseconds An examplesession excerpt looks (slightly beautied) as follows (`gt indicates the shells command prompt `is the startsign of the MK protocol strings starting with ` is the raw ascii data going over thewire)gt debug 100

tx bdV ===Ds

gt

rxbuf 93 bD===IgtpU gtomgtS=xTyf=DL|pA= gt===Kl|Lnx=mL=I===i=BM|| oXfT_UrePI=T]=gt==E=|l|

L=IE||y===Y=qM

_DebugOut_ 1804 310 203 854 -843 420 -49 49 4

2 -21-1016 123 828 828 0 11 21

-1-5850 9822 -24267 51 94 1 2 -2

207 706 -1 0 7

rxbuf 93 bD===ggtpi gtm=gtT=oxzd]DL|o===m=A=Kl|ALnx=mL=I===E=m=== KxYSourePI=T]====A===

L=IM||y===Y=nf

_DebugOut_ 1834 315 192 855 -722 414 -49 32 3

4 -21-1008 123 828 828 0 2 15

0 -897811867-24267 51 94 0 1 0

207 708 -1 0 7

gt debug 0

tx bd====DZ

gt

21httpwww2informatikhu-berlinde~obertholQK22Python Language httpwwwpythonorg

20

The debug vector is populated in the FC where element positions correspond with value typesIt includes IMU data manual control input from the RC and the barometer as well as systemstatus values such as battery voltage RSSI value ampc Depending on the setup it can include thereading from the sonar as well If the actual controller is activated with eggt ac3 1

kal_cv_init DP 3 MP 5 CP 0

gt

the controller evaluation function is executed upon each arrival of a debug packet Of coursesome information is retained across calls After computation has nished an extctrl (Externalcontrol) structure is populated and sent back to the FC Aditional measurements such as from anInfraRed Ranger (IRR) are integrated in an asynchronous manner from multiple threads Severalparameters such as the altitude setpoint PID values bias ampc can also be set from the text based userinterface While this works quite well in principle and did achieve good performance modularityand extensibility were not an initial design goal This led to another iteration of the same designwithin the MAVHUB framework which will be described in the next subsection

IO Channels UART TWI UI Network

HAL threads FC-RX Expansion Ctrl Sonar Shell

Processing Controller

mkcom2

Figure 14 Mkcom2 ow-graph

43 Heuristically tuned altitude control software

The vague vision of the overall architecture that is pursued here is that of several concurring moduleswhich are summed in a cooperative time-dependent manner and where each module is responsiblefor various behavioural aspects [1] To ease prototyping and testing of components the structurehas to be kept exible extensible and dynamically recongurable This has to be considered in theoverall onboard software design In order to illustrate this requirement the ow of information andthe interaction with additional behavioural modules will be described in more detail in the followingparagraphs References will be made to several modules operating within the MAVHUB frameworkthe basics of which are described elsewhere [25]

431 Data acquisition

First the controlware has to collect all sensory information from possibly heterogenous sourcesThese include 6 - 9 channels of IMU data (depending on IMU type) a barometric measurementseveral range sensors as well as optical sensors (cameras) and of course any other sensor which is

21

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

1500

2000

Time [s]

Value

throttle

uss_meas

k_s0

Figure 15 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m aboveground The dashed line is the raw sonar range value the solid black line is the estimate uponwhich the PID controller acts The solid green line in the lower part of the plot is the controlleroutput value which is sent to the actuator

available or desired Heterogeneity pertains to hardware channels update rates and data formatsIn MAVHUB there are two main channels if information ow One is the protocol stack whichtransmits volatile incoming messages to all active modules (apps) The other is a shared memoryarea where data can be deposited by any active process In the setup considered here FC data(including IMU barometer and possibly sonar) and intermediate internal data travel on the stackSensors connected via a two-wire bus are operated by sensor drivers and measurements are put intothe shared memory The desired result of this step is to be able to operate on a homogenous vectorof input signals within the main control loop

432 Preprocessing

Subsequent to acquisition each sensory channel is individually preprocessed according to the pe-culiarities of sensor principle and connection mode Preprocessing mostly consists of linearisationunit conversion (inverting the sensor characteristic) and several kinds of heuristic validation

Linearisation For this particular setup linearisation only has to be done for the IRRs Theseare analogue sensors and the output voltage is related to the distance s measured via u(t) = 1

s(t) An example sensor characteristic is displayed in Figure 16 For the dierent subtypes of the Sharpsensors an individually parameterised procedure has to be performed as described by eg Acroname

22

Robotics in [23] if the sensors are processed on a metric basis If the Sharp sensors are driven atthe recommended supply voltage of 5V using the datasheet specications has proven sucientlyaccurate An example script for determining the parameters from given calibration data is suppliedon this reports supplementary website 22

Unit conversion The diverse units of sensor data have to be explicitly converted to units conve-nient for later steps in the calculation in particular sensor fusion with the Kalman lter For thealtitude measurements these are metersminus3 so ADC-units or time-of-ight measurements have to beconverted to millimeters for the analog sensors (barometer accelerometer infrared) and the sonarsensor repsectively This simply amounts to a multiplicative factor

Validation Heuristic sensor data validation has to be done for all types of rangers as well as for thebarometric sensor The spurious readings these sensors produce are of dierent types though Theinfrared rangers display ambigouity beyond the lower limit of the operating ranges see Figure 16For the GP2D120 which can sense the smallest ranges of all sensors this can be mostly neglectedsince the minimal sensing range can hardly be reached due to the mechanical conguration Forall the other sensors output is surpressed when the GP2D120 is active At the upper limit of theIRRs operating range the output is surpressed when a suitable threshold is reached The followingcode example illustrates this where sensor channel number three is the close range IRR

if(in_range(sensors [3] first llim ulim))

valid = 10

else

valid = 00

sensors [3] second = (fir[3]-gtcalc(valid) gt= 099) 1 0

Surpression is realised by setting appropriate values in the measurement transform matrix H(t)of the Kalman lter Alternatively this could be done by generating suitable variances for therespective sensors in the measurement covariance matrix R(t) Driving the IRRs at 33V works butreduces the usable range In addition the IRR sensor measurements are dependent on the groundsurfaces some of which eg an oce carpet can result in erratic results

The ultrasonic sensor is susceptive to dierent kinds of spurious readings caused by late echoesThis happens both when very close to an object or surface or when far away that is beyond theupper limit of measurable distances The validation strategy employed is to set hard empiricallower and upper limits for values as for the IRRs and limiting the maximum dierence betweentwo consecutive values based on assumptions about the maximum velocity An example session isillustrated in Figure 18

Finally the barometer is sensitive to acceleration which has to be accounted for The sensorbehaviour is displayed in Figure 19 The empirical corrections read

BARO (pre [1] correct from accel -z (pre [2])

pre [1] first -= (005 pre [2] first)

The validition process in general produces one new signal per channel to be used later in theprocess for setting Kalman lter matrix values One remaining problem here is the channel cross-dependency

23

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 2: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

Contents

1 Abstract 2

2 Introduction 321 Flying robots 322 Navigation problem 323 Bio-inspired robotics 324 What is a Controller 425 What is altitude control 426 About this text 4

3 Systems 531 Airframes 532 Quadrotor systems overview 933 HUCH Sytem 11

4 Experiments 1641 Basic structural design through simulation 1642 MKcom2 2043 Heuristically tuned altitude control software 2144 Alternatives 2845 Camera experiments 29

5 Results and future work 2951 Results 2952 Overall performance 3053 Timing 3154 Graceful degradation 3155 Conclusion 31

6 Acknowledgements 31

7 List of Abbreviations 31

1 Abstract

Architectures for autonomous control of Flying Robots (FR) are currently exposed to intense re-search activity Very much facilitated by advances in battery sensor and computing technology ithas become increasingly possible to construct sophisticated ying sensing machines of small sizewith appropriate amounts of onboard computing power

In this text rst an overview will be given of several systems suitable for FR research This willthen be complemented by the description of a hardware-independent prototyping setup for high-

2

level control This setup comprises of a basic quadrotor kit augmented with an embedded Linuxsystem with an eye on self-suciency

2 Introduction

21 Flying robots

Architectures for autonomous control and navigation on ying robots or Unmanned Aerial Vehicles(UAV) as they are more commonly referred to currently are a very active area of research in roboticsMostly enabled by advances in battery technology and miniaturised sensor and computing hardware[5] or in other words by an aordability boost resulting mostly from developments in the mobilecommunication market it has been increasingly possible in recent years to construct ever moresophisticated ying machines in low-budget settings and of very small sizes whereby following moreor less diverging design strategies Various civilian applications and devices are being investigated bythe research and hobbyist communities FR also generally add to the arsenal of vehicles employablein basic research in robotics while posing some particular challenges for stabilisation and navigationbecause of increased timing constraints for realtime performance payload constraints and generalvehicle dynamics

22 Navigation problem

All mobile autonomous agents have to somehow cope with the problem of navigation In small yingrobots it becomes particularly acute because of static instability and with some morphologies thenecessity of motion for remaining aloft While the basic attitude control problem for quadrotors (andother types of FR) seems adequately solved both theoretically [6 20 21] and practically (see thesystems listed) below position and egomotion estimation and related capabilities that do not relyon external reference systems such as Global Positioning System (GPS) or indoor optical trackingare not available o the shelf

23 Bio-inspired robotics

Since robust autonomous navigation on mobile robots in uncontrolled environments already is ahard problem on the ground it makes sense methodologically to draw inspiration from how naturalorganisms solve some of the relevant problems which obviously they do While it is clear thatcurrent technology cannot produce the type of hardware used in the self-reproducing organismsthat populate the environment it is still possible to glean relevant solutions with respect to sensorymodalities motori-sensor arrangements and models of cognition founded on top of the former two Aside-import of this approach is the possibility to verify models from theoretical biology [1 p32] [18]Bio-inspired robotics is a methodological approach in robotics and has successfully been applied inwork with ground-based [18] aquatic and ying robots [34] [9] Indeed this approach can be tracedback to the beginnings of electronic computing in the 20th century which approximately coincidewith the inception of cybernetics and information theory in the 1940ies [27 30 28] Anotherrelated point of view is the discipline of bionics in general engineering The work presented in hereis part of an eort to establish an open ying platform for experiments with bio-inspired navigationstrategies and the experiments presented serve as examples for a general approach to prototypingsuch strategies by covering some of the relevant componentry procedures and problems

3

24 What is a Controller

A controller is a well dened term in control theory [16] In this work the term controller designatesthe overall hardware and software aggregate which generates real-time behaviour on the robot Incontrast to concerns of control theory a good part of this aggregate is used up by sensor acquisitionand preprocessing to realise endemic onboard state estimation capabilities with an adequate degreeof correlation to environmental conditions

25 What is altitude control

Altitude here is used as some sort of measure for the distance of the robot from the ground Forvehicles that are able to hover this is the most important variable to be controlled It enables therobot to take o from the ground and either maintain a certain distance to the ground or to maintaina certain rate of ascent and more generally keep clear of a large object or bounding surface

In a simulated environment with a perfectly at oor the question hardly arises On a physicalsystem travelling over fractally ragged ground the question does become more intricate Severalfactors are interacting such as overall type of desired behaviour desired speed relative to theenvironment to objects in the environment and the spatiotemporal dynamics of sensor responses

Several dierent behaviours have been investigated and some of them prototyped These areterrain following absolute altitude stabilisation see Figure 1 and vertical rate control The formertwo emerge from the sensor reponse dynamics Depending on wether the robot is within rangeabledistance of an object or surface a valid range measurement overrides and resets the absolute altitudeinformation Vertical rate on the other hand can be directly extracted from an onboard camerausing optic ow estimation Some notable work has been done on purely optic-ow based autopilotsby N Franceschini Franck Ruer and others [24]

A purely egocentric sensory setup is used in contrast to many other approaches in FR work whichrely on GPS for outdoor deployment and optical tracking in indoor scenarios While the resultsclearly justify a third person approach to robotics the importance of reliable endemic sensing isprobably underestimated

26 About this text

The rest of the text is organised as follows In the systems section basic aspects and components ofFRs in general will be described and some of the existing low-cost UAV system are dissected andpresented in more detail

The consequent section will present the details of some experimental controller modules for aquadrotor implemented on an onboard Linux system This includes discussion of an approach tosimulation as well as the presentation of particular controllers on real hardware The terminal partof the text will summarise the results and sketch some possible routes for further development ofthe system

The work was being conducted in 201011 within the bio-inspired navigation project under thesupervision of Prof Verena Hafner of the Cognitive Robotics group at the Department of ComputerScience of the Humboldt-Universitaumlt zu Berlin

4

(a) Absolute altitude

(b) Terrain following obstacle avoidance

Figure 1 In 1(a) the robot maintains and absolute altitude The range sensors are either surpressedor the robot is too far away from the ground to be able to measure the distance In 1(b) the robotfollows the contour of the terrain

3 Systems

31 Airframes

There are many dierent types of FR only some examples of which can be seen in Figure 2 andFigure 3 Fixed wing apping wing and rotary wing yers have emerged as the most frequentlyused classes of motor powered yers on large and small scales All of these generate lift throughtheir whole body- or component-dynamics (rotors) Dynamic lift is contrasted by balloons airshipsand blimps which are statically buoyant but generally suer from reduced maneuverability andwind susceptibility In between there are all sorts of hybrids which are not easily classied forexample robots capable of hybrid modes of locomotion such as the MMALV [2 9] or VerticalTakeO and Landing (VTOL) vehicles with pivoting rotors or airfoil elements [33 Tail sitter]The remaining part of this work is concerned exclusively with multirotor helicopters (multicopters)although regarding the framework there are many commonalities across all types of yers

Helicopters in general have the advantage of being capable of near-holonomic motion and hov-ering which gives them a certain edge in indoor or constrained-space applications and hence makesthem an overall attractive research platform The main structural advantage of the bare-bonesmulticopter is the omission of all movable parts except for n motors which signicantly reducesmechanical complexity and thereby increases mechanical robustness and maintainability

311 Multicopter ight principle

The vehicle possesses 6 degrees of freedom for movement in space and n actuators On the quadrotortwo rotors are turning clockwise or counter-clockwise respectively Equal rotation rates result inoverall equalisation of torque Changing the rate of one set of co-rotating rotors relative to the othera torque about the vehicle vertical axis is induced and it turns (yaw) Changing the rate relation

5

(a) Quadrotor helicopter (b) Coaxial helicopter

(c) Fixed wing yer (d) Flapping wing yer

Figure 2 Dierent possible airframe types for ying robots a) experimental workhorse Horst b)E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c) Multiplex FunJetphotograph from Paparazzi Wiki by Matthew Currie d) Flapping wing platform photograph byHenryk Ploumltz also with permission

among two co-rotating rotors induces a torque about the perpendicular horizontal axis Both pitchand roll movements are eected in this way in a symmetrical manner By pitching or rolling thethrust vector is deected from the pure vertical direction and the vehicle accelerates laterally Formore details on the working principle and modelling of multirotors see for example [5] [14] or [11]At the level of the individual acutators the system is not manually controllable For this reasonInertial Measurement Units (IMU) are used to realise electronic control of the vehicle attitude AnIMU is a set of sensors that provides information about orientation in space by measuring angularrates acceleration and magnetic forces over three orthogonal axes The attitude control setpointsin turn can be aected by manual or high-level autonomous control input The control vector thusis given by

uT = (pitch roll yaw thrust) (1)

While the principles of inertial navigation have been applied for decades in control of aerial vehi-

6

(a) MMALV 1 (b) MMALV 2

(c) Paparazzi dual airfoil quadrotor taking o (d) Dual airfoil quad after transition to forwardight

Figure 3 Some less prevalent airframe congurations a) and b) Morphing Micro Air and LandVehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobots LLC and Roger Quinnof Case Western Reserve University and c) and d) a Paparazzi based quadrotor with two airfoils(tail sitter design) The pictures are two frames extracted from a video by Antoine Drouin JobyRobotics with kind permission

cles with both analog and digital implementations of the control schemes [12] the use of lightweightlow-cost-and-quality inertial sensors at the same time enables the construction of Micro AerialVehicles (MAV) and poses challenges for the accuracy of the resulting solutions The general ap-proach is to use a complementary system of high-frequency angular rate sensing (gyroscopes) andlow-frequency compensation via acceleration measurements (acceleromoters) In addition informa-tion from magnetic measurements can be incorporated into the attitude estimation if a 9-Degressof Freedom (DoF) IMU is available

312 The robot body

The airframes cited above are examples of FR bodies A brief consideration of some consequencesof the specic conguration is in order The relevant aspects are geometry surface and propulsionGeometry and surface as well as motion type relate to where and how the sensors can actually bemounted In xed winged platforms there is a prefered direction of motion whereas the quadrotordisplays a four-fold structural symmetry and the vehicle front needs to be arbitrarily set Mounting

7

a forward-pointing camera clearly breaks the symmetry in regards to vision based navigation Apossible solution is downward orientation or the use of panoramic lenses see Figure 23

In order to measure the distance to the ground only the downward pointing body surface needsto be considered for sensor mounts (although see GDC below) Obviously acoustic and optical rangesensors need to be unobstructed by other body parts Deviations in range measurements due to non-zero pitch and roll angles during ight are regarded as disturbances in the controller sketched belowThis is in part justied by the nite beam-width of the sonar sensor which intrinsically measuresthe shortest path to a reecting surface Since the absolute error grows linearly with range and theinfrared sensors used here only have very limited range (lt 1m) the deviation is not compensatedeither The scenario is illustrated in Figure 4 the theoretical error for dierent angles and aboslutedistances is plotted in Figure 5 Some more dynamic types of interactions are considered below

θ

e

Figure 4 Distance measurement depending on the angle θ to the ground surface

0 10 20 30 400

200

400

600

Angle [deg]

Error

[mm]

Alt 05 mAlt 1 mAlt 15 mAlt 2 m

Figure 5 Theoretical error over angle for several dierent distances from ground

8

32 Quadrotor systems overview

The quadrotor was conceived in the 1920ies bei Etienne Oehmichen and purportedly ew onlya couple of meters at the time probably due to the manual control problem The concept washibernating for most of the 20th century to resurface as an electronic toy in 1996 The Roswellyer of Area51 Technologies seems to be the earliest appearance of a working miniature quadrotorRC yer [13] Since then development of similar systems has picked up momentum considerablyBy now (2011) there exist a number of projects that are suitable (if not specically designed) asrobotics research platforms of which this section provides an overview The projects backgroundsvary from robotics and remote sensing to hobbyist RC model-ying and electronic toys

While not exclusively targeted at multicopters one of the oldest eorts to develop a versatileand open UAV system (airborne and ground segments) for model yers is the Paparazzi (PPZ)1 project of the Ecole Nationale de lAviation Civile (ENAC) The project was founded in about2003 2 and consists of an extensive set of both hardware and software components The airbornehardware consists of a variety of base processor boards (Tiny TWOG LisaLM) sensor modulesand communication devices The control software consists of a stack of PID control loops whichare executed on the microcontroller boards The overall approach reects a certain outdoor anityConsequently one of the architectures distinctive features is the use of IR thermophiles for absoluteorientation sensing (warm earth cold sky) in outdoor environments Complementing the airbornepart of the project is a comprehensive set of ground segment software and simulation modules Thiscomprises tools for tasks such as logging plotting map-supported on-screen trajectory trackingas well as eg vehicle tracking for servo-controlled directional antennas Communication amongcomponents is realised via the text- and subscription-based IVY software bus 3 which serves as thepoint of entry for component reuse from foreign systems Paparazzi also supports a high-level XMLbased ight-plan description and airframe conguration language Overall the PPZ system oersa mature codebase and a great amount of exibility through open source licensing and a modulardesign

Founded in 2006 the MikroKopter (MK) 4 project quickly gathered momentum in Germany asan RC model-ying vehicle and aerial photography system It is the system used for all experi-ments described in this work The MK architecture is a modular system that can be bought as a kitfrom the producer and consists of a combined IMU and microprocessor board called FlightCtrl (FC)which runs the attitude control software (also FlightCtrl) In fact there are several versions of theFC featuring dierent processors and sensors In addition the project has brought forth specialElectronic Speed Controllers (ESC) which interface control output on a TWI with brushless motorscalled MK-BL The distinctive feature of these controllers is the particularly high update-rate com-pared other other ESCs Consequently the MK-BL are used across many of the other projects seealso Table 1 Optional sensor modules include a compass and GPS components The main factorsfor choosing this particular system were its ready availability at the time of project initiation in2008 cost and source code access The ground and support software for the MikroKopter on theother hand is not ideally suited to demands in robot prototyping There have been attempts atdeveloping open-source and cross-platform alternatives to the vendors MikroKopter Tool althoughin the experiments described below yet other tools were used

1Paparazzi Wiki httppaparazzienacfrwikiMain_Page2httpwwwnongnuorgpaparazzigallery_v0html3Ivy Bus httpwww2tlscenafrproductsivy4MikroKopter httpwwwmikrokopterde

9

Published in late 2008 (according to the Internet Archive) the PIXHAWK (PXH) 5 project ofthe Computer Vision and Geometry Lab at the ETH Zuumlrich is an example of a system designedfrom the ground up as a robotic research platform in this case specically targeted towards visionexperiments PXH also has its own integrated processorIMU module as well as adapter hardwarefor using miniature yet high-capacity computing hardware sometimes referred to as Computer onModule (COM) The software part of the system features a comprehensive groundstation softwarecalled QGroundControl (QGC) and a low overhead communication protocol calledMAVLink 6 Sev-eral other components are provided or are in development The systems components are publishedunder open licenses and the software parts can easily be reused and adapted

Another interesting addition from around 2010 to the growing family of quadrotor systems is theArduCopter (AC) 7 which is designed on top of a more generic autopilot for both xed-wing androtary-wing platforms the ArduPilotMega (APM) 8 which in turn is based on the popular Arduino9 meta-platform The ArduPilot software already makes use of PXHs groundstation QGC throughthe MAVLink protocol In distinction to the projects mentioned so far ArduCopter uses standardunmodied low-cost ESCs for motor control which reects the general low-cost approach of theentire system This approach is most promising in terms community engagement Other relevantprojects in this category are the Unmanned Aerial Video Platform Next Generation (UAVP-NG)10 and OpenPilot 11 projects Both feature co-designed hardware and software but both have notbeen considered more closely due to their state of development during 2010 12

Among the straightforwardly commercial vendors there are two types those targeting profes-sional use outside the RC model community and those attending to the electronic toy marketThe former are mainly used for standard security and surveillance related activities In europethese are Ascending Technologies (AscTec) and microdrones AscTec models also appear in roboticsresearch but require much higher budgets The prominent representatives from the latter categoryare the DraganFlyer of RCToys whose ancestry goes back to the Roswell yer mentioned earlierand most recently the Parrot ARDrone released in 2010 featuring onboard Linux two camerasstabilisation with optical ow and an SDK for custom extensions

321 Systems summary

All these systems dier with regards to sophistication and extendability and clearly none of themprovides out-of-the-box the type of onboard computing system desired for a robotic experimentalframework targeting high-bandwidth signal processing In heterogenous multi-vehicle systems is-sues of interoperability and code-reusability can be expected to become more salient Often easeof use in terms of development and prototyping is traded o for eciency and compact hardwarewhich makes the implementations quite idiomatic

By taking a modularised approach as regards the hardware and employing in the sense ofreusability and ease of programming more powerful Single Board Computers (SBC) or COMscapable of running an operating system dierent systems providing the basic attitude control

5Pixhawk httpwwwethzchpixhawk6MAVLink httpwwwqgroundcontrolorgmavlinkstart7Arducopter httpcodegooglecomparducopter8ArduPilotMega httpcodegooglecompardupilot-mega9Arduino httpwwwarduinocc10UAVP-NG httpnguavpch11OpenPilot httpopenpilotorg12By 2011-06-09 Thu both projects status has considerably advanced

10

such as those mentioned above can be used and wired up with more capable hardware to conductexperiments with a wide range of sensors and algorithms This necessitates the integration of severaldierent downlink and communication frameworks that are in use across dierent systems

One practical option for this part of the system while keeping reusability ease of developmentand energy requirements in mind are ARM-based Linux packages such as the Gumstix or Beagle-board families or similar devices which are available at reasonable prices In summary these werethe considerations that are accumulated in the current state of the HUCH setup described belowThe diverse FR projects can be categorised along an axis indicating the level of targeted behaviourranging from low-level actuator control up to high-level navigation and high performance signalprocessing functionality Table 1 is a graphical representation showing the projects hardware andsoftware components coverage along that axis

Motor Attitude GPS Ground High-perf

UnspecStd PWM ESCs

AscTecDragoncopter

MK MK-BL Flight-Ctrl MKNAV MK-ToolPXH pxIMU via COM QGC COMPPZ TWOG Tiny Lisa GCS COM w LisaAC ArduPilot AC-GS

HUCH COMs

Table 1 Systems overview Of course it is almost always possible to attach a COM to low-levelattitude control platform such as the MK-FC ArduPilotMega or PPZ autopilots over a serialinterface Both PXH and PPZ are designed for use with Gumstix COMs

33 HUCH Sytem

331 Basics

The HUCH project was started to test bio-inspired navigation strategies on ying robots Theproject was initially equipped with basic MK kits The MK is mainly being used for RC modelying and aerial photography but the user community is also active with various other experimentsregarding extentions and modications The platforms distinctive advantages are its price readyavailability and sucient openness for research uses 13 Several academic projects have made orstill make use of the MikroKopter platform

The core component of the MK setup is the FlightCtrl (FC) comprising of both a Printed CircuitBoard (PCB) featuring an IMU a microcontroller and the rmware implementing the attitudestabilisation RC interface telemetry and more The MK architecture also features ESCs (MK-BL) capable of receiving the actuating variable via a TWI interface at a rate of 500 Hz which marksa dierence to other ESCs available on the RC market For that reason the MK-BL is also widelybeing used in many other projects

13Although with recent versions of the FlightCtrl rmware this has started to change

11

Direction Code Command Arguments

Inb Submit external control extctrl structc GyroBaro neutral Noned Request debug vector Update interval or None for one-om Start motors Nonen Kill motors None

OutD Debug vector 32 int16 values

Table 2 Five most important HUCH commands for external control of the modied MK-FC

332 Modications

Software The HUCH group has developed various extensions and modications to the platformOne of these is an expansion of the external control interface see Table 2 via the UART a corre-sponding groundstation (mcut) and control software (mktool) These are the basis for most of thework described in the remaining part of this text

The FlightCtrl microcontroller rmware was modied (HUCH variant) initially based on killa-gregs rewrite of the original rmware and implements among other things the extended communi-cation protocol higher UART baudrates TWI sensor integration and several more items 14 Thereexists a tool 15 to realise realtime display and plotting of debug variables ashing of MikroKopterrmware with embedded avrdude code parameter editing and motor testing The MKcom pro-gramm was initially developed for using a CMUcam to control the MikroKopter from vision inputIt features the basic FC communication stack and a control console This last item served as thebasis of the rst prototype of a Linux based altitude control At the time of writing develop-ment of these tools has been abandoned in favor of Micro Aerial Vehicle Humboldt Universitaumlt zuBerlin (MAVHUB) which is described in more detail elsewhere [25]

Computing hardware To overcome the severe restrictions of the Atmel ATMega644 being usedon the FC it is necessary to attach additional processing hardware Stating it more simply a singlemicrocontroller clearly is not suitable for any kind of slightly more demanding processing For thispurpose to date dierent single board systems have been used the Gumstix Verdex Pro 16 andBeagleboard variants 17 as can be seen in the gures 6 and 7 Several other options are availableand could be utilised in the future as our approach is construed exible in this regard Working ona Linux system provides a huge advantage in abstracting the algorithms from the hardware TheLinux system is connected to the FlightCtrl via the UART port In order to achieve a sampling rateof 100 Hz a baudrate of 230400 kbaud needs to be set on this connection The DebugOut messagestructure counts 95 bytes on the wire The motor command takes up 22 bytes giving 117 bytes forone sense-act cycle At the given channel capacity (25600 bytes per second) this gives approximately

14HUCH FlightCtrl 071i httpkoroinformatikhu-berlindeqkdownloadsV071i_huch-code_motodrone09targz

15mcut httpkoroinformatikhu-berlindeqkdownloadsmcuttargz16Gumstix Verdex Pro httpwwwgumstixcomproductverdex-pro17Beagleboard httpwwwbeagleboardorg

12

218 full cycles per second under optimal conditions and should be sucient for processing at 100Hz There are problems with nding higher baudrates that are supported on both sides of theconnection due to the 20 MHz clocking of the microcontroller

(a) Verdex View 1 (b) Verdex View 2

Figure 6 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below andthe expansion board on above On top is a USB WiFi dongle

A custom ATMega based ADC expansion board is acting as a generic analog data aqcisitiondevice Analog measurements are multiplexed and transmitted down a Two Wire Interface (TWI)link to the main control COM In a dierent setup an Arduino Mini was substituted for the customboard

Sensors For altitude measurement three dierent sensors were added to the setup A barometricpressure sensor is already provided for in the vendor board design This sensor is quite noisy butcovers a large range of measurement When close to the ground range sensors can be used tomeasure the distance Of this type we used a Devantech SRF02 sonic range nder This sensorhas an integrated microcontroller that does time-of-ight calculations for an ultrasonic pulse andtransmits the result digitally over a two wire interface (TWI) The speed of sound vs the actualdistance determine the maximum update frequency In our experiments these were xed at a rateof approximately 50 Hz In addition we attached two Sharp type infrared rangers (GP2Y0A02YKGP2D120) to the robot These output an analog voltage inversely proportional to the distancemeasured They are connected to the expansion board which also transmits updates via TWI butat a rate of 100 Hz The physical conguration of the range sensors is depicted in Figure 8

13

Figure 7 The electronic stack on this copter consists of (in ascending order) FC Power and UARTbreakout Beagle breakout and Arduino Mini mount BeagleBoard and USB WiFi Dongle

333 Physical system

As has been described above the FC can be given actuation commands via both the RC and UARTinterfaces in the form of the four-element vector 1 The SBC used in this particular conguration isthe Gumstix Verdex Pro X6LP The gumstix receives its power supply of 5V DC from the FC andtalks to it over the FFUART without additional level converters The hardware component setupis depicted schematically in Figure 9 On the left hand side of the diagram the base MikroKoptersetup is seen with the FlightCtrl RC receiver and the four ESCs On the right hand side theVerdex and custom sensor board are situated realising highlevel control and UDPIP link to thegroundstation over WiFi For the operation of a second onboard SBC the Beagleboard in Figure 9an additional voltage controller had to be used between the 12V DC rail and the Beagleboard powersupply socket

OpenEmbedded The current gumstix system software is provided via the Aringngstroumlm 18 distri-bution which is based on OpenEmbedded 19 The gumstix overlay provides Linux kernel versions2621 and 2631 Unfortunately the driver for the gumstix onboard WLAN hardware (netvx boardw a Marvell cf25 chip) changed between those versions and the one in 2631 refuses to actually

18Angstrom Distribution httpwwwangstrom-distributionorg19OpenEmbedded httpwwwopenembeddedorg

14

Figure 8 Range sensors attached to frame

RC receiver Onboard electronics

BL1 Expansion Board

BL4 FlightCtrl BL3

BL2 Gumstix

Camera BeagleBoard

TWI

UART

TWI

Wi

LAN

USB

Figure 9 Basic HUCH onboard electronics The left hand region of the picture consisting of receiverFC and brushless motor controllers BL1minus4 represents the standard MK setup while the right handregion represents HUCH additions

work with our hardware so a dierent solution had to be found Fortunately here the USB sub-system works well out of the box and standard USB WLAN hardware could be used to set up thelink Running the system o an SD-card as well as TWI (I2C) support in Linux work well Onemore aspect of the WLAN setup is worth noting though It was desired to realise the wireless linkto the onboard Linux in Ad-Hoc mode for two reasons The rst is reduced startup time when usingAd-Hoc mode the second is independence of access point infrastructure In this way the minimalFR groundstation conguration can be operated in a more mobile manner In principle one of thenodes could be operated in Master mode but this is not supported by all hardware

Once the live Linux system and cross-compilation environment was up and running the MKcom

15

software provided the basis for further work on controller implementation Looking at the Linuxsystem at this point the following view presents itself in Figure 10

Gumstix

AringngstroumlmLinux 2631 SD

UIShell mktool wlan0

devttyS1 devi2c-0

FC Exp Groundstation

RxTx wires

Wireless link

Figure 10 Basic Linux setup

4 Experiments

41 Basic structural design through simulation

Initially the problem of altitude control was analysed in simulation To that end a simple con-troller was realised within the crrcsim 20 RC model simulator There are basically two possiblemethodological approaches to setting up a simulation for a model helicopter One is the derivationof the model from rst principles and implementation from scratch The other is building uponexisting if simplifying solutions that are practically usable and open for modication

A moderately physically realistic model of a quadrotor aerial system is governed by a nontrivialnonlinear dierential equation [3 pg 155] [4] Much microscopic detail can be added for furtherrenement as the need arises Such details are discussed to some extent in [14] and [8] In the near-hover ight regime the system behaves quasi-linearly but at more extreme velocities and attitudesthe increasing impact of several nonlinear eects such as blade apping vortex ring states orforward translational lift would have to be considered For our purposes these eects have so farbeen neglected but could in princpiple be incorporated into the model

Circumventing the necessity of model derivation and implementation the second approach waschosen In particular the existing real-time ready crrcsim [7] RC-model simulator software wasmodied to conduct the initial experiments This was particularly facilitated by the prior work ofJens W Wulf who implemented a quadrotor model and internal controller substructures for thissimulation framework [32] A screenshot of the Wulf-model ying in the modied simulation in canbe seen in Figure 11 crrcsim comes with an internal controller architecture that realises dierent

20Charles River Radio Controllers Simulation httpcrrcsimberliosde

16

attitude controllers The software originally is designed to interface manual control hardware suchas RC transmitters joysticks and such to the simulation engine It was modied to implementadditional controllers detailed state information output for plotting and analysis and networkedcontrol of the simulation engine A drawback of crrcsim is its monolithic architecture For futurework the core simulation engine would have to be separated from the render engine Alternativelythe PPZ approach could be used as a drop-in replacement

Figure 11 Simulation screenshot The helicopter model landscape and text console are part ofcrrcsim The actual debugging output that can be seen in the console is part of custom modications

411 Closed loop

The basic structure of the full control loop is displayed in Figure 12 The control module embeddedin the loop is a Single-Input Single-Output (SISO) type controller The actuating variable undercontrol is thrust which eects overall lift (see above) while the other three components are mostlycontrolled manually during the experiments The input to the controller is the current altitudeestimate The estimation process potentially has to consider multiple measurements which have tobe fused into a single representation

412 Measurements

In simulation global knowledge of the world- (and agent-) state is available and all system variablesare immediatly accessible This allows to use a simplied signal-ow structure which is depicted in

17

Measurements

z0

z1 Kalman lter Controller

Fusion Estimate PID System

znminus1

zn

throttle

Behaviour

setpoint

Figure 12 Controller structure with measurement branch

gure 13 In order for the controller to be structurally transferable to the real hardware system thespecic sensor conguration has to be modelled within the simulator This included preparationof IMU data by tapping the Flight Dynamics Model (FDM) module and basic modelling of therespective characteristics of the barometric and ultrasonic range sensors which were in use on thehelicopter at that time In the case of the barometer this meant the addition of white gaussiannoise A slow drift which can be observed on the real sensor due to slow air-pressure changes wasneglected For the ultrasonic range sensor the timing characteristic that is the maximum updaterate dependent on distance measured was emulated The information thus synthesized was fed intoa Kalman lter for further processing

Controller

PID Systemthrottle

Flight dynamics model

setpoint

Figure 13 Simplied controller structure

413 Sensor fusion

Sensor fusion is a problem class on its own The base intent is to derive an estimate of a systemstate variable from multiple measurements that is more reliable than it would be by using only asingle measurement There are several approaches which have been developed over the last decadesand which could be employed for this task The complementary lter approach can be chosen if the

18

sensors are aected by suciently dierent kinds of noise and thus eg spectrally complementarylters can be used on dierent measurement channels which are then linearily combined into a singlevalue Probably the most commonly used techniques are the linear Kalman lter and its nonlinearvariants Other methods are nonexhaustively Bayesian strategies such as Particle lters H-infinlters or neural networks A linear Kalman lter was chosen in the current setup for the reasonthat the lter and its characteristics are well documented and the implementation is straightforwardboth from scratch and even more so using matrix algebra libraries such as OpenCV The basic ltertask is to estimate the state xk isin Rn of a discrete time system governed by the linear stochasticequation [29] [15]

xk = Axkminus1 +Bukminus1 + wkminus1 (2)

based on a measurement zk isin Rm given as

zk = Hxk + vk (3)

where wk vk are random variables which represent process noise and measurement noise and arenormally distributed with zero mean p(wk) sim N(0 Q) p(vk) sim N(0 R) Q and R are the processand measurement noise covariance matrices The model used here consists of two state variablesx = (a dadt) with a the altitude (above ground) Later the model was extended to include d2adtso as to facilitate incorporation of accelerometer measurements One problem with the real sensorswas a clear deviation of the measurement noise from the assumed normal distribution and had tobe corrected for in preprocessing

414 PID controller

The Kalman lter state estimate can nally be used as the input to a PID throttle controller ThePID model used is a FOPDT integrating model The second input to the controller module is thesetpoint which can be set in the simulation via keyboard- or network-input to the application Therst working PID parametrisation was arrived at through manual tuning which is cumbersome andgives suboptimal results

415 Evolutionary parameter tuning

To prove the concept of using online learning within simulation at least the PID parameters wereoptimised using evolutionary strategies [22] [26] The tness function for this experiment wasconceivably simple chosen as

f(i) =

Nsum0

|xset minus xik| (4)

with individual i (a tuple (P ID)) setpoint xset the experiments duration in time steps N andthe altitude xik at time step k resulting from execution of controller i This stage involved setting upthe system so that simulation state and model parametrisation (the P I and D coecients) could

19

be controlled programmatically It was realised over a UDPIP connection between crrcsim andthe external simctrl control shell 21 implemented in the Python language 22 The results of theexperiment have been presented in [10]

42 MKcom2

MKcom short for MikroKopter communication tool was designed as a minimal software layer tosit on top of the UART communication link to the main ight board It provides a console baseduser interface for activation and conguration of a set of thin control functions and can act as agateway between the FC and a CMUcam MKcom functions can send commands to the FC andincoming UART packets are dispatched to the appropriate message handler This tool implementedthe modied MK message set

The setup was used as the basis for prototyping several versions of the control loop structureoutlined in Figures 12 and 13 The internal organisation of these implementations can be seenin Figure 14 Three dierent controller cores were realised which incrementally incorporated moremeasurement channels heuristic detail and safety hooks The detailed ow structure of the controllerdesign will be outlined below The update rate and execution timings are dictated by the arrivalof the measurement vector from the FC Auxiliary sensors were integrated asynchronously into themain loop A custom groundstation for state logging and realtime plotting was connected to thenetwork downlink indicated in the diagram

421 MKcom2 Flow structure

On startup a request for debug structure emission is sent manually from the mkcom shell to the FCwith the debug n command where n is the desired sampling interval in milliseconds An examplesession excerpt looks (slightly beautied) as follows (`gt indicates the shells command prompt `is the startsign of the MK protocol strings starting with ` is the raw ascii data going over thewire)gt debug 100

tx bdV ===Ds

gt

rxbuf 93 bD===IgtpU gtomgtS=xTyf=DL|pA= gt===Kl|Lnx=mL=I===i=BM|| oXfT_UrePI=T]=gt==E=|l|

L=IE||y===Y=qM

_DebugOut_ 1804 310 203 854 -843 420 -49 49 4

2 -21-1016 123 828 828 0 11 21

-1-5850 9822 -24267 51 94 1 2 -2

207 706 -1 0 7

rxbuf 93 bD===ggtpi gtm=gtT=oxzd]DL|o===m=A=Kl|ALnx=mL=I===E=m=== KxYSourePI=T]====A===

L=IM||y===Y=nf

_DebugOut_ 1834 315 192 855 -722 414 -49 32 3

4 -21-1008 123 828 828 0 2 15

0 -897811867-24267 51 94 0 1 0

207 708 -1 0 7

gt debug 0

tx bd====DZ

gt

21httpwww2informatikhu-berlinde~obertholQK22Python Language httpwwwpythonorg

20

The debug vector is populated in the FC where element positions correspond with value typesIt includes IMU data manual control input from the RC and the barometer as well as systemstatus values such as battery voltage RSSI value ampc Depending on the setup it can include thereading from the sonar as well If the actual controller is activated with eggt ac3 1

kal_cv_init DP 3 MP 5 CP 0

gt

the controller evaluation function is executed upon each arrival of a debug packet Of coursesome information is retained across calls After computation has nished an extctrl (Externalcontrol) structure is populated and sent back to the FC Aditional measurements such as from anInfraRed Ranger (IRR) are integrated in an asynchronous manner from multiple threads Severalparameters such as the altitude setpoint PID values bias ampc can also be set from the text based userinterface While this works quite well in principle and did achieve good performance modularityand extensibility were not an initial design goal This led to another iteration of the same designwithin the MAVHUB framework which will be described in the next subsection

IO Channels UART TWI UI Network

HAL threads FC-RX Expansion Ctrl Sonar Shell

Processing Controller

mkcom2

Figure 14 Mkcom2 ow-graph

43 Heuristically tuned altitude control software

The vague vision of the overall architecture that is pursued here is that of several concurring moduleswhich are summed in a cooperative time-dependent manner and where each module is responsiblefor various behavioural aspects [1] To ease prototyping and testing of components the structurehas to be kept exible extensible and dynamically recongurable This has to be considered in theoverall onboard software design In order to illustrate this requirement the ow of information andthe interaction with additional behavioural modules will be described in more detail in the followingparagraphs References will be made to several modules operating within the MAVHUB frameworkthe basics of which are described elsewhere [25]

431 Data acquisition

First the controlware has to collect all sensory information from possibly heterogenous sourcesThese include 6 - 9 channels of IMU data (depending on IMU type) a barometric measurementseveral range sensors as well as optical sensors (cameras) and of course any other sensor which is

21

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

1500

2000

Time [s]

Value

throttle

uss_meas

k_s0

Figure 15 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m aboveground The dashed line is the raw sonar range value the solid black line is the estimate uponwhich the PID controller acts The solid green line in the lower part of the plot is the controlleroutput value which is sent to the actuator

available or desired Heterogeneity pertains to hardware channels update rates and data formatsIn MAVHUB there are two main channels if information ow One is the protocol stack whichtransmits volatile incoming messages to all active modules (apps) The other is a shared memoryarea where data can be deposited by any active process In the setup considered here FC data(including IMU barometer and possibly sonar) and intermediate internal data travel on the stackSensors connected via a two-wire bus are operated by sensor drivers and measurements are put intothe shared memory The desired result of this step is to be able to operate on a homogenous vectorof input signals within the main control loop

432 Preprocessing

Subsequent to acquisition each sensory channel is individually preprocessed according to the pe-culiarities of sensor principle and connection mode Preprocessing mostly consists of linearisationunit conversion (inverting the sensor characteristic) and several kinds of heuristic validation

Linearisation For this particular setup linearisation only has to be done for the IRRs Theseare analogue sensors and the output voltage is related to the distance s measured via u(t) = 1

s(t) An example sensor characteristic is displayed in Figure 16 For the dierent subtypes of the Sharpsensors an individually parameterised procedure has to be performed as described by eg Acroname

22

Robotics in [23] if the sensors are processed on a metric basis If the Sharp sensors are driven atthe recommended supply voltage of 5V using the datasheet specications has proven sucientlyaccurate An example script for determining the parameters from given calibration data is suppliedon this reports supplementary website 22

Unit conversion The diverse units of sensor data have to be explicitly converted to units conve-nient for later steps in the calculation in particular sensor fusion with the Kalman lter For thealtitude measurements these are metersminus3 so ADC-units or time-of-ight measurements have to beconverted to millimeters for the analog sensors (barometer accelerometer infrared) and the sonarsensor repsectively This simply amounts to a multiplicative factor

Validation Heuristic sensor data validation has to be done for all types of rangers as well as for thebarometric sensor The spurious readings these sensors produce are of dierent types though Theinfrared rangers display ambigouity beyond the lower limit of the operating ranges see Figure 16For the GP2D120 which can sense the smallest ranges of all sensors this can be mostly neglectedsince the minimal sensing range can hardly be reached due to the mechanical conguration Forall the other sensors output is surpressed when the GP2D120 is active At the upper limit of theIRRs operating range the output is surpressed when a suitable threshold is reached The followingcode example illustrates this where sensor channel number three is the close range IRR

if(in_range(sensors [3] first llim ulim))

valid = 10

else

valid = 00

sensors [3] second = (fir[3]-gtcalc(valid) gt= 099) 1 0

Surpression is realised by setting appropriate values in the measurement transform matrix H(t)of the Kalman lter Alternatively this could be done by generating suitable variances for therespective sensors in the measurement covariance matrix R(t) Driving the IRRs at 33V works butreduces the usable range In addition the IRR sensor measurements are dependent on the groundsurfaces some of which eg an oce carpet can result in erratic results

The ultrasonic sensor is susceptive to dierent kinds of spurious readings caused by late echoesThis happens both when very close to an object or surface or when far away that is beyond theupper limit of measurable distances The validation strategy employed is to set hard empiricallower and upper limits for values as for the IRRs and limiting the maximum dierence betweentwo consecutive values based on assumptions about the maximum velocity An example session isillustrated in Figure 18

Finally the barometer is sensitive to acceleration which has to be accounted for The sensorbehaviour is displayed in Figure 19 The empirical corrections read

BARO (pre [1] correct from accel -z (pre [2])

pre [1] first -= (005 pre [2] first)

The validition process in general produces one new signal per channel to be used later in theprocess for setting Kalman lter matrix values One remaining problem here is the channel cross-dependency

23

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 3: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

level control This setup comprises of a basic quadrotor kit augmented with an embedded Linuxsystem with an eye on self-suciency

2 Introduction

21 Flying robots

Architectures for autonomous control and navigation on ying robots or Unmanned Aerial Vehicles(UAV) as they are more commonly referred to currently are a very active area of research in roboticsMostly enabled by advances in battery technology and miniaturised sensor and computing hardware[5] or in other words by an aordability boost resulting mostly from developments in the mobilecommunication market it has been increasingly possible in recent years to construct ever moresophisticated ying machines in low-budget settings and of very small sizes whereby following moreor less diverging design strategies Various civilian applications and devices are being investigated bythe research and hobbyist communities FR also generally add to the arsenal of vehicles employablein basic research in robotics while posing some particular challenges for stabilisation and navigationbecause of increased timing constraints for realtime performance payload constraints and generalvehicle dynamics

22 Navigation problem

All mobile autonomous agents have to somehow cope with the problem of navigation In small yingrobots it becomes particularly acute because of static instability and with some morphologies thenecessity of motion for remaining aloft While the basic attitude control problem for quadrotors (andother types of FR) seems adequately solved both theoretically [6 20 21] and practically (see thesystems listed) below position and egomotion estimation and related capabilities that do not relyon external reference systems such as Global Positioning System (GPS) or indoor optical trackingare not available o the shelf

23 Bio-inspired robotics

Since robust autonomous navigation on mobile robots in uncontrolled environments already is ahard problem on the ground it makes sense methodologically to draw inspiration from how naturalorganisms solve some of the relevant problems which obviously they do While it is clear thatcurrent technology cannot produce the type of hardware used in the self-reproducing organismsthat populate the environment it is still possible to glean relevant solutions with respect to sensorymodalities motori-sensor arrangements and models of cognition founded on top of the former two Aside-import of this approach is the possibility to verify models from theoretical biology [1 p32] [18]Bio-inspired robotics is a methodological approach in robotics and has successfully been applied inwork with ground-based [18] aquatic and ying robots [34] [9] Indeed this approach can be tracedback to the beginnings of electronic computing in the 20th century which approximately coincidewith the inception of cybernetics and information theory in the 1940ies [27 30 28] Anotherrelated point of view is the discipline of bionics in general engineering The work presented in hereis part of an eort to establish an open ying platform for experiments with bio-inspired navigationstrategies and the experiments presented serve as examples for a general approach to prototypingsuch strategies by covering some of the relevant componentry procedures and problems

3

24 What is a Controller

A controller is a well dened term in control theory [16] In this work the term controller designatesthe overall hardware and software aggregate which generates real-time behaviour on the robot Incontrast to concerns of control theory a good part of this aggregate is used up by sensor acquisitionand preprocessing to realise endemic onboard state estimation capabilities with an adequate degreeof correlation to environmental conditions

25 What is altitude control

Altitude here is used as some sort of measure for the distance of the robot from the ground Forvehicles that are able to hover this is the most important variable to be controlled It enables therobot to take o from the ground and either maintain a certain distance to the ground or to maintaina certain rate of ascent and more generally keep clear of a large object or bounding surface

In a simulated environment with a perfectly at oor the question hardly arises On a physicalsystem travelling over fractally ragged ground the question does become more intricate Severalfactors are interacting such as overall type of desired behaviour desired speed relative to theenvironment to objects in the environment and the spatiotemporal dynamics of sensor responses

Several dierent behaviours have been investigated and some of them prototyped These areterrain following absolute altitude stabilisation see Figure 1 and vertical rate control The formertwo emerge from the sensor reponse dynamics Depending on wether the robot is within rangeabledistance of an object or surface a valid range measurement overrides and resets the absolute altitudeinformation Vertical rate on the other hand can be directly extracted from an onboard camerausing optic ow estimation Some notable work has been done on purely optic-ow based autopilotsby N Franceschini Franck Ruer and others [24]

A purely egocentric sensory setup is used in contrast to many other approaches in FR work whichrely on GPS for outdoor deployment and optical tracking in indoor scenarios While the resultsclearly justify a third person approach to robotics the importance of reliable endemic sensing isprobably underestimated

26 About this text

The rest of the text is organised as follows In the systems section basic aspects and components ofFRs in general will be described and some of the existing low-cost UAV system are dissected andpresented in more detail

The consequent section will present the details of some experimental controller modules for aquadrotor implemented on an onboard Linux system This includes discussion of an approach tosimulation as well as the presentation of particular controllers on real hardware The terminal partof the text will summarise the results and sketch some possible routes for further development ofthe system

The work was being conducted in 201011 within the bio-inspired navigation project under thesupervision of Prof Verena Hafner of the Cognitive Robotics group at the Department of ComputerScience of the Humboldt-Universitaumlt zu Berlin

4

(a) Absolute altitude

(b) Terrain following obstacle avoidance

Figure 1 In 1(a) the robot maintains and absolute altitude The range sensors are either surpressedor the robot is too far away from the ground to be able to measure the distance In 1(b) the robotfollows the contour of the terrain

3 Systems

31 Airframes

There are many dierent types of FR only some examples of which can be seen in Figure 2 andFigure 3 Fixed wing apping wing and rotary wing yers have emerged as the most frequentlyused classes of motor powered yers on large and small scales All of these generate lift throughtheir whole body- or component-dynamics (rotors) Dynamic lift is contrasted by balloons airshipsand blimps which are statically buoyant but generally suer from reduced maneuverability andwind susceptibility In between there are all sorts of hybrids which are not easily classied forexample robots capable of hybrid modes of locomotion such as the MMALV [2 9] or VerticalTakeO and Landing (VTOL) vehicles with pivoting rotors or airfoil elements [33 Tail sitter]The remaining part of this work is concerned exclusively with multirotor helicopters (multicopters)although regarding the framework there are many commonalities across all types of yers

Helicopters in general have the advantage of being capable of near-holonomic motion and hov-ering which gives them a certain edge in indoor or constrained-space applications and hence makesthem an overall attractive research platform The main structural advantage of the bare-bonesmulticopter is the omission of all movable parts except for n motors which signicantly reducesmechanical complexity and thereby increases mechanical robustness and maintainability

311 Multicopter ight principle

The vehicle possesses 6 degrees of freedom for movement in space and n actuators On the quadrotortwo rotors are turning clockwise or counter-clockwise respectively Equal rotation rates result inoverall equalisation of torque Changing the rate of one set of co-rotating rotors relative to the othera torque about the vehicle vertical axis is induced and it turns (yaw) Changing the rate relation

5

(a) Quadrotor helicopter (b) Coaxial helicopter

(c) Fixed wing yer (d) Flapping wing yer

Figure 2 Dierent possible airframe types for ying robots a) experimental workhorse Horst b)E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c) Multiplex FunJetphotograph from Paparazzi Wiki by Matthew Currie d) Flapping wing platform photograph byHenryk Ploumltz also with permission

among two co-rotating rotors induces a torque about the perpendicular horizontal axis Both pitchand roll movements are eected in this way in a symmetrical manner By pitching or rolling thethrust vector is deected from the pure vertical direction and the vehicle accelerates laterally Formore details on the working principle and modelling of multirotors see for example [5] [14] or [11]At the level of the individual acutators the system is not manually controllable For this reasonInertial Measurement Units (IMU) are used to realise electronic control of the vehicle attitude AnIMU is a set of sensors that provides information about orientation in space by measuring angularrates acceleration and magnetic forces over three orthogonal axes The attitude control setpointsin turn can be aected by manual or high-level autonomous control input The control vector thusis given by

uT = (pitch roll yaw thrust) (1)

While the principles of inertial navigation have been applied for decades in control of aerial vehi-

6

(a) MMALV 1 (b) MMALV 2

(c) Paparazzi dual airfoil quadrotor taking o (d) Dual airfoil quad after transition to forwardight

Figure 3 Some less prevalent airframe congurations a) and b) Morphing Micro Air and LandVehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobots LLC and Roger Quinnof Case Western Reserve University and c) and d) a Paparazzi based quadrotor with two airfoils(tail sitter design) The pictures are two frames extracted from a video by Antoine Drouin JobyRobotics with kind permission

cles with both analog and digital implementations of the control schemes [12] the use of lightweightlow-cost-and-quality inertial sensors at the same time enables the construction of Micro AerialVehicles (MAV) and poses challenges for the accuracy of the resulting solutions The general ap-proach is to use a complementary system of high-frequency angular rate sensing (gyroscopes) andlow-frequency compensation via acceleration measurements (acceleromoters) In addition informa-tion from magnetic measurements can be incorporated into the attitude estimation if a 9-Degressof Freedom (DoF) IMU is available

312 The robot body

The airframes cited above are examples of FR bodies A brief consideration of some consequencesof the specic conguration is in order The relevant aspects are geometry surface and propulsionGeometry and surface as well as motion type relate to where and how the sensors can actually bemounted In xed winged platforms there is a prefered direction of motion whereas the quadrotordisplays a four-fold structural symmetry and the vehicle front needs to be arbitrarily set Mounting

7

a forward-pointing camera clearly breaks the symmetry in regards to vision based navigation Apossible solution is downward orientation or the use of panoramic lenses see Figure 23

In order to measure the distance to the ground only the downward pointing body surface needsto be considered for sensor mounts (although see GDC below) Obviously acoustic and optical rangesensors need to be unobstructed by other body parts Deviations in range measurements due to non-zero pitch and roll angles during ight are regarded as disturbances in the controller sketched belowThis is in part justied by the nite beam-width of the sonar sensor which intrinsically measuresthe shortest path to a reecting surface Since the absolute error grows linearly with range and theinfrared sensors used here only have very limited range (lt 1m) the deviation is not compensatedeither The scenario is illustrated in Figure 4 the theoretical error for dierent angles and aboslutedistances is plotted in Figure 5 Some more dynamic types of interactions are considered below

θ

e

Figure 4 Distance measurement depending on the angle θ to the ground surface

0 10 20 30 400

200

400

600

Angle [deg]

Error

[mm]

Alt 05 mAlt 1 mAlt 15 mAlt 2 m

Figure 5 Theoretical error over angle for several dierent distances from ground

8

32 Quadrotor systems overview

The quadrotor was conceived in the 1920ies bei Etienne Oehmichen and purportedly ew onlya couple of meters at the time probably due to the manual control problem The concept washibernating for most of the 20th century to resurface as an electronic toy in 1996 The Roswellyer of Area51 Technologies seems to be the earliest appearance of a working miniature quadrotorRC yer [13] Since then development of similar systems has picked up momentum considerablyBy now (2011) there exist a number of projects that are suitable (if not specically designed) asrobotics research platforms of which this section provides an overview The projects backgroundsvary from robotics and remote sensing to hobbyist RC model-ying and electronic toys

While not exclusively targeted at multicopters one of the oldest eorts to develop a versatileand open UAV system (airborne and ground segments) for model yers is the Paparazzi (PPZ)1 project of the Ecole Nationale de lAviation Civile (ENAC) The project was founded in about2003 2 and consists of an extensive set of both hardware and software components The airbornehardware consists of a variety of base processor boards (Tiny TWOG LisaLM) sensor modulesand communication devices The control software consists of a stack of PID control loops whichare executed on the microcontroller boards The overall approach reects a certain outdoor anityConsequently one of the architectures distinctive features is the use of IR thermophiles for absoluteorientation sensing (warm earth cold sky) in outdoor environments Complementing the airbornepart of the project is a comprehensive set of ground segment software and simulation modules Thiscomprises tools for tasks such as logging plotting map-supported on-screen trajectory trackingas well as eg vehicle tracking for servo-controlled directional antennas Communication amongcomponents is realised via the text- and subscription-based IVY software bus 3 which serves as thepoint of entry for component reuse from foreign systems Paparazzi also supports a high-level XMLbased ight-plan description and airframe conguration language Overall the PPZ system oersa mature codebase and a great amount of exibility through open source licensing and a modulardesign

Founded in 2006 the MikroKopter (MK) 4 project quickly gathered momentum in Germany asan RC model-ying vehicle and aerial photography system It is the system used for all experi-ments described in this work The MK architecture is a modular system that can be bought as a kitfrom the producer and consists of a combined IMU and microprocessor board called FlightCtrl (FC)which runs the attitude control software (also FlightCtrl) In fact there are several versions of theFC featuring dierent processors and sensors In addition the project has brought forth specialElectronic Speed Controllers (ESC) which interface control output on a TWI with brushless motorscalled MK-BL The distinctive feature of these controllers is the particularly high update-rate com-pared other other ESCs Consequently the MK-BL are used across many of the other projects seealso Table 1 Optional sensor modules include a compass and GPS components The main factorsfor choosing this particular system were its ready availability at the time of project initiation in2008 cost and source code access The ground and support software for the MikroKopter on theother hand is not ideally suited to demands in robot prototyping There have been attempts atdeveloping open-source and cross-platform alternatives to the vendors MikroKopter Tool althoughin the experiments described below yet other tools were used

1Paparazzi Wiki httppaparazzienacfrwikiMain_Page2httpwwwnongnuorgpaparazzigallery_v0html3Ivy Bus httpwww2tlscenafrproductsivy4MikroKopter httpwwwmikrokopterde

9

Published in late 2008 (according to the Internet Archive) the PIXHAWK (PXH) 5 project ofthe Computer Vision and Geometry Lab at the ETH Zuumlrich is an example of a system designedfrom the ground up as a robotic research platform in this case specically targeted towards visionexperiments PXH also has its own integrated processorIMU module as well as adapter hardwarefor using miniature yet high-capacity computing hardware sometimes referred to as Computer onModule (COM) The software part of the system features a comprehensive groundstation softwarecalled QGroundControl (QGC) and a low overhead communication protocol calledMAVLink 6 Sev-eral other components are provided or are in development The systems components are publishedunder open licenses and the software parts can easily be reused and adapted

Another interesting addition from around 2010 to the growing family of quadrotor systems is theArduCopter (AC) 7 which is designed on top of a more generic autopilot for both xed-wing androtary-wing platforms the ArduPilotMega (APM) 8 which in turn is based on the popular Arduino9 meta-platform The ArduPilot software already makes use of PXHs groundstation QGC throughthe MAVLink protocol In distinction to the projects mentioned so far ArduCopter uses standardunmodied low-cost ESCs for motor control which reects the general low-cost approach of theentire system This approach is most promising in terms community engagement Other relevantprojects in this category are the Unmanned Aerial Video Platform Next Generation (UAVP-NG)10 and OpenPilot 11 projects Both feature co-designed hardware and software but both have notbeen considered more closely due to their state of development during 2010 12

Among the straightforwardly commercial vendors there are two types those targeting profes-sional use outside the RC model community and those attending to the electronic toy marketThe former are mainly used for standard security and surveillance related activities In europethese are Ascending Technologies (AscTec) and microdrones AscTec models also appear in roboticsresearch but require much higher budgets The prominent representatives from the latter categoryare the DraganFlyer of RCToys whose ancestry goes back to the Roswell yer mentioned earlierand most recently the Parrot ARDrone released in 2010 featuring onboard Linux two camerasstabilisation with optical ow and an SDK for custom extensions

321 Systems summary

All these systems dier with regards to sophistication and extendability and clearly none of themprovides out-of-the-box the type of onboard computing system desired for a robotic experimentalframework targeting high-bandwidth signal processing In heterogenous multi-vehicle systems is-sues of interoperability and code-reusability can be expected to become more salient Often easeof use in terms of development and prototyping is traded o for eciency and compact hardwarewhich makes the implementations quite idiomatic

By taking a modularised approach as regards the hardware and employing in the sense ofreusability and ease of programming more powerful Single Board Computers (SBC) or COMscapable of running an operating system dierent systems providing the basic attitude control

5Pixhawk httpwwwethzchpixhawk6MAVLink httpwwwqgroundcontrolorgmavlinkstart7Arducopter httpcodegooglecomparducopter8ArduPilotMega httpcodegooglecompardupilot-mega9Arduino httpwwwarduinocc10UAVP-NG httpnguavpch11OpenPilot httpopenpilotorg12By 2011-06-09 Thu both projects status has considerably advanced

10

such as those mentioned above can be used and wired up with more capable hardware to conductexperiments with a wide range of sensors and algorithms This necessitates the integration of severaldierent downlink and communication frameworks that are in use across dierent systems

One practical option for this part of the system while keeping reusability ease of developmentand energy requirements in mind are ARM-based Linux packages such as the Gumstix or Beagle-board families or similar devices which are available at reasonable prices In summary these werethe considerations that are accumulated in the current state of the HUCH setup described belowThe diverse FR projects can be categorised along an axis indicating the level of targeted behaviourranging from low-level actuator control up to high-level navigation and high performance signalprocessing functionality Table 1 is a graphical representation showing the projects hardware andsoftware components coverage along that axis

Motor Attitude GPS Ground High-perf

UnspecStd PWM ESCs

AscTecDragoncopter

MK MK-BL Flight-Ctrl MKNAV MK-ToolPXH pxIMU via COM QGC COMPPZ TWOG Tiny Lisa GCS COM w LisaAC ArduPilot AC-GS

HUCH COMs

Table 1 Systems overview Of course it is almost always possible to attach a COM to low-levelattitude control platform such as the MK-FC ArduPilotMega or PPZ autopilots over a serialinterface Both PXH and PPZ are designed for use with Gumstix COMs

33 HUCH Sytem

331 Basics

The HUCH project was started to test bio-inspired navigation strategies on ying robots Theproject was initially equipped with basic MK kits The MK is mainly being used for RC modelying and aerial photography but the user community is also active with various other experimentsregarding extentions and modications The platforms distinctive advantages are its price readyavailability and sucient openness for research uses 13 Several academic projects have made orstill make use of the MikroKopter platform

The core component of the MK setup is the FlightCtrl (FC) comprising of both a Printed CircuitBoard (PCB) featuring an IMU a microcontroller and the rmware implementing the attitudestabilisation RC interface telemetry and more The MK architecture also features ESCs (MK-BL) capable of receiving the actuating variable via a TWI interface at a rate of 500 Hz which marksa dierence to other ESCs available on the RC market For that reason the MK-BL is also widelybeing used in many other projects

13Although with recent versions of the FlightCtrl rmware this has started to change

11

Direction Code Command Arguments

Inb Submit external control extctrl structc GyroBaro neutral Noned Request debug vector Update interval or None for one-om Start motors Nonen Kill motors None

OutD Debug vector 32 int16 values

Table 2 Five most important HUCH commands for external control of the modied MK-FC

332 Modications

Software The HUCH group has developed various extensions and modications to the platformOne of these is an expansion of the external control interface see Table 2 via the UART a corre-sponding groundstation (mcut) and control software (mktool) These are the basis for most of thework described in the remaining part of this text

The FlightCtrl microcontroller rmware was modied (HUCH variant) initially based on killa-gregs rewrite of the original rmware and implements among other things the extended communi-cation protocol higher UART baudrates TWI sensor integration and several more items 14 Thereexists a tool 15 to realise realtime display and plotting of debug variables ashing of MikroKopterrmware with embedded avrdude code parameter editing and motor testing The MKcom pro-gramm was initially developed for using a CMUcam to control the MikroKopter from vision inputIt features the basic FC communication stack and a control console This last item served as thebasis of the rst prototype of a Linux based altitude control At the time of writing develop-ment of these tools has been abandoned in favor of Micro Aerial Vehicle Humboldt Universitaumlt zuBerlin (MAVHUB) which is described in more detail elsewhere [25]

Computing hardware To overcome the severe restrictions of the Atmel ATMega644 being usedon the FC it is necessary to attach additional processing hardware Stating it more simply a singlemicrocontroller clearly is not suitable for any kind of slightly more demanding processing For thispurpose to date dierent single board systems have been used the Gumstix Verdex Pro 16 andBeagleboard variants 17 as can be seen in the gures 6 and 7 Several other options are availableand could be utilised in the future as our approach is construed exible in this regard Working ona Linux system provides a huge advantage in abstracting the algorithms from the hardware TheLinux system is connected to the FlightCtrl via the UART port In order to achieve a sampling rateof 100 Hz a baudrate of 230400 kbaud needs to be set on this connection The DebugOut messagestructure counts 95 bytes on the wire The motor command takes up 22 bytes giving 117 bytes forone sense-act cycle At the given channel capacity (25600 bytes per second) this gives approximately

14HUCH FlightCtrl 071i httpkoroinformatikhu-berlindeqkdownloadsV071i_huch-code_motodrone09targz

15mcut httpkoroinformatikhu-berlindeqkdownloadsmcuttargz16Gumstix Verdex Pro httpwwwgumstixcomproductverdex-pro17Beagleboard httpwwwbeagleboardorg

12

218 full cycles per second under optimal conditions and should be sucient for processing at 100Hz There are problems with nding higher baudrates that are supported on both sides of theconnection due to the 20 MHz clocking of the microcontroller

(a) Verdex View 1 (b) Verdex View 2

Figure 6 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below andthe expansion board on above On top is a USB WiFi dongle

A custom ATMega based ADC expansion board is acting as a generic analog data aqcisitiondevice Analog measurements are multiplexed and transmitted down a Two Wire Interface (TWI)link to the main control COM In a dierent setup an Arduino Mini was substituted for the customboard

Sensors For altitude measurement three dierent sensors were added to the setup A barometricpressure sensor is already provided for in the vendor board design This sensor is quite noisy butcovers a large range of measurement When close to the ground range sensors can be used tomeasure the distance Of this type we used a Devantech SRF02 sonic range nder This sensorhas an integrated microcontroller that does time-of-ight calculations for an ultrasonic pulse andtransmits the result digitally over a two wire interface (TWI) The speed of sound vs the actualdistance determine the maximum update frequency In our experiments these were xed at a rateof approximately 50 Hz In addition we attached two Sharp type infrared rangers (GP2Y0A02YKGP2D120) to the robot These output an analog voltage inversely proportional to the distancemeasured They are connected to the expansion board which also transmits updates via TWI butat a rate of 100 Hz The physical conguration of the range sensors is depicted in Figure 8

13

Figure 7 The electronic stack on this copter consists of (in ascending order) FC Power and UARTbreakout Beagle breakout and Arduino Mini mount BeagleBoard and USB WiFi Dongle

333 Physical system

As has been described above the FC can be given actuation commands via both the RC and UARTinterfaces in the form of the four-element vector 1 The SBC used in this particular conguration isthe Gumstix Verdex Pro X6LP The gumstix receives its power supply of 5V DC from the FC andtalks to it over the FFUART without additional level converters The hardware component setupis depicted schematically in Figure 9 On the left hand side of the diagram the base MikroKoptersetup is seen with the FlightCtrl RC receiver and the four ESCs On the right hand side theVerdex and custom sensor board are situated realising highlevel control and UDPIP link to thegroundstation over WiFi For the operation of a second onboard SBC the Beagleboard in Figure 9an additional voltage controller had to be used between the 12V DC rail and the Beagleboard powersupply socket

OpenEmbedded The current gumstix system software is provided via the Aringngstroumlm 18 distri-bution which is based on OpenEmbedded 19 The gumstix overlay provides Linux kernel versions2621 and 2631 Unfortunately the driver for the gumstix onboard WLAN hardware (netvx boardw a Marvell cf25 chip) changed between those versions and the one in 2631 refuses to actually

18Angstrom Distribution httpwwwangstrom-distributionorg19OpenEmbedded httpwwwopenembeddedorg

14

Figure 8 Range sensors attached to frame

RC receiver Onboard electronics

BL1 Expansion Board

BL4 FlightCtrl BL3

BL2 Gumstix

Camera BeagleBoard

TWI

UART

TWI

Wi

LAN

USB

Figure 9 Basic HUCH onboard electronics The left hand region of the picture consisting of receiverFC and brushless motor controllers BL1minus4 represents the standard MK setup while the right handregion represents HUCH additions

work with our hardware so a dierent solution had to be found Fortunately here the USB sub-system works well out of the box and standard USB WLAN hardware could be used to set up thelink Running the system o an SD-card as well as TWI (I2C) support in Linux work well Onemore aspect of the WLAN setup is worth noting though It was desired to realise the wireless linkto the onboard Linux in Ad-Hoc mode for two reasons The rst is reduced startup time when usingAd-Hoc mode the second is independence of access point infrastructure In this way the minimalFR groundstation conguration can be operated in a more mobile manner In principle one of thenodes could be operated in Master mode but this is not supported by all hardware

Once the live Linux system and cross-compilation environment was up and running the MKcom

15

software provided the basis for further work on controller implementation Looking at the Linuxsystem at this point the following view presents itself in Figure 10

Gumstix

AringngstroumlmLinux 2631 SD

UIShell mktool wlan0

devttyS1 devi2c-0

FC Exp Groundstation

RxTx wires

Wireless link

Figure 10 Basic Linux setup

4 Experiments

41 Basic structural design through simulation

Initially the problem of altitude control was analysed in simulation To that end a simple con-troller was realised within the crrcsim 20 RC model simulator There are basically two possiblemethodological approaches to setting up a simulation for a model helicopter One is the derivationof the model from rst principles and implementation from scratch The other is building uponexisting if simplifying solutions that are practically usable and open for modication

A moderately physically realistic model of a quadrotor aerial system is governed by a nontrivialnonlinear dierential equation [3 pg 155] [4] Much microscopic detail can be added for furtherrenement as the need arises Such details are discussed to some extent in [14] and [8] In the near-hover ight regime the system behaves quasi-linearly but at more extreme velocities and attitudesthe increasing impact of several nonlinear eects such as blade apping vortex ring states orforward translational lift would have to be considered For our purposes these eects have so farbeen neglected but could in princpiple be incorporated into the model

Circumventing the necessity of model derivation and implementation the second approach waschosen In particular the existing real-time ready crrcsim [7] RC-model simulator software wasmodied to conduct the initial experiments This was particularly facilitated by the prior work ofJens W Wulf who implemented a quadrotor model and internal controller substructures for thissimulation framework [32] A screenshot of the Wulf-model ying in the modied simulation in canbe seen in Figure 11 crrcsim comes with an internal controller architecture that realises dierent

20Charles River Radio Controllers Simulation httpcrrcsimberliosde

16

attitude controllers The software originally is designed to interface manual control hardware suchas RC transmitters joysticks and such to the simulation engine It was modied to implementadditional controllers detailed state information output for plotting and analysis and networkedcontrol of the simulation engine A drawback of crrcsim is its monolithic architecture For futurework the core simulation engine would have to be separated from the render engine Alternativelythe PPZ approach could be used as a drop-in replacement

Figure 11 Simulation screenshot The helicopter model landscape and text console are part ofcrrcsim The actual debugging output that can be seen in the console is part of custom modications

411 Closed loop

The basic structure of the full control loop is displayed in Figure 12 The control module embeddedin the loop is a Single-Input Single-Output (SISO) type controller The actuating variable undercontrol is thrust which eects overall lift (see above) while the other three components are mostlycontrolled manually during the experiments The input to the controller is the current altitudeestimate The estimation process potentially has to consider multiple measurements which have tobe fused into a single representation

412 Measurements

In simulation global knowledge of the world- (and agent-) state is available and all system variablesare immediatly accessible This allows to use a simplied signal-ow structure which is depicted in

17

Measurements

z0

z1 Kalman lter Controller

Fusion Estimate PID System

znminus1

zn

throttle

Behaviour

setpoint

Figure 12 Controller structure with measurement branch

gure 13 In order for the controller to be structurally transferable to the real hardware system thespecic sensor conguration has to be modelled within the simulator This included preparationof IMU data by tapping the Flight Dynamics Model (FDM) module and basic modelling of therespective characteristics of the barometric and ultrasonic range sensors which were in use on thehelicopter at that time In the case of the barometer this meant the addition of white gaussiannoise A slow drift which can be observed on the real sensor due to slow air-pressure changes wasneglected For the ultrasonic range sensor the timing characteristic that is the maximum updaterate dependent on distance measured was emulated The information thus synthesized was fed intoa Kalman lter for further processing

Controller

PID Systemthrottle

Flight dynamics model

setpoint

Figure 13 Simplied controller structure

413 Sensor fusion

Sensor fusion is a problem class on its own The base intent is to derive an estimate of a systemstate variable from multiple measurements that is more reliable than it would be by using only asingle measurement There are several approaches which have been developed over the last decadesand which could be employed for this task The complementary lter approach can be chosen if the

18

sensors are aected by suciently dierent kinds of noise and thus eg spectrally complementarylters can be used on dierent measurement channels which are then linearily combined into a singlevalue Probably the most commonly used techniques are the linear Kalman lter and its nonlinearvariants Other methods are nonexhaustively Bayesian strategies such as Particle lters H-infinlters or neural networks A linear Kalman lter was chosen in the current setup for the reasonthat the lter and its characteristics are well documented and the implementation is straightforwardboth from scratch and even more so using matrix algebra libraries such as OpenCV The basic ltertask is to estimate the state xk isin Rn of a discrete time system governed by the linear stochasticequation [29] [15]

xk = Axkminus1 +Bukminus1 + wkminus1 (2)

based on a measurement zk isin Rm given as

zk = Hxk + vk (3)

where wk vk are random variables which represent process noise and measurement noise and arenormally distributed with zero mean p(wk) sim N(0 Q) p(vk) sim N(0 R) Q and R are the processand measurement noise covariance matrices The model used here consists of two state variablesx = (a dadt) with a the altitude (above ground) Later the model was extended to include d2adtso as to facilitate incorporation of accelerometer measurements One problem with the real sensorswas a clear deviation of the measurement noise from the assumed normal distribution and had tobe corrected for in preprocessing

414 PID controller

The Kalman lter state estimate can nally be used as the input to a PID throttle controller ThePID model used is a FOPDT integrating model The second input to the controller module is thesetpoint which can be set in the simulation via keyboard- or network-input to the application Therst working PID parametrisation was arrived at through manual tuning which is cumbersome andgives suboptimal results

415 Evolutionary parameter tuning

To prove the concept of using online learning within simulation at least the PID parameters wereoptimised using evolutionary strategies [22] [26] The tness function for this experiment wasconceivably simple chosen as

f(i) =

Nsum0

|xset minus xik| (4)

with individual i (a tuple (P ID)) setpoint xset the experiments duration in time steps N andthe altitude xik at time step k resulting from execution of controller i This stage involved setting upthe system so that simulation state and model parametrisation (the P I and D coecients) could

19

be controlled programmatically It was realised over a UDPIP connection between crrcsim andthe external simctrl control shell 21 implemented in the Python language 22 The results of theexperiment have been presented in [10]

42 MKcom2

MKcom short for MikroKopter communication tool was designed as a minimal software layer tosit on top of the UART communication link to the main ight board It provides a console baseduser interface for activation and conguration of a set of thin control functions and can act as agateway between the FC and a CMUcam MKcom functions can send commands to the FC andincoming UART packets are dispatched to the appropriate message handler This tool implementedthe modied MK message set

The setup was used as the basis for prototyping several versions of the control loop structureoutlined in Figures 12 and 13 The internal organisation of these implementations can be seenin Figure 14 Three dierent controller cores were realised which incrementally incorporated moremeasurement channels heuristic detail and safety hooks The detailed ow structure of the controllerdesign will be outlined below The update rate and execution timings are dictated by the arrivalof the measurement vector from the FC Auxiliary sensors were integrated asynchronously into themain loop A custom groundstation for state logging and realtime plotting was connected to thenetwork downlink indicated in the diagram

421 MKcom2 Flow structure

On startup a request for debug structure emission is sent manually from the mkcom shell to the FCwith the debug n command where n is the desired sampling interval in milliseconds An examplesession excerpt looks (slightly beautied) as follows (`gt indicates the shells command prompt `is the startsign of the MK protocol strings starting with ` is the raw ascii data going over thewire)gt debug 100

tx bdV ===Ds

gt

rxbuf 93 bD===IgtpU gtomgtS=xTyf=DL|pA= gt===Kl|Lnx=mL=I===i=BM|| oXfT_UrePI=T]=gt==E=|l|

L=IE||y===Y=qM

_DebugOut_ 1804 310 203 854 -843 420 -49 49 4

2 -21-1016 123 828 828 0 11 21

-1-5850 9822 -24267 51 94 1 2 -2

207 706 -1 0 7

rxbuf 93 bD===ggtpi gtm=gtT=oxzd]DL|o===m=A=Kl|ALnx=mL=I===E=m=== KxYSourePI=T]====A===

L=IM||y===Y=nf

_DebugOut_ 1834 315 192 855 -722 414 -49 32 3

4 -21-1008 123 828 828 0 2 15

0 -897811867-24267 51 94 0 1 0

207 708 -1 0 7

gt debug 0

tx bd====DZ

gt

21httpwww2informatikhu-berlinde~obertholQK22Python Language httpwwwpythonorg

20

The debug vector is populated in the FC where element positions correspond with value typesIt includes IMU data manual control input from the RC and the barometer as well as systemstatus values such as battery voltage RSSI value ampc Depending on the setup it can include thereading from the sonar as well If the actual controller is activated with eggt ac3 1

kal_cv_init DP 3 MP 5 CP 0

gt

the controller evaluation function is executed upon each arrival of a debug packet Of coursesome information is retained across calls After computation has nished an extctrl (Externalcontrol) structure is populated and sent back to the FC Aditional measurements such as from anInfraRed Ranger (IRR) are integrated in an asynchronous manner from multiple threads Severalparameters such as the altitude setpoint PID values bias ampc can also be set from the text based userinterface While this works quite well in principle and did achieve good performance modularityand extensibility were not an initial design goal This led to another iteration of the same designwithin the MAVHUB framework which will be described in the next subsection

IO Channels UART TWI UI Network

HAL threads FC-RX Expansion Ctrl Sonar Shell

Processing Controller

mkcom2

Figure 14 Mkcom2 ow-graph

43 Heuristically tuned altitude control software

The vague vision of the overall architecture that is pursued here is that of several concurring moduleswhich are summed in a cooperative time-dependent manner and where each module is responsiblefor various behavioural aspects [1] To ease prototyping and testing of components the structurehas to be kept exible extensible and dynamically recongurable This has to be considered in theoverall onboard software design In order to illustrate this requirement the ow of information andthe interaction with additional behavioural modules will be described in more detail in the followingparagraphs References will be made to several modules operating within the MAVHUB frameworkthe basics of which are described elsewhere [25]

431 Data acquisition

First the controlware has to collect all sensory information from possibly heterogenous sourcesThese include 6 - 9 channels of IMU data (depending on IMU type) a barometric measurementseveral range sensors as well as optical sensors (cameras) and of course any other sensor which is

21

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

1500

2000

Time [s]

Value

throttle

uss_meas

k_s0

Figure 15 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m aboveground The dashed line is the raw sonar range value the solid black line is the estimate uponwhich the PID controller acts The solid green line in the lower part of the plot is the controlleroutput value which is sent to the actuator

available or desired Heterogeneity pertains to hardware channels update rates and data formatsIn MAVHUB there are two main channels if information ow One is the protocol stack whichtransmits volatile incoming messages to all active modules (apps) The other is a shared memoryarea where data can be deposited by any active process In the setup considered here FC data(including IMU barometer and possibly sonar) and intermediate internal data travel on the stackSensors connected via a two-wire bus are operated by sensor drivers and measurements are put intothe shared memory The desired result of this step is to be able to operate on a homogenous vectorof input signals within the main control loop

432 Preprocessing

Subsequent to acquisition each sensory channel is individually preprocessed according to the pe-culiarities of sensor principle and connection mode Preprocessing mostly consists of linearisationunit conversion (inverting the sensor characteristic) and several kinds of heuristic validation

Linearisation For this particular setup linearisation only has to be done for the IRRs Theseare analogue sensors and the output voltage is related to the distance s measured via u(t) = 1

s(t) An example sensor characteristic is displayed in Figure 16 For the dierent subtypes of the Sharpsensors an individually parameterised procedure has to be performed as described by eg Acroname

22

Robotics in [23] if the sensors are processed on a metric basis If the Sharp sensors are driven atthe recommended supply voltage of 5V using the datasheet specications has proven sucientlyaccurate An example script for determining the parameters from given calibration data is suppliedon this reports supplementary website 22

Unit conversion The diverse units of sensor data have to be explicitly converted to units conve-nient for later steps in the calculation in particular sensor fusion with the Kalman lter For thealtitude measurements these are metersminus3 so ADC-units or time-of-ight measurements have to beconverted to millimeters for the analog sensors (barometer accelerometer infrared) and the sonarsensor repsectively This simply amounts to a multiplicative factor

Validation Heuristic sensor data validation has to be done for all types of rangers as well as for thebarometric sensor The spurious readings these sensors produce are of dierent types though Theinfrared rangers display ambigouity beyond the lower limit of the operating ranges see Figure 16For the GP2D120 which can sense the smallest ranges of all sensors this can be mostly neglectedsince the minimal sensing range can hardly be reached due to the mechanical conguration Forall the other sensors output is surpressed when the GP2D120 is active At the upper limit of theIRRs operating range the output is surpressed when a suitable threshold is reached The followingcode example illustrates this where sensor channel number three is the close range IRR

if(in_range(sensors [3] first llim ulim))

valid = 10

else

valid = 00

sensors [3] second = (fir[3]-gtcalc(valid) gt= 099) 1 0

Surpression is realised by setting appropriate values in the measurement transform matrix H(t)of the Kalman lter Alternatively this could be done by generating suitable variances for therespective sensors in the measurement covariance matrix R(t) Driving the IRRs at 33V works butreduces the usable range In addition the IRR sensor measurements are dependent on the groundsurfaces some of which eg an oce carpet can result in erratic results

The ultrasonic sensor is susceptive to dierent kinds of spurious readings caused by late echoesThis happens both when very close to an object or surface or when far away that is beyond theupper limit of measurable distances The validation strategy employed is to set hard empiricallower and upper limits for values as for the IRRs and limiting the maximum dierence betweentwo consecutive values based on assumptions about the maximum velocity An example session isillustrated in Figure 18

Finally the barometer is sensitive to acceleration which has to be accounted for The sensorbehaviour is displayed in Figure 19 The empirical corrections read

BARO (pre [1] correct from accel -z (pre [2])

pre [1] first -= (005 pre [2] first)

The validition process in general produces one new signal per channel to be used later in theprocess for setting Kalman lter matrix values One remaining problem here is the channel cross-dependency

23

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 4: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

24 What is a Controller

A controller is a well dened term in control theory [16] In this work the term controller designatesthe overall hardware and software aggregate which generates real-time behaviour on the robot Incontrast to concerns of control theory a good part of this aggregate is used up by sensor acquisitionand preprocessing to realise endemic onboard state estimation capabilities with an adequate degreeof correlation to environmental conditions

25 What is altitude control

Altitude here is used as some sort of measure for the distance of the robot from the ground Forvehicles that are able to hover this is the most important variable to be controlled It enables therobot to take o from the ground and either maintain a certain distance to the ground or to maintaina certain rate of ascent and more generally keep clear of a large object or bounding surface

In a simulated environment with a perfectly at oor the question hardly arises On a physicalsystem travelling over fractally ragged ground the question does become more intricate Severalfactors are interacting such as overall type of desired behaviour desired speed relative to theenvironment to objects in the environment and the spatiotemporal dynamics of sensor responses

Several dierent behaviours have been investigated and some of them prototyped These areterrain following absolute altitude stabilisation see Figure 1 and vertical rate control The formertwo emerge from the sensor reponse dynamics Depending on wether the robot is within rangeabledistance of an object or surface a valid range measurement overrides and resets the absolute altitudeinformation Vertical rate on the other hand can be directly extracted from an onboard camerausing optic ow estimation Some notable work has been done on purely optic-ow based autopilotsby N Franceschini Franck Ruer and others [24]

A purely egocentric sensory setup is used in contrast to many other approaches in FR work whichrely on GPS for outdoor deployment and optical tracking in indoor scenarios While the resultsclearly justify a third person approach to robotics the importance of reliable endemic sensing isprobably underestimated

26 About this text

The rest of the text is organised as follows In the systems section basic aspects and components ofFRs in general will be described and some of the existing low-cost UAV system are dissected andpresented in more detail

The consequent section will present the details of some experimental controller modules for aquadrotor implemented on an onboard Linux system This includes discussion of an approach tosimulation as well as the presentation of particular controllers on real hardware The terminal partof the text will summarise the results and sketch some possible routes for further development ofthe system

The work was being conducted in 201011 within the bio-inspired navigation project under thesupervision of Prof Verena Hafner of the Cognitive Robotics group at the Department of ComputerScience of the Humboldt-Universitaumlt zu Berlin

4

(a) Absolute altitude

(b) Terrain following obstacle avoidance

Figure 1 In 1(a) the robot maintains and absolute altitude The range sensors are either surpressedor the robot is too far away from the ground to be able to measure the distance In 1(b) the robotfollows the contour of the terrain

3 Systems

31 Airframes

There are many dierent types of FR only some examples of which can be seen in Figure 2 andFigure 3 Fixed wing apping wing and rotary wing yers have emerged as the most frequentlyused classes of motor powered yers on large and small scales All of these generate lift throughtheir whole body- or component-dynamics (rotors) Dynamic lift is contrasted by balloons airshipsand blimps which are statically buoyant but generally suer from reduced maneuverability andwind susceptibility In between there are all sorts of hybrids which are not easily classied forexample robots capable of hybrid modes of locomotion such as the MMALV [2 9] or VerticalTakeO and Landing (VTOL) vehicles with pivoting rotors or airfoil elements [33 Tail sitter]The remaining part of this work is concerned exclusively with multirotor helicopters (multicopters)although regarding the framework there are many commonalities across all types of yers

Helicopters in general have the advantage of being capable of near-holonomic motion and hov-ering which gives them a certain edge in indoor or constrained-space applications and hence makesthem an overall attractive research platform The main structural advantage of the bare-bonesmulticopter is the omission of all movable parts except for n motors which signicantly reducesmechanical complexity and thereby increases mechanical robustness and maintainability

311 Multicopter ight principle

The vehicle possesses 6 degrees of freedom for movement in space and n actuators On the quadrotortwo rotors are turning clockwise or counter-clockwise respectively Equal rotation rates result inoverall equalisation of torque Changing the rate of one set of co-rotating rotors relative to the othera torque about the vehicle vertical axis is induced and it turns (yaw) Changing the rate relation

5

(a) Quadrotor helicopter (b) Coaxial helicopter

(c) Fixed wing yer (d) Flapping wing yer

Figure 2 Dierent possible airframe types for ying robots a) experimental workhorse Horst b)E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c) Multiplex FunJetphotograph from Paparazzi Wiki by Matthew Currie d) Flapping wing platform photograph byHenryk Ploumltz also with permission

among two co-rotating rotors induces a torque about the perpendicular horizontal axis Both pitchand roll movements are eected in this way in a symmetrical manner By pitching or rolling thethrust vector is deected from the pure vertical direction and the vehicle accelerates laterally Formore details on the working principle and modelling of multirotors see for example [5] [14] or [11]At the level of the individual acutators the system is not manually controllable For this reasonInertial Measurement Units (IMU) are used to realise electronic control of the vehicle attitude AnIMU is a set of sensors that provides information about orientation in space by measuring angularrates acceleration and magnetic forces over three orthogonal axes The attitude control setpointsin turn can be aected by manual or high-level autonomous control input The control vector thusis given by

uT = (pitch roll yaw thrust) (1)

While the principles of inertial navigation have been applied for decades in control of aerial vehi-

6

(a) MMALV 1 (b) MMALV 2

(c) Paparazzi dual airfoil quadrotor taking o (d) Dual airfoil quad after transition to forwardight

Figure 3 Some less prevalent airframe congurations a) and b) Morphing Micro Air and LandVehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobots LLC and Roger Quinnof Case Western Reserve University and c) and d) a Paparazzi based quadrotor with two airfoils(tail sitter design) The pictures are two frames extracted from a video by Antoine Drouin JobyRobotics with kind permission

cles with both analog and digital implementations of the control schemes [12] the use of lightweightlow-cost-and-quality inertial sensors at the same time enables the construction of Micro AerialVehicles (MAV) and poses challenges for the accuracy of the resulting solutions The general ap-proach is to use a complementary system of high-frequency angular rate sensing (gyroscopes) andlow-frequency compensation via acceleration measurements (acceleromoters) In addition informa-tion from magnetic measurements can be incorporated into the attitude estimation if a 9-Degressof Freedom (DoF) IMU is available

312 The robot body

The airframes cited above are examples of FR bodies A brief consideration of some consequencesof the specic conguration is in order The relevant aspects are geometry surface and propulsionGeometry and surface as well as motion type relate to where and how the sensors can actually bemounted In xed winged platforms there is a prefered direction of motion whereas the quadrotordisplays a four-fold structural symmetry and the vehicle front needs to be arbitrarily set Mounting

7

a forward-pointing camera clearly breaks the symmetry in regards to vision based navigation Apossible solution is downward orientation or the use of panoramic lenses see Figure 23

In order to measure the distance to the ground only the downward pointing body surface needsto be considered for sensor mounts (although see GDC below) Obviously acoustic and optical rangesensors need to be unobstructed by other body parts Deviations in range measurements due to non-zero pitch and roll angles during ight are regarded as disturbances in the controller sketched belowThis is in part justied by the nite beam-width of the sonar sensor which intrinsically measuresthe shortest path to a reecting surface Since the absolute error grows linearly with range and theinfrared sensors used here only have very limited range (lt 1m) the deviation is not compensatedeither The scenario is illustrated in Figure 4 the theoretical error for dierent angles and aboslutedistances is plotted in Figure 5 Some more dynamic types of interactions are considered below

θ

e

Figure 4 Distance measurement depending on the angle θ to the ground surface

0 10 20 30 400

200

400

600

Angle [deg]

Error

[mm]

Alt 05 mAlt 1 mAlt 15 mAlt 2 m

Figure 5 Theoretical error over angle for several dierent distances from ground

8

32 Quadrotor systems overview

The quadrotor was conceived in the 1920ies bei Etienne Oehmichen and purportedly ew onlya couple of meters at the time probably due to the manual control problem The concept washibernating for most of the 20th century to resurface as an electronic toy in 1996 The Roswellyer of Area51 Technologies seems to be the earliest appearance of a working miniature quadrotorRC yer [13] Since then development of similar systems has picked up momentum considerablyBy now (2011) there exist a number of projects that are suitable (if not specically designed) asrobotics research platforms of which this section provides an overview The projects backgroundsvary from robotics and remote sensing to hobbyist RC model-ying and electronic toys

While not exclusively targeted at multicopters one of the oldest eorts to develop a versatileand open UAV system (airborne and ground segments) for model yers is the Paparazzi (PPZ)1 project of the Ecole Nationale de lAviation Civile (ENAC) The project was founded in about2003 2 and consists of an extensive set of both hardware and software components The airbornehardware consists of a variety of base processor boards (Tiny TWOG LisaLM) sensor modulesand communication devices The control software consists of a stack of PID control loops whichare executed on the microcontroller boards The overall approach reects a certain outdoor anityConsequently one of the architectures distinctive features is the use of IR thermophiles for absoluteorientation sensing (warm earth cold sky) in outdoor environments Complementing the airbornepart of the project is a comprehensive set of ground segment software and simulation modules Thiscomprises tools for tasks such as logging plotting map-supported on-screen trajectory trackingas well as eg vehicle tracking for servo-controlled directional antennas Communication amongcomponents is realised via the text- and subscription-based IVY software bus 3 which serves as thepoint of entry for component reuse from foreign systems Paparazzi also supports a high-level XMLbased ight-plan description and airframe conguration language Overall the PPZ system oersa mature codebase and a great amount of exibility through open source licensing and a modulardesign

Founded in 2006 the MikroKopter (MK) 4 project quickly gathered momentum in Germany asan RC model-ying vehicle and aerial photography system It is the system used for all experi-ments described in this work The MK architecture is a modular system that can be bought as a kitfrom the producer and consists of a combined IMU and microprocessor board called FlightCtrl (FC)which runs the attitude control software (also FlightCtrl) In fact there are several versions of theFC featuring dierent processors and sensors In addition the project has brought forth specialElectronic Speed Controllers (ESC) which interface control output on a TWI with brushless motorscalled MK-BL The distinctive feature of these controllers is the particularly high update-rate com-pared other other ESCs Consequently the MK-BL are used across many of the other projects seealso Table 1 Optional sensor modules include a compass and GPS components The main factorsfor choosing this particular system were its ready availability at the time of project initiation in2008 cost and source code access The ground and support software for the MikroKopter on theother hand is not ideally suited to demands in robot prototyping There have been attempts atdeveloping open-source and cross-platform alternatives to the vendors MikroKopter Tool althoughin the experiments described below yet other tools were used

1Paparazzi Wiki httppaparazzienacfrwikiMain_Page2httpwwwnongnuorgpaparazzigallery_v0html3Ivy Bus httpwww2tlscenafrproductsivy4MikroKopter httpwwwmikrokopterde

9

Published in late 2008 (according to the Internet Archive) the PIXHAWK (PXH) 5 project ofthe Computer Vision and Geometry Lab at the ETH Zuumlrich is an example of a system designedfrom the ground up as a robotic research platform in this case specically targeted towards visionexperiments PXH also has its own integrated processorIMU module as well as adapter hardwarefor using miniature yet high-capacity computing hardware sometimes referred to as Computer onModule (COM) The software part of the system features a comprehensive groundstation softwarecalled QGroundControl (QGC) and a low overhead communication protocol calledMAVLink 6 Sev-eral other components are provided or are in development The systems components are publishedunder open licenses and the software parts can easily be reused and adapted

Another interesting addition from around 2010 to the growing family of quadrotor systems is theArduCopter (AC) 7 which is designed on top of a more generic autopilot for both xed-wing androtary-wing platforms the ArduPilotMega (APM) 8 which in turn is based on the popular Arduino9 meta-platform The ArduPilot software already makes use of PXHs groundstation QGC throughthe MAVLink protocol In distinction to the projects mentioned so far ArduCopter uses standardunmodied low-cost ESCs for motor control which reects the general low-cost approach of theentire system This approach is most promising in terms community engagement Other relevantprojects in this category are the Unmanned Aerial Video Platform Next Generation (UAVP-NG)10 and OpenPilot 11 projects Both feature co-designed hardware and software but both have notbeen considered more closely due to their state of development during 2010 12

Among the straightforwardly commercial vendors there are two types those targeting profes-sional use outside the RC model community and those attending to the electronic toy marketThe former are mainly used for standard security and surveillance related activities In europethese are Ascending Technologies (AscTec) and microdrones AscTec models also appear in roboticsresearch but require much higher budgets The prominent representatives from the latter categoryare the DraganFlyer of RCToys whose ancestry goes back to the Roswell yer mentioned earlierand most recently the Parrot ARDrone released in 2010 featuring onboard Linux two camerasstabilisation with optical ow and an SDK for custom extensions

321 Systems summary

All these systems dier with regards to sophistication and extendability and clearly none of themprovides out-of-the-box the type of onboard computing system desired for a robotic experimentalframework targeting high-bandwidth signal processing In heterogenous multi-vehicle systems is-sues of interoperability and code-reusability can be expected to become more salient Often easeof use in terms of development and prototyping is traded o for eciency and compact hardwarewhich makes the implementations quite idiomatic

By taking a modularised approach as regards the hardware and employing in the sense ofreusability and ease of programming more powerful Single Board Computers (SBC) or COMscapable of running an operating system dierent systems providing the basic attitude control

5Pixhawk httpwwwethzchpixhawk6MAVLink httpwwwqgroundcontrolorgmavlinkstart7Arducopter httpcodegooglecomparducopter8ArduPilotMega httpcodegooglecompardupilot-mega9Arduino httpwwwarduinocc10UAVP-NG httpnguavpch11OpenPilot httpopenpilotorg12By 2011-06-09 Thu both projects status has considerably advanced

10

such as those mentioned above can be used and wired up with more capable hardware to conductexperiments with a wide range of sensors and algorithms This necessitates the integration of severaldierent downlink and communication frameworks that are in use across dierent systems

One practical option for this part of the system while keeping reusability ease of developmentand energy requirements in mind are ARM-based Linux packages such as the Gumstix or Beagle-board families or similar devices which are available at reasonable prices In summary these werethe considerations that are accumulated in the current state of the HUCH setup described belowThe diverse FR projects can be categorised along an axis indicating the level of targeted behaviourranging from low-level actuator control up to high-level navigation and high performance signalprocessing functionality Table 1 is a graphical representation showing the projects hardware andsoftware components coverage along that axis

Motor Attitude GPS Ground High-perf

UnspecStd PWM ESCs

AscTecDragoncopter

MK MK-BL Flight-Ctrl MKNAV MK-ToolPXH pxIMU via COM QGC COMPPZ TWOG Tiny Lisa GCS COM w LisaAC ArduPilot AC-GS

HUCH COMs

Table 1 Systems overview Of course it is almost always possible to attach a COM to low-levelattitude control platform such as the MK-FC ArduPilotMega or PPZ autopilots over a serialinterface Both PXH and PPZ are designed for use with Gumstix COMs

33 HUCH Sytem

331 Basics

The HUCH project was started to test bio-inspired navigation strategies on ying robots Theproject was initially equipped with basic MK kits The MK is mainly being used for RC modelying and aerial photography but the user community is also active with various other experimentsregarding extentions and modications The platforms distinctive advantages are its price readyavailability and sucient openness for research uses 13 Several academic projects have made orstill make use of the MikroKopter platform

The core component of the MK setup is the FlightCtrl (FC) comprising of both a Printed CircuitBoard (PCB) featuring an IMU a microcontroller and the rmware implementing the attitudestabilisation RC interface telemetry and more The MK architecture also features ESCs (MK-BL) capable of receiving the actuating variable via a TWI interface at a rate of 500 Hz which marksa dierence to other ESCs available on the RC market For that reason the MK-BL is also widelybeing used in many other projects

13Although with recent versions of the FlightCtrl rmware this has started to change

11

Direction Code Command Arguments

Inb Submit external control extctrl structc GyroBaro neutral Noned Request debug vector Update interval or None for one-om Start motors Nonen Kill motors None

OutD Debug vector 32 int16 values

Table 2 Five most important HUCH commands for external control of the modied MK-FC

332 Modications

Software The HUCH group has developed various extensions and modications to the platformOne of these is an expansion of the external control interface see Table 2 via the UART a corre-sponding groundstation (mcut) and control software (mktool) These are the basis for most of thework described in the remaining part of this text

The FlightCtrl microcontroller rmware was modied (HUCH variant) initially based on killa-gregs rewrite of the original rmware and implements among other things the extended communi-cation protocol higher UART baudrates TWI sensor integration and several more items 14 Thereexists a tool 15 to realise realtime display and plotting of debug variables ashing of MikroKopterrmware with embedded avrdude code parameter editing and motor testing The MKcom pro-gramm was initially developed for using a CMUcam to control the MikroKopter from vision inputIt features the basic FC communication stack and a control console This last item served as thebasis of the rst prototype of a Linux based altitude control At the time of writing develop-ment of these tools has been abandoned in favor of Micro Aerial Vehicle Humboldt Universitaumlt zuBerlin (MAVHUB) which is described in more detail elsewhere [25]

Computing hardware To overcome the severe restrictions of the Atmel ATMega644 being usedon the FC it is necessary to attach additional processing hardware Stating it more simply a singlemicrocontroller clearly is not suitable for any kind of slightly more demanding processing For thispurpose to date dierent single board systems have been used the Gumstix Verdex Pro 16 andBeagleboard variants 17 as can be seen in the gures 6 and 7 Several other options are availableand could be utilised in the future as our approach is construed exible in this regard Working ona Linux system provides a huge advantage in abstracting the algorithms from the hardware TheLinux system is connected to the FlightCtrl via the UART port In order to achieve a sampling rateof 100 Hz a baudrate of 230400 kbaud needs to be set on this connection The DebugOut messagestructure counts 95 bytes on the wire The motor command takes up 22 bytes giving 117 bytes forone sense-act cycle At the given channel capacity (25600 bytes per second) this gives approximately

14HUCH FlightCtrl 071i httpkoroinformatikhu-berlindeqkdownloadsV071i_huch-code_motodrone09targz

15mcut httpkoroinformatikhu-berlindeqkdownloadsmcuttargz16Gumstix Verdex Pro httpwwwgumstixcomproductverdex-pro17Beagleboard httpwwwbeagleboardorg

12

218 full cycles per second under optimal conditions and should be sucient for processing at 100Hz There are problems with nding higher baudrates that are supported on both sides of theconnection due to the 20 MHz clocking of the microcontroller

(a) Verdex View 1 (b) Verdex View 2

Figure 6 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below andthe expansion board on above On top is a USB WiFi dongle

A custom ATMega based ADC expansion board is acting as a generic analog data aqcisitiondevice Analog measurements are multiplexed and transmitted down a Two Wire Interface (TWI)link to the main control COM In a dierent setup an Arduino Mini was substituted for the customboard

Sensors For altitude measurement three dierent sensors were added to the setup A barometricpressure sensor is already provided for in the vendor board design This sensor is quite noisy butcovers a large range of measurement When close to the ground range sensors can be used tomeasure the distance Of this type we used a Devantech SRF02 sonic range nder This sensorhas an integrated microcontroller that does time-of-ight calculations for an ultrasonic pulse andtransmits the result digitally over a two wire interface (TWI) The speed of sound vs the actualdistance determine the maximum update frequency In our experiments these were xed at a rateof approximately 50 Hz In addition we attached two Sharp type infrared rangers (GP2Y0A02YKGP2D120) to the robot These output an analog voltage inversely proportional to the distancemeasured They are connected to the expansion board which also transmits updates via TWI butat a rate of 100 Hz The physical conguration of the range sensors is depicted in Figure 8

13

Figure 7 The electronic stack on this copter consists of (in ascending order) FC Power and UARTbreakout Beagle breakout and Arduino Mini mount BeagleBoard and USB WiFi Dongle

333 Physical system

As has been described above the FC can be given actuation commands via both the RC and UARTinterfaces in the form of the four-element vector 1 The SBC used in this particular conguration isthe Gumstix Verdex Pro X6LP The gumstix receives its power supply of 5V DC from the FC andtalks to it over the FFUART without additional level converters The hardware component setupis depicted schematically in Figure 9 On the left hand side of the diagram the base MikroKoptersetup is seen with the FlightCtrl RC receiver and the four ESCs On the right hand side theVerdex and custom sensor board are situated realising highlevel control and UDPIP link to thegroundstation over WiFi For the operation of a second onboard SBC the Beagleboard in Figure 9an additional voltage controller had to be used between the 12V DC rail and the Beagleboard powersupply socket

OpenEmbedded The current gumstix system software is provided via the Aringngstroumlm 18 distri-bution which is based on OpenEmbedded 19 The gumstix overlay provides Linux kernel versions2621 and 2631 Unfortunately the driver for the gumstix onboard WLAN hardware (netvx boardw a Marvell cf25 chip) changed between those versions and the one in 2631 refuses to actually

18Angstrom Distribution httpwwwangstrom-distributionorg19OpenEmbedded httpwwwopenembeddedorg

14

Figure 8 Range sensors attached to frame

RC receiver Onboard electronics

BL1 Expansion Board

BL4 FlightCtrl BL3

BL2 Gumstix

Camera BeagleBoard

TWI

UART

TWI

Wi

LAN

USB

Figure 9 Basic HUCH onboard electronics The left hand region of the picture consisting of receiverFC and brushless motor controllers BL1minus4 represents the standard MK setup while the right handregion represents HUCH additions

work with our hardware so a dierent solution had to be found Fortunately here the USB sub-system works well out of the box and standard USB WLAN hardware could be used to set up thelink Running the system o an SD-card as well as TWI (I2C) support in Linux work well Onemore aspect of the WLAN setup is worth noting though It was desired to realise the wireless linkto the onboard Linux in Ad-Hoc mode for two reasons The rst is reduced startup time when usingAd-Hoc mode the second is independence of access point infrastructure In this way the minimalFR groundstation conguration can be operated in a more mobile manner In principle one of thenodes could be operated in Master mode but this is not supported by all hardware

Once the live Linux system and cross-compilation environment was up and running the MKcom

15

software provided the basis for further work on controller implementation Looking at the Linuxsystem at this point the following view presents itself in Figure 10

Gumstix

AringngstroumlmLinux 2631 SD

UIShell mktool wlan0

devttyS1 devi2c-0

FC Exp Groundstation

RxTx wires

Wireless link

Figure 10 Basic Linux setup

4 Experiments

41 Basic structural design through simulation

Initially the problem of altitude control was analysed in simulation To that end a simple con-troller was realised within the crrcsim 20 RC model simulator There are basically two possiblemethodological approaches to setting up a simulation for a model helicopter One is the derivationof the model from rst principles and implementation from scratch The other is building uponexisting if simplifying solutions that are practically usable and open for modication

A moderately physically realistic model of a quadrotor aerial system is governed by a nontrivialnonlinear dierential equation [3 pg 155] [4] Much microscopic detail can be added for furtherrenement as the need arises Such details are discussed to some extent in [14] and [8] In the near-hover ight regime the system behaves quasi-linearly but at more extreme velocities and attitudesthe increasing impact of several nonlinear eects such as blade apping vortex ring states orforward translational lift would have to be considered For our purposes these eects have so farbeen neglected but could in princpiple be incorporated into the model

Circumventing the necessity of model derivation and implementation the second approach waschosen In particular the existing real-time ready crrcsim [7] RC-model simulator software wasmodied to conduct the initial experiments This was particularly facilitated by the prior work ofJens W Wulf who implemented a quadrotor model and internal controller substructures for thissimulation framework [32] A screenshot of the Wulf-model ying in the modied simulation in canbe seen in Figure 11 crrcsim comes with an internal controller architecture that realises dierent

20Charles River Radio Controllers Simulation httpcrrcsimberliosde

16

attitude controllers The software originally is designed to interface manual control hardware suchas RC transmitters joysticks and such to the simulation engine It was modied to implementadditional controllers detailed state information output for plotting and analysis and networkedcontrol of the simulation engine A drawback of crrcsim is its monolithic architecture For futurework the core simulation engine would have to be separated from the render engine Alternativelythe PPZ approach could be used as a drop-in replacement

Figure 11 Simulation screenshot The helicopter model landscape and text console are part ofcrrcsim The actual debugging output that can be seen in the console is part of custom modications

411 Closed loop

The basic structure of the full control loop is displayed in Figure 12 The control module embeddedin the loop is a Single-Input Single-Output (SISO) type controller The actuating variable undercontrol is thrust which eects overall lift (see above) while the other three components are mostlycontrolled manually during the experiments The input to the controller is the current altitudeestimate The estimation process potentially has to consider multiple measurements which have tobe fused into a single representation

412 Measurements

In simulation global knowledge of the world- (and agent-) state is available and all system variablesare immediatly accessible This allows to use a simplied signal-ow structure which is depicted in

17

Measurements

z0

z1 Kalman lter Controller

Fusion Estimate PID System

znminus1

zn

throttle

Behaviour

setpoint

Figure 12 Controller structure with measurement branch

gure 13 In order for the controller to be structurally transferable to the real hardware system thespecic sensor conguration has to be modelled within the simulator This included preparationof IMU data by tapping the Flight Dynamics Model (FDM) module and basic modelling of therespective characteristics of the barometric and ultrasonic range sensors which were in use on thehelicopter at that time In the case of the barometer this meant the addition of white gaussiannoise A slow drift which can be observed on the real sensor due to slow air-pressure changes wasneglected For the ultrasonic range sensor the timing characteristic that is the maximum updaterate dependent on distance measured was emulated The information thus synthesized was fed intoa Kalman lter for further processing

Controller

PID Systemthrottle

Flight dynamics model

setpoint

Figure 13 Simplied controller structure

413 Sensor fusion

Sensor fusion is a problem class on its own The base intent is to derive an estimate of a systemstate variable from multiple measurements that is more reliable than it would be by using only asingle measurement There are several approaches which have been developed over the last decadesand which could be employed for this task The complementary lter approach can be chosen if the

18

sensors are aected by suciently dierent kinds of noise and thus eg spectrally complementarylters can be used on dierent measurement channels which are then linearily combined into a singlevalue Probably the most commonly used techniques are the linear Kalman lter and its nonlinearvariants Other methods are nonexhaustively Bayesian strategies such as Particle lters H-infinlters or neural networks A linear Kalman lter was chosen in the current setup for the reasonthat the lter and its characteristics are well documented and the implementation is straightforwardboth from scratch and even more so using matrix algebra libraries such as OpenCV The basic ltertask is to estimate the state xk isin Rn of a discrete time system governed by the linear stochasticequation [29] [15]

xk = Axkminus1 +Bukminus1 + wkminus1 (2)

based on a measurement zk isin Rm given as

zk = Hxk + vk (3)

where wk vk are random variables which represent process noise and measurement noise and arenormally distributed with zero mean p(wk) sim N(0 Q) p(vk) sim N(0 R) Q and R are the processand measurement noise covariance matrices The model used here consists of two state variablesx = (a dadt) with a the altitude (above ground) Later the model was extended to include d2adtso as to facilitate incorporation of accelerometer measurements One problem with the real sensorswas a clear deviation of the measurement noise from the assumed normal distribution and had tobe corrected for in preprocessing

414 PID controller

The Kalman lter state estimate can nally be used as the input to a PID throttle controller ThePID model used is a FOPDT integrating model The second input to the controller module is thesetpoint which can be set in the simulation via keyboard- or network-input to the application Therst working PID parametrisation was arrived at through manual tuning which is cumbersome andgives suboptimal results

415 Evolutionary parameter tuning

To prove the concept of using online learning within simulation at least the PID parameters wereoptimised using evolutionary strategies [22] [26] The tness function for this experiment wasconceivably simple chosen as

f(i) =

Nsum0

|xset minus xik| (4)

with individual i (a tuple (P ID)) setpoint xset the experiments duration in time steps N andthe altitude xik at time step k resulting from execution of controller i This stage involved setting upthe system so that simulation state and model parametrisation (the P I and D coecients) could

19

be controlled programmatically It was realised over a UDPIP connection between crrcsim andthe external simctrl control shell 21 implemented in the Python language 22 The results of theexperiment have been presented in [10]

42 MKcom2

MKcom short for MikroKopter communication tool was designed as a minimal software layer tosit on top of the UART communication link to the main ight board It provides a console baseduser interface for activation and conguration of a set of thin control functions and can act as agateway between the FC and a CMUcam MKcom functions can send commands to the FC andincoming UART packets are dispatched to the appropriate message handler This tool implementedthe modied MK message set

The setup was used as the basis for prototyping several versions of the control loop structureoutlined in Figures 12 and 13 The internal organisation of these implementations can be seenin Figure 14 Three dierent controller cores were realised which incrementally incorporated moremeasurement channels heuristic detail and safety hooks The detailed ow structure of the controllerdesign will be outlined below The update rate and execution timings are dictated by the arrivalof the measurement vector from the FC Auxiliary sensors were integrated asynchronously into themain loop A custom groundstation for state logging and realtime plotting was connected to thenetwork downlink indicated in the diagram

421 MKcom2 Flow structure

On startup a request for debug structure emission is sent manually from the mkcom shell to the FCwith the debug n command where n is the desired sampling interval in milliseconds An examplesession excerpt looks (slightly beautied) as follows (`gt indicates the shells command prompt `is the startsign of the MK protocol strings starting with ` is the raw ascii data going over thewire)gt debug 100

tx bdV ===Ds

gt

rxbuf 93 bD===IgtpU gtomgtS=xTyf=DL|pA= gt===Kl|Lnx=mL=I===i=BM|| oXfT_UrePI=T]=gt==E=|l|

L=IE||y===Y=qM

_DebugOut_ 1804 310 203 854 -843 420 -49 49 4

2 -21-1016 123 828 828 0 11 21

-1-5850 9822 -24267 51 94 1 2 -2

207 706 -1 0 7

rxbuf 93 bD===ggtpi gtm=gtT=oxzd]DL|o===m=A=Kl|ALnx=mL=I===E=m=== KxYSourePI=T]====A===

L=IM||y===Y=nf

_DebugOut_ 1834 315 192 855 -722 414 -49 32 3

4 -21-1008 123 828 828 0 2 15

0 -897811867-24267 51 94 0 1 0

207 708 -1 0 7

gt debug 0

tx bd====DZ

gt

21httpwww2informatikhu-berlinde~obertholQK22Python Language httpwwwpythonorg

20

The debug vector is populated in the FC where element positions correspond with value typesIt includes IMU data manual control input from the RC and the barometer as well as systemstatus values such as battery voltage RSSI value ampc Depending on the setup it can include thereading from the sonar as well If the actual controller is activated with eggt ac3 1

kal_cv_init DP 3 MP 5 CP 0

gt

the controller evaluation function is executed upon each arrival of a debug packet Of coursesome information is retained across calls After computation has nished an extctrl (Externalcontrol) structure is populated and sent back to the FC Aditional measurements such as from anInfraRed Ranger (IRR) are integrated in an asynchronous manner from multiple threads Severalparameters such as the altitude setpoint PID values bias ampc can also be set from the text based userinterface While this works quite well in principle and did achieve good performance modularityand extensibility were not an initial design goal This led to another iteration of the same designwithin the MAVHUB framework which will be described in the next subsection

IO Channels UART TWI UI Network

HAL threads FC-RX Expansion Ctrl Sonar Shell

Processing Controller

mkcom2

Figure 14 Mkcom2 ow-graph

43 Heuristically tuned altitude control software

The vague vision of the overall architecture that is pursued here is that of several concurring moduleswhich are summed in a cooperative time-dependent manner and where each module is responsiblefor various behavioural aspects [1] To ease prototyping and testing of components the structurehas to be kept exible extensible and dynamically recongurable This has to be considered in theoverall onboard software design In order to illustrate this requirement the ow of information andthe interaction with additional behavioural modules will be described in more detail in the followingparagraphs References will be made to several modules operating within the MAVHUB frameworkthe basics of which are described elsewhere [25]

431 Data acquisition

First the controlware has to collect all sensory information from possibly heterogenous sourcesThese include 6 - 9 channels of IMU data (depending on IMU type) a barometric measurementseveral range sensors as well as optical sensors (cameras) and of course any other sensor which is

21

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

1500

2000

Time [s]

Value

throttle

uss_meas

k_s0

Figure 15 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m aboveground The dashed line is the raw sonar range value the solid black line is the estimate uponwhich the PID controller acts The solid green line in the lower part of the plot is the controlleroutput value which is sent to the actuator

available or desired Heterogeneity pertains to hardware channels update rates and data formatsIn MAVHUB there are two main channels if information ow One is the protocol stack whichtransmits volatile incoming messages to all active modules (apps) The other is a shared memoryarea where data can be deposited by any active process In the setup considered here FC data(including IMU barometer and possibly sonar) and intermediate internal data travel on the stackSensors connected via a two-wire bus are operated by sensor drivers and measurements are put intothe shared memory The desired result of this step is to be able to operate on a homogenous vectorof input signals within the main control loop

432 Preprocessing

Subsequent to acquisition each sensory channel is individually preprocessed according to the pe-culiarities of sensor principle and connection mode Preprocessing mostly consists of linearisationunit conversion (inverting the sensor characteristic) and several kinds of heuristic validation

Linearisation For this particular setup linearisation only has to be done for the IRRs Theseare analogue sensors and the output voltage is related to the distance s measured via u(t) = 1

s(t) An example sensor characteristic is displayed in Figure 16 For the dierent subtypes of the Sharpsensors an individually parameterised procedure has to be performed as described by eg Acroname

22

Robotics in [23] if the sensors are processed on a metric basis If the Sharp sensors are driven atthe recommended supply voltage of 5V using the datasheet specications has proven sucientlyaccurate An example script for determining the parameters from given calibration data is suppliedon this reports supplementary website 22

Unit conversion The diverse units of sensor data have to be explicitly converted to units conve-nient for later steps in the calculation in particular sensor fusion with the Kalman lter For thealtitude measurements these are metersminus3 so ADC-units or time-of-ight measurements have to beconverted to millimeters for the analog sensors (barometer accelerometer infrared) and the sonarsensor repsectively This simply amounts to a multiplicative factor

Validation Heuristic sensor data validation has to be done for all types of rangers as well as for thebarometric sensor The spurious readings these sensors produce are of dierent types though Theinfrared rangers display ambigouity beyond the lower limit of the operating ranges see Figure 16For the GP2D120 which can sense the smallest ranges of all sensors this can be mostly neglectedsince the minimal sensing range can hardly be reached due to the mechanical conguration Forall the other sensors output is surpressed when the GP2D120 is active At the upper limit of theIRRs operating range the output is surpressed when a suitable threshold is reached The followingcode example illustrates this where sensor channel number three is the close range IRR

if(in_range(sensors [3] first llim ulim))

valid = 10

else

valid = 00

sensors [3] second = (fir[3]-gtcalc(valid) gt= 099) 1 0

Surpression is realised by setting appropriate values in the measurement transform matrix H(t)of the Kalman lter Alternatively this could be done by generating suitable variances for therespective sensors in the measurement covariance matrix R(t) Driving the IRRs at 33V works butreduces the usable range In addition the IRR sensor measurements are dependent on the groundsurfaces some of which eg an oce carpet can result in erratic results

The ultrasonic sensor is susceptive to dierent kinds of spurious readings caused by late echoesThis happens both when very close to an object or surface or when far away that is beyond theupper limit of measurable distances The validation strategy employed is to set hard empiricallower and upper limits for values as for the IRRs and limiting the maximum dierence betweentwo consecutive values based on assumptions about the maximum velocity An example session isillustrated in Figure 18

Finally the barometer is sensitive to acceleration which has to be accounted for The sensorbehaviour is displayed in Figure 19 The empirical corrections read

BARO (pre [1] correct from accel -z (pre [2])

pre [1] first -= (005 pre [2] first)

The validition process in general produces one new signal per channel to be used later in theprocess for setting Kalman lter matrix values One remaining problem here is the channel cross-dependency

23

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 5: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

(a) Absolute altitude

(b) Terrain following obstacle avoidance

Figure 1 In 1(a) the robot maintains and absolute altitude The range sensors are either surpressedor the robot is too far away from the ground to be able to measure the distance In 1(b) the robotfollows the contour of the terrain

3 Systems

31 Airframes

There are many dierent types of FR only some examples of which can be seen in Figure 2 andFigure 3 Fixed wing apping wing and rotary wing yers have emerged as the most frequentlyused classes of motor powered yers on large and small scales All of these generate lift throughtheir whole body- or component-dynamics (rotors) Dynamic lift is contrasted by balloons airshipsand blimps which are statically buoyant but generally suer from reduced maneuverability andwind susceptibility In between there are all sorts of hybrids which are not easily classied forexample robots capable of hybrid modes of locomotion such as the MMALV [2 9] or VerticalTakeO and Landing (VTOL) vehicles with pivoting rotors or airfoil elements [33 Tail sitter]The remaining part of this work is concerned exclusively with multirotor helicopters (multicopters)although regarding the framework there are many commonalities across all types of yers

Helicopters in general have the advantage of being capable of near-holonomic motion and hov-ering which gives them a certain edge in indoor or constrained-space applications and hence makesthem an overall attractive research platform The main structural advantage of the bare-bonesmulticopter is the omission of all movable parts except for n motors which signicantly reducesmechanical complexity and thereby increases mechanical robustness and maintainability

311 Multicopter ight principle

The vehicle possesses 6 degrees of freedom for movement in space and n actuators On the quadrotortwo rotors are turning clockwise or counter-clockwise respectively Equal rotation rates result inoverall equalisation of torque Changing the rate of one set of co-rotating rotors relative to the othera torque about the vehicle vertical axis is induced and it turns (yaw) Changing the rate relation

5

(a) Quadrotor helicopter (b) Coaxial helicopter

(c) Fixed wing yer (d) Flapping wing yer

Figure 2 Dierent possible airframe types for ying robots a) experimental workhorse Horst b)E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c) Multiplex FunJetphotograph from Paparazzi Wiki by Matthew Currie d) Flapping wing platform photograph byHenryk Ploumltz also with permission

among two co-rotating rotors induces a torque about the perpendicular horizontal axis Both pitchand roll movements are eected in this way in a symmetrical manner By pitching or rolling thethrust vector is deected from the pure vertical direction and the vehicle accelerates laterally Formore details on the working principle and modelling of multirotors see for example [5] [14] or [11]At the level of the individual acutators the system is not manually controllable For this reasonInertial Measurement Units (IMU) are used to realise electronic control of the vehicle attitude AnIMU is a set of sensors that provides information about orientation in space by measuring angularrates acceleration and magnetic forces over three orthogonal axes The attitude control setpointsin turn can be aected by manual or high-level autonomous control input The control vector thusis given by

uT = (pitch roll yaw thrust) (1)

While the principles of inertial navigation have been applied for decades in control of aerial vehi-

6

(a) MMALV 1 (b) MMALV 2

(c) Paparazzi dual airfoil quadrotor taking o (d) Dual airfoil quad after transition to forwardight

Figure 3 Some less prevalent airframe congurations a) and b) Morphing Micro Air and LandVehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobots LLC and Roger Quinnof Case Western Reserve University and c) and d) a Paparazzi based quadrotor with two airfoils(tail sitter design) The pictures are two frames extracted from a video by Antoine Drouin JobyRobotics with kind permission

cles with both analog and digital implementations of the control schemes [12] the use of lightweightlow-cost-and-quality inertial sensors at the same time enables the construction of Micro AerialVehicles (MAV) and poses challenges for the accuracy of the resulting solutions The general ap-proach is to use a complementary system of high-frequency angular rate sensing (gyroscopes) andlow-frequency compensation via acceleration measurements (acceleromoters) In addition informa-tion from magnetic measurements can be incorporated into the attitude estimation if a 9-Degressof Freedom (DoF) IMU is available

312 The robot body

The airframes cited above are examples of FR bodies A brief consideration of some consequencesof the specic conguration is in order The relevant aspects are geometry surface and propulsionGeometry and surface as well as motion type relate to where and how the sensors can actually bemounted In xed winged platforms there is a prefered direction of motion whereas the quadrotordisplays a four-fold structural symmetry and the vehicle front needs to be arbitrarily set Mounting

7

a forward-pointing camera clearly breaks the symmetry in regards to vision based navigation Apossible solution is downward orientation or the use of panoramic lenses see Figure 23

In order to measure the distance to the ground only the downward pointing body surface needsto be considered for sensor mounts (although see GDC below) Obviously acoustic and optical rangesensors need to be unobstructed by other body parts Deviations in range measurements due to non-zero pitch and roll angles during ight are regarded as disturbances in the controller sketched belowThis is in part justied by the nite beam-width of the sonar sensor which intrinsically measuresthe shortest path to a reecting surface Since the absolute error grows linearly with range and theinfrared sensors used here only have very limited range (lt 1m) the deviation is not compensatedeither The scenario is illustrated in Figure 4 the theoretical error for dierent angles and aboslutedistances is plotted in Figure 5 Some more dynamic types of interactions are considered below

θ

e

Figure 4 Distance measurement depending on the angle θ to the ground surface

0 10 20 30 400

200

400

600

Angle [deg]

Error

[mm]

Alt 05 mAlt 1 mAlt 15 mAlt 2 m

Figure 5 Theoretical error over angle for several dierent distances from ground

8

32 Quadrotor systems overview

The quadrotor was conceived in the 1920ies bei Etienne Oehmichen and purportedly ew onlya couple of meters at the time probably due to the manual control problem The concept washibernating for most of the 20th century to resurface as an electronic toy in 1996 The Roswellyer of Area51 Technologies seems to be the earliest appearance of a working miniature quadrotorRC yer [13] Since then development of similar systems has picked up momentum considerablyBy now (2011) there exist a number of projects that are suitable (if not specically designed) asrobotics research platforms of which this section provides an overview The projects backgroundsvary from robotics and remote sensing to hobbyist RC model-ying and electronic toys

While not exclusively targeted at multicopters one of the oldest eorts to develop a versatileand open UAV system (airborne and ground segments) for model yers is the Paparazzi (PPZ)1 project of the Ecole Nationale de lAviation Civile (ENAC) The project was founded in about2003 2 and consists of an extensive set of both hardware and software components The airbornehardware consists of a variety of base processor boards (Tiny TWOG LisaLM) sensor modulesand communication devices The control software consists of a stack of PID control loops whichare executed on the microcontroller boards The overall approach reects a certain outdoor anityConsequently one of the architectures distinctive features is the use of IR thermophiles for absoluteorientation sensing (warm earth cold sky) in outdoor environments Complementing the airbornepart of the project is a comprehensive set of ground segment software and simulation modules Thiscomprises tools for tasks such as logging plotting map-supported on-screen trajectory trackingas well as eg vehicle tracking for servo-controlled directional antennas Communication amongcomponents is realised via the text- and subscription-based IVY software bus 3 which serves as thepoint of entry for component reuse from foreign systems Paparazzi also supports a high-level XMLbased ight-plan description and airframe conguration language Overall the PPZ system oersa mature codebase and a great amount of exibility through open source licensing and a modulardesign

Founded in 2006 the MikroKopter (MK) 4 project quickly gathered momentum in Germany asan RC model-ying vehicle and aerial photography system It is the system used for all experi-ments described in this work The MK architecture is a modular system that can be bought as a kitfrom the producer and consists of a combined IMU and microprocessor board called FlightCtrl (FC)which runs the attitude control software (also FlightCtrl) In fact there are several versions of theFC featuring dierent processors and sensors In addition the project has brought forth specialElectronic Speed Controllers (ESC) which interface control output on a TWI with brushless motorscalled MK-BL The distinctive feature of these controllers is the particularly high update-rate com-pared other other ESCs Consequently the MK-BL are used across many of the other projects seealso Table 1 Optional sensor modules include a compass and GPS components The main factorsfor choosing this particular system were its ready availability at the time of project initiation in2008 cost and source code access The ground and support software for the MikroKopter on theother hand is not ideally suited to demands in robot prototyping There have been attempts atdeveloping open-source and cross-platform alternatives to the vendors MikroKopter Tool althoughin the experiments described below yet other tools were used

1Paparazzi Wiki httppaparazzienacfrwikiMain_Page2httpwwwnongnuorgpaparazzigallery_v0html3Ivy Bus httpwww2tlscenafrproductsivy4MikroKopter httpwwwmikrokopterde

9

Published in late 2008 (according to the Internet Archive) the PIXHAWK (PXH) 5 project ofthe Computer Vision and Geometry Lab at the ETH Zuumlrich is an example of a system designedfrom the ground up as a robotic research platform in this case specically targeted towards visionexperiments PXH also has its own integrated processorIMU module as well as adapter hardwarefor using miniature yet high-capacity computing hardware sometimes referred to as Computer onModule (COM) The software part of the system features a comprehensive groundstation softwarecalled QGroundControl (QGC) and a low overhead communication protocol calledMAVLink 6 Sev-eral other components are provided or are in development The systems components are publishedunder open licenses and the software parts can easily be reused and adapted

Another interesting addition from around 2010 to the growing family of quadrotor systems is theArduCopter (AC) 7 which is designed on top of a more generic autopilot for both xed-wing androtary-wing platforms the ArduPilotMega (APM) 8 which in turn is based on the popular Arduino9 meta-platform The ArduPilot software already makes use of PXHs groundstation QGC throughthe MAVLink protocol In distinction to the projects mentioned so far ArduCopter uses standardunmodied low-cost ESCs for motor control which reects the general low-cost approach of theentire system This approach is most promising in terms community engagement Other relevantprojects in this category are the Unmanned Aerial Video Platform Next Generation (UAVP-NG)10 and OpenPilot 11 projects Both feature co-designed hardware and software but both have notbeen considered more closely due to their state of development during 2010 12

Among the straightforwardly commercial vendors there are two types those targeting profes-sional use outside the RC model community and those attending to the electronic toy marketThe former are mainly used for standard security and surveillance related activities In europethese are Ascending Technologies (AscTec) and microdrones AscTec models also appear in roboticsresearch but require much higher budgets The prominent representatives from the latter categoryare the DraganFlyer of RCToys whose ancestry goes back to the Roswell yer mentioned earlierand most recently the Parrot ARDrone released in 2010 featuring onboard Linux two camerasstabilisation with optical ow and an SDK for custom extensions

321 Systems summary

All these systems dier with regards to sophistication and extendability and clearly none of themprovides out-of-the-box the type of onboard computing system desired for a robotic experimentalframework targeting high-bandwidth signal processing In heterogenous multi-vehicle systems is-sues of interoperability and code-reusability can be expected to become more salient Often easeof use in terms of development and prototyping is traded o for eciency and compact hardwarewhich makes the implementations quite idiomatic

By taking a modularised approach as regards the hardware and employing in the sense ofreusability and ease of programming more powerful Single Board Computers (SBC) or COMscapable of running an operating system dierent systems providing the basic attitude control

5Pixhawk httpwwwethzchpixhawk6MAVLink httpwwwqgroundcontrolorgmavlinkstart7Arducopter httpcodegooglecomparducopter8ArduPilotMega httpcodegooglecompardupilot-mega9Arduino httpwwwarduinocc10UAVP-NG httpnguavpch11OpenPilot httpopenpilotorg12By 2011-06-09 Thu both projects status has considerably advanced

10

such as those mentioned above can be used and wired up with more capable hardware to conductexperiments with a wide range of sensors and algorithms This necessitates the integration of severaldierent downlink and communication frameworks that are in use across dierent systems

One practical option for this part of the system while keeping reusability ease of developmentand energy requirements in mind are ARM-based Linux packages such as the Gumstix or Beagle-board families or similar devices which are available at reasonable prices In summary these werethe considerations that are accumulated in the current state of the HUCH setup described belowThe diverse FR projects can be categorised along an axis indicating the level of targeted behaviourranging from low-level actuator control up to high-level navigation and high performance signalprocessing functionality Table 1 is a graphical representation showing the projects hardware andsoftware components coverage along that axis

Motor Attitude GPS Ground High-perf

UnspecStd PWM ESCs

AscTecDragoncopter

MK MK-BL Flight-Ctrl MKNAV MK-ToolPXH pxIMU via COM QGC COMPPZ TWOG Tiny Lisa GCS COM w LisaAC ArduPilot AC-GS

HUCH COMs

Table 1 Systems overview Of course it is almost always possible to attach a COM to low-levelattitude control platform such as the MK-FC ArduPilotMega or PPZ autopilots over a serialinterface Both PXH and PPZ are designed for use with Gumstix COMs

33 HUCH Sytem

331 Basics

The HUCH project was started to test bio-inspired navigation strategies on ying robots Theproject was initially equipped with basic MK kits The MK is mainly being used for RC modelying and aerial photography but the user community is also active with various other experimentsregarding extentions and modications The platforms distinctive advantages are its price readyavailability and sucient openness for research uses 13 Several academic projects have made orstill make use of the MikroKopter platform

The core component of the MK setup is the FlightCtrl (FC) comprising of both a Printed CircuitBoard (PCB) featuring an IMU a microcontroller and the rmware implementing the attitudestabilisation RC interface telemetry and more The MK architecture also features ESCs (MK-BL) capable of receiving the actuating variable via a TWI interface at a rate of 500 Hz which marksa dierence to other ESCs available on the RC market For that reason the MK-BL is also widelybeing used in many other projects

13Although with recent versions of the FlightCtrl rmware this has started to change

11

Direction Code Command Arguments

Inb Submit external control extctrl structc GyroBaro neutral Noned Request debug vector Update interval or None for one-om Start motors Nonen Kill motors None

OutD Debug vector 32 int16 values

Table 2 Five most important HUCH commands for external control of the modied MK-FC

332 Modications

Software The HUCH group has developed various extensions and modications to the platformOne of these is an expansion of the external control interface see Table 2 via the UART a corre-sponding groundstation (mcut) and control software (mktool) These are the basis for most of thework described in the remaining part of this text

The FlightCtrl microcontroller rmware was modied (HUCH variant) initially based on killa-gregs rewrite of the original rmware and implements among other things the extended communi-cation protocol higher UART baudrates TWI sensor integration and several more items 14 Thereexists a tool 15 to realise realtime display and plotting of debug variables ashing of MikroKopterrmware with embedded avrdude code parameter editing and motor testing The MKcom pro-gramm was initially developed for using a CMUcam to control the MikroKopter from vision inputIt features the basic FC communication stack and a control console This last item served as thebasis of the rst prototype of a Linux based altitude control At the time of writing develop-ment of these tools has been abandoned in favor of Micro Aerial Vehicle Humboldt Universitaumlt zuBerlin (MAVHUB) which is described in more detail elsewhere [25]

Computing hardware To overcome the severe restrictions of the Atmel ATMega644 being usedon the FC it is necessary to attach additional processing hardware Stating it more simply a singlemicrocontroller clearly is not suitable for any kind of slightly more demanding processing For thispurpose to date dierent single board systems have been used the Gumstix Verdex Pro 16 andBeagleboard variants 17 as can be seen in the gures 6 and 7 Several other options are availableand could be utilised in the future as our approach is construed exible in this regard Working ona Linux system provides a huge advantage in abstracting the algorithms from the hardware TheLinux system is connected to the FlightCtrl via the UART port In order to achieve a sampling rateof 100 Hz a baudrate of 230400 kbaud needs to be set on this connection The DebugOut messagestructure counts 95 bytes on the wire The motor command takes up 22 bytes giving 117 bytes forone sense-act cycle At the given channel capacity (25600 bytes per second) this gives approximately

14HUCH FlightCtrl 071i httpkoroinformatikhu-berlindeqkdownloadsV071i_huch-code_motodrone09targz

15mcut httpkoroinformatikhu-berlindeqkdownloadsmcuttargz16Gumstix Verdex Pro httpwwwgumstixcomproductverdex-pro17Beagleboard httpwwwbeagleboardorg

12

218 full cycles per second under optimal conditions and should be sucient for processing at 100Hz There are problems with nding higher baudrates that are supported on both sides of theconnection due to the 20 MHz clocking of the microcontroller

(a) Verdex View 1 (b) Verdex View 2

Figure 6 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below andthe expansion board on above On top is a USB WiFi dongle

A custom ATMega based ADC expansion board is acting as a generic analog data aqcisitiondevice Analog measurements are multiplexed and transmitted down a Two Wire Interface (TWI)link to the main control COM In a dierent setup an Arduino Mini was substituted for the customboard

Sensors For altitude measurement three dierent sensors were added to the setup A barometricpressure sensor is already provided for in the vendor board design This sensor is quite noisy butcovers a large range of measurement When close to the ground range sensors can be used tomeasure the distance Of this type we used a Devantech SRF02 sonic range nder This sensorhas an integrated microcontroller that does time-of-ight calculations for an ultrasonic pulse andtransmits the result digitally over a two wire interface (TWI) The speed of sound vs the actualdistance determine the maximum update frequency In our experiments these were xed at a rateof approximately 50 Hz In addition we attached two Sharp type infrared rangers (GP2Y0A02YKGP2D120) to the robot These output an analog voltage inversely proportional to the distancemeasured They are connected to the expansion board which also transmits updates via TWI butat a rate of 100 Hz The physical conguration of the range sensors is depicted in Figure 8

13

Figure 7 The electronic stack on this copter consists of (in ascending order) FC Power and UARTbreakout Beagle breakout and Arduino Mini mount BeagleBoard and USB WiFi Dongle

333 Physical system

As has been described above the FC can be given actuation commands via both the RC and UARTinterfaces in the form of the four-element vector 1 The SBC used in this particular conguration isthe Gumstix Verdex Pro X6LP The gumstix receives its power supply of 5V DC from the FC andtalks to it over the FFUART without additional level converters The hardware component setupis depicted schematically in Figure 9 On the left hand side of the diagram the base MikroKoptersetup is seen with the FlightCtrl RC receiver and the four ESCs On the right hand side theVerdex and custom sensor board are situated realising highlevel control and UDPIP link to thegroundstation over WiFi For the operation of a second onboard SBC the Beagleboard in Figure 9an additional voltage controller had to be used between the 12V DC rail and the Beagleboard powersupply socket

OpenEmbedded The current gumstix system software is provided via the Aringngstroumlm 18 distri-bution which is based on OpenEmbedded 19 The gumstix overlay provides Linux kernel versions2621 and 2631 Unfortunately the driver for the gumstix onboard WLAN hardware (netvx boardw a Marvell cf25 chip) changed between those versions and the one in 2631 refuses to actually

18Angstrom Distribution httpwwwangstrom-distributionorg19OpenEmbedded httpwwwopenembeddedorg

14

Figure 8 Range sensors attached to frame

RC receiver Onboard electronics

BL1 Expansion Board

BL4 FlightCtrl BL3

BL2 Gumstix

Camera BeagleBoard

TWI

UART

TWI

Wi

LAN

USB

Figure 9 Basic HUCH onboard electronics The left hand region of the picture consisting of receiverFC and brushless motor controllers BL1minus4 represents the standard MK setup while the right handregion represents HUCH additions

work with our hardware so a dierent solution had to be found Fortunately here the USB sub-system works well out of the box and standard USB WLAN hardware could be used to set up thelink Running the system o an SD-card as well as TWI (I2C) support in Linux work well Onemore aspect of the WLAN setup is worth noting though It was desired to realise the wireless linkto the onboard Linux in Ad-Hoc mode for two reasons The rst is reduced startup time when usingAd-Hoc mode the second is independence of access point infrastructure In this way the minimalFR groundstation conguration can be operated in a more mobile manner In principle one of thenodes could be operated in Master mode but this is not supported by all hardware

Once the live Linux system and cross-compilation environment was up and running the MKcom

15

software provided the basis for further work on controller implementation Looking at the Linuxsystem at this point the following view presents itself in Figure 10

Gumstix

AringngstroumlmLinux 2631 SD

UIShell mktool wlan0

devttyS1 devi2c-0

FC Exp Groundstation

RxTx wires

Wireless link

Figure 10 Basic Linux setup

4 Experiments

41 Basic structural design through simulation

Initially the problem of altitude control was analysed in simulation To that end a simple con-troller was realised within the crrcsim 20 RC model simulator There are basically two possiblemethodological approaches to setting up a simulation for a model helicopter One is the derivationof the model from rst principles and implementation from scratch The other is building uponexisting if simplifying solutions that are practically usable and open for modication

A moderately physically realistic model of a quadrotor aerial system is governed by a nontrivialnonlinear dierential equation [3 pg 155] [4] Much microscopic detail can be added for furtherrenement as the need arises Such details are discussed to some extent in [14] and [8] In the near-hover ight regime the system behaves quasi-linearly but at more extreme velocities and attitudesthe increasing impact of several nonlinear eects such as blade apping vortex ring states orforward translational lift would have to be considered For our purposes these eects have so farbeen neglected but could in princpiple be incorporated into the model

Circumventing the necessity of model derivation and implementation the second approach waschosen In particular the existing real-time ready crrcsim [7] RC-model simulator software wasmodied to conduct the initial experiments This was particularly facilitated by the prior work ofJens W Wulf who implemented a quadrotor model and internal controller substructures for thissimulation framework [32] A screenshot of the Wulf-model ying in the modied simulation in canbe seen in Figure 11 crrcsim comes with an internal controller architecture that realises dierent

20Charles River Radio Controllers Simulation httpcrrcsimberliosde

16

attitude controllers The software originally is designed to interface manual control hardware suchas RC transmitters joysticks and such to the simulation engine It was modied to implementadditional controllers detailed state information output for plotting and analysis and networkedcontrol of the simulation engine A drawback of crrcsim is its monolithic architecture For futurework the core simulation engine would have to be separated from the render engine Alternativelythe PPZ approach could be used as a drop-in replacement

Figure 11 Simulation screenshot The helicopter model landscape and text console are part ofcrrcsim The actual debugging output that can be seen in the console is part of custom modications

411 Closed loop

The basic structure of the full control loop is displayed in Figure 12 The control module embeddedin the loop is a Single-Input Single-Output (SISO) type controller The actuating variable undercontrol is thrust which eects overall lift (see above) while the other three components are mostlycontrolled manually during the experiments The input to the controller is the current altitudeestimate The estimation process potentially has to consider multiple measurements which have tobe fused into a single representation

412 Measurements

In simulation global knowledge of the world- (and agent-) state is available and all system variablesare immediatly accessible This allows to use a simplied signal-ow structure which is depicted in

17

Measurements

z0

z1 Kalman lter Controller

Fusion Estimate PID System

znminus1

zn

throttle

Behaviour

setpoint

Figure 12 Controller structure with measurement branch

gure 13 In order for the controller to be structurally transferable to the real hardware system thespecic sensor conguration has to be modelled within the simulator This included preparationof IMU data by tapping the Flight Dynamics Model (FDM) module and basic modelling of therespective characteristics of the barometric and ultrasonic range sensors which were in use on thehelicopter at that time In the case of the barometer this meant the addition of white gaussiannoise A slow drift which can be observed on the real sensor due to slow air-pressure changes wasneglected For the ultrasonic range sensor the timing characteristic that is the maximum updaterate dependent on distance measured was emulated The information thus synthesized was fed intoa Kalman lter for further processing

Controller

PID Systemthrottle

Flight dynamics model

setpoint

Figure 13 Simplied controller structure

413 Sensor fusion

Sensor fusion is a problem class on its own The base intent is to derive an estimate of a systemstate variable from multiple measurements that is more reliable than it would be by using only asingle measurement There are several approaches which have been developed over the last decadesand which could be employed for this task The complementary lter approach can be chosen if the

18

sensors are aected by suciently dierent kinds of noise and thus eg spectrally complementarylters can be used on dierent measurement channels which are then linearily combined into a singlevalue Probably the most commonly used techniques are the linear Kalman lter and its nonlinearvariants Other methods are nonexhaustively Bayesian strategies such as Particle lters H-infinlters or neural networks A linear Kalman lter was chosen in the current setup for the reasonthat the lter and its characteristics are well documented and the implementation is straightforwardboth from scratch and even more so using matrix algebra libraries such as OpenCV The basic ltertask is to estimate the state xk isin Rn of a discrete time system governed by the linear stochasticequation [29] [15]

xk = Axkminus1 +Bukminus1 + wkminus1 (2)

based on a measurement zk isin Rm given as

zk = Hxk + vk (3)

where wk vk are random variables which represent process noise and measurement noise and arenormally distributed with zero mean p(wk) sim N(0 Q) p(vk) sim N(0 R) Q and R are the processand measurement noise covariance matrices The model used here consists of two state variablesx = (a dadt) with a the altitude (above ground) Later the model was extended to include d2adtso as to facilitate incorporation of accelerometer measurements One problem with the real sensorswas a clear deviation of the measurement noise from the assumed normal distribution and had tobe corrected for in preprocessing

414 PID controller

The Kalman lter state estimate can nally be used as the input to a PID throttle controller ThePID model used is a FOPDT integrating model The second input to the controller module is thesetpoint which can be set in the simulation via keyboard- or network-input to the application Therst working PID parametrisation was arrived at through manual tuning which is cumbersome andgives suboptimal results

415 Evolutionary parameter tuning

To prove the concept of using online learning within simulation at least the PID parameters wereoptimised using evolutionary strategies [22] [26] The tness function for this experiment wasconceivably simple chosen as

f(i) =

Nsum0

|xset minus xik| (4)

with individual i (a tuple (P ID)) setpoint xset the experiments duration in time steps N andthe altitude xik at time step k resulting from execution of controller i This stage involved setting upthe system so that simulation state and model parametrisation (the P I and D coecients) could

19

be controlled programmatically It was realised over a UDPIP connection between crrcsim andthe external simctrl control shell 21 implemented in the Python language 22 The results of theexperiment have been presented in [10]

42 MKcom2

MKcom short for MikroKopter communication tool was designed as a minimal software layer tosit on top of the UART communication link to the main ight board It provides a console baseduser interface for activation and conguration of a set of thin control functions and can act as agateway between the FC and a CMUcam MKcom functions can send commands to the FC andincoming UART packets are dispatched to the appropriate message handler This tool implementedthe modied MK message set

The setup was used as the basis for prototyping several versions of the control loop structureoutlined in Figures 12 and 13 The internal organisation of these implementations can be seenin Figure 14 Three dierent controller cores were realised which incrementally incorporated moremeasurement channels heuristic detail and safety hooks The detailed ow structure of the controllerdesign will be outlined below The update rate and execution timings are dictated by the arrivalof the measurement vector from the FC Auxiliary sensors were integrated asynchronously into themain loop A custom groundstation for state logging and realtime plotting was connected to thenetwork downlink indicated in the diagram

421 MKcom2 Flow structure

On startup a request for debug structure emission is sent manually from the mkcom shell to the FCwith the debug n command where n is the desired sampling interval in milliseconds An examplesession excerpt looks (slightly beautied) as follows (`gt indicates the shells command prompt `is the startsign of the MK protocol strings starting with ` is the raw ascii data going over thewire)gt debug 100

tx bdV ===Ds

gt

rxbuf 93 bD===IgtpU gtomgtS=xTyf=DL|pA= gt===Kl|Lnx=mL=I===i=BM|| oXfT_UrePI=T]=gt==E=|l|

L=IE||y===Y=qM

_DebugOut_ 1804 310 203 854 -843 420 -49 49 4

2 -21-1016 123 828 828 0 11 21

-1-5850 9822 -24267 51 94 1 2 -2

207 706 -1 0 7

rxbuf 93 bD===ggtpi gtm=gtT=oxzd]DL|o===m=A=Kl|ALnx=mL=I===E=m=== KxYSourePI=T]====A===

L=IM||y===Y=nf

_DebugOut_ 1834 315 192 855 -722 414 -49 32 3

4 -21-1008 123 828 828 0 2 15

0 -897811867-24267 51 94 0 1 0

207 708 -1 0 7

gt debug 0

tx bd====DZ

gt

21httpwww2informatikhu-berlinde~obertholQK22Python Language httpwwwpythonorg

20

The debug vector is populated in the FC where element positions correspond with value typesIt includes IMU data manual control input from the RC and the barometer as well as systemstatus values such as battery voltage RSSI value ampc Depending on the setup it can include thereading from the sonar as well If the actual controller is activated with eggt ac3 1

kal_cv_init DP 3 MP 5 CP 0

gt

the controller evaluation function is executed upon each arrival of a debug packet Of coursesome information is retained across calls After computation has nished an extctrl (Externalcontrol) structure is populated and sent back to the FC Aditional measurements such as from anInfraRed Ranger (IRR) are integrated in an asynchronous manner from multiple threads Severalparameters such as the altitude setpoint PID values bias ampc can also be set from the text based userinterface While this works quite well in principle and did achieve good performance modularityand extensibility were not an initial design goal This led to another iteration of the same designwithin the MAVHUB framework which will be described in the next subsection

IO Channels UART TWI UI Network

HAL threads FC-RX Expansion Ctrl Sonar Shell

Processing Controller

mkcom2

Figure 14 Mkcom2 ow-graph

43 Heuristically tuned altitude control software

The vague vision of the overall architecture that is pursued here is that of several concurring moduleswhich are summed in a cooperative time-dependent manner and where each module is responsiblefor various behavioural aspects [1] To ease prototyping and testing of components the structurehas to be kept exible extensible and dynamically recongurable This has to be considered in theoverall onboard software design In order to illustrate this requirement the ow of information andthe interaction with additional behavioural modules will be described in more detail in the followingparagraphs References will be made to several modules operating within the MAVHUB frameworkthe basics of which are described elsewhere [25]

431 Data acquisition

First the controlware has to collect all sensory information from possibly heterogenous sourcesThese include 6 - 9 channels of IMU data (depending on IMU type) a barometric measurementseveral range sensors as well as optical sensors (cameras) and of course any other sensor which is

21

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

1500

2000

Time [s]

Value

throttle

uss_meas

k_s0

Figure 15 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m aboveground The dashed line is the raw sonar range value the solid black line is the estimate uponwhich the PID controller acts The solid green line in the lower part of the plot is the controlleroutput value which is sent to the actuator

available or desired Heterogeneity pertains to hardware channels update rates and data formatsIn MAVHUB there are two main channels if information ow One is the protocol stack whichtransmits volatile incoming messages to all active modules (apps) The other is a shared memoryarea where data can be deposited by any active process In the setup considered here FC data(including IMU barometer and possibly sonar) and intermediate internal data travel on the stackSensors connected via a two-wire bus are operated by sensor drivers and measurements are put intothe shared memory The desired result of this step is to be able to operate on a homogenous vectorof input signals within the main control loop

432 Preprocessing

Subsequent to acquisition each sensory channel is individually preprocessed according to the pe-culiarities of sensor principle and connection mode Preprocessing mostly consists of linearisationunit conversion (inverting the sensor characteristic) and several kinds of heuristic validation

Linearisation For this particular setup linearisation only has to be done for the IRRs Theseare analogue sensors and the output voltage is related to the distance s measured via u(t) = 1

s(t) An example sensor characteristic is displayed in Figure 16 For the dierent subtypes of the Sharpsensors an individually parameterised procedure has to be performed as described by eg Acroname

22

Robotics in [23] if the sensors are processed on a metric basis If the Sharp sensors are driven atthe recommended supply voltage of 5V using the datasheet specications has proven sucientlyaccurate An example script for determining the parameters from given calibration data is suppliedon this reports supplementary website 22

Unit conversion The diverse units of sensor data have to be explicitly converted to units conve-nient for later steps in the calculation in particular sensor fusion with the Kalman lter For thealtitude measurements these are metersminus3 so ADC-units or time-of-ight measurements have to beconverted to millimeters for the analog sensors (barometer accelerometer infrared) and the sonarsensor repsectively This simply amounts to a multiplicative factor

Validation Heuristic sensor data validation has to be done for all types of rangers as well as for thebarometric sensor The spurious readings these sensors produce are of dierent types though Theinfrared rangers display ambigouity beyond the lower limit of the operating ranges see Figure 16For the GP2D120 which can sense the smallest ranges of all sensors this can be mostly neglectedsince the minimal sensing range can hardly be reached due to the mechanical conguration Forall the other sensors output is surpressed when the GP2D120 is active At the upper limit of theIRRs operating range the output is surpressed when a suitable threshold is reached The followingcode example illustrates this where sensor channel number three is the close range IRR

if(in_range(sensors [3] first llim ulim))

valid = 10

else

valid = 00

sensors [3] second = (fir[3]-gtcalc(valid) gt= 099) 1 0

Surpression is realised by setting appropriate values in the measurement transform matrix H(t)of the Kalman lter Alternatively this could be done by generating suitable variances for therespective sensors in the measurement covariance matrix R(t) Driving the IRRs at 33V works butreduces the usable range In addition the IRR sensor measurements are dependent on the groundsurfaces some of which eg an oce carpet can result in erratic results

The ultrasonic sensor is susceptive to dierent kinds of spurious readings caused by late echoesThis happens both when very close to an object or surface or when far away that is beyond theupper limit of measurable distances The validation strategy employed is to set hard empiricallower and upper limits for values as for the IRRs and limiting the maximum dierence betweentwo consecutive values based on assumptions about the maximum velocity An example session isillustrated in Figure 18

Finally the barometer is sensitive to acceleration which has to be accounted for The sensorbehaviour is displayed in Figure 19 The empirical corrections read

BARO (pre [1] correct from accel -z (pre [2])

pre [1] first -= (005 pre [2] first)

The validition process in general produces one new signal per channel to be used later in theprocess for setting Kalman lter matrix values One remaining problem here is the channel cross-dependency

23

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 6: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

(a) Quadrotor helicopter (b) Coaxial helicopter

(c) Fixed wing yer (d) Flapping wing yer

Figure 2 Dierent possible airframe types for ying robots a) experimental workhorse Horst b)E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c) Multiplex FunJetphotograph from Paparazzi Wiki by Matthew Currie d) Flapping wing platform photograph byHenryk Ploumltz also with permission

among two co-rotating rotors induces a torque about the perpendicular horizontal axis Both pitchand roll movements are eected in this way in a symmetrical manner By pitching or rolling thethrust vector is deected from the pure vertical direction and the vehicle accelerates laterally Formore details on the working principle and modelling of multirotors see for example [5] [14] or [11]At the level of the individual acutators the system is not manually controllable For this reasonInertial Measurement Units (IMU) are used to realise electronic control of the vehicle attitude AnIMU is a set of sensors that provides information about orientation in space by measuring angularrates acceleration and magnetic forces over three orthogonal axes The attitude control setpointsin turn can be aected by manual or high-level autonomous control input The control vector thusis given by

uT = (pitch roll yaw thrust) (1)

While the principles of inertial navigation have been applied for decades in control of aerial vehi-

6

(a) MMALV 1 (b) MMALV 2

(c) Paparazzi dual airfoil quadrotor taking o (d) Dual airfoil quad after transition to forwardight

Figure 3 Some less prevalent airframe congurations a) and b) Morphing Micro Air and LandVehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobots LLC and Roger Quinnof Case Western Reserve University and c) and d) a Paparazzi based quadrotor with two airfoils(tail sitter design) The pictures are two frames extracted from a video by Antoine Drouin JobyRobotics with kind permission

cles with both analog and digital implementations of the control schemes [12] the use of lightweightlow-cost-and-quality inertial sensors at the same time enables the construction of Micro AerialVehicles (MAV) and poses challenges for the accuracy of the resulting solutions The general ap-proach is to use a complementary system of high-frequency angular rate sensing (gyroscopes) andlow-frequency compensation via acceleration measurements (acceleromoters) In addition informa-tion from magnetic measurements can be incorporated into the attitude estimation if a 9-Degressof Freedom (DoF) IMU is available

312 The robot body

The airframes cited above are examples of FR bodies A brief consideration of some consequencesof the specic conguration is in order The relevant aspects are geometry surface and propulsionGeometry and surface as well as motion type relate to where and how the sensors can actually bemounted In xed winged platforms there is a prefered direction of motion whereas the quadrotordisplays a four-fold structural symmetry and the vehicle front needs to be arbitrarily set Mounting

7

a forward-pointing camera clearly breaks the symmetry in regards to vision based navigation Apossible solution is downward orientation or the use of panoramic lenses see Figure 23

In order to measure the distance to the ground only the downward pointing body surface needsto be considered for sensor mounts (although see GDC below) Obviously acoustic and optical rangesensors need to be unobstructed by other body parts Deviations in range measurements due to non-zero pitch and roll angles during ight are regarded as disturbances in the controller sketched belowThis is in part justied by the nite beam-width of the sonar sensor which intrinsically measuresthe shortest path to a reecting surface Since the absolute error grows linearly with range and theinfrared sensors used here only have very limited range (lt 1m) the deviation is not compensatedeither The scenario is illustrated in Figure 4 the theoretical error for dierent angles and aboslutedistances is plotted in Figure 5 Some more dynamic types of interactions are considered below

θ

e

Figure 4 Distance measurement depending on the angle θ to the ground surface

0 10 20 30 400

200

400

600

Angle [deg]

Error

[mm]

Alt 05 mAlt 1 mAlt 15 mAlt 2 m

Figure 5 Theoretical error over angle for several dierent distances from ground

8

32 Quadrotor systems overview

The quadrotor was conceived in the 1920ies bei Etienne Oehmichen and purportedly ew onlya couple of meters at the time probably due to the manual control problem The concept washibernating for most of the 20th century to resurface as an electronic toy in 1996 The Roswellyer of Area51 Technologies seems to be the earliest appearance of a working miniature quadrotorRC yer [13] Since then development of similar systems has picked up momentum considerablyBy now (2011) there exist a number of projects that are suitable (if not specically designed) asrobotics research platforms of which this section provides an overview The projects backgroundsvary from robotics and remote sensing to hobbyist RC model-ying and electronic toys

While not exclusively targeted at multicopters one of the oldest eorts to develop a versatileand open UAV system (airborne and ground segments) for model yers is the Paparazzi (PPZ)1 project of the Ecole Nationale de lAviation Civile (ENAC) The project was founded in about2003 2 and consists of an extensive set of both hardware and software components The airbornehardware consists of a variety of base processor boards (Tiny TWOG LisaLM) sensor modulesand communication devices The control software consists of a stack of PID control loops whichare executed on the microcontroller boards The overall approach reects a certain outdoor anityConsequently one of the architectures distinctive features is the use of IR thermophiles for absoluteorientation sensing (warm earth cold sky) in outdoor environments Complementing the airbornepart of the project is a comprehensive set of ground segment software and simulation modules Thiscomprises tools for tasks such as logging plotting map-supported on-screen trajectory trackingas well as eg vehicle tracking for servo-controlled directional antennas Communication amongcomponents is realised via the text- and subscription-based IVY software bus 3 which serves as thepoint of entry for component reuse from foreign systems Paparazzi also supports a high-level XMLbased ight-plan description and airframe conguration language Overall the PPZ system oersa mature codebase and a great amount of exibility through open source licensing and a modulardesign

Founded in 2006 the MikroKopter (MK) 4 project quickly gathered momentum in Germany asan RC model-ying vehicle and aerial photography system It is the system used for all experi-ments described in this work The MK architecture is a modular system that can be bought as a kitfrom the producer and consists of a combined IMU and microprocessor board called FlightCtrl (FC)which runs the attitude control software (also FlightCtrl) In fact there are several versions of theFC featuring dierent processors and sensors In addition the project has brought forth specialElectronic Speed Controllers (ESC) which interface control output on a TWI with brushless motorscalled MK-BL The distinctive feature of these controllers is the particularly high update-rate com-pared other other ESCs Consequently the MK-BL are used across many of the other projects seealso Table 1 Optional sensor modules include a compass and GPS components The main factorsfor choosing this particular system were its ready availability at the time of project initiation in2008 cost and source code access The ground and support software for the MikroKopter on theother hand is not ideally suited to demands in robot prototyping There have been attempts atdeveloping open-source and cross-platform alternatives to the vendors MikroKopter Tool althoughin the experiments described below yet other tools were used

1Paparazzi Wiki httppaparazzienacfrwikiMain_Page2httpwwwnongnuorgpaparazzigallery_v0html3Ivy Bus httpwww2tlscenafrproductsivy4MikroKopter httpwwwmikrokopterde

9

Published in late 2008 (according to the Internet Archive) the PIXHAWK (PXH) 5 project ofthe Computer Vision and Geometry Lab at the ETH Zuumlrich is an example of a system designedfrom the ground up as a robotic research platform in this case specically targeted towards visionexperiments PXH also has its own integrated processorIMU module as well as adapter hardwarefor using miniature yet high-capacity computing hardware sometimes referred to as Computer onModule (COM) The software part of the system features a comprehensive groundstation softwarecalled QGroundControl (QGC) and a low overhead communication protocol calledMAVLink 6 Sev-eral other components are provided or are in development The systems components are publishedunder open licenses and the software parts can easily be reused and adapted

Another interesting addition from around 2010 to the growing family of quadrotor systems is theArduCopter (AC) 7 which is designed on top of a more generic autopilot for both xed-wing androtary-wing platforms the ArduPilotMega (APM) 8 which in turn is based on the popular Arduino9 meta-platform The ArduPilot software already makes use of PXHs groundstation QGC throughthe MAVLink protocol In distinction to the projects mentioned so far ArduCopter uses standardunmodied low-cost ESCs for motor control which reects the general low-cost approach of theentire system This approach is most promising in terms community engagement Other relevantprojects in this category are the Unmanned Aerial Video Platform Next Generation (UAVP-NG)10 and OpenPilot 11 projects Both feature co-designed hardware and software but both have notbeen considered more closely due to their state of development during 2010 12

Among the straightforwardly commercial vendors there are two types those targeting profes-sional use outside the RC model community and those attending to the electronic toy marketThe former are mainly used for standard security and surveillance related activities In europethese are Ascending Technologies (AscTec) and microdrones AscTec models also appear in roboticsresearch but require much higher budgets The prominent representatives from the latter categoryare the DraganFlyer of RCToys whose ancestry goes back to the Roswell yer mentioned earlierand most recently the Parrot ARDrone released in 2010 featuring onboard Linux two camerasstabilisation with optical ow and an SDK for custom extensions

321 Systems summary

All these systems dier with regards to sophistication and extendability and clearly none of themprovides out-of-the-box the type of onboard computing system desired for a robotic experimentalframework targeting high-bandwidth signal processing In heterogenous multi-vehicle systems is-sues of interoperability and code-reusability can be expected to become more salient Often easeof use in terms of development and prototyping is traded o for eciency and compact hardwarewhich makes the implementations quite idiomatic

By taking a modularised approach as regards the hardware and employing in the sense ofreusability and ease of programming more powerful Single Board Computers (SBC) or COMscapable of running an operating system dierent systems providing the basic attitude control

5Pixhawk httpwwwethzchpixhawk6MAVLink httpwwwqgroundcontrolorgmavlinkstart7Arducopter httpcodegooglecomparducopter8ArduPilotMega httpcodegooglecompardupilot-mega9Arduino httpwwwarduinocc10UAVP-NG httpnguavpch11OpenPilot httpopenpilotorg12By 2011-06-09 Thu both projects status has considerably advanced

10

such as those mentioned above can be used and wired up with more capable hardware to conductexperiments with a wide range of sensors and algorithms This necessitates the integration of severaldierent downlink and communication frameworks that are in use across dierent systems

One practical option for this part of the system while keeping reusability ease of developmentand energy requirements in mind are ARM-based Linux packages such as the Gumstix or Beagle-board families or similar devices which are available at reasonable prices In summary these werethe considerations that are accumulated in the current state of the HUCH setup described belowThe diverse FR projects can be categorised along an axis indicating the level of targeted behaviourranging from low-level actuator control up to high-level navigation and high performance signalprocessing functionality Table 1 is a graphical representation showing the projects hardware andsoftware components coverage along that axis

Motor Attitude GPS Ground High-perf

UnspecStd PWM ESCs

AscTecDragoncopter

MK MK-BL Flight-Ctrl MKNAV MK-ToolPXH pxIMU via COM QGC COMPPZ TWOG Tiny Lisa GCS COM w LisaAC ArduPilot AC-GS

HUCH COMs

Table 1 Systems overview Of course it is almost always possible to attach a COM to low-levelattitude control platform such as the MK-FC ArduPilotMega or PPZ autopilots over a serialinterface Both PXH and PPZ are designed for use with Gumstix COMs

33 HUCH Sytem

331 Basics

The HUCH project was started to test bio-inspired navigation strategies on ying robots Theproject was initially equipped with basic MK kits The MK is mainly being used for RC modelying and aerial photography but the user community is also active with various other experimentsregarding extentions and modications The platforms distinctive advantages are its price readyavailability and sucient openness for research uses 13 Several academic projects have made orstill make use of the MikroKopter platform

The core component of the MK setup is the FlightCtrl (FC) comprising of both a Printed CircuitBoard (PCB) featuring an IMU a microcontroller and the rmware implementing the attitudestabilisation RC interface telemetry and more The MK architecture also features ESCs (MK-BL) capable of receiving the actuating variable via a TWI interface at a rate of 500 Hz which marksa dierence to other ESCs available on the RC market For that reason the MK-BL is also widelybeing used in many other projects

13Although with recent versions of the FlightCtrl rmware this has started to change

11

Direction Code Command Arguments

Inb Submit external control extctrl structc GyroBaro neutral Noned Request debug vector Update interval or None for one-om Start motors Nonen Kill motors None

OutD Debug vector 32 int16 values

Table 2 Five most important HUCH commands for external control of the modied MK-FC

332 Modications

Software The HUCH group has developed various extensions and modications to the platformOne of these is an expansion of the external control interface see Table 2 via the UART a corre-sponding groundstation (mcut) and control software (mktool) These are the basis for most of thework described in the remaining part of this text

The FlightCtrl microcontroller rmware was modied (HUCH variant) initially based on killa-gregs rewrite of the original rmware and implements among other things the extended communi-cation protocol higher UART baudrates TWI sensor integration and several more items 14 Thereexists a tool 15 to realise realtime display and plotting of debug variables ashing of MikroKopterrmware with embedded avrdude code parameter editing and motor testing The MKcom pro-gramm was initially developed for using a CMUcam to control the MikroKopter from vision inputIt features the basic FC communication stack and a control console This last item served as thebasis of the rst prototype of a Linux based altitude control At the time of writing develop-ment of these tools has been abandoned in favor of Micro Aerial Vehicle Humboldt Universitaumlt zuBerlin (MAVHUB) which is described in more detail elsewhere [25]

Computing hardware To overcome the severe restrictions of the Atmel ATMega644 being usedon the FC it is necessary to attach additional processing hardware Stating it more simply a singlemicrocontroller clearly is not suitable for any kind of slightly more demanding processing For thispurpose to date dierent single board systems have been used the Gumstix Verdex Pro 16 andBeagleboard variants 17 as can be seen in the gures 6 and 7 Several other options are availableand could be utilised in the future as our approach is construed exible in this regard Working ona Linux system provides a huge advantage in abstracting the algorithms from the hardware TheLinux system is connected to the FlightCtrl via the UART port In order to achieve a sampling rateof 100 Hz a baudrate of 230400 kbaud needs to be set on this connection The DebugOut messagestructure counts 95 bytes on the wire The motor command takes up 22 bytes giving 117 bytes forone sense-act cycle At the given channel capacity (25600 bytes per second) this gives approximately

14HUCH FlightCtrl 071i httpkoroinformatikhu-berlindeqkdownloadsV071i_huch-code_motodrone09targz

15mcut httpkoroinformatikhu-berlindeqkdownloadsmcuttargz16Gumstix Verdex Pro httpwwwgumstixcomproductverdex-pro17Beagleboard httpwwwbeagleboardorg

12

218 full cycles per second under optimal conditions and should be sucient for processing at 100Hz There are problems with nding higher baudrates that are supported on both sides of theconnection due to the 20 MHz clocking of the microcontroller

(a) Verdex View 1 (b) Verdex View 2

Figure 6 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below andthe expansion board on above On top is a USB WiFi dongle

A custom ATMega based ADC expansion board is acting as a generic analog data aqcisitiondevice Analog measurements are multiplexed and transmitted down a Two Wire Interface (TWI)link to the main control COM In a dierent setup an Arduino Mini was substituted for the customboard

Sensors For altitude measurement three dierent sensors were added to the setup A barometricpressure sensor is already provided for in the vendor board design This sensor is quite noisy butcovers a large range of measurement When close to the ground range sensors can be used tomeasure the distance Of this type we used a Devantech SRF02 sonic range nder This sensorhas an integrated microcontroller that does time-of-ight calculations for an ultrasonic pulse andtransmits the result digitally over a two wire interface (TWI) The speed of sound vs the actualdistance determine the maximum update frequency In our experiments these were xed at a rateof approximately 50 Hz In addition we attached two Sharp type infrared rangers (GP2Y0A02YKGP2D120) to the robot These output an analog voltage inversely proportional to the distancemeasured They are connected to the expansion board which also transmits updates via TWI butat a rate of 100 Hz The physical conguration of the range sensors is depicted in Figure 8

13

Figure 7 The electronic stack on this copter consists of (in ascending order) FC Power and UARTbreakout Beagle breakout and Arduino Mini mount BeagleBoard and USB WiFi Dongle

333 Physical system

As has been described above the FC can be given actuation commands via both the RC and UARTinterfaces in the form of the four-element vector 1 The SBC used in this particular conguration isthe Gumstix Verdex Pro X6LP The gumstix receives its power supply of 5V DC from the FC andtalks to it over the FFUART without additional level converters The hardware component setupis depicted schematically in Figure 9 On the left hand side of the diagram the base MikroKoptersetup is seen with the FlightCtrl RC receiver and the four ESCs On the right hand side theVerdex and custom sensor board are situated realising highlevel control and UDPIP link to thegroundstation over WiFi For the operation of a second onboard SBC the Beagleboard in Figure 9an additional voltage controller had to be used between the 12V DC rail and the Beagleboard powersupply socket

OpenEmbedded The current gumstix system software is provided via the Aringngstroumlm 18 distri-bution which is based on OpenEmbedded 19 The gumstix overlay provides Linux kernel versions2621 and 2631 Unfortunately the driver for the gumstix onboard WLAN hardware (netvx boardw a Marvell cf25 chip) changed between those versions and the one in 2631 refuses to actually

18Angstrom Distribution httpwwwangstrom-distributionorg19OpenEmbedded httpwwwopenembeddedorg

14

Figure 8 Range sensors attached to frame

RC receiver Onboard electronics

BL1 Expansion Board

BL4 FlightCtrl BL3

BL2 Gumstix

Camera BeagleBoard

TWI

UART

TWI

Wi

LAN

USB

Figure 9 Basic HUCH onboard electronics The left hand region of the picture consisting of receiverFC and brushless motor controllers BL1minus4 represents the standard MK setup while the right handregion represents HUCH additions

work with our hardware so a dierent solution had to be found Fortunately here the USB sub-system works well out of the box and standard USB WLAN hardware could be used to set up thelink Running the system o an SD-card as well as TWI (I2C) support in Linux work well Onemore aspect of the WLAN setup is worth noting though It was desired to realise the wireless linkto the onboard Linux in Ad-Hoc mode for two reasons The rst is reduced startup time when usingAd-Hoc mode the second is independence of access point infrastructure In this way the minimalFR groundstation conguration can be operated in a more mobile manner In principle one of thenodes could be operated in Master mode but this is not supported by all hardware

Once the live Linux system and cross-compilation environment was up and running the MKcom

15

software provided the basis for further work on controller implementation Looking at the Linuxsystem at this point the following view presents itself in Figure 10

Gumstix

AringngstroumlmLinux 2631 SD

UIShell mktool wlan0

devttyS1 devi2c-0

FC Exp Groundstation

RxTx wires

Wireless link

Figure 10 Basic Linux setup

4 Experiments

41 Basic structural design through simulation

Initially the problem of altitude control was analysed in simulation To that end a simple con-troller was realised within the crrcsim 20 RC model simulator There are basically two possiblemethodological approaches to setting up a simulation for a model helicopter One is the derivationof the model from rst principles and implementation from scratch The other is building uponexisting if simplifying solutions that are practically usable and open for modication

A moderately physically realistic model of a quadrotor aerial system is governed by a nontrivialnonlinear dierential equation [3 pg 155] [4] Much microscopic detail can be added for furtherrenement as the need arises Such details are discussed to some extent in [14] and [8] In the near-hover ight regime the system behaves quasi-linearly but at more extreme velocities and attitudesthe increasing impact of several nonlinear eects such as blade apping vortex ring states orforward translational lift would have to be considered For our purposes these eects have so farbeen neglected but could in princpiple be incorporated into the model

Circumventing the necessity of model derivation and implementation the second approach waschosen In particular the existing real-time ready crrcsim [7] RC-model simulator software wasmodied to conduct the initial experiments This was particularly facilitated by the prior work ofJens W Wulf who implemented a quadrotor model and internal controller substructures for thissimulation framework [32] A screenshot of the Wulf-model ying in the modied simulation in canbe seen in Figure 11 crrcsim comes with an internal controller architecture that realises dierent

20Charles River Radio Controllers Simulation httpcrrcsimberliosde

16

attitude controllers The software originally is designed to interface manual control hardware suchas RC transmitters joysticks and such to the simulation engine It was modied to implementadditional controllers detailed state information output for plotting and analysis and networkedcontrol of the simulation engine A drawback of crrcsim is its monolithic architecture For futurework the core simulation engine would have to be separated from the render engine Alternativelythe PPZ approach could be used as a drop-in replacement

Figure 11 Simulation screenshot The helicopter model landscape and text console are part ofcrrcsim The actual debugging output that can be seen in the console is part of custom modications

411 Closed loop

The basic structure of the full control loop is displayed in Figure 12 The control module embeddedin the loop is a Single-Input Single-Output (SISO) type controller The actuating variable undercontrol is thrust which eects overall lift (see above) while the other three components are mostlycontrolled manually during the experiments The input to the controller is the current altitudeestimate The estimation process potentially has to consider multiple measurements which have tobe fused into a single representation

412 Measurements

In simulation global knowledge of the world- (and agent-) state is available and all system variablesare immediatly accessible This allows to use a simplied signal-ow structure which is depicted in

17

Measurements

z0

z1 Kalman lter Controller

Fusion Estimate PID System

znminus1

zn

throttle

Behaviour

setpoint

Figure 12 Controller structure with measurement branch

gure 13 In order for the controller to be structurally transferable to the real hardware system thespecic sensor conguration has to be modelled within the simulator This included preparationof IMU data by tapping the Flight Dynamics Model (FDM) module and basic modelling of therespective characteristics of the barometric and ultrasonic range sensors which were in use on thehelicopter at that time In the case of the barometer this meant the addition of white gaussiannoise A slow drift which can be observed on the real sensor due to slow air-pressure changes wasneglected For the ultrasonic range sensor the timing characteristic that is the maximum updaterate dependent on distance measured was emulated The information thus synthesized was fed intoa Kalman lter for further processing

Controller

PID Systemthrottle

Flight dynamics model

setpoint

Figure 13 Simplied controller structure

413 Sensor fusion

Sensor fusion is a problem class on its own The base intent is to derive an estimate of a systemstate variable from multiple measurements that is more reliable than it would be by using only asingle measurement There are several approaches which have been developed over the last decadesand which could be employed for this task The complementary lter approach can be chosen if the

18

sensors are aected by suciently dierent kinds of noise and thus eg spectrally complementarylters can be used on dierent measurement channels which are then linearily combined into a singlevalue Probably the most commonly used techniques are the linear Kalman lter and its nonlinearvariants Other methods are nonexhaustively Bayesian strategies such as Particle lters H-infinlters or neural networks A linear Kalman lter was chosen in the current setup for the reasonthat the lter and its characteristics are well documented and the implementation is straightforwardboth from scratch and even more so using matrix algebra libraries such as OpenCV The basic ltertask is to estimate the state xk isin Rn of a discrete time system governed by the linear stochasticequation [29] [15]

xk = Axkminus1 +Bukminus1 + wkminus1 (2)

based on a measurement zk isin Rm given as

zk = Hxk + vk (3)

where wk vk are random variables which represent process noise and measurement noise and arenormally distributed with zero mean p(wk) sim N(0 Q) p(vk) sim N(0 R) Q and R are the processand measurement noise covariance matrices The model used here consists of two state variablesx = (a dadt) with a the altitude (above ground) Later the model was extended to include d2adtso as to facilitate incorporation of accelerometer measurements One problem with the real sensorswas a clear deviation of the measurement noise from the assumed normal distribution and had tobe corrected for in preprocessing

414 PID controller

The Kalman lter state estimate can nally be used as the input to a PID throttle controller ThePID model used is a FOPDT integrating model The second input to the controller module is thesetpoint which can be set in the simulation via keyboard- or network-input to the application Therst working PID parametrisation was arrived at through manual tuning which is cumbersome andgives suboptimal results

415 Evolutionary parameter tuning

To prove the concept of using online learning within simulation at least the PID parameters wereoptimised using evolutionary strategies [22] [26] The tness function for this experiment wasconceivably simple chosen as

f(i) =

Nsum0

|xset minus xik| (4)

with individual i (a tuple (P ID)) setpoint xset the experiments duration in time steps N andthe altitude xik at time step k resulting from execution of controller i This stage involved setting upthe system so that simulation state and model parametrisation (the P I and D coecients) could

19

be controlled programmatically It was realised over a UDPIP connection between crrcsim andthe external simctrl control shell 21 implemented in the Python language 22 The results of theexperiment have been presented in [10]

42 MKcom2

MKcom short for MikroKopter communication tool was designed as a minimal software layer tosit on top of the UART communication link to the main ight board It provides a console baseduser interface for activation and conguration of a set of thin control functions and can act as agateway between the FC and a CMUcam MKcom functions can send commands to the FC andincoming UART packets are dispatched to the appropriate message handler This tool implementedthe modied MK message set

The setup was used as the basis for prototyping several versions of the control loop structureoutlined in Figures 12 and 13 The internal organisation of these implementations can be seenin Figure 14 Three dierent controller cores were realised which incrementally incorporated moremeasurement channels heuristic detail and safety hooks The detailed ow structure of the controllerdesign will be outlined below The update rate and execution timings are dictated by the arrivalof the measurement vector from the FC Auxiliary sensors were integrated asynchronously into themain loop A custom groundstation for state logging and realtime plotting was connected to thenetwork downlink indicated in the diagram

421 MKcom2 Flow structure

On startup a request for debug structure emission is sent manually from the mkcom shell to the FCwith the debug n command where n is the desired sampling interval in milliseconds An examplesession excerpt looks (slightly beautied) as follows (`gt indicates the shells command prompt `is the startsign of the MK protocol strings starting with ` is the raw ascii data going over thewire)gt debug 100

tx bdV ===Ds

gt

rxbuf 93 bD===IgtpU gtomgtS=xTyf=DL|pA= gt===Kl|Lnx=mL=I===i=BM|| oXfT_UrePI=T]=gt==E=|l|

L=IE||y===Y=qM

_DebugOut_ 1804 310 203 854 -843 420 -49 49 4

2 -21-1016 123 828 828 0 11 21

-1-5850 9822 -24267 51 94 1 2 -2

207 706 -1 0 7

rxbuf 93 bD===ggtpi gtm=gtT=oxzd]DL|o===m=A=Kl|ALnx=mL=I===E=m=== KxYSourePI=T]====A===

L=IM||y===Y=nf

_DebugOut_ 1834 315 192 855 -722 414 -49 32 3

4 -21-1008 123 828 828 0 2 15

0 -897811867-24267 51 94 0 1 0

207 708 -1 0 7

gt debug 0

tx bd====DZ

gt

21httpwww2informatikhu-berlinde~obertholQK22Python Language httpwwwpythonorg

20

The debug vector is populated in the FC where element positions correspond with value typesIt includes IMU data manual control input from the RC and the barometer as well as systemstatus values such as battery voltage RSSI value ampc Depending on the setup it can include thereading from the sonar as well If the actual controller is activated with eggt ac3 1

kal_cv_init DP 3 MP 5 CP 0

gt

the controller evaluation function is executed upon each arrival of a debug packet Of coursesome information is retained across calls After computation has nished an extctrl (Externalcontrol) structure is populated and sent back to the FC Aditional measurements such as from anInfraRed Ranger (IRR) are integrated in an asynchronous manner from multiple threads Severalparameters such as the altitude setpoint PID values bias ampc can also be set from the text based userinterface While this works quite well in principle and did achieve good performance modularityand extensibility were not an initial design goal This led to another iteration of the same designwithin the MAVHUB framework which will be described in the next subsection

IO Channels UART TWI UI Network

HAL threads FC-RX Expansion Ctrl Sonar Shell

Processing Controller

mkcom2

Figure 14 Mkcom2 ow-graph

43 Heuristically tuned altitude control software

The vague vision of the overall architecture that is pursued here is that of several concurring moduleswhich are summed in a cooperative time-dependent manner and where each module is responsiblefor various behavioural aspects [1] To ease prototyping and testing of components the structurehas to be kept exible extensible and dynamically recongurable This has to be considered in theoverall onboard software design In order to illustrate this requirement the ow of information andthe interaction with additional behavioural modules will be described in more detail in the followingparagraphs References will be made to several modules operating within the MAVHUB frameworkthe basics of which are described elsewhere [25]

431 Data acquisition

First the controlware has to collect all sensory information from possibly heterogenous sourcesThese include 6 - 9 channels of IMU data (depending on IMU type) a barometric measurementseveral range sensors as well as optical sensors (cameras) and of course any other sensor which is

21

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

1500

2000

Time [s]

Value

throttle

uss_meas

k_s0

Figure 15 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m aboveground The dashed line is the raw sonar range value the solid black line is the estimate uponwhich the PID controller acts The solid green line in the lower part of the plot is the controlleroutput value which is sent to the actuator

available or desired Heterogeneity pertains to hardware channels update rates and data formatsIn MAVHUB there are two main channels if information ow One is the protocol stack whichtransmits volatile incoming messages to all active modules (apps) The other is a shared memoryarea where data can be deposited by any active process In the setup considered here FC data(including IMU barometer and possibly sonar) and intermediate internal data travel on the stackSensors connected via a two-wire bus are operated by sensor drivers and measurements are put intothe shared memory The desired result of this step is to be able to operate on a homogenous vectorof input signals within the main control loop

432 Preprocessing

Subsequent to acquisition each sensory channel is individually preprocessed according to the pe-culiarities of sensor principle and connection mode Preprocessing mostly consists of linearisationunit conversion (inverting the sensor characteristic) and several kinds of heuristic validation

Linearisation For this particular setup linearisation only has to be done for the IRRs Theseare analogue sensors and the output voltage is related to the distance s measured via u(t) = 1

s(t) An example sensor characteristic is displayed in Figure 16 For the dierent subtypes of the Sharpsensors an individually parameterised procedure has to be performed as described by eg Acroname

22

Robotics in [23] if the sensors are processed on a metric basis If the Sharp sensors are driven atthe recommended supply voltage of 5V using the datasheet specications has proven sucientlyaccurate An example script for determining the parameters from given calibration data is suppliedon this reports supplementary website 22

Unit conversion The diverse units of sensor data have to be explicitly converted to units conve-nient for later steps in the calculation in particular sensor fusion with the Kalman lter For thealtitude measurements these are metersminus3 so ADC-units or time-of-ight measurements have to beconverted to millimeters for the analog sensors (barometer accelerometer infrared) and the sonarsensor repsectively This simply amounts to a multiplicative factor

Validation Heuristic sensor data validation has to be done for all types of rangers as well as for thebarometric sensor The spurious readings these sensors produce are of dierent types though Theinfrared rangers display ambigouity beyond the lower limit of the operating ranges see Figure 16For the GP2D120 which can sense the smallest ranges of all sensors this can be mostly neglectedsince the minimal sensing range can hardly be reached due to the mechanical conguration Forall the other sensors output is surpressed when the GP2D120 is active At the upper limit of theIRRs operating range the output is surpressed when a suitable threshold is reached The followingcode example illustrates this where sensor channel number three is the close range IRR

if(in_range(sensors [3] first llim ulim))

valid = 10

else

valid = 00

sensors [3] second = (fir[3]-gtcalc(valid) gt= 099) 1 0

Surpression is realised by setting appropriate values in the measurement transform matrix H(t)of the Kalman lter Alternatively this could be done by generating suitable variances for therespective sensors in the measurement covariance matrix R(t) Driving the IRRs at 33V works butreduces the usable range In addition the IRR sensor measurements are dependent on the groundsurfaces some of which eg an oce carpet can result in erratic results

The ultrasonic sensor is susceptive to dierent kinds of spurious readings caused by late echoesThis happens both when very close to an object or surface or when far away that is beyond theupper limit of measurable distances The validation strategy employed is to set hard empiricallower and upper limits for values as for the IRRs and limiting the maximum dierence betweentwo consecutive values based on assumptions about the maximum velocity An example session isillustrated in Figure 18

Finally the barometer is sensitive to acceleration which has to be accounted for The sensorbehaviour is displayed in Figure 19 The empirical corrections read

BARO (pre [1] correct from accel -z (pre [2])

pre [1] first -= (005 pre [2] first)

The validition process in general produces one new signal per channel to be used later in theprocess for setting Kalman lter matrix values One remaining problem here is the channel cross-dependency

23

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 7: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

(a) MMALV 1 (b) MMALV 2

(c) Paparazzi dual airfoil quadrotor taking o (d) Dual airfoil quad after transition to forwardight

Figure 3 Some less prevalent airframe congurations a) and b) Morphing Micro Air and LandVehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobots LLC and Roger Quinnof Case Western Reserve University and c) and d) a Paparazzi based quadrotor with two airfoils(tail sitter design) The pictures are two frames extracted from a video by Antoine Drouin JobyRobotics with kind permission

cles with both analog and digital implementations of the control schemes [12] the use of lightweightlow-cost-and-quality inertial sensors at the same time enables the construction of Micro AerialVehicles (MAV) and poses challenges for the accuracy of the resulting solutions The general ap-proach is to use a complementary system of high-frequency angular rate sensing (gyroscopes) andlow-frequency compensation via acceleration measurements (acceleromoters) In addition informa-tion from magnetic measurements can be incorporated into the attitude estimation if a 9-Degressof Freedom (DoF) IMU is available

312 The robot body

The airframes cited above are examples of FR bodies A brief consideration of some consequencesof the specic conguration is in order The relevant aspects are geometry surface and propulsionGeometry and surface as well as motion type relate to where and how the sensors can actually bemounted In xed winged platforms there is a prefered direction of motion whereas the quadrotordisplays a four-fold structural symmetry and the vehicle front needs to be arbitrarily set Mounting

7

a forward-pointing camera clearly breaks the symmetry in regards to vision based navigation Apossible solution is downward orientation or the use of panoramic lenses see Figure 23

In order to measure the distance to the ground only the downward pointing body surface needsto be considered for sensor mounts (although see GDC below) Obviously acoustic and optical rangesensors need to be unobstructed by other body parts Deviations in range measurements due to non-zero pitch and roll angles during ight are regarded as disturbances in the controller sketched belowThis is in part justied by the nite beam-width of the sonar sensor which intrinsically measuresthe shortest path to a reecting surface Since the absolute error grows linearly with range and theinfrared sensors used here only have very limited range (lt 1m) the deviation is not compensatedeither The scenario is illustrated in Figure 4 the theoretical error for dierent angles and aboslutedistances is plotted in Figure 5 Some more dynamic types of interactions are considered below

θ

e

Figure 4 Distance measurement depending on the angle θ to the ground surface

0 10 20 30 400

200

400

600

Angle [deg]

Error

[mm]

Alt 05 mAlt 1 mAlt 15 mAlt 2 m

Figure 5 Theoretical error over angle for several dierent distances from ground

8

32 Quadrotor systems overview

The quadrotor was conceived in the 1920ies bei Etienne Oehmichen and purportedly ew onlya couple of meters at the time probably due to the manual control problem The concept washibernating for most of the 20th century to resurface as an electronic toy in 1996 The Roswellyer of Area51 Technologies seems to be the earliest appearance of a working miniature quadrotorRC yer [13] Since then development of similar systems has picked up momentum considerablyBy now (2011) there exist a number of projects that are suitable (if not specically designed) asrobotics research platforms of which this section provides an overview The projects backgroundsvary from robotics and remote sensing to hobbyist RC model-ying and electronic toys

While not exclusively targeted at multicopters one of the oldest eorts to develop a versatileand open UAV system (airborne and ground segments) for model yers is the Paparazzi (PPZ)1 project of the Ecole Nationale de lAviation Civile (ENAC) The project was founded in about2003 2 and consists of an extensive set of both hardware and software components The airbornehardware consists of a variety of base processor boards (Tiny TWOG LisaLM) sensor modulesand communication devices The control software consists of a stack of PID control loops whichare executed on the microcontroller boards The overall approach reects a certain outdoor anityConsequently one of the architectures distinctive features is the use of IR thermophiles for absoluteorientation sensing (warm earth cold sky) in outdoor environments Complementing the airbornepart of the project is a comprehensive set of ground segment software and simulation modules Thiscomprises tools for tasks such as logging plotting map-supported on-screen trajectory trackingas well as eg vehicle tracking for servo-controlled directional antennas Communication amongcomponents is realised via the text- and subscription-based IVY software bus 3 which serves as thepoint of entry for component reuse from foreign systems Paparazzi also supports a high-level XMLbased ight-plan description and airframe conguration language Overall the PPZ system oersa mature codebase and a great amount of exibility through open source licensing and a modulardesign

Founded in 2006 the MikroKopter (MK) 4 project quickly gathered momentum in Germany asan RC model-ying vehicle and aerial photography system It is the system used for all experi-ments described in this work The MK architecture is a modular system that can be bought as a kitfrom the producer and consists of a combined IMU and microprocessor board called FlightCtrl (FC)which runs the attitude control software (also FlightCtrl) In fact there are several versions of theFC featuring dierent processors and sensors In addition the project has brought forth specialElectronic Speed Controllers (ESC) which interface control output on a TWI with brushless motorscalled MK-BL The distinctive feature of these controllers is the particularly high update-rate com-pared other other ESCs Consequently the MK-BL are used across many of the other projects seealso Table 1 Optional sensor modules include a compass and GPS components The main factorsfor choosing this particular system were its ready availability at the time of project initiation in2008 cost and source code access The ground and support software for the MikroKopter on theother hand is not ideally suited to demands in robot prototyping There have been attempts atdeveloping open-source and cross-platform alternatives to the vendors MikroKopter Tool althoughin the experiments described below yet other tools were used

1Paparazzi Wiki httppaparazzienacfrwikiMain_Page2httpwwwnongnuorgpaparazzigallery_v0html3Ivy Bus httpwww2tlscenafrproductsivy4MikroKopter httpwwwmikrokopterde

9

Published in late 2008 (according to the Internet Archive) the PIXHAWK (PXH) 5 project ofthe Computer Vision and Geometry Lab at the ETH Zuumlrich is an example of a system designedfrom the ground up as a robotic research platform in this case specically targeted towards visionexperiments PXH also has its own integrated processorIMU module as well as adapter hardwarefor using miniature yet high-capacity computing hardware sometimes referred to as Computer onModule (COM) The software part of the system features a comprehensive groundstation softwarecalled QGroundControl (QGC) and a low overhead communication protocol calledMAVLink 6 Sev-eral other components are provided or are in development The systems components are publishedunder open licenses and the software parts can easily be reused and adapted

Another interesting addition from around 2010 to the growing family of quadrotor systems is theArduCopter (AC) 7 which is designed on top of a more generic autopilot for both xed-wing androtary-wing platforms the ArduPilotMega (APM) 8 which in turn is based on the popular Arduino9 meta-platform The ArduPilot software already makes use of PXHs groundstation QGC throughthe MAVLink protocol In distinction to the projects mentioned so far ArduCopter uses standardunmodied low-cost ESCs for motor control which reects the general low-cost approach of theentire system This approach is most promising in terms community engagement Other relevantprojects in this category are the Unmanned Aerial Video Platform Next Generation (UAVP-NG)10 and OpenPilot 11 projects Both feature co-designed hardware and software but both have notbeen considered more closely due to their state of development during 2010 12

Among the straightforwardly commercial vendors there are two types those targeting profes-sional use outside the RC model community and those attending to the electronic toy marketThe former are mainly used for standard security and surveillance related activities In europethese are Ascending Technologies (AscTec) and microdrones AscTec models also appear in roboticsresearch but require much higher budgets The prominent representatives from the latter categoryare the DraganFlyer of RCToys whose ancestry goes back to the Roswell yer mentioned earlierand most recently the Parrot ARDrone released in 2010 featuring onboard Linux two camerasstabilisation with optical ow and an SDK for custom extensions

321 Systems summary

All these systems dier with regards to sophistication and extendability and clearly none of themprovides out-of-the-box the type of onboard computing system desired for a robotic experimentalframework targeting high-bandwidth signal processing In heterogenous multi-vehicle systems is-sues of interoperability and code-reusability can be expected to become more salient Often easeof use in terms of development and prototyping is traded o for eciency and compact hardwarewhich makes the implementations quite idiomatic

By taking a modularised approach as regards the hardware and employing in the sense ofreusability and ease of programming more powerful Single Board Computers (SBC) or COMscapable of running an operating system dierent systems providing the basic attitude control

5Pixhawk httpwwwethzchpixhawk6MAVLink httpwwwqgroundcontrolorgmavlinkstart7Arducopter httpcodegooglecomparducopter8ArduPilotMega httpcodegooglecompardupilot-mega9Arduino httpwwwarduinocc10UAVP-NG httpnguavpch11OpenPilot httpopenpilotorg12By 2011-06-09 Thu both projects status has considerably advanced

10

such as those mentioned above can be used and wired up with more capable hardware to conductexperiments with a wide range of sensors and algorithms This necessitates the integration of severaldierent downlink and communication frameworks that are in use across dierent systems

One practical option for this part of the system while keeping reusability ease of developmentand energy requirements in mind are ARM-based Linux packages such as the Gumstix or Beagle-board families or similar devices which are available at reasonable prices In summary these werethe considerations that are accumulated in the current state of the HUCH setup described belowThe diverse FR projects can be categorised along an axis indicating the level of targeted behaviourranging from low-level actuator control up to high-level navigation and high performance signalprocessing functionality Table 1 is a graphical representation showing the projects hardware andsoftware components coverage along that axis

Motor Attitude GPS Ground High-perf

UnspecStd PWM ESCs

AscTecDragoncopter

MK MK-BL Flight-Ctrl MKNAV MK-ToolPXH pxIMU via COM QGC COMPPZ TWOG Tiny Lisa GCS COM w LisaAC ArduPilot AC-GS

HUCH COMs

Table 1 Systems overview Of course it is almost always possible to attach a COM to low-levelattitude control platform such as the MK-FC ArduPilotMega or PPZ autopilots over a serialinterface Both PXH and PPZ are designed for use with Gumstix COMs

33 HUCH Sytem

331 Basics

The HUCH project was started to test bio-inspired navigation strategies on ying robots Theproject was initially equipped with basic MK kits The MK is mainly being used for RC modelying and aerial photography but the user community is also active with various other experimentsregarding extentions and modications The platforms distinctive advantages are its price readyavailability and sucient openness for research uses 13 Several academic projects have made orstill make use of the MikroKopter platform

The core component of the MK setup is the FlightCtrl (FC) comprising of both a Printed CircuitBoard (PCB) featuring an IMU a microcontroller and the rmware implementing the attitudestabilisation RC interface telemetry and more The MK architecture also features ESCs (MK-BL) capable of receiving the actuating variable via a TWI interface at a rate of 500 Hz which marksa dierence to other ESCs available on the RC market For that reason the MK-BL is also widelybeing used in many other projects

13Although with recent versions of the FlightCtrl rmware this has started to change

11

Direction Code Command Arguments

Inb Submit external control extctrl structc GyroBaro neutral Noned Request debug vector Update interval or None for one-om Start motors Nonen Kill motors None

OutD Debug vector 32 int16 values

Table 2 Five most important HUCH commands for external control of the modied MK-FC

332 Modications

Software The HUCH group has developed various extensions and modications to the platformOne of these is an expansion of the external control interface see Table 2 via the UART a corre-sponding groundstation (mcut) and control software (mktool) These are the basis for most of thework described in the remaining part of this text

The FlightCtrl microcontroller rmware was modied (HUCH variant) initially based on killa-gregs rewrite of the original rmware and implements among other things the extended communi-cation protocol higher UART baudrates TWI sensor integration and several more items 14 Thereexists a tool 15 to realise realtime display and plotting of debug variables ashing of MikroKopterrmware with embedded avrdude code parameter editing and motor testing The MKcom pro-gramm was initially developed for using a CMUcam to control the MikroKopter from vision inputIt features the basic FC communication stack and a control console This last item served as thebasis of the rst prototype of a Linux based altitude control At the time of writing develop-ment of these tools has been abandoned in favor of Micro Aerial Vehicle Humboldt Universitaumlt zuBerlin (MAVHUB) which is described in more detail elsewhere [25]

Computing hardware To overcome the severe restrictions of the Atmel ATMega644 being usedon the FC it is necessary to attach additional processing hardware Stating it more simply a singlemicrocontroller clearly is not suitable for any kind of slightly more demanding processing For thispurpose to date dierent single board systems have been used the Gumstix Verdex Pro 16 andBeagleboard variants 17 as can be seen in the gures 6 and 7 Several other options are availableand could be utilised in the future as our approach is construed exible in this regard Working ona Linux system provides a huge advantage in abstracting the algorithms from the hardware TheLinux system is connected to the FlightCtrl via the UART port In order to achieve a sampling rateof 100 Hz a baudrate of 230400 kbaud needs to be set on this connection The DebugOut messagestructure counts 95 bytes on the wire The motor command takes up 22 bytes giving 117 bytes forone sense-act cycle At the given channel capacity (25600 bytes per second) this gives approximately

14HUCH FlightCtrl 071i httpkoroinformatikhu-berlindeqkdownloadsV071i_huch-code_motodrone09targz

15mcut httpkoroinformatikhu-berlindeqkdownloadsmcuttargz16Gumstix Verdex Pro httpwwwgumstixcomproductverdex-pro17Beagleboard httpwwwbeagleboardorg

12

218 full cycles per second under optimal conditions and should be sucient for processing at 100Hz There are problems with nding higher baudrates that are supported on both sides of theconnection due to the 20 MHz clocking of the microcontroller

(a) Verdex View 1 (b) Verdex View 2

Figure 6 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below andthe expansion board on above On top is a USB WiFi dongle

A custom ATMega based ADC expansion board is acting as a generic analog data aqcisitiondevice Analog measurements are multiplexed and transmitted down a Two Wire Interface (TWI)link to the main control COM In a dierent setup an Arduino Mini was substituted for the customboard

Sensors For altitude measurement three dierent sensors were added to the setup A barometricpressure sensor is already provided for in the vendor board design This sensor is quite noisy butcovers a large range of measurement When close to the ground range sensors can be used tomeasure the distance Of this type we used a Devantech SRF02 sonic range nder This sensorhas an integrated microcontroller that does time-of-ight calculations for an ultrasonic pulse andtransmits the result digitally over a two wire interface (TWI) The speed of sound vs the actualdistance determine the maximum update frequency In our experiments these were xed at a rateof approximately 50 Hz In addition we attached two Sharp type infrared rangers (GP2Y0A02YKGP2D120) to the robot These output an analog voltage inversely proportional to the distancemeasured They are connected to the expansion board which also transmits updates via TWI butat a rate of 100 Hz The physical conguration of the range sensors is depicted in Figure 8

13

Figure 7 The electronic stack on this copter consists of (in ascending order) FC Power and UARTbreakout Beagle breakout and Arduino Mini mount BeagleBoard and USB WiFi Dongle

333 Physical system

As has been described above the FC can be given actuation commands via both the RC and UARTinterfaces in the form of the four-element vector 1 The SBC used in this particular conguration isthe Gumstix Verdex Pro X6LP The gumstix receives its power supply of 5V DC from the FC andtalks to it over the FFUART without additional level converters The hardware component setupis depicted schematically in Figure 9 On the left hand side of the diagram the base MikroKoptersetup is seen with the FlightCtrl RC receiver and the four ESCs On the right hand side theVerdex and custom sensor board are situated realising highlevel control and UDPIP link to thegroundstation over WiFi For the operation of a second onboard SBC the Beagleboard in Figure 9an additional voltage controller had to be used between the 12V DC rail and the Beagleboard powersupply socket

OpenEmbedded The current gumstix system software is provided via the Aringngstroumlm 18 distri-bution which is based on OpenEmbedded 19 The gumstix overlay provides Linux kernel versions2621 and 2631 Unfortunately the driver for the gumstix onboard WLAN hardware (netvx boardw a Marvell cf25 chip) changed between those versions and the one in 2631 refuses to actually

18Angstrom Distribution httpwwwangstrom-distributionorg19OpenEmbedded httpwwwopenembeddedorg

14

Figure 8 Range sensors attached to frame

RC receiver Onboard electronics

BL1 Expansion Board

BL4 FlightCtrl BL3

BL2 Gumstix

Camera BeagleBoard

TWI

UART

TWI

Wi

LAN

USB

Figure 9 Basic HUCH onboard electronics The left hand region of the picture consisting of receiverFC and brushless motor controllers BL1minus4 represents the standard MK setup while the right handregion represents HUCH additions

work with our hardware so a dierent solution had to be found Fortunately here the USB sub-system works well out of the box and standard USB WLAN hardware could be used to set up thelink Running the system o an SD-card as well as TWI (I2C) support in Linux work well Onemore aspect of the WLAN setup is worth noting though It was desired to realise the wireless linkto the onboard Linux in Ad-Hoc mode for two reasons The rst is reduced startup time when usingAd-Hoc mode the second is independence of access point infrastructure In this way the minimalFR groundstation conguration can be operated in a more mobile manner In principle one of thenodes could be operated in Master mode but this is not supported by all hardware

Once the live Linux system and cross-compilation environment was up and running the MKcom

15

software provided the basis for further work on controller implementation Looking at the Linuxsystem at this point the following view presents itself in Figure 10

Gumstix

AringngstroumlmLinux 2631 SD

UIShell mktool wlan0

devttyS1 devi2c-0

FC Exp Groundstation

RxTx wires

Wireless link

Figure 10 Basic Linux setup

4 Experiments

41 Basic structural design through simulation

Initially the problem of altitude control was analysed in simulation To that end a simple con-troller was realised within the crrcsim 20 RC model simulator There are basically two possiblemethodological approaches to setting up a simulation for a model helicopter One is the derivationof the model from rst principles and implementation from scratch The other is building uponexisting if simplifying solutions that are practically usable and open for modication

A moderately physically realistic model of a quadrotor aerial system is governed by a nontrivialnonlinear dierential equation [3 pg 155] [4] Much microscopic detail can be added for furtherrenement as the need arises Such details are discussed to some extent in [14] and [8] In the near-hover ight regime the system behaves quasi-linearly but at more extreme velocities and attitudesthe increasing impact of several nonlinear eects such as blade apping vortex ring states orforward translational lift would have to be considered For our purposes these eects have so farbeen neglected but could in princpiple be incorporated into the model

Circumventing the necessity of model derivation and implementation the second approach waschosen In particular the existing real-time ready crrcsim [7] RC-model simulator software wasmodied to conduct the initial experiments This was particularly facilitated by the prior work ofJens W Wulf who implemented a quadrotor model and internal controller substructures for thissimulation framework [32] A screenshot of the Wulf-model ying in the modied simulation in canbe seen in Figure 11 crrcsim comes with an internal controller architecture that realises dierent

20Charles River Radio Controllers Simulation httpcrrcsimberliosde

16

attitude controllers The software originally is designed to interface manual control hardware suchas RC transmitters joysticks and such to the simulation engine It was modied to implementadditional controllers detailed state information output for plotting and analysis and networkedcontrol of the simulation engine A drawback of crrcsim is its monolithic architecture For futurework the core simulation engine would have to be separated from the render engine Alternativelythe PPZ approach could be used as a drop-in replacement

Figure 11 Simulation screenshot The helicopter model landscape and text console are part ofcrrcsim The actual debugging output that can be seen in the console is part of custom modications

411 Closed loop

The basic structure of the full control loop is displayed in Figure 12 The control module embeddedin the loop is a Single-Input Single-Output (SISO) type controller The actuating variable undercontrol is thrust which eects overall lift (see above) while the other three components are mostlycontrolled manually during the experiments The input to the controller is the current altitudeestimate The estimation process potentially has to consider multiple measurements which have tobe fused into a single representation

412 Measurements

In simulation global knowledge of the world- (and agent-) state is available and all system variablesare immediatly accessible This allows to use a simplied signal-ow structure which is depicted in

17

Measurements

z0

z1 Kalman lter Controller

Fusion Estimate PID System

znminus1

zn

throttle

Behaviour

setpoint

Figure 12 Controller structure with measurement branch

gure 13 In order for the controller to be structurally transferable to the real hardware system thespecic sensor conguration has to be modelled within the simulator This included preparationof IMU data by tapping the Flight Dynamics Model (FDM) module and basic modelling of therespective characteristics of the barometric and ultrasonic range sensors which were in use on thehelicopter at that time In the case of the barometer this meant the addition of white gaussiannoise A slow drift which can be observed on the real sensor due to slow air-pressure changes wasneglected For the ultrasonic range sensor the timing characteristic that is the maximum updaterate dependent on distance measured was emulated The information thus synthesized was fed intoa Kalman lter for further processing

Controller

PID Systemthrottle

Flight dynamics model

setpoint

Figure 13 Simplied controller structure

413 Sensor fusion

Sensor fusion is a problem class on its own The base intent is to derive an estimate of a systemstate variable from multiple measurements that is more reliable than it would be by using only asingle measurement There are several approaches which have been developed over the last decadesand which could be employed for this task The complementary lter approach can be chosen if the

18

sensors are aected by suciently dierent kinds of noise and thus eg spectrally complementarylters can be used on dierent measurement channels which are then linearily combined into a singlevalue Probably the most commonly used techniques are the linear Kalman lter and its nonlinearvariants Other methods are nonexhaustively Bayesian strategies such as Particle lters H-infinlters or neural networks A linear Kalman lter was chosen in the current setup for the reasonthat the lter and its characteristics are well documented and the implementation is straightforwardboth from scratch and even more so using matrix algebra libraries such as OpenCV The basic ltertask is to estimate the state xk isin Rn of a discrete time system governed by the linear stochasticequation [29] [15]

xk = Axkminus1 +Bukminus1 + wkminus1 (2)

based on a measurement zk isin Rm given as

zk = Hxk + vk (3)

where wk vk are random variables which represent process noise and measurement noise and arenormally distributed with zero mean p(wk) sim N(0 Q) p(vk) sim N(0 R) Q and R are the processand measurement noise covariance matrices The model used here consists of two state variablesx = (a dadt) with a the altitude (above ground) Later the model was extended to include d2adtso as to facilitate incorporation of accelerometer measurements One problem with the real sensorswas a clear deviation of the measurement noise from the assumed normal distribution and had tobe corrected for in preprocessing

414 PID controller

The Kalman lter state estimate can nally be used as the input to a PID throttle controller ThePID model used is a FOPDT integrating model The second input to the controller module is thesetpoint which can be set in the simulation via keyboard- or network-input to the application Therst working PID parametrisation was arrived at through manual tuning which is cumbersome andgives suboptimal results

415 Evolutionary parameter tuning

To prove the concept of using online learning within simulation at least the PID parameters wereoptimised using evolutionary strategies [22] [26] The tness function for this experiment wasconceivably simple chosen as

f(i) =

Nsum0

|xset minus xik| (4)

with individual i (a tuple (P ID)) setpoint xset the experiments duration in time steps N andthe altitude xik at time step k resulting from execution of controller i This stage involved setting upthe system so that simulation state and model parametrisation (the P I and D coecients) could

19

be controlled programmatically It was realised over a UDPIP connection between crrcsim andthe external simctrl control shell 21 implemented in the Python language 22 The results of theexperiment have been presented in [10]

42 MKcom2

MKcom short for MikroKopter communication tool was designed as a minimal software layer tosit on top of the UART communication link to the main ight board It provides a console baseduser interface for activation and conguration of a set of thin control functions and can act as agateway between the FC and a CMUcam MKcom functions can send commands to the FC andincoming UART packets are dispatched to the appropriate message handler This tool implementedthe modied MK message set

The setup was used as the basis for prototyping several versions of the control loop structureoutlined in Figures 12 and 13 The internal organisation of these implementations can be seenin Figure 14 Three dierent controller cores were realised which incrementally incorporated moremeasurement channels heuristic detail and safety hooks The detailed ow structure of the controllerdesign will be outlined below The update rate and execution timings are dictated by the arrivalof the measurement vector from the FC Auxiliary sensors were integrated asynchronously into themain loop A custom groundstation for state logging and realtime plotting was connected to thenetwork downlink indicated in the diagram

421 MKcom2 Flow structure

On startup a request for debug structure emission is sent manually from the mkcom shell to the FCwith the debug n command where n is the desired sampling interval in milliseconds An examplesession excerpt looks (slightly beautied) as follows (`gt indicates the shells command prompt `is the startsign of the MK protocol strings starting with ` is the raw ascii data going over thewire)gt debug 100

tx bdV ===Ds

gt

rxbuf 93 bD===IgtpU gtomgtS=xTyf=DL|pA= gt===Kl|Lnx=mL=I===i=BM|| oXfT_UrePI=T]=gt==E=|l|

L=IE||y===Y=qM

_DebugOut_ 1804 310 203 854 -843 420 -49 49 4

2 -21-1016 123 828 828 0 11 21

-1-5850 9822 -24267 51 94 1 2 -2

207 706 -1 0 7

rxbuf 93 bD===ggtpi gtm=gtT=oxzd]DL|o===m=A=Kl|ALnx=mL=I===E=m=== KxYSourePI=T]====A===

L=IM||y===Y=nf

_DebugOut_ 1834 315 192 855 -722 414 -49 32 3

4 -21-1008 123 828 828 0 2 15

0 -897811867-24267 51 94 0 1 0

207 708 -1 0 7

gt debug 0

tx bd====DZ

gt

21httpwww2informatikhu-berlinde~obertholQK22Python Language httpwwwpythonorg

20

The debug vector is populated in the FC where element positions correspond with value typesIt includes IMU data manual control input from the RC and the barometer as well as systemstatus values such as battery voltage RSSI value ampc Depending on the setup it can include thereading from the sonar as well If the actual controller is activated with eggt ac3 1

kal_cv_init DP 3 MP 5 CP 0

gt

the controller evaluation function is executed upon each arrival of a debug packet Of coursesome information is retained across calls After computation has nished an extctrl (Externalcontrol) structure is populated and sent back to the FC Aditional measurements such as from anInfraRed Ranger (IRR) are integrated in an asynchronous manner from multiple threads Severalparameters such as the altitude setpoint PID values bias ampc can also be set from the text based userinterface While this works quite well in principle and did achieve good performance modularityand extensibility were not an initial design goal This led to another iteration of the same designwithin the MAVHUB framework which will be described in the next subsection

IO Channels UART TWI UI Network

HAL threads FC-RX Expansion Ctrl Sonar Shell

Processing Controller

mkcom2

Figure 14 Mkcom2 ow-graph

43 Heuristically tuned altitude control software

The vague vision of the overall architecture that is pursued here is that of several concurring moduleswhich are summed in a cooperative time-dependent manner and where each module is responsiblefor various behavioural aspects [1] To ease prototyping and testing of components the structurehas to be kept exible extensible and dynamically recongurable This has to be considered in theoverall onboard software design In order to illustrate this requirement the ow of information andthe interaction with additional behavioural modules will be described in more detail in the followingparagraphs References will be made to several modules operating within the MAVHUB frameworkthe basics of which are described elsewhere [25]

431 Data acquisition

First the controlware has to collect all sensory information from possibly heterogenous sourcesThese include 6 - 9 channels of IMU data (depending on IMU type) a barometric measurementseveral range sensors as well as optical sensors (cameras) and of course any other sensor which is

21

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

1500

2000

Time [s]

Value

throttle

uss_meas

k_s0

Figure 15 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m aboveground The dashed line is the raw sonar range value the solid black line is the estimate uponwhich the PID controller acts The solid green line in the lower part of the plot is the controlleroutput value which is sent to the actuator

available or desired Heterogeneity pertains to hardware channels update rates and data formatsIn MAVHUB there are two main channels if information ow One is the protocol stack whichtransmits volatile incoming messages to all active modules (apps) The other is a shared memoryarea where data can be deposited by any active process In the setup considered here FC data(including IMU barometer and possibly sonar) and intermediate internal data travel on the stackSensors connected via a two-wire bus are operated by sensor drivers and measurements are put intothe shared memory The desired result of this step is to be able to operate on a homogenous vectorof input signals within the main control loop

432 Preprocessing

Subsequent to acquisition each sensory channel is individually preprocessed according to the pe-culiarities of sensor principle and connection mode Preprocessing mostly consists of linearisationunit conversion (inverting the sensor characteristic) and several kinds of heuristic validation

Linearisation For this particular setup linearisation only has to be done for the IRRs Theseare analogue sensors and the output voltage is related to the distance s measured via u(t) = 1

s(t) An example sensor characteristic is displayed in Figure 16 For the dierent subtypes of the Sharpsensors an individually parameterised procedure has to be performed as described by eg Acroname

22

Robotics in [23] if the sensors are processed on a metric basis If the Sharp sensors are driven atthe recommended supply voltage of 5V using the datasheet specications has proven sucientlyaccurate An example script for determining the parameters from given calibration data is suppliedon this reports supplementary website 22

Unit conversion The diverse units of sensor data have to be explicitly converted to units conve-nient for later steps in the calculation in particular sensor fusion with the Kalman lter For thealtitude measurements these are metersminus3 so ADC-units or time-of-ight measurements have to beconverted to millimeters for the analog sensors (barometer accelerometer infrared) and the sonarsensor repsectively This simply amounts to a multiplicative factor

Validation Heuristic sensor data validation has to be done for all types of rangers as well as for thebarometric sensor The spurious readings these sensors produce are of dierent types though Theinfrared rangers display ambigouity beyond the lower limit of the operating ranges see Figure 16For the GP2D120 which can sense the smallest ranges of all sensors this can be mostly neglectedsince the minimal sensing range can hardly be reached due to the mechanical conguration Forall the other sensors output is surpressed when the GP2D120 is active At the upper limit of theIRRs operating range the output is surpressed when a suitable threshold is reached The followingcode example illustrates this where sensor channel number three is the close range IRR

if(in_range(sensors [3] first llim ulim))

valid = 10

else

valid = 00

sensors [3] second = (fir[3]-gtcalc(valid) gt= 099) 1 0

Surpression is realised by setting appropriate values in the measurement transform matrix H(t)of the Kalman lter Alternatively this could be done by generating suitable variances for therespective sensors in the measurement covariance matrix R(t) Driving the IRRs at 33V works butreduces the usable range In addition the IRR sensor measurements are dependent on the groundsurfaces some of which eg an oce carpet can result in erratic results

The ultrasonic sensor is susceptive to dierent kinds of spurious readings caused by late echoesThis happens both when very close to an object or surface or when far away that is beyond theupper limit of measurable distances The validation strategy employed is to set hard empiricallower and upper limits for values as for the IRRs and limiting the maximum dierence betweentwo consecutive values based on assumptions about the maximum velocity An example session isillustrated in Figure 18

Finally the barometer is sensitive to acceleration which has to be accounted for The sensorbehaviour is displayed in Figure 19 The empirical corrections read

BARO (pre [1] correct from accel -z (pre [2])

pre [1] first -= (005 pre [2] first)

The validition process in general produces one new signal per channel to be used later in theprocess for setting Kalman lter matrix values One remaining problem here is the channel cross-dependency

23

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 8: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

a forward-pointing camera clearly breaks the symmetry in regards to vision based navigation Apossible solution is downward orientation or the use of panoramic lenses see Figure 23

In order to measure the distance to the ground only the downward pointing body surface needsto be considered for sensor mounts (although see GDC below) Obviously acoustic and optical rangesensors need to be unobstructed by other body parts Deviations in range measurements due to non-zero pitch and roll angles during ight are regarded as disturbances in the controller sketched belowThis is in part justied by the nite beam-width of the sonar sensor which intrinsically measuresthe shortest path to a reecting surface Since the absolute error grows linearly with range and theinfrared sensors used here only have very limited range (lt 1m) the deviation is not compensatedeither The scenario is illustrated in Figure 4 the theoretical error for dierent angles and aboslutedistances is plotted in Figure 5 Some more dynamic types of interactions are considered below

θ

e

Figure 4 Distance measurement depending on the angle θ to the ground surface

0 10 20 30 400

200

400

600

Angle [deg]

Error

[mm]

Alt 05 mAlt 1 mAlt 15 mAlt 2 m

Figure 5 Theoretical error over angle for several dierent distances from ground

8

32 Quadrotor systems overview

The quadrotor was conceived in the 1920ies bei Etienne Oehmichen and purportedly ew onlya couple of meters at the time probably due to the manual control problem The concept washibernating for most of the 20th century to resurface as an electronic toy in 1996 The Roswellyer of Area51 Technologies seems to be the earliest appearance of a working miniature quadrotorRC yer [13] Since then development of similar systems has picked up momentum considerablyBy now (2011) there exist a number of projects that are suitable (if not specically designed) asrobotics research platforms of which this section provides an overview The projects backgroundsvary from robotics and remote sensing to hobbyist RC model-ying and electronic toys

While not exclusively targeted at multicopters one of the oldest eorts to develop a versatileand open UAV system (airborne and ground segments) for model yers is the Paparazzi (PPZ)1 project of the Ecole Nationale de lAviation Civile (ENAC) The project was founded in about2003 2 and consists of an extensive set of both hardware and software components The airbornehardware consists of a variety of base processor boards (Tiny TWOG LisaLM) sensor modulesand communication devices The control software consists of a stack of PID control loops whichare executed on the microcontroller boards The overall approach reects a certain outdoor anityConsequently one of the architectures distinctive features is the use of IR thermophiles for absoluteorientation sensing (warm earth cold sky) in outdoor environments Complementing the airbornepart of the project is a comprehensive set of ground segment software and simulation modules Thiscomprises tools for tasks such as logging plotting map-supported on-screen trajectory trackingas well as eg vehicle tracking for servo-controlled directional antennas Communication amongcomponents is realised via the text- and subscription-based IVY software bus 3 which serves as thepoint of entry for component reuse from foreign systems Paparazzi also supports a high-level XMLbased ight-plan description and airframe conguration language Overall the PPZ system oersa mature codebase and a great amount of exibility through open source licensing and a modulardesign

Founded in 2006 the MikroKopter (MK) 4 project quickly gathered momentum in Germany asan RC model-ying vehicle and aerial photography system It is the system used for all experi-ments described in this work The MK architecture is a modular system that can be bought as a kitfrom the producer and consists of a combined IMU and microprocessor board called FlightCtrl (FC)which runs the attitude control software (also FlightCtrl) In fact there are several versions of theFC featuring dierent processors and sensors In addition the project has brought forth specialElectronic Speed Controllers (ESC) which interface control output on a TWI with brushless motorscalled MK-BL The distinctive feature of these controllers is the particularly high update-rate com-pared other other ESCs Consequently the MK-BL are used across many of the other projects seealso Table 1 Optional sensor modules include a compass and GPS components The main factorsfor choosing this particular system were its ready availability at the time of project initiation in2008 cost and source code access The ground and support software for the MikroKopter on theother hand is not ideally suited to demands in robot prototyping There have been attempts atdeveloping open-source and cross-platform alternatives to the vendors MikroKopter Tool althoughin the experiments described below yet other tools were used

1Paparazzi Wiki httppaparazzienacfrwikiMain_Page2httpwwwnongnuorgpaparazzigallery_v0html3Ivy Bus httpwww2tlscenafrproductsivy4MikroKopter httpwwwmikrokopterde

9

Published in late 2008 (according to the Internet Archive) the PIXHAWK (PXH) 5 project ofthe Computer Vision and Geometry Lab at the ETH Zuumlrich is an example of a system designedfrom the ground up as a robotic research platform in this case specically targeted towards visionexperiments PXH also has its own integrated processorIMU module as well as adapter hardwarefor using miniature yet high-capacity computing hardware sometimes referred to as Computer onModule (COM) The software part of the system features a comprehensive groundstation softwarecalled QGroundControl (QGC) and a low overhead communication protocol calledMAVLink 6 Sev-eral other components are provided or are in development The systems components are publishedunder open licenses and the software parts can easily be reused and adapted

Another interesting addition from around 2010 to the growing family of quadrotor systems is theArduCopter (AC) 7 which is designed on top of a more generic autopilot for both xed-wing androtary-wing platforms the ArduPilotMega (APM) 8 which in turn is based on the popular Arduino9 meta-platform The ArduPilot software already makes use of PXHs groundstation QGC throughthe MAVLink protocol In distinction to the projects mentioned so far ArduCopter uses standardunmodied low-cost ESCs for motor control which reects the general low-cost approach of theentire system This approach is most promising in terms community engagement Other relevantprojects in this category are the Unmanned Aerial Video Platform Next Generation (UAVP-NG)10 and OpenPilot 11 projects Both feature co-designed hardware and software but both have notbeen considered more closely due to their state of development during 2010 12

Among the straightforwardly commercial vendors there are two types those targeting profes-sional use outside the RC model community and those attending to the electronic toy marketThe former are mainly used for standard security and surveillance related activities In europethese are Ascending Technologies (AscTec) and microdrones AscTec models also appear in roboticsresearch but require much higher budgets The prominent representatives from the latter categoryare the DraganFlyer of RCToys whose ancestry goes back to the Roswell yer mentioned earlierand most recently the Parrot ARDrone released in 2010 featuring onboard Linux two camerasstabilisation with optical ow and an SDK for custom extensions

321 Systems summary

All these systems dier with regards to sophistication and extendability and clearly none of themprovides out-of-the-box the type of onboard computing system desired for a robotic experimentalframework targeting high-bandwidth signal processing In heterogenous multi-vehicle systems is-sues of interoperability and code-reusability can be expected to become more salient Often easeof use in terms of development and prototyping is traded o for eciency and compact hardwarewhich makes the implementations quite idiomatic

By taking a modularised approach as regards the hardware and employing in the sense ofreusability and ease of programming more powerful Single Board Computers (SBC) or COMscapable of running an operating system dierent systems providing the basic attitude control

5Pixhawk httpwwwethzchpixhawk6MAVLink httpwwwqgroundcontrolorgmavlinkstart7Arducopter httpcodegooglecomparducopter8ArduPilotMega httpcodegooglecompardupilot-mega9Arduino httpwwwarduinocc10UAVP-NG httpnguavpch11OpenPilot httpopenpilotorg12By 2011-06-09 Thu both projects status has considerably advanced

10

such as those mentioned above can be used and wired up with more capable hardware to conductexperiments with a wide range of sensors and algorithms This necessitates the integration of severaldierent downlink and communication frameworks that are in use across dierent systems

One practical option for this part of the system while keeping reusability ease of developmentand energy requirements in mind are ARM-based Linux packages such as the Gumstix or Beagle-board families or similar devices which are available at reasonable prices In summary these werethe considerations that are accumulated in the current state of the HUCH setup described belowThe diverse FR projects can be categorised along an axis indicating the level of targeted behaviourranging from low-level actuator control up to high-level navigation and high performance signalprocessing functionality Table 1 is a graphical representation showing the projects hardware andsoftware components coverage along that axis

Motor Attitude GPS Ground High-perf

UnspecStd PWM ESCs

AscTecDragoncopter

MK MK-BL Flight-Ctrl MKNAV MK-ToolPXH pxIMU via COM QGC COMPPZ TWOG Tiny Lisa GCS COM w LisaAC ArduPilot AC-GS

HUCH COMs

Table 1 Systems overview Of course it is almost always possible to attach a COM to low-levelattitude control platform such as the MK-FC ArduPilotMega or PPZ autopilots over a serialinterface Both PXH and PPZ are designed for use with Gumstix COMs

33 HUCH Sytem

331 Basics

The HUCH project was started to test bio-inspired navigation strategies on ying robots Theproject was initially equipped with basic MK kits The MK is mainly being used for RC modelying and aerial photography but the user community is also active with various other experimentsregarding extentions and modications The platforms distinctive advantages are its price readyavailability and sucient openness for research uses 13 Several academic projects have made orstill make use of the MikroKopter platform

The core component of the MK setup is the FlightCtrl (FC) comprising of both a Printed CircuitBoard (PCB) featuring an IMU a microcontroller and the rmware implementing the attitudestabilisation RC interface telemetry and more The MK architecture also features ESCs (MK-BL) capable of receiving the actuating variable via a TWI interface at a rate of 500 Hz which marksa dierence to other ESCs available on the RC market For that reason the MK-BL is also widelybeing used in many other projects

13Although with recent versions of the FlightCtrl rmware this has started to change

11

Direction Code Command Arguments

Inb Submit external control extctrl structc GyroBaro neutral Noned Request debug vector Update interval or None for one-om Start motors Nonen Kill motors None

OutD Debug vector 32 int16 values

Table 2 Five most important HUCH commands for external control of the modied MK-FC

332 Modications

Software The HUCH group has developed various extensions and modications to the platformOne of these is an expansion of the external control interface see Table 2 via the UART a corre-sponding groundstation (mcut) and control software (mktool) These are the basis for most of thework described in the remaining part of this text

The FlightCtrl microcontroller rmware was modied (HUCH variant) initially based on killa-gregs rewrite of the original rmware and implements among other things the extended communi-cation protocol higher UART baudrates TWI sensor integration and several more items 14 Thereexists a tool 15 to realise realtime display and plotting of debug variables ashing of MikroKopterrmware with embedded avrdude code parameter editing and motor testing The MKcom pro-gramm was initially developed for using a CMUcam to control the MikroKopter from vision inputIt features the basic FC communication stack and a control console This last item served as thebasis of the rst prototype of a Linux based altitude control At the time of writing develop-ment of these tools has been abandoned in favor of Micro Aerial Vehicle Humboldt Universitaumlt zuBerlin (MAVHUB) which is described in more detail elsewhere [25]

Computing hardware To overcome the severe restrictions of the Atmel ATMega644 being usedon the FC it is necessary to attach additional processing hardware Stating it more simply a singlemicrocontroller clearly is not suitable for any kind of slightly more demanding processing For thispurpose to date dierent single board systems have been used the Gumstix Verdex Pro 16 andBeagleboard variants 17 as can be seen in the gures 6 and 7 Several other options are availableand could be utilised in the future as our approach is construed exible in this regard Working ona Linux system provides a huge advantage in abstracting the algorithms from the hardware TheLinux system is connected to the FlightCtrl via the UART port In order to achieve a sampling rateof 100 Hz a baudrate of 230400 kbaud needs to be set on this connection The DebugOut messagestructure counts 95 bytes on the wire The motor command takes up 22 bytes giving 117 bytes forone sense-act cycle At the given channel capacity (25600 bytes per second) this gives approximately

14HUCH FlightCtrl 071i httpkoroinformatikhu-berlindeqkdownloadsV071i_huch-code_motodrone09targz

15mcut httpkoroinformatikhu-berlindeqkdownloadsmcuttargz16Gumstix Verdex Pro httpwwwgumstixcomproductverdex-pro17Beagleboard httpwwwbeagleboardorg

12

218 full cycles per second under optimal conditions and should be sucient for processing at 100Hz There are problems with nding higher baudrates that are supported on both sides of theconnection due to the 20 MHz clocking of the microcontroller

(a) Verdex View 1 (b) Verdex View 2

Figure 6 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below andthe expansion board on above On top is a USB WiFi dongle

A custom ATMega based ADC expansion board is acting as a generic analog data aqcisitiondevice Analog measurements are multiplexed and transmitted down a Two Wire Interface (TWI)link to the main control COM In a dierent setup an Arduino Mini was substituted for the customboard

Sensors For altitude measurement three dierent sensors were added to the setup A barometricpressure sensor is already provided for in the vendor board design This sensor is quite noisy butcovers a large range of measurement When close to the ground range sensors can be used tomeasure the distance Of this type we used a Devantech SRF02 sonic range nder This sensorhas an integrated microcontroller that does time-of-ight calculations for an ultrasonic pulse andtransmits the result digitally over a two wire interface (TWI) The speed of sound vs the actualdistance determine the maximum update frequency In our experiments these were xed at a rateof approximately 50 Hz In addition we attached two Sharp type infrared rangers (GP2Y0A02YKGP2D120) to the robot These output an analog voltage inversely proportional to the distancemeasured They are connected to the expansion board which also transmits updates via TWI butat a rate of 100 Hz The physical conguration of the range sensors is depicted in Figure 8

13

Figure 7 The electronic stack on this copter consists of (in ascending order) FC Power and UARTbreakout Beagle breakout and Arduino Mini mount BeagleBoard and USB WiFi Dongle

333 Physical system

As has been described above the FC can be given actuation commands via both the RC and UARTinterfaces in the form of the four-element vector 1 The SBC used in this particular conguration isthe Gumstix Verdex Pro X6LP The gumstix receives its power supply of 5V DC from the FC andtalks to it over the FFUART without additional level converters The hardware component setupis depicted schematically in Figure 9 On the left hand side of the diagram the base MikroKoptersetup is seen with the FlightCtrl RC receiver and the four ESCs On the right hand side theVerdex and custom sensor board are situated realising highlevel control and UDPIP link to thegroundstation over WiFi For the operation of a second onboard SBC the Beagleboard in Figure 9an additional voltage controller had to be used between the 12V DC rail and the Beagleboard powersupply socket

OpenEmbedded The current gumstix system software is provided via the Aringngstroumlm 18 distri-bution which is based on OpenEmbedded 19 The gumstix overlay provides Linux kernel versions2621 and 2631 Unfortunately the driver for the gumstix onboard WLAN hardware (netvx boardw a Marvell cf25 chip) changed between those versions and the one in 2631 refuses to actually

18Angstrom Distribution httpwwwangstrom-distributionorg19OpenEmbedded httpwwwopenembeddedorg

14

Figure 8 Range sensors attached to frame

RC receiver Onboard electronics

BL1 Expansion Board

BL4 FlightCtrl BL3

BL2 Gumstix

Camera BeagleBoard

TWI

UART

TWI

Wi

LAN

USB

Figure 9 Basic HUCH onboard electronics The left hand region of the picture consisting of receiverFC and brushless motor controllers BL1minus4 represents the standard MK setup while the right handregion represents HUCH additions

work with our hardware so a dierent solution had to be found Fortunately here the USB sub-system works well out of the box and standard USB WLAN hardware could be used to set up thelink Running the system o an SD-card as well as TWI (I2C) support in Linux work well Onemore aspect of the WLAN setup is worth noting though It was desired to realise the wireless linkto the onboard Linux in Ad-Hoc mode for two reasons The rst is reduced startup time when usingAd-Hoc mode the second is independence of access point infrastructure In this way the minimalFR groundstation conguration can be operated in a more mobile manner In principle one of thenodes could be operated in Master mode but this is not supported by all hardware

Once the live Linux system and cross-compilation environment was up and running the MKcom

15

software provided the basis for further work on controller implementation Looking at the Linuxsystem at this point the following view presents itself in Figure 10

Gumstix

AringngstroumlmLinux 2631 SD

UIShell mktool wlan0

devttyS1 devi2c-0

FC Exp Groundstation

RxTx wires

Wireless link

Figure 10 Basic Linux setup

4 Experiments

41 Basic structural design through simulation

Initially the problem of altitude control was analysed in simulation To that end a simple con-troller was realised within the crrcsim 20 RC model simulator There are basically two possiblemethodological approaches to setting up a simulation for a model helicopter One is the derivationof the model from rst principles and implementation from scratch The other is building uponexisting if simplifying solutions that are practically usable and open for modication

A moderately physically realistic model of a quadrotor aerial system is governed by a nontrivialnonlinear dierential equation [3 pg 155] [4] Much microscopic detail can be added for furtherrenement as the need arises Such details are discussed to some extent in [14] and [8] In the near-hover ight regime the system behaves quasi-linearly but at more extreme velocities and attitudesthe increasing impact of several nonlinear eects such as blade apping vortex ring states orforward translational lift would have to be considered For our purposes these eects have so farbeen neglected but could in princpiple be incorporated into the model

Circumventing the necessity of model derivation and implementation the second approach waschosen In particular the existing real-time ready crrcsim [7] RC-model simulator software wasmodied to conduct the initial experiments This was particularly facilitated by the prior work ofJens W Wulf who implemented a quadrotor model and internal controller substructures for thissimulation framework [32] A screenshot of the Wulf-model ying in the modied simulation in canbe seen in Figure 11 crrcsim comes with an internal controller architecture that realises dierent

20Charles River Radio Controllers Simulation httpcrrcsimberliosde

16

attitude controllers The software originally is designed to interface manual control hardware suchas RC transmitters joysticks and such to the simulation engine It was modied to implementadditional controllers detailed state information output for plotting and analysis and networkedcontrol of the simulation engine A drawback of crrcsim is its monolithic architecture For futurework the core simulation engine would have to be separated from the render engine Alternativelythe PPZ approach could be used as a drop-in replacement

Figure 11 Simulation screenshot The helicopter model landscape and text console are part ofcrrcsim The actual debugging output that can be seen in the console is part of custom modications

411 Closed loop

The basic structure of the full control loop is displayed in Figure 12 The control module embeddedin the loop is a Single-Input Single-Output (SISO) type controller The actuating variable undercontrol is thrust which eects overall lift (see above) while the other three components are mostlycontrolled manually during the experiments The input to the controller is the current altitudeestimate The estimation process potentially has to consider multiple measurements which have tobe fused into a single representation

412 Measurements

In simulation global knowledge of the world- (and agent-) state is available and all system variablesare immediatly accessible This allows to use a simplied signal-ow structure which is depicted in

17

Measurements

z0

z1 Kalman lter Controller

Fusion Estimate PID System

znminus1

zn

throttle

Behaviour

setpoint

Figure 12 Controller structure with measurement branch

gure 13 In order for the controller to be structurally transferable to the real hardware system thespecic sensor conguration has to be modelled within the simulator This included preparationof IMU data by tapping the Flight Dynamics Model (FDM) module and basic modelling of therespective characteristics of the barometric and ultrasonic range sensors which were in use on thehelicopter at that time In the case of the barometer this meant the addition of white gaussiannoise A slow drift which can be observed on the real sensor due to slow air-pressure changes wasneglected For the ultrasonic range sensor the timing characteristic that is the maximum updaterate dependent on distance measured was emulated The information thus synthesized was fed intoa Kalman lter for further processing

Controller

PID Systemthrottle

Flight dynamics model

setpoint

Figure 13 Simplied controller structure

413 Sensor fusion

Sensor fusion is a problem class on its own The base intent is to derive an estimate of a systemstate variable from multiple measurements that is more reliable than it would be by using only asingle measurement There are several approaches which have been developed over the last decadesand which could be employed for this task The complementary lter approach can be chosen if the

18

sensors are aected by suciently dierent kinds of noise and thus eg spectrally complementarylters can be used on dierent measurement channels which are then linearily combined into a singlevalue Probably the most commonly used techniques are the linear Kalman lter and its nonlinearvariants Other methods are nonexhaustively Bayesian strategies such as Particle lters H-infinlters or neural networks A linear Kalman lter was chosen in the current setup for the reasonthat the lter and its characteristics are well documented and the implementation is straightforwardboth from scratch and even more so using matrix algebra libraries such as OpenCV The basic ltertask is to estimate the state xk isin Rn of a discrete time system governed by the linear stochasticequation [29] [15]

xk = Axkminus1 +Bukminus1 + wkminus1 (2)

based on a measurement zk isin Rm given as

zk = Hxk + vk (3)

where wk vk are random variables which represent process noise and measurement noise and arenormally distributed with zero mean p(wk) sim N(0 Q) p(vk) sim N(0 R) Q and R are the processand measurement noise covariance matrices The model used here consists of two state variablesx = (a dadt) with a the altitude (above ground) Later the model was extended to include d2adtso as to facilitate incorporation of accelerometer measurements One problem with the real sensorswas a clear deviation of the measurement noise from the assumed normal distribution and had tobe corrected for in preprocessing

414 PID controller

The Kalman lter state estimate can nally be used as the input to a PID throttle controller ThePID model used is a FOPDT integrating model The second input to the controller module is thesetpoint which can be set in the simulation via keyboard- or network-input to the application Therst working PID parametrisation was arrived at through manual tuning which is cumbersome andgives suboptimal results

415 Evolutionary parameter tuning

To prove the concept of using online learning within simulation at least the PID parameters wereoptimised using evolutionary strategies [22] [26] The tness function for this experiment wasconceivably simple chosen as

f(i) =

Nsum0

|xset minus xik| (4)

with individual i (a tuple (P ID)) setpoint xset the experiments duration in time steps N andthe altitude xik at time step k resulting from execution of controller i This stage involved setting upthe system so that simulation state and model parametrisation (the P I and D coecients) could

19

be controlled programmatically It was realised over a UDPIP connection between crrcsim andthe external simctrl control shell 21 implemented in the Python language 22 The results of theexperiment have been presented in [10]

42 MKcom2

MKcom short for MikroKopter communication tool was designed as a minimal software layer tosit on top of the UART communication link to the main ight board It provides a console baseduser interface for activation and conguration of a set of thin control functions and can act as agateway between the FC and a CMUcam MKcom functions can send commands to the FC andincoming UART packets are dispatched to the appropriate message handler This tool implementedthe modied MK message set

The setup was used as the basis for prototyping several versions of the control loop structureoutlined in Figures 12 and 13 The internal organisation of these implementations can be seenin Figure 14 Three dierent controller cores were realised which incrementally incorporated moremeasurement channels heuristic detail and safety hooks The detailed ow structure of the controllerdesign will be outlined below The update rate and execution timings are dictated by the arrivalof the measurement vector from the FC Auxiliary sensors were integrated asynchronously into themain loop A custom groundstation for state logging and realtime plotting was connected to thenetwork downlink indicated in the diagram

421 MKcom2 Flow structure

On startup a request for debug structure emission is sent manually from the mkcom shell to the FCwith the debug n command where n is the desired sampling interval in milliseconds An examplesession excerpt looks (slightly beautied) as follows (`gt indicates the shells command prompt `is the startsign of the MK protocol strings starting with ` is the raw ascii data going over thewire)gt debug 100

tx bdV ===Ds

gt

rxbuf 93 bD===IgtpU gtomgtS=xTyf=DL|pA= gt===Kl|Lnx=mL=I===i=BM|| oXfT_UrePI=T]=gt==E=|l|

L=IE||y===Y=qM

_DebugOut_ 1804 310 203 854 -843 420 -49 49 4

2 -21-1016 123 828 828 0 11 21

-1-5850 9822 -24267 51 94 1 2 -2

207 706 -1 0 7

rxbuf 93 bD===ggtpi gtm=gtT=oxzd]DL|o===m=A=Kl|ALnx=mL=I===E=m=== KxYSourePI=T]====A===

L=IM||y===Y=nf

_DebugOut_ 1834 315 192 855 -722 414 -49 32 3

4 -21-1008 123 828 828 0 2 15

0 -897811867-24267 51 94 0 1 0

207 708 -1 0 7

gt debug 0

tx bd====DZ

gt

21httpwww2informatikhu-berlinde~obertholQK22Python Language httpwwwpythonorg

20

The debug vector is populated in the FC where element positions correspond with value typesIt includes IMU data manual control input from the RC and the barometer as well as systemstatus values such as battery voltage RSSI value ampc Depending on the setup it can include thereading from the sonar as well If the actual controller is activated with eggt ac3 1

kal_cv_init DP 3 MP 5 CP 0

gt

the controller evaluation function is executed upon each arrival of a debug packet Of coursesome information is retained across calls After computation has nished an extctrl (Externalcontrol) structure is populated and sent back to the FC Aditional measurements such as from anInfraRed Ranger (IRR) are integrated in an asynchronous manner from multiple threads Severalparameters such as the altitude setpoint PID values bias ampc can also be set from the text based userinterface While this works quite well in principle and did achieve good performance modularityand extensibility were not an initial design goal This led to another iteration of the same designwithin the MAVHUB framework which will be described in the next subsection

IO Channels UART TWI UI Network

HAL threads FC-RX Expansion Ctrl Sonar Shell

Processing Controller

mkcom2

Figure 14 Mkcom2 ow-graph

43 Heuristically tuned altitude control software

The vague vision of the overall architecture that is pursued here is that of several concurring moduleswhich are summed in a cooperative time-dependent manner and where each module is responsiblefor various behavioural aspects [1] To ease prototyping and testing of components the structurehas to be kept exible extensible and dynamically recongurable This has to be considered in theoverall onboard software design In order to illustrate this requirement the ow of information andthe interaction with additional behavioural modules will be described in more detail in the followingparagraphs References will be made to several modules operating within the MAVHUB frameworkthe basics of which are described elsewhere [25]

431 Data acquisition

First the controlware has to collect all sensory information from possibly heterogenous sourcesThese include 6 - 9 channels of IMU data (depending on IMU type) a barometric measurementseveral range sensors as well as optical sensors (cameras) and of course any other sensor which is

21

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

1500

2000

Time [s]

Value

throttle

uss_meas

k_s0

Figure 15 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m aboveground The dashed line is the raw sonar range value the solid black line is the estimate uponwhich the PID controller acts The solid green line in the lower part of the plot is the controlleroutput value which is sent to the actuator

available or desired Heterogeneity pertains to hardware channels update rates and data formatsIn MAVHUB there are two main channels if information ow One is the protocol stack whichtransmits volatile incoming messages to all active modules (apps) The other is a shared memoryarea where data can be deposited by any active process In the setup considered here FC data(including IMU barometer and possibly sonar) and intermediate internal data travel on the stackSensors connected via a two-wire bus are operated by sensor drivers and measurements are put intothe shared memory The desired result of this step is to be able to operate on a homogenous vectorof input signals within the main control loop

432 Preprocessing

Subsequent to acquisition each sensory channel is individually preprocessed according to the pe-culiarities of sensor principle and connection mode Preprocessing mostly consists of linearisationunit conversion (inverting the sensor characteristic) and several kinds of heuristic validation

Linearisation For this particular setup linearisation only has to be done for the IRRs Theseare analogue sensors and the output voltage is related to the distance s measured via u(t) = 1

s(t) An example sensor characteristic is displayed in Figure 16 For the dierent subtypes of the Sharpsensors an individually parameterised procedure has to be performed as described by eg Acroname

22

Robotics in [23] if the sensors are processed on a metric basis If the Sharp sensors are driven atthe recommended supply voltage of 5V using the datasheet specications has proven sucientlyaccurate An example script for determining the parameters from given calibration data is suppliedon this reports supplementary website 22

Unit conversion The diverse units of sensor data have to be explicitly converted to units conve-nient for later steps in the calculation in particular sensor fusion with the Kalman lter For thealtitude measurements these are metersminus3 so ADC-units or time-of-ight measurements have to beconverted to millimeters for the analog sensors (barometer accelerometer infrared) and the sonarsensor repsectively This simply amounts to a multiplicative factor

Validation Heuristic sensor data validation has to be done for all types of rangers as well as for thebarometric sensor The spurious readings these sensors produce are of dierent types though Theinfrared rangers display ambigouity beyond the lower limit of the operating ranges see Figure 16For the GP2D120 which can sense the smallest ranges of all sensors this can be mostly neglectedsince the minimal sensing range can hardly be reached due to the mechanical conguration Forall the other sensors output is surpressed when the GP2D120 is active At the upper limit of theIRRs operating range the output is surpressed when a suitable threshold is reached The followingcode example illustrates this where sensor channel number three is the close range IRR

if(in_range(sensors [3] first llim ulim))

valid = 10

else

valid = 00

sensors [3] second = (fir[3]-gtcalc(valid) gt= 099) 1 0

Surpression is realised by setting appropriate values in the measurement transform matrix H(t)of the Kalman lter Alternatively this could be done by generating suitable variances for therespective sensors in the measurement covariance matrix R(t) Driving the IRRs at 33V works butreduces the usable range In addition the IRR sensor measurements are dependent on the groundsurfaces some of which eg an oce carpet can result in erratic results

The ultrasonic sensor is susceptive to dierent kinds of spurious readings caused by late echoesThis happens both when very close to an object or surface or when far away that is beyond theupper limit of measurable distances The validation strategy employed is to set hard empiricallower and upper limits for values as for the IRRs and limiting the maximum dierence betweentwo consecutive values based on assumptions about the maximum velocity An example session isillustrated in Figure 18

Finally the barometer is sensitive to acceleration which has to be accounted for The sensorbehaviour is displayed in Figure 19 The empirical corrections read

BARO (pre [1] correct from accel -z (pre [2])

pre [1] first -= (005 pre [2] first)

The validition process in general produces one new signal per channel to be used later in theprocess for setting Kalman lter matrix values One remaining problem here is the channel cross-dependency

23

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 9: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

32 Quadrotor systems overview

The quadrotor was conceived in the 1920ies bei Etienne Oehmichen and purportedly ew onlya couple of meters at the time probably due to the manual control problem The concept washibernating for most of the 20th century to resurface as an electronic toy in 1996 The Roswellyer of Area51 Technologies seems to be the earliest appearance of a working miniature quadrotorRC yer [13] Since then development of similar systems has picked up momentum considerablyBy now (2011) there exist a number of projects that are suitable (if not specically designed) asrobotics research platforms of which this section provides an overview The projects backgroundsvary from robotics and remote sensing to hobbyist RC model-ying and electronic toys

While not exclusively targeted at multicopters one of the oldest eorts to develop a versatileand open UAV system (airborne and ground segments) for model yers is the Paparazzi (PPZ)1 project of the Ecole Nationale de lAviation Civile (ENAC) The project was founded in about2003 2 and consists of an extensive set of both hardware and software components The airbornehardware consists of a variety of base processor boards (Tiny TWOG LisaLM) sensor modulesand communication devices The control software consists of a stack of PID control loops whichare executed on the microcontroller boards The overall approach reects a certain outdoor anityConsequently one of the architectures distinctive features is the use of IR thermophiles for absoluteorientation sensing (warm earth cold sky) in outdoor environments Complementing the airbornepart of the project is a comprehensive set of ground segment software and simulation modules Thiscomprises tools for tasks such as logging plotting map-supported on-screen trajectory trackingas well as eg vehicle tracking for servo-controlled directional antennas Communication amongcomponents is realised via the text- and subscription-based IVY software bus 3 which serves as thepoint of entry for component reuse from foreign systems Paparazzi also supports a high-level XMLbased ight-plan description and airframe conguration language Overall the PPZ system oersa mature codebase and a great amount of exibility through open source licensing and a modulardesign

Founded in 2006 the MikroKopter (MK) 4 project quickly gathered momentum in Germany asan RC model-ying vehicle and aerial photography system It is the system used for all experi-ments described in this work The MK architecture is a modular system that can be bought as a kitfrom the producer and consists of a combined IMU and microprocessor board called FlightCtrl (FC)which runs the attitude control software (also FlightCtrl) In fact there are several versions of theFC featuring dierent processors and sensors In addition the project has brought forth specialElectronic Speed Controllers (ESC) which interface control output on a TWI with brushless motorscalled MK-BL The distinctive feature of these controllers is the particularly high update-rate com-pared other other ESCs Consequently the MK-BL are used across many of the other projects seealso Table 1 Optional sensor modules include a compass and GPS components The main factorsfor choosing this particular system were its ready availability at the time of project initiation in2008 cost and source code access The ground and support software for the MikroKopter on theother hand is not ideally suited to demands in robot prototyping There have been attempts atdeveloping open-source and cross-platform alternatives to the vendors MikroKopter Tool althoughin the experiments described below yet other tools were used

1Paparazzi Wiki httppaparazzienacfrwikiMain_Page2httpwwwnongnuorgpaparazzigallery_v0html3Ivy Bus httpwww2tlscenafrproductsivy4MikroKopter httpwwwmikrokopterde

9

Published in late 2008 (according to the Internet Archive) the PIXHAWK (PXH) 5 project ofthe Computer Vision and Geometry Lab at the ETH Zuumlrich is an example of a system designedfrom the ground up as a robotic research platform in this case specically targeted towards visionexperiments PXH also has its own integrated processorIMU module as well as adapter hardwarefor using miniature yet high-capacity computing hardware sometimes referred to as Computer onModule (COM) The software part of the system features a comprehensive groundstation softwarecalled QGroundControl (QGC) and a low overhead communication protocol calledMAVLink 6 Sev-eral other components are provided or are in development The systems components are publishedunder open licenses and the software parts can easily be reused and adapted

Another interesting addition from around 2010 to the growing family of quadrotor systems is theArduCopter (AC) 7 which is designed on top of a more generic autopilot for both xed-wing androtary-wing platforms the ArduPilotMega (APM) 8 which in turn is based on the popular Arduino9 meta-platform The ArduPilot software already makes use of PXHs groundstation QGC throughthe MAVLink protocol In distinction to the projects mentioned so far ArduCopter uses standardunmodied low-cost ESCs for motor control which reects the general low-cost approach of theentire system This approach is most promising in terms community engagement Other relevantprojects in this category are the Unmanned Aerial Video Platform Next Generation (UAVP-NG)10 and OpenPilot 11 projects Both feature co-designed hardware and software but both have notbeen considered more closely due to their state of development during 2010 12

Among the straightforwardly commercial vendors there are two types those targeting profes-sional use outside the RC model community and those attending to the electronic toy marketThe former are mainly used for standard security and surveillance related activities In europethese are Ascending Technologies (AscTec) and microdrones AscTec models also appear in roboticsresearch but require much higher budgets The prominent representatives from the latter categoryare the DraganFlyer of RCToys whose ancestry goes back to the Roswell yer mentioned earlierand most recently the Parrot ARDrone released in 2010 featuring onboard Linux two camerasstabilisation with optical ow and an SDK for custom extensions

321 Systems summary

All these systems dier with regards to sophistication and extendability and clearly none of themprovides out-of-the-box the type of onboard computing system desired for a robotic experimentalframework targeting high-bandwidth signal processing In heterogenous multi-vehicle systems is-sues of interoperability and code-reusability can be expected to become more salient Often easeof use in terms of development and prototyping is traded o for eciency and compact hardwarewhich makes the implementations quite idiomatic

By taking a modularised approach as regards the hardware and employing in the sense ofreusability and ease of programming more powerful Single Board Computers (SBC) or COMscapable of running an operating system dierent systems providing the basic attitude control

5Pixhawk httpwwwethzchpixhawk6MAVLink httpwwwqgroundcontrolorgmavlinkstart7Arducopter httpcodegooglecomparducopter8ArduPilotMega httpcodegooglecompardupilot-mega9Arduino httpwwwarduinocc10UAVP-NG httpnguavpch11OpenPilot httpopenpilotorg12By 2011-06-09 Thu both projects status has considerably advanced

10

such as those mentioned above can be used and wired up with more capable hardware to conductexperiments with a wide range of sensors and algorithms This necessitates the integration of severaldierent downlink and communication frameworks that are in use across dierent systems

One practical option for this part of the system while keeping reusability ease of developmentand energy requirements in mind are ARM-based Linux packages such as the Gumstix or Beagle-board families or similar devices which are available at reasonable prices In summary these werethe considerations that are accumulated in the current state of the HUCH setup described belowThe diverse FR projects can be categorised along an axis indicating the level of targeted behaviourranging from low-level actuator control up to high-level navigation and high performance signalprocessing functionality Table 1 is a graphical representation showing the projects hardware andsoftware components coverage along that axis

Motor Attitude GPS Ground High-perf

UnspecStd PWM ESCs

AscTecDragoncopter

MK MK-BL Flight-Ctrl MKNAV MK-ToolPXH pxIMU via COM QGC COMPPZ TWOG Tiny Lisa GCS COM w LisaAC ArduPilot AC-GS

HUCH COMs

Table 1 Systems overview Of course it is almost always possible to attach a COM to low-levelattitude control platform such as the MK-FC ArduPilotMega or PPZ autopilots over a serialinterface Both PXH and PPZ are designed for use with Gumstix COMs

33 HUCH Sytem

331 Basics

The HUCH project was started to test bio-inspired navigation strategies on ying robots Theproject was initially equipped with basic MK kits The MK is mainly being used for RC modelying and aerial photography but the user community is also active with various other experimentsregarding extentions and modications The platforms distinctive advantages are its price readyavailability and sucient openness for research uses 13 Several academic projects have made orstill make use of the MikroKopter platform

The core component of the MK setup is the FlightCtrl (FC) comprising of both a Printed CircuitBoard (PCB) featuring an IMU a microcontroller and the rmware implementing the attitudestabilisation RC interface telemetry and more The MK architecture also features ESCs (MK-BL) capable of receiving the actuating variable via a TWI interface at a rate of 500 Hz which marksa dierence to other ESCs available on the RC market For that reason the MK-BL is also widelybeing used in many other projects

13Although with recent versions of the FlightCtrl rmware this has started to change

11

Direction Code Command Arguments

Inb Submit external control extctrl structc GyroBaro neutral Noned Request debug vector Update interval or None for one-om Start motors Nonen Kill motors None

OutD Debug vector 32 int16 values

Table 2 Five most important HUCH commands for external control of the modied MK-FC

332 Modications

Software The HUCH group has developed various extensions and modications to the platformOne of these is an expansion of the external control interface see Table 2 via the UART a corre-sponding groundstation (mcut) and control software (mktool) These are the basis for most of thework described in the remaining part of this text

The FlightCtrl microcontroller rmware was modied (HUCH variant) initially based on killa-gregs rewrite of the original rmware and implements among other things the extended communi-cation protocol higher UART baudrates TWI sensor integration and several more items 14 Thereexists a tool 15 to realise realtime display and plotting of debug variables ashing of MikroKopterrmware with embedded avrdude code parameter editing and motor testing The MKcom pro-gramm was initially developed for using a CMUcam to control the MikroKopter from vision inputIt features the basic FC communication stack and a control console This last item served as thebasis of the rst prototype of a Linux based altitude control At the time of writing develop-ment of these tools has been abandoned in favor of Micro Aerial Vehicle Humboldt Universitaumlt zuBerlin (MAVHUB) which is described in more detail elsewhere [25]

Computing hardware To overcome the severe restrictions of the Atmel ATMega644 being usedon the FC it is necessary to attach additional processing hardware Stating it more simply a singlemicrocontroller clearly is not suitable for any kind of slightly more demanding processing For thispurpose to date dierent single board systems have been used the Gumstix Verdex Pro 16 andBeagleboard variants 17 as can be seen in the gures 6 and 7 Several other options are availableand could be utilised in the future as our approach is construed exible in this regard Working ona Linux system provides a huge advantage in abstracting the algorithms from the hardware TheLinux system is connected to the FlightCtrl via the UART port In order to achieve a sampling rateof 100 Hz a baudrate of 230400 kbaud needs to be set on this connection The DebugOut messagestructure counts 95 bytes on the wire The motor command takes up 22 bytes giving 117 bytes forone sense-act cycle At the given channel capacity (25600 bytes per second) this gives approximately

14HUCH FlightCtrl 071i httpkoroinformatikhu-berlindeqkdownloadsV071i_huch-code_motodrone09targz

15mcut httpkoroinformatikhu-berlindeqkdownloadsmcuttargz16Gumstix Verdex Pro httpwwwgumstixcomproductverdex-pro17Beagleboard httpwwwbeagleboardorg

12

218 full cycles per second under optimal conditions and should be sucient for processing at 100Hz There are problems with nding higher baudrates that are supported on both sides of theconnection due to the 20 MHz clocking of the microcontroller

(a) Verdex View 1 (b) Verdex View 2

Figure 6 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below andthe expansion board on above On top is a USB WiFi dongle

A custom ATMega based ADC expansion board is acting as a generic analog data aqcisitiondevice Analog measurements are multiplexed and transmitted down a Two Wire Interface (TWI)link to the main control COM In a dierent setup an Arduino Mini was substituted for the customboard

Sensors For altitude measurement three dierent sensors were added to the setup A barometricpressure sensor is already provided for in the vendor board design This sensor is quite noisy butcovers a large range of measurement When close to the ground range sensors can be used tomeasure the distance Of this type we used a Devantech SRF02 sonic range nder This sensorhas an integrated microcontroller that does time-of-ight calculations for an ultrasonic pulse andtransmits the result digitally over a two wire interface (TWI) The speed of sound vs the actualdistance determine the maximum update frequency In our experiments these were xed at a rateof approximately 50 Hz In addition we attached two Sharp type infrared rangers (GP2Y0A02YKGP2D120) to the robot These output an analog voltage inversely proportional to the distancemeasured They are connected to the expansion board which also transmits updates via TWI butat a rate of 100 Hz The physical conguration of the range sensors is depicted in Figure 8

13

Figure 7 The electronic stack on this copter consists of (in ascending order) FC Power and UARTbreakout Beagle breakout and Arduino Mini mount BeagleBoard and USB WiFi Dongle

333 Physical system

As has been described above the FC can be given actuation commands via both the RC and UARTinterfaces in the form of the four-element vector 1 The SBC used in this particular conguration isthe Gumstix Verdex Pro X6LP The gumstix receives its power supply of 5V DC from the FC andtalks to it over the FFUART without additional level converters The hardware component setupis depicted schematically in Figure 9 On the left hand side of the diagram the base MikroKoptersetup is seen with the FlightCtrl RC receiver and the four ESCs On the right hand side theVerdex and custom sensor board are situated realising highlevel control and UDPIP link to thegroundstation over WiFi For the operation of a second onboard SBC the Beagleboard in Figure 9an additional voltage controller had to be used between the 12V DC rail and the Beagleboard powersupply socket

OpenEmbedded The current gumstix system software is provided via the Aringngstroumlm 18 distri-bution which is based on OpenEmbedded 19 The gumstix overlay provides Linux kernel versions2621 and 2631 Unfortunately the driver for the gumstix onboard WLAN hardware (netvx boardw a Marvell cf25 chip) changed between those versions and the one in 2631 refuses to actually

18Angstrom Distribution httpwwwangstrom-distributionorg19OpenEmbedded httpwwwopenembeddedorg

14

Figure 8 Range sensors attached to frame

RC receiver Onboard electronics

BL1 Expansion Board

BL4 FlightCtrl BL3

BL2 Gumstix

Camera BeagleBoard

TWI

UART

TWI

Wi

LAN

USB

Figure 9 Basic HUCH onboard electronics The left hand region of the picture consisting of receiverFC and brushless motor controllers BL1minus4 represents the standard MK setup while the right handregion represents HUCH additions

work with our hardware so a dierent solution had to be found Fortunately here the USB sub-system works well out of the box and standard USB WLAN hardware could be used to set up thelink Running the system o an SD-card as well as TWI (I2C) support in Linux work well Onemore aspect of the WLAN setup is worth noting though It was desired to realise the wireless linkto the onboard Linux in Ad-Hoc mode for two reasons The rst is reduced startup time when usingAd-Hoc mode the second is independence of access point infrastructure In this way the minimalFR groundstation conguration can be operated in a more mobile manner In principle one of thenodes could be operated in Master mode but this is not supported by all hardware

Once the live Linux system and cross-compilation environment was up and running the MKcom

15

software provided the basis for further work on controller implementation Looking at the Linuxsystem at this point the following view presents itself in Figure 10

Gumstix

AringngstroumlmLinux 2631 SD

UIShell mktool wlan0

devttyS1 devi2c-0

FC Exp Groundstation

RxTx wires

Wireless link

Figure 10 Basic Linux setup

4 Experiments

41 Basic structural design through simulation

Initially the problem of altitude control was analysed in simulation To that end a simple con-troller was realised within the crrcsim 20 RC model simulator There are basically two possiblemethodological approaches to setting up a simulation for a model helicopter One is the derivationof the model from rst principles and implementation from scratch The other is building uponexisting if simplifying solutions that are practically usable and open for modication

A moderately physically realistic model of a quadrotor aerial system is governed by a nontrivialnonlinear dierential equation [3 pg 155] [4] Much microscopic detail can be added for furtherrenement as the need arises Such details are discussed to some extent in [14] and [8] In the near-hover ight regime the system behaves quasi-linearly but at more extreme velocities and attitudesthe increasing impact of several nonlinear eects such as blade apping vortex ring states orforward translational lift would have to be considered For our purposes these eects have so farbeen neglected but could in princpiple be incorporated into the model

Circumventing the necessity of model derivation and implementation the second approach waschosen In particular the existing real-time ready crrcsim [7] RC-model simulator software wasmodied to conduct the initial experiments This was particularly facilitated by the prior work ofJens W Wulf who implemented a quadrotor model and internal controller substructures for thissimulation framework [32] A screenshot of the Wulf-model ying in the modied simulation in canbe seen in Figure 11 crrcsim comes with an internal controller architecture that realises dierent

20Charles River Radio Controllers Simulation httpcrrcsimberliosde

16

attitude controllers The software originally is designed to interface manual control hardware suchas RC transmitters joysticks and such to the simulation engine It was modied to implementadditional controllers detailed state information output for plotting and analysis and networkedcontrol of the simulation engine A drawback of crrcsim is its monolithic architecture For futurework the core simulation engine would have to be separated from the render engine Alternativelythe PPZ approach could be used as a drop-in replacement

Figure 11 Simulation screenshot The helicopter model landscape and text console are part ofcrrcsim The actual debugging output that can be seen in the console is part of custom modications

411 Closed loop

The basic structure of the full control loop is displayed in Figure 12 The control module embeddedin the loop is a Single-Input Single-Output (SISO) type controller The actuating variable undercontrol is thrust which eects overall lift (see above) while the other three components are mostlycontrolled manually during the experiments The input to the controller is the current altitudeestimate The estimation process potentially has to consider multiple measurements which have tobe fused into a single representation

412 Measurements

In simulation global knowledge of the world- (and agent-) state is available and all system variablesare immediatly accessible This allows to use a simplied signal-ow structure which is depicted in

17

Measurements

z0

z1 Kalman lter Controller

Fusion Estimate PID System

znminus1

zn

throttle

Behaviour

setpoint

Figure 12 Controller structure with measurement branch

gure 13 In order for the controller to be structurally transferable to the real hardware system thespecic sensor conguration has to be modelled within the simulator This included preparationof IMU data by tapping the Flight Dynamics Model (FDM) module and basic modelling of therespective characteristics of the barometric and ultrasonic range sensors which were in use on thehelicopter at that time In the case of the barometer this meant the addition of white gaussiannoise A slow drift which can be observed on the real sensor due to slow air-pressure changes wasneglected For the ultrasonic range sensor the timing characteristic that is the maximum updaterate dependent on distance measured was emulated The information thus synthesized was fed intoa Kalman lter for further processing

Controller

PID Systemthrottle

Flight dynamics model

setpoint

Figure 13 Simplied controller structure

413 Sensor fusion

Sensor fusion is a problem class on its own The base intent is to derive an estimate of a systemstate variable from multiple measurements that is more reliable than it would be by using only asingle measurement There are several approaches which have been developed over the last decadesand which could be employed for this task The complementary lter approach can be chosen if the

18

sensors are aected by suciently dierent kinds of noise and thus eg spectrally complementarylters can be used on dierent measurement channels which are then linearily combined into a singlevalue Probably the most commonly used techniques are the linear Kalman lter and its nonlinearvariants Other methods are nonexhaustively Bayesian strategies such as Particle lters H-infinlters or neural networks A linear Kalman lter was chosen in the current setup for the reasonthat the lter and its characteristics are well documented and the implementation is straightforwardboth from scratch and even more so using matrix algebra libraries such as OpenCV The basic ltertask is to estimate the state xk isin Rn of a discrete time system governed by the linear stochasticequation [29] [15]

xk = Axkminus1 +Bukminus1 + wkminus1 (2)

based on a measurement zk isin Rm given as

zk = Hxk + vk (3)

where wk vk are random variables which represent process noise and measurement noise and arenormally distributed with zero mean p(wk) sim N(0 Q) p(vk) sim N(0 R) Q and R are the processand measurement noise covariance matrices The model used here consists of two state variablesx = (a dadt) with a the altitude (above ground) Later the model was extended to include d2adtso as to facilitate incorporation of accelerometer measurements One problem with the real sensorswas a clear deviation of the measurement noise from the assumed normal distribution and had tobe corrected for in preprocessing

414 PID controller

The Kalman lter state estimate can nally be used as the input to a PID throttle controller ThePID model used is a FOPDT integrating model The second input to the controller module is thesetpoint which can be set in the simulation via keyboard- or network-input to the application Therst working PID parametrisation was arrived at through manual tuning which is cumbersome andgives suboptimal results

415 Evolutionary parameter tuning

To prove the concept of using online learning within simulation at least the PID parameters wereoptimised using evolutionary strategies [22] [26] The tness function for this experiment wasconceivably simple chosen as

f(i) =

Nsum0

|xset minus xik| (4)

with individual i (a tuple (P ID)) setpoint xset the experiments duration in time steps N andthe altitude xik at time step k resulting from execution of controller i This stage involved setting upthe system so that simulation state and model parametrisation (the P I and D coecients) could

19

be controlled programmatically It was realised over a UDPIP connection between crrcsim andthe external simctrl control shell 21 implemented in the Python language 22 The results of theexperiment have been presented in [10]

42 MKcom2

MKcom short for MikroKopter communication tool was designed as a minimal software layer tosit on top of the UART communication link to the main ight board It provides a console baseduser interface for activation and conguration of a set of thin control functions and can act as agateway between the FC and a CMUcam MKcom functions can send commands to the FC andincoming UART packets are dispatched to the appropriate message handler This tool implementedthe modied MK message set

The setup was used as the basis for prototyping several versions of the control loop structureoutlined in Figures 12 and 13 The internal organisation of these implementations can be seenin Figure 14 Three dierent controller cores were realised which incrementally incorporated moremeasurement channels heuristic detail and safety hooks The detailed ow structure of the controllerdesign will be outlined below The update rate and execution timings are dictated by the arrivalof the measurement vector from the FC Auxiliary sensors were integrated asynchronously into themain loop A custom groundstation for state logging and realtime plotting was connected to thenetwork downlink indicated in the diagram

421 MKcom2 Flow structure

On startup a request for debug structure emission is sent manually from the mkcom shell to the FCwith the debug n command where n is the desired sampling interval in milliseconds An examplesession excerpt looks (slightly beautied) as follows (`gt indicates the shells command prompt `is the startsign of the MK protocol strings starting with ` is the raw ascii data going over thewire)gt debug 100

tx bdV ===Ds

gt

rxbuf 93 bD===IgtpU gtomgtS=xTyf=DL|pA= gt===Kl|Lnx=mL=I===i=BM|| oXfT_UrePI=T]=gt==E=|l|

L=IE||y===Y=qM

_DebugOut_ 1804 310 203 854 -843 420 -49 49 4

2 -21-1016 123 828 828 0 11 21

-1-5850 9822 -24267 51 94 1 2 -2

207 706 -1 0 7

rxbuf 93 bD===ggtpi gtm=gtT=oxzd]DL|o===m=A=Kl|ALnx=mL=I===E=m=== KxYSourePI=T]====A===

L=IM||y===Y=nf

_DebugOut_ 1834 315 192 855 -722 414 -49 32 3

4 -21-1008 123 828 828 0 2 15

0 -897811867-24267 51 94 0 1 0

207 708 -1 0 7

gt debug 0

tx bd====DZ

gt

21httpwww2informatikhu-berlinde~obertholQK22Python Language httpwwwpythonorg

20

The debug vector is populated in the FC where element positions correspond with value typesIt includes IMU data manual control input from the RC and the barometer as well as systemstatus values such as battery voltage RSSI value ampc Depending on the setup it can include thereading from the sonar as well If the actual controller is activated with eggt ac3 1

kal_cv_init DP 3 MP 5 CP 0

gt

the controller evaluation function is executed upon each arrival of a debug packet Of coursesome information is retained across calls After computation has nished an extctrl (Externalcontrol) structure is populated and sent back to the FC Aditional measurements such as from anInfraRed Ranger (IRR) are integrated in an asynchronous manner from multiple threads Severalparameters such as the altitude setpoint PID values bias ampc can also be set from the text based userinterface While this works quite well in principle and did achieve good performance modularityand extensibility were not an initial design goal This led to another iteration of the same designwithin the MAVHUB framework which will be described in the next subsection

IO Channels UART TWI UI Network

HAL threads FC-RX Expansion Ctrl Sonar Shell

Processing Controller

mkcom2

Figure 14 Mkcom2 ow-graph

43 Heuristically tuned altitude control software

The vague vision of the overall architecture that is pursued here is that of several concurring moduleswhich are summed in a cooperative time-dependent manner and where each module is responsiblefor various behavioural aspects [1] To ease prototyping and testing of components the structurehas to be kept exible extensible and dynamically recongurable This has to be considered in theoverall onboard software design In order to illustrate this requirement the ow of information andthe interaction with additional behavioural modules will be described in more detail in the followingparagraphs References will be made to several modules operating within the MAVHUB frameworkthe basics of which are described elsewhere [25]

431 Data acquisition

First the controlware has to collect all sensory information from possibly heterogenous sourcesThese include 6 - 9 channels of IMU data (depending on IMU type) a barometric measurementseveral range sensors as well as optical sensors (cameras) and of course any other sensor which is

21

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

1500

2000

Time [s]

Value

throttle

uss_meas

k_s0

Figure 15 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m aboveground The dashed line is the raw sonar range value the solid black line is the estimate uponwhich the PID controller acts The solid green line in the lower part of the plot is the controlleroutput value which is sent to the actuator

available or desired Heterogeneity pertains to hardware channels update rates and data formatsIn MAVHUB there are two main channels if information ow One is the protocol stack whichtransmits volatile incoming messages to all active modules (apps) The other is a shared memoryarea where data can be deposited by any active process In the setup considered here FC data(including IMU barometer and possibly sonar) and intermediate internal data travel on the stackSensors connected via a two-wire bus are operated by sensor drivers and measurements are put intothe shared memory The desired result of this step is to be able to operate on a homogenous vectorof input signals within the main control loop

432 Preprocessing

Subsequent to acquisition each sensory channel is individually preprocessed according to the pe-culiarities of sensor principle and connection mode Preprocessing mostly consists of linearisationunit conversion (inverting the sensor characteristic) and several kinds of heuristic validation

Linearisation For this particular setup linearisation only has to be done for the IRRs Theseare analogue sensors and the output voltage is related to the distance s measured via u(t) = 1

s(t) An example sensor characteristic is displayed in Figure 16 For the dierent subtypes of the Sharpsensors an individually parameterised procedure has to be performed as described by eg Acroname

22

Robotics in [23] if the sensors are processed on a metric basis If the Sharp sensors are driven atthe recommended supply voltage of 5V using the datasheet specications has proven sucientlyaccurate An example script for determining the parameters from given calibration data is suppliedon this reports supplementary website 22

Unit conversion The diverse units of sensor data have to be explicitly converted to units conve-nient for later steps in the calculation in particular sensor fusion with the Kalman lter For thealtitude measurements these are metersminus3 so ADC-units or time-of-ight measurements have to beconverted to millimeters for the analog sensors (barometer accelerometer infrared) and the sonarsensor repsectively This simply amounts to a multiplicative factor

Validation Heuristic sensor data validation has to be done for all types of rangers as well as for thebarometric sensor The spurious readings these sensors produce are of dierent types though Theinfrared rangers display ambigouity beyond the lower limit of the operating ranges see Figure 16For the GP2D120 which can sense the smallest ranges of all sensors this can be mostly neglectedsince the minimal sensing range can hardly be reached due to the mechanical conguration Forall the other sensors output is surpressed when the GP2D120 is active At the upper limit of theIRRs operating range the output is surpressed when a suitable threshold is reached The followingcode example illustrates this where sensor channel number three is the close range IRR

if(in_range(sensors [3] first llim ulim))

valid = 10

else

valid = 00

sensors [3] second = (fir[3]-gtcalc(valid) gt= 099) 1 0

Surpression is realised by setting appropriate values in the measurement transform matrix H(t)of the Kalman lter Alternatively this could be done by generating suitable variances for therespective sensors in the measurement covariance matrix R(t) Driving the IRRs at 33V works butreduces the usable range In addition the IRR sensor measurements are dependent on the groundsurfaces some of which eg an oce carpet can result in erratic results

The ultrasonic sensor is susceptive to dierent kinds of spurious readings caused by late echoesThis happens both when very close to an object or surface or when far away that is beyond theupper limit of measurable distances The validation strategy employed is to set hard empiricallower and upper limits for values as for the IRRs and limiting the maximum dierence betweentwo consecutive values based on assumptions about the maximum velocity An example session isillustrated in Figure 18

Finally the barometer is sensitive to acceleration which has to be accounted for The sensorbehaviour is displayed in Figure 19 The empirical corrections read

BARO (pre [1] correct from accel -z (pre [2])

pre [1] first -= (005 pre [2] first)

The validition process in general produces one new signal per channel to be used later in theprocess for setting Kalman lter matrix values One remaining problem here is the channel cross-dependency

23

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 10: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

Published in late 2008 (according to the Internet Archive) the PIXHAWK (PXH) 5 project ofthe Computer Vision and Geometry Lab at the ETH Zuumlrich is an example of a system designedfrom the ground up as a robotic research platform in this case specically targeted towards visionexperiments PXH also has its own integrated processorIMU module as well as adapter hardwarefor using miniature yet high-capacity computing hardware sometimes referred to as Computer onModule (COM) The software part of the system features a comprehensive groundstation softwarecalled QGroundControl (QGC) and a low overhead communication protocol calledMAVLink 6 Sev-eral other components are provided or are in development The systems components are publishedunder open licenses and the software parts can easily be reused and adapted

Another interesting addition from around 2010 to the growing family of quadrotor systems is theArduCopter (AC) 7 which is designed on top of a more generic autopilot for both xed-wing androtary-wing platforms the ArduPilotMega (APM) 8 which in turn is based on the popular Arduino9 meta-platform The ArduPilot software already makes use of PXHs groundstation QGC throughthe MAVLink protocol In distinction to the projects mentioned so far ArduCopter uses standardunmodied low-cost ESCs for motor control which reects the general low-cost approach of theentire system This approach is most promising in terms community engagement Other relevantprojects in this category are the Unmanned Aerial Video Platform Next Generation (UAVP-NG)10 and OpenPilot 11 projects Both feature co-designed hardware and software but both have notbeen considered more closely due to their state of development during 2010 12

Among the straightforwardly commercial vendors there are two types those targeting profes-sional use outside the RC model community and those attending to the electronic toy marketThe former are mainly used for standard security and surveillance related activities In europethese are Ascending Technologies (AscTec) and microdrones AscTec models also appear in roboticsresearch but require much higher budgets The prominent representatives from the latter categoryare the DraganFlyer of RCToys whose ancestry goes back to the Roswell yer mentioned earlierand most recently the Parrot ARDrone released in 2010 featuring onboard Linux two camerasstabilisation with optical ow and an SDK for custom extensions

321 Systems summary

All these systems dier with regards to sophistication and extendability and clearly none of themprovides out-of-the-box the type of onboard computing system desired for a robotic experimentalframework targeting high-bandwidth signal processing In heterogenous multi-vehicle systems is-sues of interoperability and code-reusability can be expected to become more salient Often easeof use in terms of development and prototyping is traded o for eciency and compact hardwarewhich makes the implementations quite idiomatic

By taking a modularised approach as regards the hardware and employing in the sense ofreusability and ease of programming more powerful Single Board Computers (SBC) or COMscapable of running an operating system dierent systems providing the basic attitude control

5Pixhawk httpwwwethzchpixhawk6MAVLink httpwwwqgroundcontrolorgmavlinkstart7Arducopter httpcodegooglecomparducopter8ArduPilotMega httpcodegooglecompardupilot-mega9Arduino httpwwwarduinocc10UAVP-NG httpnguavpch11OpenPilot httpopenpilotorg12By 2011-06-09 Thu both projects status has considerably advanced

10

such as those mentioned above can be used and wired up with more capable hardware to conductexperiments with a wide range of sensors and algorithms This necessitates the integration of severaldierent downlink and communication frameworks that are in use across dierent systems

One practical option for this part of the system while keeping reusability ease of developmentand energy requirements in mind are ARM-based Linux packages such as the Gumstix or Beagle-board families or similar devices which are available at reasonable prices In summary these werethe considerations that are accumulated in the current state of the HUCH setup described belowThe diverse FR projects can be categorised along an axis indicating the level of targeted behaviourranging from low-level actuator control up to high-level navigation and high performance signalprocessing functionality Table 1 is a graphical representation showing the projects hardware andsoftware components coverage along that axis

Motor Attitude GPS Ground High-perf

UnspecStd PWM ESCs

AscTecDragoncopter

MK MK-BL Flight-Ctrl MKNAV MK-ToolPXH pxIMU via COM QGC COMPPZ TWOG Tiny Lisa GCS COM w LisaAC ArduPilot AC-GS

HUCH COMs

Table 1 Systems overview Of course it is almost always possible to attach a COM to low-levelattitude control platform such as the MK-FC ArduPilotMega or PPZ autopilots over a serialinterface Both PXH and PPZ are designed for use with Gumstix COMs

33 HUCH Sytem

331 Basics

The HUCH project was started to test bio-inspired navigation strategies on ying robots Theproject was initially equipped with basic MK kits The MK is mainly being used for RC modelying and aerial photography but the user community is also active with various other experimentsregarding extentions and modications The platforms distinctive advantages are its price readyavailability and sucient openness for research uses 13 Several academic projects have made orstill make use of the MikroKopter platform

The core component of the MK setup is the FlightCtrl (FC) comprising of both a Printed CircuitBoard (PCB) featuring an IMU a microcontroller and the rmware implementing the attitudestabilisation RC interface telemetry and more The MK architecture also features ESCs (MK-BL) capable of receiving the actuating variable via a TWI interface at a rate of 500 Hz which marksa dierence to other ESCs available on the RC market For that reason the MK-BL is also widelybeing used in many other projects

13Although with recent versions of the FlightCtrl rmware this has started to change

11

Direction Code Command Arguments

Inb Submit external control extctrl structc GyroBaro neutral Noned Request debug vector Update interval or None for one-om Start motors Nonen Kill motors None

OutD Debug vector 32 int16 values

Table 2 Five most important HUCH commands for external control of the modied MK-FC

332 Modications

Software The HUCH group has developed various extensions and modications to the platformOne of these is an expansion of the external control interface see Table 2 via the UART a corre-sponding groundstation (mcut) and control software (mktool) These are the basis for most of thework described in the remaining part of this text

The FlightCtrl microcontroller rmware was modied (HUCH variant) initially based on killa-gregs rewrite of the original rmware and implements among other things the extended communi-cation protocol higher UART baudrates TWI sensor integration and several more items 14 Thereexists a tool 15 to realise realtime display and plotting of debug variables ashing of MikroKopterrmware with embedded avrdude code parameter editing and motor testing The MKcom pro-gramm was initially developed for using a CMUcam to control the MikroKopter from vision inputIt features the basic FC communication stack and a control console This last item served as thebasis of the rst prototype of a Linux based altitude control At the time of writing develop-ment of these tools has been abandoned in favor of Micro Aerial Vehicle Humboldt Universitaumlt zuBerlin (MAVHUB) which is described in more detail elsewhere [25]

Computing hardware To overcome the severe restrictions of the Atmel ATMega644 being usedon the FC it is necessary to attach additional processing hardware Stating it more simply a singlemicrocontroller clearly is not suitable for any kind of slightly more demanding processing For thispurpose to date dierent single board systems have been used the Gumstix Verdex Pro 16 andBeagleboard variants 17 as can be seen in the gures 6 and 7 Several other options are availableand could be utilised in the future as our approach is construed exible in this regard Working ona Linux system provides a huge advantage in abstracting the algorithms from the hardware TheLinux system is connected to the FlightCtrl via the UART port In order to achieve a sampling rateof 100 Hz a baudrate of 230400 kbaud needs to be set on this connection The DebugOut messagestructure counts 95 bytes on the wire The motor command takes up 22 bytes giving 117 bytes forone sense-act cycle At the given channel capacity (25600 bytes per second) this gives approximately

14HUCH FlightCtrl 071i httpkoroinformatikhu-berlindeqkdownloadsV071i_huch-code_motodrone09targz

15mcut httpkoroinformatikhu-berlindeqkdownloadsmcuttargz16Gumstix Verdex Pro httpwwwgumstixcomproductverdex-pro17Beagleboard httpwwwbeagleboardorg

12

218 full cycles per second under optimal conditions and should be sucient for processing at 100Hz There are problems with nding higher baudrates that are supported on both sides of theconnection due to the 20 MHz clocking of the microcontroller

(a) Verdex View 1 (b) Verdex View 2

Figure 6 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below andthe expansion board on above On top is a USB WiFi dongle

A custom ATMega based ADC expansion board is acting as a generic analog data aqcisitiondevice Analog measurements are multiplexed and transmitted down a Two Wire Interface (TWI)link to the main control COM In a dierent setup an Arduino Mini was substituted for the customboard

Sensors For altitude measurement three dierent sensors were added to the setup A barometricpressure sensor is already provided for in the vendor board design This sensor is quite noisy butcovers a large range of measurement When close to the ground range sensors can be used tomeasure the distance Of this type we used a Devantech SRF02 sonic range nder This sensorhas an integrated microcontroller that does time-of-ight calculations for an ultrasonic pulse andtransmits the result digitally over a two wire interface (TWI) The speed of sound vs the actualdistance determine the maximum update frequency In our experiments these were xed at a rateof approximately 50 Hz In addition we attached two Sharp type infrared rangers (GP2Y0A02YKGP2D120) to the robot These output an analog voltage inversely proportional to the distancemeasured They are connected to the expansion board which also transmits updates via TWI butat a rate of 100 Hz The physical conguration of the range sensors is depicted in Figure 8

13

Figure 7 The electronic stack on this copter consists of (in ascending order) FC Power and UARTbreakout Beagle breakout and Arduino Mini mount BeagleBoard and USB WiFi Dongle

333 Physical system

As has been described above the FC can be given actuation commands via both the RC and UARTinterfaces in the form of the four-element vector 1 The SBC used in this particular conguration isthe Gumstix Verdex Pro X6LP The gumstix receives its power supply of 5V DC from the FC andtalks to it over the FFUART without additional level converters The hardware component setupis depicted schematically in Figure 9 On the left hand side of the diagram the base MikroKoptersetup is seen with the FlightCtrl RC receiver and the four ESCs On the right hand side theVerdex and custom sensor board are situated realising highlevel control and UDPIP link to thegroundstation over WiFi For the operation of a second onboard SBC the Beagleboard in Figure 9an additional voltage controller had to be used between the 12V DC rail and the Beagleboard powersupply socket

OpenEmbedded The current gumstix system software is provided via the Aringngstroumlm 18 distri-bution which is based on OpenEmbedded 19 The gumstix overlay provides Linux kernel versions2621 and 2631 Unfortunately the driver for the gumstix onboard WLAN hardware (netvx boardw a Marvell cf25 chip) changed between those versions and the one in 2631 refuses to actually

18Angstrom Distribution httpwwwangstrom-distributionorg19OpenEmbedded httpwwwopenembeddedorg

14

Figure 8 Range sensors attached to frame

RC receiver Onboard electronics

BL1 Expansion Board

BL4 FlightCtrl BL3

BL2 Gumstix

Camera BeagleBoard

TWI

UART

TWI

Wi

LAN

USB

Figure 9 Basic HUCH onboard electronics The left hand region of the picture consisting of receiverFC and brushless motor controllers BL1minus4 represents the standard MK setup while the right handregion represents HUCH additions

work with our hardware so a dierent solution had to be found Fortunately here the USB sub-system works well out of the box and standard USB WLAN hardware could be used to set up thelink Running the system o an SD-card as well as TWI (I2C) support in Linux work well Onemore aspect of the WLAN setup is worth noting though It was desired to realise the wireless linkto the onboard Linux in Ad-Hoc mode for two reasons The rst is reduced startup time when usingAd-Hoc mode the second is independence of access point infrastructure In this way the minimalFR groundstation conguration can be operated in a more mobile manner In principle one of thenodes could be operated in Master mode but this is not supported by all hardware

Once the live Linux system and cross-compilation environment was up and running the MKcom

15

software provided the basis for further work on controller implementation Looking at the Linuxsystem at this point the following view presents itself in Figure 10

Gumstix

AringngstroumlmLinux 2631 SD

UIShell mktool wlan0

devttyS1 devi2c-0

FC Exp Groundstation

RxTx wires

Wireless link

Figure 10 Basic Linux setup

4 Experiments

41 Basic structural design through simulation

Initially the problem of altitude control was analysed in simulation To that end a simple con-troller was realised within the crrcsim 20 RC model simulator There are basically two possiblemethodological approaches to setting up a simulation for a model helicopter One is the derivationof the model from rst principles and implementation from scratch The other is building uponexisting if simplifying solutions that are practically usable and open for modication

A moderately physically realistic model of a quadrotor aerial system is governed by a nontrivialnonlinear dierential equation [3 pg 155] [4] Much microscopic detail can be added for furtherrenement as the need arises Such details are discussed to some extent in [14] and [8] In the near-hover ight regime the system behaves quasi-linearly but at more extreme velocities and attitudesthe increasing impact of several nonlinear eects such as blade apping vortex ring states orforward translational lift would have to be considered For our purposes these eects have so farbeen neglected but could in princpiple be incorporated into the model

Circumventing the necessity of model derivation and implementation the second approach waschosen In particular the existing real-time ready crrcsim [7] RC-model simulator software wasmodied to conduct the initial experiments This was particularly facilitated by the prior work ofJens W Wulf who implemented a quadrotor model and internal controller substructures for thissimulation framework [32] A screenshot of the Wulf-model ying in the modied simulation in canbe seen in Figure 11 crrcsim comes with an internal controller architecture that realises dierent

20Charles River Radio Controllers Simulation httpcrrcsimberliosde

16

attitude controllers The software originally is designed to interface manual control hardware suchas RC transmitters joysticks and such to the simulation engine It was modied to implementadditional controllers detailed state information output for plotting and analysis and networkedcontrol of the simulation engine A drawback of crrcsim is its monolithic architecture For futurework the core simulation engine would have to be separated from the render engine Alternativelythe PPZ approach could be used as a drop-in replacement

Figure 11 Simulation screenshot The helicopter model landscape and text console are part ofcrrcsim The actual debugging output that can be seen in the console is part of custom modications

411 Closed loop

The basic structure of the full control loop is displayed in Figure 12 The control module embeddedin the loop is a Single-Input Single-Output (SISO) type controller The actuating variable undercontrol is thrust which eects overall lift (see above) while the other three components are mostlycontrolled manually during the experiments The input to the controller is the current altitudeestimate The estimation process potentially has to consider multiple measurements which have tobe fused into a single representation

412 Measurements

In simulation global knowledge of the world- (and agent-) state is available and all system variablesare immediatly accessible This allows to use a simplied signal-ow structure which is depicted in

17

Measurements

z0

z1 Kalman lter Controller

Fusion Estimate PID System

znminus1

zn

throttle

Behaviour

setpoint

Figure 12 Controller structure with measurement branch

gure 13 In order for the controller to be structurally transferable to the real hardware system thespecic sensor conguration has to be modelled within the simulator This included preparationof IMU data by tapping the Flight Dynamics Model (FDM) module and basic modelling of therespective characteristics of the barometric and ultrasonic range sensors which were in use on thehelicopter at that time In the case of the barometer this meant the addition of white gaussiannoise A slow drift which can be observed on the real sensor due to slow air-pressure changes wasneglected For the ultrasonic range sensor the timing characteristic that is the maximum updaterate dependent on distance measured was emulated The information thus synthesized was fed intoa Kalman lter for further processing

Controller

PID Systemthrottle

Flight dynamics model

setpoint

Figure 13 Simplied controller structure

413 Sensor fusion

Sensor fusion is a problem class on its own The base intent is to derive an estimate of a systemstate variable from multiple measurements that is more reliable than it would be by using only asingle measurement There are several approaches which have been developed over the last decadesand which could be employed for this task The complementary lter approach can be chosen if the

18

sensors are aected by suciently dierent kinds of noise and thus eg spectrally complementarylters can be used on dierent measurement channels which are then linearily combined into a singlevalue Probably the most commonly used techniques are the linear Kalman lter and its nonlinearvariants Other methods are nonexhaustively Bayesian strategies such as Particle lters H-infinlters or neural networks A linear Kalman lter was chosen in the current setup for the reasonthat the lter and its characteristics are well documented and the implementation is straightforwardboth from scratch and even more so using matrix algebra libraries such as OpenCV The basic ltertask is to estimate the state xk isin Rn of a discrete time system governed by the linear stochasticequation [29] [15]

xk = Axkminus1 +Bukminus1 + wkminus1 (2)

based on a measurement zk isin Rm given as

zk = Hxk + vk (3)

where wk vk are random variables which represent process noise and measurement noise and arenormally distributed with zero mean p(wk) sim N(0 Q) p(vk) sim N(0 R) Q and R are the processand measurement noise covariance matrices The model used here consists of two state variablesx = (a dadt) with a the altitude (above ground) Later the model was extended to include d2adtso as to facilitate incorporation of accelerometer measurements One problem with the real sensorswas a clear deviation of the measurement noise from the assumed normal distribution and had tobe corrected for in preprocessing

414 PID controller

The Kalman lter state estimate can nally be used as the input to a PID throttle controller ThePID model used is a FOPDT integrating model The second input to the controller module is thesetpoint which can be set in the simulation via keyboard- or network-input to the application Therst working PID parametrisation was arrived at through manual tuning which is cumbersome andgives suboptimal results

415 Evolutionary parameter tuning

To prove the concept of using online learning within simulation at least the PID parameters wereoptimised using evolutionary strategies [22] [26] The tness function for this experiment wasconceivably simple chosen as

f(i) =

Nsum0

|xset minus xik| (4)

with individual i (a tuple (P ID)) setpoint xset the experiments duration in time steps N andthe altitude xik at time step k resulting from execution of controller i This stage involved setting upthe system so that simulation state and model parametrisation (the P I and D coecients) could

19

be controlled programmatically It was realised over a UDPIP connection between crrcsim andthe external simctrl control shell 21 implemented in the Python language 22 The results of theexperiment have been presented in [10]

42 MKcom2

MKcom short for MikroKopter communication tool was designed as a minimal software layer tosit on top of the UART communication link to the main ight board It provides a console baseduser interface for activation and conguration of a set of thin control functions and can act as agateway between the FC and a CMUcam MKcom functions can send commands to the FC andincoming UART packets are dispatched to the appropriate message handler This tool implementedthe modied MK message set

The setup was used as the basis for prototyping several versions of the control loop structureoutlined in Figures 12 and 13 The internal organisation of these implementations can be seenin Figure 14 Three dierent controller cores were realised which incrementally incorporated moremeasurement channels heuristic detail and safety hooks The detailed ow structure of the controllerdesign will be outlined below The update rate and execution timings are dictated by the arrivalof the measurement vector from the FC Auxiliary sensors were integrated asynchronously into themain loop A custom groundstation for state logging and realtime plotting was connected to thenetwork downlink indicated in the diagram

421 MKcom2 Flow structure

On startup a request for debug structure emission is sent manually from the mkcom shell to the FCwith the debug n command where n is the desired sampling interval in milliseconds An examplesession excerpt looks (slightly beautied) as follows (`gt indicates the shells command prompt `is the startsign of the MK protocol strings starting with ` is the raw ascii data going over thewire)gt debug 100

tx bdV ===Ds

gt

rxbuf 93 bD===IgtpU gtomgtS=xTyf=DL|pA= gt===Kl|Lnx=mL=I===i=BM|| oXfT_UrePI=T]=gt==E=|l|

L=IE||y===Y=qM

_DebugOut_ 1804 310 203 854 -843 420 -49 49 4

2 -21-1016 123 828 828 0 11 21

-1-5850 9822 -24267 51 94 1 2 -2

207 706 -1 0 7

rxbuf 93 bD===ggtpi gtm=gtT=oxzd]DL|o===m=A=Kl|ALnx=mL=I===E=m=== KxYSourePI=T]====A===

L=IM||y===Y=nf

_DebugOut_ 1834 315 192 855 -722 414 -49 32 3

4 -21-1008 123 828 828 0 2 15

0 -897811867-24267 51 94 0 1 0

207 708 -1 0 7

gt debug 0

tx bd====DZ

gt

21httpwww2informatikhu-berlinde~obertholQK22Python Language httpwwwpythonorg

20

The debug vector is populated in the FC where element positions correspond with value typesIt includes IMU data manual control input from the RC and the barometer as well as systemstatus values such as battery voltage RSSI value ampc Depending on the setup it can include thereading from the sonar as well If the actual controller is activated with eggt ac3 1

kal_cv_init DP 3 MP 5 CP 0

gt

the controller evaluation function is executed upon each arrival of a debug packet Of coursesome information is retained across calls After computation has nished an extctrl (Externalcontrol) structure is populated and sent back to the FC Aditional measurements such as from anInfraRed Ranger (IRR) are integrated in an asynchronous manner from multiple threads Severalparameters such as the altitude setpoint PID values bias ampc can also be set from the text based userinterface While this works quite well in principle and did achieve good performance modularityand extensibility were not an initial design goal This led to another iteration of the same designwithin the MAVHUB framework which will be described in the next subsection

IO Channels UART TWI UI Network

HAL threads FC-RX Expansion Ctrl Sonar Shell

Processing Controller

mkcom2

Figure 14 Mkcom2 ow-graph

43 Heuristically tuned altitude control software

The vague vision of the overall architecture that is pursued here is that of several concurring moduleswhich are summed in a cooperative time-dependent manner and where each module is responsiblefor various behavioural aspects [1] To ease prototyping and testing of components the structurehas to be kept exible extensible and dynamically recongurable This has to be considered in theoverall onboard software design In order to illustrate this requirement the ow of information andthe interaction with additional behavioural modules will be described in more detail in the followingparagraphs References will be made to several modules operating within the MAVHUB frameworkthe basics of which are described elsewhere [25]

431 Data acquisition

First the controlware has to collect all sensory information from possibly heterogenous sourcesThese include 6 - 9 channels of IMU data (depending on IMU type) a barometric measurementseveral range sensors as well as optical sensors (cameras) and of course any other sensor which is

21

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

1500

2000

Time [s]

Value

throttle

uss_meas

k_s0

Figure 15 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m aboveground The dashed line is the raw sonar range value the solid black line is the estimate uponwhich the PID controller acts The solid green line in the lower part of the plot is the controlleroutput value which is sent to the actuator

available or desired Heterogeneity pertains to hardware channels update rates and data formatsIn MAVHUB there are two main channels if information ow One is the protocol stack whichtransmits volatile incoming messages to all active modules (apps) The other is a shared memoryarea where data can be deposited by any active process In the setup considered here FC data(including IMU barometer and possibly sonar) and intermediate internal data travel on the stackSensors connected via a two-wire bus are operated by sensor drivers and measurements are put intothe shared memory The desired result of this step is to be able to operate on a homogenous vectorof input signals within the main control loop

432 Preprocessing

Subsequent to acquisition each sensory channel is individually preprocessed according to the pe-culiarities of sensor principle and connection mode Preprocessing mostly consists of linearisationunit conversion (inverting the sensor characteristic) and several kinds of heuristic validation

Linearisation For this particular setup linearisation only has to be done for the IRRs Theseare analogue sensors and the output voltage is related to the distance s measured via u(t) = 1

s(t) An example sensor characteristic is displayed in Figure 16 For the dierent subtypes of the Sharpsensors an individually parameterised procedure has to be performed as described by eg Acroname

22

Robotics in [23] if the sensors are processed on a metric basis If the Sharp sensors are driven atthe recommended supply voltage of 5V using the datasheet specications has proven sucientlyaccurate An example script for determining the parameters from given calibration data is suppliedon this reports supplementary website 22

Unit conversion The diverse units of sensor data have to be explicitly converted to units conve-nient for later steps in the calculation in particular sensor fusion with the Kalman lter For thealtitude measurements these are metersminus3 so ADC-units or time-of-ight measurements have to beconverted to millimeters for the analog sensors (barometer accelerometer infrared) and the sonarsensor repsectively This simply amounts to a multiplicative factor

Validation Heuristic sensor data validation has to be done for all types of rangers as well as for thebarometric sensor The spurious readings these sensors produce are of dierent types though Theinfrared rangers display ambigouity beyond the lower limit of the operating ranges see Figure 16For the GP2D120 which can sense the smallest ranges of all sensors this can be mostly neglectedsince the minimal sensing range can hardly be reached due to the mechanical conguration Forall the other sensors output is surpressed when the GP2D120 is active At the upper limit of theIRRs operating range the output is surpressed when a suitable threshold is reached The followingcode example illustrates this where sensor channel number three is the close range IRR

if(in_range(sensors [3] first llim ulim))

valid = 10

else

valid = 00

sensors [3] second = (fir[3]-gtcalc(valid) gt= 099) 1 0

Surpression is realised by setting appropriate values in the measurement transform matrix H(t)of the Kalman lter Alternatively this could be done by generating suitable variances for therespective sensors in the measurement covariance matrix R(t) Driving the IRRs at 33V works butreduces the usable range In addition the IRR sensor measurements are dependent on the groundsurfaces some of which eg an oce carpet can result in erratic results

The ultrasonic sensor is susceptive to dierent kinds of spurious readings caused by late echoesThis happens both when very close to an object or surface or when far away that is beyond theupper limit of measurable distances The validation strategy employed is to set hard empiricallower and upper limits for values as for the IRRs and limiting the maximum dierence betweentwo consecutive values based on assumptions about the maximum velocity An example session isillustrated in Figure 18

Finally the barometer is sensitive to acceleration which has to be accounted for The sensorbehaviour is displayed in Figure 19 The empirical corrections read

BARO (pre [1] correct from accel -z (pre [2])

pre [1] first -= (005 pre [2] first)

The validition process in general produces one new signal per channel to be used later in theprocess for setting Kalman lter matrix values One remaining problem here is the channel cross-dependency

23

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 11: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

such as those mentioned above can be used and wired up with more capable hardware to conductexperiments with a wide range of sensors and algorithms This necessitates the integration of severaldierent downlink and communication frameworks that are in use across dierent systems

One practical option for this part of the system while keeping reusability ease of developmentand energy requirements in mind are ARM-based Linux packages such as the Gumstix or Beagle-board families or similar devices which are available at reasonable prices In summary these werethe considerations that are accumulated in the current state of the HUCH setup described belowThe diverse FR projects can be categorised along an axis indicating the level of targeted behaviourranging from low-level actuator control up to high-level navigation and high performance signalprocessing functionality Table 1 is a graphical representation showing the projects hardware andsoftware components coverage along that axis

Motor Attitude GPS Ground High-perf

UnspecStd PWM ESCs

AscTecDragoncopter

MK MK-BL Flight-Ctrl MKNAV MK-ToolPXH pxIMU via COM QGC COMPPZ TWOG Tiny Lisa GCS COM w LisaAC ArduPilot AC-GS

HUCH COMs

Table 1 Systems overview Of course it is almost always possible to attach a COM to low-levelattitude control platform such as the MK-FC ArduPilotMega or PPZ autopilots over a serialinterface Both PXH and PPZ are designed for use with Gumstix COMs

33 HUCH Sytem

331 Basics

The HUCH project was started to test bio-inspired navigation strategies on ying robots Theproject was initially equipped with basic MK kits The MK is mainly being used for RC modelying and aerial photography but the user community is also active with various other experimentsregarding extentions and modications The platforms distinctive advantages are its price readyavailability and sucient openness for research uses 13 Several academic projects have made orstill make use of the MikroKopter platform

The core component of the MK setup is the FlightCtrl (FC) comprising of both a Printed CircuitBoard (PCB) featuring an IMU a microcontroller and the rmware implementing the attitudestabilisation RC interface telemetry and more The MK architecture also features ESCs (MK-BL) capable of receiving the actuating variable via a TWI interface at a rate of 500 Hz which marksa dierence to other ESCs available on the RC market For that reason the MK-BL is also widelybeing used in many other projects

13Although with recent versions of the FlightCtrl rmware this has started to change

11

Direction Code Command Arguments

Inb Submit external control extctrl structc GyroBaro neutral Noned Request debug vector Update interval or None for one-om Start motors Nonen Kill motors None

OutD Debug vector 32 int16 values

Table 2 Five most important HUCH commands for external control of the modied MK-FC

332 Modications

Software The HUCH group has developed various extensions and modications to the platformOne of these is an expansion of the external control interface see Table 2 via the UART a corre-sponding groundstation (mcut) and control software (mktool) These are the basis for most of thework described in the remaining part of this text

The FlightCtrl microcontroller rmware was modied (HUCH variant) initially based on killa-gregs rewrite of the original rmware and implements among other things the extended communi-cation protocol higher UART baudrates TWI sensor integration and several more items 14 Thereexists a tool 15 to realise realtime display and plotting of debug variables ashing of MikroKopterrmware with embedded avrdude code parameter editing and motor testing The MKcom pro-gramm was initially developed for using a CMUcam to control the MikroKopter from vision inputIt features the basic FC communication stack and a control console This last item served as thebasis of the rst prototype of a Linux based altitude control At the time of writing develop-ment of these tools has been abandoned in favor of Micro Aerial Vehicle Humboldt Universitaumlt zuBerlin (MAVHUB) which is described in more detail elsewhere [25]

Computing hardware To overcome the severe restrictions of the Atmel ATMega644 being usedon the FC it is necessary to attach additional processing hardware Stating it more simply a singlemicrocontroller clearly is not suitable for any kind of slightly more demanding processing For thispurpose to date dierent single board systems have been used the Gumstix Verdex Pro 16 andBeagleboard variants 17 as can be seen in the gures 6 and 7 Several other options are availableand could be utilised in the future as our approach is construed exible in this regard Working ona Linux system provides a huge advantage in abstracting the algorithms from the hardware TheLinux system is connected to the FlightCtrl via the UART port In order to achieve a sampling rateof 100 Hz a baudrate of 230400 kbaud needs to be set on this connection The DebugOut messagestructure counts 95 bytes on the wire The motor command takes up 22 bytes giving 117 bytes forone sense-act cycle At the given channel capacity (25600 bytes per second) this gives approximately

14HUCH FlightCtrl 071i httpkoroinformatikhu-berlindeqkdownloadsV071i_huch-code_motodrone09targz

15mcut httpkoroinformatikhu-berlindeqkdownloadsmcuttargz16Gumstix Verdex Pro httpwwwgumstixcomproductverdex-pro17Beagleboard httpwwwbeagleboardorg

12

218 full cycles per second under optimal conditions and should be sucient for processing at 100Hz There are problems with nding higher baudrates that are supported on both sides of theconnection due to the 20 MHz clocking of the microcontroller

(a) Verdex View 1 (b) Verdex View 2

Figure 6 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below andthe expansion board on above On top is a USB WiFi dongle

A custom ATMega based ADC expansion board is acting as a generic analog data aqcisitiondevice Analog measurements are multiplexed and transmitted down a Two Wire Interface (TWI)link to the main control COM In a dierent setup an Arduino Mini was substituted for the customboard

Sensors For altitude measurement three dierent sensors were added to the setup A barometricpressure sensor is already provided for in the vendor board design This sensor is quite noisy butcovers a large range of measurement When close to the ground range sensors can be used tomeasure the distance Of this type we used a Devantech SRF02 sonic range nder This sensorhas an integrated microcontroller that does time-of-ight calculations for an ultrasonic pulse andtransmits the result digitally over a two wire interface (TWI) The speed of sound vs the actualdistance determine the maximum update frequency In our experiments these were xed at a rateof approximately 50 Hz In addition we attached two Sharp type infrared rangers (GP2Y0A02YKGP2D120) to the robot These output an analog voltage inversely proportional to the distancemeasured They are connected to the expansion board which also transmits updates via TWI butat a rate of 100 Hz The physical conguration of the range sensors is depicted in Figure 8

13

Figure 7 The electronic stack on this copter consists of (in ascending order) FC Power and UARTbreakout Beagle breakout and Arduino Mini mount BeagleBoard and USB WiFi Dongle

333 Physical system

As has been described above the FC can be given actuation commands via both the RC and UARTinterfaces in the form of the four-element vector 1 The SBC used in this particular conguration isthe Gumstix Verdex Pro X6LP The gumstix receives its power supply of 5V DC from the FC andtalks to it over the FFUART without additional level converters The hardware component setupis depicted schematically in Figure 9 On the left hand side of the diagram the base MikroKoptersetup is seen with the FlightCtrl RC receiver and the four ESCs On the right hand side theVerdex and custom sensor board are situated realising highlevel control and UDPIP link to thegroundstation over WiFi For the operation of a second onboard SBC the Beagleboard in Figure 9an additional voltage controller had to be used between the 12V DC rail and the Beagleboard powersupply socket

OpenEmbedded The current gumstix system software is provided via the Aringngstroumlm 18 distri-bution which is based on OpenEmbedded 19 The gumstix overlay provides Linux kernel versions2621 and 2631 Unfortunately the driver for the gumstix onboard WLAN hardware (netvx boardw a Marvell cf25 chip) changed between those versions and the one in 2631 refuses to actually

18Angstrom Distribution httpwwwangstrom-distributionorg19OpenEmbedded httpwwwopenembeddedorg

14

Figure 8 Range sensors attached to frame

RC receiver Onboard electronics

BL1 Expansion Board

BL4 FlightCtrl BL3

BL2 Gumstix

Camera BeagleBoard

TWI

UART

TWI

Wi

LAN

USB

Figure 9 Basic HUCH onboard electronics The left hand region of the picture consisting of receiverFC and brushless motor controllers BL1minus4 represents the standard MK setup while the right handregion represents HUCH additions

work with our hardware so a dierent solution had to be found Fortunately here the USB sub-system works well out of the box and standard USB WLAN hardware could be used to set up thelink Running the system o an SD-card as well as TWI (I2C) support in Linux work well Onemore aspect of the WLAN setup is worth noting though It was desired to realise the wireless linkto the onboard Linux in Ad-Hoc mode for two reasons The rst is reduced startup time when usingAd-Hoc mode the second is independence of access point infrastructure In this way the minimalFR groundstation conguration can be operated in a more mobile manner In principle one of thenodes could be operated in Master mode but this is not supported by all hardware

Once the live Linux system and cross-compilation environment was up and running the MKcom

15

software provided the basis for further work on controller implementation Looking at the Linuxsystem at this point the following view presents itself in Figure 10

Gumstix

AringngstroumlmLinux 2631 SD

UIShell mktool wlan0

devttyS1 devi2c-0

FC Exp Groundstation

RxTx wires

Wireless link

Figure 10 Basic Linux setup

4 Experiments

41 Basic structural design through simulation

Initially the problem of altitude control was analysed in simulation To that end a simple con-troller was realised within the crrcsim 20 RC model simulator There are basically two possiblemethodological approaches to setting up a simulation for a model helicopter One is the derivationof the model from rst principles and implementation from scratch The other is building uponexisting if simplifying solutions that are practically usable and open for modication

A moderately physically realistic model of a quadrotor aerial system is governed by a nontrivialnonlinear dierential equation [3 pg 155] [4] Much microscopic detail can be added for furtherrenement as the need arises Such details are discussed to some extent in [14] and [8] In the near-hover ight regime the system behaves quasi-linearly but at more extreme velocities and attitudesthe increasing impact of several nonlinear eects such as blade apping vortex ring states orforward translational lift would have to be considered For our purposes these eects have so farbeen neglected but could in princpiple be incorporated into the model

Circumventing the necessity of model derivation and implementation the second approach waschosen In particular the existing real-time ready crrcsim [7] RC-model simulator software wasmodied to conduct the initial experiments This was particularly facilitated by the prior work ofJens W Wulf who implemented a quadrotor model and internal controller substructures for thissimulation framework [32] A screenshot of the Wulf-model ying in the modied simulation in canbe seen in Figure 11 crrcsim comes with an internal controller architecture that realises dierent

20Charles River Radio Controllers Simulation httpcrrcsimberliosde

16

attitude controllers The software originally is designed to interface manual control hardware suchas RC transmitters joysticks and such to the simulation engine It was modied to implementadditional controllers detailed state information output for plotting and analysis and networkedcontrol of the simulation engine A drawback of crrcsim is its monolithic architecture For futurework the core simulation engine would have to be separated from the render engine Alternativelythe PPZ approach could be used as a drop-in replacement

Figure 11 Simulation screenshot The helicopter model landscape and text console are part ofcrrcsim The actual debugging output that can be seen in the console is part of custom modications

411 Closed loop

The basic structure of the full control loop is displayed in Figure 12 The control module embeddedin the loop is a Single-Input Single-Output (SISO) type controller The actuating variable undercontrol is thrust which eects overall lift (see above) while the other three components are mostlycontrolled manually during the experiments The input to the controller is the current altitudeestimate The estimation process potentially has to consider multiple measurements which have tobe fused into a single representation

412 Measurements

In simulation global knowledge of the world- (and agent-) state is available and all system variablesare immediatly accessible This allows to use a simplied signal-ow structure which is depicted in

17

Measurements

z0

z1 Kalman lter Controller

Fusion Estimate PID System

znminus1

zn

throttle

Behaviour

setpoint

Figure 12 Controller structure with measurement branch

gure 13 In order for the controller to be structurally transferable to the real hardware system thespecic sensor conguration has to be modelled within the simulator This included preparationof IMU data by tapping the Flight Dynamics Model (FDM) module and basic modelling of therespective characteristics of the barometric and ultrasonic range sensors which were in use on thehelicopter at that time In the case of the barometer this meant the addition of white gaussiannoise A slow drift which can be observed on the real sensor due to slow air-pressure changes wasneglected For the ultrasonic range sensor the timing characteristic that is the maximum updaterate dependent on distance measured was emulated The information thus synthesized was fed intoa Kalman lter for further processing

Controller

PID Systemthrottle

Flight dynamics model

setpoint

Figure 13 Simplied controller structure

413 Sensor fusion

Sensor fusion is a problem class on its own The base intent is to derive an estimate of a systemstate variable from multiple measurements that is more reliable than it would be by using only asingle measurement There are several approaches which have been developed over the last decadesand which could be employed for this task The complementary lter approach can be chosen if the

18

sensors are aected by suciently dierent kinds of noise and thus eg spectrally complementarylters can be used on dierent measurement channels which are then linearily combined into a singlevalue Probably the most commonly used techniques are the linear Kalman lter and its nonlinearvariants Other methods are nonexhaustively Bayesian strategies such as Particle lters H-infinlters or neural networks A linear Kalman lter was chosen in the current setup for the reasonthat the lter and its characteristics are well documented and the implementation is straightforwardboth from scratch and even more so using matrix algebra libraries such as OpenCV The basic ltertask is to estimate the state xk isin Rn of a discrete time system governed by the linear stochasticequation [29] [15]

xk = Axkminus1 +Bukminus1 + wkminus1 (2)

based on a measurement zk isin Rm given as

zk = Hxk + vk (3)

where wk vk are random variables which represent process noise and measurement noise and arenormally distributed with zero mean p(wk) sim N(0 Q) p(vk) sim N(0 R) Q and R are the processand measurement noise covariance matrices The model used here consists of two state variablesx = (a dadt) with a the altitude (above ground) Later the model was extended to include d2adtso as to facilitate incorporation of accelerometer measurements One problem with the real sensorswas a clear deviation of the measurement noise from the assumed normal distribution and had tobe corrected for in preprocessing

414 PID controller

The Kalman lter state estimate can nally be used as the input to a PID throttle controller ThePID model used is a FOPDT integrating model The second input to the controller module is thesetpoint which can be set in the simulation via keyboard- or network-input to the application Therst working PID parametrisation was arrived at through manual tuning which is cumbersome andgives suboptimal results

415 Evolutionary parameter tuning

To prove the concept of using online learning within simulation at least the PID parameters wereoptimised using evolutionary strategies [22] [26] The tness function for this experiment wasconceivably simple chosen as

f(i) =

Nsum0

|xset minus xik| (4)

with individual i (a tuple (P ID)) setpoint xset the experiments duration in time steps N andthe altitude xik at time step k resulting from execution of controller i This stage involved setting upthe system so that simulation state and model parametrisation (the P I and D coecients) could

19

be controlled programmatically It was realised over a UDPIP connection between crrcsim andthe external simctrl control shell 21 implemented in the Python language 22 The results of theexperiment have been presented in [10]

42 MKcom2

MKcom short for MikroKopter communication tool was designed as a minimal software layer tosit on top of the UART communication link to the main ight board It provides a console baseduser interface for activation and conguration of a set of thin control functions and can act as agateway between the FC and a CMUcam MKcom functions can send commands to the FC andincoming UART packets are dispatched to the appropriate message handler This tool implementedthe modied MK message set

The setup was used as the basis for prototyping several versions of the control loop structureoutlined in Figures 12 and 13 The internal organisation of these implementations can be seenin Figure 14 Three dierent controller cores were realised which incrementally incorporated moremeasurement channels heuristic detail and safety hooks The detailed ow structure of the controllerdesign will be outlined below The update rate and execution timings are dictated by the arrivalof the measurement vector from the FC Auxiliary sensors were integrated asynchronously into themain loop A custom groundstation for state logging and realtime plotting was connected to thenetwork downlink indicated in the diagram

421 MKcom2 Flow structure

On startup a request for debug structure emission is sent manually from the mkcom shell to the FCwith the debug n command where n is the desired sampling interval in milliseconds An examplesession excerpt looks (slightly beautied) as follows (`gt indicates the shells command prompt `is the startsign of the MK protocol strings starting with ` is the raw ascii data going over thewire)gt debug 100

tx bdV ===Ds

gt

rxbuf 93 bD===IgtpU gtomgtS=xTyf=DL|pA= gt===Kl|Lnx=mL=I===i=BM|| oXfT_UrePI=T]=gt==E=|l|

L=IE||y===Y=qM

_DebugOut_ 1804 310 203 854 -843 420 -49 49 4

2 -21-1016 123 828 828 0 11 21

-1-5850 9822 -24267 51 94 1 2 -2

207 706 -1 0 7

rxbuf 93 bD===ggtpi gtm=gtT=oxzd]DL|o===m=A=Kl|ALnx=mL=I===E=m=== KxYSourePI=T]====A===

L=IM||y===Y=nf

_DebugOut_ 1834 315 192 855 -722 414 -49 32 3

4 -21-1008 123 828 828 0 2 15

0 -897811867-24267 51 94 0 1 0

207 708 -1 0 7

gt debug 0

tx bd====DZ

gt

21httpwww2informatikhu-berlinde~obertholQK22Python Language httpwwwpythonorg

20

The debug vector is populated in the FC where element positions correspond with value typesIt includes IMU data manual control input from the RC and the barometer as well as systemstatus values such as battery voltage RSSI value ampc Depending on the setup it can include thereading from the sonar as well If the actual controller is activated with eggt ac3 1

kal_cv_init DP 3 MP 5 CP 0

gt

the controller evaluation function is executed upon each arrival of a debug packet Of coursesome information is retained across calls After computation has nished an extctrl (Externalcontrol) structure is populated and sent back to the FC Aditional measurements such as from anInfraRed Ranger (IRR) are integrated in an asynchronous manner from multiple threads Severalparameters such as the altitude setpoint PID values bias ampc can also be set from the text based userinterface While this works quite well in principle and did achieve good performance modularityand extensibility were not an initial design goal This led to another iteration of the same designwithin the MAVHUB framework which will be described in the next subsection

IO Channels UART TWI UI Network

HAL threads FC-RX Expansion Ctrl Sonar Shell

Processing Controller

mkcom2

Figure 14 Mkcom2 ow-graph

43 Heuristically tuned altitude control software

The vague vision of the overall architecture that is pursued here is that of several concurring moduleswhich are summed in a cooperative time-dependent manner and where each module is responsiblefor various behavioural aspects [1] To ease prototyping and testing of components the structurehas to be kept exible extensible and dynamically recongurable This has to be considered in theoverall onboard software design In order to illustrate this requirement the ow of information andthe interaction with additional behavioural modules will be described in more detail in the followingparagraphs References will be made to several modules operating within the MAVHUB frameworkthe basics of which are described elsewhere [25]

431 Data acquisition

First the controlware has to collect all sensory information from possibly heterogenous sourcesThese include 6 - 9 channels of IMU data (depending on IMU type) a barometric measurementseveral range sensors as well as optical sensors (cameras) and of course any other sensor which is

21

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

1500

2000

Time [s]

Value

throttle

uss_meas

k_s0

Figure 15 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m aboveground The dashed line is the raw sonar range value the solid black line is the estimate uponwhich the PID controller acts The solid green line in the lower part of the plot is the controlleroutput value which is sent to the actuator

available or desired Heterogeneity pertains to hardware channels update rates and data formatsIn MAVHUB there are two main channels if information ow One is the protocol stack whichtransmits volatile incoming messages to all active modules (apps) The other is a shared memoryarea where data can be deposited by any active process In the setup considered here FC data(including IMU barometer and possibly sonar) and intermediate internal data travel on the stackSensors connected via a two-wire bus are operated by sensor drivers and measurements are put intothe shared memory The desired result of this step is to be able to operate on a homogenous vectorof input signals within the main control loop

432 Preprocessing

Subsequent to acquisition each sensory channel is individually preprocessed according to the pe-culiarities of sensor principle and connection mode Preprocessing mostly consists of linearisationunit conversion (inverting the sensor characteristic) and several kinds of heuristic validation

Linearisation For this particular setup linearisation only has to be done for the IRRs Theseare analogue sensors and the output voltage is related to the distance s measured via u(t) = 1

s(t) An example sensor characteristic is displayed in Figure 16 For the dierent subtypes of the Sharpsensors an individually parameterised procedure has to be performed as described by eg Acroname

22

Robotics in [23] if the sensors are processed on a metric basis If the Sharp sensors are driven atthe recommended supply voltage of 5V using the datasheet specications has proven sucientlyaccurate An example script for determining the parameters from given calibration data is suppliedon this reports supplementary website 22

Unit conversion The diverse units of sensor data have to be explicitly converted to units conve-nient for later steps in the calculation in particular sensor fusion with the Kalman lter For thealtitude measurements these are metersminus3 so ADC-units or time-of-ight measurements have to beconverted to millimeters for the analog sensors (barometer accelerometer infrared) and the sonarsensor repsectively This simply amounts to a multiplicative factor

Validation Heuristic sensor data validation has to be done for all types of rangers as well as for thebarometric sensor The spurious readings these sensors produce are of dierent types though Theinfrared rangers display ambigouity beyond the lower limit of the operating ranges see Figure 16For the GP2D120 which can sense the smallest ranges of all sensors this can be mostly neglectedsince the minimal sensing range can hardly be reached due to the mechanical conguration Forall the other sensors output is surpressed when the GP2D120 is active At the upper limit of theIRRs operating range the output is surpressed when a suitable threshold is reached The followingcode example illustrates this where sensor channel number three is the close range IRR

if(in_range(sensors [3] first llim ulim))

valid = 10

else

valid = 00

sensors [3] second = (fir[3]-gtcalc(valid) gt= 099) 1 0

Surpression is realised by setting appropriate values in the measurement transform matrix H(t)of the Kalman lter Alternatively this could be done by generating suitable variances for therespective sensors in the measurement covariance matrix R(t) Driving the IRRs at 33V works butreduces the usable range In addition the IRR sensor measurements are dependent on the groundsurfaces some of which eg an oce carpet can result in erratic results

The ultrasonic sensor is susceptive to dierent kinds of spurious readings caused by late echoesThis happens both when very close to an object or surface or when far away that is beyond theupper limit of measurable distances The validation strategy employed is to set hard empiricallower and upper limits for values as for the IRRs and limiting the maximum dierence betweentwo consecutive values based on assumptions about the maximum velocity An example session isillustrated in Figure 18

Finally the barometer is sensitive to acceleration which has to be accounted for The sensorbehaviour is displayed in Figure 19 The empirical corrections read

BARO (pre [1] correct from accel -z (pre [2])

pre [1] first -= (005 pre [2] first)

The validition process in general produces one new signal per channel to be used later in theprocess for setting Kalman lter matrix values One remaining problem here is the channel cross-dependency

23

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 12: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

Direction Code Command Arguments

Inb Submit external control extctrl structc GyroBaro neutral Noned Request debug vector Update interval or None for one-om Start motors Nonen Kill motors None

OutD Debug vector 32 int16 values

Table 2 Five most important HUCH commands for external control of the modied MK-FC

332 Modications

Software The HUCH group has developed various extensions and modications to the platformOne of these is an expansion of the external control interface see Table 2 via the UART a corre-sponding groundstation (mcut) and control software (mktool) These are the basis for most of thework described in the remaining part of this text

The FlightCtrl microcontroller rmware was modied (HUCH variant) initially based on killa-gregs rewrite of the original rmware and implements among other things the extended communi-cation protocol higher UART baudrates TWI sensor integration and several more items 14 Thereexists a tool 15 to realise realtime display and plotting of debug variables ashing of MikroKopterrmware with embedded avrdude code parameter editing and motor testing The MKcom pro-gramm was initially developed for using a CMUcam to control the MikroKopter from vision inputIt features the basic FC communication stack and a control console This last item served as thebasis of the rst prototype of a Linux based altitude control At the time of writing develop-ment of these tools has been abandoned in favor of Micro Aerial Vehicle Humboldt Universitaumlt zuBerlin (MAVHUB) which is described in more detail elsewhere [25]

Computing hardware To overcome the severe restrictions of the Atmel ATMega644 being usedon the FC it is necessary to attach additional processing hardware Stating it more simply a singlemicrocontroller clearly is not suitable for any kind of slightly more demanding processing For thispurpose to date dierent single board systems have been used the Gumstix Verdex Pro 16 andBeagleboard variants 17 as can be seen in the gures 6 and 7 Several other options are availableand could be utilised in the future as our approach is construed exible in this regard Working ona Linux system provides a huge advantage in abstracting the algorithms from the hardware TheLinux system is connected to the FlightCtrl via the UART port In order to achieve a sampling rateof 100 Hz a baudrate of 230400 kbaud needs to be set on this connection The DebugOut messagestructure counts 95 bytes on the wire The motor command takes up 22 bytes giving 117 bytes forone sense-act cycle At the given channel capacity (25600 bytes per second) this gives approximately

14HUCH FlightCtrl 071i httpkoroinformatikhu-berlindeqkdownloadsV071i_huch-code_motodrone09targz

15mcut httpkoroinformatikhu-berlindeqkdownloadsmcuttargz16Gumstix Verdex Pro httpwwwgumstixcomproductverdex-pro17Beagleboard httpwwwbeagleboardorg

12

218 full cycles per second under optimal conditions and should be sucient for processing at 100Hz There are problems with nding higher baudrates that are supported on both sides of theconnection due to the 20 MHz clocking of the microcontroller

(a) Verdex View 1 (b) Verdex View 2

Figure 6 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below andthe expansion board on above On top is a USB WiFi dongle

A custom ATMega based ADC expansion board is acting as a generic analog data aqcisitiondevice Analog measurements are multiplexed and transmitted down a Two Wire Interface (TWI)link to the main control COM In a dierent setup an Arduino Mini was substituted for the customboard

Sensors For altitude measurement three dierent sensors were added to the setup A barometricpressure sensor is already provided for in the vendor board design This sensor is quite noisy butcovers a large range of measurement When close to the ground range sensors can be used tomeasure the distance Of this type we used a Devantech SRF02 sonic range nder This sensorhas an integrated microcontroller that does time-of-ight calculations for an ultrasonic pulse andtransmits the result digitally over a two wire interface (TWI) The speed of sound vs the actualdistance determine the maximum update frequency In our experiments these were xed at a rateof approximately 50 Hz In addition we attached two Sharp type infrared rangers (GP2Y0A02YKGP2D120) to the robot These output an analog voltage inversely proportional to the distancemeasured They are connected to the expansion board which also transmits updates via TWI butat a rate of 100 Hz The physical conguration of the range sensors is depicted in Figure 8

13

Figure 7 The electronic stack on this copter consists of (in ascending order) FC Power and UARTbreakout Beagle breakout and Arduino Mini mount BeagleBoard and USB WiFi Dongle

333 Physical system

As has been described above the FC can be given actuation commands via both the RC and UARTinterfaces in the form of the four-element vector 1 The SBC used in this particular conguration isthe Gumstix Verdex Pro X6LP The gumstix receives its power supply of 5V DC from the FC andtalks to it over the FFUART without additional level converters The hardware component setupis depicted schematically in Figure 9 On the left hand side of the diagram the base MikroKoptersetup is seen with the FlightCtrl RC receiver and the four ESCs On the right hand side theVerdex and custom sensor board are situated realising highlevel control and UDPIP link to thegroundstation over WiFi For the operation of a second onboard SBC the Beagleboard in Figure 9an additional voltage controller had to be used between the 12V DC rail and the Beagleboard powersupply socket

OpenEmbedded The current gumstix system software is provided via the Aringngstroumlm 18 distri-bution which is based on OpenEmbedded 19 The gumstix overlay provides Linux kernel versions2621 and 2631 Unfortunately the driver for the gumstix onboard WLAN hardware (netvx boardw a Marvell cf25 chip) changed between those versions and the one in 2631 refuses to actually

18Angstrom Distribution httpwwwangstrom-distributionorg19OpenEmbedded httpwwwopenembeddedorg

14

Figure 8 Range sensors attached to frame

RC receiver Onboard electronics

BL1 Expansion Board

BL4 FlightCtrl BL3

BL2 Gumstix

Camera BeagleBoard

TWI

UART

TWI

Wi

LAN

USB

Figure 9 Basic HUCH onboard electronics The left hand region of the picture consisting of receiverFC and brushless motor controllers BL1minus4 represents the standard MK setup while the right handregion represents HUCH additions

work with our hardware so a dierent solution had to be found Fortunately here the USB sub-system works well out of the box and standard USB WLAN hardware could be used to set up thelink Running the system o an SD-card as well as TWI (I2C) support in Linux work well Onemore aspect of the WLAN setup is worth noting though It was desired to realise the wireless linkto the onboard Linux in Ad-Hoc mode for two reasons The rst is reduced startup time when usingAd-Hoc mode the second is independence of access point infrastructure In this way the minimalFR groundstation conguration can be operated in a more mobile manner In principle one of thenodes could be operated in Master mode but this is not supported by all hardware

Once the live Linux system and cross-compilation environment was up and running the MKcom

15

software provided the basis for further work on controller implementation Looking at the Linuxsystem at this point the following view presents itself in Figure 10

Gumstix

AringngstroumlmLinux 2631 SD

UIShell mktool wlan0

devttyS1 devi2c-0

FC Exp Groundstation

RxTx wires

Wireless link

Figure 10 Basic Linux setup

4 Experiments

41 Basic structural design through simulation

Initially the problem of altitude control was analysed in simulation To that end a simple con-troller was realised within the crrcsim 20 RC model simulator There are basically two possiblemethodological approaches to setting up a simulation for a model helicopter One is the derivationof the model from rst principles and implementation from scratch The other is building uponexisting if simplifying solutions that are practically usable and open for modication

A moderately physically realistic model of a quadrotor aerial system is governed by a nontrivialnonlinear dierential equation [3 pg 155] [4] Much microscopic detail can be added for furtherrenement as the need arises Such details are discussed to some extent in [14] and [8] In the near-hover ight regime the system behaves quasi-linearly but at more extreme velocities and attitudesthe increasing impact of several nonlinear eects such as blade apping vortex ring states orforward translational lift would have to be considered For our purposes these eects have so farbeen neglected but could in princpiple be incorporated into the model

Circumventing the necessity of model derivation and implementation the second approach waschosen In particular the existing real-time ready crrcsim [7] RC-model simulator software wasmodied to conduct the initial experiments This was particularly facilitated by the prior work ofJens W Wulf who implemented a quadrotor model and internal controller substructures for thissimulation framework [32] A screenshot of the Wulf-model ying in the modied simulation in canbe seen in Figure 11 crrcsim comes with an internal controller architecture that realises dierent

20Charles River Radio Controllers Simulation httpcrrcsimberliosde

16

attitude controllers The software originally is designed to interface manual control hardware suchas RC transmitters joysticks and such to the simulation engine It was modied to implementadditional controllers detailed state information output for plotting and analysis and networkedcontrol of the simulation engine A drawback of crrcsim is its monolithic architecture For futurework the core simulation engine would have to be separated from the render engine Alternativelythe PPZ approach could be used as a drop-in replacement

Figure 11 Simulation screenshot The helicopter model landscape and text console are part ofcrrcsim The actual debugging output that can be seen in the console is part of custom modications

411 Closed loop

The basic structure of the full control loop is displayed in Figure 12 The control module embeddedin the loop is a Single-Input Single-Output (SISO) type controller The actuating variable undercontrol is thrust which eects overall lift (see above) while the other three components are mostlycontrolled manually during the experiments The input to the controller is the current altitudeestimate The estimation process potentially has to consider multiple measurements which have tobe fused into a single representation

412 Measurements

In simulation global knowledge of the world- (and agent-) state is available and all system variablesare immediatly accessible This allows to use a simplied signal-ow structure which is depicted in

17

Measurements

z0

z1 Kalman lter Controller

Fusion Estimate PID System

znminus1

zn

throttle

Behaviour

setpoint

Figure 12 Controller structure with measurement branch

gure 13 In order for the controller to be structurally transferable to the real hardware system thespecic sensor conguration has to be modelled within the simulator This included preparationof IMU data by tapping the Flight Dynamics Model (FDM) module and basic modelling of therespective characteristics of the barometric and ultrasonic range sensors which were in use on thehelicopter at that time In the case of the barometer this meant the addition of white gaussiannoise A slow drift which can be observed on the real sensor due to slow air-pressure changes wasneglected For the ultrasonic range sensor the timing characteristic that is the maximum updaterate dependent on distance measured was emulated The information thus synthesized was fed intoa Kalman lter for further processing

Controller

PID Systemthrottle

Flight dynamics model

setpoint

Figure 13 Simplied controller structure

413 Sensor fusion

Sensor fusion is a problem class on its own The base intent is to derive an estimate of a systemstate variable from multiple measurements that is more reliable than it would be by using only asingle measurement There are several approaches which have been developed over the last decadesand which could be employed for this task The complementary lter approach can be chosen if the

18

sensors are aected by suciently dierent kinds of noise and thus eg spectrally complementarylters can be used on dierent measurement channels which are then linearily combined into a singlevalue Probably the most commonly used techniques are the linear Kalman lter and its nonlinearvariants Other methods are nonexhaustively Bayesian strategies such as Particle lters H-infinlters or neural networks A linear Kalman lter was chosen in the current setup for the reasonthat the lter and its characteristics are well documented and the implementation is straightforwardboth from scratch and even more so using matrix algebra libraries such as OpenCV The basic ltertask is to estimate the state xk isin Rn of a discrete time system governed by the linear stochasticequation [29] [15]

xk = Axkminus1 +Bukminus1 + wkminus1 (2)

based on a measurement zk isin Rm given as

zk = Hxk + vk (3)

where wk vk are random variables which represent process noise and measurement noise and arenormally distributed with zero mean p(wk) sim N(0 Q) p(vk) sim N(0 R) Q and R are the processand measurement noise covariance matrices The model used here consists of two state variablesx = (a dadt) with a the altitude (above ground) Later the model was extended to include d2adtso as to facilitate incorporation of accelerometer measurements One problem with the real sensorswas a clear deviation of the measurement noise from the assumed normal distribution and had tobe corrected for in preprocessing

414 PID controller

The Kalman lter state estimate can nally be used as the input to a PID throttle controller ThePID model used is a FOPDT integrating model The second input to the controller module is thesetpoint which can be set in the simulation via keyboard- or network-input to the application Therst working PID parametrisation was arrived at through manual tuning which is cumbersome andgives suboptimal results

415 Evolutionary parameter tuning

To prove the concept of using online learning within simulation at least the PID parameters wereoptimised using evolutionary strategies [22] [26] The tness function for this experiment wasconceivably simple chosen as

f(i) =

Nsum0

|xset minus xik| (4)

with individual i (a tuple (P ID)) setpoint xset the experiments duration in time steps N andthe altitude xik at time step k resulting from execution of controller i This stage involved setting upthe system so that simulation state and model parametrisation (the P I and D coecients) could

19

be controlled programmatically It was realised over a UDPIP connection between crrcsim andthe external simctrl control shell 21 implemented in the Python language 22 The results of theexperiment have been presented in [10]

42 MKcom2

MKcom short for MikroKopter communication tool was designed as a minimal software layer tosit on top of the UART communication link to the main ight board It provides a console baseduser interface for activation and conguration of a set of thin control functions and can act as agateway between the FC and a CMUcam MKcom functions can send commands to the FC andincoming UART packets are dispatched to the appropriate message handler This tool implementedthe modied MK message set

The setup was used as the basis for prototyping several versions of the control loop structureoutlined in Figures 12 and 13 The internal organisation of these implementations can be seenin Figure 14 Three dierent controller cores were realised which incrementally incorporated moremeasurement channels heuristic detail and safety hooks The detailed ow structure of the controllerdesign will be outlined below The update rate and execution timings are dictated by the arrivalof the measurement vector from the FC Auxiliary sensors were integrated asynchronously into themain loop A custom groundstation for state logging and realtime plotting was connected to thenetwork downlink indicated in the diagram

421 MKcom2 Flow structure

On startup a request for debug structure emission is sent manually from the mkcom shell to the FCwith the debug n command where n is the desired sampling interval in milliseconds An examplesession excerpt looks (slightly beautied) as follows (`gt indicates the shells command prompt `is the startsign of the MK protocol strings starting with ` is the raw ascii data going over thewire)gt debug 100

tx bdV ===Ds

gt

rxbuf 93 bD===IgtpU gtomgtS=xTyf=DL|pA= gt===Kl|Lnx=mL=I===i=BM|| oXfT_UrePI=T]=gt==E=|l|

L=IE||y===Y=qM

_DebugOut_ 1804 310 203 854 -843 420 -49 49 4

2 -21-1016 123 828 828 0 11 21

-1-5850 9822 -24267 51 94 1 2 -2

207 706 -1 0 7

rxbuf 93 bD===ggtpi gtm=gtT=oxzd]DL|o===m=A=Kl|ALnx=mL=I===E=m=== KxYSourePI=T]====A===

L=IM||y===Y=nf

_DebugOut_ 1834 315 192 855 -722 414 -49 32 3

4 -21-1008 123 828 828 0 2 15

0 -897811867-24267 51 94 0 1 0

207 708 -1 0 7

gt debug 0

tx bd====DZ

gt

21httpwww2informatikhu-berlinde~obertholQK22Python Language httpwwwpythonorg

20

The debug vector is populated in the FC where element positions correspond with value typesIt includes IMU data manual control input from the RC and the barometer as well as systemstatus values such as battery voltage RSSI value ampc Depending on the setup it can include thereading from the sonar as well If the actual controller is activated with eggt ac3 1

kal_cv_init DP 3 MP 5 CP 0

gt

the controller evaluation function is executed upon each arrival of a debug packet Of coursesome information is retained across calls After computation has nished an extctrl (Externalcontrol) structure is populated and sent back to the FC Aditional measurements such as from anInfraRed Ranger (IRR) are integrated in an asynchronous manner from multiple threads Severalparameters such as the altitude setpoint PID values bias ampc can also be set from the text based userinterface While this works quite well in principle and did achieve good performance modularityand extensibility were not an initial design goal This led to another iteration of the same designwithin the MAVHUB framework which will be described in the next subsection

IO Channels UART TWI UI Network

HAL threads FC-RX Expansion Ctrl Sonar Shell

Processing Controller

mkcom2

Figure 14 Mkcom2 ow-graph

43 Heuristically tuned altitude control software

The vague vision of the overall architecture that is pursued here is that of several concurring moduleswhich are summed in a cooperative time-dependent manner and where each module is responsiblefor various behavioural aspects [1] To ease prototyping and testing of components the structurehas to be kept exible extensible and dynamically recongurable This has to be considered in theoverall onboard software design In order to illustrate this requirement the ow of information andthe interaction with additional behavioural modules will be described in more detail in the followingparagraphs References will be made to several modules operating within the MAVHUB frameworkthe basics of which are described elsewhere [25]

431 Data acquisition

First the controlware has to collect all sensory information from possibly heterogenous sourcesThese include 6 - 9 channels of IMU data (depending on IMU type) a barometric measurementseveral range sensors as well as optical sensors (cameras) and of course any other sensor which is

21

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

1500

2000

Time [s]

Value

throttle

uss_meas

k_s0

Figure 15 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m aboveground The dashed line is the raw sonar range value the solid black line is the estimate uponwhich the PID controller acts The solid green line in the lower part of the plot is the controlleroutput value which is sent to the actuator

available or desired Heterogeneity pertains to hardware channels update rates and data formatsIn MAVHUB there are two main channels if information ow One is the protocol stack whichtransmits volatile incoming messages to all active modules (apps) The other is a shared memoryarea where data can be deposited by any active process In the setup considered here FC data(including IMU barometer and possibly sonar) and intermediate internal data travel on the stackSensors connected via a two-wire bus are operated by sensor drivers and measurements are put intothe shared memory The desired result of this step is to be able to operate on a homogenous vectorof input signals within the main control loop

432 Preprocessing

Subsequent to acquisition each sensory channel is individually preprocessed according to the pe-culiarities of sensor principle and connection mode Preprocessing mostly consists of linearisationunit conversion (inverting the sensor characteristic) and several kinds of heuristic validation

Linearisation For this particular setup linearisation only has to be done for the IRRs Theseare analogue sensors and the output voltage is related to the distance s measured via u(t) = 1

s(t) An example sensor characteristic is displayed in Figure 16 For the dierent subtypes of the Sharpsensors an individually parameterised procedure has to be performed as described by eg Acroname

22

Robotics in [23] if the sensors are processed on a metric basis If the Sharp sensors are driven atthe recommended supply voltage of 5V using the datasheet specications has proven sucientlyaccurate An example script for determining the parameters from given calibration data is suppliedon this reports supplementary website 22

Unit conversion The diverse units of sensor data have to be explicitly converted to units conve-nient for later steps in the calculation in particular sensor fusion with the Kalman lter For thealtitude measurements these are metersminus3 so ADC-units or time-of-ight measurements have to beconverted to millimeters for the analog sensors (barometer accelerometer infrared) and the sonarsensor repsectively This simply amounts to a multiplicative factor

Validation Heuristic sensor data validation has to be done for all types of rangers as well as for thebarometric sensor The spurious readings these sensors produce are of dierent types though Theinfrared rangers display ambigouity beyond the lower limit of the operating ranges see Figure 16For the GP2D120 which can sense the smallest ranges of all sensors this can be mostly neglectedsince the minimal sensing range can hardly be reached due to the mechanical conguration Forall the other sensors output is surpressed when the GP2D120 is active At the upper limit of theIRRs operating range the output is surpressed when a suitable threshold is reached The followingcode example illustrates this where sensor channel number three is the close range IRR

if(in_range(sensors [3] first llim ulim))

valid = 10

else

valid = 00

sensors [3] second = (fir[3]-gtcalc(valid) gt= 099) 1 0

Surpression is realised by setting appropriate values in the measurement transform matrix H(t)of the Kalman lter Alternatively this could be done by generating suitable variances for therespective sensors in the measurement covariance matrix R(t) Driving the IRRs at 33V works butreduces the usable range In addition the IRR sensor measurements are dependent on the groundsurfaces some of which eg an oce carpet can result in erratic results

The ultrasonic sensor is susceptive to dierent kinds of spurious readings caused by late echoesThis happens both when very close to an object or surface or when far away that is beyond theupper limit of measurable distances The validation strategy employed is to set hard empiricallower and upper limits for values as for the IRRs and limiting the maximum dierence betweentwo consecutive values based on assumptions about the maximum velocity An example session isillustrated in Figure 18

Finally the barometer is sensitive to acceleration which has to be accounted for The sensorbehaviour is displayed in Figure 19 The empirical corrections read

BARO (pre [1] correct from accel -z (pre [2])

pre [1] first -= (005 pre [2] first)

The validition process in general produces one new signal per channel to be used later in theprocess for setting Kalman lter matrix values One remaining problem here is the channel cross-dependency

23

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 13: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

218 full cycles per second under optimal conditions and should be sucient for processing at 100Hz There are problems with nding higher baudrates that are supported on both sides of theconnection due to the 20 MHz clocking of the microcontroller

(a) Verdex View 1 (b) Verdex View 2

Figure 6 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below andthe expansion board on above On top is a USB WiFi dongle

A custom ATMega based ADC expansion board is acting as a generic analog data aqcisitiondevice Analog measurements are multiplexed and transmitted down a Two Wire Interface (TWI)link to the main control COM In a dierent setup an Arduino Mini was substituted for the customboard

Sensors For altitude measurement three dierent sensors were added to the setup A barometricpressure sensor is already provided for in the vendor board design This sensor is quite noisy butcovers a large range of measurement When close to the ground range sensors can be used tomeasure the distance Of this type we used a Devantech SRF02 sonic range nder This sensorhas an integrated microcontroller that does time-of-ight calculations for an ultrasonic pulse andtransmits the result digitally over a two wire interface (TWI) The speed of sound vs the actualdistance determine the maximum update frequency In our experiments these were xed at a rateof approximately 50 Hz In addition we attached two Sharp type infrared rangers (GP2Y0A02YKGP2D120) to the robot These output an analog voltage inversely proportional to the distancemeasured They are connected to the expansion board which also transmits updates via TWI butat a rate of 100 Hz The physical conguration of the range sensors is depicted in Figure 8

13

Figure 7 The electronic stack on this copter consists of (in ascending order) FC Power and UARTbreakout Beagle breakout and Arduino Mini mount BeagleBoard and USB WiFi Dongle

333 Physical system

As has been described above the FC can be given actuation commands via both the RC and UARTinterfaces in the form of the four-element vector 1 The SBC used in this particular conguration isthe Gumstix Verdex Pro X6LP The gumstix receives its power supply of 5V DC from the FC andtalks to it over the FFUART without additional level converters The hardware component setupis depicted schematically in Figure 9 On the left hand side of the diagram the base MikroKoptersetup is seen with the FlightCtrl RC receiver and the four ESCs On the right hand side theVerdex and custom sensor board are situated realising highlevel control and UDPIP link to thegroundstation over WiFi For the operation of a second onboard SBC the Beagleboard in Figure 9an additional voltage controller had to be used between the 12V DC rail and the Beagleboard powersupply socket

OpenEmbedded The current gumstix system software is provided via the Aringngstroumlm 18 distri-bution which is based on OpenEmbedded 19 The gumstix overlay provides Linux kernel versions2621 and 2631 Unfortunately the driver for the gumstix onboard WLAN hardware (netvx boardw a Marvell cf25 chip) changed between those versions and the one in 2631 refuses to actually

18Angstrom Distribution httpwwwangstrom-distributionorg19OpenEmbedded httpwwwopenembeddedorg

14

Figure 8 Range sensors attached to frame

RC receiver Onboard electronics

BL1 Expansion Board

BL4 FlightCtrl BL3

BL2 Gumstix

Camera BeagleBoard

TWI

UART

TWI

Wi

LAN

USB

Figure 9 Basic HUCH onboard electronics The left hand region of the picture consisting of receiverFC and brushless motor controllers BL1minus4 represents the standard MK setup while the right handregion represents HUCH additions

work with our hardware so a dierent solution had to be found Fortunately here the USB sub-system works well out of the box and standard USB WLAN hardware could be used to set up thelink Running the system o an SD-card as well as TWI (I2C) support in Linux work well Onemore aspect of the WLAN setup is worth noting though It was desired to realise the wireless linkto the onboard Linux in Ad-Hoc mode for two reasons The rst is reduced startup time when usingAd-Hoc mode the second is independence of access point infrastructure In this way the minimalFR groundstation conguration can be operated in a more mobile manner In principle one of thenodes could be operated in Master mode but this is not supported by all hardware

Once the live Linux system and cross-compilation environment was up and running the MKcom

15

software provided the basis for further work on controller implementation Looking at the Linuxsystem at this point the following view presents itself in Figure 10

Gumstix

AringngstroumlmLinux 2631 SD

UIShell mktool wlan0

devttyS1 devi2c-0

FC Exp Groundstation

RxTx wires

Wireless link

Figure 10 Basic Linux setup

4 Experiments

41 Basic structural design through simulation

Initially the problem of altitude control was analysed in simulation To that end a simple con-troller was realised within the crrcsim 20 RC model simulator There are basically two possiblemethodological approaches to setting up a simulation for a model helicopter One is the derivationof the model from rst principles and implementation from scratch The other is building uponexisting if simplifying solutions that are practically usable and open for modication

A moderately physically realistic model of a quadrotor aerial system is governed by a nontrivialnonlinear dierential equation [3 pg 155] [4] Much microscopic detail can be added for furtherrenement as the need arises Such details are discussed to some extent in [14] and [8] In the near-hover ight regime the system behaves quasi-linearly but at more extreme velocities and attitudesthe increasing impact of several nonlinear eects such as blade apping vortex ring states orforward translational lift would have to be considered For our purposes these eects have so farbeen neglected but could in princpiple be incorporated into the model

Circumventing the necessity of model derivation and implementation the second approach waschosen In particular the existing real-time ready crrcsim [7] RC-model simulator software wasmodied to conduct the initial experiments This was particularly facilitated by the prior work ofJens W Wulf who implemented a quadrotor model and internal controller substructures for thissimulation framework [32] A screenshot of the Wulf-model ying in the modied simulation in canbe seen in Figure 11 crrcsim comes with an internal controller architecture that realises dierent

20Charles River Radio Controllers Simulation httpcrrcsimberliosde

16

attitude controllers The software originally is designed to interface manual control hardware suchas RC transmitters joysticks and such to the simulation engine It was modied to implementadditional controllers detailed state information output for plotting and analysis and networkedcontrol of the simulation engine A drawback of crrcsim is its monolithic architecture For futurework the core simulation engine would have to be separated from the render engine Alternativelythe PPZ approach could be used as a drop-in replacement

Figure 11 Simulation screenshot The helicopter model landscape and text console are part ofcrrcsim The actual debugging output that can be seen in the console is part of custom modications

411 Closed loop

The basic structure of the full control loop is displayed in Figure 12 The control module embeddedin the loop is a Single-Input Single-Output (SISO) type controller The actuating variable undercontrol is thrust which eects overall lift (see above) while the other three components are mostlycontrolled manually during the experiments The input to the controller is the current altitudeestimate The estimation process potentially has to consider multiple measurements which have tobe fused into a single representation

412 Measurements

In simulation global knowledge of the world- (and agent-) state is available and all system variablesare immediatly accessible This allows to use a simplied signal-ow structure which is depicted in

17

Measurements

z0

z1 Kalman lter Controller

Fusion Estimate PID System

znminus1

zn

throttle

Behaviour

setpoint

Figure 12 Controller structure with measurement branch

gure 13 In order for the controller to be structurally transferable to the real hardware system thespecic sensor conguration has to be modelled within the simulator This included preparationof IMU data by tapping the Flight Dynamics Model (FDM) module and basic modelling of therespective characteristics of the barometric and ultrasonic range sensors which were in use on thehelicopter at that time In the case of the barometer this meant the addition of white gaussiannoise A slow drift which can be observed on the real sensor due to slow air-pressure changes wasneglected For the ultrasonic range sensor the timing characteristic that is the maximum updaterate dependent on distance measured was emulated The information thus synthesized was fed intoa Kalman lter for further processing

Controller

PID Systemthrottle

Flight dynamics model

setpoint

Figure 13 Simplied controller structure

413 Sensor fusion

Sensor fusion is a problem class on its own The base intent is to derive an estimate of a systemstate variable from multiple measurements that is more reliable than it would be by using only asingle measurement There are several approaches which have been developed over the last decadesand which could be employed for this task The complementary lter approach can be chosen if the

18

sensors are aected by suciently dierent kinds of noise and thus eg spectrally complementarylters can be used on dierent measurement channels which are then linearily combined into a singlevalue Probably the most commonly used techniques are the linear Kalman lter and its nonlinearvariants Other methods are nonexhaustively Bayesian strategies such as Particle lters H-infinlters or neural networks A linear Kalman lter was chosen in the current setup for the reasonthat the lter and its characteristics are well documented and the implementation is straightforwardboth from scratch and even more so using matrix algebra libraries such as OpenCV The basic ltertask is to estimate the state xk isin Rn of a discrete time system governed by the linear stochasticequation [29] [15]

xk = Axkminus1 +Bukminus1 + wkminus1 (2)

based on a measurement zk isin Rm given as

zk = Hxk + vk (3)

where wk vk are random variables which represent process noise and measurement noise and arenormally distributed with zero mean p(wk) sim N(0 Q) p(vk) sim N(0 R) Q and R are the processand measurement noise covariance matrices The model used here consists of two state variablesx = (a dadt) with a the altitude (above ground) Later the model was extended to include d2adtso as to facilitate incorporation of accelerometer measurements One problem with the real sensorswas a clear deviation of the measurement noise from the assumed normal distribution and had tobe corrected for in preprocessing

414 PID controller

The Kalman lter state estimate can nally be used as the input to a PID throttle controller ThePID model used is a FOPDT integrating model The second input to the controller module is thesetpoint which can be set in the simulation via keyboard- or network-input to the application Therst working PID parametrisation was arrived at through manual tuning which is cumbersome andgives suboptimal results

415 Evolutionary parameter tuning

To prove the concept of using online learning within simulation at least the PID parameters wereoptimised using evolutionary strategies [22] [26] The tness function for this experiment wasconceivably simple chosen as

f(i) =

Nsum0

|xset minus xik| (4)

with individual i (a tuple (P ID)) setpoint xset the experiments duration in time steps N andthe altitude xik at time step k resulting from execution of controller i This stage involved setting upthe system so that simulation state and model parametrisation (the P I and D coecients) could

19

be controlled programmatically It was realised over a UDPIP connection between crrcsim andthe external simctrl control shell 21 implemented in the Python language 22 The results of theexperiment have been presented in [10]

42 MKcom2

MKcom short for MikroKopter communication tool was designed as a minimal software layer tosit on top of the UART communication link to the main ight board It provides a console baseduser interface for activation and conguration of a set of thin control functions and can act as agateway between the FC and a CMUcam MKcom functions can send commands to the FC andincoming UART packets are dispatched to the appropriate message handler This tool implementedthe modied MK message set

The setup was used as the basis for prototyping several versions of the control loop structureoutlined in Figures 12 and 13 The internal organisation of these implementations can be seenin Figure 14 Three dierent controller cores were realised which incrementally incorporated moremeasurement channels heuristic detail and safety hooks The detailed ow structure of the controllerdesign will be outlined below The update rate and execution timings are dictated by the arrivalof the measurement vector from the FC Auxiliary sensors were integrated asynchronously into themain loop A custom groundstation for state logging and realtime plotting was connected to thenetwork downlink indicated in the diagram

421 MKcom2 Flow structure

On startup a request for debug structure emission is sent manually from the mkcom shell to the FCwith the debug n command where n is the desired sampling interval in milliseconds An examplesession excerpt looks (slightly beautied) as follows (`gt indicates the shells command prompt `is the startsign of the MK protocol strings starting with ` is the raw ascii data going over thewire)gt debug 100

tx bdV ===Ds

gt

rxbuf 93 bD===IgtpU gtomgtS=xTyf=DL|pA= gt===Kl|Lnx=mL=I===i=BM|| oXfT_UrePI=T]=gt==E=|l|

L=IE||y===Y=qM

_DebugOut_ 1804 310 203 854 -843 420 -49 49 4

2 -21-1016 123 828 828 0 11 21

-1-5850 9822 -24267 51 94 1 2 -2

207 706 -1 0 7

rxbuf 93 bD===ggtpi gtm=gtT=oxzd]DL|o===m=A=Kl|ALnx=mL=I===E=m=== KxYSourePI=T]====A===

L=IM||y===Y=nf

_DebugOut_ 1834 315 192 855 -722 414 -49 32 3

4 -21-1008 123 828 828 0 2 15

0 -897811867-24267 51 94 0 1 0

207 708 -1 0 7

gt debug 0

tx bd====DZ

gt

21httpwww2informatikhu-berlinde~obertholQK22Python Language httpwwwpythonorg

20

The debug vector is populated in the FC where element positions correspond with value typesIt includes IMU data manual control input from the RC and the barometer as well as systemstatus values such as battery voltage RSSI value ampc Depending on the setup it can include thereading from the sonar as well If the actual controller is activated with eggt ac3 1

kal_cv_init DP 3 MP 5 CP 0

gt

the controller evaluation function is executed upon each arrival of a debug packet Of coursesome information is retained across calls After computation has nished an extctrl (Externalcontrol) structure is populated and sent back to the FC Aditional measurements such as from anInfraRed Ranger (IRR) are integrated in an asynchronous manner from multiple threads Severalparameters such as the altitude setpoint PID values bias ampc can also be set from the text based userinterface While this works quite well in principle and did achieve good performance modularityand extensibility were not an initial design goal This led to another iteration of the same designwithin the MAVHUB framework which will be described in the next subsection

IO Channels UART TWI UI Network

HAL threads FC-RX Expansion Ctrl Sonar Shell

Processing Controller

mkcom2

Figure 14 Mkcom2 ow-graph

43 Heuristically tuned altitude control software

The vague vision of the overall architecture that is pursued here is that of several concurring moduleswhich are summed in a cooperative time-dependent manner and where each module is responsiblefor various behavioural aspects [1] To ease prototyping and testing of components the structurehas to be kept exible extensible and dynamically recongurable This has to be considered in theoverall onboard software design In order to illustrate this requirement the ow of information andthe interaction with additional behavioural modules will be described in more detail in the followingparagraphs References will be made to several modules operating within the MAVHUB frameworkthe basics of which are described elsewhere [25]

431 Data acquisition

First the controlware has to collect all sensory information from possibly heterogenous sourcesThese include 6 - 9 channels of IMU data (depending on IMU type) a barometric measurementseveral range sensors as well as optical sensors (cameras) and of course any other sensor which is

21

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

1500

2000

Time [s]

Value

throttle

uss_meas

k_s0

Figure 15 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m aboveground The dashed line is the raw sonar range value the solid black line is the estimate uponwhich the PID controller acts The solid green line in the lower part of the plot is the controlleroutput value which is sent to the actuator

available or desired Heterogeneity pertains to hardware channels update rates and data formatsIn MAVHUB there are two main channels if information ow One is the protocol stack whichtransmits volatile incoming messages to all active modules (apps) The other is a shared memoryarea where data can be deposited by any active process In the setup considered here FC data(including IMU barometer and possibly sonar) and intermediate internal data travel on the stackSensors connected via a two-wire bus are operated by sensor drivers and measurements are put intothe shared memory The desired result of this step is to be able to operate on a homogenous vectorof input signals within the main control loop

432 Preprocessing

Subsequent to acquisition each sensory channel is individually preprocessed according to the pe-culiarities of sensor principle and connection mode Preprocessing mostly consists of linearisationunit conversion (inverting the sensor characteristic) and several kinds of heuristic validation

Linearisation For this particular setup linearisation only has to be done for the IRRs Theseare analogue sensors and the output voltage is related to the distance s measured via u(t) = 1

s(t) An example sensor characteristic is displayed in Figure 16 For the dierent subtypes of the Sharpsensors an individually parameterised procedure has to be performed as described by eg Acroname

22

Robotics in [23] if the sensors are processed on a metric basis If the Sharp sensors are driven atthe recommended supply voltage of 5V using the datasheet specications has proven sucientlyaccurate An example script for determining the parameters from given calibration data is suppliedon this reports supplementary website 22

Unit conversion The diverse units of sensor data have to be explicitly converted to units conve-nient for later steps in the calculation in particular sensor fusion with the Kalman lter For thealtitude measurements these are metersminus3 so ADC-units or time-of-ight measurements have to beconverted to millimeters for the analog sensors (barometer accelerometer infrared) and the sonarsensor repsectively This simply amounts to a multiplicative factor

Validation Heuristic sensor data validation has to be done for all types of rangers as well as for thebarometric sensor The spurious readings these sensors produce are of dierent types though Theinfrared rangers display ambigouity beyond the lower limit of the operating ranges see Figure 16For the GP2D120 which can sense the smallest ranges of all sensors this can be mostly neglectedsince the minimal sensing range can hardly be reached due to the mechanical conguration Forall the other sensors output is surpressed when the GP2D120 is active At the upper limit of theIRRs operating range the output is surpressed when a suitable threshold is reached The followingcode example illustrates this where sensor channel number three is the close range IRR

if(in_range(sensors [3] first llim ulim))

valid = 10

else

valid = 00

sensors [3] second = (fir[3]-gtcalc(valid) gt= 099) 1 0

Surpression is realised by setting appropriate values in the measurement transform matrix H(t)of the Kalman lter Alternatively this could be done by generating suitable variances for therespective sensors in the measurement covariance matrix R(t) Driving the IRRs at 33V works butreduces the usable range In addition the IRR sensor measurements are dependent on the groundsurfaces some of which eg an oce carpet can result in erratic results

The ultrasonic sensor is susceptive to dierent kinds of spurious readings caused by late echoesThis happens both when very close to an object or surface or when far away that is beyond theupper limit of measurable distances The validation strategy employed is to set hard empiricallower and upper limits for values as for the IRRs and limiting the maximum dierence betweentwo consecutive values based on assumptions about the maximum velocity An example session isillustrated in Figure 18

Finally the barometer is sensitive to acceleration which has to be accounted for The sensorbehaviour is displayed in Figure 19 The empirical corrections read

BARO (pre [1] correct from accel -z (pre [2])

pre [1] first -= (005 pre [2] first)

The validition process in general produces one new signal per channel to be used later in theprocess for setting Kalman lter matrix values One remaining problem here is the channel cross-dependency

23

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 14: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

Figure 7 The electronic stack on this copter consists of (in ascending order) FC Power and UARTbreakout Beagle breakout and Arduino Mini mount BeagleBoard and USB WiFi Dongle

333 Physical system

As has been described above the FC can be given actuation commands via both the RC and UARTinterfaces in the form of the four-element vector 1 The SBC used in this particular conguration isthe Gumstix Verdex Pro X6LP The gumstix receives its power supply of 5V DC from the FC andtalks to it over the FFUART without additional level converters The hardware component setupis depicted schematically in Figure 9 On the left hand side of the diagram the base MikroKoptersetup is seen with the FlightCtrl RC receiver and the four ESCs On the right hand side theVerdex and custom sensor board are situated realising highlevel control and UDPIP link to thegroundstation over WiFi For the operation of a second onboard SBC the Beagleboard in Figure 9an additional voltage controller had to be used between the 12V DC rail and the Beagleboard powersupply socket

OpenEmbedded The current gumstix system software is provided via the Aringngstroumlm 18 distri-bution which is based on OpenEmbedded 19 The gumstix overlay provides Linux kernel versions2621 and 2631 Unfortunately the driver for the gumstix onboard WLAN hardware (netvx boardw a Marvell cf25 chip) changed between those versions and the one in 2631 refuses to actually

18Angstrom Distribution httpwwwangstrom-distributionorg19OpenEmbedded httpwwwopenembeddedorg

14

Figure 8 Range sensors attached to frame

RC receiver Onboard electronics

BL1 Expansion Board

BL4 FlightCtrl BL3

BL2 Gumstix

Camera BeagleBoard

TWI

UART

TWI

Wi

LAN

USB

Figure 9 Basic HUCH onboard electronics The left hand region of the picture consisting of receiverFC and brushless motor controllers BL1minus4 represents the standard MK setup while the right handregion represents HUCH additions

work with our hardware so a dierent solution had to be found Fortunately here the USB sub-system works well out of the box and standard USB WLAN hardware could be used to set up thelink Running the system o an SD-card as well as TWI (I2C) support in Linux work well Onemore aspect of the WLAN setup is worth noting though It was desired to realise the wireless linkto the onboard Linux in Ad-Hoc mode for two reasons The rst is reduced startup time when usingAd-Hoc mode the second is independence of access point infrastructure In this way the minimalFR groundstation conguration can be operated in a more mobile manner In principle one of thenodes could be operated in Master mode but this is not supported by all hardware

Once the live Linux system and cross-compilation environment was up and running the MKcom

15

software provided the basis for further work on controller implementation Looking at the Linuxsystem at this point the following view presents itself in Figure 10

Gumstix

AringngstroumlmLinux 2631 SD

UIShell mktool wlan0

devttyS1 devi2c-0

FC Exp Groundstation

RxTx wires

Wireless link

Figure 10 Basic Linux setup

4 Experiments

41 Basic structural design through simulation

Initially the problem of altitude control was analysed in simulation To that end a simple con-troller was realised within the crrcsim 20 RC model simulator There are basically two possiblemethodological approaches to setting up a simulation for a model helicopter One is the derivationof the model from rst principles and implementation from scratch The other is building uponexisting if simplifying solutions that are practically usable and open for modication

A moderately physically realistic model of a quadrotor aerial system is governed by a nontrivialnonlinear dierential equation [3 pg 155] [4] Much microscopic detail can be added for furtherrenement as the need arises Such details are discussed to some extent in [14] and [8] In the near-hover ight regime the system behaves quasi-linearly but at more extreme velocities and attitudesthe increasing impact of several nonlinear eects such as blade apping vortex ring states orforward translational lift would have to be considered For our purposes these eects have so farbeen neglected but could in princpiple be incorporated into the model

Circumventing the necessity of model derivation and implementation the second approach waschosen In particular the existing real-time ready crrcsim [7] RC-model simulator software wasmodied to conduct the initial experiments This was particularly facilitated by the prior work ofJens W Wulf who implemented a quadrotor model and internal controller substructures for thissimulation framework [32] A screenshot of the Wulf-model ying in the modied simulation in canbe seen in Figure 11 crrcsim comes with an internal controller architecture that realises dierent

20Charles River Radio Controllers Simulation httpcrrcsimberliosde

16

attitude controllers The software originally is designed to interface manual control hardware suchas RC transmitters joysticks and such to the simulation engine It was modied to implementadditional controllers detailed state information output for plotting and analysis and networkedcontrol of the simulation engine A drawback of crrcsim is its monolithic architecture For futurework the core simulation engine would have to be separated from the render engine Alternativelythe PPZ approach could be used as a drop-in replacement

Figure 11 Simulation screenshot The helicopter model landscape and text console are part ofcrrcsim The actual debugging output that can be seen in the console is part of custom modications

411 Closed loop

The basic structure of the full control loop is displayed in Figure 12 The control module embeddedin the loop is a Single-Input Single-Output (SISO) type controller The actuating variable undercontrol is thrust which eects overall lift (see above) while the other three components are mostlycontrolled manually during the experiments The input to the controller is the current altitudeestimate The estimation process potentially has to consider multiple measurements which have tobe fused into a single representation

412 Measurements

In simulation global knowledge of the world- (and agent-) state is available and all system variablesare immediatly accessible This allows to use a simplied signal-ow structure which is depicted in

17

Measurements

z0

z1 Kalman lter Controller

Fusion Estimate PID System

znminus1

zn

throttle

Behaviour

setpoint

Figure 12 Controller structure with measurement branch

gure 13 In order for the controller to be structurally transferable to the real hardware system thespecic sensor conguration has to be modelled within the simulator This included preparationof IMU data by tapping the Flight Dynamics Model (FDM) module and basic modelling of therespective characteristics of the barometric and ultrasonic range sensors which were in use on thehelicopter at that time In the case of the barometer this meant the addition of white gaussiannoise A slow drift which can be observed on the real sensor due to slow air-pressure changes wasneglected For the ultrasonic range sensor the timing characteristic that is the maximum updaterate dependent on distance measured was emulated The information thus synthesized was fed intoa Kalman lter for further processing

Controller

PID Systemthrottle

Flight dynamics model

setpoint

Figure 13 Simplied controller structure

413 Sensor fusion

Sensor fusion is a problem class on its own The base intent is to derive an estimate of a systemstate variable from multiple measurements that is more reliable than it would be by using only asingle measurement There are several approaches which have been developed over the last decadesand which could be employed for this task The complementary lter approach can be chosen if the

18

sensors are aected by suciently dierent kinds of noise and thus eg spectrally complementarylters can be used on dierent measurement channels which are then linearily combined into a singlevalue Probably the most commonly used techniques are the linear Kalman lter and its nonlinearvariants Other methods are nonexhaustively Bayesian strategies such as Particle lters H-infinlters or neural networks A linear Kalman lter was chosen in the current setup for the reasonthat the lter and its characteristics are well documented and the implementation is straightforwardboth from scratch and even more so using matrix algebra libraries such as OpenCV The basic ltertask is to estimate the state xk isin Rn of a discrete time system governed by the linear stochasticequation [29] [15]

xk = Axkminus1 +Bukminus1 + wkminus1 (2)

based on a measurement zk isin Rm given as

zk = Hxk + vk (3)

where wk vk are random variables which represent process noise and measurement noise and arenormally distributed with zero mean p(wk) sim N(0 Q) p(vk) sim N(0 R) Q and R are the processand measurement noise covariance matrices The model used here consists of two state variablesx = (a dadt) with a the altitude (above ground) Later the model was extended to include d2adtso as to facilitate incorporation of accelerometer measurements One problem with the real sensorswas a clear deviation of the measurement noise from the assumed normal distribution and had tobe corrected for in preprocessing

414 PID controller

The Kalman lter state estimate can nally be used as the input to a PID throttle controller ThePID model used is a FOPDT integrating model The second input to the controller module is thesetpoint which can be set in the simulation via keyboard- or network-input to the application Therst working PID parametrisation was arrived at through manual tuning which is cumbersome andgives suboptimal results

415 Evolutionary parameter tuning

To prove the concept of using online learning within simulation at least the PID parameters wereoptimised using evolutionary strategies [22] [26] The tness function for this experiment wasconceivably simple chosen as

f(i) =

Nsum0

|xset minus xik| (4)

with individual i (a tuple (P ID)) setpoint xset the experiments duration in time steps N andthe altitude xik at time step k resulting from execution of controller i This stage involved setting upthe system so that simulation state and model parametrisation (the P I and D coecients) could

19

be controlled programmatically It was realised over a UDPIP connection between crrcsim andthe external simctrl control shell 21 implemented in the Python language 22 The results of theexperiment have been presented in [10]

42 MKcom2

MKcom short for MikroKopter communication tool was designed as a minimal software layer tosit on top of the UART communication link to the main ight board It provides a console baseduser interface for activation and conguration of a set of thin control functions and can act as agateway between the FC and a CMUcam MKcom functions can send commands to the FC andincoming UART packets are dispatched to the appropriate message handler This tool implementedthe modied MK message set

The setup was used as the basis for prototyping several versions of the control loop structureoutlined in Figures 12 and 13 The internal organisation of these implementations can be seenin Figure 14 Three dierent controller cores were realised which incrementally incorporated moremeasurement channels heuristic detail and safety hooks The detailed ow structure of the controllerdesign will be outlined below The update rate and execution timings are dictated by the arrivalof the measurement vector from the FC Auxiliary sensors were integrated asynchronously into themain loop A custom groundstation for state logging and realtime plotting was connected to thenetwork downlink indicated in the diagram

421 MKcom2 Flow structure

On startup a request for debug structure emission is sent manually from the mkcom shell to the FCwith the debug n command where n is the desired sampling interval in milliseconds An examplesession excerpt looks (slightly beautied) as follows (`gt indicates the shells command prompt `is the startsign of the MK protocol strings starting with ` is the raw ascii data going over thewire)gt debug 100

tx bdV ===Ds

gt

rxbuf 93 bD===IgtpU gtomgtS=xTyf=DL|pA= gt===Kl|Lnx=mL=I===i=BM|| oXfT_UrePI=T]=gt==E=|l|

L=IE||y===Y=qM

_DebugOut_ 1804 310 203 854 -843 420 -49 49 4

2 -21-1016 123 828 828 0 11 21

-1-5850 9822 -24267 51 94 1 2 -2

207 706 -1 0 7

rxbuf 93 bD===ggtpi gtm=gtT=oxzd]DL|o===m=A=Kl|ALnx=mL=I===E=m=== KxYSourePI=T]====A===

L=IM||y===Y=nf

_DebugOut_ 1834 315 192 855 -722 414 -49 32 3

4 -21-1008 123 828 828 0 2 15

0 -897811867-24267 51 94 0 1 0

207 708 -1 0 7

gt debug 0

tx bd====DZ

gt

21httpwww2informatikhu-berlinde~obertholQK22Python Language httpwwwpythonorg

20

The debug vector is populated in the FC where element positions correspond with value typesIt includes IMU data manual control input from the RC and the barometer as well as systemstatus values such as battery voltage RSSI value ampc Depending on the setup it can include thereading from the sonar as well If the actual controller is activated with eggt ac3 1

kal_cv_init DP 3 MP 5 CP 0

gt

the controller evaluation function is executed upon each arrival of a debug packet Of coursesome information is retained across calls After computation has nished an extctrl (Externalcontrol) structure is populated and sent back to the FC Aditional measurements such as from anInfraRed Ranger (IRR) are integrated in an asynchronous manner from multiple threads Severalparameters such as the altitude setpoint PID values bias ampc can also be set from the text based userinterface While this works quite well in principle and did achieve good performance modularityand extensibility were not an initial design goal This led to another iteration of the same designwithin the MAVHUB framework which will be described in the next subsection

IO Channels UART TWI UI Network

HAL threads FC-RX Expansion Ctrl Sonar Shell

Processing Controller

mkcom2

Figure 14 Mkcom2 ow-graph

43 Heuristically tuned altitude control software

The vague vision of the overall architecture that is pursued here is that of several concurring moduleswhich are summed in a cooperative time-dependent manner and where each module is responsiblefor various behavioural aspects [1] To ease prototyping and testing of components the structurehas to be kept exible extensible and dynamically recongurable This has to be considered in theoverall onboard software design In order to illustrate this requirement the ow of information andthe interaction with additional behavioural modules will be described in more detail in the followingparagraphs References will be made to several modules operating within the MAVHUB frameworkthe basics of which are described elsewhere [25]

431 Data acquisition

First the controlware has to collect all sensory information from possibly heterogenous sourcesThese include 6 - 9 channels of IMU data (depending on IMU type) a barometric measurementseveral range sensors as well as optical sensors (cameras) and of course any other sensor which is

21

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

1500

2000

Time [s]

Value

throttle

uss_meas

k_s0

Figure 15 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m aboveground The dashed line is the raw sonar range value the solid black line is the estimate uponwhich the PID controller acts The solid green line in the lower part of the plot is the controlleroutput value which is sent to the actuator

available or desired Heterogeneity pertains to hardware channels update rates and data formatsIn MAVHUB there are two main channels if information ow One is the protocol stack whichtransmits volatile incoming messages to all active modules (apps) The other is a shared memoryarea where data can be deposited by any active process In the setup considered here FC data(including IMU barometer and possibly sonar) and intermediate internal data travel on the stackSensors connected via a two-wire bus are operated by sensor drivers and measurements are put intothe shared memory The desired result of this step is to be able to operate on a homogenous vectorof input signals within the main control loop

432 Preprocessing

Subsequent to acquisition each sensory channel is individually preprocessed according to the pe-culiarities of sensor principle and connection mode Preprocessing mostly consists of linearisationunit conversion (inverting the sensor characteristic) and several kinds of heuristic validation

Linearisation For this particular setup linearisation only has to be done for the IRRs Theseare analogue sensors and the output voltage is related to the distance s measured via u(t) = 1

s(t) An example sensor characteristic is displayed in Figure 16 For the dierent subtypes of the Sharpsensors an individually parameterised procedure has to be performed as described by eg Acroname

22

Robotics in [23] if the sensors are processed on a metric basis If the Sharp sensors are driven atthe recommended supply voltage of 5V using the datasheet specications has proven sucientlyaccurate An example script for determining the parameters from given calibration data is suppliedon this reports supplementary website 22

Unit conversion The diverse units of sensor data have to be explicitly converted to units conve-nient for later steps in the calculation in particular sensor fusion with the Kalman lter For thealtitude measurements these are metersminus3 so ADC-units or time-of-ight measurements have to beconverted to millimeters for the analog sensors (barometer accelerometer infrared) and the sonarsensor repsectively This simply amounts to a multiplicative factor

Validation Heuristic sensor data validation has to be done for all types of rangers as well as for thebarometric sensor The spurious readings these sensors produce are of dierent types though Theinfrared rangers display ambigouity beyond the lower limit of the operating ranges see Figure 16For the GP2D120 which can sense the smallest ranges of all sensors this can be mostly neglectedsince the minimal sensing range can hardly be reached due to the mechanical conguration Forall the other sensors output is surpressed when the GP2D120 is active At the upper limit of theIRRs operating range the output is surpressed when a suitable threshold is reached The followingcode example illustrates this where sensor channel number three is the close range IRR

if(in_range(sensors [3] first llim ulim))

valid = 10

else

valid = 00

sensors [3] second = (fir[3]-gtcalc(valid) gt= 099) 1 0

Surpression is realised by setting appropriate values in the measurement transform matrix H(t)of the Kalman lter Alternatively this could be done by generating suitable variances for therespective sensors in the measurement covariance matrix R(t) Driving the IRRs at 33V works butreduces the usable range In addition the IRR sensor measurements are dependent on the groundsurfaces some of which eg an oce carpet can result in erratic results

The ultrasonic sensor is susceptive to dierent kinds of spurious readings caused by late echoesThis happens both when very close to an object or surface or when far away that is beyond theupper limit of measurable distances The validation strategy employed is to set hard empiricallower and upper limits for values as for the IRRs and limiting the maximum dierence betweentwo consecutive values based on assumptions about the maximum velocity An example session isillustrated in Figure 18

Finally the barometer is sensitive to acceleration which has to be accounted for The sensorbehaviour is displayed in Figure 19 The empirical corrections read

BARO (pre [1] correct from accel -z (pre [2])

pre [1] first -= (005 pre [2] first)

The validition process in general produces one new signal per channel to be used later in theprocess for setting Kalman lter matrix values One remaining problem here is the channel cross-dependency

23

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 15: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

Figure 8 Range sensors attached to frame

RC receiver Onboard electronics

BL1 Expansion Board

BL4 FlightCtrl BL3

BL2 Gumstix

Camera BeagleBoard

TWI

UART

TWI

Wi

LAN

USB

Figure 9 Basic HUCH onboard electronics The left hand region of the picture consisting of receiverFC and brushless motor controllers BL1minus4 represents the standard MK setup while the right handregion represents HUCH additions

work with our hardware so a dierent solution had to be found Fortunately here the USB sub-system works well out of the box and standard USB WLAN hardware could be used to set up thelink Running the system o an SD-card as well as TWI (I2C) support in Linux work well Onemore aspect of the WLAN setup is worth noting though It was desired to realise the wireless linkto the onboard Linux in Ad-Hoc mode for two reasons The rst is reduced startup time when usingAd-Hoc mode the second is independence of access point infrastructure In this way the minimalFR groundstation conguration can be operated in a more mobile manner In principle one of thenodes could be operated in Master mode but this is not supported by all hardware

Once the live Linux system and cross-compilation environment was up and running the MKcom

15

software provided the basis for further work on controller implementation Looking at the Linuxsystem at this point the following view presents itself in Figure 10

Gumstix

AringngstroumlmLinux 2631 SD

UIShell mktool wlan0

devttyS1 devi2c-0

FC Exp Groundstation

RxTx wires

Wireless link

Figure 10 Basic Linux setup

4 Experiments

41 Basic structural design through simulation

Initially the problem of altitude control was analysed in simulation To that end a simple con-troller was realised within the crrcsim 20 RC model simulator There are basically two possiblemethodological approaches to setting up a simulation for a model helicopter One is the derivationof the model from rst principles and implementation from scratch The other is building uponexisting if simplifying solutions that are practically usable and open for modication

A moderately physically realistic model of a quadrotor aerial system is governed by a nontrivialnonlinear dierential equation [3 pg 155] [4] Much microscopic detail can be added for furtherrenement as the need arises Such details are discussed to some extent in [14] and [8] In the near-hover ight regime the system behaves quasi-linearly but at more extreme velocities and attitudesthe increasing impact of several nonlinear eects such as blade apping vortex ring states orforward translational lift would have to be considered For our purposes these eects have so farbeen neglected but could in princpiple be incorporated into the model

Circumventing the necessity of model derivation and implementation the second approach waschosen In particular the existing real-time ready crrcsim [7] RC-model simulator software wasmodied to conduct the initial experiments This was particularly facilitated by the prior work ofJens W Wulf who implemented a quadrotor model and internal controller substructures for thissimulation framework [32] A screenshot of the Wulf-model ying in the modied simulation in canbe seen in Figure 11 crrcsim comes with an internal controller architecture that realises dierent

20Charles River Radio Controllers Simulation httpcrrcsimberliosde

16

attitude controllers The software originally is designed to interface manual control hardware suchas RC transmitters joysticks and such to the simulation engine It was modied to implementadditional controllers detailed state information output for plotting and analysis and networkedcontrol of the simulation engine A drawback of crrcsim is its monolithic architecture For futurework the core simulation engine would have to be separated from the render engine Alternativelythe PPZ approach could be used as a drop-in replacement

Figure 11 Simulation screenshot The helicopter model landscape and text console are part ofcrrcsim The actual debugging output that can be seen in the console is part of custom modications

411 Closed loop

The basic structure of the full control loop is displayed in Figure 12 The control module embeddedin the loop is a Single-Input Single-Output (SISO) type controller The actuating variable undercontrol is thrust which eects overall lift (see above) while the other three components are mostlycontrolled manually during the experiments The input to the controller is the current altitudeestimate The estimation process potentially has to consider multiple measurements which have tobe fused into a single representation

412 Measurements

In simulation global knowledge of the world- (and agent-) state is available and all system variablesare immediatly accessible This allows to use a simplied signal-ow structure which is depicted in

17

Measurements

z0

z1 Kalman lter Controller

Fusion Estimate PID System

znminus1

zn

throttle

Behaviour

setpoint

Figure 12 Controller structure with measurement branch

gure 13 In order for the controller to be structurally transferable to the real hardware system thespecic sensor conguration has to be modelled within the simulator This included preparationof IMU data by tapping the Flight Dynamics Model (FDM) module and basic modelling of therespective characteristics of the barometric and ultrasonic range sensors which were in use on thehelicopter at that time In the case of the barometer this meant the addition of white gaussiannoise A slow drift which can be observed on the real sensor due to slow air-pressure changes wasneglected For the ultrasonic range sensor the timing characteristic that is the maximum updaterate dependent on distance measured was emulated The information thus synthesized was fed intoa Kalman lter for further processing

Controller

PID Systemthrottle

Flight dynamics model

setpoint

Figure 13 Simplied controller structure

413 Sensor fusion

Sensor fusion is a problem class on its own The base intent is to derive an estimate of a systemstate variable from multiple measurements that is more reliable than it would be by using only asingle measurement There are several approaches which have been developed over the last decadesand which could be employed for this task The complementary lter approach can be chosen if the

18

sensors are aected by suciently dierent kinds of noise and thus eg spectrally complementarylters can be used on dierent measurement channels which are then linearily combined into a singlevalue Probably the most commonly used techniques are the linear Kalman lter and its nonlinearvariants Other methods are nonexhaustively Bayesian strategies such as Particle lters H-infinlters or neural networks A linear Kalman lter was chosen in the current setup for the reasonthat the lter and its characteristics are well documented and the implementation is straightforwardboth from scratch and even more so using matrix algebra libraries such as OpenCV The basic ltertask is to estimate the state xk isin Rn of a discrete time system governed by the linear stochasticequation [29] [15]

xk = Axkminus1 +Bukminus1 + wkminus1 (2)

based on a measurement zk isin Rm given as

zk = Hxk + vk (3)

where wk vk are random variables which represent process noise and measurement noise and arenormally distributed with zero mean p(wk) sim N(0 Q) p(vk) sim N(0 R) Q and R are the processand measurement noise covariance matrices The model used here consists of two state variablesx = (a dadt) with a the altitude (above ground) Later the model was extended to include d2adtso as to facilitate incorporation of accelerometer measurements One problem with the real sensorswas a clear deviation of the measurement noise from the assumed normal distribution and had tobe corrected for in preprocessing

414 PID controller

The Kalman lter state estimate can nally be used as the input to a PID throttle controller ThePID model used is a FOPDT integrating model The second input to the controller module is thesetpoint which can be set in the simulation via keyboard- or network-input to the application Therst working PID parametrisation was arrived at through manual tuning which is cumbersome andgives suboptimal results

415 Evolutionary parameter tuning

To prove the concept of using online learning within simulation at least the PID parameters wereoptimised using evolutionary strategies [22] [26] The tness function for this experiment wasconceivably simple chosen as

f(i) =

Nsum0

|xset minus xik| (4)

with individual i (a tuple (P ID)) setpoint xset the experiments duration in time steps N andthe altitude xik at time step k resulting from execution of controller i This stage involved setting upthe system so that simulation state and model parametrisation (the P I and D coecients) could

19

be controlled programmatically It was realised over a UDPIP connection between crrcsim andthe external simctrl control shell 21 implemented in the Python language 22 The results of theexperiment have been presented in [10]

42 MKcom2

MKcom short for MikroKopter communication tool was designed as a minimal software layer tosit on top of the UART communication link to the main ight board It provides a console baseduser interface for activation and conguration of a set of thin control functions and can act as agateway between the FC and a CMUcam MKcom functions can send commands to the FC andincoming UART packets are dispatched to the appropriate message handler This tool implementedthe modied MK message set

The setup was used as the basis for prototyping several versions of the control loop structureoutlined in Figures 12 and 13 The internal organisation of these implementations can be seenin Figure 14 Three dierent controller cores were realised which incrementally incorporated moremeasurement channels heuristic detail and safety hooks The detailed ow structure of the controllerdesign will be outlined below The update rate and execution timings are dictated by the arrivalof the measurement vector from the FC Auxiliary sensors were integrated asynchronously into themain loop A custom groundstation for state logging and realtime plotting was connected to thenetwork downlink indicated in the diagram

421 MKcom2 Flow structure

On startup a request for debug structure emission is sent manually from the mkcom shell to the FCwith the debug n command where n is the desired sampling interval in milliseconds An examplesession excerpt looks (slightly beautied) as follows (`gt indicates the shells command prompt `is the startsign of the MK protocol strings starting with ` is the raw ascii data going over thewire)gt debug 100

tx bdV ===Ds

gt

rxbuf 93 bD===IgtpU gtomgtS=xTyf=DL|pA= gt===Kl|Lnx=mL=I===i=BM|| oXfT_UrePI=T]=gt==E=|l|

L=IE||y===Y=qM

_DebugOut_ 1804 310 203 854 -843 420 -49 49 4

2 -21-1016 123 828 828 0 11 21

-1-5850 9822 -24267 51 94 1 2 -2

207 706 -1 0 7

rxbuf 93 bD===ggtpi gtm=gtT=oxzd]DL|o===m=A=Kl|ALnx=mL=I===E=m=== KxYSourePI=T]====A===

L=IM||y===Y=nf

_DebugOut_ 1834 315 192 855 -722 414 -49 32 3

4 -21-1008 123 828 828 0 2 15

0 -897811867-24267 51 94 0 1 0

207 708 -1 0 7

gt debug 0

tx bd====DZ

gt

21httpwww2informatikhu-berlinde~obertholQK22Python Language httpwwwpythonorg

20

The debug vector is populated in the FC where element positions correspond with value typesIt includes IMU data manual control input from the RC and the barometer as well as systemstatus values such as battery voltage RSSI value ampc Depending on the setup it can include thereading from the sonar as well If the actual controller is activated with eggt ac3 1

kal_cv_init DP 3 MP 5 CP 0

gt

the controller evaluation function is executed upon each arrival of a debug packet Of coursesome information is retained across calls After computation has nished an extctrl (Externalcontrol) structure is populated and sent back to the FC Aditional measurements such as from anInfraRed Ranger (IRR) are integrated in an asynchronous manner from multiple threads Severalparameters such as the altitude setpoint PID values bias ampc can also be set from the text based userinterface While this works quite well in principle and did achieve good performance modularityand extensibility were not an initial design goal This led to another iteration of the same designwithin the MAVHUB framework which will be described in the next subsection

IO Channels UART TWI UI Network

HAL threads FC-RX Expansion Ctrl Sonar Shell

Processing Controller

mkcom2

Figure 14 Mkcom2 ow-graph

43 Heuristically tuned altitude control software

The vague vision of the overall architecture that is pursued here is that of several concurring moduleswhich are summed in a cooperative time-dependent manner and where each module is responsiblefor various behavioural aspects [1] To ease prototyping and testing of components the structurehas to be kept exible extensible and dynamically recongurable This has to be considered in theoverall onboard software design In order to illustrate this requirement the ow of information andthe interaction with additional behavioural modules will be described in more detail in the followingparagraphs References will be made to several modules operating within the MAVHUB frameworkthe basics of which are described elsewhere [25]

431 Data acquisition

First the controlware has to collect all sensory information from possibly heterogenous sourcesThese include 6 - 9 channels of IMU data (depending on IMU type) a barometric measurementseveral range sensors as well as optical sensors (cameras) and of course any other sensor which is

21

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

1500

2000

Time [s]

Value

throttle

uss_meas

k_s0

Figure 15 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m aboveground The dashed line is the raw sonar range value the solid black line is the estimate uponwhich the PID controller acts The solid green line in the lower part of the plot is the controlleroutput value which is sent to the actuator

available or desired Heterogeneity pertains to hardware channels update rates and data formatsIn MAVHUB there are two main channels if information ow One is the protocol stack whichtransmits volatile incoming messages to all active modules (apps) The other is a shared memoryarea where data can be deposited by any active process In the setup considered here FC data(including IMU barometer and possibly sonar) and intermediate internal data travel on the stackSensors connected via a two-wire bus are operated by sensor drivers and measurements are put intothe shared memory The desired result of this step is to be able to operate on a homogenous vectorof input signals within the main control loop

432 Preprocessing

Subsequent to acquisition each sensory channel is individually preprocessed according to the pe-culiarities of sensor principle and connection mode Preprocessing mostly consists of linearisationunit conversion (inverting the sensor characteristic) and several kinds of heuristic validation

Linearisation For this particular setup linearisation only has to be done for the IRRs Theseare analogue sensors and the output voltage is related to the distance s measured via u(t) = 1

s(t) An example sensor characteristic is displayed in Figure 16 For the dierent subtypes of the Sharpsensors an individually parameterised procedure has to be performed as described by eg Acroname

22

Robotics in [23] if the sensors are processed on a metric basis If the Sharp sensors are driven atthe recommended supply voltage of 5V using the datasheet specications has proven sucientlyaccurate An example script for determining the parameters from given calibration data is suppliedon this reports supplementary website 22

Unit conversion The diverse units of sensor data have to be explicitly converted to units conve-nient for later steps in the calculation in particular sensor fusion with the Kalman lter For thealtitude measurements these are metersminus3 so ADC-units or time-of-ight measurements have to beconverted to millimeters for the analog sensors (barometer accelerometer infrared) and the sonarsensor repsectively This simply amounts to a multiplicative factor

Validation Heuristic sensor data validation has to be done for all types of rangers as well as for thebarometric sensor The spurious readings these sensors produce are of dierent types though Theinfrared rangers display ambigouity beyond the lower limit of the operating ranges see Figure 16For the GP2D120 which can sense the smallest ranges of all sensors this can be mostly neglectedsince the minimal sensing range can hardly be reached due to the mechanical conguration Forall the other sensors output is surpressed when the GP2D120 is active At the upper limit of theIRRs operating range the output is surpressed when a suitable threshold is reached The followingcode example illustrates this where sensor channel number three is the close range IRR

if(in_range(sensors [3] first llim ulim))

valid = 10

else

valid = 00

sensors [3] second = (fir[3]-gtcalc(valid) gt= 099) 1 0

Surpression is realised by setting appropriate values in the measurement transform matrix H(t)of the Kalman lter Alternatively this could be done by generating suitable variances for therespective sensors in the measurement covariance matrix R(t) Driving the IRRs at 33V works butreduces the usable range In addition the IRR sensor measurements are dependent on the groundsurfaces some of which eg an oce carpet can result in erratic results

The ultrasonic sensor is susceptive to dierent kinds of spurious readings caused by late echoesThis happens both when very close to an object or surface or when far away that is beyond theupper limit of measurable distances The validation strategy employed is to set hard empiricallower and upper limits for values as for the IRRs and limiting the maximum dierence betweentwo consecutive values based on assumptions about the maximum velocity An example session isillustrated in Figure 18

Finally the barometer is sensitive to acceleration which has to be accounted for The sensorbehaviour is displayed in Figure 19 The empirical corrections read

BARO (pre [1] correct from accel -z (pre [2])

pre [1] first -= (005 pre [2] first)

The validition process in general produces one new signal per channel to be used later in theprocess for setting Kalman lter matrix values One remaining problem here is the channel cross-dependency

23

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 16: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

software provided the basis for further work on controller implementation Looking at the Linuxsystem at this point the following view presents itself in Figure 10

Gumstix

AringngstroumlmLinux 2631 SD

UIShell mktool wlan0

devttyS1 devi2c-0

FC Exp Groundstation

RxTx wires

Wireless link

Figure 10 Basic Linux setup

4 Experiments

41 Basic structural design through simulation

Initially the problem of altitude control was analysed in simulation To that end a simple con-troller was realised within the crrcsim 20 RC model simulator There are basically two possiblemethodological approaches to setting up a simulation for a model helicopter One is the derivationof the model from rst principles and implementation from scratch The other is building uponexisting if simplifying solutions that are practically usable and open for modication

A moderately physically realistic model of a quadrotor aerial system is governed by a nontrivialnonlinear dierential equation [3 pg 155] [4] Much microscopic detail can be added for furtherrenement as the need arises Such details are discussed to some extent in [14] and [8] In the near-hover ight regime the system behaves quasi-linearly but at more extreme velocities and attitudesthe increasing impact of several nonlinear eects such as blade apping vortex ring states orforward translational lift would have to be considered For our purposes these eects have so farbeen neglected but could in princpiple be incorporated into the model

Circumventing the necessity of model derivation and implementation the second approach waschosen In particular the existing real-time ready crrcsim [7] RC-model simulator software wasmodied to conduct the initial experiments This was particularly facilitated by the prior work ofJens W Wulf who implemented a quadrotor model and internal controller substructures for thissimulation framework [32] A screenshot of the Wulf-model ying in the modied simulation in canbe seen in Figure 11 crrcsim comes with an internal controller architecture that realises dierent

20Charles River Radio Controllers Simulation httpcrrcsimberliosde

16

attitude controllers The software originally is designed to interface manual control hardware suchas RC transmitters joysticks and such to the simulation engine It was modied to implementadditional controllers detailed state information output for plotting and analysis and networkedcontrol of the simulation engine A drawback of crrcsim is its monolithic architecture For futurework the core simulation engine would have to be separated from the render engine Alternativelythe PPZ approach could be used as a drop-in replacement

Figure 11 Simulation screenshot The helicopter model landscape and text console are part ofcrrcsim The actual debugging output that can be seen in the console is part of custom modications

411 Closed loop

The basic structure of the full control loop is displayed in Figure 12 The control module embeddedin the loop is a Single-Input Single-Output (SISO) type controller The actuating variable undercontrol is thrust which eects overall lift (see above) while the other three components are mostlycontrolled manually during the experiments The input to the controller is the current altitudeestimate The estimation process potentially has to consider multiple measurements which have tobe fused into a single representation

412 Measurements

In simulation global knowledge of the world- (and agent-) state is available and all system variablesare immediatly accessible This allows to use a simplied signal-ow structure which is depicted in

17

Measurements

z0

z1 Kalman lter Controller

Fusion Estimate PID System

znminus1

zn

throttle

Behaviour

setpoint

Figure 12 Controller structure with measurement branch

gure 13 In order for the controller to be structurally transferable to the real hardware system thespecic sensor conguration has to be modelled within the simulator This included preparationof IMU data by tapping the Flight Dynamics Model (FDM) module and basic modelling of therespective characteristics of the barometric and ultrasonic range sensors which were in use on thehelicopter at that time In the case of the barometer this meant the addition of white gaussiannoise A slow drift which can be observed on the real sensor due to slow air-pressure changes wasneglected For the ultrasonic range sensor the timing characteristic that is the maximum updaterate dependent on distance measured was emulated The information thus synthesized was fed intoa Kalman lter for further processing

Controller

PID Systemthrottle

Flight dynamics model

setpoint

Figure 13 Simplied controller structure

413 Sensor fusion

Sensor fusion is a problem class on its own The base intent is to derive an estimate of a systemstate variable from multiple measurements that is more reliable than it would be by using only asingle measurement There are several approaches which have been developed over the last decadesand which could be employed for this task The complementary lter approach can be chosen if the

18

sensors are aected by suciently dierent kinds of noise and thus eg spectrally complementarylters can be used on dierent measurement channels which are then linearily combined into a singlevalue Probably the most commonly used techniques are the linear Kalman lter and its nonlinearvariants Other methods are nonexhaustively Bayesian strategies such as Particle lters H-infinlters or neural networks A linear Kalman lter was chosen in the current setup for the reasonthat the lter and its characteristics are well documented and the implementation is straightforwardboth from scratch and even more so using matrix algebra libraries such as OpenCV The basic ltertask is to estimate the state xk isin Rn of a discrete time system governed by the linear stochasticequation [29] [15]

xk = Axkminus1 +Bukminus1 + wkminus1 (2)

based on a measurement zk isin Rm given as

zk = Hxk + vk (3)

where wk vk are random variables which represent process noise and measurement noise and arenormally distributed with zero mean p(wk) sim N(0 Q) p(vk) sim N(0 R) Q and R are the processand measurement noise covariance matrices The model used here consists of two state variablesx = (a dadt) with a the altitude (above ground) Later the model was extended to include d2adtso as to facilitate incorporation of accelerometer measurements One problem with the real sensorswas a clear deviation of the measurement noise from the assumed normal distribution and had tobe corrected for in preprocessing

414 PID controller

The Kalman lter state estimate can nally be used as the input to a PID throttle controller ThePID model used is a FOPDT integrating model The second input to the controller module is thesetpoint which can be set in the simulation via keyboard- or network-input to the application Therst working PID parametrisation was arrived at through manual tuning which is cumbersome andgives suboptimal results

415 Evolutionary parameter tuning

To prove the concept of using online learning within simulation at least the PID parameters wereoptimised using evolutionary strategies [22] [26] The tness function for this experiment wasconceivably simple chosen as

f(i) =

Nsum0

|xset minus xik| (4)

with individual i (a tuple (P ID)) setpoint xset the experiments duration in time steps N andthe altitude xik at time step k resulting from execution of controller i This stage involved setting upthe system so that simulation state and model parametrisation (the P I and D coecients) could

19

be controlled programmatically It was realised over a UDPIP connection between crrcsim andthe external simctrl control shell 21 implemented in the Python language 22 The results of theexperiment have been presented in [10]

42 MKcom2

MKcom short for MikroKopter communication tool was designed as a minimal software layer tosit on top of the UART communication link to the main ight board It provides a console baseduser interface for activation and conguration of a set of thin control functions and can act as agateway between the FC and a CMUcam MKcom functions can send commands to the FC andincoming UART packets are dispatched to the appropriate message handler This tool implementedthe modied MK message set

The setup was used as the basis for prototyping several versions of the control loop structureoutlined in Figures 12 and 13 The internal organisation of these implementations can be seenin Figure 14 Three dierent controller cores were realised which incrementally incorporated moremeasurement channels heuristic detail and safety hooks The detailed ow structure of the controllerdesign will be outlined below The update rate and execution timings are dictated by the arrivalof the measurement vector from the FC Auxiliary sensors were integrated asynchronously into themain loop A custom groundstation for state logging and realtime plotting was connected to thenetwork downlink indicated in the diagram

421 MKcom2 Flow structure

On startup a request for debug structure emission is sent manually from the mkcom shell to the FCwith the debug n command where n is the desired sampling interval in milliseconds An examplesession excerpt looks (slightly beautied) as follows (`gt indicates the shells command prompt `is the startsign of the MK protocol strings starting with ` is the raw ascii data going over thewire)gt debug 100

tx bdV ===Ds

gt

rxbuf 93 bD===IgtpU gtomgtS=xTyf=DL|pA= gt===Kl|Lnx=mL=I===i=BM|| oXfT_UrePI=T]=gt==E=|l|

L=IE||y===Y=qM

_DebugOut_ 1804 310 203 854 -843 420 -49 49 4

2 -21-1016 123 828 828 0 11 21

-1-5850 9822 -24267 51 94 1 2 -2

207 706 -1 0 7

rxbuf 93 bD===ggtpi gtm=gtT=oxzd]DL|o===m=A=Kl|ALnx=mL=I===E=m=== KxYSourePI=T]====A===

L=IM||y===Y=nf

_DebugOut_ 1834 315 192 855 -722 414 -49 32 3

4 -21-1008 123 828 828 0 2 15

0 -897811867-24267 51 94 0 1 0

207 708 -1 0 7

gt debug 0

tx bd====DZ

gt

21httpwww2informatikhu-berlinde~obertholQK22Python Language httpwwwpythonorg

20

The debug vector is populated in the FC where element positions correspond with value typesIt includes IMU data manual control input from the RC and the barometer as well as systemstatus values such as battery voltage RSSI value ampc Depending on the setup it can include thereading from the sonar as well If the actual controller is activated with eggt ac3 1

kal_cv_init DP 3 MP 5 CP 0

gt

the controller evaluation function is executed upon each arrival of a debug packet Of coursesome information is retained across calls After computation has nished an extctrl (Externalcontrol) structure is populated and sent back to the FC Aditional measurements such as from anInfraRed Ranger (IRR) are integrated in an asynchronous manner from multiple threads Severalparameters such as the altitude setpoint PID values bias ampc can also be set from the text based userinterface While this works quite well in principle and did achieve good performance modularityand extensibility were not an initial design goal This led to another iteration of the same designwithin the MAVHUB framework which will be described in the next subsection

IO Channels UART TWI UI Network

HAL threads FC-RX Expansion Ctrl Sonar Shell

Processing Controller

mkcom2

Figure 14 Mkcom2 ow-graph

43 Heuristically tuned altitude control software

The vague vision of the overall architecture that is pursued here is that of several concurring moduleswhich are summed in a cooperative time-dependent manner and where each module is responsiblefor various behavioural aspects [1] To ease prototyping and testing of components the structurehas to be kept exible extensible and dynamically recongurable This has to be considered in theoverall onboard software design In order to illustrate this requirement the ow of information andthe interaction with additional behavioural modules will be described in more detail in the followingparagraphs References will be made to several modules operating within the MAVHUB frameworkthe basics of which are described elsewhere [25]

431 Data acquisition

First the controlware has to collect all sensory information from possibly heterogenous sourcesThese include 6 - 9 channels of IMU data (depending on IMU type) a barometric measurementseveral range sensors as well as optical sensors (cameras) and of course any other sensor which is

21

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

1500

2000

Time [s]

Value

throttle

uss_meas

k_s0

Figure 15 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m aboveground The dashed line is the raw sonar range value the solid black line is the estimate uponwhich the PID controller acts The solid green line in the lower part of the plot is the controlleroutput value which is sent to the actuator

available or desired Heterogeneity pertains to hardware channels update rates and data formatsIn MAVHUB there are two main channels if information ow One is the protocol stack whichtransmits volatile incoming messages to all active modules (apps) The other is a shared memoryarea where data can be deposited by any active process In the setup considered here FC data(including IMU barometer and possibly sonar) and intermediate internal data travel on the stackSensors connected via a two-wire bus are operated by sensor drivers and measurements are put intothe shared memory The desired result of this step is to be able to operate on a homogenous vectorof input signals within the main control loop

432 Preprocessing

Subsequent to acquisition each sensory channel is individually preprocessed according to the pe-culiarities of sensor principle and connection mode Preprocessing mostly consists of linearisationunit conversion (inverting the sensor characteristic) and several kinds of heuristic validation

Linearisation For this particular setup linearisation only has to be done for the IRRs Theseare analogue sensors and the output voltage is related to the distance s measured via u(t) = 1

s(t) An example sensor characteristic is displayed in Figure 16 For the dierent subtypes of the Sharpsensors an individually parameterised procedure has to be performed as described by eg Acroname

22

Robotics in [23] if the sensors are processed on a metric basis If the Sharp sensors are driven atthe recommended supply voltage of 5V using the datasheet specications has proven sucientlyaccurate An example script for determining the parameters from given calibration data is suppliedon this reports supplementary website 22

Unit conversion The diverse units of sensor data have to be explicitly converted to units conve-nient for later steps in the calculation in particular sensor fusion with the Kalman lter For thealtitude measurements these are metersminus3 so ADC-units or time-of-ight measurements have to beconverted to millimeters for the analog sensors (barometer accelerometer infrared) and the sonarsensor repsectively This simply amounts to a multiplicative factor

Validation Heuristic sensor data validation has to be done for all types of rangers as well as for thebarometric sensor The spurious readings these sensors produce are of dierent types though Theinfrared rangers display ambigouity beyond the lower limit of the operating ranges see Figure 16For the GP2D120 which can sense the smallest ranges of all sensors this can be mostly neglectedsince the minimal sensing range can hardly be reached due to the mechanical conguration Forall the other sensors output is surpressed when the GP2D120 is active At the upper limit of theIRRs operating range the output is surpressed when a suitable threshold is reached The followingcode example illustrates this where sensor channel number three is the close range IRR

if(in_range(sensors [3] first llim ulim))

valid = 10

else

valid = 00

sensors [3] second = (fir[3]-gtcalc(valid) gt= 099) 1 0

Surpression is realised by setting appropriate values in the measurement transform matrix H(t)of the Kalman lter Alternatively this could be done by generating suitable variances for therespective sensors in the measurement covariance matrix R(t) Driving the IRRs at 33V works butreduces the usable range In addition the IRR sensor measurements are dependent on the groundsurfaces some of which eg an oce carpet can result in erratic results

The ultrasonic sensor is susceptive to dierent kinds of spurious readings caused by late echoesThis happens both when very close to an object or surface or when far away that is beyond theupper limit of measurable distances The validation strategy employed is to set hard empiricallower and upper limits for values as for the IRRs and limiting the maximum dierence betweentwo consecutive values based on assumptions about the maximum velocity An example session isillustrated in Figure 18

Finally the barometer is sensitive to acceleration which has to be accounted for The sensorbehaviour is displayed in Figure 19 The empirical corrections read

BARO (pre [1] correct from accel -z (pre [2])

pre [1] first -= (005 pre [2] first)

The validition process in general produces one new signal per channel to be used later in theprocess for setting Kalman lter matrix values One remaining problem here is the channel cross-dependency

23

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 17: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

attitude controllers The software originally is designed to interface manual control hardware suchas RC transmitters joysticks and such to the simulation engine It was modied to implementadditional controllers detailed state information output for plotting and analysis and networkedcontrol of the simulation engine A drawback of crrcsim is its monolithic architecture For futurework the core simulation engine would have to be separated from the render engine Alternativelythe PPZ approach could be used as a drop-in replacement

Figure 11 Simulation screenshot The helicopter model landscape and text console are part ofcrrcsim The actual debugging output that can be seen in the console is part of custom modications

411 Closed loop

The basic structure of the full control loop is displayed in Figure 12 The control module embeddedin the loop is a Single-Input Single-Output (SISO) type controller The actuating variable undercontrol is thrust which eects overall lift (see above) while the other three components are mostlycontrolled manually during the experiments The input to the controller is the current altitudeestimate The estimation process potentially has to consider multiple measurements which have tobe fused into a single representation

412 Measurements

In simulation global knowledge of the world- (and agent-) state is available and all system variablesare immediatly accessible This allows to use a simplied signal-ow structure which is depicted in

17

Measurements

z0

z1 Kalman lter Controller

Fusion Estimate PID System

znminus1

zn

throttle

Behaviour

setpoint

Figure 12 Controller structure with measurement branch

gure 13 In order for the controller to be structurally transferable to the real hardware system thespecic sensor conguration has to be modelled within the simulator This included preparationof IMU data by tapping the Flight Dynamics Model (FDM) module and basic modelling of therespective characteristics of the barometric and ultrasonic range sensors which were in use on thehelicopter at that time In the case of the barometer this meant the addition of white gaussiannoise A slow drift which can be observed on the real sensor due to slow air-pressure changes wasneglected For the ultrasonic range sensor the timing characteristic that is the maximum updaterate dependent on distance measured was emulated The information thus synthesized was fed intoa Kalman lter for further processing

Controller

PID Systemthrottle

Flight dynamics model

setpoint

Figure 13 Simplied controller structure

413 Sensor fusion

Sensor fusion is a problem class on its own The base intent is to derive an estimate of a systemstate variable from multiple measurements that is more reliable than it would be by using only asingle measurement There are several approaches which have been developed over the last decadesand which could be employed for this task The complementary lter approach can be chosen if the

18

sensors are aected by suciently dierent kinds of noise and thus eg spectrally complementarylters can be used on dierent measurement channels which are then linearily combined into a singlevalue Probably the most commonly used techniques are the linear Kalman lter and its nonlinearvariants Other methods are nonexhaustively Bayesian strategies such as Particle lters H-infinlters or neural networks A linear Kalman lter was chosen in the current setup for the reasonthat the lter and its characteristics are well documented and the implementation is straightforwardboth from scratch and even more so using matrix algebra libraries such as OpenCV The basic ltertask is to estimate the state xk isin Rn of a discrete time system governed by the linear stochasticequation [29] [15]

xk = Axkminus1 +Bukminus1 + wkminus1 (2)

based on a measurement zk isin Rm given as

zk = Hxk + vk (3)

where wk vk are random variables which represent process noise and measurement noise and arenormally distributed with zero mean p(wk) sim N(0 Q) p(vk) sim N(0 R) Q and R are the processand measurement noise covariance matrices The model used here consists of two state variablesx = (a dadt) with a the altitude (above ground) Later the model was extended to include d2adtso as to facilitate incorporation of accelerometer measurements One problem with the real sensorswas a clear deviation of the measurement noise from the assumed normal distribution and had tobe corrected for in preprocessing

414 PID controller

The Kalman lter state estimate can nally be used as the input to a PID throttle controller ThePID model used is a FOPDT integrating model The second input to the controller module is thesetpoint which can be set in the simulation via keyboard- or network-input to the application Therst working PID parametrisation was arrived at through manual tuning which is cumbersome andgives suboptimal results

415 Evolutionary parameter tuning

To prove the concept of using online learning within simulation at least the PID parameters wereoptimised using evolutionary strategies [22] [26] The tness function for this experiment wasconceivably simple chosen as

f(i) =

Nsum0

|xset minus xik| (4)

with individual i (a tuple (P ID)) setpoint xset the experiments duration in time steps N andthe altitude xik at time step k resulting from execution of controller i This stage involved setting upthe system so that simulation state and model parametrisation (the P I and D coecients) could

19

be controlled programmatically It was realised over a UDPIP connection between crrcsim andthe external simctrl control shell 21 implemented in the Python language 22 The results of theexperiment have been presented in [10]

42 MKcom2

MKcom short for MikroKopter communication tool was designed as a minimal software layer tosit on top of the UART communication link to the main ight board It provides a console baseduser interface for activation and conguration of a set of thin control functions and can act as agateway between the FC and a CMUcam MKcom functions can send commands to the FC andincoming UART packets are dispatched to the appropriate message handler This tool implementedthe modied MK message set

The setup was used as the basis for prototyping several versions of the control loop structureoutlined in Figures 12 and 13 The internal organisation of these implementations can be seenin Figure 14 Three dierent controller cores were realised which incrementally incorporated moremeasurement channels heuristic detail and safety hooks The detailed ow structure of the controllerdesign will be outlined below The update rate and execution timings are dictated by the arrivalof the measurement vector from the FC Auxiliary sensors were integrated asynchronously into themain loop A custom groundstation for state logging and realtime plotting was connected to thenetwork downlink indicated in the diagram

421 MKcom2 Flow structure

On startup a request for debug structure emission is sent manually from the mkcom shell to the FCwith the debug n command where n is the desired sampling interval in milliseconds An examplesession excerpt looks (slightly beautied) as follows (`gt indicates the shells command prompt `is the startsign of the MK protocol strings starting with ` is the raw ascii data going over thewire)gt debug 100

tx bdV ===Ds

gt

rxbuf 93 bD===IgtpU gtomgtS=xTyf=DL|pA= gt===Kl|Lnx=mL=I===i=BM|| oXfT_UrePI=T]=gt==E=|l|

L=IE||y===Y=qM

_DebugOut_ 1804 310 203 854 -843 420 -49 49 4

2 -21-1016 123 828 828 0 11 21

-1-5850 9822 -24267 51 94 1 2 -2

207 706 -1 0 7

rxbuf 93 bD===ggtpi gtm=gtT=oxzd]DL|o===m=A=Kl|ALnx=mL=I===E=m=== KxYSourePI=T]====A===

L=IM||y===Y=nf

_DebugOut_ 1834 315 192 855 -722 414 -49 32 3

4 -21-1008 123 828 828 0 2 15

0 -897811867-24267 51 94 0 1 0

207 708 -1 0 7

gt debug 0

tx bd====DZ

gt

21httpwww2informatikhu-berlinde~obertholQK22Python Language httpwwwpythonorg

20

The debug vector is populated in the FC where element positions correspond with value typesIt includes IMU data manual control input from the RC and the barometer as well as systemstatus values such as battery voltage RSSI value ampc Depending on the setup it can include thereading from the sonar as well If the actual controller is activated with eggt ac3 1

kal_cv_init DP 3 MP 5 CP 0

gt

the controller evaluation function is executed upon each arrival of a debug packet Of coursesome information is retained across calls After computation has nished an extctrl (Externalcontrol) structure is populated and sent back to the FC Aditional measurements such as from anInfraRed Ranger (IRR) are integrated in an asynchronous manner from multiple threads Severalparameters such as the altitude setpoint PID values bias ampc can also be set from the text based userinterface While this works quite well in principle and did achieve good performance modularityand extensibility were not an initial design goal This led to another iteration of the same designwithin the MAVHUB framework which will be described in the next subsection

IO Channels UART TWI UI Network

HAL threads FC-RX Expansion Ctrl Sonar Shell

Processing Controller

mkcom2

Figure 14 Mkcom2 ow-graph

43 Heuristically tuned altitude control software

The vague vision of the overall architecture that is pursued here is that of several concurring moduleswhich are summed in a cooperative time-dependent manner and where each module is responsiblefor various behavioural aspects [1] To ease prototyping and testing of components the structurehas to be kept exible extensible and dynamically recongurable This has to be considered in theoverall onboard software design In order to illustrate this requirement the ow of information andthe interaction with additional behavioural modules will be described in more detail in the followingparagraphs References will be made to several modules operating within the MAVHUB frameworkthe basics of which are described elsewhere [25]

431 Data acquisition

First the controlware has to collect all sensory information from possibly heterogenous sourcesThese include 6 - 9 channels of IMU data (depending on IMU type) a barometric measurementseveral range sensors as well as optical sensors (cameras) and of course any other sensor which is

21

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

1500

2000

Time [s]

Value

throttle

uss_meas

k_s0

Figure 15 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m aboveground The dashed line is the raw sonar range value the solid black line is the estimate uponwhich the PID controller acts The solid green line in the lower part of the plot is the controlleroutput value which is sent to the actuator

available or desired Heterogeneity pertains to hardware channels update rates and data formatsIn MAVHUB there are two main channels if information ow One is the protocol stack whichtransmits volatile incoming messages to all active modules (apps) The other is a shared memoryarea where data can be deposited by any active process In the setup considered here FC data(including IMU barometer and possibly sonar) and intermediate internal data travel on the stackSensors connected via a two-wire bus are operated by sensor drivers and measurements are put intothe shared memory The desired result of this step is to be able to operate on a homogenous vectorof input signals within the main control loop

432 Preprocessing

Subsequent to acquisition each sensory channel is individually preprocessed according to the pe-culiarities of sensor principle and connection mode Preprocessing mostly consists of linearisationunit conversion (inverting the sensor characteristic) and several kinds of heuristic validation

Linearisation For this particular setup linearisation only has to be done for the IRRs Theseare analogue sensors and the output voltage is related to the distance s measured via u(t) = 1

s(t) An example sensor characteristic is displayed in Figure 16 For the dierent subtypes of the Sharpsensors an individually parameterised procedure has to be performed as described by eg Acroname

22

Robotics in [23] if the sensors are processed on a metric basis If the Sharp sensors are driven atthe recommended supply voltage of 5V using the datasheet specications has proven sucientlyaccurate An example script for determining the parameters from given calibration data is suppliedon this reports supplementary website 22

Unit conversion The diverse units of sensor data have to be explicitly converted to units conve-nient for later steps in the calculation in particular sensor fusion with the Kalman lter For thealtitude measurements these are metersminus3 so ADC-units or time-of-ight measurements have to beconverted to millimeters for the analog sensors (barometer accelerometer infrared) and the sonarsensor repsectively This simply amounts to a multiplicative factor

Validation Heuristic sensor data validation has to be done for all types of rangers as well as for thebarometric sensor The spurious readings these sensors produce are of dierent types though Theinfrared rangers display ambigouity beyond the lower limit of the operating ranges see Figure 16For the GP2D120 which can sense the smallest ranges of all sensors this can be mostly neglectedsince the minimal sensing range can hardly be reached due to the mechanical conguration Forall the other sensors output is surpressed when the GP2D120 is active At the upper limit of theIRRs operating range the output is surpressed when a suitable threshold is reached The followingcode example illustrates this where sensor channel number three is the close range IRR

if(in_range(sensors [3] first llim ulim))

valid = 10

else

valid = 00

sensors [3] second = (fir[3]-gtcalc(valid) gt= 099) 1 0

Surpression is realised by setting appropriate values in the measurement transform matrix H(t)of the Kalman lter Alternatively this could be done by generating suitable variances for therespective sensors in the measurement covariance matrix R(t) Driving the IRRs at 33V works butreduces the usable range In addition the IRR sensor measurements are dependent on the groundsurfaces some of which eg an oce carpet can result in erratic results

The ultrasonic sensor is susceptive to dierent kinds of spurious readings caused by late echoesThis happens both when very close to an object or surface or when far away that is beyond theupper limit of measurable distances The validation strategy employed is to set hard empiricallower and upper limits for values as for the IRRs and limiting the maximum dierence betweentwo consecutive values based on assumptions about the maximum velocity An example session isillustrated in Figure 18

Finally the barometer is sensitive to acceleration which has to be accounted for The sensorbehaviour is displayed in Figure 19 The empirical corrections read

BARO (pre [1] correct from accel -z (pre [2])

pre [1] first -= (005 pre [2] first)

The validition process in general produces one new signal per channel to be used later in theprocess for setting Kalman lter matrix values One remaining problem here is the channel cross-dependency

23

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 18: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

Measurements

z0

z1 Kalman lter Controller

Fusion Estimate PID System

znminus1

zn

throttle

Behaviour

setpoint

Figure 12 Controller structure with measurement branch

gure 13 In order for the controller to be structurally transferable to the real hardware system thespecic sensor conguration has to be modelled within the simulator This included preparationof IMU data by tapping the Flight Dynamics Model (FDM) module and basic modelling of therespective characteristics of the barometric and ultrasonic range sensors which were in use on thehelicopter at that time In the case of the barometer this meant the addition of white gaussiannoise A slow drift which can be observed on the real sensor due to slow air-pressure changes wasneglected For the ultrasonic range sensor the timing characteristic that is the maximum updaterate dependent on distance measured was emulated The information thus synthesized was fed intoa Kalman lter for further processing

Controller

PID Systemthrottle

Flight dynamics model

setpoint

Figure 13 Simplied controller structure

413 Sensor fusion

Sensor fusion is a problem class on its own The base intent is to derive an estimate of a systemstate variable from multiple measurements that is more reliable than it would be by using only asingle measurement There are several approaches which have been developed over the last decadesand which could be employed for this task The complementary lter approach can be chosen if the

18

sensors are aected by suciently dierent kinds of noise and thus eg spectrally complementarylters can be used on dierent measurement channels which are then linearily combined into a singlevalue Probably the most commonly used techniques are the linear Kalman lter and its nonlinearvariants Other methods are nonexhaustively Bayesian strategies such as Particle lters H-infinlters or neural networks A linear Kalman lter was chosen in the current setup for the reasonthat the lter and its characteristics are well documented and the implementation is straightforwardboth from scratch and even more so using matrix algebra libraries such as OpenCV The basic ltertask is to estimate the state xk isin Rn of a discrete time system governed by the linear stochasticequation [29] [15]

xk = Axkminus1 +Bukminus1 + wkminus1 (2)

based on a measurement zk isin Rm given as

zk = Hxk + vk (3)

where wk vk are random variables which represent process noise and measurement noise and arenormally distributed with zero mean p(wk) sim N(0 Q) p(vk) sim N(0 R) Q and R are the processand measurement noise covariance matrices The model used here consists of two state variablesx = (a dadt) with a the altitude (above ground) Later the model was extended to include d2adtso as to facilitate incorporation of accelerometer measurements One problem with the real sensorswas a clear deviation of the measurement noise from the assumed normal distribution and had tobe corrected for in preprocessing

414 PID controller

The Kalman lter state estimate can nally be used as the input to a PID throttle controller ThePID model used is a FOPDT integrating model The second input to the controller module is thesetpoint which can be set in the simulation via keyboard- or network-input to the application Therst working PID parametrisation was arrived at through manual tuning which is cumbersome andgives suboptimal results

415 Evolutionary parameter tuning

To prove the concept of using online learning within simulation at least the PID parameters wereoptimised using evolutionary strategies [22] [26] The tness function for this experiment wasconceivably simple chosen as

f(i) =

Nsum0

|xset minus xik| (4)

with individual i (a tuple (P ID)) setpoint xset the experiments duration in time steps N andthe altitude xik at time step k resulting from execution of controller i This stage involved setting upthe system so that simulation state and model parametrisation (the P I and D coecients) could

19

be controlled programmatically It was realised over a UDPIP connection between crrcsim andthe external simctrl control shell 21 implemented in the Python language 22 The results of theexperiment have been presented in [10]

42 MKcom2

MKcom short for MikroKopter communication tool was designed as a minimal software layer tosit on top of the UART communication link to the main ight board It provides a console baseduser interface for activation and conguration of a set of thin control functions and can act as agateway between the FC and a CMUcam MKcom functions can send commands to the FC andincoming UART packets are dispatched to the appropriate message handler This tool implementedthe modied MK message set

The setup was used as the basis for prototyping several versions of the control loop structureoutlined in Figures 12 and 13 The internal organisation of these implementations can be seenin Figure 14 Three dierent controller cores were realised which incrementally incorporated moremeasurement channels heuristic detail and safety hooks The detailed ow structure of the controllerdesign will be outlined below The update rate and execution timings are dictated by the arrivalof the measurement vector from the FC Auxiliary sensors were integrated asynchronously into themain loop A custom groundstation for state logging and realtime plotting was connected to thenetwork downlink indicated in the diagram

421 MKcom2 Flow structure

On startup a request for debug structure emission is sent manually from the mkcom shell to the FCwith the debug n command where n is the desired sampling interval in milliseconds An examplesession excerpt looks (slightly beautied) as follows (`gt indicates the shells command prompt `is the startsign of the MK protocol strings starting with ` is the raw ascii data going over thewire)gt debug 100

tx bdV ===Ds

gt

rxbuf 93 bD===IgtpU gtomgtS=xTyf=DL|pA= gt===Kl|Lnx=mL=I===i=BM|| oXfT_UrePI=T]=gt==E=|l|

L=IE||y===Y=qM

_DebugOut_ 1804 310 203 854 -843 420 -49 49 4

2 -21-1016 123 828 828 0 11 21

-1-5850 9822 -24267 51 94 1 2 -2

207 706 -1 0 7

rxbuf 93 bD===ggtpi gtm=gtT=oxzd]DL|o===m=A=Kl|ALnx=mL=I===E=m=== KxYSourePI=T]====A===

L=IM||y===Y=nf

_DebugOut_ 1834 315 192 855 -722 414 -49 32 3

4 -21-1008 123 828 828 0 2 15

0 -897811867-24267 51 94 0 1 0

207 708 -1 0 7

gt debug 0

tx bd====DZ

gt

21httpwww2informatikhu-berlinde~obertholQK22Python Language httpwwwpythonorg

20

The debug vector is populated in the FC where element positions correspond with value typesIt includes IMU data manual control input from the RC and the barometer as well as systemstatus values such as battery voltage RSSI value ampc Depending on the setup it can include thereading from the sonar as well If the actual controller is activated with eggt ac3 1

kal_cv_init DP 3 MP 5 CP 0

gt

the controller evaluation function is executed upon each arrival of a debug packet Of coursesome information is retained across calls After computation has nished an extctrl (Externalcontrol) structure is populated and sent back to the FC Aditional measurements such as from anInfraRed Ranger (IRR) are integrated in an asynchronous manner from multiple threads Severalparameters such as the altitude setpoint PID values bias ampc can also be set from the text based userinterface While this works quite well in principle and did achieve good performance modularityand extensibility were not an initial design goal This led to another iteration of the same designwithin the MAVHUB framework which will be described in the next subsection

IO Channels UART TWI UI Network

HAL threads FC-RX Expansion Ctrl Sonar Shell

Processing Controller

mkcom2

Figure 14 Mkcom2 ow-graph

43 Heuristically tuned altitude control software

The vague vision of the overall architecture that is pursued here is that of several concurring moduleswhich are summed in a cooperative time-dependent manner and where each module is responsiblefor various behavioural aspects [1] To ease prototyping and testing of components the structurehas to be kept exible extensible and dynamically recongurable This has to be considered in theoverall onboard software design In order to illustrate this requirement the ow of information andthe interaction with additional behavioural modules will be described in more detail in the followingparagraphs References will be made to several modules operating within the MAVHUB frameworkthe basics of which are described elsewhere [25]

431 Data acquisition

First the controlware has to collect all sensory information from possibly heterogenous sourcesThese include 6 - 9 channels of IMU data (depending on IMU type) a barometric measurementseveral range sensors as well as optical sensors (cameras) and of course any other sensor which is

21

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

1500

2000

Time [s]

Value

throttle

uss_meas

k_s0

Figure 15 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m aboveground The dashed line is the raw sonar range value the solid black line is the estimate uponwhich the PID controller acts The solid green line in the lower part of the plot is the controlleroutput value which is sent to the actuator

available or desired Heterogeneity pertains to hardware channels update rates and data formatsIn MAVHUB there are two main channels if information ow One is the protocol stack whichtransmits volatile incoming messages to all active modules (apps) The other is a shared memoryarea where data can be deposited by any active process In the setup considered here FC data(including IMU barometer and possibly sonar) and intermediate internal data travel on the stackSensors connected via a two-wire bus are operated by sensor drivers and measurements are put intothe shared memory The desired result of this step is to be able to operate on a homogenous vectorof input signals within the main control loop

432 Preprocessing

Subsequent to acquisition each sensory channel is individually preprocessed according to the pe-culiarities of sensor principle and connection mode Preprocessing mostly consists of linearisationunit conversion (inverting the sensor characteristic) and several kinds of heuristic validation

Linearisation For this particular setup linearisation only has to be done for the IRRs Theseare analogue sensors and the output voltage is related to the distance s measured via u(t) = 1

s(t) An example sensor characteristic is displayed in Figure 16 For the dierent subtypes of the Sharpsensors an individually parameterised procedure has to be performed as described by eg Acroname

22

Robotics in [23] if the sensors are processed on a metric basis If the Sharp sensors are driven atthe recommended supply voltage of 5V using the datasheet specications has proven sucientlyaccurate An example script for determining the parameters from given calibration data is suppliedon this reports supplementary website 22

Unit conversion The diverse units of sensor data have to be explicitly converted to units conve-nient for later steps in the calculation in particular sensor fusion with the Kalman lter For thealtitude measurements these are metersminus3 so ADC-units or time-of-ight measurements have to beconverted to millimeters for the analog sensors (barometer accelerometer infrared) and the sonarsensor repsectively This simply amounts to a multiplicative factor

Validation Heuristic sensor data validation has to be done for all types of rangers as well as for thebarometric sensor The spurious readings these sensors produce are of dierent types though Theinfrared rangers display ambigouity beyond the lower limit of the operating ranges see Figure 16For the GP2D120 which can sense the smallest ranges of all sensors this can be mostly neglectedsince the minimal sensing range can hardly be reached due to the mechanical conguration Forall the other sensors output is surpressed when the GP2D120 is active At the upper limit of theIRRs operating range the output is surpressed when a suitable threshold is reached The followingcode example illustrates this where sensor channel number three is the close range IRR

if(in_range(sensors [3] first llim ulim))

valid = 10

else

valid = 00

sensors [3] second = (fir[3]-gtcalc(valid) gt= 099) 1 0

Surpression is realised by setting appropriate values in the measurement transform matrix H(t)of the Kalman lter Alternatively this could be done by generating suitable variances for therespective sensors in the measurement covariance matrix R(t) Driving the IRRs at 33V works butreduces the usable range In addition the IRR sensor measurements are dependent on the groundsurfaces some of which eg an oce carpet can result in erratic results

The ultrasonic sensor is susceptive to dierent kinds of spurious readings caused by late echoesThis happens both when very close to an object or surface or when far away that is beyond theupper limit of measurable distances The validation strategy employed is to set hard empiricallower and upper limits for values as for the IRRs and limiting the maximum dierence betweentwo consecutive values based on assumptions about the maximum velocity An example session isillustrated in Figure 18

Finally the barometer is sensitive to acceleration which has to be accounted for The sensorbehaviour is displayed in Figure 19 The empirical corrections read

BARO (pre [1] correct from accel -z (pre [2])

pre [1] first -= (005 pre [2] first)

The validition process in general produces one new signal per channel to be used later in theprocess for setting Kalman lter matrix values One remaining problem here is the channel cross-dependency

23

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 19: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

sensors are aected by suciently dierent kinds of noise and thus eg spectrally complementarylters can be used on dierent measurement channels which are then linearily combined into a singlevalue Probably the most commonly used techniques are the linear Kalman lter and its nonlinearvariants Other methods are nonexhaustively Bayesian strategies such as Particle lters H-infinlters or neural networks A linear Kalman lter was chosen in the current setup for the reasonthat the lter and its characteristics are well documented and the implementation is straightforwardboth from scratch and even more so using matrix algebra libraries such as OpenCV The basic ltertask is to estimate the state xk isin Rn of a discrete time system governed by the linear stochasticequation [29] [15]

xk = Axkminus1 +Bukminus1 + wkminus1 (2)

based on a measurement zk isin Rm given as

zk = Hxk + vk (3)

where wk vk are random variables which represent process noise and measurement noise and arenormally distributed with zero mean p(wk) sim N(0 Q) p(vk) sim N(0 R) Q and R are the processand measurement noise covariance matrices The model used here consists of two state variablesx = (a dadt) with a the altitude (above ground) Later the model was extended to include d2adtso as to facilitate incorporation of accelerometer measurements One problem with the real sensorswas a clear deviation of the measurement noise from the assumed normal distribution and had tobe corrected for in preprocessing

414 PID controller

The Kalman lter state estimate can nally be used as the input to a PID throttle controller ThePID model used is a FOPDT integrating model The second input to the controller module is thesetpoint which can be set in the simulation via keyboard- or network-input to the application Therst working PID parametrisation was arrived at through manual tuning which is cumbersome andgives suboptimal results

415 Evolutionary parameter tuning

To prove the concept of using online learning within simulation at least the PID parameters wereoptimised using evolutionary strategies [22] [26] The tness function for this experiment wasconceivably simple chosen as

f(i) =

Nsum0

|xset minus xik| (4)

with individual i (a tuple (P ID)) setpoint xset the experiments duration in time steps N andthe altitude xik at time step k resulting from execution of controller i This stage involved setting upthe system so that simulation state and model parametrisation (the P I and D coecients) could

19

be controlled programmatically It was realised over a UDPIP connection between crrcsim andthe external simctrl control shell 21 implemented in the Python language 22 The results of theexperiment have been presented in [10]

42 MKcom2

MKcom short for MikroKopter communication tool was designed as a minimal software layer tosit on top of the UART communication link to the main ight board It provides a console baseduser interface for activation and conguration of a set of thin control functions and can act as agateway between the FC and a CMUcam MKcom functions can send commands to the FC andincoming UART packets are dispatched to the appropriate message handler This tool implementedthe modied MK message set

The setup was used as the basis for prototyping several versions of the control loop structureoutlined in Figures 12 and 13 The internal organisation of these implementations can be seenin Figure 14 Three dierent controller cores were realised which incrementally incorporated moremeasurement channels heuristic detail and safety hooks The detailed ow structure of the controllerdesign will be outlined below The update rate and execution timings are dictated by the arrivalof the measurement vector from the FC Auxiliary sensors were integrated asynchronously into themain loop A custom groundstation for state logging and realtime plotting was connected to thenetwork downlink indicated in the diagram

421 MKcom2 Flow structure

On startup a request for debug structure emission is sent manually from the mkcom shell to the FCwith the debug n command where n is the desired sampling interval in milliseconds An examplesession excerpt looks (slightly beautied) as follows (`gt indicates the shells command prompt `is the startsign of the MK protocol strings starting with ` is the raw ascii data going over thewire)gt debug 100

tx bdV ===Ds

gt

rxbuf 93 bD===IgtpU gtomgtS=xTyf=DL|pA= gt===Kl|Lnx=mL=I===i=BM|| oXfT_UrePI=T]=gt==E=|l|

L=IE||y===Y=qM

_DebugOut_ 1804 310 203 854 -843 420 -49 49 4

2 -21-1016 123 828 828 0 11 21

-1-5850 9822 -24267 51 94 1 2 -2

207 706 -1 0 7

rxbuf 93 bD===ggtpi gtm=gtT=oxzd]DL|o===m=A=Kl|ALnx=mL=I===E=m=== KxYSourePI=T]====A===

L=IM||y===Y=nf

_DebugOut_ 1834 315 192 855 -722 414 -49 32 3

4 -21-1008 123 828 828 0 2 15

0 -897811867-24267 51 94 0 1 0

207 708 -1 0 7

gt debug 0

tx bd====DZ

gt

21httpwww2informatikhu-berlinde~obertholQK22Python Language httpwwwpythonorg

20

The debug vector is populated in the FC where element positions correspond with value typesIt includes IMU data manual control input from the RC and the barometer as well as systemstatus values such as battery voltage RSSI value ampc Depending on the setup it can include thereading from the sonar as well If the actual controller is activated with eggt ac3 1

kal_cv_init DP 3 MP 5 CP 0

gt

the controller evaluation function is executed upon each arrival of a debug packet Of coursesome information is retained across calls After computation has nished an extctrl (Externalcontrol) structure is populated and sent back to the FC Aditional measurements such as from anInfraRed Ranger (IRR) are integrated in an asynchronous manner from multiple threads Severalparameters such as the altitude setpoint PID values bias ampc can also be set from the text based userinterface While this works quite well in principle and did achieve good performance modularityand extensibility were not an initial design goal This led to another iteration of the same designwithin the MAVHUB framework which will be described in the next subsection

IO Channels UART TWI UI Network

HAL threads FC-RX Expansion Ctrl Sonar Shell

Processing Controller

mkcom2

Figure 14 Mkcom2 ow-graph

43 Heuristically tuned altitude control software

The vague vision of the overall architecture that is pursued here is that of several concurring moduleswhich are summed in a cooperative time-dependent manner and where each module is responsiblefor various behavioural aspects [1] To ease prototyping and testing of components the structurehas to be kept exible extensible and dynamically recongurable This has to be considered in theoverall onboard software design In order to illustrate this requirement the ow of information andthe interaction with additional behavioural modules will be described in more detail in the followingparagraphs References will be made to several modules operating within the MAVHUB frameworkthe basics of which are described elsewhere [25]

431 Data acquisition

First the controlware has to collect all sensory information from possibly heterogenous sourcesThese include 6 - 9 channels of IMU data (depending on IMU type) a barometric measurementseveral range sensors as well as optical sensors (cameras) and of course any other sensor which is

21

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

1500

2000

Time [s]

Value

throttle

uss_meas

k_s0

Figure 15 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m aboveground The dashed line is the raw sonar range value the solid black line is the estimate uponwhich the PID controller acts The solid green line in the lower part of the plot is the controlleroutput value which is sent to the actuator

available or desired Heterogeneity pertains to hardware channels update rates and data formatsIn MAVHUB there are two main channels if information ow One is the protocol stack whichtransmits volatile incoming messages to all active modules (apps) The other is a shared memoryarea where data can be deposited by any active process In the setup considered here FC data(including IMU barometer and possibly sonar) and intermediate internal data travel on the stackSensors connected via a two-wire bus are operated by sensor drivers and measurements are put intothe shared memory The desired result of this step is to be able to operate on a homogenous vectorof input signals within the main control loop

432 Preprocessing

Subsequent to acquisition each sensory channel is individually preprocessed according to the pe-culiarities of sensor principle and connection mode Preprocessing mostly consists of linearisationunit conversion (inverting the sensor characteristic) and several kinds of heuristic validation

Linearisation For this particular setup linearisation only has to be done for the IRRs Theseare analogue sensors and the output voltage is related to the distance s measured via u(t) = 1

s(t) An example sensor characteristic is displayed in Figure 16 For the dierent subtypes of the Sharpsensors an individually parameterised procedure has to be performed as described by eg Acroname

22

Robotics in [23] if the sensors are processed on a metric basis If the Sharp sensors are driven atthe recommended supply voltage of 5V using the datasheet specications has proven sucientlyaccurate An example script for determining the parameters from given calibration data is suppliedon this reports supplementary website 22

Unit conversion The diverse units of sensor data have to be explicitly converted to units conve-nient for later steps in the calculation in particular sensor fusion with the Kalman lter For thealtitude measurements these are metersminus3 so ADC-units or time-of-ight measurements have to beconverted to millimeters for the analog sensors (barometer accelerometer infrared) and the sonarsensor repsectively This simply amounts to a multiplicative factor

Validation Heuristic sensor data validation has to be done for all types of rangers as well as for thebarometric sensor The spurious readings these sensors produce are of dierent types though Theinfrared rangers display ambigouity beyond the lower limit of the operating ranges see Figure 16For the GP2D120 which can sense the smallest ranges of all sensors this can be mostly neglectedsince the minimal sensing range can hardly be reached due to the mechanical conguration Forall the other sensors output is surpressed when the GP2D120 is active At the upper limit of theIRRs operating range the output is surpressed when a suitable threshold is reached The followingcode example illustrates this where sensor channel number three is the close range IRR

if(in_range(sensors [3] first llim ulim))

valid = 10

else

valid = 00

sensors [3] second = (fir[3]-gtcalc(valid) gt= 099) 1 0

Surpression is realised by setting appropriate values in the measurement transform matrix H(t)of the Kalman lter Alternatively this could be done by generating suitable variances for therespective sensors in the measurement covariance matrix R(t) Driving the IRRs at 33V works butreduces the usable range In addition the IRR sensor measurements are dependent on the groundsurfaces some of which eg an oce carpet can result in erratic results

The ultrasonic sensor is susceptive to dierent kinds of spurious readings caused by late echoesThis happens both when very close to an object or surface or when far away that is beyond theupper limit of measurable distances The validation strategy employed is to set hard empiricallower and upper limits for values as for the IRRs and limiting the maximum dierence betweentwo consecutive values based on assumptions about the maximum velocity An example session isillustrated in Figure 18

Finally the barometer is sensitive to acceleration which has to be accounted for The sensorbehaviour is displayed in Figure 19 The empirical corrections read

BARO (pre [1] correct from accel -z (pre [2])

pre [1] first -= (005 pre [2] first)

The validition process in general produces one new signal per channel to be used later in theprocess for setting Kalman lter matrix values One remaining problem here is the channel cross-dependency

23

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 20: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

be controlled programmatically It was realised over a UDPIP connection between crrcsim andthe external simctrl control shell 21 implemented in the Python language 22 The results of theexperiment have been presented in [10]

42 MKcom2

MKcom short for MikroKopter communication tool was designed as a minimal software layer tosit on top of the UART communication link to the main ight board It provides a console baseduser interface for activation and conguration of a set of thin control functions and can act as agateway between the FC and a CMUcam MKcom functions can send commands to the FC andincoming UART packets are dispatched to the appropriate message handler This tool implementedthe modied MK message set

The setup was used as the basis for prototyping several versions of the control loop structureoutlined in Figures 12 and 13 The internal organisation of these implementations can be seenin Figure 14 Three dierent controller cores were realised which incrementally incorporated moremeasurement channels heuristic detail and safety hooks The detailed ow structure of the controllerdesign will be outlined below The update rate and execution timings are dictated by the arrivalof the measurement vector from the FC Auxiliary sensors were integrated asynchronously into themain loop A custom groundstation for state logging and realtime plotting was connected to thenetwork downlink indicated in the diagram

421 MKcom2 Flow structure

On startup a request for debug structure emission is sent manually from the mkcom shell to the FCwith the debug n command where n is the desired sampling interval in milliseconds An examplesession excerpt looks (slightly beautied) as follows (`gt indicates the shells command prompt `is the startsign of the MK protocol strings starting with ` is the raw ascii data going over thewire)gt debug 100

tx bdV ===Ds

gt

rxbuf 93 bD===IgtpU gtomgtS=xTyf=DL|pA= gt===Kl|Lnx=mL=I===i=BM|| oXfT_UrePI=T]=gt==E=|l|

L=IE||y===Y=qM

_DebugOut_ 1804 310 203 854 -843 420 -49 49 4

2 -21-1016 123 828 828 0 11 21

-1-5850 9822 -24267 51 94 1 2 -2

207 706 -1 0 7

rxbuf 93 bD===ggtpi gtm=gtT=oxzd]DL|o===m=A=Kl|ALnx=mL=I===E=m=== KxYSourePI=T]====A===

L=IM||y===Y=nf

_DebugOut_ 1834 315 192 855 -722 414 -49 32 3

4 -21-1008 123 828 828 0 2 15

0 -897811867-24267 51 94 0 1 0

207 708 -1 0 7

gt debug 0

tx bd====DZ

gt

21httpwww2informatikhu-berlinde~obertholQK22Python Language httpwwwpythonorg

20

The debug vector is populated in the FC where element positions correspond with value typesIt includes IMU data manual control input from the RC and the barometer as well as systemstatus values such as battery voltage RSSI value ampc Depending on the setup it can include thereading from the sonar as well If the actual controller is activated with eggt ac3 1

kal_cv_init DP 3 MP 5 CP 0

gt

the controller evaluation function is executed upon each arrival of a debug packet Of coursesome information is retained across calls After computation has nished an extctrl (Externalcontrol) structure is populated and sent back to the FC Aditional measurements such as from anInfraRed Ranger (IRR) are integrated in an asynchronous manner from multiple threads Severalparameters such as the altitude setpoint PID values bias ampc can also be set from the text based userinterface While this works quite well in principle and did achieve good performance modularityand extensibility were not an initial design goal This led to another iteration of the same designwithin the MAVHUB framework which will be described in the next subsection

IO Channels UART TWI UI Network

HAL threads FC-RX Expansion Ctrl Sonar Shell

Processing Controller

mkcom2

Figure 14 Mkcom2 ow-graph

43 Heuristically tuned altitude control software

The vague vision of the overall architecture that is pursued here is that of several concurring moduleswhich are summed in a cooperative time-dependent manner and where each module is responsiblefor various behavioural aspects [1] To ease prototyping and testing of components the structurehas to be kept exible extensible and dynamically recongurable This has to be considered in theoverall onboard software design In order to illustrate this requirement the ow of information andthe interaction with additional behavioural modules will be described in more detail in the followingparagraphs References will be made to several modules operating within the MAVHUB frameworkthe basics of which are described elsewhere [25]

431 Data acquisition

First the controlware has to collect all sensory information from possibly heterogenous sourcesThese include 6 - 9 channels of IMU data (depending on IMU type) a barometric measurementseveral range sensors as well as optical sensors (cameras) and of course any other sensor which is

21

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

1500

2000

Time [s]

Value

throttle

uss_meas

k_s0

Figure 15 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m aboveground The dashed line is the raw sonar range value the solid black line is the estimate uponwhich the PID controller acts The solid green line in the lower part of the plot is the controlleroutput value which is sent to the actuator

available or desired Heterogeneity pertains to hardware channels update rates and data formatsIn MAVHUB there are two main channels if information ow One is the protocol stack whichtransmits volatile incoming messages to all active modules (apps) The other is a shared memoryarea where data can be deposited by any active process In the setup considered here FC data(including IMU barometer and possibly sonar) and intermediate internal data travel on the stackSensors connected via a two-wire bus are operated by sensor drivers and measurements are put intothe shared memory The desired result of this step is to be able to operate on a homogenous vectorof input signals within the main control loop

432 Preprocessing

Subsequent to acquisition each sensory channel is individually preprocessed according to the pe-culiarities of sensor principle and connection mode Preprocessing mostly consists of linearisationunit conversion (inverting the sensor characteristic) and several kinds of heuristic validation

Linearisation For this particular setup linearisation only has to be done for the IRRs Theseare analogue sensors and the output voltage is related to the distance s measured via u(t) = 1

s(t) An example sensor characteristic is displayed in Figure 16 For the dierent subtypes of the Sharpsensors an individually parameterised procedure has to be performed as described by eg Acroname

22

Robotics in [23] if the sensors are processed on a metric basis If the Sharp sensors are driven atthe recommended supply voltage of 5V using the datasheet specications has proven sucientlyaccurate An example script for determining the parameters from given calibration data is suppliedon this reports supplementary website 22

Unit conversion The diverse units of sensor data have to be explicitly converted to units conve-nient for later steps in the calculation in particular sensor fusion with the Kalman lter For thealtitude measurements these are metersminus3 so ADC-units or time-of-ight measurements have to beconverted to millimeters for the analog sensors (barometer accelerometer infrared) and the sonarsensor repsectively This simply amounts to a multiplicative factor

Validation Heuristic sensor data validation has to be done for all types of rangers as well as for thebarometric sensor The spurious readings these sensors produce are of dierent types though Theinfrared rangers display ambigouity beyond the lower limit of the operating ranges see Figure 16For the GP2D120 which can sense the smallest ranges of all sensors this can be mostly neglectedsince the minimal sensing range can hardly be reached due to the mechanical conguration Forall the other sensors output is surpressed when the GP2D120 is active At the upper limit of theIRRs operating range the output is surpressed when a suitable threshold is reached The followingcode example illustrates this where sensor channel number three is the close range IRR

if(in_range(sensors [3] first llim ulim))

valid = 10

else

valid = 00

sensors [3] second = (fir[3]-gtcalc(valid) gt= 099) 1 0

Surpression is realised by setting appropriate values in the measurement transform matrix H(t)of the Kalman lter Alternatively this could be done by generating suitable variances for therespective sensors in the measurement covariance matrix R(t) Driving the IRRs at 33V works butreduces the usable range In addition the IRR sensor measurements are dependent on the groundsurfaces some of which eg an oce carpet can result in erratic results

The ultrasonic sensor is susceptive to dierent kinds of spurious readings caused by late echoesThis happens both when very close to an object or surface or when far away that is beyond theupper limit of measurable distances The validation strategy employed is to set hard empiricallower and upper limits for values as for the IRRs and limiting the maximum dierence betweentwo consecutive values based on assumptions about the maximum velocity An example session isillustrated in Figure 18

Finally the barometer is sensitive to acceleration which has to be accounted for The sensorbehaviour is displayed in Figure 19 The empirical corrections read

BARO (pre [1] correct from accel -z (pre [2])

pre [1] first -= (005 pre [2] first)

The validition process in general produces one new signal per channel to be used later in theprocess for setting Kalman lter matrix values One remaining problem here is the channel cross-dependency

23

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 21: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

The debug vector is populated in the FC where element positions correspond with value typesIt includes IMU data manual control input from the RC and the barometer as well as systemstatus values such as battery voltage RSSI value ampc Depending on the setup it can include thereading from the sonar as well If the actual controller is activated with eggt ac3 1

kal_cv_init DP 3 MP 5 CP 0

gt

the controller evaluation function is executed upon each arrival of a debug packet Of coursesome information is retained across calls After computation has nished an extctrl (Externalcontrol) structure is populated and sent back to the FC Aditional measurements such as from anInfraRed Ranger (IRR) are integrated in an asynchronous manner from multiple threads Severalparameters such as the altitude setpoint PID values bias ampc can also be set from the text based userinterface While this works quite well in principle and did achieve good performance modularityand extensibility were not an initial design goal This led to another iteration of the same designwithin the MAVHUB framework which will be described in the next subsection

IO Channels UART TWI UI Network

HAL threads FC-RX Expansion Ctrl Sonar Shell

Processing Controller

mkcom2

Figure 14 Mkcom2 ow-graph

43 Heuristically tuned altitude control software

The vague vision of the overall architecture that is pursued here is that of several concurring moduleswhich are summed in a cooperative time-dependent manner and where each module is responsiblefor various behavioural aspects [1] To ease prototyping and testing of components the structurehas to be kept exible extensible and dynamically recongurable This has to be considered in theoverall onboard software design In order to illustrate this requirement the ow of information andthe interaction with additional behavioural modules will be described in more detail in the followingparagraphs References will be made to several modules operating within the MAVHUB frameworkthe basics of which are described elsewhere [25]

431 Data acquisition

First the controlware has to collect all sensory information from possibly heterogenous sourcesThese include 6 - 9 channels of IMU data (depending on IMU type) a barometric measurementseveral range sensors as well as optical sensors (cameras) and of course any other sensor which is

21

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

1500

2000

Time [s]

Value

throttle

uss_meas

k_s0

Figure 15 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m aboveground The dashed line is the raw sonar range value the solid black line is the estimate uponwhich the PID controller acts The solid green line in the lower part of the plot is the controlleroutput value which is sent to the actuator

available or desired Heterogeneity pertains to hardware channels update rates and data formatsIn MAVHUB there are two main channels if information ow One is the protocol stack whichtransmits volatile incoming messages to all active modules (apps) The other is a shared memoryarea where data can be deposited by any active process In the setup considered here FC data(including IMU barometer and possibly sonar) and intermediate internal data travel on the stackSensors connected via a two-wire bus are operated by sensor drivers and measurements are put intothe shared memory The desired result of this step is to be able to operate on a homogenous vectorof input signals within the main control loop

432 Preprocessing

Subsequent to acquisition each sensory channel is individually preprocessed according to the pe-culiarities of sensor principle and connection mode Preprocessing mostly consists of linearisationunit conversion (inverting the sensor characteristic) and several kinds of heuristic validation

Linearisation For this particular setup linearisation only has to be done for the IRRs Theseare analogue sensors and the output voltage is related to the distance s measured via u(t) = 1

s(t) An example sensor characteristic is displayed in Figure 16 For the dierent subtypes of the Sharpsensors an individually parameterised procedure has to be performed as described by eg Acroname

22

Robotics in [23] if the sensors are processed on a metric basis If the Sharp sensors are driven atthe recommended supply voltage of 5V using the datasheet specications has proven sucientlyaccurate An example script for determining the parameters from given calibration data is suppliedon this reports supplementary website 22

Unit conversion The diverse units of sensor data have to be explicitly converted to units conve-nient for later steps in the calculation in particular sensor fusion with the Kalman lter For thealtitude measurements these are metersminus3 so ADC-units or time-of-ight measurements have to beconverted to millimeters for the analog sensors (barometer accelerometer infrared) and the sonarsensor repsectively This simply amounts to a multiplicative factor

Validation Heuristic sensor data validation has to be done for all types of rangers as well as for thebarometric sensor The spurious readings these sensors produce are of dierent types though Theinfrared rangers display ambigouity beyond the lower limit of the operating ranges see Figure 16For the GP2D120 which can sense the smallest ranges of all sensors this can be mostly neglectedsince the minimal sensing range can hardly be reached due to the mechanical conguration Forall the other sensors output is surpressed when the GP2D120 is active At the upper limit of theIRRs operating range the output is surpressed when a suitable threshold is reached The followingcode example illustrates this where sensor channel number three is the close range IRR

if(in_range(sensors [3] first llim ulim))

valid = 10

else

valid = 00

sensors [3] second = (fir[3]-gtcalc(valid) gt= 099) 1 0

Surpression is realised by setting appropriate values in the measurement transform matrix H(t)of the Kalman lter Alternatively this could be done by generating suitable variances for therespective sensors in the measurement covariance matrix R(t) Driving the IRRs at 33V works butreduces the usable range In addition the IRR sensor measurements are dependent on the groundsurfaces some of which eg an oce carpet can result in erratic results

The ultrasonic sensor is susceptive to dierent kinds of spurious readings caused by late echoesThis happens both when very close to an object or surface or when far away that is beyond theupper limit of measurable distances The validation strategy employed is to set hard empiricallower and upper limits for values as for the IRRs and limiting the maximum dierence betweentwo consecutive values based on assumptions about the maximum velocity An example session isillustrated in Figure 18

Finally the barometer is sensitive to acceleration which has to be accounted for The sensorbehaviour is displayed in Figure 19 The empirical corrections read

BARO (pre [1] correct from accel -z (pre [2])

pre [1] first -= (005 pre [2] first)

The validition process in general produces one new signal per channel to be used later in theprocess for setting Kalman lter matrix values One remaining problem here is the channel cross-dependency

23

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 22: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

1500

2000

Time [s]

Value

throttle

uss_meas

k_s0

Figure 15 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m aboveground The dashed line is the raw sonar range value the solid black line is the estimate uponwhich the PID controller acts The solid green line in the lower part of the plot is the controlleroutput value which is sent to the actuator

available or desired Heterogeneity pertains to hardware channels update rates and data formatsIn MAVHUB there are two main channels if information ow One is the protocol stack whichtransmits volatile incoming messages to all active modules (apps) The other is a shared memoryarea where data can be deposited by any active process In the setup considered here FC data(including IMU barometer and possibly sonar) and intermediate internal data travel on the stackSensors connected via a two-wire bus are operated by sensor drivers and measurements are put intothe shared memory The desired result of this step is to be able to operate on a homogenous vectorof input signals within the main control loop

432 Preprocessing

Subsequent to acquisition each sensory channel is individually preprocessed according to the pe-culiarities of sensor principle and connection mode Preprocessing mostly consists of linearisationunit conversion (inverting the sensor characteristic) and several kinds of heuristic validation

Linearisation For this particular setup linearisation only has to be done for the IRRs Theseare analogue sensors and the output voltage is related to the distance s measured via u(t) = 1

s(t) An example sensor characteristic is displayed in Figure 16 For the dierent subtypes of the Sharpsensors an individually parameterised procedure has to be performed as described by eg Acroname

22

Robotics in [23] if the sensors are processed on a metric basis If the Sharp sensors are driven atthe recommended supply voltage of 5V using the datasheet specications has proven sucientlyaccurate An example script for determining the parameters from given calibration data is suppliedon this reports supplementary website 22

Unit conversion The diverse units of sensor data have to be explicitly converted to units conve-nient for later steps in the calculation in particular sensor fusion with the Kalman lter For thealtitude measurements these are metersminus3 so ADC-units or time-of-ight measurements have to beconverted to millimeters for the analog sensors (barometer accelerometer infrared) and the sonarsensor repsectively This simply amounts to a multiplicative factor

Validation Heuristic sensor data validation has to be done for all types of rangers as well as for thebarometric sensor The spurious readings these sensors produce are of dierent types though Theinfrared rangers display ambigouity beyond the lower limit of the operating ranges see Figure 16For the GP2D120 which can sense the smallest ranges of all sensors this can be mostly neglectedsince the minimal sensing range can hardly be reached due to the mechanical conguration Forall the other sensors output is surpressed when the GP2D120 is active At the upper limit of theIRRs operating range the output is surpressed when a suitable threshold is reached The followingcode example illustrates this where sensor channel number three is the close range IRR

if(in_range(sensors [3] first llim ulim))

valid = 10

else

valid = 00

sensors [3] second = (fir[3]-gtcalc(valid) gt= 099) 1 0

Surpression is realised by setting appropriate values in the measurement transform matrix H(t)of the Kalman lter Alternatively this could be done by generating suitable variances for therespective sensors in the measurement covariance matrix R(t) Driving the IRRs at 33V works butreduces the usable range In addition the IRR sensor measurements are dependent on the groundsurfaces some of which eg an oce carpet can result in erratic results

The ultrasonic sensor is susceptive to dierent kinds of spurious readings caused by late echoesThis happens both when very close to an object or surface or when far away that is beyond theupper limit of measurable distances The validation strategy employed is to set hard empiricallower and upper limits for values as for the IRRs and limiting the maximum dierence betweentwo consecutive values based on assumptions about the maximum velocity An example session isillustrated in Figure 18

Finally the barometer is sensitive to acceleration which has to be accounted for The sensorbehaviour is displayed in Figure 19 The empirical corrections read

BARO (pre [1] correct from accel -z (pre [2])

pre [1] first -= (005 pre [2] first)

The validition process in general produces one new signal per channel to be used later in theprocess for setting Kalman lter matrix values One remaining problem here is the channel cross-dependency

23

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 23: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

Robotics in [23] if the sensors are processed on a metric basis If the Sharp sensors are driven atthe recommended supply voltage of 5V using the datasheet specications has proven sucientlyaccurate An example script for determining the parameters from given calibration data is suppliedon this reports supplementary website 22

Unit conversion The diverse units of sensor data have to be explicitly converted to units conve-nient for later steps in the calculation in particular sensor fusion with the Kalman lter For thealtitude measurements these are metersminus3 so ADC-units or time-of-ight measurements have to beconverted to millimeters for the analog sensors (barometer accelerometer infrared) and the sonarsensor repsectively This simply amounts to a multiplicative factor

Validation Heuristic sensor data validation has to be done for all types of rangers as well as for thebarometric sensor The spurious readings these sensors produce are of dierent types though Theinfrared rangers display ambigouity beyond the lower limit of the operating ranges see Figure 16For the GP2D120 which can sense the smallest ranges of all sensors this can be mostly neglectedsince the minimal sensing range can hardly be reached due to the mechanical conguration Forall the other sensors output is surpressed when the GP2D120 is active At the upper limit of theIRRs operating range the output is surpressed when a suitable threshold is reached The followingcode example illustrates this where sensor channel number three is the close range IRR

if(in_range(sensors [3] first llim ulim))

valid = 10

else

valid = 00

sensors [3] second = (fir[3]-gtcalc(valid) gt= 099) 1 0

Surpression is realised by setting appropriate values in the measurement transform matrix H(t)of the Kalman lter Alternatively this could be done by generating suitable variances for therespective sensors in the measurement covariance matrix R(t) Driving the IRRs at 33V works butreduces the usable range In addition the IRR sensor measurements are dependent on the groundsurfaces some of which eg an oce carpet can result in erratic results

The ultrasonic sensor is susceptive to dierent kinds of spurious readings caused by late echoesThis happens both when very close to an object or surface or when far away that is beyond theupper limit of measurable distances The validation strategy employed is to set hard empiricallower and upper limits for values as for the IRRs and limiting the maximum dierence betweentwo consecutive values based on assumptions about the maximum velocity An example session isillustrated in Figure 18

Finally the barometer is sensitive to acceleration which has to be accounted for The sensorbehaviour is displayed in Figure 19 The empirical corrections read

BARO (pre [1] correct from accel -z (pre [2])

pre [1] first -= (005 pre [2] first)

The validition process in general produces one new signal per channel to be used later in theprocess for setting Kalman lter matrix values One remaining problem here is the channel cross-dependency

23

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 24: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

0 50 100 150 200 250 300 350 400

0

1

2

3

4

5

lower limit

Range [mm]

Voltage[V]

Measured with 33V supply

Datasheet

Measured with 5V supply

Figure 16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the measure-ments with 33V supply the dashed red line is the GP2D120x variant measured with a 5V supplyand the dashed black line is the data from the datasheet

0 2 4 6 8 10 12 14 16 18 20

0

200

400

600

800

1000

Time [s]

Value

IR1

IR1 valid

IR2

IR2 valid

Figure 17 Example linearised and validated measurements from two IRRs The dotted step-functionlike graphs at the bottom indicate validity of the respective channel while the red horizontal barsindicate the empricial upper limits

Further aspects When raw IMU data is used for attitude estimation an incremental updatehas to be performed on the state variables to be able to execute the strapdown calculation on theacceleration data In the MK case this is already done by the FlightCtrl and the angular rateintegral as well as the z-acceleration in the navigation frame is provided via the sensor link Sincethere was no compass onboard the prototype system the full strapdown calculation could not bedone for the x and y dimensions

Additional complications can arise from the asynchronous data delivery of the various sensorsParticularly the sonar sensors are limited to low rates of measurement due to the relatively low

24

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 25: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

0 5 10 15 20 25 30 35 40 45 50

0

500

1000

1500

2000

2500

Time [s]

Value

USS USS valid Kalman est

Figure 18 USS measurements during a 50 sec ight over wooden planks gravel and a piece ofelevated ground The USS outliers can clearly be seen The pulse-shaped graph at the bottom isthe USS valid signal which is feed into the Kalman measurement transform matrix

2 3 4 5 6 7 8 9 10

minus2000

minus1000

0

1000

2000

Time [s]

Value

Barometer z-Accel middot01

Figure 19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visible The actualz-acceleration value is scaled with a factor of 01

speed of sound A distance of 2 meters gives 4 meters of eective range to be travelled by the sonicpulse resulting in a time of ight of approximately 12 ms Acquisition of infrared ranging data wasrun at approximately 100 Hz In practice this means that care has to be taken to lter raw sensorvalues at sensor acquisition rate rather than at control loop rate

25

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 26: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

433 Sensor fusion and state estimation

The device employed in this system for sensor data fusion is a linear Kalman lter (KF) as intro-duced above The formalism requires the dierent measurements to be expressed in equal unitsThis necessitates the unit conversion step described above The lter is then able to combine redun-dant information into a single state estimate based on the consecutive prediction and measurementupdate steps Several variants of lter implementation were tested The nal choice was the KFclass provided by the OpenCV 23 library The output of the Kalman lter are three state vari-ables vertical position velocity and acceleration The position estimate is used as the input tothe controller while the second derivative is needed for measurement integration of the verticalacceleration

There are several potential renements of this processing step First of all the control inputcould be integrated to improve the models prediction via the Buk term in formula 2 There alsoexist nonlinear variants of the basic KF such as the Extended Kalman lter (EKF) and UnscentedKalman lter (UKF) which extend the linear evolution at the cost of additional computing timeSince the quadrotor behaves almost linearly in the near hover ight regime and the linear KFsperformance was sucient in practice these were not further explored Several other techniquesexist for fusing sensory information (see above) but none of these were tested yet in ight Finallythe entire ow structure including sensor communication and processing is illustrated in Figure 20

434 Controller

The process to be controlled is modelled as a First Order Plus Dead Time (FOPDT) integratingmodel The implemenation is realised in standard discretised form given by

CO = bias+Kp

(e(tk) +

1

Ti

tksuml=0

e(tl)4t+ Tde(tk)minus e(tkminus1)

4t

)(5)

where the error term e(tk) is given by the dierence of the altitude set-point xset and the currentaltitude estimate x0 which is the rst component of the state vector estimate x from Equation 2

e(tk) = xset minus x0(tk) (6)

The set-point can be changed by the operator via some conventional user interface mechanismor it can be mapped onto a physical control device such as the gas stick of the RC transmitterThe controller parametrisation for the real helicopter was accomplished via a recipe based approachborrowed from the Practical Process control e-book 24 The bias is determined empirically as avalue slightly below take-o lift within Ground eect (GE) The controller works robustly acrossa variety of congurations that is varying payloads within ground eect and in free ight Thechange in system behaviour during the transition from GE to free ight and back can be clearlyobserved when doing a system bump test as shown in gures 21 which is required by the integratingcontroller tuning recipe The controller could successfully be transferred and run on a secondhelicopter without modication The same parameters have also been used across the two dierent

23Open Computer-Vision [[httpopencvwillowgaragecom][httpopencvwillowgaragecom]]24Practical Process Control httpwwwcontrolgurucom

26

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 27: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

USS IR1 IR2 Baro IMU

ExpCtrl FC

TWI UART

Demux Demux

Measurement vector x1 x5

Linearisation

Unit conversion

Validation

Kalman

State vector s0 s1 s2

to Controller

Figure 20 State estimation ow diagram The top row represents the physical sensors the secondrow are the interface electronics thrird and fourth row are communication elements Everythingbelow the demultiplexers is the preprocessing and state estimation chain

implementations (mkcom2 MAVHUB) without problems The PI and D parameters yield fromthe system behaviour via Equations 7 8 9 and 10 where θp and Tc denote dead time and processtime constant respectively

Integration gain Klowastp = PV(CO middot time) (7)

Controller gain Kc =1

Klowastp

2Tcθp

(Tc +12θp)

2(8)

Reset time Ti = 2Tc + θp (9)

Deriv time Td =14θ

2p + Tcθp

2Tc + θp(10)

Dead time and controller output are extracted from the graphical system bump result plot seethe le controller-tuningpy in 22

27

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 28: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

22 24 26 28 30 32 34

0

500

1000

1500

2000

thr start

resp onset 1

thr change

resp onset 2

slope 1 slope 2

Time [s]

Alt[m

m]

USS Baro Estimate

22 24 26 28 30 32 34

0

100

200

300

400

500

Time [s]

Value

Throttle (commanded) Throttle (actual)

Figure 21 System bump test with mkcom2 At throttle start throttle is bumped from value 0 toslight climb (375) Approx 600ms later response can be read from the sensors At thr changethe throttle is changed to a slow descend value of 365 with response starting at approx responset 2 From the three points of resp onset 1 resp onset 2 and slope 2 touchdown thecontroller parameters can be calculated

44 Alternatives

The robot controllers described so far are while generally working the result of cumbersome tuningprocesses Especially sensor validation and fusion heuristics are very fragile Consequently it is de-sirable to have some other algorithmic device which robustly achieves the same without hand-tuningbut which can be trained from experimental data One such method that has been preliminarilytested is Slow Feature Analysis (SFA)

28

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 29: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

441 Slow Feature Analysis

SFA is an unsupervised learning algorithm for extracting slowly varying features from aquickly varying input signal [31]

In prosaic terms the SFA algorithm works as follows First the quickly varying input signalis expanded into a nonlinear function space (eg polynomials) Then the expanded signals isnormalised to have zero mean and unit variance via eg Principal Component Analysis (PCA)By looking at the time derivative of the transformed signal the least varying component(s) can beidentied and extracted

While this method has not been tested online a preliminary test was run on recorded datato evaluate the algorithms output with regards to its applicability to sensor fusion and lteringThe Python MDP Toolkit was used for this run which yielded promising results as can be seen inFigure 22

45 Camera experiments

As a concluding example of the prototyping methodology described so far by means of the altitudecontrol problem an optical compass used for yaw stabilisation will be described The actual imageprocessing setup is part of an ongoing diploma thesis and will be described in detail elsewhere [19]A Logitech USB webcam with a panoramic lens attached is used as image sensor and mounted ontop of the robot which can be seen in Figure 23

451 Optical compass

The optical compass is used to determine the yaw deviation compared to a stored snapshot Themeasured deviation is connected through a linear gain to the yaw component of u from Equation 1resulting in a P-only yaw-rate controller The controller output is superimposed on the manualyaw input In the ight experiments the helicopter yaw was perturbed via manual input up to thepoint of equilibrium of manual gain and compass gain Upon release of the Yaw-stick of the RCthe helicopter reliably returns to level yaw angle

For this experiment the BeagleBoard depicted in Figure 9 was running a standalone imageacquisition and processing module transmitting an adequate structure containing the compassinformation via MAVLink over Ethernet to the Gumstix The Gumstix in turn is running all ofthe FC communication groundstation downlink and altitude controller code within MAVHUB asin all the other epxeriments described above

5 Results and future work

51 Results

A exible network of computational extensions can be attached to a basic RC model quadrotor andthusly enable control of basic functions provided by the vendor rmware SBCs running EmbeddedLinux are exible in terms of the necessary hardware connections and the operating system itselfprovides the familiarly rich toolset for almost any task One of the implicit hopes is to be ableto swap the underlying base kits to take advantage of improved or dierent capabilities whileproviding high-level control and more complex sensors through an unchanged setup In that regard

29

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 30: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

70 75 80 85 90 95

0

500

1000

1500

2000

2500

Time [s]

Alt[m

m]

IRR2 Baro USS

70 75 80 85 90 95

minus1

0

1

Time [s]

Value

Slow

Figure 22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers The raw readingsare displayed in the upper graph while extracted slow feature is plotted in the lower part The slowcomponent is dimensionless but morphologically correct

the altitude control problem was used to bootstrap and verify a design methodology as well asinvestigate aspects of software architecture

52 Overall performance

Many tests were performed over indoor and outdoor surfaces such as linoleum wood agstonegravel grass and bushes A selection of dierent runs is documented in Figure 24

30

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 31: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

53 Timing

One critical issue with using Linux is to achieve deterministic timing No hard realtime extensionsfor Linux were used Timing was evaluated on the basis of practical adequacy The main loopexecution jitter is neglible in comparison with the overall loop dead time Single sample basedprocessing reduces the overall latency and is realistic at sample rates below 500Hz The maximumsampling rate on the kind of system investigated has not been determined but is expected to bequite variable dependent on the hardware used An architectural consequence is the possibility ofoboard real-time controllers which might provide additional convenience for prototyping Thisapproach has been shown to work by others [17] Still immediate testing in the target environmentis advantageous in keeping the surprise rate at steady level In Figure 25 and Figure 26 the inter-sample delays are plotted for both the data-driven processing loop in mkcom2 as well as for thesoft-regulated loop in the MAVHUB asynchronous controller

54 Graceful degradation

Using an operating system introduces additional points of failure During all tests the currentsetup proved benign in this regard Nonetheless handshakes between the dierent control hardwarecomponents should be used to be able to trigger emergency landings or other fallback routines inlower control layers in case of system hangups

55 Conclusion

While there is much room for improvement in nearly all directions it appears that the basic decisionsregarding the experimental approach used here support many future routes and will interoperatewell with diverse componentry This seems important regarding the rapid pace of ongoing researchin this area which requires the ability to quickly take advantage of results from a wide variety ofprojects

6 Acknowledgements

I would like to thank in alphabetical order Ferry Bachmann Verena Hafner Carsten Huhn Math-ias Muumlller Andreas Pieper and Michael Schulz for inspiration discussion support and good tem-per Additionally i would like to thank in order of appearance Henryk Ploumltz Matthew Currie(anonymously) Roger Quinn and Antoine Drouin for permission to include photographs of dier-ent systems

7 List of Abbreviations

AC ArduCopter 10

APM ArduPilotMega 10

COM Computer on Module 10

DoF Degress of Freedom 7

EKF Extended Kalman lter 26

ESC Electronic Speed Controllers 9

31

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 32: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

FDM Flight Dynamics Model 18

FOPDT First Order Plus Dead Time 26

FC FlightCtrl 9

FR Flying Robots 2

GE Ground eect 26

GPS Global Positioning System 3

HUCH Humboldt University Copter Heros

IMU Inertial Measurement Units 6

IRR InfraRed Ranger 21

KF Kalman lter 26

MAV Micro Aerial Vehicles 7

MAVHUB Micro Aerial Vehicle Humboldt Universitaumlt zu Berlin 12

MK MikroKopter 9

PCA Principal Component Analysis 29

PCB Printed Circuit Board 11

PPZ Paparazzi 9

PWM Pulse Width Modulation

PXH PIXHAWK 10

QGC QGroundControl 10

SBC Single Board Computers 10

SFA Slow Feature Analysis 28

TWI Two Wire Interface 13

UAV Unmanned Aerial Vehicles 3

UAVP-NG Unmanned Aerial Video Platform Next Generation 10

UKF Unscented Kalman lter 26

USS UltraSonic Sonar

VTOL Vertical TakeO and Landing 5

List of Figures

1 In 1(a) the robot maintains and absolute altitude The range sensors are eithersurpressed or the robot is too far away from the ground to be able to measure thedistance In 1(b) the robot follows the contour of the terrain 5

2 Dierent possible airframe types for ying robots a) experimental workhorse Horstb) E-Flite Blade MCX S300 photograph by Henryk Ploumltz with kind permission c)Multiplex FunJet photograph from Paparazzi Wiki by Matthew Currie d) Flappingwing platform photograph by Henryk Ploumltz also with permission 6

32

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 33: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

3 Some less prevalent airframe congurations a) and b) Morphing Micro Air andLand Vehicle (MMALV) Photograph courtesy of Richard Bachmann of BioRobotsLLC and Roger Quinn of Case Western Reserve University and c) and d) a Paparazzibased quadrotor with two airfoils (tail sitter design) The pictures are two framesextracted from a video by Antoine Drouin Joby Robotics with kind permission 7

4 Distance measurement depending on the angle θ to the ground surface 85 Theoretical error over angle for several dierent distances from ground 86 The Gumstix Verdex is sandwiched between the MikroKopter FlightCtrl board below

and the expansion board on above On top is a USB WiFi dongle 137 The electronic stack on this copter consists of (in ascending order) FC Power and

UART breakout Beagle breakout and Arduino Mini mount BeagleBoard and USBWiFi Dongle 14

8 Range sensors attached to frame 159 Basic HUCH onboard electronics The left hand region of the picture consisting

of receiver FC and brushless motor controllers BL1minus4 represents the standard MKsetup while the right hand region represents HUCH additions 15

10 Basic Linux setup 1611 Simulation screenshot The helicopter model landscape and text console are part

of crrcsim The actual debugging output that can be seen in the console is part ofcustom modications 17

12 Controller structure with measurement branch 1813 Simplied controller structure 1814 Mkcom2 ow-graph 2115 Mkcom2 controller performance The helicopter is set to keep an altitude of 15 m

above ground The dashed line is the raw sonar range value the solid black line isthe estimate upon which the PID controller acts The solid green line in the lowerpart of the plot is the controller output value which is sent to the actuator 22

16 Sensor characteristic for the Sharp GP2D120(x) The solid green line are the mea-surements with 33V supply the dashed red line is the GP2D120x variant measuredwith a 5V supply and the dashed black line is the data from the datasheet 24

17 Example linearised and validated measurements from two IRRs The dotted step-function like graphs at the bottom indicate validity of the respective channel whilethe red horizontal bars indicate the empricial upper limits 24

18 USS measurements during a 50 sec ight over wooden planks gravel and a pieceof elevated ground The USS outliers can clearly be seen The pulse-shaped graphat the bottom is the USS valid signal which is feed into the Kalman measurementtransform matrix 25

19 Barometer and z-acceleration graphs Here the copter experiences two hard smacksand the barometers deviation correlated to the accelerometer value is clearly visibleThe actual z-acceleration value is scaled with a factor of 01 25

20 State estimation ow diagram The top row represents the physical sensors thesecond row are the interface electronics thrird and fourth row are communicationelements Everything below the demultiplexers is the preprocessing and state esti-mation chain 27

33

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 34: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

21 System bump test with mkcom2 At throttle start throttle is bumped from value 0to slight climb (375) Approx 600ms later response can be read from the sensors Atthr change the throttle is changed to a slow descend value of 365 with responsestarting at approx resp onset 2 From the three points of resp onset 1 responset 2 and slope 2 touchdown the controller parameters can be calculated 28

22 Slow Feature Analysis run on three components of the raw altitude measurementsThese were the ultrasonic sonar the barometer and one of the infrared rangers Theraw readings are displayed in the upper graph while extracted slow feature is plottedin the lower part The slow component is dimensionless but morphologically correct 30

23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller) 3724 Altitude state estimate evolution during controlled altitude over some ten seconds

for a set of low setpoints over wood carpet and grass The other three variables wereunder manual control The carpet segment can be clearly made out in a) and b) 38

25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quiterobust as control-loop execution is triggered by the arrival of a data packet from theFlightCtrl 39

26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz 39

References

[1] Ronald C Arkin Behaviour Based Robotics MIT Press 1998

[2] Richard J Bachmann Frank J Boria Ravi Vaidyanathan Peter G Ifju and Roger D Quinn Abiologically inspired micro-vehicle capable of aerial and terrestrial locomotion Mechanism andMachine Theory 44(3)513 526 2009 ISSN 0094-114X doi DOI101016jmechmachtheory200808008 URL httpwwwsciencedirectcomsciencearticleB6V46-4TMHKRG-12

33da4bb0c1b534dc552f1c568d1811d4 Special Issue on Bio-Inspired Mechanism Engineering

[3] Walter Bittner Flugmechanik der Hubschrauber - Technologie das ugdynamische SystemHubschrauber Flugstabilitaumlten Steuerbarkeit Springer 2009

[4] Samir Bouabdallah and Roland Siegwart Full Control of a Quadrotor In Proceedings of the2007 IEEERSJ International Conference on Intelligent Robots and Systems pages 1531582007 URL httpsirslabdiiunisiitdownloadirosdatapapers0181pdf inc - qk- 0181pdf

[5] Samir Bouabdallah Andreacute Noth and Roland Siegwart PID vs LQ control techniques appliedto an indoor micro quadrotor In In IEEE International Conference on Intelligent Robots andSystems (IROS pages 24512456 2004

[6] P Castillo A Dzul and R Lozano Real-time stabilization and tracking of a four rotormini-rotorcraft IEEE Transactions on Control Systems Technology 2004 525pdf

[7] crrcsim Development Team Charles River Radio Controllers Simulation Nov 2010 URLhttpcrrcsimberliosde

34

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 35: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

[8] Carsten Deeg Modeling simulation and implementation of an autonomously ying robot PhDthesis TU Berlin 2006

[9] Dario Floreano Jean-Christophe Zuerey Mandyam V Srinivasan and Charlie Ellingtoneditors Flying Insects and Robots Springer 2009

[10] Verena V Hafner Ferry Bachmann Oswald Berthold Michael Schulz and Mathias MuumlllerAn autonomous ying robot for testing bio-inspired navigation strategies In Proceedings forthe joint conference of ISR 2010 (41st International Symposium on Robotics) and ROBOTIK2010 (6th German Conference on Robotics) VDE Verlag 2010

[11] Tim Hansen Aufbau einer Quadrokopterregelung basierend auf einem Intertialen Navigation-ssystem Technical report Technische Universitaumlt Darmstadt Fachbereich Elektrotechnik undInformationstechnik 2009

[12] Helmut Hoelzer Anwendung elektrischer netzwerke zur loumlsung von dierentialgleichungen undzur stabilisierung von regelvorgaumlngen Masters thesis Fakultaumlt fuumlr Mathematik und PhysikTH Darmstadt 1946 Hoelzer - Anwendung elektrischer Netzwerkepdf

[13] Gabe Homann Dev Gorur Rajnarayan Steven L Wasl Phd C Claire J Tomlin and Assis-tant Professor The stanford testbed of autonomous rotorcraft for multi agent control (starmacIn In Proceedings of the 23rd Digital Avionics Systems Conference 2004

[14] Gabriel M Homann Haomiao Huang Steven L Wasl and Er Claire J Tomlin Quadrotorhelicopter ight dynamics and control Theory and experiment In In Proc of the AIAAGuidance Navigation and Control Conference 2007

[15] Hugh Durrant-Whyte Multi Sensor Data Fusion Jan 2011 URL httpwwwacfrusyd

eduaupdfstrainingmultiSensorDataFusiondataFusionNotespdf Lecture Notes

[16] Jan Lunze Regelungstechnik 1 - Systemtheoretische Grundlagen Analyse und Entwurf ein-schleiger Regelungen Springer 2008

[17] Johannes Meyer Personal communication 2010

[18] Ralf Moumlller Das Ameisenpatent Spektrum 2006

[19] Mathias Muumlller Ongoing diploma thesis expected to be nished in 2011

[20] Eryk Brian Nice Design of a four rotor hovering vehicle Masters thesis Cornell University2004 inc - Designof4RotHoverVehiclepdf

[21] Paul Pounds Robert Mahony and Peter Corke Modelling and control of a quad-rotor robotIn Proceedings of the Australasian Conference on Robotics and Automation 2006 2006 URLhttpeprintsquteduau33767

[22] Ingo Rechenberg Evolutionsstrategie Optimierung technischer Systeme nach Prinzipien derbiologischen Evolution Frommann Holzboog 1973

[23] Acroname Robotics Linearizing sharp ranger data Dec 2010 URL httpwwwacroname

comroboticsinfoarticlesirlinearirlinearhtml

35

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 36: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

[24] Franck Ruer and Nicolas H Franceschini Visually guided micro-aerial vehicle Automatictake o terrain following landing and wind reaction In ICRA pages 23392346 IEEE 2004

[25] Michael Schulz MAVHUB Ein auf MAVLink basierendes Robotik Framework Student re-search project in the Bio-inspired navigation group HU Berlin 2011

[26] Dario Floreano Stefano Nol Evolutionary Robotics MIT Press 2000

[27] John von Neumann A rst draft of a report on the EDVAC Technical report Moore Schoolof Electrical Engineering University of Pennsylvania 1945

[28] John von Neumann The Computer and the Brain Yalw University Press 1958

[29] Greg Welch and Gary Bishop An Introduction to the Kalman Filter

[30] Norbert Wiener Cybernetic or control and communication in the animal and the machineWiley 1948

[31] L Wiskott P Berkes M Franzius H Sprekeler and N Wilbert Slow feature analysisScholarpedia 6(4)5282 2011

[32] Jens Wilhelm Wulf How to adjust multicopter parameters multicopter model version 1Technical report - 2009

[33] LA Young EW Aiken JL Johnson R Demblewski J Andrews and J Klem New conceptsand perspectives on micro-rotorcraft and small autonomous rotary-wing vehicles Technicalreport NATIONAL AERONAUTICS AND SPACE ADMINISTRATION MOFFETT FIELDCA ROTORCRAFT DIVISION 2002

[34] Jean-Christophe Zuerey Bio-inspired Flying Robots EPFL Press 2008 URL httpbook

zuffinfo

36

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 37: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

Figure 23 Quadrotor with panoramic camera attached at the top (Photograph by Mathias Muumlller)

37

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 38: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(a) Flying over wooden oor at 300 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(b) 500 mm

0 5 10 15 20 25 30 35 40 45 50 55 60

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(c) 800 mm

6 8 10 12 14 16 18 20 22 24 26 28 30

0

500

1000

Time [s]

Dist

[mm]

Setpoint Alt est

(d) and at 400 mm over grass

Figure 24 Altitude state estimate evolution during controlled altitude over some ten seconds fora set of low setpoints over wood carpet and grass The other three variables were under manualcontrol The carpet segment can be clearly made out in a) and b)

38

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations
Page 39: An Approach to UAV Controller Prototyping with Linuxoberthol/QK/Studienarbeit.pdf · An Approach to UAV Controller Prototyping with Linux Student research project (Studienarbeit)

0 1 2 3 4 5 6 7 8 9 10

05

1

2

3middot10minus2

Time [s]

dt[s]

dt

Figure 25 Mkcom2 controller timing behaviour at a sampling rate of 100 Hz The dt oscillatesbetween the values 001s and 002s Disregarding the oscillation the timing is quite robust ascontrol-loop execution is triggered by the arrival of a data packet from the FlightCtrl

0 2 4 6 8 10 12 14

2

21

22

23

24

25middot10minus2

Time [s]

dt[s]

dt

Figure 26 MAVHUB controller timing behaviour at a sampling rate of 50 Hz

39

  • Abstract
  • Introduction
    • Flying robots
    • Navigation problem
    • Bio-inspired robotics
    • What is a Controller
    • What is altitude control
    • About this text
      • Systems
        • Airframes
        • Quadrotor systems overview
        • HUCH Sytem
          • Experiments
            • Basic structural design through simulation
            • MKcom2
            • Heuristically tuned altitude control software
            • Alternatives
            • Camera experiments
              • Results and future work
                • Results
                • Overall performance
                • Timing
                • Graceful degradation
                • Conclusion
                  • Acknowledgements
                  • List of Abbreviations