Iowa S tate University 2008

1

Fall

2008

DISCLAIMER: This document was developed as part of the requirements of an electrical and computer engineering

course at Iowa State University, Ames, Iowa. The document does not constitute a professional engineering design

or a professional land surveying document. Although the information is intended to be accurate, the associated

students, faculty, and Iowa State University make no claims, promises, or guarantees about the accuracy,

completeness, quality, or adequacy of the information. Document users shall ensure that any such use does not

violate any laws with regard to professional licensing and certification requirements. Such use includes any work

resulting from this student-prepared document that is required to be under the responsible charge of a licensed

engineer or surveyor. This document is copyrighted by the students who produced the document and the

associated faculty advisors. No part may be reproduced without the written permission of the senior design course

coordinator.

Iowa State University

MicroCART

Project Plan Document

Fall 2008 (May09-03)

Second Semester Members:

Matt Beecher

Drew Crawford

Mike Dent

Phong Deo

Jason Funk *

Anthony Nowell

Karl Svec *

Dave Zajicek

Yan Zhang

First Semester Members:

Didum Abraham

Wade Paustian

Muhammad Riaz

Jay Roltgen *

Kyle Rutledge

Tabrina Sienkiewicz

Ryan Steffens *

* Indicates Team Leader

Corporate Sponsor:

Iowa State University | Table of Contents 2

Table of Contents

1 Project Requirements Specification ............................................................................................... 6

1.1 Problem Statement ................................................................................................................. 6

1.2 Goal Statement ....................................................................................................................... 6

1.3 Market Reseach ...................................................................................................................... 6

1.4 Concept Sketch ....................................................................................................................... 7

1.5 System Block Diagram ............................................................................................................ 8

1.6 System Description ................................................................................................................. 8

1.6.1 Ground Station ................................................................................................................ 8

1.6.2 Processing ....................................................................................................................... 9

1.6.3 Servo Control ................................................................................................................ 10

1.6.4 Sensors .......................................................................................................................... 11

1.6.5 Filtering ......................................................................................................................... 13

1.6.6 Power ............................................................................................................................ 13

1.6.7 Chassis ........................................................................................................................... 13

1.6.8 Overrides ....................................................................................................................... 14

1.7 Operating Environment ........................................................................................................ 14

1.7.1 Hardware ....................................................................................................................... 15

1.7.2 Software ........................................................................................................................ 15

1.7.3 Physical .......................................................................................................................... 15

1.8 Requirements ....................................................................................................................... 15

1.8.1 Functional Requirements .............................................................................................. 15

1.8.2 Non-Functional Requirements ...................................................................................... 16

1.9 Deliverables .......................................................................................................................... 16


2 Previous System Status ................................................................................................................ 16

2.1 Ground Station ..................................................................................................................... 16

2.2 Sensors .................................................................................................................................. 16

2.2.1 Sonar ............................................................................................................................. 16

2.2.2 Altimeter ....................................................................................................................... 16

2.2.3 Inertial Measurement Unit (IMU) ................................................................................. 16

2.2.4 Compass ........................................................................................................................ 17

2.2.5 GPS ................................................................................................................................ 17

2.3 Filtering ................................................................................................................................. 17

2.4 Processing Software ............................................................................................................. 17

2.5 Kill Switch .............................................................................................................................. 17

2.6 Manual Override ................................................................................................................... 17

2.7 Mechanical ............................................................................................................................ 17

2.8 Work Breakdown Structure .................................................................................................. 18

2.8.1 Fall 2008 Schedule ........................................................................................................ 18

2.8.2 Spring 2009 Schedule .................................................................................................... 20

2.9 Project Schedule ................................................................................................................... 22

2.10 Resource Requirements........................................................................................................ 23

2.11 Risks ...................................................................................................................................... 23

3 Project Plan Summary .................................................................................................................. 24

4 Design Document ......................................................................................................................... 25

4.1 Ground Station ..................................................................................................................... 25

4.1.1 Overview ....................................................................................................................... 25

4.1.2 Current System Status ................................................................................................... 25


4.2 Sensors .................................................................................................................................. 25

4.2.1 Sonar ............................................................................................................................. 25

4.2.2 IMU ................................................................................................................................ 25

4.2.3 Compass ........................................................................................................................ 25

4.2.4 GPS ................................................................................................................................ 26

4.2.5 Altimeter ....................................................................................................................... 26

4.3 Filtering ................................................................................................................................. 29

4.3.1 Overview ....................................................................................................................... 29


4.3.3 Plan ................................................................................................................................ 29

4.3.4 Digital Butterworth Lowpass Filter ............................................................................... 29

4.3.5 Sonar Lowpass Filter ..................................................................................................... 32

4.3.6 Compass Lowpass Filter ................................................................................................ 32

4.3.7 IMU Lowpass Filter ........................................................................................................ 33

4.4 Flight Control Software ......................................................................................................... 35

4.4.1 Overall Design and Current Status ................................................................................ 35

4.4.2 Planned Improvements ................................................................................................. 36

4.4.3 Schedule ........................................................................................................................ 38

4.5 Manual Override ................................................................................................................... 38


4.5.2 Plan ................................................................................................................................ 38

4.5.3 Functional Requirements .............................................................................................. 38

4.5.4 Design ............................................................................................................................ 39

5 Conclusion .................................................................................................................................... 40


6 References ................................................................................................................................... 41

7 Appendix A: Sensor Figures ......................................................................................................... 42

8 Appendix B: Filtering Figures ....................................................................................................... 44

9 Appendix C: Manual Override Figures ......................................................................................... 47

Iowa State University | Project Requirements Specification 6

1 Project Requirements Specification

1.1 Problem Statement

The International Aerial Robotics Competition (IARC) was created with the desire to push the

boundaries of UAV technology. The competition has been redesigned several times to ensure that

the technology to compete the entire mission is not currently available, requiring innovation and

ingenuity. IARC Mission 4 is broken up into 4 different levels of competition. Level 1 requires the

vehicle to takeoff and navigate to a point up to 3 km away autonomously via 4 GPS waypoints and

then maintain a hover. Level 2 requires the vehicle to autonomously identify a target building.

Level 3 requires the vehicle to navigate the structure and relay reconnaissance information back to

the ground station. Level 4 requires the team to complete Levels 1-3 in order in less than 15

minutes.

1.2 Goal Statement

The current goal of the MicroCART project team is to produce an autonomous helicopter able to

complete the qualifications for Level 1 of the IARC 4th

Mission.

1.3 Market Reseach

There are a wide variety of shapes, sizes, and configurations present in the field of UAVs today.

Depending on the purpose of the vehicle, these characteristics may vary. UAVs are currently used

in a number of military roles, such as reconnaissance and attack. The RQ-2 Pioneer is used for

