L OW A LT I T U D E BA L L O O N E X P E R I M E N T S I N T E CH N O L O G Y ( L A B E T ) F I N A L R E P O RT

Transcription

1 L OW A LT I T U D E BA L L O O N E X P E R I M E N T S I N T E CH N O L O G Y ( L A B E T ) VERSION IV DEC09-14/LABETIV_SP09 F I N A L R E P O RT FACULTY ADVISOR S AND CLIENT: MATTHEW NELSON, DR. JOHN BASART SPACE SY STEMS AND CO NTROLS LAB TEAM MEMBERS: HENRI BAI STEVE BECKERT IAN MOODIE MIKE RAU DECEMBER 11, 2009 DISCLAIMER: This document was developed as part of the requirements of a multi-discipline design 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.

2 Table of Contents Aircraft Structural Design... 3 Chassis Materials... 3 Weight Reduction... 3 Base Station... 4 Message Protocol... 5 Aircraft Firmware... 6 Timers... 6 Fan, Servo Control... 6 ADC... 6 SPI... 7 RF Communication... 7 Control Algorithm... 7 Firmware Structure... 9 Testing...10 PIC24FJ64GA Component Testing...10 RC Aircraft Testing...11 Component Integration...11 Schematic/PCB Layout...12 Pin Assignments...12 Explorer 16, Prototype Pin Assignments...13 Schematic...14 Layout...15 Current State of LABET IV...16 Appendix...17 A) Message Protocol...17 B) Fan and Servo Control Interrupt...17 LABET IV PAGE 2

3 Aircraft Structural Design Chassis Materials Model of Frame (two motor, Cradle) The team decided to move forward with using ABS (acrylonitrile butadiene styrene) as the material of choice. ABS has good impact strength, is lightweight, and readily available. The key deciding factor was the cost of the material compared to carbon fiber or fiberglass. A sheet of ABS with dimensions x 24 x 48 cost approximately $11, while a similarly sized sheet of fiberglass costs upwards of $70 and carbon fiber was even higher. The sheet thickness was determined to be too thin to support the craft on its own, so when the individual pieces were cut out of the sheet, two layers were glued together to create the designed thickness of 1/8 th inch. Each piece was hand cut by utility knife and finished with a Dremel tool to clean any rough or sharp edges. The two gimble rings were modeled in SolidWorks and the model files sent to the ME Department Media Center where a rapid prototyping 3D printer made the actual parts out of ABS plastic. The initial consideration for these prototypes were not intended to be the final product, but after a light sanding, they proved to be strong enough to withstand any forces seen in-flight. Weight Reduction After the chassis was built and all the components mounted, the aircraft weight was over budget with the components installed. Further investigation showed the batteries were found to be overspecified from what the team originally designed. The weight difference was calculated to be at minimum 40 grams over allowance. In order to compensate for the extra load, chassis material was removed from non crucial areas. Cutting material in the SolidWorks model showed a weight loss of 45 grams with the specified material as ABS plastic. The actual weight loss of the entire chassis was approximately 65 grams while avoiding high stress areas. LABET IV PAGE 3

4 Base Station Aircraft Following Weight Reduction The purpose of the base station is to have a way to communicate with the aircraft through a standardized protocol. It can issue movement commands, landing commands, and various abort commands. The aircraft also sends a heartbeat signal that also has various debugging information. Information sent back from the aircraft is gyroscope information, accelerometer information, battery information, and temperature information. Commands sent to the aircraft include desired movement for translation is 3 axes, and rotation about the yaw axis. The base station is implemented in Labview. Labview was chosen for its ease of use, easily implemented serial port libriaries and HID libraries, as well as built-in safe asynchronous code execution. Data is received and sent through an RF module. The RF module is transmitted transparently and to Labview, looks like any ordinary com port. The RF pair needs to be configured once and can be turned on and transmit/receive. There are two main threads. One thread handles polling the controller data, building the packet, and sending it to the serial port. The other thread handles receiving data, checking if it is a valid data packet, and parsing the data. The receiving thread also outputs the received data to a user interface. Accessing the resources for the serial port is done thread-safe, meaning when writing or reading from the serial port, the operation is atomic. If the controller is in an idle state (no human interaction), the base station still sends a command, with the values set to the idle values. This is zero. All data is mapped from -100 to 100, or specifically, with a bias of This was chosen so no conversion is necessary on the aircraft firmware. LABET IV PAGE 4

