development of an embedded system
TRANSCRIPT
Development of an Embedded Systemfor Quad-Motor Aerial Vehicles
Research assignment report
Marc de Hoop
Development of an Embedded Systemfor Quad-Motor Aerial Vehicles
REPORT
submitted in partial fulfillment of therequirements for a
RESEARCH ASSIGNMENT
in
COMPUTER SCIENCE
by
Marc de Hoopborn in Bodegraven, the Netherlands
Software Engineering Research GroupDepartment of Software Technology
Faculty EEMCS, Delft University of TechnologyDelft, the Netherlandswww.ewi.tudelft.nl
c© 2007 Marc de Hoop.Use the information in this document for commercial puproses isprohibited. For commercial use contact the author.
Cover picture: the prototype of the hardware in the X-Ufo.
Development of an Embedded Systemfor Quad-Motor Aerial Vehicles
Author: Marc de HoopStudent id: 1170791Email: [email protected]
Abstract
The TUDelft course in Embedded Real-Time Systems wants to use a quad-rotoraerial vehicle named X-Ufo for their lab course. To make the system useable for thelab course, this vehicle needs to be equipped with sensors and an embedded systemthat reads the sensor data and transmits the data to a system that has to be programmedby students.
A group of students from the faculty of Aerospace Engineering has designed aquad-rotor aerial vehicle named Insight that needs sensorsand a control system.
This document describes the result of research done to develop an embedded sys-tem that functions as platform for development of a control system for the stabilisationof quad-motor aerial vehicles.
The designed system contains accelerometers, gyroscopes,a pressure sensor and,for Embedded Real-Time Systems, a compass. The sensors are read by a microcon-troller that can do control or transmit the sensor data via anRS232 link. Experimentsshow that, although with some filtering, the hardware is ableto measure the positionand change in position of the quad-rotor.
University supervisor: Prof.dr.ir. A.J.C. van Gemund, Faculty EEMCS, TU Delft
Preface
This report describes the result of my work done on the development of the hardware forthe X-Ufo and the Insight. I believe I made something really useful for both IN4073 andMicroTeam and I am proud of the result. I would like to thank the following people for theircontribution. I would like to thank Arjan van Gemund for thisproject, his help, time andadvice.
I also would like to thank Silvan Thus for sharing his knowledge and his advice on thedomain of control systems and aerospace engineering.
There is a time to work and a time to rest, and for their supportand interest in thisproject during these times of rest, I would like to thank my family, girlfriend and her family.
And last I thank the Creator of life, the universe and everything, including birds. SDG.
Marc de HoopDelft, the Netherlands
November 19, 2007
iii
Contents
Preface iii
Contents v
List of Figures vii
1 Introduction 11.1 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Design Exploration 32.1 IN4073 lab project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Helicopter hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42.3 Requirements of the new hardware . . . . . . . . . . . . . . . . . . . .. . 52.4 Chosen sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.5 Choosing the microcontroller . . . . . . . . . . . . . . . . . . . . . .. . . 72.6 Power supply and motor control . . . . . . . . . . . . . . . . . . . . . .. 92.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Hardware design 113.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 The microcontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113.3 The sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.4 Connecting to the PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.5 FETs and power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.6 Connecting to the X32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Experimental results 214.1 ATmega128 software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Modifying the trexcomm device . . . . . . . . . . . . . . . . . . . . . . . 21
v
Contents Contents
4.3 X32 software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.4 PC application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.5 Experimental results . . . . . . . . . . . . . . . . . . . . . . . . . . . . .254.6 Weight of the prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . .294.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5 Conclusions and Future Work 315.1 Reflection and future work . . . . . . . . . . . . . . . . . . . . . . . . . .31
Bibliography 33
A Schematics of the breakout boards 35
B Contents of the CD 39
vi
List of Figures
2.1 Lab hardware setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32.2 Hardware in the TREX 450 . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
3.1 Overview of the hardware . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 123.2 Schematic of the microcontroller and directly connected parts . . . . . . . . . . 133.3 Schematic of the sensors . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 143.4 Schematic of the IDG300 part of the IMU breakout board . . .. . . . . . . . . 153.5 Picture of the compass on its breakout board with the wrong arrow . . . . . . . 163.6 Schematic of the RS232 level conversion . . . . . . . . . . . . . .. . . . . . . 163.7 Schematic of the power supply and motor controlling FETs. . . . . . . . . . . 17
4.1 Structure of the software for the ATmega128 . . . . . . . . . . .. . . . . . . . 224.2 Finite State Machine of the trexcomm peripheral . . . . . . . . . . . . . . . . 224.3 Finite State Machine of the xufocomm peripheral . . . . . . . . . . . . . . . . 234.4 Screendump of the PC application . . . . . . . . . . . . . . . . . . . .. . . . 244.5 Plot of the sensor data while doing pitch/roll movement with motors off . . . . 264.6 Plot of the sensor data while doing pitch/roll movement with motors at half power 264.7 Plot of the sensor data while doing pitch/roll movement with motors at full power 274.8 Plot of the filtered sensor data while doing pitch/roll movement with motors at
full power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.9 Plot of the compass data while rotating the ufo with motors off . . . . . . . . . 284.10 Plot of the compass data while rotating the ufo with motors on . . . . . . . . . 28
A.1 IMU breakout board schematic . . . . . . . . . . . . . . . . . . . . . . .. . . 36A.2 Pressure sensor breakout board schematic . . . . . . . . . . . .. . . . . . . . 37
vii
Chapter 1
Introduction
This chapter introduces the problem, states the problem statement gives a summary of thecontributions and an outline of the rest of this report.
1.1 Problem statement
TUDelft’s faculty of Electrical Engineering, Mathematicsand Computer Science offers acourse in Embedded Real-Time Systems (IN4073) [9, pp. 76]. This course provides anintroduction embedded systems programming. In the lab project students have to developan embedded control unit for a tethered electrical model helicopter. The goal of the project isto stabilize the helicopter such that it can be controlled with a single joystick. The helicopterused in the course in 2006 was a TREX 450 [11].
This helicopter has an output power in the order of three hundred watts. One couldimagine that putting a pencil in the running rotor blades would easily make two pencilsout of one. It was already obligatory to wear safety goggles while testing, but this was notenough to ensure the safety of the students.
Therefore something new has to be found to use for this course. Something that couldfly and would need a controller to become stable. To fulfill this need the Silverlit X-Ufowas found. The X-Ufo is a remote controlled flying toy with four rotors. The output powerof X-Ufo’s the motors is much lower, making it (nearly) harmless.
The helicopter used in the lab project was equipped with somehardware to control theservos and communicate with an FPGA board. To be able to use the X-Ufo for the labcourse the ufo needs a comparable piece of hardware.
For a Design Synthesis Exercise a group of nine students, named MicroTeam of thefaculty of Aerospace Engineering designed a quad-rotor aerial vehicle named Insight, com-parable with the X-Ufo. In the preparation phase of this research assignment they contactedArjan van Gemund because of his experience with the stabilisation of the helicopter. Be-cause the principles of the Insight and the X-Ufo are nearly the same the hardware could, inprinciple, also be the same, so we decided to work together.
The multidisciplinarity of this problem is expressed in theproblem statement. Theproblem that is adressed in the research assignment that is presented in this report is:
1
1.2 Contributions Introduction
A piece of hardware has to be designed that can be used as a platform todevelop a control system for the X-Ufo in the IN4073 lab course and for
MicroTeam’s Insight.
1.2 Contributions
Two versions are made, one for IN4073 and one for MicroTeam. The two versions sharemuch aspects. E.g. both versions use an ATmega128 from Atmelas main controller and anSCP1000 pressure sensor from VTI technologies.
The X-Ufo version for IN4073 the hardware has an InvenSense IDG300 dual axisMEMS gyroscope, an Analog Devices ADXL330 iMEMS accelerometer, a VTI Technolo-gies SCP1000 pressure sensor and a Honeywell HMC6352 digital compass sensor.
MicroTeam wanted to use an MZK Profi Penta receiver module to communicate tothe hardware and an Analog Devices ADIS16350 Inertia Measurement Unit (IMU) so theMicroTeam version uses an ADIS16350 as IMU and A MZK Profi Penta receiver for thewireless connection. This version has no compass.
Experiments show that the resulting hardware works for the given situations.
1.3 Outline
Chapter 2 describes the sensors and other components that were chosen to be used in thehardware. In Chapter 3 the schematic of the hardware is givenand explained. The writtensoftware and experimental results are presented in Chapter4. Chapter 5 concludes thisreport.
2
Chapter 2
Design Exploration
This chapter describes the parts that were chosen to be used in the hardware. It describesthe sensors and their interfaces and it describes which microcontroller was chosen and thereasoning behind those choices.
2.1 IN4073 lab project
To illustrate the context of the design, this section will give a short introduction to theIN4073 course and lab project. As mentioned in Chapter 1, thecourse provides an intro-duction embedded systems programming. In the lab project students have to develop anembedded control unit for a tethered electrical model helicopter. The goal of the project isto stabilize the helicopter such that it can be controlled with a single joystick.
The hardware used is depicted in Figure 2.1. The PC is a generic PC running Linux,the FPGA is loaded with the X32 softcore which functions as a microcontroller. The PCis meant only as a user interface to change control parameters and pass the position of thejoystick to the X32. The students have to program this user interface in C.
InterfaceElectronics
PC
Heli Link
FPGA
PC Link
Joystick
Figure 2.1: Lab hardware setup
The X32 softcore on the FPGA is a 32-bit softcore, developed by Symen Woutersen, andcan be programmed in C. See [13], [14] and [15] for more information. The students have toprogram their controller, filtering and other functions on the X32. The X32 communicateswith the PC and the helicopter using an RS232 connection. Thecommunication protocolbetween the PC and X32 is not defined; the students have to design their own protocol.
3
2.2 Helicopter hardware Design Exploration
For the communication from the helicopter to the X32 the X32 is equipped with a spe-cial peripheral that generates an interrupt when it has received all sensor values. The sensorvalues can be read via the peripheral’s memory mapped interface. The communication fromthe X32 to the helicopter is done via a character based transmitter. Accomplishing to theprotocol is a task for the students. For more detailed information about the assignment andthe protocol, consult [10].
2.2 Helicopter hardware
To get an idea of the hardware that is needed this section gives an overview of the hardwarethat was used in 2006/2007 in the TREX 450 helicopter. A schematic of TREX hardware isgiven in Figure 2.2.
Figure 2.2: Hardware in the TREX 450
The hardware consists of:
• A PIC18F1220P microcontroller from Microchip. A microcontroller in an 18-pinpdip package with 4kB flash memory for instruction storage (2bytes per instruction),256 bytes data memory and EEPROM, 7 10-bit AD-converters, 1 PWM module, andan 8 x 8 bit hardware multiplier. See [6] for more detailed information.
The microcontroller sends sensor data to the X32 and receives commands to changethe servo positions. When no command is received for 2ms the microcontroller entersa safe mode, shuts the engine down and sets the servos to a neutral position.
4
Design Exploration 2.3 Requirements of the new hardware
• Three ENC-03A gyroscopes from muRata. These gyroscopes have a maximum angu-lar velocity of±300/s and a sensitivity of 0.67mV//s. See [7] for more information.
• An analog hardware filter for each gyroscope. This filter is needed to filter the sensornoise and the vibration noise when the main rotor is running.
• Five connectors for servos. These servos control the yaw, pitch, roll, lift and the mainengine. Although the main engine is not a servo, its speed is controlled via a servointerface.
2.3 Requirements of the new hardware
The fact that new hardware has to be developed gives the ability to change the hardware oradd new features. People involved in the project expressed the following requirements:
• The Embedded Software Lab (ESL) that offers the IN4073 course requires new andbetter gyrosocopes. The gyroscopes used in the helicopter are no longer availablefrom Farnell, the main supplier of electronics.
• The ESL also wanted accelerometers in the new hardware. A suggestion is theADXL330, which is also used in the Nintendo Wii-mote ([8]). This data could even-tually be merged with the gyroscope data using a Kalman estimator.
• MicroTeam needs support for the ADIS16350 Inertia Measurement Unit (IMU) thatthey use for the Insight. The ADIS16350 has an SPI interface.
• MicroTeam needs wireless communication using an MZK Profi Penta receiver. Thisreceiver is a receiver for remote controlled aerial vehicles like model helicopters. Itsoutput signal is a sort of pulse width modulated.
• For MicroTeam enough headroom in the microcontroller is required to implement acontrol algorithm.
• MicroTeam needs to measure the altitude of their quad-rotorand suggested to add apressure sensor to measure the atmospheric pressure to determine the altitude.
• Because the quad-rotors have to fly the weight of the components is a serious issue.Components may not be too large or too heavy.
Using the ADIS16350 for IN4073 is not an option because it costs over $400 perpiece. Looking for a suitable accelerometer three possibleoptions were available: theLIS3LV02DQ from ST Microelectronics, the ADXL330 from Analog Devices and theMMA7260QR2 from Freescale Semiconductor. Key specifications of these accelerometersare listed in Table 2.1.
5
2.4 Chosen sensors Design Exploration
Table 2.1: Accelerometer specifications
Device Nr ofaxes
Measurementrange
Sensitivity Interface
LIS3LV02DQ 3 Selectable1.5g/2g/4g/6g
800 mV/g 1.5 g Analog
ADXL330 3 3g 300 mV/g AnalogMMA7260QR2 3 Selectable 2g/6g 12 or 16 bits, 1024 or
340 units/g at 12 bitsSPI or I2C
2.4 Chosen sensors
The chosen accelerometer is the ADXL330 from Analog Devices(see [2] for the datasheet);not in particular because of the specifications but more because it was the cheapest ac-celerometer available on a breakout board at SparkFun Electronics1 and because it is usedin the Nintendo Wii so there is a good chance that it will be produced for at least the nextten years. A breakout board is a piece of PCB containing the chip and eventually somesupporting electronics. It has a connector to connect the chip to the outside world. Thissaves you the hassle of soldering these small chips and makesthe chips reusable.
SparkFun also sells a 5 degrees of freedom IMU, which is a breakout board with anADXL330 and an IDG300 dual axis gyroscope from InvenSense (see [5] for the datasheet).Because this would give a 3 axis accelerometer and gyroscopes for pitch and roll mea-surement for a good price this IMU was chosen for the X-Ufo. The IDG300 can handle amaximum angular velocity of 500/s and has a sensitivity of 2.0mV//s where the ENC03can handle 300/s and has a sensitivity of 0.67mV//s. To use the outputs of these sensorsan Analog-Digital converter (ADC) is needed.
Yaw control would not be possible with this setup because theIMU has no gyroscopefor the yaw. Therefore a gyro could be added, but this would not give an absolute valuefor the yaw. Also this time SparkFun has a solution: a HMC6352compass sensor fromHoneywell (see [4] for the datasheet) on a breakout board. This sensor has an I2C interfaceand measures the compass heading with a precision up to one thenth of a degree. The I2Cinterface is an interface with two wires, SCL and SDA. SCL functions as clock and SDAtransports the data from and to the device.
MicroTeam has chosen their own IMU and doesn’t need the ADXL330, the IDG300and the compass sensor. The chosen ADIS16350 (see [1] for thedatasheet) has an SPIinterface. This is a 4 wire interface, the wires are named MOSI, MISO, SCK andSS. TheMOSI (Master Out Slave In) transports data from the master tothe slave and MISO (MasterIn Slave Out) from the slave to the master. SCK is the clock andSSis the Slave Selectsignal. The bar above SS means it is active-low. If only one device is used this signal canbe connected to the ground on the slave side. If more devices are used the microcontrollercan use this to select the device it wants to talk to.
For the pressure sensor we looked no further than SparkFun and chose the SCP1000
1www.sparkfun.com
6
Design Exploration 2.5 Choosing the microcontroller
barometric pressure sensor from VTI technologies. This sensor has an SPI interface andmeasures the pressure from 30kPa to 120kPa and is able to measure the altitude with aprecision of 8cm two times a second or with a precision of 20 cmnine times a second. Thiswould fulfill the needs of MicroTeam.
2.5 Choosing the microcontroller
The microcontroller to be used has to connect to all sensors mentioned in the previoussection. The following interfaces have to be supported:
• 5 analog inputs for the IMU.
• An I2C interface for the compass.
• An SPI interface for the pressure sensor and the ADIS16350 IMU.
• RS232 to connect to the X32 board.
These interfaces could be implemented in software but a hardware interface is preferredbecause this saves processing time. For development of the software for the microcontrollerthe following is needed:
• A UART to connect the microcontroller to the serial port of the PC.
• An interface to program the microcontroller in-circuit.
• Having a good, preferably free, C compiler available for themicrocontroller.
Furthermore the following things are required:
• 4 PWM outputs to control the four motors. This can be used to control servo’s andDC motors.
• The X-Ufo has 4 leds, one under each motor, for decoration andto show which of thefour rotors is the front. These leds have to shine and it wouldbe nice to control theseleds.
• A connector which brings a couple I/O pins to the outside world for future extensions.
• A hardware multiplier. The microcontroller has to do control which implies multiply-accumulate operations. A hardware multiplier saves time.
• A sufficient amount of program and data memory to be able to write a serious amountof software and not having to worry about having enough memory.
• The microcontroller should be fast enough. The faster the better, more operations persecond gives more processing power so you can do more and moreadvanced things.
7
2.5 Choosing the microcontroller Design Exploration
• The microcontroller has to work in a little rough environment, 4 PWM controlledmotors, each one drawing 1A from the power supply — which might be a battery —guarantees that the supply voltage will be noisy. This can besmoothed with capacitorsbut capacitors can’t fix everything.
The microcontroller used in the helicopter is a PIC18F1220P. For this goal this micro-controller is not suitable. It has a maximum of 16 I/O pins available which is insufficient.Microchip offers a parametric search function on their website to determine which micro-controller has the features you need. Doing a parametric search on microcontrollers from thePIC18F-series with requirements “status = in production”,“memory type = flash” (repro-grammable), “Program memory=128KB” (the maximum in the PIC18F-series) and “CPUspeed = 12 MIPS” (also the highest available) resulted in a list of 4 microcontrollers. Thedifferences between these 4 microcontrollers was in the number of ADC channels (8 or 12)and the USB interface. The PIC18F67J11 was the cheapest and because 8 ADC channels issufficient and an USB interface is not needed so this would be an option.
However, there is a little difficulty. There are in principletwo compilers available for thePIC18F: MPLABR© C18 student edition from Microchip and the Small device C compiler(SDCC)2. MPLAB R© C18 looks promising but is only available for Windows and is akindof trial version because it disables some optimizing features after 60 days. SDCC is opensource and free but on the website is stated that PIC18F support is a work in progress andthe list of supported microcontrollers does not explicitlymention the PIC18F67J11.
There are more companies producing microcontrollers. For hobbyists there are in prin-ciple two main options for microcontrollers, Mircochip andAtmel. When looking at At-mel’s assortment, a powerful microcontroller is the ATmega128. Key features are: RISCarchitecture, 16 MIPS, 128KB program memory, 4KB ram, up to 53 I/O pins, SPI, I2Ccompatible two-wire interface, 8-channel 10 bit ADC, 8 x 8 bit hardware multiplier, 6 PWMchannels, 2 UARTS, in system programmable. See [3] for more information. Above thatthe GNU C compiler GCC supports nearly all Atmel microcontrollers. With its 16 MIPSand 2 cycle hardware multiplier it should be powerful enoughto do control. Conclusion:this microcontroller has all we need.
Experiences of hobbyists with Atmel and Microchip microcontrollers is that Atmelsare more hobbyist-friendly. An Atmel can be programmed witha computer’s parallel portusing only 3 resistors and they tend to be tougher than Mircochip when talking about thestability with a noisy power supply. During the developmentof the helicopter hardware thePIC18F1220P could not be run the on its maximum speed (10 MIPSat 40 MHz) which isnot very promising. We never encountered problems running Atmels on their maximumspeed, 16 MHz in case of the ATmega128. Most instructions take a single clock cycle so,with up to 16 MIPS, they could be faster than a PIC18F. Taking into account that GCC isavailable for the ATmega128 decided for the ATmega128.
2http://sdcc.sourceforge.net/
8
Design Exploration 2.6 Power supply and motor control
2.6 Power supply and motor control
The X-Ufo gets its power from a 12V NiMH battery and the Insight has a 7.4V LiPo battery.Some parts need a supply voltage of 5V and others need 3.3V. Therefore the voltage has tobe adjusted. We could use a high performance DC-DC converterto convert the power fromthe battery to the required voltage. The risk of using DC-DC converters is that it can bedifficult to get them stable. Although linear regulators arevery unefficient, the amount ofwasted power is negligible compared with the power that is consumed by the motors (up to12W per motor). Therefore we decided to use standard linear voltage regulators. For 5Vthe standard choice is the widely used 7805. For 3.3V the LM3940 was chosen.
The motors in the X-Ufo are DC motors and the Insight has motors with a servo in-terface. A servo interface is a form of PWM. The easiest method to control the speed ofDC motors is by pulse-width-modulating the supply voltage of the motors. As the currentthat flows through the motors is about 1A and a microcontroller cannot handle these largecurrents we need something to do the switching. Field-effect-transistors (FETs) are a goodchoice for this situation. FETs combine fast switching witha low resistance. Originally theIRF1010N FET was chosen. This FET has a TO220 package and has an RDS(on) of 12mΩ.When buying the parts for the prototype the electronics shopdid not have the IRF1010Nand the shop owner suggested the smaller, TO-92 packaged BS170. Trusting his experiencethe BS170 was chosen, but looking at the datasheet shows thatthe static on-resistance is1Ω, which would cause a dissipation of 1W when 1A flows through the FET. While testingwith the prototype the X-Ufo did not lift off; it was impossible to get the motors run fastenough. When checking the hardware the BS170 FETs were extremely hot so another FEThas to be chosen.
The original X-Ufo hardware used FDS9926 FETs from Fairchild semiconductor. Asingle FDS9926 combines two FETS in one SOIC-8 package. These FETs have anRDS(on)
of 0.030mΩ at a gate-source voltage of 4.5V, even better than the IRF1010N. The FETs weredesoldered from the original hardware and put into the prototype and it worked beautifullyso the FDS9926 was chosen as FET to control the motors.
Table 2.2: Hardware summary
Function IN4073 version MicroTeam versionMicrocontroller ATmega128 ATmega128Connection RS232 MZK Profi Penta (wireless,
PWM output)Inertia ADXL330 and IDG300 (analog) ADIS16350 (SPI)Absolute yaw HMC6352 (I2C) noneAltitude SCP1000 (SPI) SCP1000 (SPI)
9
2.7 Summary Design Exploration
2.7 Summary
The components used in the IN4073 and MicroTeam version are summarized in Table 2.2.There are differences between the IN4073 version and the MicroTeam version but the prin-ciple of both versions is the same. The sensors used in the IN4073 version are all fromSparkFun Electronics and are available on a breakout board which saves difficult soldering.
10
Chapter 3
Hardware design
This chapter gives the schematic of the hardware that was designed. First an overview willbe given and then each part is described in more detail. Choices made during the designwill be explained to give insight in the reasoning behind theschematic.
3.1 Overview
To get a good overview Figure 3.1 gives a block diagram of the system. On the left are thesensors. Some sensors are only used in the Insight version and some are used only in theX-Ufo version. In the middle is the ATmega128, the microcontroller. On the right are theFETs that control the motors. The labels beside the arrows indicate the kind of signal. Thenext sections cover the internals of the blocks.
Because the ATmega128’s RS232 interface is on the 0-5V levela level converter isneeded to connect to the PC. A standard MAX232 circuit is usedto do this level conversion.Some systems need 5V and some need 3.3V and the motors run on 12V. Therefore the 12V input from the battery or power supply is converted to 5V and3.3V using respectively a7805 and an LM3940.
3.2 The microcontroller
The ATmega128 is available in two versions. The normal version needs 4.5 to 5.5V andallows for clock speeds up to 16MHz. The version with an L suffix allows for a supply volt-age down to 2.7V but runs no faster than 8MHz. As 5V is available and there is no reasonto choose the L version, the normal version was chosen. The VCC pins are connected to5V and two capacitors stabilize the supply power. C10, the 100µF capacitor can eventuallybe smaller but 100µF is more on the safe side. In the prototype, all polarized capacitors inthe schematic were electrolytic capacitors (ELCOs) but they can be replaced with tantalumcapacitors to save on weight and size.
The reset pin is active low and to keep te microcontroller outof reset mode it has to beconnected to +5V. R1 is used to allow the microcontroller to be reset by the programmer
11
3.2 The microcontroller Hardware design
Figure 3.1: Overview of the hardware
(RST is connected to the programmer) or by using button S1. C11 is to keep spikes or noisefrom resetting the microcontroller.
PEN is also connected to +5V. This is needed to be able to program the microcontroller.If PEN is not connected the microcontroller cannot be programmed.
LED4 indicates that 5V is supplied and LED1 and LED2 have no special function butcan for example be used to indicate if the link is up (as the helicopter had).
Then the are a couple of pinheaders:
• JP3 connects this part of the hardware to the separate board with the RS232 levelconverter. It uses mostly the standard Atmel ISP pinout but the 3.3V, RxD and TxD
12
Hardware design 3.3 The sensors
Figure 3.2: Schematic of the microcontroller and directly connected parts
are added.
• For future extensions JP2 is an extension header that connects to all pins of PORTAand has a +5V and GND pin.
• JP9 and JP13 connect to the board with the voltage regulatorsand FETs.
• JP18 is connected to the Profi Penta receiver. The receiver outputs a PWM signal at50 Hz. To detect this signal it is connected to an external interrupt pin. This pin isconfigurable for the detection of rising edges, falling edges, rising and falling edgesand a low level on the pin. In combination with a timer it shouldn’t be to difficult todecode this signal.
3.3 The sensors
Figure 3.3 shows all four sensors. These four sensors are never used together becauseInsight does not use the compass nor the ADXL330/IDG300 IMU and for IN4073 theADIS16350 is not used. The pinheaders drawn in the schematicindicate the location of
13
3.3 The sensors Hardware design
Figure 3.3: Schematic of the sensors
the header on the breakout board. The schematics of the breakout boards are given in Ap-pendix A
The ADIS16350 and the pressure sensor have an SPI interface.To connect multipledevices to an SPI bus the slave select signal has to be used. When the slave select is highan SPI slave sets all outputs in high-impedance mode so that it is virtually disconnected.When slave select is low the slave is selected. A diode is added in the MISO line to avoidproblems when in case of a bug both devices get selected.
Something to keep in mind is that the pressure sensor is configured by default to ignorethe slave select signal. This can be fixed by changing the content of the CFG2 register.Refer to the datasheet [12, section 4.1.2] for more information
The pressure sensor is a 3.3V device and the ATmega128 is a 5V device so level con-version has to be done for signals from the ATmega to the pressure sensor. This is done bythe zener-diodes D1, D2 and D3.
14
Hardware design 3.4 Connecting to the PC
Each sensor is supplied with the required voltage. If the sensor can work on 3.3 and 5V,5V was chosen for easy interfacing.
What is not in the schematic but is done in the prototype is themodification of thefilter of the IDG300 on the breakout board. Figure 3.4 shows a part of the IMU breakoutboard schematic. The XOUT and YOUT signals are filtered usingan RC filter. The cutofffrequency for such a filter is given by:
fc =1
2πRCHz
In this caseR= 750Ω andC = 0.1µF, thus fc ≈ 2.1KHz. In practice the sample rate ofthe system is at most 1KHz so to prevent aliasing the bandwidth of input signal must be lessthan 500Hz. The information in these signals is present in the lower part of the spectrum,below 50Hz; the part above 50Hz is mainly noise and vibrationof the frame due to therunning motors. Therefore, the 750Ω resistor was replaced with a 33kΩ resistor so the newcutoff frequency is about 48Hz. This provides sufficient damping for unwanted frequencies.
Figure 3.4: Schematic of the IDG300 part of the IMU breakout board
The HMC6352 compass has an I2C interface which usually requires pullup resistors.The pullup resistors are not present in the schematic because the ATmega128 has built-in switchable pullup resistors. Notice that the breakout board from SparkFun Electronics,depiced in Figure 3.5 has a small mistake, the north-arrow does not point to the north but tothe west.
15
3.4 Connecting to the PC Hardware design
Figure 3.5: Picture of the compass on its breakout board withthe wrong arrow
Figure 3.6: Schematic of the RS232 level conversion
3.4 Connecting to the PC
Figure 3.6 shows the schematic of the separate board that connects the hardware to the PC.The X-Ufo or Insight quad-rotor is connected via JP14. JP15 is used to connect to an At-mel ISP programmer. A simple ISP programmer for the parallelport can be obtained fromhttp://aavrs.nl/index.php?p=55 . For computers without parallel ports USB program-mers like this one:http://www.aavrs.nl/index.php?p=1012 are available. Using aUSB-parallel converter is not recommended because in practice they only work for printers.
A standard MAX232 is used to convert the 0-5V RS232 signals from the ATmega to theRS232 level voltages to connect to the pc’s serial port. For computers without serial portsUSB-serial converters do a good job or a circuit with an FTDI FT232R USB UART chipcan be built.
16
Hardware design 3.5 FETs and power
3.5 FETs and power
Figure 3.7: Schematic of the power supply and motor controlling FETs
The X-Ufo gets its power from a 12V NiMH battery1 and the Insight quad-rotor uses a7.4V LiPo battery. The battery is connected to JP11. To convert these voltages to 5 volt a7805 is used and for 3.3V an LM3940 is used. The LM3940 needs atleast a 33µF capacitoron its output to get a stable 3.3V.
1For IN4073 it might be an idea to use a 12V/4A DC power supply because X-Ufo drains the battery inabout 5 minutes.
17
3.6 Connecting to the X32 Hardware design
The motors are switched by FDS9926 FETs. The FETs have a pull-down resistor onthe gate to prevent that noise on the gate will open the FET andlet the motors run when theATmega128 is in reset state or programming mode.
The leds that are mounted under the motors in the X-Ufo are switched on by connectingthem to +5V and switched off by putting the output port of the ATmega in high impedancemode. Due to the construction of the ATmega it is not possibleto switch off the ledscompletely, so ‘off’ means ‘dimmed’.
JP10 and JP12 connect to JP9 and JP13 on board with the microcontroller and sensors.
3.6 Connecting to the X32
This section is only important for IN4073 because MicroTeamdoesn’t use the X32. Toconnect the hardware to the X32 the following connections have to be made:
• Connect B1 pin 1 (GND) to JP3 pin 10 (GND)
• Connect B1 pin 9 (RxD) to JP3 pin 6 (TxD) via a 270Ω resistor2.
• Connect B1 pin 11 (TxD) JP 3 pin 8 (RxD)
The X-Ufo software uses a different protocol than the helicopter hardware did. Becausethe sensors of the X-Ufo are more precise, the sensor values needed more bits than fittedin the old protocol. Therefore a modified version of thetrex_comm peripheral was madeunder the namexufo_comm . The modified X32 source tree is available on the accompaniedCD. The new make target is namedx32-in4073-xufo .
The communication between the X-Ufo and the X32 is an 500kbps, 8 databits, no parityand 1 stopbit link. Data from the X-Ufo to the X32 is transmitted in packets of 3 bytes asfollows (MSB - LSB):
1aaadddd 0ddddddd 0ddddddd
where ’a’ denotes an address bit, and ’d’ denotes the actual data. Thexufo_commperipheral makes all sensor values available viaperipheral[PERIPHERAL_XUFO_S0] toperipheral[PERIPHERAL_XUFO_S6] . The xufo_comm peripheral generates an interruptnamedINTERRUPT_XUFOwhen the seventh sensor value is received. This happens aboutevery 1ms. Table 3.1 lists the addresses, the sensors and thedata format of the sensors.
Data from the X32 to the X-Ufo is transmitted via the character based UART. To senddata to the X-Ufo setperipheral[PERIPHERAL_XUFO_A] to the byte that has to be sent.
The protocol to be used to transmit data to the X-Ufo is slightly different:
1aaaaaaa 0ddddddd 0ddddddd
Although the address part is longer only the first 5 adresses are used. See Table 3.2 forthe list.
2The Spartan-3 FPGA can tolerate 5V signals only when using a resistor, according to [16, p. 31].
18
Hardware design 3.6 Connecting to the X32
Table 3.1: Sensor address map
Address Sensor Data format0 ADXL330 acceleration in X-direction 10 bits unsigned1 ADXL330 acceleration in Y-direction 10 bits unsigned2 ADXL330 acceleration in Z-direction 10 bits unsigned3 IDG300 gyroscope for the X-axis 10 bits unsigned4 IDG300 gyroscope for the Y-axis 10 bits unsigned5 HMC6352 compass heading 0-3599 (0.1 degrees)6 SCP1000 barometric pressure 17 bits unsigned
Table 3.2: Actuator address map
Address Sensor Data format0 Leds 4 bits: front (red), right, back, left1 Front motor 11 bits: 0 is off, 2047 is full on2 Right motor 11 bits: 0 is off, 2047 is full on3 Back motor 11 bits: 0 is off, 2047 is full on4 Left motor 11 bits: 0 is off, 2047 is full on
When no data is received for a certain amount of time the X-Ufoshuts the motors downand enters a safe state. A blinking led indicates that the ufois in safe state3.
3The prototype has no extra leds and uses the four X-Ufo leds for this purpose
19
Chapter 4
Experimental results
Experiments were done to see if the hardware fulfills the requirements and is usable forIN4073 and MicroTeam. This chapter describes the software that was written, the experi-ments and their results.
4.1 ATmega128 software
The ATmega128 software is written in C and compiled wit GCC-AVR. The software hasat this moment support for the ADXL330 accelerometer, the IDG300 gyroscope and theHMC6352 compass, which is enough for the IN4073 lab course. The software is availableon the accompanied CD. Figure 4.1 gives an overview of the structure of the software. Thecircles are separate C files.
Main contains the main loop and the Interrupt Service Routines (ISRs). The main loopread the sensors, transmits these to the X32 and checks if thelink with the X32 is workingproperly. The ADXL330 and IDG300 are analog and are read via the AD converter usingfunctions inadc . The compass is an I2C device and is read using functions incompasswhich usesi2c for the I2C functions.i2c is a library made by Peter Fleury and is availablefrom http://jump.to/fleury . The compass has an update rate of maximum 20Hz so itis queried only once per so many calls of the compass read function.
The ATmega128 software has, according to David A. Wheeler’s‘SLOCCount’, 801source lines of code.
4.2 Modifying the trex comm device
As mentioned in Section 3.6 the protocol that is used to communicate between the X32 andthe X-Ufo is different from the protocol that was used for theTREX. For communicationfrom the X32 to the X-Ufo this is only a change in software on the X32 side. From theX-Ufo to the X32 a special peripheral is used. This peripheral is written in VHDL andsynthesized into the X32 before it is flashed in the FPGA. To let the X32 recognise theprotocol this peripheral has to be changed.
21
4.2 Modifying the trexcomm device Experimental results
Figure 4.1: Structure of the software for the ATmega128
The oldtrex_comm device consists of an RS232 transmitter and receiver. The receiveris connected to a Finite State Machine (FSM). A diagram of theFSM is given in Figure 4.2
Figure 4.2: Finite State Machine of the trexcomm peripheral
The FSM starts in the FIRST state and if it receives a byte thathas the MSB equalto 1, which indicates a first byte, the byte is stored in a buffer and the FSM advances tothe SECOND state. On receipt of another byte with MSB equal to0 the address decodingis done and the value of this packet is stored in the appropriate sensor value buffer. Ifthe address is equal to 1002 (410) the data in the sensor value buffers is transported to theoutputs and an interrupt is issued to indicate that a new set of all sensor values is available.
22
Experimental results 4.3 X32 software
The user who programs the X32 can define an interrupt service routine that is executedwhen this interrupt is issued. The registers that hold the sensor data are memory mappedand available for the user as a variable.
Figure 4.3: Finite State Machine of the xufocomm peripheral
The X-Ufo protocol has one byte and two addresses more than the TREX protocol soan extra state and two buffers have to be added. The modifiedtrex_comm device is namedxufo_comm . The FSM of thexufo_comm peripheral is given in Figure 4.3. The bus-widthof the X32 is 32 bits so the increase in length from 10 to 17 bitsfor the sensor values isno problem for the X32. The interrupt is now generated when the address is equal to 1102
(610).
4.3 X32 software
The ATmega128 has only 4 KB RAM. This is enough for normal situations but for thelogging of sensor data this is far too little. Sending the measurement data to the PC is notan option because most modern PC’s have a 16550A UART which can handle only 115,200bps while the X-Ufo hardware runs on 500 kbps. Lowering the X-Ufo speed to 115,200 bpsis possible but with an error of 2.1% when using a 16MHz crystal, according to [3, p. 198].In practice this is too much and the PC receives garbage. The highest possible speed thatworks is 38,400 bps.
The X32 has 1MB RAM so sending the sensor data to the X32 to let the X32 log thesensor data would be the easiest option. A simple program waswritten that sends the controlcommands from the PC to the X-Ufo to be able to control the ufo.The program logs thedata and saves it in its memory. When the memory is full the data is transmitted to the PC.The PC saves the data and writes a gnuplot script for easy plotting.
The amount of source lines of code is 319 for this program.
23
4.4 PC application Experimental results
4.4 PC application
For testing purposes and receiving the log files an application on the PC was written. Ascreendump of the application is given in Figure 4.4. The application is written in C usingGTK as widget toolkit and the cairo graphics library to draw the position of the joystick andthe position of the ufo. The program is multithreaded, one thread reads the joystick, onethread reads the serial port, one thread writes to the serialport and one thread is the mainthread.
Figure 4.4: Screendump of the PC application
At the start of the program the other threads are created and the serial port and thejoystick device are opened.
The X32 sends data to the PC and when the serial-read thread updates the sensor read-ings, calculates the position and updates the compass, sideand front views to reflect thecurrent state of the ufo.
When the joystick changes the joystick thread updates the joystick position view. Therotation of the position cross gives reflects the rotation ofthe joystick twist handle. Thearrows under the position view display the state of the POV-hat of the joystick and thecheckboxes are checked when the corresponding button is pressed. The new pitch, roll,yaw and lift values are passed to the serial-write thread andthe thread is woken up. On
24
Experimental results 4.5 Experimental results
wake up the thread sends all information to the X32. The thread has a sleep timeout suchthat the state is updated at least once per 500ms.
The application can work with keyboard control by activating the keyboard control textbox. The application cannot work without joystick but modifying the application such thatit works without joystick should be rather straightforward.
When the logging start button is clicked the application sends the log command to theX32 and goes in log receiving mode. All received data is put into a file until the X32indicates the end of the log.
Features visible in the interface that are not (yet) implemented in the X32 or ATmega128are:
• Control: The pid values for the yaw, roll and pitch controller can be entered andmodified and are transmitted to the X32 but the X32 does not usethe values.
• Filtering: filtering is implemented in the ATmega128, more on that in the experimentsbut it can only be enabled or disabled by reprogramming the ATmega128. Filteringis something that the IN4073 students have to implement themselves in the X32.
• Other modes than manual and safe mode. As no control is implemented in the X32or ATmega128 the other modes don’t make sense and act only as safemode.
The PC application is the largest of the three programs, it contains 1966 source lines ofcode.
4.5 Experimental results
A number of experiments are done to check the capabilities ofthe sensors and the wholesystem. The first experiment is a simple pitch/roll with motors off. Figure 4.5 shows a graphof the measured sensor data. In this graph x, y and z refer to the accelerometers and xr andyr to the gyroscopes.
The plot shows a smooth line and displays the movements of theufo accurately. Thisaccurateness is nice but when the motors are running at only half power an extreme amountof noise is produced, due to the vibrations of the frame. Thiscan be seen in Figure 4.6. Itgets even worse when applying full power, as in Figure 4.7.
This does not mean that all is lost and there is nothing that can be done. A simple secondorder Butterworth filter is able to reduce the noise in such a way that it looks like there isno noise at all. Figure 4.8 shows the result of such filtering.
In the beginning of this project there were some doubts aboutthe usability of the com-pass sensor in combination with the magnetic field of the motors. This is in practice noproblem at all. Comparing Figure 4.9 and 4.10 shows no noise or problems. The compassdata shown in the graphs is not filtered and there is no need forfiltering. If filtering iswanted, the compass can do measurement summing (see [4, p. 8]). The compass is alsoinsensitive to vibration because it is not a classical compass with a needle but it measuresthe earth magnetic field directly.
25
4.5 Experimental results Experimental results
0
100
200
300
400
500
600
700
800
900
1.35e+09 1.4e+09 1.45e+09 1.5e+09 1.55e+09 1.6e+09 1.65e+09 1.7e+09 1.75e+09
xyzxryr
Figure 4.5: Plot of the sensor data while doing pitch/roll movement with motors off
0
100
200
300
400
500
600
700
800
900
0 5e+07 1e+08 1.5e+08 2e+08 2.5e+08 3e+08 3.5e+08
xyzxryr
Figure 4.6: Plot of the sensor data while doing pitch/roll movement with motors at halfpower
26
Experimental results 4.5 Experimental results
0
100
200
300
400
500
600
700
800
900
5.5e+08 6e+08 6.5e+08 7e+08 7.5e+08 8e+08 8.5e+08 9e+08 9.5e+08
xyzxryr
Figure 4.7: Plot of the sensor data while doing pitch/roll movement with motors at fullpower
0
100
200
300
400
500
600
700
800
900
1e+08 1.5e+08 2e+08 2.5e+08 3e+08 3.5e+08 4e+08 4.5e+08 5e+08 5.5e+08 6e+08
xyzxryr
Figure 4.8: Plot of the filtered sensor data while doing pitch/roll movement with motors atfull power
27
4.5 Experimental results Experimental results
0
500
1000
1500
2000
2500
3000
3500
1.75e+09 1.8e+09 1.85e+09 1.9e+09 1.95e+09 2e+09 2.05e+09 2.1e+09 2.15e+09
compass
Figure 4.9: Plot of the compass data while rotating the ufo with motors off
0
500
1000
1500
2000
2500
3000
3500
5e+08 5.5e+08 6e+08 6.5e+08 7e+08 7.5e+08 8e+08 8.5e+08
compass
Figure 4.10: Plot of the compass data while rotating the ufo with motors on
28
Experimental results 4.6 Weight of the prototype
4.6 Weight of the prototype
Because one of the requirements is that the solution has to flyand should not be too heavy,the weight of the prototype was measured to give an indication of the weight. Table 4.1 liststhe results. The values are measured using a standard digital kitchen scale and are purelymeant as indication. To save weight, trough-hole components can be replaced by surfacemount components and the pcb can be replaced with a thinner variant.
Table 4.1: Weight of parts of the X-Ufo and the prototype
Measured object MassComplete X-Ufo with prototype 228 gCompass sensor on breakout board 2 gPressure sensor on breakout board 2 gADXL330/IDG300 IMU breakout board 3 gX-Ufo without prototype 180 gPrototype with IMU and compass 48 gX-Ufo standard battery 78 gADIS16350 (according to [1, p. 6]) 16 gMZK Profi Penta receiver 4 g
The prototype has no pressure sensor but if it would have the total mass would become50 g for the IN4073 configuration. Based on this information,the MicroTeam version wouldbe 48-2-3+16+4=63 g.
4.7 Conclusion
This chapter shows that the developed hardware works and is usable. The experiments showthat the accelerometers and gyroscopes are sensitive to vibrations, but this is easy to filter.The compass is not sensitive to vibrations nor to the magnetic field produced by the motors.The total weight of the prototype is 48 g. The total amount of source lines of code is 3086for the ATmega128, X32 and PC software together.
29
Chapter 5
Conclusions and Future Work
In this report we have described the design of an embedded system aimed to control quad-rotor aerial vehicles in the context of the IN4073 Real-TimeEmbedded Systems lab courseat the EEMCS faculty and the MicroTeam quad-rotor project atthe Aerospace Engineeringfaculty.
The selected hardware for the IN4073 version is an InvenSense IDG300 dual axisMEMS gyroscope, an Analog Devices ADXL330 iMEMS accelerometer, a VTI Technolo-gies SCP1000 pressure sensor, a Honeywell HMC6352 digital compass sensor and an AT-mega128 microcontroller.
The MicroTeam version has an Analog Devices ADIS16350 IMU, aVTI TechnologiesSCP1000 pressure sensor, an MZK Profi Penta receiver and an ATmega128 microcontroller.
The microcontroller is in-system programmable and can communicate to the PC orX32 using an RS232 connection. The motors are controlled using PWM in the IN4073version and as servos in the MicroTeam version. For future extensions an extension headeris available with 8 I/O lines and a +5V and GND line.
Experiments show that the ADXL330 and IDG300 fulfill the needs for IN4073 in thisconfiguration, but filtering needs to be applied.
The total mass of the IN4073 prototype is 48 g and a MicroTeam version of this proto-type would weigh 63 g.
5.1 Reflection and future work
I learned many new things. In software development I learnedto know and use a couplenew libraries. To test the hardware and make an example for IN4073 I wrote a PC. Thisapplication uses GTK, pthreads, the cairo graphic library and more supporting libraries. Idid not like LATEX before I wrote this report because I didn’t know it. After reading a tutorial,buying a good book and writing this report my view on LATEX has changed.
I also learned to double-check the position of a TQFP packaged chip before solderingit. When doing the first test with the prototype board the board consumed about 150mAwhen doing nothing. Checking the board for a short circuit didn’t help. Finally I found outthat the orientation of the ATmega128 was wrong by 90 degrees. That happened because
31
5.1 Reflection and future work Conclusions and Future Work
I accidentally took the ISP connector for the extension header and based the orientation ofthe ATmega on the wrong header. I had to remove the chip and order a new one.
As this assignment was multidisciplinary, I learned that aerospace engineers think inweight and Matlab while electrical engineers don’t care about the weight and think in C.
This research assignment was a full time job for two and a halfmonths and it took muchtime but it was worth it and I’m proud of the result.
There is more to explore in quad-motor aerial vehicles. Research questions I can thinkof at this moment are:
• How fast can we measure the sensors by fine tuning the softwarein the ATmega128?
• Which control algorithm will deliver the best stability forthe amount of processingpower that is available with the ATmega128?
• What is the minimum effort that is needed to get the X-Ufo stable?
• Will the use of a real-time OS improve the stability/usability?
32
Bibliography
[1] Analog Devices, Inc.ADIS16350 datasheet — Tri-Axis Inertial Sensor. http://www.analog.com/UploadedFiles/Data_Sheets/ADIS16350.pdf .
[2] Analog Devices, Inc. ADXL330 datasheet — Small, Low Power, 3-Axis±3g iMEMSR© Accelerometer. http://www.analog.com/UploadedFiles/Data_Sheets/ADXL330.pdf .
[3] Atmel Corporation.ATmega128 and ATmega128L datasheet — 8-bit Microcontrollerwith 128K Bytes In-System Programmable Flash. http://www.atmel.com/dyn/resources/prod_documents/doc2467.pdf .
[4] Honeywell. Digital Compass Solution HMC6352. http://www.ssec.honeywell.com/magnetic/datasheets/HMC6352.pdf .
[5] InvenSense, Inc.IDG300 datasheet — Integrated Dual-Axis Gyro. http://www.invensense.com/shared/pdf/IDG300_Datasheet.pdf .
[6] Microchip Technology Inc. PIC18F1220/1320 Data Sheet. http://ww1.microchip.com/downloads/en/DeviceDoc/39605F.pdf .
[7] muRata. ENC-03J datasheet — Piezoelectric Vibrating Gyroscopes (GYROSTARR©).http://www.murata.com/catalog/s42e.pdf .
[8] SparkFun Electronics. Wii-mote guts, december 2006.http://www.sparkfun.com/commerce/present.php?p=Wii-Internals .
[9] TUDelft Faculty of EEMCS. Computer engineering msc programme study guide,2006/2007. Available fromhttp://campus.ewi.tudelft.nl/ via “Study guides(PDF files)”.
[10] Arjan J.C. van Gemund. IN4073 assignment for 2006.http://www.st.ewi.tudelft.nl/ ˜ gemund/Courses/In4073/2006/assignment.pdf .
[11] Arjan J.C. van Gemund. IN4073 course website 2006.http://www.st.ewi.tudelft.nl/ ˜ gemund/Courses/In4073/2006/index.html .
33
BIBLIOGRAPHY
[12] VTI technologies.SCP1000 series absolute pressure sensor product family specifica-tion. Available from http://www.vti.fi/en/products-solutions/products/pressure-sensors/scp1000-pressure-sensor/ .
[13] Sijmen Woutersen. X32 32 bit softcore home page.http://x32.ewi.tudelft.nl/ .
[14] Sijmen Woutersen.X32 Programmers manual, November 2006.http://x32.ewi.tudelft.nl/x32progman.pdf .
[15] Sijmen Woutersen. The X32 softcore – a top-down approach on processor de-sign. Master’s thesis, TUDelft, 2006.http://x32.ewi.tudelft.nl/woutersen_thesis.pdf .
[16] Xilinx, Inc. Spartan-3 Starter Kit Board User Guide. http://www.digilentinc.com/Data/Products/S3BOARD/S3BOARD-rm.pdf .
34
Appendix A
Schematics of the breakout boards
This appendix gives the schematics of the breakout boards. These schematics are designedby SparkFun Electronics and Copyrightc© 2007 SparkFun Electronics.
Figure A.1 gives the schematic of the IMU breakout board. To reduce the bandwith ofthe gyroscope signals, R2 and R3 are replaced with 33k resistors in the prototype.
Figure A.2 gives the schematic of the pressure sensor breakout board.The compass sensor breakout board contains no additional electronics, only a small
capacitor with an unknown value between GND and 3.3v. Pin 5 isconnected to GND, pin7 to SDA, pin 10 to SCL and pin 14 to 3.3v (the compass works on 2.7 to 5V).
35
Sch
em
atics
ofth
ebre
ako
ut
board
s
1
1
2
2
3
3
4
4
D D
C C
B B
A A
Title
Number RevisionSize
A
Date: 5/31/2006 Sheet of File: C:\Global\..\IMU Combo - v03.schdoc Drawn By:
IMU 5 Degrees of Freedom
Spark Fun Electronics
0.1uFC11
GND3.3V
ST
0.1uF
C8
0.1uF
C9
XAxis
YAxis
VCC
ST
NC4
NC9
COM3
CO
M5
NC
16
VC
C15
NC1
ST2
CO
M6
CO
M7
Z-O
ut
8
Y-Out10
NC11
X-Out12V
CC
14
NC
13
ADXL330U2
0.1uF
C10ZAxis
XAxisYAxisZAxis
0.22uFC6
2.2
R1
0.1uFC7
0.22uFC5
0.1uFC1
3.3V
X-Rate VRefY-Rate
750
R3XAGC
8
GN
D2
Xout3
VD
D14
CPOUT17
GN
D22
YAGC23
GN
D25
Yout28V
DD
29
Vref32
VD
D34
GN
D38
GN
D39
GN
D40
IDG-300U1
0.1uFC4
1.0uFC2
VCC
VCC
0.1uFC3
750
R2
X-Rate
VRefY-Rate
123456789
Header 9
JP1
Figure
A.1:
IMU
breakoutboard
schematic
36
Schematics of the breakout boards
Figure A.2: Pressure sensor breakout board schematic
37
Appendix B
Contents of the CD
The accompanied CD contains the following files and folders:
• report.pdf : This report in PDF format.
• references : Electronic versions of the referenced sources.
• schematics : Schematic in CadSoft EAGLE format. The board file is incomplete butincluded anyway so that it might save work.
• x32 : contains the complete X32 package fromhttp://x32.ewi.tudelft.nl withthexufo_comm peripheral. For synthesizing and compiling see [14] and [15].
• xufo-emb : The ATmega128 software. To compile this code gcc-avr and avr-libc areneeded. To program an ATmega128 avrdude is needed. Runmake all to compileandmake program to program the microcontroller.
• xufo-pc : The PC application that was made to test the prototype. Run./configureandmake all to compile. Xufo-pc uses quite a few libraries, at least libgtk2.0-dev,libgconf2-dev and libcairo2-dev and the kernel headers.
• xufo-x32 : The software that was written for the X32. This can be compiled usingthe tools in the X32 package. Runmake main to compile andmake uploadrun toupload the program to the X32 and run it.
Material in this report, pdf version, schematics, xufo-emb(with exception of the I2Clibrary and parts of the adc routines), xufo-pc and xufo-x32is copyright c© 2007 Marc deHoop and may not be used for commercial purposes. For commercial purposes contact theauthor.
39