Post on 07-Jan-2022
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
Iowa State University | Table of Contents 3
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
Iowa State University | Table of Contents 4
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.2 Current System Status ................................................................................................... 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.1 Current System Status ................................................................................................... 38
4.5.2 Plan ................................................................................................................................ 38
4.5.3 Functional Requirements .............................................................................................. 38
4.5.4 Design ............................................................................................................................ 39
5 Conclusion .................................................................................................................................... 40
Iowa State University | Table of Contents 5
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)
Iowa State University | Project Requirements Specification 7
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)
Iowa State University | Project Requirements Specification 8
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.
Iowa State University | Project Requirements Specification 9
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.
Iowa State University | Project Requirements Specification 10
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.
Iowa State University | Project Requirements Specification 11
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.
Iowa State University | Project Requirements Specification 12
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.
Iowa State University | Project Requirements Specification 13
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.
Iowa State University | Project Requirements Specification 14
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)
Iowa State University | Project Requirements Specification 15
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.
Iowa State University | Previous System Status 17
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.
Iowa State University | Previous System Status 18
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
Iowa State University | Previous System Status 19
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
Iowa State University | Previous System Status 20
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
Address misc. issues identified in Flight Test 1
03/07/2009 – 04/11/2009
Entire Group
Flight Test 2 (tentative)
04/11/2009
Entire Group
Address misc. issues identified in Flight Test 2
04/11/2009 – 04/25/2009
Entire Group
Flight Test 3 (tentative)
04/25/2009
Entire Group
Address misc. issues identified in Flight Test 3
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
Iowa State University | Previous System Status 21
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
Iowa State University | Previous System Status 22
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
4.2.3.1 Current Status
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
Iowa State University | Design Document 26
compass from the magnetic fields produced by the engine and other electronic equipment on the
helicopter.
4.2.4 GPS
4.2.4.1 Current Status
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
4.2.5.1 Current Status
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.
Iowa State University | Design Document 27
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.
Iowa State University | Design Document 28
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).
Iowa State University | Design Document 29
• 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.
4.3.2 Current System Status
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,
Iowa State University | Design Document 30
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.
4.3.4.1 Input Specification
The filter accepts a single channel of data from a sensor as input.
4.3.4.2 Output Specification
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.
Iowa State University | Design Document 31
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.
Iowa State University | Design Document 32
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.
4.3.5.1 Input Specification
The Sonar lowpass filter accepts one channel of sensor data as input: altitude.
4.3.5.2 Output Specification
The Sonar lowpass filter outputs filtered versions of the altitude channel with unwanted high
frequency content removed.
4.3.5.3 Software Specification
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.
4.3.6.1 Input Specification
The Compass lowpass filter accepts three channels of sensor data as input: x, y, z compass values.
4.3.6.2 Output Specification
The Compass lowpass filter outputs filtered versions of the three Compass channels, with unwanted
high frequency content removed.
4.3.6.3 Software Specification
4.3.6.3.1 B.3.3.1 Class Diagram
Figure 12. Compass Lowpass filter class diagram.
Iowa State University | Design Document 33
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.
4.3.7.1 Input Specification
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.
Iowa State University | Design Document 34
4.3.7.2 Output Specification
The IMU lowpass filter outputs filtered versions of the 8 corresponding IMU channels, with
unwanted high frequency content removed.
4.3.7.3 Software Specification
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.
Iowa State University | Design Document 35
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.
Iowa State University | Design Document 36
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
Iowa State University | Design Document 37
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.
Iowa State University | Design Document 38
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
4.5.1 Current System Status
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.
Iowa State University | Design Document 39
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.
4.5.4.1 Input Specification
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.
4.5.4.2 Output Specification
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.
Iowa State University | Appendix B: Filtering Figures 45
Figure B2. Time and Frequency Domain Plots for Sonar values.
Iowa State University | Appendix B: Filtering Figures 46
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.