reconnaissance and surveillance purposes. The MQ-1 Predator UAV (Figure 1) is armed with

missiles and is used as a platform for locating and hitting ground targets in sensitive areas. UAVs

are also used in civil applications such as firefighting when a human observer would be at risk,

police observation of civil disturbances and crime scenes, and reconnaissance support in natural

disasters. The Bell Eagle Eye (Figure 2) is currently used by the US coast guard.

Figure 1. MQ-1 Predator UAV. (http://www.tech.military.com) Figure 2. Bell Eagle Eye. (http://www.bellheliecopter.com)


1.4 Concept Sketch

The following sketch (Figure 3) from the Fall 2007 Project Plan is an overview of the basic operation

of the MicroCART vehicle. It gives a representation of the helicopter taking off, navigating to a

target location, and maintaining hover. The MicroCART system consists of a modified Xcel 60 RC

helicopter and an avionics and flight control system that has been developed over several years by

phased senior design project teams.

Figure 3. MicroCART Concept Sketch. (Webber, et al., 2007)


1.5 System Block Diagram

Figure 4. System Block Diagram.

1.6 System Description

The MicroCART avionics and control system is divided into 8 subsystems. These systems are

Ground Station, Processing, Servo Control, Sensors, Filtering, Power, Chassis, and Overrides. Each

system is broken down further, as outlined in the description below, which has been adopted from

the Fall 2007 and Spring 2008 Project Plans.

1.6.1 Ground Station

The ground station runs on a personal computer running a version of the Linux operating system.

Ground station software is used to load waypoints and air data coefficients into the aircraft, prior to

and during flight, and to show the status of the aircraft during flight.

1.6.1.1 Communication

The communication subsystem of the ground station receives current state information from the

aircraft via a wireless data communications link that attaches to the ground station PC through a

serial port. This sub-system is also used to send GPS navigation waypoints and air data coefficients

to the helicopter.


1.6.1.2 Graphical User Interface (GUI)

The graphical user interface portion of the ground station uses aircraft state information received

from the communication component to display the current position and altitude of the aircraft. It

includes a 3D representation of the helicopter using OpenGL.

1.6.2 Processing

The processing system controls the aircraft's flight, communicates with the ground station, and

collects and performs calculations on information received from the sensors. The processing system

runs on a Technologic TS-7300 single board computer (Figure 5). The TS-7300 is attached to the

MicroCART chassis, and runs a Linux operating system and the custom flight control and avionics

software package.

Figure 5. Technologic TS-7300 Single Board Computer.

1.6.2.1 Control

The control subsystem is responsible for coordinating the aircraft's flight by analyzing all available

data and determining speed and heading setpoints.

1.6.2.2 Input/Output

The input/output module handles input and output needed by the processing system to

communicate with all connected components.


1.6.2.3 Communication

The communication component sends and receives data from the ground station. The

communication subsystem sends state information to the ground station, so it can display the

current state of the aircraft, and receives desired way points from the ground station. The

subsystem uses the same wireless data communications link system as the ground station. Figure 6

shows the Digi RF modems. On the right is the modem package as used with the ground station,

and the left shows the modem without the packaging, as it is mounted on the helicopter.

Figure 6. XTend-PKG 900MHz RF Modem.

1.6.3 Servo Control

Servo control is responsible for the movement of the servos, after the control subsystem

determines what actions are needed. Servo control abstracts the servos from the control

subsystem.

1.6.3.1 Servo

The servos apply changes to the aircraft's mechanical hardware, such as the rotor wing, to affect

changes in its flight path. Servo actions cause helicopter movements about a body-centered set of

coordinate axes (Figure 7). The x-axis of the coordinate system always points in the direction of the

helicopter’s forward motion.


1.6.3.2 Roll

Roll controls the angle of the rotor wing to roll the aircraft about the X-axis. Roll is tightly coupled to

pitch.

1.6.3.3 Pitch

Pitch controls the angle of the rotor wing to tilt the aircraft about the Y-axis.

1.6.3.4 Yaw

Yaw causes the aircraft to rotate about the Z-axis.

1.6.3.5 Throttle

Throttle controls the speed of the rotor wing which effects power. Increasing the throttle gives the

aircraft more lift and speed but requires pitch and yaw to be adjusted to maintain the same flight

path.

1.6.3.6 Collective

Collective adjusts the rotor wing to increase or decrease lift, causing the aircraft to move up or

down from a stationary hover.

1.6.4 Sensors

A variety of sensors are used to gather accurate information on the aircraft's position relative to its

environment: GPS, sonar, altimeter, compass, and inertial measurement unit.

1.6.4.1 GPS

The Global Positioning System (GPS) receiver provides position and location information of the

aircraft.

1.6.4.2 Sonar

The sonar provides accurate distance information from an object, given that object is within 20 feet

of the aircraft (Figure 8). The current sonar system only has one active channel, which is used to

measure helicopter altitude, from 6 inches to 20 feet.

Figure 7. Coordinate System Reference.


Figure 8. Sonar Schematic.

1.6.4.3 Altimeter

The altimeter provides accurate helicopter altitude information for altitudes greater than 20 feet

above ground level. At 20ft, the system uses altimeter measurements, rather than sonar

measurements to determine helicopter altitude. The altimeter module is comprised of an SCP1000

atmospheric pressure sensor driven by an Atmel Atmega16 microcontroller.

1.6.4.4 Compass

The compass provides three-dimensional heading information. Figure 9 shows the PNI Micro Mag 3

compass board (top) attached to a serial port communication board (bottom).

Figure 9. Compass module plugged into the RS-232 Com Board.


1.6.4.5 Inertial Measurement Unit (IMU)

The IMU consists of a system of accelerometers and gyroscopes to measures acceleration and

changes in roll, pitch, and yaw. It is used to provide position information, using dead reckoning, as

well as feedback to initiate changes in roll, pitch, and yaw.

1.6.5 Filtering

Filtering aims to remove noise from the sensor outputs. Filtering will be used to reduce the effects

of noise due to electronics hardware inaccuracy and inconsistencies and noise caused by aircraft

vibrations.

1.6.5.1 Kalman Filter

The Kalman filter is an efficient recursive filter that will be used to reduce noise affects for the

sensor-based state vector control system. Other autonomous helicopter projects have had success

with Kalman filters.

1.6.5.2 High-Low Pass Filter

The high-low pass filter will remove measurements above or below specified frequencies, to

remove noise that may corrupt and mask expected good sensor measurements.

1.6.6 Power

The power system provides electrical power to all of the system components on board the aircraft.

1.6.6.1 Batteries

The aircraft batteries are rechargeable, and they supply power for all of the aircraft's electrical

systems. The batteries were selected because they provide the most power in the lightest available

forms.

1.6.6.2 Charging System

The charging system for the batteries is stored on the ground and is designed specifically for

charging the current power system batteries.

1.6.6.3 Wiring System

The wiring system consists of a wiring harness on the aircraft which delivers power to all the

electrical components. It is designed to be lightweight and to resist damage due to aircraft

movement and vibration.

1.6.7 Chassis

The airframe is a COTS Xcel size 60 acrobatic helicopter. The chassis provides system structure and

protects the components from water, since the aircraft must be capable of operating in inclement

weather conditions.


1.6.7.1 Shock Control

The shock control subsystem minimizes vibration to prevent damaging system components and to

reduce noise and interference effects on sensor data.

1.6.7.2 Mechanical

The chassis houses a gasoline-powered 2-stroke engine which provides power for the wing rotor

and tail rotor.

1.6.7.3 Test Harness

The test harness is used to fasten the aircraft to the landing pad, which restricts the aircraft's

freedom of movement, so it cannot move above a very low altitude. The Test Harness reduces

project risk by protecting against serious crashes when doing flight tests.

1.6.8 Overrides

The overrides system provides recovery options in case the autonomous functionality of the aircraft

fails or any of the sub-systems on the aircraft fail.

1.6.8.1 Kill Switch

The kill switch is wired directly into the spark plug of the aircraft’s gasoline engine. The kill switch

uses a dedicated receiver on the aircraft and a separate remote control unit on the ground. If the

kill switch is activated the aircraft engine stops.

1.6.8.2 Manual Override

The manual override control allows the ground operator to fly the aircraft using a joystick or a

traditional RC helicopter remote control unit. The manual override control acts as a security

measure in case the helicopter fails or does not perform properly during autonomous flight. The

manual override component needs to be fully operational before any autonomous flight tests can

begin.

1.7 Operating Environment

The system obtains waypoints for the helicopter from a ground station user. The waypoints are

then sent to the processing unit where they are compared to the current system’s state. The system

state vector includes the system’s altitude, position, and location. The processing calculates and

updated the state vector by analyzing data received from the sensors and filtering sensed data.

Depending on the current state and desired way point, the processing unit modifies output to the

servos which control the helicopter’s speed and movement. (Beecher, et al., 2008)


1.7.1 Hardware

The ground station operates from a PC laptop capable of OpenGL rendering. The helicopter

operates from a Technologic TS-7300 Single Board Computer. The specifications for the TS-7300

computer that pertain to the operating environment are as follows:

• 200MHz ARM9 CPU with MMU

• Altera 2C8 Cyclone II FPGA

• 32 MB SDRAM

• USB 2.0 Compatible OHCI ports

• 10 RS232 serial ports

(Beecher, et al., 2008)

1.7.2 Software

The software for the ground station operates in a Java Virtual Machine. The software for the

helicopter operates in a Debian Linux Operating System for ARM. (Beecher, et al., 2008)

1.7.3 Physical

The physical environment also affects MicroCART. Helicopter flight will require a minimum

temperature of 40 degrees Fahrenheit and relatively low wind speeds. Otherwise, the system can

operate in temperatures from 40 degrees Fahrenheit to 110 degrees Fahrenheit and in wind gusts

speeds up to 30 mph. The expected physical environment at the IARC competition site includes

both trees and buildings, so the helicopter must be capable of simple obstacle avoidance. (Beecher,

et al., 2008)

1.8 Requirements

1.8.1 Functional Requirements

FR001: The aircraft shall be fully autonomous (Weber et al., 2007, p.19)

FR002: The aircraft shall not employ tethers for communications with the ground station (Beecher, et al., 2008)

FR004: The aircraft shall be able to fly 3 km (Beecher, et al., 2008)

FR005: The aircraft shall have communications capabilities that can span 3 km (Beecher, et al., 2008)

FR006: The aircraft shall be able to fly to within 1 meter of a designated GPS way point (Weber et al., 2007, p.19)

FR007: The aircraft shall be equipped with a completely independent termination mechanism that can render the

aircraft ballistic upon command (Beecher, et al., 2008)

FR008: The aircraft shall be able to hover at a GPS point (Weber et al., 2007, p.19)

FR009: The aircraft shall be able to take off (Weber et al., 2007, p.19)

FR010: The aircraft shall be able to safely land (Weber et al., 2007, p.19)

FR011: The aircraft shall be able to relay sensor information back to a ground station (Beecher, et al., 2008)

FR012: The aircraft shall be able to be controlled manually by an operator in the event that the aircraft becomes

unstable or a hazard to bystanders (Beecher, et al., 2008)

FR013: The aircraft shall be able to receive GPS way points from a ground station (Weber et al., 2007, p.19)

FR014: The aircraft shall be able to carry a sensor probe to a defined way point (Weber et al., 2007, p.19)

FR015: The aircraft must be able to fly continuously for at least 20 minutes(Weber et al., 2007, p.19)

Iowa State University | Previous System Status 16

FR016: The aircraft shall be able to reach an altitude of 50 ft (Weber et al., 2007, p.19)

FR017: The aircraft shall be able to sense position and attitude to a height of 50 ft AGL (Weber et al., 2007, p.19)

FR018: The aircraft shall be able to reach and maintain a horizontal airspeed of 13.03 KTS (15 mph) (Weber et al.,

2007, p.19)

FR019: The ground station shall have a GUI with which users can enter information to define a mission (Weber et

al., 2007, p.19)

FR020: The ground station shall be able to display the current state of the aircraft on a GUI (Weber et al., 2007,

p.19)

1.8.2 Non-Functional Requirements

NFR01: The aircraft must weigh less than 14 lbs to not exceed the payload of the motor (Weber et al., 2007, p.19)

1.9 Deliverables

Throughout this term deliverables will support the team objectives, these include:

• Project Plan

• Design Document

• Weekly Progress Reports

• Software capable of producing autonomous hover

2 Previous System Status

2.1 Ground Station

The ground station has most of its features integrated, and the team is currently troubleshooting

minor communication issues with the helicopter. The graphical user interface (GUI) and OpenGL

component works, and it displays correct data during flight tests. PID and trim values can be sent to

and received from the helicopter. Currently, the only outstanding issue is the loss of data packets

between the ground station and the helicopter’s flight control software. The team is currently

investigating causes and possible solutions.

2.2 Sensors

2.2.1 Sonar

Sonar has been implemented and tested. A bug that occasionally causes bad readings has been

identified and is currently awaiting a verification of the fix.

2.2.2 Altimeter

A test circuit has been created and exists on a breadboard, and code is nearing completion.

2.2.3 Inertial Measurement Unit (IMU)

The IMU is complete and tested.


2.2.4 Compass

The compass is fully coded and functions, but needs to be calibrated and fully tested.

2.2.5 GPS

The GPS is implemented and believed to be functional, but is awaiting integration and testing.

2.3 Filtering

There is Kalman filter code currently in the MicroCART repository. This code is incomplete and

untested, and is being replaced with simple highpass/lowpass filter code. If the simple filter is

ineffective, the Kalman filter code based upon the KFilter open source framework will be

integrated.

2.4 Processing Software

The major features of the flight control software are tested and working. A flight test was

performed in the spring semester to test autonomous control of the roll channel, and was generally

successful. Improvements since then have added the capability to set trim on servos, which we

hope will help stabilize the helicopter in hover. Communication with the ground station works in

the lab, but begins to drop packets when the helicopter engine is running. Communication issues

are being addressed.

2.5 Kill Switch

The kill switch is not currently integrated into the helicopter.

2.6 Manual Override

The manual override for the roll and pitch channels have been implemented. Both overrides have

been tested in the lab. The roll channel override was tested in the spring flight test and functioned

properly.

2.7 Mechanical

Extensive work was done to the helicopter last semester to get the motor running smoothly, but

the mechanical connections are still not optimal. Currently, the helicopter is having a problem on

the pitch channel which is causing it to twitch on engine run-up.

The helicopter also has its original landing gear bolted below the electronics section, which is then

connected to the chassis of the helicopter. This is causing unnecessary jolting on takeoff and landing

and can be avoided by changing the configuration of the electronics bay and landing gear. Shock

absorption is integrated into the system currently and may be upgraded in the future.


2.8 Work Breakdown Structure

2.8.1 Fall 2008 Schedule

2.8.1.1 Flight Tests

Flight Test 1

09/20/2008

Entire Group

Address misc. issues identified in Flight Test 1; lab and ground tests

09/20/2008 – 10/16/2008

Entire Group

Flight Test 2, pending successful ground test

10/16/2008

Entire Group

Address misc. issues identified in Flight Test 2, lab and ground tests

10/16/2008 – 11/21/2008

Entire Group

Flight Test 3, pending successful ground test

11/21/2008

Entire Group

Address misc. issues identified in Flight Test 3

11/21/2008 – 12/12/2008

Entire Group

2.8.1.2 Ground Station

Work communication bug

09/25/2008 – 10/09/2008

Mike Dent, Kyle Rutledge


2.8.1.3 Sensors

Integrate GPS code into system, test

09/25/2008 – 12/12/2008

Jason Funk

Calibrate and Test Compass

09/25/2008 – 12/12/2008

Anthony Nowell, Muhammad Riaz

Test Sonar

09/25/2008 – 10/18/2008

Anthony Nowell, Muhammad Riaz

Implement and Test Altimeter

09/25/2008 – 12/12/2008

Ryan Steffens

2.8.1.4 Filtering

Implement Low/High Pass Filter

09/25/2008 – 12/12/2008

Matt Beecher, Wade Paustian, Karl Svec

2.8.1.5 Mechanical

Resolve twitching problem

09/25/2008 – 10/11/2008

Tabrina Sienkiewicz

Adjust ball linkages

09/25/2008 – 10/11/2008

Tabrina Sienkiewicz

Replace link between tail rotor and servo

10/02/2008 – 10/16/2008

Tabrina Sienkiewicz

Learn to fly helicopter

09/25/2008 – 12/08/2008

Didum Abraham


2.8.2 Spring 2009 Schedule

2.8.2.1 Flight Tests

Preparations for Flight Test 1

01/12/2009 – 03/07/2009

Entre Group

Flight Test 1 (tentative)

03/07/2009

Entire Group


03/07/2009 – 04/11/2009

Entire Group


04/11/2009

Entire Group


04/11/2009 – 04/25/2009

Entire Group


04/25/2009

Entire Group


04/25/2009 – 05/08/2009

Entire Group

2.8.2.2 Flight Control and Filtering

Resolve Flight Control software stability issues

01/12/2009 – 02/02/2009

Jay Roltgen, Wade Paustian


Kalman filtering research and implementation

02/02/2009 – 03/30/2009

Jay Roltgen, Wade Paustian

Flight Control Error Packets

02/02/2009 – 02/09/2009

Wade Paustian

2.8.2.3 Sensors

Complete Altimeter prototype

01/12/2009 – 02/09/2009

Ryan Steffens

Compass calibration and shielding experimentation

02/09/2009 – 03/02/2009

Ryan Steffens

Prepare final Altimeter board and test

03/02/2009 – 03/30/2009

Ryan Steffens

GPS integration and test

03/30/2009 – 04/20/2009

Ryan Steffens

2.8.2.4 Manual Overrides

Implement 5 channels

01/12/2009 – 02/09/2009

Muhammad Riaz

Design Watchdog code

02/09/2009 – 02/23/2009

Muhammad Riaz

EMI shielding research and implementation

02/23/2009 – 04/14/2009

Muhammad Riaz


2.9 Project Schedule

Figure 10. Work Schedule for Fall 2008 and Spring 2009.

Iowa State University | Project Plan Summary 23

2.10 Resource Requirements

The table below summarizes the costs associated with the spring semester work. The resource cost

represents the equivalent cost of the student time donated by Iowa State University. The projected

parts cost represents the estimated cost for fuel and unforeseen costs for helicopter upkeep.

Student Time Hours Employees Weeks Rate Cost

7 11 15 $20.00 $23,100

Resource Cost 1155 $23,100

Projected Parts Cost $150.00

Total Cost $23,250

Table 1. Resource Requirements for Spring 2009.

2.11 Risks

The following is a list of risks and ways to minimize them, as compiled by the Fall 2007 team.

Risk: Helicopter damage from collisions

Management: Only allow skilled pilots to fly the helicopter until the joystick is complete

Implement the manual override switch

Install padded landing gear

Use test stand for simple flight testing

Use tether for hover capability testing

Risk: Loss of team member

Management: Overlap team member skills

Document thoroughly

Risk: Injury from vehicle malfunction

Management: Check the systems carefully before each flight

Keep all observers at least 20 feet away from helicopter while running

Risk: Equipment hardware failures

Management: Implement vibration isolation on all electronic components

Keep funds available for equipment replacement

Make sure the components and connections are correct before powering

components or conducting a flight test

Iowa State University | Project Plan Summary 24

3 Project Plan Summary

The MicroCART project is quickly nearing a feature complete milestone. Almost all major system

components are now complete, with most either finished or in need of flight testing.

There are still several things holding up further flight tests of autonomous hover. The issue of servo

twitch has been identified to be caused by the manual override relays, but will need further

investigation to determine a workaround. An issue with communication between the helicopter

and ground station is currently being investigated, but appears to be related to bad hardware.

There are several issues outstanding in the sensors subsystem. Sonar still needs to be tested and

validated, and the compass needs to be calibrated and tested. The altimeter is progressing nicely,

but will need to have a circuit board designed and manufactured before true testing can begin.

The project team still has several major hurdles to overcome if we are to achieve our goals for the

semester. We have divided out work for each issue to the relevant groups, with the Aerospace and

Electrical Engineers troubleshooting the twitch/override issues, the flight control and ground

station sub-teams investigating the communication issues, and the sensor group working the sensor

issues. With hard, focused work, we will still have a good chance of meeting our goals this fall.

Iowa State University | Design Document 25

4 Design Document

4.1 Ground Station

4.1.1 Overview

Ground station software loads waypoints for the helicopter prior to flight and displays real-time

system status of the helicopter, specifically: its altitude, heading, positioning, and location. The

ground station is complete, in a sense that everything in it is working and integrated with the flight

control software. The term of our project will involve adding packets to the communications

interface, as needed, to support any additional information needed from the helicopter.

4.1.2 Current System Status

The ground station currently has all of the features integrated. The graphical user interface (GUI)

and OpenGL component works, and it displays the correct data during flight tests. PID and trim

values can be sent to and received from the helicopter. The frequency of packets sent to the ground

station can also be configured. The ground station will be updated as needed to support additional

packets from the helicopter.

4.2 Sensors

4.2.1 Sonar

4.2.1.1 Current Status

The sonar has been implemented and tested to give valid data. Several issues were discovered in

the past semester that had caused the sonar to fail on initialization and potentially crash in flight.

Testing will continue to ensure stability, but the sonar is now believed to be complete.

4.2.2 IMU

4.2.2.1 Current System Status

The IMU has been implemented and tested to give valid data. Research will continue next semester

into the best method to combine sensor data, with the IMU at the forefront of this research. This

work will take place in the flight control code and will be independent of the IMU sensor’s function.

4.2.3 Compass


The compass has been integrated into the system. Testing has shown that the data the compass

gives is invalid once the helicopter’s engine is started. Calibration of the compass this semester

appeared to improve the operation slightly, and further work will be done next semester to attempt

to tune the system further. In addition to this, techniques will be investigated to try to shield the


compass from the magnetic fields produced by the engine and other electronic equipment on the

helicopter.

4.2.4 GPS


The GPS has been partially integrated into the system. Testing of the GPS sensor on a laptop

computer was successful, but those results could not be duplicated when attached to the

helicopter. Testing will continue next semester to investigate what issues may be causing conflict

with the GPS sensor.

4.2.5 Altimeter


Numerous issues have been discovered with the design of the altimeter. Several issues were found

with the altimeter’s circuit layout, and others with the code to run on the microcontroller. The

physical circuit is now capable of sending and receiving data from a computer across the RS-232

port. The code for the microcontroller is nearly complete, and is currently undergoing an overhaul

to fix a large design flaw. A working prototype should be done early in the semester, with a final

design hoped for by the end of the semester.

4.2.5.2 Input Specification

The primary input to the altimeter subsystem is the atmospheric pressure.

4.2.5.3 Output Specification

The primary output is the altitude calculated from the measured atmospheric pressure. The altitude

output is of type float.

4.2.5.4 User Interface Specification

Within the altimeter subsystem, the ATmega AVR microcontroller will read input data requests and

output a response over a USART (RS-232 serial connection). Table 2 outlines the USART interface to

the microcontroller.

Input Output Format Output Size Description

$i $i,{ready}* 6 bytes Initialize the altimeter or verify that it is already initialized.

When initialized, ready will be “T”, otherwise “F”.

$p $p,(data}* 8 bytes Request the current pressure reading. {data} is a 3 byte

representation of the 19 bits read directly from the

pressure sensor.

$u $u,ucart* 10 bytes Input for validating USART communication

Table 2. Altimeter USART communication interface.


4.2.5.5 Hardware Design

The altimeter requires a constant 5 VDC supplied to its voltage regulator which outputs 3.3 VDC to

the subcomponents. The altimeter uses an Atmel AVR ATmega16L microcontroller to communicate

readings from the SP1000-D01 Absolute Pressure Sensor to the RS-232 serial connection. An

updated circuit diagram can be found in Appendix A (Figure A1).

4.2.5.5.1 Atmel AVR ATmega16 8-bit Microcontroller

• The AVR communicates over the RS-232 serial connection using the Serial USART.

• The AVR communicates with the SCP1000-D01 using the SPI bus.

4.2.5.5.2 SCP1000-D01 Absolute Pressure Sensor

• The SCP1000 operates at supply voltages from 2.4 to 3.3 VDC with a very low current draws

(typically <25uA).

• The SCP1000 measures pressure in the range of 30 kPa to 120kPa.

• The SCP1000 stores 19 bits of pressure data in its data registers. The resulting integer must

be divided by 4 to get pressure measurement in Pa.

• The SCP1000 has 2 modes being accounted for in the design of the altimeter. The initial

implementation of the altimeter will use high resolution mode, the high speed mode is

being accounted for in the event that the output data refresh rate is not fast enough. The

modes are summarized below in Table 3.

Mode Pressure

Resolution

Digital

Resolution

Output Data

Refresh Rate

High Resolution 1.5 Pa 17 bits 1.8 Hz

High Speed 3.0 Pa 15 bits 9 Hz

Table 3. Summary of Pressure Sensor modes.


4.2.5.6 Software Specifications

There are 2 main components to the altimeter software, listed below. Additionally, a sequence

diagram for requesting a pressure reading can be found in Appendix A (Figure A2).

4.2.5.6.1 7.2.1.5.1 Altimeter Class in the Flight Control Code (altimeter.cpp)

The flight control software shall reuse the serial class to read and write data to the altimeter. The

following methods shall provide an interface to the rest of the flight controller for obtaining the

altitude.

• Altimeter() – Constructor to initialize the Altimeter class

• float GetAltitude() – Public method that returns most recently measured and stored altitude

• void UpdateAltitude() – Public method to request the current pressure from the altimeter,

convert it to an altitude, and store it for subsequent calls made to GetAltitude().

4.2.5.6.2 7.2.1.5.2 Altimeter Microcontroller Code (altimeter_uc.c)

The following methods allow the Altimeter class of the flight control code to retrieve readings from

the pressure sensor.

• void main() – Initializes both the microcontroller and pressure sensor. Then it loops

indefinitely taking messages from sensorRead() and determining the proper course of

action.

• void initMicro() – Initializes the Atmel AVR microcontroller.

• void initPressureSensor() – Initializes the SCP1000 pressure sensor.

• char* getPressure() – Retrieves pressure reading from the pressure sensor. This function

may be called any time during normal operation and will wait until the sensor is ready.

• char* readRS232() – Retrieves and returns a message from the RS-232 serial port. This

function will wait until the port is ready and reads until a null character is found or the

buffer is full.

• void writeRS232(char*) – Writes data over the RS-232 serial port one byte at a time until the

entire message has been sent.

• char usartRead8() – Reads and returns 8 bits of data from the RS-232 serial port (USART).

• void usartWrite8(char data) – Writes 8 bits of data to the RS-232 serial port (USART).


• void sensorWrite8(const SensorAddr_t address, const char data) – Writes 8 bits of data to

the address specified of the pressure sensor (SPI).

• char sensorRead8(const SensorAddr_t address) – Reads and returns 8 bits of data from the

address specified of the pressure sensor (SPI).

4.3 Filtering

4.3.1 Overview

The Xcell-60 helicopter presents an unfavorable environment for sensitive electronic devices. The

helicopter's ignition system creates electromagnetic radiation that can introduce noise into the

signals coming from the various sensors mounted on the helicopter. Mechanical vibration can also

introduce noise into signals coming from sensors that are sensitive to motion, such as the Inertial

Measurement Unit (IMU). Therefore, filtering of sensor data is necessary to remove unwanted

noise, while still retaining as much useful information as possible.


This semester, the filter code has been integrated into the flight control software on the helicopter.

A private IMU_LPFilter member has been added to the IMU class, and is used during the IMU class's

run function just after reading the serial packet from the IMU sensor. The output of the filter is

stored in the IMU class's public member variables corresponding to the measurements that were

filtered. The Compass measurements are being filtered the same way as the IMU, only using

Compass_LPFilter.

4.3.3 Plan

Kalman filtering of all sensor data is the final goal for filtering on the MicroCART project. If Kalman

filtering is used for all sensor data, there will be no need for the Butterworth filters. However, the

Kalman filter and its implementation are complex, and the sensor data needs to be filtered. So, a

phased approach has been taken. Filtering will is implemented using digital Butterworth lowpass

filters, which have the advantage of being easy to design, implement, and understand. Later, the

lowpass filters will be replaced by a Kalman filter. Until the Butterworth filters are replaced, the

filtering coefficients for the Butterworth filters will need to be updated as better flight test data

becomes available for characterization.

4.3.4 Digital Butterworth Lowpass Filter

A digital Butterworth lowpass filter has the advantage of having no ripple in the passband. The

filter coefficients can also be adjusted so that the gain of the Butterworth filter is never greater than

unity. The design used was a C++ class for a generic Nth order digital Butterworth filter, which is

characterized by the transfer function below. Since the filter class is generic, it can be easily reused,


with different parameters, for different sensors. The slope after the cutoff frequency for the

Butterworth filter is -20*order dB/decade.

Equation 1. Butterworth Filter Transfer Function.

On the design parameter of order, it was decided an order of N = 2, would provide a good balance

between filter performance (-40 dB/decade of attenuation in the stopband), computational cost,

and delay. While a longer, higher performance filter could be used, this would also increase the

delay from input to output, which is particularly important. We do not want to limit the flight

control software's ability to react to sudden changes in the helicopter's attitude.

A small selection of representative time and frequency domain plots of data from the x acceleration

of the IMU and the altitude from the sonar from in in-lab test are included in Appendix B. Graphs

for frequency response for a second-order Butterworth filter are also included in Appendix B.


The filter accepts a single channel of data from a sensor as input.


The filter outputs a filtered version of the sensor data, with the unwanted high frequency content

attenuated.

4.3.4.3 Software Specification

4.3.4.3.1 B.1.3.1 Class Diagram

Figure 11. Butterworth Filter Class Diagram.


4.3.4.3.2 Data Structures

The ButterworthFilter class contains the following private attributes:

• int mOrder – An integer used to store the length, or order, of the filter

• vector<float> mACoeffs – A vector of floating point numbers containing the a coefficients

• vector<float> mBCoeff - A vector of floating point numbers containing the b coefficients

• vector<float> mInDelayLine – A vector of floating point numbers that stores previous inputs

• vector<float> mOutDelayLine – A vector of floating point numbers that stores previous

outputs

4.3.4.3.3 Methods

The ButterworthFilter class defines the following public methods:

• ButterworthFilter(int order, vector<float> &a, vector<float> &b) – This constructor method

takes the order, along with vectors containing the coefficients as arguments. The input

vectors need to be of size order+1.

o The constructor resizes mInDelayLine and mOutDelayLine to be order+1 long, and

initialized to zero.

o The coefficient vector arguments get deep copied to mACoeffs and mBCoeffs.

o Note: The ButterworthFilter does not allocate memory for member variables other

than through creating vector<float>, so deconstruction happens without an explicit

~ButterworthFilter().

• float runFilter(float input) – This method implements the difference equation, noted in

Equation 2. The difference equation was obtained by taking the inverse z-transform of the

transfer function.

yn = b0xn + b1xn-1 + ... + bNxn-N – a1yn-1 – a2yn-2 - ... - aNyn-N

Equation 2. Difference Equation.

Note that the coefficient a0 is absent from the equation – the filter coefficients must be

appropriately scaled such that a0 = 1. The method works by accepting a single floating-point value

as input, and computes the difference between a sum of products for the b coefficients and a sum

of products for the a coefficients. The method then shifts the values in the input and output delay

lines, and returns the computed difference as a floating point value, which corresponds to yn.


4.3.5 Sonar Lowpass Filter

All the sensor data will have error introduced by noise. The ultrasonic transducer may pick up high

frequency noise in the form of electromagnetic noise or from vibration on the helicopter.


The Sonar lowpass filter accepts one channel of sensor data as input: altitude.


The Sonar lowpass filter outputs filtered versions of the altitude channel with unwanted high

frequency content removed.


4.3.5.3.1 B.2.3.1 Butterworth Filter

The filtering for the sonar only needs one channel of data input and output, so it will be done using

a Butterworth filter placed in the Sonar class. Note that this is different from the Compass and IMU

which need multiple channels of data input and output, and are done with collections of

Butterworth filters placed in their respective classes. For method specifications review the

Butterworth Filter Software Specification.

4.3.6 Compass Lowpass Filter

The compass sensor is especially susceptible to magnetic noise, which the helicopter produces

making it a prime candidate for filtering.


The Compass lowpass filter accepts three channels of sensor data as input: x, y, z compass values.


The Compass lowpass filter outputs filtered versions of the three Compass channels, with unwanted

high frequency content removed.


4.3.6.3.1 B.3.3.1 Class Diagram

Figure 12. Compass Lowpass filter class diagram.


4.3.6.3.2 Data Structures

The Compass_LPFilter class contains the following private attributes:

• ButterworthFilter x

• ButterworthFilter y

• ButterworthFilter zr

Each of these private attributes is a ButterworthFilter object for each component of raw Compass

data.

4.3.6.3.3 Methods

The Compass_LPFilter class defines the following public methods (these should be the same as the

IMU_LPFilter methods):

• Compass_LPFilter() – This constructor method initializes the filter parameters for each

individual ButterworthFilter object contained in the class using order = 2, and coefficients

written in the constructor.

• Compass_LPFilter(vector<float>& aCoeffs, vector<float>& bCoeffs) – This constructor

initializes the filter parameters for each Butterworth Filter object using order = 2 and the

coefficients passed in. The aCoeffs and bCoeffs should be vectors of size 3 (determined

from: order+1).

• ~Compass_LPFilter() – This deconstructor frees the memory used by the Butterworth filters

from their creation.

• vector<float> runFilter(vector<float> inputs) – This method accepts a vector of floating

point values corresponding to pitch and roll angles, accelerations, and angular rates. It

routes each input to its corresponding filter object and calls the runFilter() method on each

object. The results are placed in a floating point array and the method returns a pointer to

this array.

4.3.7 IMU Lowpass Filter

The IMU_LPFilter has been created to reduce the effects of noise on the IMU measurements.

Possible noise sources are vibrations and electromagnetic noise from the helicopter, particularly the

ignition system.


The IMU lowpass filter accepts 8 channels of sensor data as input: pitch and roll angles; x, y and z

accelerations; and pitch, roll and yaw rates.



The IMU lowpass filter outputs filtered versions of the 8 corresponding IMU channels, with

unwanted high frequency content removed.


4.3.7.3.1 Class Diagram

Figure 13. Compass Lowpass filter class diagram.

4.3.7.3.2 Module Specification

The IMU module has the same description as the Compass low pass filter. Only IMU_ LPFilter

instead of Compass_ LPFilter, and needs a vector of 8 values instead of 3 values when using its

runFilter(vector<float>) method.


4.4 Flight Control Software

The flight control software is nearly completed. Important aspects of the software include serial

communication between all of the sensors and the flight control software, controllers for all of the

servos attached to the helicopter, and navigation software. This semester we plan to fix

communication issues with the ground station, add software to calculate the position from the IMU

in addition to the GPS, and clean up the code to enhance readability and ease future debugging or

enhancements. Additionally, we will need to begin investigating sensor filtering to obtain more

accurate readings from initially noisy sensor readings.

4.4.1 Overall Design and Current Status

4.4.1.1 Control

The flight control software implements a cascading system of three proportional controllers in

order to achieve autonomous flight. We utilize standard Proportional-Integral-Derivative (PID)

controllers for each of the following operations in sequence:

1) Obtaining the desired velocity to achieve the position set by the ground station.

