Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
Substance Abuse Montcalm, Michigan
Next
Download to read offline and view in fullscreen.

0

Share

Download to read offline

FYP Report rev34 AM-10-04-15

Download to read offline

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to like this

FYP Report rev34 AM-10-04-15

  1. 1. M.ENG RESEARCH PROJECT APRIL 2015 1  Abstract— A prototype autonomous airship and control system was developed and tested. Despite being among the earliest types of unmanned aerial vehicles to receive research attention, airships remain attractive as a platform because they can attain longer flight times and are inherently more stable in air than equivalent helicopters or multirotors. Previous autonomous blimps have required a connection to a computer on the ground, or carefully calibrated multi-camera rigs in order to calculate their pose relative to their target. This project instead utilizes currently available low-cost lightweight hardware and open- source software to perform all processing on board the blimp. The controller, running on a Linux microcomputer, combines pose estimates from a downward looking camera, motion vector estimates from video and an eleven degree-of-freedom inertial measurement unit to control the vehicle altitude, heading and speed in station-keeping and follow-me tests. The system was tuned and evaluated using indoor test flights. Index Terms— Autonomous airship, blimp, pose estimation, unmanned aerial vehicle, visual servoing. I. INTRODUCTION NMANNED AERIAL VEHICLES, popularly referred to as ‘drones’ or UAVs, first emerged in the 1950s, but in the last 15 years have become a topic of growing research, commercial and public interest. Applications of UAV technology are widespread and ever increasing, from military and surveillance uses to agriculture and package delivery. Two different perspectives on civilian UAV usage are provided by [1] and [2]; numerous other technology reviews have been written exploring uses in specific fields [3]. Several factors have combined to drive this expansion. Key technologies (including System-on-a-Chip (SoC) processors, lightweight lithium polymer batteries and microelectronic sensors) have matured and become mass-market as a result of widespread adoption of smartphone-like devices. These components are now able to meet the twin requirements for UAV technologies: real-time performance and small physical size and weight [4], [5]. Building UAVs was initially only feasible for well-resourced organisations but today the open-source, crowd-funding and hobbyist movements have lowered the barrier to entry. Smaller companies, researchers and individuals can now share their systems, designs, research and code with the community [6]. Capitalising on the now widespread availability of UAV components and associated computing platforms, this project set out to deliver a blimp system suitable for developing visual controls, with applications in wide area persistent surveillance and mapping missions. The indoor prototype, presented in Figure 1, has a flight duration of four hours and uses imagery and an Inertial Measurement Unit (IMU) to station-keep relative to an image target beneath. Major components are all commercially available items, resulting in a low cost, lightweight system. Figure 1 – Prototype blimp system in flight in the lab. Blimp is 3.5m long, flying around 4m above ground In the rest of this section, prior work in UAV airships is briefly reviewed and the objectives for this project are outlined. The main sections of this paper then present the blimp, review a dynamic model suitable for closed-loop control and outline the autopilot software. The chosen control techniques are evaluated on the blimp platform before applications and areas for future work are suggested. A. Airships and blimps Airships are traditionally defined as craft whose main source of lift is buoyancy from an envelope of lighter than air gas, i.e. Helium. Blimps are airships without a rigid skeleton. An ideal blimp is neutrally buoyant in air, only requiring powered thrust to move or change direction. As a result, compared to multirotor drones of equivalent payloads, an ideal blimp has far smaller inflight power consumption. Untethered Autonomous Flight Using Visual and Inertial Sensing on an Indoor Blimp Andrew Mathieson supervised by Dr Toby Breckon U
  2. 2. M.ENG RESEARCH PROJECT APRIL 2015 2 Lithium Polymer batteries, the current de-facto standard for UAV applications, have an energy storage density of ~200 Wh/kg [7], so reduced power consumption directly corresponds to longer flight durations, mitigating one of the major drawbacks of current research UAVs. B. Review of selected previous UAV blimps Blimps as UAVs have received research interest since the late-1990s, when AURORA, a 9 m long blimp carrying radios, a forward-looking camera and a PC104 format computer was built and used for environmental monitoring [8]. The autopilot for that blimp was developed in a Matlab environment using a detailed model of the non-linear blimp dynamics For navigation, AURORA primarily used differential-GPS to fly between waypoints but the forward-looking camera was also utilised to follow parallel lines such as road markings [9]. That project was successful and contributed important applications of control theory to blimps. The complications of outdoor flight, in particular wind gusts and aviation regulations, meant that, to date, most research blimps have been designed for indoor flight and have used the well-established model of a ground controller to perform computations, relaying instructions to the in-flight hardware. The usual position location method for drones, GPS or similar, is known to be unreliable indoors [10], so research has instead explored vision based navigation. In [11] a blimp was localised using data from static cameras, this work was repeated in [12] using a roof mounted camera that looked down on the blimp to estimate its pose relative to the floor. Both achieved a stable closed loop response. Building on this, the multicamera motion-capture system used in [13] was able to achieve path-planning around multiple objects and through doors, maintaining knowledge of the blimp position to within ±30 mm. Whilst such fine accuracy is very desirable in an indoor blimp, outside of the carefully controlled environments navigation is impossible. The other approach, as favoured by this project and many others, is to place a small lightweight camera on-board the blimp and estimate the pose of the blimp based on features in the environment. In [14], a 1.5 m long remote-controlled blimp platform able to carry a pan/tilt wireless camera was built and flown. That project included consideration of component weight and lift capacity. Low-cost servomotors, required due to weight constraints, caused some electrical noise problems. C. Objectives for his project This project built on the extensive literature to deliver a blimp platform suitable for control engineering and UAV vision development. The test case for the blimp is station-keeping relative to a target. If the target is stationary this behaviour corresponds to position holding and is an important prerequisite for docking and rendezvousing [15]. If the target moves, ability to follow it is useful for tasks such as wildlife monitoring and crowd observation. Following a moving target is also a prerequisite for more complex behaviours including search and vehicle tracking. Previous projects relied on communication to a ground station to augment their on-board systems and the blimp itself was unable to fly without the help of equipment on the ground. In this project, the control system is realised completely on board the blimp. Moving away from reliance on ground-based computation/location will allow ‘untethered’ teleoperation, operation in potentially hazardous environments, and operation in environments where good positioning may be hard to acquire. II. THE BLIMP The contribution of this project has been to demonstrate untethered autonomous flight of a blimp using entry-level components. The work culminated in building a prototype whose specifications are summarised in Table 1: Envelope 3.5 m x 2 m ⌀ x 0.8 mm thick PVC, weight 3.73 kg. Encloses 4.5 m 3 , net lift 1 kg. Propulsion & steering Two-off 200 mm ⌀ propellers, each with 8 V brushless dc motor, vectored thrust. Power supply 5500 mAh 11.1V Lithium Polymer battery Control Raspberry Pi 2 teleoperated via Wi-Fi Sensing & Electronics IMU; 720p HD camera; Custom PCB stackup integrating all components. Optical isolation to reduce electrical noise Table 1 – Blimp as-built specification Using commodity parts where possible resulted in a total component cost of £140, and the gas-retaining envelope cost a further £200. A graphic breakdown is found in Appendix A. A. Envelope and weight budget In the literature, most blimps built for indoor research were around 2 m in size. Procurement issues with small blimp envelopes required this project to use a slightly larger 3.5 m envelope, which weighs 3.73 kg and can carry a 1 kg payload. Variable atmospheric conditions can affect the lifting capacity by ±75 g between flights so ballast is employed to trim the blimp to neutral buoyancy prior to each flight. Components were selected to minimise weight, with some custom work where off-the-shelf parts would have been unacceptably bulky. The payload weight (excluding envelope self-weight) is broken down by component in Figure 2. Figure 2 –Payload weight breakdown, units kg. 0.45 0.31 0.05 0.07 0.16 0.06 0.01 0.02 5500mAh LiPo battery Frame; bolts; other Raspberry Pi; Wi-Fi; Camera Motor; servos Case; other ABS parts PCBs; electronics IMU; PWM driver Ballast
  3. 3. M.ENG RESEARCH PROJECT APRIL 2015 3 B. Microcomputer choice Numerous lightweight embedded platforms are now available. A recent review of some of these platforms with relevance to UAVs may be found in [4]. This project selected the Raspberry Pi 2 Linux microcomputer, primarily for its matching camera module and hardware support. The software architecture, described in Section IV, is split into four concurrent threads to utilise the quad-core ARM CPU. The camera module connects directly to the Broadcom SoC using a wide SCI bus, so some of the video processing workload can be handled in the GPU. In Section V this capability is used to estimate the motion of the blimp alongside the main CPU-bound pose estimation routine. Other peripherals are connected to an I2C bus and General Purpose Input/Outputs (GPIOs). C. Electronics The payload electronics design for this project is shown as a block diagram in Figure 3. The camera module and microcomputer are located at the bottom of the stackup and receive 5 V power from the logic power regulator. Above this, a custom PCB integrates the IMU and Pulse Width Modulation (PWM) output driver. A second custom PCB locates the optical isolation and buffering required for control of the motors and servos. Figure 3 – Electronics block diagram The two primary propulsion units are brushless DC motor driven propellers as used in quadcopters. Directional control is achieved by vectoring the thrust direction using servo motors with a range of ±90° A secondary board provides sixteen extra channels of 12 bit PWM output for the microcontroller (NXP Semiconductor PCA9685). The 11 degree-of-freedom inertial measurement unit (Adafruit Industries, [17]) integrates three microelectronic sensors: L3DG20H 3-axis gyroscope; LSM303DLHC 3-axis accelerometer and 3-axis magnetometer; BMP180 barometric pressure & temperature sensors. Both boards communicate with the microcomputer via an I2C bus. Logic systems are supplied with a regulated 5 V supply to prevent interference from electrically noisy actuators. The microcomputer takes around 30 s to reboot after an interruption, during which time actuator control cannot be assured, loss of power in flight is something to be avoided. It was noted in [14] that electrical noise, particularly from micro servos could interfere with effective video capture under certain circumstances. To prevent this, this project implemented optocouplers on the PWM and GPIO signal lines. Six twin-channel optocouplers are included; each buffered to the correct voltage for driving servos and motors using an op-amp. Component values were chosen to achieve an almost linear throttle response; a circuit diagram is in Appendix A. Optocouplers also prevent excess current damage to the microcontroller pins which could occur in fault conditions such as an accidental short circuit of the motors. Blimps flown outdoors frequently utilise additional actuators on the tail for greater manoeuvrability [18]. In readiness for future work where these may be required, the design also included two isolated bidirectional DC drivers. D. Power The main flight battery, powering the motors and servos, is a 5500 mAh Lithium Polymer battery, weight 0.448 kg. A secondary battery (capacity 1000 mAh, weight 58 g) was provided to allow use of the logic systems independently of the motors, allowing communication and remote control functionality to be confirmed before the motors are powered. The main battery can power the electronics for a theoretical maximum duration of greater than 7 hrs. During flight tests of manoeuvring and active station keeping, a low level of motor thrust was maintained continuously, so the estimated real- world battery life of the system is around 4 hrs. Current mid-market multirotors, by comparison, typically have quoted flight times less than 1 hr with little ability to carry spare batteries so in this respect the advantage of lighter- than-air platforms remains clear. The complete system is housed in a 3D-printed case, with aluminium arms that support the propeller units, as shown in Figure 4. Figure 4 – Blimp payload. Inset – Logic PCB showing IMU and PWM breakouts III. BLIMP DYNAMICS Developing a controller for the blimp begins with understanding its flight characteristics. In this section, the coordinate frames used are defined and then the method of [15] is followed to formulate an equation of motion for the blimp. The focus throughout is on the sources of simplifying assumptions and how they affect the controller design. vectoring servos frame attaches to envelope downward looking camera brushless motors 3D-printed case PCBs inside IMU PWM
  4. 4. M.ENG RESEARCH PROJECT APRIL 2015 4 A. Coordinate frames A blimp has a minimum of six degrees of freedom: the 𝑋, 𝑌, 𝑍 position and 𝑦𝑎𝑤, 𝑝𝑖𝑡𝑐ℎ, 𝑟𝑜𝑙𝑙 rotations relative to the ground; plus any extra degrees of freedom required to model changes in shape during flight. These extra deformational degrees of freedom can be neglected by assuming that the envelope of the blimp is inflated taught so does not deform, and that the payload is rigidly affixed to the envelope. For the rigid body motions, an ego-centric coordinate system is used, with its origin at the centre of mass of the payload. Instead of tracking the motions of the blimp relative to the world, the system tracks the motion of objects in the world relative to itself. In the egocentric frame, 𝑋 direction is positive forwards, 𝑍 is positive upwards, and 𝑌 is positive to the right. 𝑦𝑎𝑤, 𝑝𝑖𝑡𝑐ℎ and 𝑟𝑜𝑙𝑙 are defined in the conventional way (Figure 5). The principal axes of the IMU are aligned with the egocentric coordinate system; transformation of camera pose estimates into the ego frame is discussed below. Figure 5 – Blimp coordinate frame and envelope dimensions Hereafter, the pose of the blimp, these six coordinates, is denoted by the 6x1 vector {x}. B. Aerodynamics The blimp is equipped with two main propellers which are driven at variable speeds (from 0 to 8000 rpm), and directed at an angle between ±90° to provide vectored thrust. Common mode thrust provides forward/backward and up/down control; differential thrust provides control of 𝑦𝑎𝑤. The settings of these four actuators are the output of the controller. This blimp therefore has more degrees of freedom than actuators – it is under-actuated. To resolve this, further simplifying assumptions are required before developing a controller. The first of these is that 𝑝𝑖𝑡𝑐ℎ is decoupled from 𝑋 velocity, and effectively constant. This assumption amounts to neglecting the effect of aerodynamic lift or downforce as the blimp flies forward. Aero forces are proportional to velocity squared, so at the low speeds of flight (typically less than 1 m/s indoors) the symmetrical shape of the blimp envelope means lift is small and so this assumption is valid. At higher speeds and in strong prevailing winds, as experienced by outdoor blimps, these forces do become considerable, so aerilons and rudders are used on commercial outdoor blimps. The blimp envelope used here was originally intended for static advertising use so its four inflatable fins serve no aerodynamic purpose. An aerodynamic effect which is not negligible, however, is drag. The literature on airship drag has used wind tunnel data to estimate drag coefficients for large, outdoor flying envelopes of various aspect ratios at various Reynolds numbers [19]. Authors investigating small indoor blimps such as this have assumed that drag forces can be assumed to be a simple function of velocity, in effect assuming that any transitional, turbulent or form drags can be neglected and that the only important source of drag is skin friction [15]. As this blimp is larger than the 2 m model used in [15], this assumption has been tested by comparing the flight Reynolds number (i) of this blimp to an estimated critical Reynolds number 𝑅𝑒 𝑐𝑟𝑖𝑡for blimps in air. 𝑅𝑒𝑓𝑙𝑖𝑔ℎ𝑡 = 𝜌 𝑢 𝑥 𝐿 𝜇 = (1.22 𝑘𝑔 𝑚3⁄ )(1 𝑚 𝑠⁄ )(3.5 𝑚) (1.84 × 10−5 𝑃𝑎𝑠) = 2.3 × 105 (i) Wind tunnel tests of the HALROP stratospheric blimp [19] suggested that transition from laminar to turbulent boundary layer (and hence from skin friction dominated to pressure dominated drag) occurred at 𝑅𝑒 𝑐𝑟𝑖𝑡 = 7.5 × 105 . That blimp, like those analysed in the literature related to transitional flows around blimp hulls, has a streamlined shape with an aspect ratio of 1 /6. In comparison, 𝑅𝑒 𝑐𝑟𝑖𝑡 for a sphere (aspect ratio 1) is 3.8 × 105 [20]: compared to a sphere, the streamlined blimp shape reduces the adverse pressure gradient experienced by the boundary layer, and prevents it transitioning until a higher Reynolds number. When inflated, the blimp in this project has an aspect ratio closer to ½, with an almost hemispherical front. As the aspect ratio of this blimp lies between that of a sphere and that of HALROP, it is reasonable to assume their respective critical Reynolds numbers are lower and upper bounds for 𝑅𝑒 𝑐𝑟𝑖𝑡 of this blimp. In any case, as 𝑅𝑒𝑓𝑙𝑖𝑔ℎ𝑡 is less than the assumed lower bound for 𝑅𝑒 𝑐𝑟𝑖𝑡, the boundary layer may be assumed to remain laminar, and the assumption made by [15] of drag being proportional only to velocity squared holds. For larger blimps, blimps that fly faster than this or blimps with additional aerilons the laminar drag assumption should be re-examined. Laminar drag coefficients for planar and rotational motions of a model blimp (with aspect ratio 1 /3, 𝑅𝑒𝑓𝑙𝑖𝑔ℎ𝑡 = 1 × 105 ) were obtained experimentally in [18] – in the absence of any more applicable low speed data, these values may be utilised. Neglecting drag coefficients which represent interactions between degrees of freedom, (justified by the low flight speed), and absorbing constant factors such as the blimp cross- sectional area and air density into the terms, a 6x6 drag coefficient matrix, [𝐶 𝑑] may be obtained. Multiplying this by the velocities squared ({ẋ}2 ) gives the 6x1 vector of drag forces in the ego frame. The second simplifying assumption required is that roll and rolling motion is constant and negligible. This assumption is validated by concentrating the centre of mass of the blimp/payload below the centre of buoyancy which helps return the blimp to zero 𝑟𝑜𝑙𝑙 and 𝑝𝑖𝑡𝑐ℎ. ℎ Payload centre envelope⌀2m Port Stbd
  5. 5. M.ENG RESEARCH PROJECT APRIL 2015 5 C. Mass, inertia and centripetal effects The all-up mass, 𝑚, of this blimp is 4.6 kg: 3.73 kg envelope material 𝑚 𝑒, 0.874 kg payload, plus ballast to balance. Neglecting gas leakage which is very slow, this mass is assumed to be constant throughout each flight. Moments of inertia about the for each of the three rotational motions ( 𝐽 𝑦𝑎𝑤, 𝐽 𝑝𝑖𝑡𝑐ℎ, 𝐽𝑟𝑜𝑙𝑙) can be calculated using standard formulae if the blimp is approximated as an ellipsoid with major axis 3.5 m and minor axes 2 m. A real blimp also displaces a large volume of air as it flies or rotates so its effective mass and inertia are much greater than would be expected from the formulae [15]. Coefficients for this additional mass and inertia ( 𝑚 𝑎 𝑥,𝑦,𝑧 , 𝐽 𝑎 𝑦𝑎𝑤,𝑝𝑖𝑡𝑐ℎ,𝑟𝑜𝑙𝑙 ) are given by Figure 6.10 in [21], with b/a, the aspect ratio = 2/3.5. Due to the symmetry of modelling the blimp as an ellipsoid, 𝑚 𝑎 𝑦 = 𝑚 𝑎 𝑧 , 𝐽 𝑦𝑎𝑤 = 𝐽 𝑝𝑖𝑡𝑐ℎ, likewise 𝐽 𝑎 𝑦𝑎𝑤 = 𝐽 𝑎 𝑝𝑖𝑡𝑐ℎ . 𝐽 𝑎 𝑟𝑜𝑙𝑙 is considered negligible. These form the diagonal terms of the 6x6 mass matrix [𝑀]. The effect of off-diagonal terms, which would represent the inertia on coupling between degrees of freedom, and the effect of centripetal forces, has been ignored since flight speed is low. D. External forces Buoyancy, gravity, forces and moments from the thrusters, and any other disturbances (e.g. gusts) act as external forces on the blimp. For an envelope of volume 𝑉𝑒and air and helium at laboratory conditions the lift is calculated with (ii): Payload, kg = 𝑉𝑒(𝜌 𝑎𝑖𝑟 − 𝜌 𝐻𝑒) − 𝑚 𝑒 4.5 m3(1.22 kg/m3 − 0.17 kg/m3) − 3.73 kg = 1 kg (ii) Ideally, the weight is balanced by the buoyancy. During flights this is rarely perfect, so the thrusters either provide a constant downforce (if too heavy), or the blimp is held at a constant height using ballast (if too buoyant). By controlling the vertical component of the thrust, closed-loop regulation of height is achieved during flights. The thrusters create a turning moment if a differential thrust is applied, allowing control of the 𝑦𝑎𝑤 and 𝑟𝑜𝑙𝑙 degrees of freedom. In common with most airships, there is no ability to directly actuate in the 𝑌 direction, however the non-linearity present in the blimp response to thrust means this can usually be overcome with a combination of 𝑋 and 𝑦𝑎𝑤 motions. In indoor flight gusts can usually be prevented; the remaining forces are denoted as the 6x1 vector {𝐹𝑒𝑥𝑡}. E. Dynamic model The assumptions related to each term in the blimp dynamics equation (iii) have now been examined. [𝑀]{ẍ} + [𝐶 𝑑]{ẋ}2 + {𝐹𝑒𝑥𝑡} = {0} , from [15] (iii) Even this simplified model of the blimp is non-linear. In section VI the real world stability of the blimp is compared to predictions of classical control methods using this model. IV. SOFTWARE Software for controlling blimps was first explored in detail by the AURORA project [9], which, in common with many robots, used a hierarchical control model. In this project, a similar controller has been implemented, with the enhancement that an additional PC on the ground is not required. All control work, including handling pilot input and providing a GUI, is carried out by the microcomputer on- board the blimp. In the current implementation, the blimp may be piloted either by sending instructions from a (Bluetooth) keyboard, or by connecting wirelessly using Virtual Network Computing (VNC) to view the GUI. For routine flights VNC is preferred as it gives the pilot a full overview of the software; however important quality-of-service and flight safety concerns arise when relying on a wireless network for control, [22], so direct control using the keyboard is retained as a fall-back option. A. Software architecture The software, written in Python, is structured into four threads, each of which has a scope of responsibility as outlined in Table 2. Threads interact by setting and polling flags and data structures in the global namespace. Mutual exclusion operators control access to shared data and resources. thread initialisation runtime termination Graphical User Interface Thread Load data Initialise GUI Start other threads Respond to pilot input, Queue jobs for hardware Verify termination; Save log files. Hardware Abstraction Thread Set motor home states; Get initial IMU pose Control motors as required by job queue Poll the IMU Stop and home motors Autopilot Thread Fuse pose information from camera and IMU; Generate autopilot jobs Vision Thread Open camera, start recording Visual and motion pose estimation Close camera; save video. Table 2 – Four-thread software architecture In operational conditions the GUI Thread is responsible for starting each of the other threads. When all threads have successfully initialised, operation may begin. Interactions between the threads are shown in a flowchart in Appendix B. B. Hardware abstraction and error handling Actuators are represented by objects containing state variables for direction and thrust. These reside in the namespace of the Hardware Abstraction Thread and only that thread gets direct access to the hardware to manage race conditions and prevent actuators receiving conflicting instructions. Other code, such as the GUI, keyboard and autopilot, generates jobs (instructions describing what hardware changes are required when) into a queue managed by the Hardware Abstraction Thread. Jobs may have start times immediately or scheduled for the future; jobs may have variable priorities; jobs may be blocking (having a defined execution time) or non-blocking
  6. 6. M.ENG RESEARCH PROJECT APRIL 2015 6 (assumed to take place as soon as they are due) and they may or may not recur again at a future time. When jobs are added to the queue, the logic in Figure 6 is applied to decide if a hardware update is required; otherwise, the thread polls the IMU for new pose measurements. Figure 6 – Job prioritisation logic This design ensures good pose estimates are available when required, and also ensures a high-priority job (e.g. an emergency stop) is able to override any lower priority jobs that might otherwise block the queue. In the event of an unexpected runtime problem that is not caught by its parent thread, the main thread issues stop instructions to the hardware job queue and terminates the other threads. This ensures that the actuator outputs (particularly the brushless motors) are not left in an undetermined state post-termination. C. Multitasking performance By splitting compute-intensive work such as vision processing into separate threads the job queue can remain responsive to pilot input even if another thread is busy. The four-threaded structure is also well suited to the quad- core processor of this microcomputer allowing the system to achieve a maximum throughput of 5.8 fps using 320 x 240 px images. In comparison, the single core predecessor Model B+ could only achieve around 1 fps at this image size. V. POSE ESTIMATION & CONTROL In the previous three sections the prototype vehicle has been presented, a dynamic model for blimps in flight outlined, and the high level software stack described. The challenge of controlling the prototype is now addressed. In the context of the four-thread architecture, the following methods are implemented by the Vision Thread and the Autopilot Thread. A. Pose estimation from camera For any control problem, reliable information about the current system state is essential. Here, this is the pose vector {x} = {𝑋, 𝑌, 𝑍, 𝑦𝑎𝑤, 𝑝𝑖𝑡𝑐ℎ, 𝑟𝑜𝑙𝑙} 𝑇 . As noted above, this blimp is not equipped with GPS (unreliable indoors) or a differential location method (useless without calibrated equipment independent of the blimp). Instead, the most effective sensor for pose estimation is the on-board camera. The camera was calibrated using the technique of [23] to calculate its distortion matrix – before each flight this is loaded from a file. Incoming video frames are converted to grayscale and de-distorted using the preloaded camera matrix. The image is then checked for the presence of the target – a planar chessboard pattern. Detection of the chessboard during flight uses the same method as in calibration – if found, the pose may then be estimated. The camera is located in the centre of the payload facing straight down onto the floor and target, allowing easy calculation of the rotation [𝑅] and translation {𝑡} relative to the target using the perspective-n-point solution of [24]. Requiring the floor and image plane to remain parallel is equivalent to assuming that 𝑟𝑜𝑙𝑙 and 𝑝𝑖𝑡𝑐ℎ disturbances can be neglected. In Section III it was seen that slow flight speeds and high inertia of the blimp ensures this is usually the case. Expressing the rotation as a 3x3 Rodrigues form matrix, the rotational pose coordinates are recovered using(iv) and the positional pose coordinates {𝑋, 𝑌, 𝑍} using (v): { 𝑦𝑎𝑤 𝑝𝑖𝑡𝑐ℎ 𝑟𝑜𝑙𝑙 } = { tan−1 ( 𝑅1,2 𝑅1,1 ) −tan−1 ( 𝑅3,2 𝑅3,3 ) tan−1 ( −𝑅3,1 √(𝑅3,2)2 + (𝑅3,3)2 ) } {𝑋, 𝑌, 𝑍} 𝑇 = −[𝑅] 𝑇 {𝑡} (iv) (v) Where 𝑅1,2 etc. refer to terms of the Rodrigues matrix. The pose estimation method is run on a small image, 320x240 px, with two iterations of subpixel refinement to improve reliability of the pose data supplied to the autopilot controller. The trade-off between reliability and framerate in a bench test is assessed in Table 3. In this test, a ‘bad pose estimate’ is defined as a disagreement of greater than 20° from ground truth in any of the three Euler angles, while the blimp is stationary over the target for one minute. As expected, larger images give superior accuracy, however a very slow frame rate is undesirable for controller stability. Equally, the marginal decrease in bad pose rate using unlimited refinement does not justify the frame rate penalty incurred. The selected configuration is highlighted in bold; it allows refined images to be processed at 4.8 fps. Of the good estimates, 90% are within ±5° of ground truth. To try to counter this 5° variability by continuously functioning actuators would be inefficient and shorten component lifetimes, so instead controllers ignore fluctuations in this small range. Once the blimp has been controlled to be within tolerance of the target heading the natural stability of the blimp in the air helps it to remain in place.
  7. 7. M.ENG RESEARCH PROJECT APRIL 2015 7 Rate of bad pose estimates and frame rate No subpixel refinement Two iterations of refinement Unlimited iterations Small image 320 x 240px 0.72 bad poses/s at 5.8 fps 0.43 bad poses/s at 4.8 fps 0.39 bad poses/s at 2.2 fps Large image 640 x 480px 0.11 bad poses/s at 1.8 fps 0.09 bad poses/s at 1.8 fps 0.08 bad poses/s at 0.7 fps Table 3 – Reducing rate of bad pose estimates by changing image size and number of refinement iterations. In the ‘unlimited iterations’ case, refinement stops when the change in corner location is less than 0.001 px. B. Pose estimation from Inertial Measurement Unit The IMU, as described above, contains five sensors: accelerometer, magnetometer (compass), gyroscope (each with 3 orthogonal axes), barometric pressure and temperature. The pressure sensor gives a direct reading the height above sea level of the blimp, using the ISA barometric formula. The nominal resolution of this sensor is ±0.1 m, although in test conditions this variability was found to be ±0.25 m. Tests on the bench indicated that height readings are normally distributed about the true height, so in flight, variability of height estimates is smoothed by taking the mean of the most recent ten samples. Flight altitude 𝑍 is calculated by subtracting the current height above sea level from the height above sea level at takeoff. Similarly, with the magnetometer giving a measurement of 𝑦𝑎𝑤 relative to the North direction and the accelerometer giving measurements for 𝑝𝑖𝑡𝑐ℎ and 𝑟𝑜𝑙𝑙 relative to gravity, the current flight pose relative to the start is also calculated by the IMU software [24]. Calculating positional coordinates by double-integrating IMU accelerations is generally considered to be ineffective because measurement noise is greatly exacerbated by the integration process, so the IMU is currently only used for rotational pose estimation. C. Velocity estimation using H.264 The final source of pose information is the optic flow in the scene, which in steady flight is correlated to the motion of the camera over the scene. Unlike the direct pose estimation, this method does not require a specific target in the scene, instead it can work using features in the natural environment. The camera used natively records video in H.264 (MPEG AVC) format. An intermediate step in the H.264 encoding process is to calculate the optic flow in each 16x16 pixel macroblock. In common with many modern SoCs, this encoding process is implemented using the graphic processing unit instead of the CPU, happily, the camera drivers allow access to these intermediates, permitting analysis of the motion domain as well as the image domain. Each time the camera encodes a video frame, the motion field is copied to memory using a HSV colour space to represent the direction of the motion field, sum-of-absolute- differences measure and magnitude of the motion field at each pixel, in a similar manner as used in [25]. In this application it was found that the GPU can work about five times faster than the CPU so to avoid unnecessary computation HSV motion arrays are only processed when camera pose data is also ready. The aim of the motion processing is to reduce the incoming motion field into four estimates: the direction and magnitude of the foreground and background motion. To achieve station keeping relative to a target in the foreground, the controller tries to minimise the motion relative to the foreground, and keep the motion relative to the background constant. In the case of a stationary target, the background motion should additionally be zero. The MPEG block-matcher that achieves this motion encoding is not as robust as a specialised optic flow routine, so the produced motion fields tend to be very noisy. Furthermore, the level of motion detected is not always independent of scene features. This is demonstrated in Figure 7, where the brightest colours indicate largest motion and the mapping from motion direction to hue is given in the key. The ground truth here is the camera moving forwards over the chessboard. In the HSV array, the predominant hue is red, corresponding to a direction of around 0° as expected. However, in some macroblocks the motion has been incorrectly classified the motion incorrectly (green). Figure 7 – Captured image with located chessboard axes overlaid; Motion HSV representation of same frame, strongest motion is detected in the chessboard area and along the bottom edge; Key. In many frames the signal-to-noise ratio is high so a clustering approach would frequently misclassify noisy background pixels as foreground and vice versa. Instead, the components of the motion field are considered, and the noise is modelled as Gaussian white noise present at a low level in every macroblock. Otsu’s thresholding [26] is used to binarise the magnitude of the motion field, removing small-magnitude noise from the frame, leaving the larger magnitude motion which must be classified as either foreground or background. A histogram of the directions of these motions with bin widths corresponding to 5 degree intervals is computed, and the modal class is taken to be the average direction of the foreground’s motion. For the HSV motion array shown above, this method estimated the foreground motion direction to be at 353 ° which is in good agreement with the ground truth. The performance of this motion segmenter implementation on the blimp is evaluated over a larger number of tests in Table 4. In general, performance is satisfactory, although better performance is seen when the blimp is moving relative to a stationary target than when both the target and the background are experiencing large magnitude motion. In the final column of Table 4, if the target has already been located, a region-of-interest around the target is used to denote the foreground. In the problematic moving background case, this method helps, however it relies on the target being in view.
  8. 8. M.ENG RESEARCH PROJECT APRIL 2015 8 Scenario Ground truth motion direction Number of frames where motion estimate is within ±10° of ground truth Fore- ground Back- ground Fore- ground Back- ground Using ROI Flight over stationary target 0° None 86/ 177 91/ 177 38/ 41 Flight over moving target None 180° 53 /124 66 /124 20/ 53 Table 4 – Experimental verification of H.264 motion direction segmentation, acquired in the lab. A weakness of this current implementation of motion direction estimation is that it is not able to correctly detect or compensate for out-of-plane motion. The motion classifier presented in [25] solves this by compared the incoming data to a large library of pre-computed motion fields. D. Sensor Fusion Once all sources of pose estimates have been resolved into the ego frame, the simplest way to combine them into a single best guess is to take a weighted average. Here, the weights awarded to each component were optimised experimentally to minimise the disagreement between the different pose sources over a large number of samples in controlled conditions. In autopilot mode sensor fusion runs at 5 Hz, limited by the vision system refresh rate. Improved techniques for combining sensor data have been widely explored in the literature, where Kalman Filtering is a commonly used technique. In [26], two filter formulations are combined to fuse IMU and chessboard derived pose information. An opportunity for future work would be to apply that work to this blimp, and extend it by incorporating the motion directions estimates and their estimated uncertainties into state transitions. Such a ‘motion augmented’ fusion method should give more reliable pose estimates than the current system. E. De-coupled control The system now has an estimate of its current pose which is good to within measurement error. The final step in realising autonomous station-keeping is to transform the error between the current pose estimate and the target pose into the actuator movements required to get to the target. In Section III the dynamics of the blimp were considered, and the simplifying assumptions permitted by low speed flight were explored. In particular, coupling between degrees of freedom due to aerodynamics and moment effects was neglected. Furthermore, motion in several degrees of freedom, notable 𝑟𝑜𝑙𝑙 and 𝑝𝑖𝑡𝑐ℎ, was also neglected due to the flight characteristics of the large blimp envelope and concentrated payload mass. These simplifications mean that a separate controller can be implemented for each actuatable degree of freedom. Following the model of [9], higher-level controllers may then be implemented to adjust the setpoints of these controllers in accordance with mission requirements. F. 𝑍 controller Regulates the steady-state height of the blimp. Primary input source is the barometric pressure sensor, supplemented by camera pose distance-to-image information when chessboard target is in view. Output is the vertical component of the common mode thrust required to balance the weight of the blimp with the buoyancy. Good control of the flying height is required to ensure that the planar motion detection works properly. This is primarily provided by the neutral buoyancy of the envelope; using the 𝑍 controller at a low thrust level (10%) is sufficient to control height and also helps improve responsiveness of the other controllers, as the motors are already spinning continuously. G. 𝑦𝑎𝑤 controller Regulates the heading of the blimp. Primary input source is the sensor fusion angle provided by the IMU and vision system. When the chessboard target is in view, stable heading hold relative to the chessboard with no operator intervention was recorded. Without the vision system periodically correcting the target heading, stability was limited by the tendency for the IMU 𝑦𝑎𝑤 measurement to drift. Once the blimp had lost the original target heading, oscillation between ±60° of the target direction was observed. The 𝑦𝑎𝑤 controller was tested and tuned with the blimp tethered at a fixed height above the chessboard target, but allowing it to yaw freely. With autopilot engaged, the target was displaced by angles between 0° and 60°. The system step response was calculated from the recorded log data. In the next section the tuning of this controller is outlined. H. 𝑋 controller, 𝑋 velocity controller Regulates the position of the blimp relative to the target, or, in the case of a moving target, tries to match the speed of the target. Primary input source for 𝑋 controller is the location of the target centre relative to the image. If H.264 motion directions are available, these are used to determine whether to speed up or slow down. As there are no absolute or inertial sources of reliable 𝑋 pose information, this controller can only function when the target is in view. Output is the horizontal component of the common-mode thrust. The 𝑋 controller was tested by ballasting the envelope to neutral buoyancy and flying over a chessboard moving forwards below. In Figure 8 the 𝑋 position of the target points (whose location in the first frame are shown in the inset) during one of these tests is plotted. The controller is able to keep the position of each target point in the frame within ±25 pixels of the starting value, which, given the properties of the camera and distance to the target, equates to~ ±90 mm in the real world. The lines do not remain parallel at all times because the blimp does not move purely in the 𝑋 direction; in particular, if 𝑍 and 𝑦𝑎𝑤 fluctuations were not also controlled, the accuracy of the 𝑋 controller was reduced to ~±200 mm. The large inertia of the blimp envelope when flying forward made this controller more susceptible to overshoot than the other controllers.
  9. 9. M.ENG RESEARCH PROJECT APRIL 2015 9 Figure 8 – Position of target points during 𝑋 controller test VI. RESULTS & DISCUSSION Each controller has a proportional and integral gain. As in the conventional PI controller, proportional gain 𝐾𝑝 controls the magnitude of the thrust output and the gains have been selected to provide a sub-critical response for good stability. Multirotors require fast responses to errors for aerobatic flight, however in a blimp the low speed of flight and large inertia means that there is no great advantage to trading off stability for a quicker response. Unlike in a conventional controller which is evaluated at a fixed update frequency, this application requires that the controller can be updated irregularly whenever new pose information becomes available. Furthermore, thruster instructions put into the job queue by the autopilot may be interrupted and overridden by other higher priority instructions. For these reasons, the integration time in the PI controller is implemented as the runtime of each instruction. Large errors therefore result in a large correcting force being applied for a long time; if, as the blimp approaches its set point it receives a new pose estimate, it refines the instructions to the actuators accordingly. Even if no new information is received, the actuators will at the latest be stopped at the first estimated end time, which will be closer to the target than before. Once the blimp has settled to be within tolerance of the target it returns to its usual hovering state. A. Tuning by experiment To verify this approach experimentally, the normalised time-domain unit step response of the 𝑦𝑎𝑤 controller in the tuning tests is plotted in Figure 9. It is seen that whilst there is good convergence to the target, during the rise period the variability between tests (shown by the grey ±2σ bounds) is more than double that during steady state. With 𝐾𝑝 = −5, this is a subcritical response. The median 5 to 95% rise time of the responses is 4.94 s. The autopilot was configured to ignore pose estimates containing Euler angles outside of expected ranges to mitigate against incorrect pose estimates that could cause very large actuator commands to be issued. It was noticed that bad pose estimations were more likely immediately after a rapid motion of the servos (e.g. going from hard left to hard right) when the reaction caused the blimp gondola to briefly swing in the 𝑟𝑜𝑙𝑙 direction. In test flights, this out-of-plane motion was damped by the large inertia of the blimp envelope so did not affect control stability. Performing Kalman filtering on pose estimates prior to their use in the autopilot would further help protect against this source of errors. B. Comparison with analytical methods Standard methods for controller tuning require that the system transfer function be linear and second-order [27]. Even after the simplification process outlined above was applied to the blimp dynamics the result was non-linear; a complete treatment which does not omit coupling between degrees of freedom would also likely be higher-than-seccond order. Tuning results from standard methods must therefore be approached with caution; this project used them to inform the range of values of 𝐾𝑝 to test. Approximating the system transfer function as second order with time delay using Harriott’s method (see [27]) allowed Nyquist analysis to find the gain margin from the step response tests. The gain margin of the median line in Figure 9 was 26 db, suggesting 𝐾𝑝 should be set to 19 for a critical response. Figure 9 – Normalised time domain unit step response of 𝑦𝑎𝑤 controller at 𝐾 𝑝 = −5. Responses have been normalised by timeshifting such that the step input occurrs at t=0, and scaling such that the average 𝑦𝑎𝑤 before the step = 0 and average 𝑦𝑎𝑤 after step = 1. Median and ±2 standard deviation bounds of the normalised responses are also plotted at each time instant. 0 40 80 120 160 200 240 0 10 20 30 40 50 60 time, s x1 x2 x3 x4 X Y initial point positions ego frame directions trackedXpositions,px -0.2 0.0 0.2 0.4 0.6 0.8 1.0 1.2 -6 -4 -2 0 2 4 6 8 10 12 14 16 18 normalisedyawresponse time relative to step, s Unit Step at t=0 Median Norm. response Median+2σ Median-2σ Test 1 Normalised response Test 2 Normalised response Test 3 Normalised response Test 4 Normalised response Test 5 Normalised response Test 6 Normalised response Test 7 Normalised response Test 8 Normalised response
  10. 10. M.ENG RESEARCH PROJECT APRIL 2015 10 In reality this was found to be an over-estimate, frequently causing the system to overshoot the target or develop unstable oscilations which required manual intervention to correct. In contrast, the widespread Zeigler-Nichols time-domain tuning method underpredicted 𝐾𝑝. Z-N tuning suggested 𝐾𝑝 should be set to 5.71 for a critical response. Gains up to 15 were tested and found to be stable, albeit with some overshoot causing oscilation about the target. Both analyical tuning methods estimate system properties from the transient part of the state response, so their accuracy will have suffered from the high variablity of the data during this important period. Reducing this variabilty proved difficult due to the non-linear dynamics of the real blimp and enviromental disturbances such as gusts which, although considered to be small, were not controlled for. The final weakness in this tuning method is that interactions between degrees of freedom are not well-modeled by using independent controllers for 𝑦𝑎𝑤, 𝑋 and 𝑍. Nevertheless, setting 𝐾𝑝 to 10 resulted in much improved performance. The step response was twice as fast as in tuning (2 s median rise time), and overshoot oscilation was < ±10°. The long-term performance of the tuned 𝑦𝑎𝑤 controller system is plotted in Figure 10. In these tests, the blimp was positioned at rest out-of alignment with the target, started up and autopilot engauged. As desired, the estimated 𝑦𝑎𝑤 moves towards the setpoint, and then good control stability is seen over the rest of the test duration. Corrective action, shown by the Actuator Differental Thrust, was only required when the blimp drifted more than 5° away from the target. Figure 10 – 𝑦𝑎𝑤 station-keeping long-duration test, 𝐾𝑝 = 10, following a step change in target position of 55° VII. CONCLUSION An indoor blimp capable of untethered autonomous flight has been designed, built and tuned. Development of the control scheme began by considering the dynamics of the blimp, and utilised pose estimates from an IMU and a visual target. The controller was tuned, and the experimental values compared to values suggested by analytical tuning methods. Indoor flight testing proved that the system works well. Manual control of the blimp is sufficiently dexterous to pilot it towards the target, and, once the target is in visual range the stabilising autopilot holds the blimp position within ±10° and ±0.2 m. Provided the target remains in view of the blimp, the system also realises ‘follow me’ behaviour if the target moves. To achieve these results, the approach of [15] was followed: the main actuatable degrees of freedom were decoupled to allow a separate controller to be implemented for each one. This approach proved to be simple but effective – once tuned, it achieved stable performance in the test cases for this project. With the groundwork of a usable platform now in place, opportunities to extend it abound, both in controls engineering and beyond. Improving the motion classification and better integrating it with the other pose estimate sources, e.g. by implementing Kalman filtering on board the blimp should lead to better stability when the target is not in view. A method of adjusting controller gains adaptively as described by [28] could replace the manually tuned controllers used here to further improve the stability of the blimp in autopilot mode by making it more resilient to disturbances. In wider applications, prior to this project Durham University did not have a blimp so work requiring a persistent aerial viewpoint was performed by other types of UAV. In some of these applications the advantages of long flight durations and aerodynamic stability possessed by a blimp may be beneficial. This project has included optical isolation and segregated power supplies to prevent problems of electrical noise suffered by some similar previous projects, at negligible extra cost. Similarly, using off-the-shelf and open-source components in preference to custom solutions should prolong the useful life of the system by enabling continuous improvement. Unlike in previous work, all pose estimation and control processing is performed on board the blimp, demonstrating that autonomous station keeping of a UAV blimp no longer requires vast resources or reliance on ground-based equipment. ACKNOWLEDGMENT The author would like to thank Dr T Breckon for his support throughout; I Hutchinson, N Clarey and the Electronics Workshop staff for their assistance procuring electronics and fabricating PCBs; C Wintrip and the Mechanical Workshop staff for 3D printing work; J Gibson for arranging helium supply; and S Apps and the Thermo Lab staff for assistance with filling the blimp before flights. 20 40 60 80 100 yaw,° Setpoint SSF Yaw -100 0 100 0 20 40 60 80 100 120 140 160 180 200 220 thrust,% time, s Actuator Differential Thrust
  11. 11. M.ENG RESEARCH PROJECT APRIL 2015 11 NOMENCLATURE GPIO General Purpose Input/Outputs BLDC Brushless DC Motor 𝑋, 𝑌, 𝑍 Blimp positional coordinates 𝑦𝑎𝑤, 𝑝𝑖𝑡𝑐ℎ, 𝑟𝑜𝑙𝑙 Blimp rotational coordinates [Euler angles] {𝑥} Pose vector = {𝑋, 𝑌, 𝑍, 𝑦𝑎𝑤, 𝑝𝑖𝑡𝑐ℎ, 𝑟𝑜𝑙𝑙} 𝑇 {𝑥̇}, {𝑥̈} Velocity vector, Acceleration vector 𝑚, 𝐽 Total mass, moment of inertia 𝑚 𝑒, 𝑉𝑒 Mass of envelope, Volume of envelope 𝜌 𝑎𝑖𝑟, 𝜌 𝐻𝑒 Standard densities for Air and Helium 𝑚 𝑎 𝑋,𝑌,𝑍 Added mass in 𝑋, 𝑌, 𝑍 directions respectively 𝐽 𝑎 𝑦𝑎𝑤,𝑝𝑖𝑡𝑐ℎ,𝑟𝑜𝑙𝑙 Added inertia in 𝑦𝑎𝑤, 𝑝𝑖𝑡𝑐ℎ, 𝑟𝑜𝑙𝑙 directions [𝑀] Matrix of masses, inertias & added masses [𝐶 𝑑] Matrix of drag coefficients, 𝜌 𝑎𝑖𝑟, etc. {𝐹𝑒𝑥𝑡} Vector of external forces e.g. gravity etc. ISA International Standard Atmosphere [𝑅] 3x3 Rodrigues form rotation matrix {𝑡} Translation vector, = {Δ𝑋, Δ𝑌, Δ𝑍, } 𝑇 H.264 MPEG Advanced Video Codec REFERENCES [1] J. Irizarry and E. N. Johnson, “Feasibility Study to Determine the Economic and Operational Benefits of Utilizing Unmanned Aerial Vehicles,” Georgia Institute of Technology, Atlanta, USA, 2014. [2] D. Jenkins and B. Vasigh, “The economic impact of unmanned aircraft systems integration in the United States,” Association for Unmanned Vehicle Systems International, Arlington, VA, USA, 2013. [3] A. Mathieson, “Literature Reveiw - An Autotonous Flying Blimp,” Durham University, Durham, UK, 2015. [4] A. Bjalemarkl and H. Bergkvist, “Quadcopter control using Android based sensing,” Lund University, Lund, Denmark, 2014. [5] R. Brockers, M. Humenberger, S. Weiss and L. Matthies, “Towards autonomous navigation of miniature UAV,” in IEEE Conference on Computer Vision and Pattern Recognition Workshops, Columbus Ohio, USA, 2014. [6] S. Shah, “Real-time Image Processing on Low Cost Embedded Computers,” EECS Department UCBC , Berkeley, USA, 2014. [7] C. S. Clark and E. Simon, “Evaluation of Lithium Polymer Technology for Small Satellite Applications,” in Small Satellites, AIAA/USU 21st Ann. Conf. on, North Logan, Utah, USA, 2007. [8] A. Elfes, S. S. Bueno, M. Bergerman and J. G. Ramos, “A semi- autonomous robotic airship for environmental monitoring missions,” in 1998 IEEE International Conference on Robotics and Automation, Leuven, 1998. [9] A. Elfes, S. S. Bueno1, J. G. Ramos, E. C. d. Paiva, M. Bergerman, J. R. H. Carvalho, S. M. Maeta, L. G. B. Mirisola, B. G. Faria and J. R. Azinheira, “Modelling, Control and Perception for an Autonomous Robotic Airship,” in Sensor Based Intelligent Robots, Int. Workshop on, Dagstuhl, Germany, 2000. [10] J. Pestana, J. Sanchez-Lopez, P. Campoy and S. Saripalli, “Vision based GPS-denied Object Tracking and Following for Unmanned Aerial Vehicles,” in IEEE International Symposium on Safety, Security, and Rescue Robotics (SSRR), Linkoping, Sweden, 2013. [11] Y. Kawai, S. Kitagawa, S. Izoe and M. Fujita, “An Unmanned Planar Blimp on Visual Feedback Control: Experimental Results,” Faculty of Engineering, Kanazawa University, Kanazawa, Japan, 2004. [12] L. M. Alkurdi and R. B. Fisher, “Visual Control of an Autonomous Indoor Robotic Blimp,” Edinburgh University, Edinburgh, UK, 2011. [13] J. Muller, N. Kohler and W. Burgard, “Autonomous Miniature Blimp Navigation with Online Motion Planning and Re-planning,” in IEEE/RSJ International Conference on Inteligent Robots and Systems, San Francisco, USA, 2011. [14] C. Shucksmith, “Design and Implementation of an Airbourne Surveillance Vehicle,” Oxford University, Oxford, UK, 2006. [15] S. van der Zwaan, A. Bernardino and J. Santos-Victor, “Vision based station keeping and docking for an aerial blimp,” in IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS 2000) (Volume:1 ) , Takamatsu, 2000. [16] Adafruit Industries, “Adafruit 10-DOF IMU Breakout - L3GD20H + LSM303 + BMP180,” 15 10 2014. [Online]. Available: http://www.adafruit.com/product/1604. [Accessed 20 10 2014]. [17] S. B. V. Gomes, “An Investigation of the Flight Dynamics of Airships,” Cranfeild Institute of Technology Aero Department, Cranfeild, UK, 1990. [18] N. Yamamura, K. Matsuuchi, M. Onda, S. Yamazaki and A. Saski, “Drag Reduction of High Altitude Airships by Active Boundary Layer Control,” Fluids and Thermal Engineering, JSME Int. Journal Series B, vol. 42, no. 1, pp. 230-237, 2008. [19] E. L. Houghton, P. W. Carpenter, S. Collicott and D. Valentine, “Turbulence on Spheres,” in Aerodynamics for Engineering Students, Elsevier, 2012, p. 507. [20] P. Naaijen, “Rigid Body Dynamics in TU Deflt OCW,” 2014. [Online]. Available: http://ocw.tudelft.nl/fileadmin/ocw/courses/OffshoreHydromechanic s/res00032/!506172742032204f666673686f726520487964726f6d65 6368616e696373.pdf. [Accessed 03 06 2015]. [21] J. J. G. Ramos, S. M. Maeta, L. G. B. Mirisola, S. S. Bueno, M. Bergerman, B. G. Faria, G. E. M. Pinto and A. H. Bruciapaglia, “Internet-Based Solutions in the Development and Operation of an Unmanned Robotic Airship,” Proceedings of the IEEE, vol. 91, no. 3, pp. 463-475, 03 2003. [22] Z. Zhang, “Flexible camera calibration by viewing a plane from unknown orientations,” in Computer Vision, Proc. 7th IEEE Int. Conf on, Kerkyra, Greece, 1999. [23] D. F. DeMenthon and L. S. Davis, “Model-Based Object Pose in 25 Lines of Code,” Computer Vision, Int. Jrn of,, vol. 23, no. 1, pp. 123- 141, 1995. [24] R. Barnett, “RTIMULib - a versatile C++ and Python 9-dof and 10- dof IMU library,” 11 12 2014. [Online]. Available: https://github.com/richards-tech/RTIMULib/. [Accessed 01 01 2015]. [25] M. Narayana, A. Hanson and E. Learned-Miller, “Coherent Motion Segmentation in Moving Camera Videos using Optical Flow Orientations,” in Computer Vision ICCV, 2013 IEEE Int. Conf on, Sydney, Australia, 2013. [26] N. Otsu, “A Threshold Selection Method from Gray-Level Histograms,” Systems, Man & Cybernetics, IEEE Trans. on, vol. 9, no. 1, pp. 62-66, 1999. [27] G. Ligorio and A. M. Sabatini, “Extended Kalman Filter-Based Methods for Pose Estimation Using Visual, Inertial and Magnetic Sensors: Comparative Analysis,” MDPI Sensors, vol. 13, no. 2, pp. 1919-1941, 2013. [28] I. P. Jakoubek, “Experimental Identification of Stable Nonoscillatory Systems from Step-Responses by Selected Methods,” 2008. [29] J. Ko, D. Klein, D. Fox and D. Haehnel, “Gaussian Processes and Reinforcement Learning for Identification and Control of an Autonomous Blimp,” in IEEE Internation Conference on Robotics and Automation, Rome, 2009. [30] Adafruit Industries, “Adafruit 16-Channel 12-bit PWM/Servo Driver - I2C interface,” 16 02 2015. [Online]. Available: http://www.adafruit.com/product/815. [Accessed 20 10 2014].
  12. 12. M.ENG RESEARCH PROJECT APRIL 2015 12 APPENDICES – SUPPLEMENTARY FIGURES A. The Blimp Figure 11 – Cost breakdown. Figure 12 – Schematic for two channels of optoisolation/buffering, with signal flow from PWM output to servo highlighted. The blimp has twelve channels of optically isolated output available. B. Software Figure 13 – Thread interactions during startup. Bold lines show flow of execution, dashed lines represent data exchange between functions. £197 £30 £28 £33 £41 £10 Blimp envelope 3D printed enclosure * Raspberry Pi; Wi-Fi; Camera BLDC motors; ESC; battery * IMU; PWM driver Electronics; other * * denotes free issue items PWM signal twin optocoupler MCT61, DIP Logic side: 5.0 V dc supply Motor side: 7.4 V dc supply Thrust vector servos Servo signal Twin op amps LM358A
  13. 13. M.ENG RESEARCH PROJECT APRIL 2015 13 Figure 14 – Thread interaction during runtime. Bold lines show flow of execution, dashed lines represent data exchange between functions. At termination, Hardware Abstraction Thread stops all motors, GUI Thread writes log files to disc, and Vision Thread closes camera. C. Performance Results Figure 15 – Comparison of step response predicted by 2nd order with time delay modelled transfer function (Harriot’s method) and median step response of real blimp. Inset – correlation plot between the two step responses. Spearman’s 𝑅2 = 0.967. -0.2 0 0.2 0.4 0.6 0.8 1 1.2 -4 -2 0 2 4 6 8 10 Stepresponse time relative to step, s Harriott approx. Median response R² = 0.9679 Medianpoints Harriott points Correlation plot

Views

Total views

287

On Slideshare

0

From embeds

0

Number of embeds

9

Actions

Downloads

1

Shares

0

Comments

0

Likes

0

×