5 LabView Base Station Screen Shot The screen shot above shows the general UI of our base station. The controller buttons and knobs all change depending if it has changed on the physical controller. We used an X-Box360 controller. Each graph will be populated with data once we start receiving data from the aircraft. The left joystick controls translation, the right joystick controls yaw. When the trigger buttons are not pressed, the aircraft will try to maintain its current elevation. Pressing the left trigger will command a descent in the aircraft, and pressing the right trigger will command an ascent in the aircraft. Message Protocol The message protocol is set up as follows (everything is in number of bytes): Header Data Length Message Type Data Xor 3 Variable 1 Variable 1 The header will always consist of 0x19 0x28 0x37. The data length is the length of data starting from Message Type and up to, and including, the XOR. This was chosen such that the probability of accepting a message that has been unaligned is low, and we discard that packet. Packets with an incorrect xor byte will also be discarded. Appendix A lists all the possible message types. When receiving a packet, the base station checks if the header is exact 0x19 0x28 0x37. If it is not or if the error-checking xor byte does not match up, it discards the packet. If both the header and xor byte are correct, the software sends the data to parsing. LABET IV PAGE 5

6 Aircraft Firmware Timers The core of firmware on the aircraft is based on frequent repetitions of tasks. These tasks include polling sensors, sending status messages, and sending fan/servo control signals. This repetition is implemented using the PIC microcontroller s timers. All 5 PIC timers are used. Timer 1 is used to control sensor polling; timer 2 sends aircraft status messages; timers 3 and 4 control the servos and fans; and timer 5 is used as a delay during firmware initialization. Timers 1, 2, and 5 are configured 1 such that 1 tick of the timer is seconds. This means, with a two-byte count register, the functions associated with timers 1, 2, and 5 can alert with frequency 0.95 Hz to Hz. Times 3 and 4 are used in the generation of control signals to the fans and servos. As later explained, these pieces of the aircraft need precisely timed control signals. For this reason, timers 3 and 4 are 1 configured such that 1 tick of the timer is seconds. This allows for a higher resolution. 6 2e Fan, Servo Control Fans and servos are controlled by pulse-width modulation (PWM) signals generated by the PIC processor. This functionality is the most important task of the PIC and therefore the timer associated with this task has the highest priority and is unable to be interrupted by any other process. These signals are connected directly to the servos but must utilize an electronic speed controller in order to manipulate fan speeds. This results in both the fans and servos being controllable in similar methods. Both the fans and servos need a control pulse every 20 milliseconds. The length of the high pulse determines the angle of the servo or speed of the fan. This length ranges from 1ms to 2ms, with 1ms resulting in a minimum angle or minimum fan speed and 2ms resulting in a maximum angle or fan speed. The firmware accomplishes this control by first assigning 6 general purpose input-outputs (GPIOs), one for each of four servos and two fans. As shown in appendix B, the function ServoInterrupt() uses a switch statement to determine the appropriate count value to set in the timer. Since each servo receives only a maximum of 2ms pulse every 20ms, up to 10 servos can be controlled. The switch statement used to control servos has 5 states one for each of 4 servos and one state NO_SERVO. As an example, when ServoInterrupt() is run with current state SERVO_L1, the function first polls the software for the intended position of servo L1. The function then determines the count value necessary for the timer, sets the control line for servo L1 high and increments the current servo. The next time ServoInterrupt() alerts, the servo L1 control line is set low and the function repeats the previous sequence with servo L2. ADC The analog-to-digital converter (ADC) is responsible for polling the gyroscopes and sonar sensors. The ADC is configured such that the analog values 0 Volts to 3.3 Volts are mapped to the digital values 0 to These analog sensors are polled during each cycle of timer 1. LABET IV PAGE 6