2) Obtaining the desired attitude to achieve the velocity found in step 1.

3) Obtaining the desired servo response to obtain the attitude found in step 2.

The current flight control software has been tested with simulated sensors and the cascading

system of PID controllers is tested working in a simulated environment. Additionally, over a series

of flight tests, the helicopter has shown to give an oscillatory response when attempting to hover

autonomously on the roll channel.

4.4.1.2 Sensors

To obtain state information about the helicopter, the flight control software must obtain

information from the sensors. Previous MicroCART teams have implemented a polling approach to

this problem, wherein the flight control software requests data from each of the sensors

periodically. This has advantages and disadvantages, which have been evaluated and reevaluated

several times over the years. Building on prior teams' experience, we will choose to continue using

this method, while eliminating the disadvantages as best we can.

To communicate with each sensor, the flight control software implements serial input/output. This

serial communication needs to be evaluated for potential bugs, as the helicopter flight control

currently suffers from rare, irreproducible crashes. We think that the source of these crashes may

lie somewhere in the serial communication.


4.4.1.3 Ground Station

The flight control software implements serial communication over an RF link with the ground

station. The serial communication with the ground station implements a Cyclic Redundancy Check

(CRC) to verify that the data sent to the ground station is valid, and throws out packets that do not

pass the CRC.

