Mercury VTOL suas Testing and Measurement Plan

Transcription

1 Mercury VTOL suas Testing and Measurement Plan Introduction Mercury is a small VTOL (Vertical Take-Off and Landing) aircraft that is building off of a quadrotor design. The end goal of the project is for Mercury to be an suas (small Unmanned Aircraft System) that well allow it to be completely autonomous. Cameras and sensors such as sonars and optical flow sensors will be added to market the aircraft for various tactical and emergency response uses. Our current design is being built from an existing quadrotor design. This allows the electrical and computer engineering team to work on the control systems, sensors, and circuitry while the mechanical engineering team designs a new chassis that will be more suitable for our applications. Once the chassis design is completed, the electrical engineering team will move the electronics to the new design and work on a PCB design to simplify the circuitry. The whole team will then work together to modify Mercury to make the system more user friendly and marketable towards an audience who does not have experience with radio-controlled aircraft. Design Specifications: - Stabile flight with weight of all electronics and camera - Power consumption must be less than 90W per pound - Achieve 12+ minutes of continuous flight time on a single battery pack - Stabile maneuverability in 10 mph crosswind - Electronics wiring integrated into PCB - Easy assembly and disassembly

2 Flight Controls Mercury s hardware mostly consists of commercially available electronics. The battery, speed controllers, motors, and receiver are found in many radiocontrolled aircraft. The FMU (Flight Management Unit) is an Arduino-based system that is intended for programming fully autonomous aircraft. The receiver sends the transmitters input to the FMU and everything is controlled by the FMU from that point forward. After the initial hardware setup, the basic functionality was tested after taking the propellers off of the motors. This grounded Mercury, which eliminates the chance of the aircraft uncontrollably taking flight and causing injury or damage. This was helpful for checking confirming that the motors were all rotating the correct direction and that the throttle control of the system was not reversed. We also checked that each motor would speed up or slow down according to each control input. Once everything appeared to be working, we installed the blades and performed test flights. Unfortunately, most of the flight controls cannot be easily measured in a quantifiable way. While there are accelerometers and a GPS built into the FMU, the most reliable way to test Mercury s flight controls is for an experienced pilot to fly the aircraft to see how it feels. One of our group members, who has experience flying radio-controlled helicopters and quadrotors, tests the maneuverability of the aircraft by manually flying from a standard 2.4GHz transmitter. Observing the speed of the response, the amount of oscillation, and the steady state position gives the information needed to adjust the PID controller for yaw, pitch, roll, and acceleration of Mercury. This approach has worked very well so far and we plan to continue using it. Power System

3 The power system in Mercury has a couple of options: 3s LiPo (Lithium Polymer) battery pack or 4s battery pack. The 4s LiPosystem is a higher voltage, so it is easy to assume it will consume more power, but the motors that would be used with the 4s system can generate more lift, which will allow the quadrotor to lift the extra weight of the battery while possibly drawing less current. If that is the case, Mercury can get the same flight time while lifting more weight, such as the weight of the optical flow sensor, sonars, and camera. The current 3s system gets about 15 minutes of flight time. Our goal is to achieve at least 12 minutes of flight time once all of the additional sensors and cameras are installed. It s possible we will be fine with our current power system, but we plan on running motor efficiency tests to compare the 3s and 4s systems. The shop at Rocket Ship Systems has a simple motor efficiency mechanism set up that we can connect each system to. The idea of the mechanism is to use the motor s thrust to push onto a small scale. This allows us to measure the amount of thrust the motor is putting out. Another important factor in the power efficiency testing is the charge in the battery. Using a LiPo charger that is capable of balancing each cell, we can fully charge a battery before the test and recharge the batter after the test. The LiPo charge will display how much power was added to the battery to bring it back to a maximum charge. That will be the amount the motor consumed during the test. One test should be run at maximum throttle with each system to determine how much thrust each motor is capable of. We can determine how much of a charge was used in the process to calculate our battery life in a worse case scenario (maximum throttle for the entire flight). It is also important to measure the thrust of the current 3s motors at a typical throttle level for hovering in place (typical flight). Once we know the thrust in that situation, we can set up the 4s system on the power efficiency rig and slowly increase the throttle until it puts out the same amount of thrust. The power consumption of the 3s system and the 4s system can then be compared to determine which system is more efficient at that weight.

4 If the 4s system turns out to be the more efficient system, we will modify Mercury to use the 4s system and measure some actual flight times to make sure the 4s system actually does increase efficiency. Once that is confirmed, we can start adding weight to Mercury to find out exactly how much it will lift and still perform as we want it to. This is extremely important for choosing sensors and cameras. If the 4s system will not allow Mercury to lift enough, we will have to find lighter sensors and/or design the new chassis to be much lighter. Software and Autonomous Systems Testing autonomous systems can be difficult and dangerous. Flying an aircraft manually allows the pilot to observe the response of each input as well as any movement that was not allowed by the pilot. Manual flight also gives the pilot complete control, which means unwanted behaviors can be corrected at any time. Having a real person directly connected to the aircraft drastically improves the safety of test flights. This is why testing an autonomous system is so difficult. How do you achieve the same level of safety while keeping the aircraft fully autonomous? The Arduino-based flight management unit is controlled by the Arduino Mission Planner software. Mission Planner uploads all software to Mercury and displays real-time telemetry. The code is written, compiled, and debugged in the standard Arduino compiler. Since software is the brain of an autonomous system, it is extremely important to ensure the accuracy of the output from the code. Our software will need to detect changes in Mercury s position and apply control inputs accordingly. The first step is to make sure the control theory behind the code is correct. By creating a block diagram simulation in Simulink, we can check the step response and impulse response of the system. The most important factor is making sure the system stabilizes to the correct value. The biggest part of that is making sure the system actually does stabilize. After that, we need to make sure the system

5 does not oscillate for a long time before stabilizing. The last step is making sure the system responds quickly. We prioritize those three elements of a step response in that order because they are ranked from most important for safety to least important for safety. If a system takes slightly longer to respond, it will not have a large effect on the safety. However, if a system does not stabilize, the aircraft will apply a control input and continue applying the control input, which is guaranteed to cause the system to lose control. Unnecessary oscillations can also cause serious issues. Fast and violent oscillations apply an unexpected force on the physical components and can cause a hardware failure. Once we confirm our control system works properly in Simulink, we can implement the controller into our code for things like automatic takeoff and landing, drift correction, and altitude hold. Testing the code without the motors is not very difficult. Using the telemetry system on Mercury, we can monitor the aircraft s realtime orientation on a computer. The plan is print each motor s throttle percentage on the screen and disconnect the motors from the speed controllers so the motors cannot power on. This will allow us to monitor the output signal to the motors while holding the aircraft and moving it around to see how the controller responds. If the values printed out on the screen look correct, the next step is to reconnect the motors and perform an actual test flight. For all or our autonomous systems, our pilot will be able to flip a switch on his transmitter to regain manual control at any time.