7 SPI The serial peripheral interface (SPI) is responsible for communicating with the digital accelerometer. During initialization, the accelerometer is configured to high-sensitivity (±2g) and 16-bit resolution. The acceleration is measured in all 3 axes during each cycle of timer 1. RF Communication Communication with the base station is fostered by the Universal Asynchronous Receiver/Transmitter (UART). The Aerocomm wireless transceiver connects to the PIC s UART. To communicate with the base station, the transceiver is first configured to pair up with another receiver based on a specific MAC address. Data is then transferred using standard UART transmit and receive functions. Data is received from the base station by way of a software interrupts which alerts each time a byte is received by the PIC. This data is quickly stored in a queue and processed later. When the main loop cycles around, RF queue is unloaded and processed by functions which decode the queued data according to the message protocol outlined in this document. Data is sent from the aircraft to the base station during each cycle of timer 2. Control Algorithm The control algorithms can be broken down into two parts the creation of control signals and the conversion of control signals into fan speeds and servo angles. All the control algorithms are run as a background task in the main loop of the firmware. Control of the aircraft begins with decoding the inputs commands from the base station and finding the desired movement set by the user. This movement command is brought into the aircraft in 4 bytes, one byte for the each of the following: translation in the X direction, translation in the Y direction, translation in the Z direction, and rotation about the Y-axis. The command byte for each of these motions is an unsigned number ranging from 0 to 200. This number is biased on the aircraft resulting in a commanded motion of -100 to 100. The commanded motion is then multiplied and deg scaled to a command of 2 for translation or for rotations. The second part of the creation of sm s control signals is the sensor feedback from the accelerometer and gyroscope. The sensor values are deg scaled to 2 for translation and for rotations. Finally, feedback signals are subtracted from the sm s commanded signals resulting in an error signal for each of 3 translational accelerations and 1 rotational velocity. This error signal is then passed through a PID controller and sent to the second half of the control algorithm. LABET IV PAGE 7

8 Control Error Signal Due to the design of the aircraft, specifically the placement of the servos and fans, there is no direct application of the previously mentioned error signals. For this reason, these error signals must be converted to something useful. This is accomplished by using the sum of the squares of directional acceleration to calculate the fan thrusts and the arctangent of directional accelerations to calculate the servo angles. Conversion of Error Signals to Fan/Servo Controls LABET IV PAGE 8

9 Firmware Structure As previously explained, the firmware revolves around timers and the functions called during a specific timer s interrupt. The diagram below explains this functionality. Main() RF Data Received Interrupt Timer 1 (Sensor Polling) Initialize Processor Receive Data from UART Poll All Sensors (ADC, SPI) Initialize Components Add Data to Queue Apply Biases and Scale Factors Initialize Timers Save Sensor Data in Memory While(1) Timer 2 (RF Transmit) Parse Queued Data Read Sensor Values from Memory Set Desired Movement Variables from Queued Data Create Data String Compute Necessary Fan Speeds and Servo Angles based on Desired Movement and Sensor Data Send Data Through UART Set Fan and Servo PWM Values Timer 4 (Fan PWM) Timer 3 (Servo PWM) Timer 5 (Delay Timer) Get Servo Duty Cycle from Variable set in Main Generate PWM for 4 Servos Get Left Fan Duty Cycle from Variable set in Main Get Right Fan Duty Cycle from Variable set in Main Used as a delay in milliseconds Generate PWM for Fans LABET IV PAGE 9