4.4.2 Planned Improvements

4.4.2.1 IMU position calculation

Currently, the helicopter plans to obtain its permission from GPS data. However, this solution is

inadequate because the GPS data is far too noisy to acquire a stable fixed position. This calls for

additional sensor data to enhance our position information. We plan to use IMU accelerometer

data to calculate the position of the helicopter and use this in addition to the GPS data to localize

the helicopter's position. The challenge of this module will be to convert the coordinate space from

the helicopter body-frame acceleration to ECEF (earth-centered earth-fixed) accelerations. After

obtaining the ECEF accelerations, the module should integrate the accelerations to obtain a dead-

reckoning estimate of the helicopter's position.

4.4.2.1.1 Input Specification

We plan to use strictly IMU sensor data to find the helicopter's position from the value.

• Pitch angle

• Roll angle

• Helicopter X-axis acceleration (forward – backwards)

• Helicopter Y-axis acceleration (left – right)

• Helicopter Z-axis acceleration (up – down)

These values will be sufficient to obtain the results we desire

4.4.2.1.2 Output Specification

The output of the module shall be the normalized ECEF acceleration in terms of X, Y, and Z. In this

new coordinate space, Z is straight down into the earth, X is north, and Y is south. The following

shall be the output of the module:

• Helicopter North-South acceleration

