projects:tgifuav2012 [HSBNE Wiki]

Link to this comparison view

--- projects:tgifuav2012 [2016/03/14 18:49]
+++ projects:tgifuav2012 [2020/04/11 12:01]
127.0.0.1 external edit
@@ Line 1: / Line 1: @@
+If you want to know more about our entry in the UAV outback challenge competition, please contact:
+**Team name:** TGIF ( Thank Goodness It Flies, Toes Go In First, This Gust Isnt Funny, There Goes Instrument Failure, This Game Is Fun, The Goal Is Flight, etc )
+**Team Leader:** David ( aka Buzz )
+**Team Members:** Travis (aka TJ) , Seppo ( aka Seppo )
+**email:** davidbuzz at gmail dot com
+**Final Summary:** "UAV Project", we had three financial member/s ( and many keen helpers) in the team, and we worked on our entry for a long 18months, and completed all "Deliverables" ( preparation stages) leading up to the competition ( including over 10 hours of logged autonomous flight, and hundreds more not logged ) , and we attended the "UAV Outback Challenge" in Aug 2012 as one of only 6 teams ( out of approx 60 who originally submitted Deliverable 1) to get that far. We worked in "friendly competition" with the Canberra UAV team, and even shared some ideas and what not, and we are glad to see them out do us! ( We both used modified ArduPlane software as our onboard autopilot solution/s).
+Ultimately, we were unable to compete due to last minute ( day before actually) airframe damage , but we still consider "6th place" a good first attempt!
+We have now "closed up shop", broken down the UAV, split the resources up, and "called it a day"....... at least until the next competition is announced...... then we'll see......
+Buzz.
+===== Some videos: =====
+Early 2012 video showing out "fleet" of UAVs of different scales, learning to use them, tuning, and testing:
+https://www.youtube.com/embed/AoV1w9INHzI?rel=0&amp;controls=0
+Deliverable 3: ( interesting 4 minute video) Team TGIF Deliverable 3 Video
+https://youtu.be/at0UzT2Db78
+Deliverable 2 Video: ( long @ 24 minutes, kinda dull video, but lots more details, including takeoffs, landings, parachute, safety checks, bottle drops , team members blah, blah etc ) . Team TGIF Deliverable 2 Video
+https://youtu.be/mCFqSywOmUo
+Early Concept/s and ideas only, no longer entirely relevant:
+===== Airframe =====
+{{http://hsbne.org/assets/img/projects/tgifuav/Rutan.long-EZ.g-wily.arp.jpg|img}} {{http://hsbne.org/assets/img/projects/tgifuav/MQ-9_Reaper_in_flight_2.jpg|img}} {{http://hsbne.org/assets/img/projects/tgifuav/uav.png|img}}
+I think a tail-mounted push-prop would be a good option to explore. This moves our CoG back to give us plenty of unobstructed, continuous space in the nose for instrumentation. The battery might also have to live in the nose if we have trouble balancing.
+**The upsides for a push-prop that I've found are:**
+Less expensive, unprotectable spinny bits hitting the ground upon a crash,
+Don't have to worry about losing thrust to your rotor wash hitting the nose of your plane,
+A 'chute can pop out of the nose and arrest forward motion and support descent without risk of snarling up prop.
+**The downsides are:**
+Less low-speed lift and maneuverability due to lack of rotor wash over wings,
+You've gotta be careful to give the prop enough air, if it's spinning in a bubble of low-pressure air you're not going to get as much thrust. See tapered end on predator drone above.
+A 2m length of corflute rolled into an airfoil with a length of balsa or carbon fibre tube running the length would do quite well as a wing. 9 gramme servos can be hidden inside the wing such that only their horn protrudes with a short link to the ailerons.
+A triangular cross-sectional main body, oriented to present a flat face on the top upon which the wing can be mounted.
+Until we get some real cargo, probably need a fair bit of dead weight in the nose to balance out the motor on the back. I'm not sure about the whole rudder-and-elevators-on-the-nose approach, seems a bit weird. The wing would have to be roughly near the centre though
+{{http://hsbne.org/assets/img/projects/tgifuav/A10Thunderbolt2_990422-F-7910D-517.jpg|img}}
+Seppo and I have been discussing this in depth and have considered the above airframe for a number of reasons.
+  - The plane is an inherently stable design that is designed to fly slowly and loiter over an area for long periods
+  - The engine mounting position is easier to achieve than a tail mounted pusher prop and the prop is protected in case of crash landing.
+  - High mounted engines also means less clearance is needed during take off and landing, hence shorter and lighter landing gear.
+  - Having the engines nearer the middle of the plane makes it easier to balance as other than the fuel tank this will be the heaviest part of the plane.
+  - Twin engines means redundancy in case of engine failure, it also allows us to use a smaller and probably cheaper engine
+  - Straight wings and control surfaces are easy to form and control. We will only need a single tail fin not twin as on the plane.
+  - The fuselage is large and roomy and should provide us plenty of room for sensors, avionics and subsidiary systems.
+We aren't talking about doing a scale model of this, but keeping the main theme of the fuselage. I.e. Long straight fuselage with little to no taper, low-mid mounted straight wing with little to no sweep and large control surfaces. High mounted mid-rear engines in-between wings and tail plane. We can probably create a fuselage of this type out of foam & carbon fibre rods, tubes and sheet very easily and quickly (my estimate is about $600 per fuselage). Custom designing a fuselage means we can design our airplane around our sensor package instead of the other way around. This will make integration between the two a lot simpler. I am already working on a basic design for this and will try to have some rough sketches ready for Tuesday night.
+This is my version of this fuselage. Work in progress of course. The two small fins fuselage are mounting points for pusher props. Having a high mount like this means less of an issue with ground clearance. The idea is to make the fuselage out of a suitable tube material, Carbon fibre springs to mind and then use the internal shelf for mounting all the electronics and sensors as well as stiffening the fuselage. This is similar to how a 747 or similar aircraft works.
+{{http://hsbne.org/assets/img/projects/tgifuav/uav.jpg|img}}
+===== Communications =====
+Other teams use 3G modems? I think? If reception is reliable that's a heap of low-latency bandwidth available. A digital TX/RX is a must for manual take-off, landing, disaster control (outside of competition), plus they weigh bugger all.
+Having looked into this and considering the rule changes for this year regarding the loss of signal. It would likely be a much cheaper and simpler idea to use a 900MHz data modem for all telemetry and long rang commands. The modems themselves are fairly cheap, very easy to implement and very lightweight. 3G modems that can be used with a micro-controller tend to be quite expensive (cheapest I have found is $400) and then we would have to pay for a sim card and data service on top of that. 900MHz is one of the "LIPD" licenses specified by the ACMA and we can use up too 1W EIRP in this band with no licensing requi red. For the video link that is requested by the judges I would suggest we use a common 2.4GHz wireless video system. These are easy to get, cheap, fairly reliable, lightweight and low power. I have seen ones that are 1W output (before antenna gain) and weigh 21g. We are allowed to use up too 4W EIRP in this band. We also need to sort out a kill signal system that is entirely separate to these two systems, perhaps another 900MHz system on a second channel, or a lower frequency (433MHz, 40MHz, 27MHz) that will have better range characteristics.
+===== Sensors =====
+Some of these may cancel each other out, but we'll see:
+**3 x Gyro** 3 rotational axes.
+**3 x Accelerometer** 3 linear axes.
+**2 x Horizon sensor** Need something to zero your X and Y axes.
+**1 x Altitude sensor** Barometer or laser rangefinder.
+**1 x GPS** Duh.
+**1 x Joe-finder** Either an IR camera or some other IR sensor.
+**1 x Camera** Required by rules?
+{{http://hsbne.org/assets/img/projects/tgifuav/SystemsV2.jpeg|img}}
+This is a systems diagram done up by Sepp and I as a basis for what we will need. As you can see there are a number of sensor systems that we think are required to make this successful. They are as follows:
+  - GPS for Autopilot (used to compare current position with desired position and crosschecking against FMC GPS)
+  - Barometric Altimeter to give us a much more precise altitude fix than GPS can
+  - Radio/Ultrasonic Altimeter to give a much faster update rate than Barometric can for autonomous landing
+  - GPS for FMC (used to generate flight plan from sensor package data and crosschecking against Autopilot GPS)
+  - Inertial Navigation system (Accelerometers and/or Gyroscopes) to allow auto leveling of the plane and also to counter wind effects
+  - IR Camera for detecting "Joe"\\
+The reasoning behind two GPS units is that it will allow us to compare the data from the two and throw one set of data out if it's wildly out of spec for some reason. Horizon sensors are not needed if we are doing a taxi take off, as we can "zero" the accelerometers and gyros to a level position on the ground and then use that as the reference for level flight. The second altimeter can be done away with, but only if we elect to manually land the aircraft. Sepp suggested the possibility of using our own "ILS" to allow the plane to land autonomously without the need for the on board sensors. Whether we can do this would be up to the judges. The IR camera we are looking at is a 4096x1 pixel line camera, it is very responsive at the required wavelength (850nm according to the spec of the camera mentioned in the rules). By putting a lense with a known angle of deflection in front of this we can calculate the angle to the target and hence, the targets position relative to the UAV. The idea we had considered was to mount this laterally on the belly of aircraft so that it is aimed vertically down and hence will be scanning quite a wide swathe underneath the aircraft. This also makes the math to generate target position easier (mmm... pythagora).
+The camera is not a requirement, it is a request. I somehow think though that if they have too many entries, ones without camera's will not be looked favorably upon. A camera is not much extra weight too add (100g) and not a great power drain either. This also gives us another form of feedback as to what the aircraft is doing.
+===== Stabilisation =====
+Keeping the plane flying level. Constant wind is not the concern of this system, but sudden gusts are.
+Your rotation about X axis (roll) and rotation about Y (pitch) can by detected and controlled with gyros and ailerons and elevators respectively. These give a rotational velocity measurement, so you can dead-reckon your current orientation, but this drifts quickly. You need some form of absolute reference to zero them regularly (a few times in 10 seconds, ballpark). The horizon is a pretty good thing to zero roll on once you've cleared the treeline.
+I'm trying to remember at this point why accelerometers are required... (Lemming edit: to counter sudden changes in lift) A fixed-wing plane only has actuators that can control its rotation. Navigation Route-planning, course correction and accounting for steady wind are this system's responsibility.
+Breaking this down into two parts is a better idea. Basically along the lines of real time and non real time functions. The Autopilot will handle course correction, maintaining level flight and accounting for any wind conditions whether they be strong, light, gusty or steady. The flight management computer will integrate the current position with the desired position and plan how to get there and then provide a desired way-point to the autopilot, also integrating data from the IR Sensor package to decide where it should fly next to maximize our chances of finding "Joe".
+===== Target-finding =====
+Camera or other means of spotting Joe on the ground. Joe's position must be calculated to 100m accuracy before dropping can occur.
+IR Line camera with wide angle lense in front of it. Think about 60° or so should do. With a 60° lense we can cover a 460 foot wide track from 400 feet up. Basically however high we fly is how wide an area of ground we are covering. With the camera having an update rate of 20KHz, we should have no trouble with being able to scan the longitudinal direction. At 100km/h ground speed this will be one frame every 2mm. We can slow this down to 300Hz and still be achieving better than 1 frame every 10cm. As we do not need to log and/or transmit this data handling it is just a case of being able to scan each frame fast enough looking for bright spots and then calculating their position, and the likely hood (DoP) of them being "Joe".
+Camera From the rules:
+*//5.13 Access to Video Stream from UAV *// The UAV Challenge Organisers request that teams that have a live video stream at the ground station from their UAV provide access to this stream so that it can be recorded or broadcast to the crowed at the airport.
+This would be easy to achieve and I think it would be good to overlay some form of OSD on it. There are a number of off the shelf solutions for this, some which also include an autopilot function.
+===== Smart payload? =====
+Some form of nose that fits on the payload and steers it to the target by using rudimentary IR sensing and controlling some fins or a 'chute.
+Quoting rules section 2.1.2: Once Joe has been located, the air vehicle must safely deliver a life saving drink to him (minimum of 500ml). There are no restrictions on the deployment device, however a competition scrutineer on the range must be able to open the container by hand and measure the quantity of drink delivered. The drink must be an unopened container suitable for human consumption – examples include a bottle of water or soft drink. The emergency package (containing the drink) must be dropped as closely as possible to Outback Joe, without touching him.
+More points are awarded the closer you are to the target.
+Smart payload is an interesting idea, but somehow we would have to ensure the payload could see Joe before release, as if it's just looking for the brightest IR source it might head for something else (a hot rock for instance) and steer wildly away from Joe. Using dead reckoning from known values (performance of payload, wind speed, speed of aircraft, aircrafts position, Joes position) is probably a better solution. It may require a bit of testing to get all those things nailed down but once we do I think it will be just as accurate and there is less to go wrong.
+As for the payload itself, the idea I have seen and quite like, is simply a PET water bottle attached by a short length of string to a plastic shopping bag. Both are fairly light weight objects, it will be an easy to open container and the bag provides just enough drag to slow the bottle down that it doesn't disintegrate on landing.
+===== Kill-switch =====
+Parachute allowed within the rules? Slow circular glide to the ground with a last-minute stall hook at the end to kill downward velocity.
+It must be a separate device that receives a heartbeat from the controller.
+The flight termination servo positions for fixed-wing UAVs are:
+  * Throttle closed;
+  * Full up elevator;
+  * Full right rudder;
+  * Full down on the right aileron;
+  * Full up on the left aileron; and
+  * Full flaps down (if applicable).
+There is some flex in the rules for less suicidal kill-switches, but you'd have to justify it very strongly indeed.
+Parachute is a must in my mind. Also having a rearward launched parachute means the plane will slow down VERY quickly and start to drop out of the sky. I really don't want to have us put all the time/effort/money into something like this, only to have to crash it into the ground due to a computer bug or communications issue. At least if we have a parachute we can come back the next year with the same plane, having to start again from scratch would be painful.
+Current Rules 2010 V1.2
+UAV Outback challenge rules
+Copy/Pasta from the new rules
+Major Revision Record Changes from 2009 • There are numerous changes in the rules from last year and all teams are advised to read this document very carefully. • Major changes include, but are not limited to:
+New front page: IMPORTANT NOTICE TO COMPETITORS.
+  * Section 2.1: Changes to waypoints and mission boundary.
+  * Section 2.1.2: New section on Air Traffic Management.
+  * Section 2.2: Competitors now have additional time to set up and pack up.
+  * Section 4: Change of dates in schedule.
+  * Section 4.1: New section outlining option for early delivery of documents.
+  * Section 5.2: Now require UAV controller to be MAAA gold-wing standard or equivalent (previous rule was bronze-wing standard).
+  * Section 5.5: New section on Data Link loss flight behaviour.
+  * Section 5.6: Modification to flight termination behaviour due tointroduction of data link loss behaviour.
+  * Section 5.14: New section on sharing of equipment between teams.
+  * Section 5.16: New section on situational awareness requirement.
+  * Section 5.17: New section on Li-Po battery management.
+  * Section 6.2: Added new requirements for the flight video.
+  * Section 6.4: Change to scoring - Mission performance (flying)
+===== Interesting rule bits =====
+.11 Definition of “Completed Mission” A Search and Rescue Challenge mission is considered complete if:
+  - The UAV does not cross the mission boundary.
+  - The emergency package comes to rest within 100m of Outback Joe.
+  - The emergency package does not touch Outback Joe.
+  - At least 500mL of water is recovered by the scrutineers on the course.
+  - The UAV returns to the airport and lands.
+ACMA Class license for comms stuff