10 A typical cycle for the firmware is the following: 1) A command message is sent from the base station containing the desired motion of the aircraft according to the user. The presence of this data interrupts the current process (except fan/servo control) and unloads the incoming data into a queue for later processing. 2) Simultaneously, timer 1 is running and prompting the sampling of each sensor (gyroscope, accelerometer, and sonar). 3) Also simultaneously, timers 3 and 4 are constantly sending control signals to each fan and servo every 20ms, with the length of each signal dependent on necessary angle of the servo or speed of the fan. 4) When the main loop comes around, the first task is to unload the data stored in the queue. This data is processed and decoded in order to extract the commanded directions from the base station. 5) The commanded directions are used in conjunction with sensors values and run through the control algorithm to determine a new set point for each fan and servo. This set point is a value 0 to 100 representing the minimum and maximum speed/range of the device. 6) The new set points for each fan and servo are implemented next time timers 3 and 4 are alerted. 7) Finally, during each iteration of timer 2, a status message is built and sent to the base station via RF transceiver. Testing PIC24FJ64GA004 Testing of the LABET project began by becoming familiar with the functionality of the PIC processor. This involved using a 16-bit PIC development board and learning PIC functionalities from example programs and online tutorials. Some of the peripherals learned included the UART, serial peripheral interface (SPI), ADC, timers, interrupts, and assignable peripheral. These peripheral were then tested on the component level using pieces of LABET s intended hardware. Component Testing Each hardware component used on the aircraft was first tested individually in order to prove its functionality and develop the appropriate supporting circuitry for creating an overall aircraft schematic. Again, for this step, a 16-bit PIC development board was used. The gyroscope and sonar sensors were tested with the PIC ADC, the accelerometer was tested with the PIC SPI, and the wireless transceiver was tested with the PIC UART. Each of these tests was programmed to run at a fixed frequency, thus testing the PIC timers. The timers were also used to produce a PWM signal in order to test each fan and servo. The component-level testing proved to be the most technically difficult yet most important step of the design process. Time spent working toward functional components was time saved when integrating the components. After each component was working on its own, the integration process was much easier, as individual components of software need only be combined. LABET IV PAGE 10

11 RC Aircraft Testing While the prototype board was being populated and tested, the aircraft structure was tested under RC control. Since the components installed (servos and EDFs) were RC ready, and after installing two ESC motor controllers for the EDFs, an RC receiver was used to operate each component individually. Each gimble ring servo set was mapped to each joystick on the RC transmitter. The ESCs were connected to the same signal on the receiver and mapped to a single potentiometer on the transmitter. The aircraft proved to be easily maneuverable without any feedback control. An interesting observation was if the aircraft went into roll oscillations, one yaw revolution would create a centrifugal force from the motors and cancel any roll oscillation. This may be one control feature which can be implemented in the future if roll issues arise. Overall, the test proved the aircraft will perform as expected. Component Integration After each sensor had been tested and proven functional individually, the sensors were integrated and the firmware was tested under full-load conditions. While the custom PCB was being processed, this testing took place on the Microchip Explorer 16 Development board and a prototype board created for testing. This prototype board contained all the appropriate connections designed on the custom PCB but was tied to an off-board processor. This setup is shown in the picture below. LABET IV PAGE 11

12 Prototype board with Explorer 16 development board Schematic/PCB Layout Pin Assignments The process of creating the schematic and board layout was closely tied to component testing. After each component s functionality was proven, the PIC microcontroller pins were assigned. Assignments were made taking into account possible functionalities of each PIC pin and the pin s physical location. This rational was used in order to make routing the PCB easier and the signal paths shorter. Below is a chart outlining the PIC pin assignments. LABET IV PAGE 12

13 Pin PIC Function I/O Component Description 1 2 RP22 I Accelerometer Accelerometer SPI Master In Slave Out 3 RP23 O Accelerometer Accelerometer SPI Master Out Slave In 4 RP24 O Accelerometer Accelerometer SPI CS 5 RP25 I/O Accelerometer Accelerometer SPI Clock 6 VSS - PIC Enables On-Chip Regulator (requires cap on pin 7, see 23.2) 7 VCAP - PIC External Filter Capacitor Connection (regulator enabled) 8 RP10 I RF Aerocomm UART Clear to Send 9 RP11 O RF Aerocomm UART Request to Send 10 RP12 O RF Aerocomm UART TX 11 RP13 I RF Aerocomm UART RX RA7 O Fan Fan R Control Signal 14 RB14 O Servo Servo R1 Control Signal 15 RB15 O Servo Servo R2 Control Signal 16 AVSS - PIC Ground Reference for Analog Modules 17 AVDD - PIC Positive Supply for Analog Modules 18 MCLR I PIC Master Clear (device Reset) Input 19 AN0 I Sonar Sonar Analog Input 20 RA1 O Sonar Sonar Control Signal 21 PGD1 I/O PIC In-Circuit Debugger and ICSP Programming Data 22 PGC1 I/O PIC In-Circuit Debugger and ICSP Programming Clock 23 AN4 I Gyroscope Gyroscope X-Axis Analog Signal 24 AN5 I Gyroscope Gyroscope Y-Axis Analog Signal 25 AN6 I Gyroscope Gyroscope Analog Temperature Signal 26 RC1 O Gyroscope Gyroscope AZ Control Signal 27 AN8 I PIC Battery A/D Sensor 28 VDD - PIC Positive Supply for Peripheral Digital Logics and I/O Pins 29 VSS - PIC Ground Reference for Logic and I/O Pins 30 OSCI I PIC Main Oscilator Input 31 OSCO O PIC Main Oscilator Output RC3 O Fan Fan L2 Control Signal 37 RC4 O Servo Servo L1 Control Signal 38 RC5 O Servo Servo L2 Control Signal 39 VSS - PIC Ground Reference for Logic and I/O Pins 40 VDD - PIC Positive Supply for Peripheral Digital Logics and I/O Pins Explorer 16, Prototype Pin Assignments While the pin assignments were set for the dedicated PIC, changes had to be made in order for the prototype board to be functional with a PIC Explorer 16 Development board. The Explorer 16 LABET IV PAGE 13