• Helicopter East-West acceleration

• Helicopter Up-Down acceleration


4.4.2.1.3 Software Specification

The software for this subsystem will utilize the roll, pitch and yaw angles from the IMU to rotate the

coordinate system. These angles are commonly known as Euler angles. The software will then

perform the following operations:

1) The software will first calculate the gravity vector in the ECEF plane and rotate it using the

pitch and roll angles provided by the IMU.

2) Having done that, it will subtract this new rotated gravity vector from the body-frame

accelerations directly reported by the IMU.

3) Finally, it will rotate the body-frame accelerations reported by the IMU to the local-level

coordinate space, giving us the helicopter's true acceleration in the ECEF space.

Having calculated the accelerations in the ECEF plane, this subsystem will then integrate those

accelerations to obtain an estimate of the helicopter's velocity and position.

4.4.2.2 Sensor combination for estimating position

There are several redundant sensors in the helicopter. We can utilize this redundancy to obtain a

more accurate image of the helicopter's position if we filter the sensor data correctly. The

redundant sensors that we will utilize to find the helicopter's position are:

• IMU ECEF (earth-centered earth-fixed) accelerations (calculated as described in Section

4.4.2.1)

• GPS position

Implementing a recursive linear estimator filter is a standard procedure in the control field for this

problem, and we will implement the optimal recursive linear estimator, the Kalman filter. The filter

