This week I added a joystick to our groundstation and flew via telemetry. It was pretty intense, and I was surprised how little the delay and control surface sensitivity loss impacted the flight. As is, the set up wouldn't allow you to do and crazy 3D flying, but it operated just fine.
The only questions I'd have is about the delay and seemingly "stuttery" control surfaces. Is this delay normal? Is the control surface skipping effect normal?
Thank you for your support!
T-Rex 450 loiter
APM 2.0
MediaTek MT3329 and barometer
Now winter has passed in New Zealand, so I went to make loiter working on the T-Rex 450.
After playing a bit with the PIDs it worked pretty well as you can see in the video.
There was a sea breeze going but the heli did very well holding altitude (only barometer) and position.
Thank you very much DIY DRONES Team.
The next nice day I’ll get navigation a try, some waypoints and RTL. I’m sure it will work the same, if I get the setup right.
I’ll keep you posted.
A new strong video link on 5.8 Ghz frq.
This is a FPV RC Mini 5.8GHz 1200mW wireless AV transmitter and receiver combo set, 9 CH, high power transmitter,long distance transmission. Good device for FPV use.
New function Switching the video channel ON FLIGHT. Useful if you suddenly find a interference from another transmitter on the same channel.
TX with integrated Heat Sink & Fan Cooling.
Fully compatible with 2.4GHz R/C radios!
You can get 3 km range without any problem and more than 14 Km. range with optional Patch 18dbi 5.8Ghz
For even further range try out our 24 dBi 5.8 gHz Parabolic Grid antenna
It is designed and tested to offer the lowest possible RF and EM output so as not to interfere with any of your sensitive RC components. The transmitter operates from a 6V-16V input voltage and generates very little heat despite the broad input voltage range.When powered a red LED indicates the transmitter is working. An aluminum base plate is used to keep the transmitter running cool and with a total weight of just about 20g this is a perfect companion to the Fatshark Aviator and Dominator 5.8Ghz.
Transmitter 1200mW 5,8Ghz
• Dimension: 70*38*18.5mm
• Weight: 65 gr.
• Channel Swiching ON FLIGHT: YES
• Working Voltage: DC12V
• Working Current: 700mA
• Refrigeration: Heat Sing & Fan Cooling.
• Working Frequency: 5.8G
• Digital Display
• Working Channels: 9CH 1): 5720Mhz 2): 5740Mhz 3): 5760Mhz 4): 5780Mhz 5): 5800Mhz 6): 5820Mhz 7): 5840Mhz 8): 5860Mhz 9): 5880Mhz
• Working Power: 1200mW
• Transmitting Range: 2500m - 4000m (In Open Fields)
Receiver:
• Dimension: 72*43*11mm
• Working Voltage: DC12V
• Working Current: 200mA
• Working Frequency:5.8G
• Digital Display
• Working Channels: 9CH 1): 5720Mhz 2): 5740Mhz 3): 5760Mhz 4): 5780Mhz 5): 5800Mhz 6): 5820Mhz 7): 5840Mhz 8): 5860Mhz 9): 5880Mhz
INCLUDE:
•1x Transmitter 5.8Ghz 1200mW
•1x Receiver
•2x Antenna Onmi 3dBi
•2x Cable
•2x Connector
•2x AV cable
•1x Manual
***Compatible with goggles: Fatshark Aviator 5.8Ghz, Dominator in 5.8Ghz and Predator.***
***Compatible with receiver: Airwave, Uno and DUO from ImmersionRC***
See more about this 5.8 Ghz wireless video system
Clever! As the poster says, "This is a prototype, soon to be available at www.cxndesigns.com"
So , more than a few people have expressed concern over the amount of wing flex exhibited by the techpod . To exhibit just some of the strenght of the 9 mm OD 7 mm ID tubes I use I put together this quick clip .
that is 2 x 42 inch long 9mm tubes connected by a 6 inch x 7 mm inner connector rod , lifting a 5 gallon jug of water @ 42lbs suspended in the middle .good for a 8.4 g loading with a 5 lbs techpod and not all the lift comes from the tips unlike this demo . the spar could have taken much more. You may notice the two small nylon pieces in the middle . these keep the whole thing from exploding .
find out more about the techpod at hobbyuav.com
Thanks for taking the time to read another Blog post.
"Not another Blog post" you say, "Get off your *** and code something up I hear you say" :)
Yeh I know, I hope to have some time over xmas. I am using this BLOG to clarify what I want to do, attempt to make notes that I can refer to (when I finally get my finger out), and get feedback from people to better understand how to best achieve my goal.
Just a quick note on the diagram above. I describe it below but I have remove a number of components that we currently use in the code because they unnecessarily complicate the drawing and are not used in my setup. They could be included in the controller if the user desired.
My Goal is to improve the ACRO mode
The Arducopter has been developed with a significant focus on autonomous flight. The hardware and IMU code is working extremely well. However ACRO mode is much simpler than the quality of the majority of this code and hardware deserves.
The unrestricted ROLL_PITCH_ACRO code is found here:
http://code.google.com/p/ardupilot-mega/source/browse/ArduCopter/ArduCopter.pde#1652
However it is combined with a YAW_HOLD code by default, shown here:
http://code.google.com/p/ardupilot-mega/source/browse/ArduCopter/ArduCopter.pde#1576
instead of the YAW_ACRO code here:
http://code.google.com/p/ardupilot-mega/source/browse/ArduCopter/ArduCopter.pde#1566
I understand this has been because it significantly improves when flying a helicopter.
There is also some restricted ACRO code, that is accessed by setting AXIS_ENABLE to 1, here:
http://code.google.com/p/ardupilot-mega/source/browse/ArduCopter/ArduCopter.pde#1629
The difference between what I refer to as restricted and unrestricted is weather or not the code allows the airframe to rotate through 360 degrees in any direction.
True ACRO mode will allow the pilot to do flips in roll and yaw or any combination there of.
Restricted ACRO mode is basically controlling STABILIZE mode using a rate input rather than an absolute angle input.
Ideal ACRO mode
The idea ACRO mode is "Fly by wire". By that I mean that the airframe is stabilized as it is in STABILIZE mode but controlled by rate inputs like it is and ACRO mode. I have shown a number of PID control loops above that illustrate potential options to implement this.
The first is the rate only control loop that is currently used by default. This PID design suffers from the absence of absolute attitude feedback. This means that noise, sensor drift, and external forces can cause the attitude of the airframe to vary when no variation is commanded.
The second is the rate controlled stabilize loop that can be set by assigning AXIS_ENABLE to 1. This is a very nice option in that it allows small and precise attitude changes to be made by small stick inputs. This makes it possible to precisely control the airframe not only at hover but also in fast forward flight when pitched forward at 30 degrees. This mode could also be combined with the ALT_HOLD throttle mode to make learning to fly ACRO easier. However, this PID design doesn't result in crisp response because the rate is only increased in proportion to the difference between the desired attitude and measured attitude. This difference must build up to achieve full rate. The last option addresses this problem using a feed forward technique.
The third option is what I would like to eventually implement. This is a feed forward PID design. Here the desired rate is directly fed into the rate controller. However unlike the rate only PID design, the rate is also fed into the attitude input via an integrator (or rate times time step sum). The attitude feedback part of this PID controller only attempts to correct the error in attitude, it is not responsible for commanding the desired rate. In this way we are able to achieve full rate without the "wind up" effect of the attitude controller but still achieve a very stable attitude when zero rate is commanded. If the copter is hit by an external force, the attitude feedback part of the PID will reset the attitude to where it should be. This brings me to the attitude error limit. This is there to prevent poor PID coefficient choices from causing the airframe to continue to move far after the rate command has been set to zero.
Gimbal Lock and Ardupilot
This brings me to a very important point that is missing if we want to be able to use an unrestricted and stabilized implementation of ACRO. Currently the roll and pitch controllers assume that the commands to move the airframe in roll, pitch and yaw correspond to the measurements of attitude. While this is not far from the truth during hover it creates a larger and larger error as the pitch or roll angles increase.
This made flying the quad very strange for me initially. I am used to flying aircraft where I could "Bank and Yank" the aircraft through a turn (roll to say 45 degrees and use pitch to turn). Because of this effect we need to "Bank and Yaw" instead.
While rolled 45 degrees to the right, an input in Yaw to the right (measured by the attitude controller as an angle from north around the horizon) will cause an equal rotation rate in both Yaw to the right and Pitch down. This will cause the Pitch controller to add a pitch up once as this error grows but because this pitch up is at 45 degrees from the horizon it will cause both an increase in pitch up and an increase in yaw to the right.
Ideally what we would do is translate the coordinate system of the earth to that of the airframe before commanding a desired pitch, roll and yaw rate. In this case if the airframe is rolled 45 degrees to the right and a yaw command to the right is applied the yaw controller will command both a yaw and pitch rate command that keeps the nose of the airframe on the horizon.
Without this facility we can't implement a stabilized, unlimited ACRO mode.
Stability in ACRO mode
The common perception of perfect ACRO mode is that we command a rate in any axis and the airframe moves in that axis. While this is good, it is what is known as neutrally stable. When we fly an aircraft we like the aircraft to have a tendency to right its self without user input, this is known as positively stable. This can be implemented into the PID controller using a user defined attitude to rate feedback loop. Basically the roll and pitch angle is multiplied by a stability factor and subtracted from the desired roll and pitch rate. This results in the airframe moving back to level when the sticks are released in a similar way to STABILIZE but when full stick is applied the airframe will continue to rotate in what ever direction is commanded.
An ACRO beginner would set the stability factor high resulting in performance very close to STABILIZE while an experienced pilot might set it to zero or very small so that the attitude can be set not move if the sticks are let go.
OK it's over
Well this pretty much sums up my intentions. The reason I have chosen to focus on ACRO is because most of what I describe above can be done without effecting any other of the auto modes (limited stabilized ACRO mode with a stability factor). And this also happens to be what I want to fly with when I do my 55 km/h runs down a valley out the back of a friends farm house.(Video to come, but I want to get lower).
Any way, if you have read all the way to this point I congratulate your patience. Thank you in advance for any feedback, comments, and (especially) corrections, you can give on the ideas expressed above.
You may be happy to know that I think I am out of things I want to put on my BLOG now :) Now I just need to fix my USB port on my ARM2 so that I can program it without holding the USB cable.
EDIT:
Equations for translation between EARTH frame and BODY frame:
BODY_RATE_YAW = cos(PITCH_Angle) x cos(ROLL_ANGLE) x EARTH_RATE_YAW +
sin(ROLL_ANGLE) x EARTH_RATE_PITCH;
BODY_RATE_PITCH = cos(ROLL_ANGLE) x EARTH_RATE_PITCH +
sin(ROLL_ANGLE) x EARTH_RATE_YAW;
BODY_RATE_ROLL = EARTH_RATE_ROLL + sin(PITCH_ANGLE) x EARTH_RATE_YAW;
This is an update to my previous post about bulding my first quad copter. Finally the most important packages from China & Hong Kong has arrived, containing the motors and the new Hobbywing Quattro 20A ESC / 3A BEC.
I have also purchased the Turnigy 9x which was quickly updated to the ER9X firmware using a standard Arduino as the programmer. I followed the instructions from here in case someone needs to do the same. I plan on upgrading the radio to the FrSky ACCT module which spreads over 40 frequencies rather than the Turnigy's 16, so it should be more resilient to interference from other 2.4GHz radios.
After having set up everything, verifying the correct rotation (and propeller placement) on each motor, calibrating the ESC and leveling the quad it was time for a test flight. Indoors of course, and with about 2x2 meters of unobstructed space available :-) I'm happy to report that it hovers like a dream in stabilize mode
Was getting annoyed by the stupidly heavy frame of the Scorpion Y650 which is made of thick fibreglass sheets (available from Hobbyking). With the GoPro sitting on the camera gimbal and a 4S 3000mAh battery I was only getting 6-7 min flying time.
Had a look at the price of CF sheets and CF 450 size heli tail booms and it looked like an affordable project to design and build a hexacopter from scratch. Above is the basic design and below is the frame plates assembled with the CF booms and aluminium boom holders.
www.multiwiicopter.comin Queensland sell a clear dome with a 100mm diameter which will fit nicely over the electronics.
Just this portion of the frame is incredibly light. I'm quite hopeful that I will get much longer flight times than the Y6 with this design. Sheered one of the bolts in the process so will need to pull it all apart and try to get the remaining bolt out.
Up, down, bank, take a photo! Researchers at Zhejiang University in Hangzhou, China, have developed a quadcopter that can be controlled by thought alone. The idea is to give people with impaired motor abilities a new avenue for interaction.
Their system relies on the commercially available Emotiv electroencephalography (EEG) headset to interpret brain activity as commands for the quadcopter. Commands are relayed first by Bluetooth to a laptop, then by wireless to the hovering aircraft.
The quadcopter's range of motion is limited by the brain activity that the EEG can pick up. A user can move the flyer forward by thinking "right", fly up by thinking "push", and turn clockwise by thinking "left". Thinking "left hard" tells the quadcopter to take off from the ground. Clenched teeth and blinking both produce a brain signal that the EEG can read, commanding the flyer to descend or to take a picture using the on-board camera, respectively. By default, that camera sends a stream of video back to the laptop, and the user can capture a still of any scene they choose by blinking four times. The system is due to be presented next month at the Ubiquitous Computing Conference in Pittsburgh, Pennsylvania.
Seeing and taking pictures from new vantage points are two applications that the researchers think will be useful for disabled users. They also suggest that the thought-controlled quadcopters could "fight" against physically controlled quadcopters, dodging, diving and pushing to force each other out of a ring.
"Maybe one day in the future, disabled people can use brain [control] to drive a plane in which they are seated, and go anywhere they want to go," the researchers imagine in the conclusion to their presentation.
Hal Hodson, technology reporter
Records are made to be broken, and a bunch of students at the University of Maryland are smashing the ones they just set earlier this summer. They're so close to winning the crazy-hard American Helicopter Society's Igor I. Sikorsky Human-Powered Helicopter competition — watch an amazing eight-foot flight past the jump.
Henry Enerson, a freshman at UMD, is one of a handful of pilots taking turns furiously pedaling in the cockpit of the Gamera II, a human-powered quadcopter. The team has already met one major requirement of the Sikorsky Prize this week, hovering for 65 seconds. Now if they can hit one minute and get a little higher than 8 feet -- to exactly 3 meters, or 9.8 feet -- they'll win the $250,000 32-year-old prize.
The team has been testing all week but had to take a break for a few hours today so the students could go to class. We're following their progress and we'll update here if they set any further records -- meanwhile, watch Henry's flight below.
My wing is complete now I am back to working on the fuselage. Having left the fuselage for a while I have come up with some different Ideas for it. My Eflite 6s 22.2v 5000ah 30c lipo battery is about a pound more than I figured on. So I took the air frame back to the shop and lightened it up even more I cut out the material between every other hole along The sides into diamond shapes and spent 1/2 a day drilling more holes in it .It is as light as it is going to get. Unless I put a heilum bladder inside the fuslage and fill the Tundra tires with heilum as well ? I got a dual AR 7010 reciever when I got a 2.4 mhz module for my Futaba 9c I am going to separate the two recievers about 42 inches apart one at the front of the plane and one above the plane at the rear in a plastic dome I am going to mount hte Lypo batteryand the Castle Creations P
hoenix ice 100 ESC
one above and below a shelf at the front of the plane. Cooling air will come straight through the front and into the 80 mm Delta 32 EDF.I work from sketches heres is the latest sketch . You guys have a Great Day!
So we packed a bunch of prototype planes and went to Thailand to do a bit of flying. Much like our Road Trip series but a bit shorter, we'll be showing the ins and outs of modern airplane design - and the fun that can be had while being completely serious :)
Prototypes weigh around 450 - 600g, up to 40" wingspan. Please keep that in mind when watching some of the ... "stunts" :)
Some excerpts:
NASA's Global Hawks, for example, were first used to gather data during a limited number of flights in 2010, but researchers are hoping that updated technology and new base closer to Atlantic hurricanes will make the experiments better than ever, said Scott Braun, a NASA investigator who leads the Global Hawk experiments.
The three-year program is just starting, and for now NASA’s plan is focused on basic research, rather than real-time forecasting. Still, with a 116-foot wingspan and an ability to stay in the air for nearly 30 hours, the Global Hawk promises to be extremely useful for observing hurricanes.
“We are still a long ways away from replacing manned flights,” he said. Instead, the UAVs will supplement manned flights by flying at altitudes of up to 60,000 feet, thousands of feet above the thrashing winds and rain. One aircraft is designed to gather data about the environment around a storm, while the other UAV will study the storm itself.
While Global Hawks may soon be a regular fixture above hurricanes, NOAA is experimenting with small, unmanned watercraft to penetrate storms at sea level.
The Wave Glider is a solar- and wave-powered floating platform that can take measurements from both the air and sea. Wave Gliders have been used for a range of weather and climate research, but now NOAA is experimenting with placing the craft in the path of oncoming hurricanes.
Unlike other craft, in theory, the Wave Glider can stay out indefinitely thanks to its solar panels and energy gathered from waves, said NOAA’s Alan Leonardi. “The idea is to position a string of these in the path of a hurricane and gather data in a way we haven’t been able to before,” he said.
APM2.0 with ArduPilot 2.6 and MinimOSD v 0.1 (firmware 1.9 mav 1.0) installed on Maxi Swift.
All launched and landed in Stab mode, few seconds after lauch - mode switched to RTL, then to Auto.
During flight no 1 (has 3 "missions") - WP list loaded in-flight via telemetry.
Telemetry: Xbee Pro 900. On the ground - 13.5 Yagi, On MaxiSwift - whip.
Camera - GoPro Hero r2 recording mode, video link: 1.2 GHz, Tx 1.5W + vee antenna, RX + BiQuad antenna.
Flight no 1 - triangle 1x0.5 km, then lift 700m, then lift 1200m
Flight no 2 - lift 2500m
Flight no 3 - distance 5 km, route 11 km
Flight no 4 - distance 5 km, route 12 km
Flight no 5 - distance 10 km, route 23 km
Sample params and logs/kml files: logs%20and%20parms.zip
from this flight:
One of the differences between APM 2.0 and APM 2.5 is that on APM 2.5 there is no daughterboard covering the barometric pressure sensor. So what? Well, if you've got your APM 2.5 in an enclosure of some sort, it's no big deal (the official enclosures will be out in a few weeks and will be included with APM 2.5 orders then; people who have received an APM 2.5 already are entitled to a free enclosure with their next order). But if you don't have have your APM 2.5 in an enclosure, the lack of daughterboard protecting the baro sensor from the windstream can wreck havoc with your altitude measurement!
I learned this the hard way this morning, when I mounted my new APM 2.5 on the top of my quad, out in the breeze. When I switched on Altitude Hold mode, it decided to head straight for the skies. A quick switch to manual to land, then an upload of logs to the dev team revealed the problem (thanks to Jason Short and Pat Hickey). The vortex from my props was generating crazy readings with baro sensor. (This hadn't caused a problem on APM 2.0 because the daughterboard served as a wind shield.)
Solution: a bit of cotton padding, taped on top of the sensor, as shown above. Back to air and all was well-rock-solid Alt Hold. Whew.
So if you've got your APM 2.5 mounted out in the open, like I did, tape on a bit of cotton padding or a bit of paper tissue for now, until you get a proper enclosure. And remember: pressure sensors are, well, sensitive to pressure ;-) That includes wind of any sort. Shield your sensors!
hey everyone ,
Quick update on the techpod testing . the milestone of a one hour flight running full fpv gear with OSD has been reached . enjoy :-)
I fast forward around 1:30 and go back to normal speed around 55:00 so you can see it pass the 1 hour mark and land .sorry for the poor quality of the upload . the origanal looks way better . I am trying to raise the money to have the molds made and do the first production run . Please help support my kickstarter project !
and thank you to all my awesome supporters .
visit my web site to for more info
here is the plane in question.
On this episode of MyGeekShow we tested a new airspeed sensor we installed on the Shrike. It allowed us to get our first cruise airspeed, max airspeed, and stall speed. Very cool!
See you Saturday!
I have been following DIYDrones for years now, and have gleaned lots from other people's efforts along the way. I recently decided (after finding some cost effective frames on ebay) to get started for myself.
I started the heli hobby 2 years ago with a trex-450 in which i learnt pretty quickly, start small... much smaller than a 450 class heli! Constantly breaking various parts of the 450 was too expensive, so i gave up for a while. After some more reading online, and deciding I needed to push on, I purchased myself a Blade mSR to learn how to fly. It was nice, I got to use my DX8 transmitter during the learning process, its a bulletproof little fixed pitch heli which taught me how to compensate, and eventually I got very used to the flying process.
I purchased another spektrum receiver, and an initial cheap hexa kit (from GoodLuckBuy) which had frame/motors/esc's and a kk board. When it arrived it was missing parts (which they did quickly send me), but coming from china it took a while to get it all. I had also ordered an APM2 board at this point, but due to the popularity it took a while for it to get out to me, during that time APM2.5 came out, so I opted for the upgrade.
With the flimsiness of the initial hexa frame, I decided to get something a little more substantial. I went with the ATG 700-AL frame (which was cheapest at GLB, maybe I should have known better)... It arrived, missing 1 piece... Not a big deal, it was just the top plate of one of the motor mount assemblies. (I have ordered the missing part, and some extras from omgfly.com).
Over the course of the last 2 weeks I have assembled the new hexa with the APM2.5 board, GPS, Sonar and OSD. Power distribution is done via the Hexacopter power distribution board (available via the store here), with the deans connectors on whips, instead of directly to the board. This let me deal with the size of the frame, and short ESC power leads. I have a 2 Y setup from battery to the distribution. Y setup for 2 batteries feeds a Y setup breaking off power to the attopilot voltage+current sensor, which then feeds the distribution board and a separate UBEC to power the video gear (camera+transmitter).
I have had a few test flights and with defaults it is VERY stable... Loiter works perfectly with no wind, when its a little windy it seems to drift and have weird altitude drops.
I have some photos of the assembled hexa on my gallery here: http://g.chote.me/Multirotor/Hexacopter
I will continue to update with my progress, and get some videos together also.
Thanks for taking the time to read this post. First of all I would like to reassure you that this is in no way a criticism of the code or the Dev team, they have done a fantastic job.
I am working towards making my own contribution to the Arducopter code base to improve the "Fly by Wire" aspects, but it will take time for me to get the environment set up. (two kids under 2 and 2 jobs) So in the mean time I would like to discuss my ideas. If they are supported and still not implemented when I get my finger out then I will start attempting to implement and test them.
I would appreciate any feedback you can give me.
So this is my first idea to address two problems I and others have experienced in using the Arducopter.
The dreaded drop in altitude when transitioning from Alt Hold or any other Auto mode to Stabilize. Ok, it isn't a big deal once you get used to it but it isn't pretty and I think we could do better.
So I see a number of problems to be addressed:
1. Drop or increase in height when changing modes.
2. Throttle hover position in Stabilize is not in a fixed location so it needs to be "found"
3. Alt Hold is implemented such that it changes height rather aggressively.
I was able to address point 2 and even point 1 to a lesser degree setting up my throttle curve in my transmitter to set hover at mid stick.
Point 3 makes using Alt Hold to control altitude while learning or filming quite clumsy or impractical.
Ok so here is the idea. It has three parts to bare with me.
Manual Throttle curve making hover at mid stick
Now I could see in the code where the throttle offset was changed to place throttle_cruise at mid stick but it did this by simply offsetting and limiting the curve. What I suggest above is to add two slopes for > throttle_cruise and < throttle_cruise. This means that no matter what throttle_cruise is set to the pilot will have access to full throttle range in Stabilize. throttle_cruise takes approximately 5 seconds to move 90% to hover. This means that the throttle position during hover for a bad throttle_cruise setting would move quiet slowly even in the worst case.
Alt Hold has progressive rate vs stick input and smaller dead band
The diagrams on the right show the throttle input vs requested climb rate when using Alt Hold. I am suggesting that we should make this progressive with only a small dead band in the middle. This makes it possible to make smooth and slow altitude changes without having to use the Manual Throttle. (great for learning and filming)
Transitioning from Auto mode via Alt Hold mode
When switching from Auto to Stabilize we could pause in Alt Hold mode. How I was thinking we could do this is to spend a maximum of 2 seconds in Alt Hold mode or until we move the throttle to the dead zone in Alt Hold. What ever happens first. The effect of this is to limit the sudden drop or increase in hight to -120cm/s to 180cm/s and give the pilot time to react by moving the throttle to the central position. Once in the dead band the throttle setting should be within 10% of that required for Hover.
Advantages:
Mid stick is always what you need to hover.
Change from Alt Hold to Stabilize should not result in scary moments because the throttle stick position should be within 10% of Hover.
Change from Auto modes, when the throttle has been set to max or min, will give the pilot 2 seconds warning before going to full or no throttle.
Alt Hold is much more "Fly by Wire".
Disadvantages:
Alt Hold would drift if the throttle is just outside the much small dead band.
There may be times when the 2 second delay moving to Stabilize could prevent the pilot adding full throttle in time to prevent a crash.
I would really appreciate any feedback and insight people have into this idea or these problems in general.
Thanks
Edit:
Code for this approach:
As always the code is marching on and there are already changes made in the areas I have been discussing. So I thought I would list the main requirements in the code to make this work the way I describe.
The main requirement is that g.throttle_cruise is only updated when the copter is in a stable stationary hover. The simple testes for this could be
(g.rc_3.control_in > g.throttle_min && abs(climb_rate) < 60&& abs(g.rc_1.control_in) < 1000 && abs(g.rc_2.control_in) < 1000 )
This can happen in all flight modes. Altitude is kept in different flight conditions other than hover using the Rate I term. The Rate I term limit needs to be large enough to compensate for all flight conditions.
The code for the throttle position to manual throttle output is very straight forward.
if(g.rc_3.control_in < (500 - th_deadband/2)){
g.rc_3.servo_out = g.throttle_cruise * (g.rc_3.control_in / (500 - th_deadband/2));
break;
}else if(g.rc_3.control_in > (500 + th_deadband/2){
g.rc_3.servo_out = g.throttle_cruise + (1000-g.throttle_cruise) * ((g.rc_3.control_in-500-th_deadband/2) / (500-th_deadband/2));
break;
}else{
g.rc_3.servo_out = g.throttle_cruise;
}
The code for the throttle position to altitude rate output is something like this:
if(g.rc_3.control_in < (500 - th_deadband/2)){
th_Rate = -120 * (g.rc_3.control_in / (500 - th_deadband/2));
break;
}else if(g.rc_3.control_in > (500 + th_deadband/2){
th_Rate = 180 * ((g.rc_3.control_in-500-th_deadband/2) / (500-th_deadband/2));
break;
}else{
th_Rate = 0;
}
Sorry but I am not familiar enough with C to add the types quickly.
In the latest version of the code the throttle_cruise factor is updated in two places. Here where it was before and what I think works well with this approach.
http://code.google.com/p/ardupilot-mega/source/browse/ArduCopter/ArduCopter.pde#1813
throttle_avg = throttle_avg * .99 + (float)g.rc_3.control_in * .01;
g.throttle_cruise = throttle_avg;
The new addition here is a problem for this approach. The code is Here:
http://code.google.com/p/ardupilot-mega/source/browse/ArduCopter/ArduCopter.pde#1891
and here:
http://code.google.com/p/ardupilot-mega/source/browse/ArduCopter/system.pde#635
The second update prevents this approach from working because it is constantly resetting the Altitude I term and adding it to g.throttle_cruise.
UPDATE : I have discarded the Zephyr V70 option due to input from you guys . I am now torn between these :
----------------------------------------------------------------------------------------------------------------------------
Hi Guys,
I had been checking out the Zephyr v70 V-Tail Glider as an APM platform, but am not sure if all the GPS and telemetry, most importantly the APM 1 board with Oilpan will fit in it.
I am planning on running it on a 3S 2200mAh LiPo, so I get some extra space there, but the APM seems awfully large and if it fits, it will be a tight fit with the R/C Rx.
If someone has the Zephyr, it being such a popular glider, I would like to know their opinion.
Another question - does the current ArduPlane code support V-Tail mixing? Its probably there, but needs to be enabled in the code manually???
Product Page: http://www.hobbyking.com/hobbyking/store/uh_viewitem.asp?idproduct=22703
Kabir