14 Development board was used to run the aircraft firmware during the component integration phase of testing. While this board allowed all firmware to be tested, it also contained many pieces of hardware which were unused. This not only added extra weight to the prototype setup but also added complexity to the PIC pin assignments. For this reason, some PIC pin assignments functional on the processor itself were not functional on the Explorer 16 board. The LABET team resolved this problem by re-assigning these functional to open pins on the Explorer 16 board. Schematic After the completion of the prototype board and confirmation that all components worked as desired, priority switched the creation of a printed circuit board. A PCB is desirable because it will simplify the aircraft circuitry, reduce weight, and increase the aesthetic appeal of the aircraft. The PCB schematic was created using Cadsoft s board layout program EAGLE. EAGLE was chosen over other board layout programs because of the pre-existing libraries that are built in or can be downloaded from the Cadsoft website. Primarily, the sensors were purchased through Sparkfun electronics and Sparkfun provides a library with many of these sensors already constructed in Eagle. Microchip also provides libraries for its PIC controllers. Problems were encountered when it was discovered that none of the components used on the aircraft were actually available in these libraries. As previously discussed there was an available PIC24FJ schematic but a new package had to be created with the proper pin assignments for the PIC24FJXX004 utilized in this design. Once the PIC was completed focus shifted to the remaining components. None of the sensors were available through the Sparkfun library as hoped so these were all created from scratch. Customized pin headers were used for the sensors, servos, motor control, and battery connections. These components all utilize the standard 2.54 mm spacing so standard pin headers with customized pin assignments were used. The only remaining difficulty was creating a custom pin header for the Aerocomm board as it utilizes closer than normal pin spacing. Once the schematic was completed it was checked through EAGLE to ensure all the nets were connected as desired. A board layout was then created from the schematic design. LABET IV PAGE 14

15 Layout As with most board layout software EAGLE was able to automatically create a layout from the schematic. This layout it created directly from the schematic with the components laid out exactly as they were in the schematic. The layout also utilizes free wiring in its initial incarnation. Free wiring draws the shortest straight-line distance from pin to pin. These lines often cross other components or wiring. The components were moved individually around the layout within the restrictions of 3.2 x3.9. This restriction is built into EAGLE but worked well has a space limitation of 4 is required by the aircraft chassis design. The components were moved inside the space to create a minimum amount of cross over in the wiring and components. It was important to minimize this effort as the PCB had a restriction of two wiring layers. This restriction was to simplify design and minimize the cost of printing the board. When all of the components were placed in an efficient manner EAGLE s autoroute tool was utilized to turn the free wiring into proper printed traces. EAGLE was able to autoroute the entire PCB once the individual components were properly arranged. The board layout has been completed and a PCB has been received from Advanced Circuits. LABET IV PAGE 15