will take as input the ECEF accelerations on each axis from the IMU with the GPS position data,

which will give us a more precise estimate of the helicopter's position. A precise estimate is

necessary to obtain hover and movement on pitch and roll axes.

4.4.2.2.1 Input Specification

The input shall be the sensor data from the GPS and the calculated accelerations from the IMU.

Additionally, the Kalman filter implementation requires that we estimate the relative accuracy of

these two measures. Since the GPS is likely to give a more accurate estimate of the position, and

the IMU a more precise position, we will need to evaluate these the relative weight of the two

sensors and choose which sensor to give the most priority to. This evaluation will be performed

through testing and evaluation of each sensor individually.


4.4.2.2.2 Output Specification

The output of this subsystem shall be the velocity and position of the helicopter, which shall be a

precise, accurate estimate of the helicopter's position.

4.4.2.2.3 Software Specification

The software for this subsystem shall be capable of performing a Kalman filtering operation on the

input data. The Kalman filter is designed to accommodate sensors of various degrees of accuracy

and produce the optimal estimate of the combined sensor data. The software shall take as input

the noisy sensor data and output the Kalman-estimated value of the desired data.

4.4.3 Schedule

• Investigate and implement coordinate transformations (1 week) (most work already done)

• Investigate and implement Kalman filtering (5 weeks)

