building an indoor autonomous blimp, and supplies details of the landmark navigation system. Results from the robot are supplied and extensions suggested.
An Autonomous Blimp Gordon Wyeth and Ivan Barron Department of Electrical and Computer Engineering University of Queensland, 4072 QLD AUSTRALIA
Abstract This paper describes the design of a lighter than air autonomous robot and its natural landmark navigation system that operates in three dimensions. The robot has successfully flown the University banner at science shows and open days under public scrutiny. The robot is nearly 2m long and 0.8m wide, making the robot suitable for use in indoor environments. The robot may be programmed to fly a course by giving the robot a sequence of landmarks and trajectories. In addition, the robot may be programmed to look for landmarks that indicate a navigational error. Error landmarks are then paired with correction trajectories so that the robot can resume normal navigation. The navigational planner shares messages with a set of low level reactive controllers that perform the necessary trajectory generation. This paper describes the hardware considerations for building an indoor autonomous blimp, and supplies details of the landmark navigation system. Results from the robot are supplied and extensions suggested.
1
Introduction
An autonomous blimp is a lighter than air robot that can successfully navigate an environment by flying through it. A flying robot can pass over terrain that may be impassable for land based robots, providing access to otherwise inaccessible areas. Travelling at height, a flying robot can observe the environment from a unique vantage point, or can be observed by many ground based viewers. A blimp design for a robot has limited payload capability, as it relies on its neutral buoyancy to stay afloat. Variations in mass affect this balance, making the collection and dumping of payload difficult. As such blimp robots should be viewed as either observation platforms, or, as we have used our design, as observable platforms that can carry advertising or other information. The design of such a robot presents various challenges to the robot designer. • All components must be as light as possible. The addition of mass to the design has a corresponding
increase in the volume of supporting lighter than air gas. • The blimp is highly non-linear system controlled by propeller actuators based on noisy sonar data. This presents interesting controller design problems. • Navigation methods must be designed to operate in three dimensions rather than the usual two dimensions required of terrestrial robots. • Odometry is impossible and misalignment is the norm for a flying robot. The navigation methods must cope with the unpredictable forces of wind and air gusts. • All navigation must happen in real time. There is no provision to stop and think as can a land based robot. This paper presents an overview of the solutions to these many and varied problems. Firstly, the physical nature of the robot is presented with consideration to layout, lightweight design, sensor choice and controller implementation. Secondly, the software that performs real time navigation is described illustrating both high level planning and low level control. Finally, the paper evaluates the performance of the robot.
2
Hardware Design
The design of a lighter than air robot imposes restrictions on the design of the propulsion system, the processor and the sensors both in terms of their own weight and in terms of the power consumption which has implications for the power source weight. By keeping the weight of the electronics to a minimum, the volume of supporting gas is reduced. In our design, the blimp is supported by 0.9 m3 of helium / nitrogen "balloon" gas, which achieves neutral buoyancy with a robot with total mass of 0.8 kg. The propulsion is provided by four DC fans providing 3.5 degrees of freedom (forward, vertical, yaw and limited pitch) and a top forward speed of 0.6 ms-1. Sensing is performed using ten custom designed sonar sensors, each weighing 8g. By keeping the processor board design under 70g, the robot is able to carry sufficient batteries for 40 minutes of active flight. This section describes the structure of the blimp showing the propulsion system used and the corresponding sensor arrangement. Details are provided for the design of the lightweight sonar system, and its performance reviewed. An overview of the on-board controller is provided.
2.1
Blimp Structure
Vref
The blimp is made from a balsa wood frame that encloses two balloons. Each balloon is filled with a helium /nitrogen mixture called balloon gas (CIG code 124) which is available at a fraction of the cost of pure helium, but has similar lift capabilities. The balloons are custom made from aluminiumised mylar. Each balloon has a volume of 0.45 m3 giving a net lift of 300g after the 130g of balloon weight has been subtracted. The balsa wood frame has a mass of 74g, and provides mounting points for the sensors, actuators, controller and batteries. The semirigid frame is 1750 mm long, 780 mm wide and stands 900 mm tall. As shown in Figure 1, the robot has four propeller actuators that provide 3.5 DOF. The vertical propellers provide vertical translation and limited pitch control (mA for motor-aft, mF for motor-front), while the side mounted propellers provide horizontal translation and yaw control (mL for motor-left and mR for motor-right). Each propeller is driven by a high efficiency 2W electric motor, providing an effective 80 mN of thrust for a weight cost of 30g. Each motor consumes 250 mA at maximum speed. When travelling horizontally under the power of two motors, viscous losses set a top speed of 0.6 ms-1 which is attained in about 5 seconds. The net weight of the propulsion system is 130g including wiring. With the complete blimp structure in place, including propulsion, 400g of lift remains for the sensor system, controller board and power supply. mL Plan
mR mA
mF
Elevation
High Gain Amplifier
+
Rx
40 kHz Oscillator Tx
To micro
From micro Enable
Figure 2: Block layout of a single sonar sensor.
Figure 2 shows the block layout of a single sensor, and the interface to the controller. The transducers are tuned to 40 kHz with a 6 kHz bandwidth. To drive the transmitting transducer the sensor generates a 40 kHz pulse train, the duration of which is set by the controller using the enable line. Given the limited bandwidth of the transducer, the pulse train must typically run for about 20 cycles (500 µs) to achieve peak output (see Figure 3). The receiver transducer drives a high gain, high bandwidth amplifier built from discrete components. The amplifier consists of two complementary Darlington stages, providing a voltage gain of 90 dB at 40 kHz. The output of the receiver amplifier is compared to a reference voltage, providing a digital signal that is read by the controller. The controller measures the time between the transmitter being enabled and the leading edge at the comparator. This time relates to the travel time of the sonar ping, which in turn relates to the distance at which the reflection occurred: 331. t d= 2 where d is the distance to the reflecting object in metres, and t is the travel time of the sonar ping in seconds. The constant 331 is the speed of sound at STP. Enable
Figure 1. Blimp structure showing the balsa frame, balloons and motor locations.
2.2
Sonar System
The choice of sensor system for the blimp was defined by the project constraints of minimum weight and minimum power consumption, and the requirements to perceive the distance to obstacles on all six sides of the blimp as well as relative pitch and yaw. These constraints and requirements were all met by the use of a custom designed sonar system.
Transmit
Amplified Rx
VREF
Output
t Figure 3: Timing for a typical distance measurement.
Given the rise time of the transmitter and receiver, there is a predictable error in the measure of the
time travelled of around 250 µs (~80 mm). However varying reflection and signal strengths affect the rise time seen at the comparator adding a noisy component to the measure of +/- 100 µs (~40 mm) over typical measurement ranges. Figure 3 illustrates the sequence of timing event that occur in a typical distance measurement. The maximum reliable range for wall detection was found to be 3m, with a minimum range of about 0.4 m. The minimum range comes about from the need to ignore early direct transmissions from transmitter to receiver. Each sensor has a beam width of 40o. The circuit is implemented using off-the-shelf surface mount components. The PCB measures 13 x 33 mm, and the total sensor (including transducers) weighs just 7 g. Power consumption peaks at 25 mA during ping transmission, with a quiescent current of 5 mA. The robot uses ten of these sonar sensors arranged as shown in Figure 4. This arrangement provides the complete sensing requirements outlined above: distance on all six sides, plus relative pitch and relative yaw. Sensors are labelled using a pair of characters. The first character indicates whether the sensor is the front bank (F) or the aft bank (A). The second character indicates the orientation of the sensor: up (U), down (D), left (L), right (R), forward (F) or aft (A). The total mass of the sensors including wiring is 100g. This leaves 300g of lift to support the controller board and power supply. uFL
uAL
Plan
uAR
uFR
uAU
uFU
uAA
uFF uAD
uFD
Elevation
Figure 4: The positions and orientations of the ten sonar sensors.
2.3
On-board Controller
The custom built controller is based around the Intel 80C196KC microcontroller. This is a 16 bit 20 MHz microcontroller featuring: • two timers and an advanced timer management system, • three PWM channels, • 8 channel 10 bit A/D conversion, • serial communications, • digital I/O ports. Figure 5 shows a block diagram of the controller built around this device. The custom board has 32k of EPROM and 32k of SRAM for program development. The four motor drives are provided using two L293B motor drive chip, with speed control from the processor’s 3 PWM channels and a fourth channel of PWM generated from the timer system. Direction control comes from the I/O ports.
Battery Level
PC
Serial Comms
32k ROM
Switch 80C196KC Microcontroller
LED
Mux 1
Mux 2
From sonars
Motor Drive 1
32k RAM Motor Drive 2
To motors
Figure 5: Block diagram of the controller
The sonars are driven from the timer ports. The processor can read two sensors at once, with the sensors being chosen using 8:1 multiplexers. This allows the controller to use up to 16 sonar sensors. The A/D port is used to monitor battery voltage, and to read a trimpot that is used as part of the user interface. The user interface also includes a pushbutton, an LED and a piezo speaker. For more detailed interactions, the user can connect to the serial port and communicate using a teletype program. The serial port is also used for program download and development. In its entirety the controller board weighs 70 g, leaving 230 g for the power supply. The board consumes around 300 mA for normal operation.
2.4
Power Supply and Ballast
Power is stored in seven AA NiCad batteries. This provides an 8.4 V supply with a capacity of 600 mAh. Given an average consumption of under 1 A, the batteries last for about 40 minutes of typical operation. The total mass of the batteries and connectors is 160 g. The remaining 70g of mass was added in ballast. The adjustment of ballast weights allowed for day to day variations in air pressure, air temperature and balloon pressure - all of which contribute to variations in the lift of the balloons. The extra lift also allowed for small payloads such as advertising signs to be carried. More importantly the robot was able to carry a light string tether during development. Bugs in the code would sometimes cause the robot to fly to the ceiling and not return: the string made recovery much simpler!
3
Navigation Software
The task of developing navigation software for autonomous operation of a blimp is complicated by: • the lack of odometry, • misalignment caused by air gusts, • operation in three dimensions, and • the "soft" non-linear nature of actuation by propeller. The blimp uses natural landmarks for navigation, eliminating the need for odometry. Landmarks are defined as certain configurations of surrounding walls detected by the sensors. A motion plan for the robot is defined as a direction to head from the current landmark and a set of
possible landmarks that may be found along that trajectory. When one of the current set of landmarks is found, the planner identifies the new position of the robot. Based on that position the planner generates a new trajectory and looks for a new set of landmarks. The design of the sequencer allows for errors by checking for a variety of possible landmarks and generating the necessary corrections to the sequence necessary for recovery. Landmarks may also be based on internal state. For example, a low battery condition evaluates as a landmark that generates an immediate downward motion so that the robot does not float away! The trajectories between landmarks are generated by a pair of control systems, one for each motor pair. The controllers seek to minimise the error between the current relative position and attitude of the robot and the desired position and attitude defined by the planner. The controllers act as a set of reactive behaviours that deal with the real time aspects of robot navigation such as maintaining a set altitude or a distance from a wall, and also act to prevent collisions from unexpected obstacles. This section shows details of the control systems and the navigation planner, and illustrates the operation of the planner for a real example used at an open day display.
3.1
Control Systems Design
The control systems have to deal with a multi-input multioutput control problem, operating in a non-linear fashion with significant unpredictable disturbances. The nature of the problem has lead to a heuristic approach to control systems design based on experimentation with the complete craft. The control system uses the sonar sensor information to generate error information for 5 axes: x, y and z representing the Cartesian coordinates with respect to the robot, θ representing yaw and γ representing pitch. The error is determined by measuring the differences between values derived from the sensors and the desired offsets delivered from the planner. The planner specifies the desired offsets as a 5-tuple {xoff, yoff, zoff, θoff, γoff}. Offsets that are set to 0 indicate a don’t care condition for that axis. Error always evaluates to 0 on axes in a don’t care state. Positive and negative values of offset refer to offsets on opposite sides of the craft. For example, positive values of xoff refer to an offset in front of the craft, while negative values refer to an offset to the aft of robot. The sonar sensors do not directly provide information along the same axes, so the errors are derived using the following equations. The error in the x or longitudinal axis of the blimp, ex, is calculated by: x off − u FF , if x off > 0 ex = x off + u AA , if x off < 0 where uFF and uAA represent the front and aft facing sensors respectively using the notation defined in Section 2.2. Note that positive values of xoff represent distances to objects in front of the craft, negative values refer to the aft. For the y or lateral axis of the craft: y off − front (u AL , u FL ), if y off > 0 ey = y off + front (u AR , u FR ), if y off < 0
where “front” is a function that evaluates which sensor is at the front for the robot’s current direction of motion along the x axis. The sign of yoff indicates whether the offset is to the right or left. In the z or vertical axis: z off − min (u AU , u FU ), if z off > 0 ez = z off + min (u AD , u FD ), if z off < 0 where “min” is a function that returns the lesser of the two distance values. The error in yaw, θ, is calculated by: θ off + u AL − u FL , if yoff > 0 eθ = θ off + u AR − u FR , if yoff < 0 using the value of yoff to determine if the object with which to align is on the left or right. Finally, error to the desired pitch, γ, is determined by: γ off + u AU − u FU , if z off > 0 eγ = γ off + u AD − u FD , if z off < 0 Note that all of these error values evaluate to 0 if the corresponding offset is set to 0. The error values are translated to motor values using the systems shown in Figure 6. The system shown in 6(a) relates the errors in the z axis and the pitch to the motor commands for the two vertical propellers, mF and mA representing the front and aft motors respectively. (a) kz
ez
mA
+
z
z
kγ
eγ
-1
mF
+
z
(b) ex
kx
+
z
ey
z
ky
z
eθ
mL
+
-1
+
mR z
kθ
Figure 6: The systems that translate axis errors into motor commands. (a) The systems that relates z axis and pitch errors to the vertical propellers (b) The relationship between, x axis, y axis and yaw error to the horizontal propeller pair.
The system in Figure 6(b) has the more complex task of relating the errors in the x axis, the y axis and the yaw to the forward facing left and right motors, mL and mR. This task is complicated by the indirect relationship between y axis errors and motor commands. In order to correct errors along the y axis the control system induces x axis motion and yaw, which serve to push the blimp away from the obstacle found in the y axis. The non-linear limit functions in this system are introduced to stop the motor values from being saturated from one type of error. Consider the situation where there is a large ex. Without the limit function the motors would drive forward at maximum value, swamping any correction from ey or eθ.
The performance of the control systems is discussed in Section 4, where it is evaluated in context with the planner described immediately below.
3.2
Start
Vector 1: {0,0,500,0,0}
Navigation Planner
The planner interacts with the controller by specifying a 5tuple that describes the desired offsets from a landmark. By specifying these 5 values, the controller will then try to minimise the errors induced by the offsets and hence create motion. For example, if the robot is provided with the 5-tuple {0, 0, 500, 0, 0} the robot will move vertically to a position that is 500 mm from the ceiling. Disturbances in other directions are ignored. We call each such instantiation of a 5-tuple a vector. During the execution of a vector, the planner continuously evaluates the conditions in search of landmarks. Landmarks have five types. INTERCEPT (x, y, z) - All three offsets must be within the specified values. The sign of the offsets is evaluated as for the controller (for example, positive x is forward and negative x is aft). Zeroes indicate a don’t care condition. LEAVE (x, y, z) - All three offsets must be outside the specified values. SENSOR (n, range, outside) - Specific sensor n must be outside the specified range if outside is true, or inside the range if outside is false. ANALOG (n, range, outside) - Analog to digital channel n must be outside the specified range if outside is true, or inside the range if outside is false. TIME (t) - t ticks of the system clock have passed since the last landmark. In addition, each landmark has a level of confidence, c, associated with it. A landmark must evaluate true c times consecutively before it will be recognised by the planner. Upon recognition of a landmark, the planner generates a new vector to navigate to the next desired landmark. Each vector may have many landmarks associated with it. The planner evaluates each of the landmarks associated with the current vector, and will choose the next vector depending on the landmark that appears first. In effect this makes the navigation map appear as a directed graph, with the vectors as the nodes and the landmarks as the links between nodes. Figure 7 shows a simple example. The robot starts with a {0, 0, 500, 0, 0} vector which causes it to rise towards the ceiling. When the robot comes within 600 mm of the ceiling, the landmark evaluates to true and the control system has a new set of offsets {0, 0, -500, 0, 0} which cause the robot to descend to the floor. Note that the robot never achieves the goal set by the initial vector. It is not important that the robot achieves the offsets specified in the 5-tuple, so long as the robot encounters a landmark. This is true again of the second vector; the offsets are never achieved as the landmark evaluates first,
Landmark 1: INTERCEPT (0, 0, 600)
Landmark 2: INTERCEPT (0, 0, -600) Vector 2: {0,0,-500,0,0}
looping the planner back to the original vector. Clearly, this example bounces the blimp back and forth continuously from floor to ceiling. A more complex and complete example follows. Figure 7: A simple example of planner operation. The nodes represent the vectors and the links between nodes represent the landmarks. This examples bounces the blimp between floor and ceiling.
3.3
Actual Navigation Example
The following example is from a demonstration given on the Departmental Project Demonstration Day. The blimp was run in our Electrical Machines laboratory, chosen for its high ceiling and interesting 3 dimensional navigation features. Figure 8 shows the layout of the task. The blimp started at the demonstration stand, flew to the ceiling, followed the wall to the opposite corner and then descended on to a landing below that corner. From that landing the blimp followed a set of stairs back to lab floor, and then followed the wall back to the demonstration stand, where it halted on user command. Figure 9 shows the graph used to achieve this navigational task. The robot rises vertically from the stand, keeping 500 mm from the wall. The first landmark is any encounter within 500 mm of the ceiling. The next vector follows the wall using a small yaw component to keep the robot directed into the wall so as not to float too far out into the open. If the battery power drops at this stage, the robot will descend to the floor. When the top corner is found, a vector that drops and spins the robot is generated bringing the robot down to the landing. As soon as the spin is completed (indicated by the lack of a front sensor reading) the robot descends the stairs, using a pitch component to assist with the downward travel. There is no landmark at the base of the stairs, so the timer is used. If the front wall is found before the timer expires the robot starts the wall following back to the demonstration stand. A hand over the top front sensor causes the robot to stop.
3 1,2 4
8
3 2 4
5
1 7,8
7
5,6
6
Plan
Elevation
Figure 8: Plan and elevation of the Demonstration Day navigation task.. The robot flies straight up from the demonstration stand, across the ceiling and down a set of stairs. From the base of the stairs, the robot follows the walls back to the stand. The numbered points represent the landmarks used in the diagram below.
START
{0,500,500,0,0}
INTERCEPT (0,0,500)
1
{500,500,500,5,0}
INTERCEPT (500,0,0)
2 ANALOG (BATTERY LOW) SENSOR (UFU,300,TRUE) SENSOR (UFU,300,TRUE)
{0,500,-500,0,0}
{500,0,-500,5,10} TIMER (100)
5 INTERCEPT (500,0,0)
{500,-500,0,5,0}
LEAVE (1500,0,0)
4
ANALOG (BATTERY LOW)
{0,0,0,0,0}
8
{0,0,-500,-100,0}
3
LEAVE (1500,0,0)
{500,0,-500,5,0}
6
INTERCEPT (500,0,0)
7 {0,0,-500,-100,0}
INTERCEPT (500,0,0)
{500,-500,0,5,0}
LEAVE (1500,0,0)
{0,0,-500,-100,0}
Figure 9: The directed graph used to perform the Demonstration Day navigation task. The boxes represent the vectors used to drive the robot from landmark to landmark. Each link indicates the landmark type an parameters. The boxed numbers relate the landmarks with the physical locations on the map above.
Figure 10: The blimp in action. Here it is seen navigating towards landmark 3, the top corner, on Demonstration Day.
4
Performance of the Blimp
Using the navigation software, the robot is capable of accurate sequenced point to point navigation in an indoor environment. The software generates appropriate corrective actions for navigational errors, and deals with real time events. It runs on a 2 MIPS microcontroller, using less than 1% of the controller's computational bandwidth. In short, the robot performs reliably in an environment with slow moving air. Sharp gusts and high winds are beyond the ability of the small motors to correct, limiting applications for this robot to an indoor environment. Apart from the Demonstration Day display the robot has also flown in the Brisbane Convention Centre during an educational exposition there. It met with near tragedy due to an extremely powerful air conditioning duct. Careful design was needed in this case to ensure that the robot stayed clear of passages of swiftly moving air. The robot operated at height at all times to maximise visibility and to ensure that the robot remained out of reach of curious spectators. The navigation software has proven highly reliable so long as the robot remained within its physical capabilities and did not enter strong air flows. The development of flight paths in new environments is a simple process, involving some degree of trial and error. The basic demonstration flights were set up in minutes, with extra fail safe landmarks and controller tweaks being developed in about an hour or so. The most notable problem with the current design is the lack of stability in the control system level. A sudden disturbance causes a great deal of oscillation before the system will damp sufficiently to operate effectively. If this oscillation becomes too severe, the robot picks up erroneous sensor readings as the angles to objects become too great to receive sonar reflections. While these bad readings are ignored by the navigation system (only landmarks that appear several times consecutively are registered), they worsen the control system instability. It is believed that the current proportional systems bear most improvement through incorporation of derivative components into the systems. Further sensors such as solid state accelerometers may also improve control system stability.
These stability problems are exacerbated by the lack of structural and aerodynamic integrity of the robot. Vibration in the balsa space frame introduces further dynamic issues that are difficult to damp. The high profile balloons are particularly susceptible to side-on gusts of air, the direction which the drive arrangement is the least able to correct. A blimp with the structure built into a single aerodynamic shape offers improved structural integrity if helium pressure is maintained. Such a structural redesign may allow the blimp to negotiate windier environments Improvements in the power from the propellers would also improve performance in open environments. The power could be increased from better propeller design (we used cheap hobby propellers) and larger motors driven from better quality batteries. Lithium-Ion batteries offer half the weight for twice the capacity, effectively offering an increase in the weight budget for more powerful motors and the corresponding increase in the power budget to maintain flight time. Power improvements would also come from more efficient power electronics for the motor drivers; the L293 drivers are only about 80% efficient.
5
Related Work
As far as the authors are aware, the concept of an indoor autonomous blimp is unique. Every year, there are many attempts to build autonomous helicopters that can complete the challenge of the Aerial Robotics Competition. The object of this contest is to deliver disks from one side of a barrier to the other in an outdoor environment. While there are some related problems in both the blimp and the design of these helicopter devices (such as [Fagg et al, 1993]), the blimp alleviates many of the difficult control problems by achieving neutral buoyancy through its balloons. Naturally, the helicopters offer a feature that the blimp cannot: they can carry payload. Other researchers have investigated the problems of flight through simulation. The Air-Soar project [Pearson et al, 1993] offers a simulated flying environment within which to investigate autonomous flying techniques. The platform, based on the SGI flight simulator, is focussed on winged flight rather than blimps. Remote control blimps as a hobby are also starting to achieve some popularity. The resources available now for blimp construction inspired Paulos and Canny [1997] to use a blimp as a telepresence operated over the World Wide Web. This blimp allows a remote user to fly indoors by remote control and receive live video data. This application represents the other end of the (somewhat limited) indoor blimp application spectrum: their blimp is designed as an observer, ours is designed to be observable.
6
Conclusions
The construction of a lighter than air robot offers many challenges. This paper has illustrated the design of such a robot, highlighting the tradeoffs made between weight and power. A light weight, low power sonar sensor was presented and used as the basis for flight control and
landmark recognition. While it is recognised that the low level control systems can be improved, the navigation software has proved capable of dealing with real and complex flying missions in a robust fashion. While the completed robot has limited applications, the exercise provides valuable lessons in point to point robot navigation, whether in the air or on the ground.
References [Barron, 1995] Ivan Barron. An Autonomous Blimp. Honours Thesis, Department of Electrical and Computer Engineering, The University of Queensland, 1995.
[Fagg et al, 1993] A. Fagg, M. Lewis, J. Montgomery, G. Bekey. The USC Autonomous Flying Vehicle: An Experiment in Real-Time Behaviour-Based Control. Proceedings of the 1993 IEEE/RSJ International Conference on Intelligent Robots and Systems, July 1993, pp. 1173-80 [Paulos and Canny, 1997] E. Paulos and J. Canny. Ubiquitous Tele-embodiment: Applications and Implications. International Journal of Human-Computer Studies, 1997. [Pearson et al, 1993] D. Pearson, S. Huffman, M. Willis, J. Laird and R. Jones. A Symbolic Solution to Intelligent Real-Time Control. Robotics and Autonomous Systems, V. 11, 1993, pp. 279-291.