16 Current State of LABET IV As of the publishing of this document, LABET IV can be flown with all electronics and controlled by an X-Box controller through the base station. The control system is functional but needs to be tuned to optimize performance. This tuning has been held off until the custom PCB is installed on the aircraft. The custom PCB has been received but not yet installed on the aircraft. This process was not delayed in order to ensure a working demonstration during the IRP review. The prototype will be scrapped in the upcoming days and sensors moved onto the custom PCB. The LABET project intended on making use of base station hardware developed by the SSCL. This project, however, was delayed and is not yet complete. The LABET team resolved this problem by using a PIC development to interface the base station computer and wireless transceiver. In the future when the intended base station hardware is completed, the only changes that will be necessary include adjusting the destination MAC addresses of each transceiver. The autonomous landing feature has yet to be implemented. This implementation will take place after the custom board is populated. The firmware is designed such that when an auto-land command is detected, each desired movement variable will be set to 0. The sonar will then be used to set a decrease in desired elevation proportional to the distance from the ground. LABET IV PAGE 16

17 Appendix A) Message Protocol Message To Header 1 Header 2 Header 3 DataLength Data (MsgType) Data Data Data Data Enter Land Mode Aircraft 0x19 0x28 0x37 1 0x11 Abort Land Mode Aircraft 0x19 0x28 0x37 1 0x22 Movement Cmd Aircraft 0x19 0x28 0x37 5 0x33 Translation X Translation Y Yaw Elevation Aircraft Status Base Station 0x19 0x28 0x x44 Gyro X MSB Gyro X LSB Gyro Y MSB Gyro Y LSB Abort All Aircraft 0x19 0x28 0x37 1 0x55 Memory Op Aircraft 0x19 0x28 0x37 4 0x66 Read? Loc Data Memory Poll Base Station 0x19 0x28 0x37 3 0x77 Loc Data Fan Reset Aircraft 0x19 0x28 0x37 1 0x Data Data Data Data Data Data Data Data Data Data Sonar MSB Sonar LSB Battery MSB Battery LSB Temp MSB Temp LSB Accel X MSB Accel X LSB Accel Y MSB Accel Y LSB Data Data Data Data Data Data Data Data XOR byte bytes 3-4 bytes 3-4 bytes 3-8 Accel Z MSB Accel Z LSB Fan L Fan R Servo L1 Servo L2 Servo R1 Servo R2 bytes 3-24 bytes 3-4 bytes 3-7 bytes 3-6 bytes 3-4 B) Fan and Servo Control Interrupt unsigned int ServoInterrupt( void ) { static SERVO_STATE currentservo = SERVO_L1; static unsigned int SL1, SL2, SR1, SR2; unsigned int countvalue; ); if( currentservo == SERVO_L1 ) { SL1 = TICKS_PER_SERVO_FAN_MSECOND + ( TICKS_PER_SERVO_FAN_MSECOND * ServoL1 / 100 countvalue = SL1; currentservo = SERVO_L2; SERVO_L1_HIGH(); // take current servo high } else if( currentservo == SERVO_L2 ) { SERVO_L1_LOW(); // take previous servo low ); SL2 = TICKS_PER_SERVO_FAN_MSECOND + ( TICKS_PER_SERVO_FAN_MSECOND * ServoL2 / 100 LABET IV PAGE 17

18 countvalue = SL2; currentservo = SERVO_R1; SERVO_L2_HIGH(); // take current servo high } else if( currentservo == SERVO_R1 ) { SERVO_L2_LOW(); // take previous servo low ); SR1 = TICKS_PER_SERVO_FAN_MSECOND + ( TICKS_PER_SERVO_FAN_MSECOND * ServoR1 / 100 countvalue = SR1; currentservo = SERVO_R2; SERVO_R1_HIGH(); // take current servo high } else if( currentservo == SERVO_R2 ) { SERVO_R1_LOW(); // take previous servo low ); SR2 = TICKS_PER_SERVO_FAN_MSECOND + ( TICKS_PER_SERVO_FAN_MSECOND * ServoR2 / 100 countvalue = SR2; currentservo = NO_SERVO; SERVO_R2_HIGH(); // take current servo high } else if( currentservo == NO_SERVO ) { SERVO_R2_LOW(); // take previous servo low SR1 - SR2; } else { } countvalue = (SERVO_PERIOD_MSECONDS * TICKS_PER_SERVO_FAN_MSECOND) - SL1 - SL2 - currentservo = SERVO_L1; countvalue = 1; currentservo = SERVO_L1; } return countvalue; LABET IV PAGE 18