• Optimize Kalman filter for testing (2 weeks)

• Test with helicopter in flight (8 weeks)

4.5 Manual Override


The current Manual Override circuit is believed to be working properly. Two channels, each for roll

and pitch were tested which were properly working. The code for the Watchdog is being designed.

4.5.2 Plan

Currently there are only two channels being used by the manual override. Five channels, each for

roll, pitch, yaw, throttle and collective would be implemented. Noise is believed to be the reason for

the inaccurate values generated by sensors like compass and sonar. Sensitive PCB’s, which are prone

to electromagnetic noise, need to be shielded. Several shielding techniques would be researched and

implemented to get accurate readings from sensors.

4.5.3 Functional Requirements

FR1: The manual override shall allow control of the helicopter via remote control at the beginning

stages of this project.

FR2: The manual override shall allow control of the helicopter via remote control in emergency

situations once the project is finished.

FR3: The manual override shall use the designated channel 7 on the receiver for the remote control.

FR4: The manual override shall switch between the appropriate inputs, either manual or computer

controlled, to drive all of the servos depending on the signal received on channel 7.


4.5.4 Design

A switch was required to choose between RC manual control and the flight control system. The type

of switch we chose was a UAV backup switch. This switch is driven by the channel 7 input. There is

no need to have different relays for this purpose. Each channel’s output is connected to the

corresponding servo. The FCS (Flight control system) inputs have been connected to receive input

from the computer for a particular channel for a corresponding servo. The RC ports of the switch

receive input from the remote control receiver for each relay. There is an input port on the switch

called “Watchdog”. Signal from flight control system is fed into this Watchdog port which detects a

change in pulse every two seconds. This pulse is generated by FCS which indicates whether the

flight control software is working or not. If the flight control software fails, the switch will

automatically switch to RC controls.


The circuit will receive input from a remote control being run manually on the ground.

a) If channel 7 is switched on, the input that will drive the servos will come from the remote

control, as normal.

b) If channel 7 is toggled to the middle position, the input driving the servos will ultimately

come from the computer, on COM port 3, via a Pontech servo control board.


The output of the circuit will drive each of the servos with appropriate input, from either the RC

receiver, or from the Pontech servo controller.

4.5.4.3 Hardware Specification

4.5.4.3.1 Components

The servo controller is made by Pontech, and the model number is SV203. This is a common servo

controller and is compatible with the servos we already have. The backup switch used is an

Electrodynamics SP-112. We chose this back up switch because it has 6 channels. We need multiple

channels because we need to control the servos related to the movement of roll, pitch, yaw and

throttle independently.

4.5.4.3.2 Hardware Schematic

Please see Appendix C (Figure C1) for a hardware schematic of the manual override system.

Iowa State University | Conclusion 40

5 Conclusion

The MicroCART project has now reached a critical juncture. We made good progress this semester

with successful hover for a good length of time on both the roll and pitch channels. However, we

still have a long way to go.

We are currently limited on the channels we can attempt computer control on due to poor sensor

data. The compass will need to be working properly before autonomous control of the yaw channel

can be tested, and the altimeter will need to be completed, integrated, and tested before the

collective and throttle channels can be tested. In addition to all of this, there is still work to do with

the Flight Control software to determine why the helicopter is drifting with computer-controlled

roll. All of these issues will need to be addressed before a successful hover on all 5 channels can be

accomplished.

Even with all of that, we are closer now than any other team has been, and stand a very good

chance of making significant progress towards the full hover objective next semester. We are very

close to being finished with all design work, with the altimeter, engine shielding, and potential

Kalman filter work all that remains to be finalized. The rest of the project is nearing a maintenance

phase of fixing bugs, tweaking protocols, and improving handling characteristics. With hard work

from all team members and a strong 491 group, we will move even closer to completing the

project.

Iowa State University | References 41

6 References

Beecher, M., Crawford, D., Dent, M., Funk, J., Nowell, A., Svec, K., et al. (2008). Spring 2008

MicroCART Project Plan. Iowa State University, Department of Electrical and Computer Engineering.

Webber, B., Brokman, A., Laird, A., Nguyen, M., Peyton, M., Sanfilippo, P., et al. (2007). Micro-CART

Fall 2007 Project Plan. Iowa State University, Department of Electrical and Computer Engineering.

AUVSI. 2008. 2008 <http://iarc.angel-strike.com/>.

Iowa State University | Appendix A: Sensor Figures 42

7 Appendix A: Sensor Figures

Figure A1. Altimeter Circuit Diagram/Hardware Schematic.

Iowa State University | Appendix A: Sensor Figures 43

Figure A2. Altimeter Pressure Request Sequence Diagram.

Iowa State University | Appendix B: Filtering Figures 44

8 Appendix B: Filtering Figures

Below are a selection of representative time and frequency domain plots of parameters the x

acceleration of the IMU and the altitude determined by the sonar were chosen. These data were

collected during in-lab system tests in which the helicopter was manually moved and rotated to test

pitch, roll, yaw, and accelerations in the x, y, and z directions. As can be seen in the plots, the IMU

signals are dominated by low-frequency components below 0.06π (Beecher, et al., 2008). These

above mentioned graphs are followed by the graphs for frequency response for a second-order

Butterworth filter. All graphs mentioned here created by Karl Svec.

Figure B1. Time and Frequency Domain Plots for IMU x acceleration from in-lab test.


Figure B2. Time and Frequency Domain Plots for Sonar values.


Figure B3. Frequency for Second-Order Butterworth Filter (ωc=0.06π).

Figure B3 shows the magnitude and phase response of a second-order digital Butterworth filter

with a cutoff frequency of 0.06π. The associated filter coefficients are a0 = 1, a1 = -1.7347, a2 =

0.766, b0 = 0.0078, b1 = 0.0156, and b2 = 0.0078.

Iowa State University | Appendix C: Manual Override Figures 47

9 Appendix C: Manual Override Figures

Figure C1. Manual Override Hardware Schematic.

Iowa S tate University 2008

Documents