Considering repowering from pusher to twin. Efficiency loss?


Well-known member
It's great to hear your experience especially as you are flying a platform that is different in almost every way from mine. I believe some of my statements were likely based on my equipment, usage and environment, so let me explain them. This sort of discussion is really valuable for those interested in building a system, as well.

Airframe weight and wind. I have no issue with the image quality itself in wind - you are running the a6000 with manual controls, I'm running CHDK on my Canon. Manual control of the camera is important to keep a high shutter speed, low ISO and locked autofocus if possible. The issue with buffeting is with Arduplane and the way it captures metadata. My stitching software places a lot of importance on the camera attitude and position data. It's used for calibration, alignment and correction of things like shutter lag and wind drift, and it's captured by the Pixhawk when it fires the camera trigger. I have about 150ms of total shutter lag as calculated during alignment, and if the plane is pounded out of attitude or position by a gust, the photo and the metadata no longer align, resulting in calibration failure and discarded images. This is why I specified that with Arduplane and Micmac, at least, the plane must have weight and inertia to hold attitude against gusts. It doesn't help that SK is famously gusty. I personally tried the system in a lighter airframe and was disappointed by the results.

The ultimate solution for this to use a camera with a hot-shoe and use CAM_FEEDBACK_PIN to log the exact moment the shutter fires. This is also done by the Emlid Reach RTK system, something I plan to add to my system in the future as well. Once I get my airframe properly powered, I can afford to fly a better camera without the fear of losing it on takeoff. However, most peoples' first attempts will likely involve a servo-triggered point-and-shoot, and this will work better with a heavier airframe.

Software... I agree with you fully in principle. I also write embedded code and PLC systems for agriculture and industry, and clean code that is inherently understandable and testable is a goal for us all. I'm honestly a little jealous that you have time and funding to write your own autopilot! It sounds like a great project.

The real risk with Ardupilot is not the codebase - it is mature and has been tested heavily by many users. It's the vast number of parameters that the user is allowed access to, and in many cases has to adjust to get good flight. A good example that you will see posted all over the internet in crash threads is that it's easy to build an initial setup where the sticks give the correct commands, MANUAL will fly fine, but the stabilization outputs are cross-controlled. When you then flip into an auto mode in the air, it will attempt to pull down elevator to correct down pitch - and as the pitch drops, the amount of down elevator grows, as does the throttle setpoint. This can put you in a very bad situation in under a second. When you flip back into MANUAL you are headed for the ground vertically with high airspeed, and had better have a plan that doesn't involve ripping the wing off by hauling panic elevator. This particular failure mode is responsible for most of the lawn darts, and the equivalent mix-up for ailerons has ruined a lot of wings. Bench testing in all modes is the solution here, as well as flying plenty high before your first switch into an auto mode.

Once it is flying safely in FBWA at low rates, getting it to fly a good envelope for mapping requires adjusting a bunch of parameters that can result in power-on stalls while in a bank, i.e. spins that grow into spiral dives. Even when it's setup and flying reliably, wind shear can still put you into some nasty stalls. The autopilot responds like a beginner pilot and is incapable of escaping these. This is why I recommend the pilot is capable of flying the full envelope of their airframe before attempting to install an Arduplane system.


Well-known member
I don't have any knowledge of the ardupilot geotagging system, but if you account for trigger lag, then ardudpilot should be able to geotag with your actual/current orientation and location, even if you are bounced off your target a bit? But maybe the system works differently from how I would imagine it. In my system I log the aircraft location and attitude at the estimated time the shutter fires, so as long as I'm not too far out of sync with that I get really good initial estimate results.

We bought a seagull uav triggering system with hot shoe, but apparently I was not smart enough to get it work properly. I couldn't get my trigger rates faster than about one picture every 2-3 seconds. I'm sure it was something I didn't understand or had misconfigured on my side, but I eventually got frustrated with it and built my own trigger for about $40 using a pico switch and cut the end off a manual (wired) remote trigger to get the right connector/pinout to the camera. I still had to mess around, but finally figured out that if I held the trigger down for 0.3 seconds, then the release triggered the shutter when I expected, and i can shoot sustained at a 0.5 second interval (assuming I fly with my fast SD cards.) It took some work to get there, but now I'm really pleased with the sync of my geotagging and initial camera pose estimation. (And I'm not using the hot shoe any more.)

I've never flown the ardupilot system (and only watched others fly px4) but I agree it is full of 100's of settable parameters ... and it's not clear outside that particular development culture what many of them are for or do ... and often the ones we would imagine should be there don't exist. I have heard of people struggling to get their systems tuned because they don't have the knob they need to turn, and don't know what half the other knobs even do. This would probably be a similar issue in my system if I handed it off to someone completely new to it.

I think I understand what you mean if you get up/down (or left right) reversed in some modes. I've done that in the past. It helps to establish some conventions, but with every transmitter and every servo and every install potentially doing it backwards from every other one there is plenty of room for setup trouble here.

For flight envelope protection, again I don't know how ardupilot does this (but I seem to recall they have modes that don't require an airspeed sensor.) For my system I depend on airspeed and the system establishes dynamic pitch angle limits to maintain the airspeed limits I preset in the config file. (Of course I need to know in advance what those are, so if I screwed that up I could still have stall issues.) My system would fail if the pitot sensor failed, but so far it hasn't. I think a lot of people are currently wondering if the 737-max has a software bug or bad failure mode in this domain. For UAV's we can typically keep things much simpler. The cost / weight / complexity of a far more robust system often grossly outweighs the cost of a new UAV. For whatever it's worth, we have one person in our lab working on a synthetic alpha/beta estimation system which is closely tied to a synthetic airspeed estimation system. After air france 447, a lot more people became interested in ways to estimate airspeed without needing a physical pitot tube (which can clog or fail in a variety of ways.)



Well-known member
It's the attitude that really gets thrown off by the wind, as SK is cursed with all manner of downbursts, wind shear and rotor, especially in the hilly region where I live. For example, I was flying my FT Explorer FPV last evening in "moderate" winds. One second you are flying straight and level, blink and you are at 50 degrees of roll or seeing nothing but sky. The Explorer has one of FT's larger wingspans and a significant takeoff weight of 750g, but it's a feather in the wind here.

You have the advantage that your system can compensate for shutter lag internally, and record the position at that moment. Ardupilot cannot, unless it is attached to a hot shoe for feedback. This would actually be a simple and useful bugfix, to add yet another parameter to delay the position/attitude fix to match the shutter time.

Ardupilot supports pitot tubes, but so many people have issues with them that I decided to use the (quite good) synthetic airspeed system. Most issues are with covering the tube properly for calibration on a windy day, as the software will attempt to calibrate it to zero on every startup, but there are a surprising number of failures in the air as well. The synthetic airspeed system, combined with roll and pitch limits, a reasonable cruise speed and a minimum cruise throttle setting works 99% of the time once I got everything tuned up.

My only issue with the stall prevention code is that when I WANT to drop below my stall speed, during the landing flare, it is forcing the nose down constantly to try to get my airspeed up. It's pretty much 3-point landings or nothing, unless I land in manual - but a FBWA/MANUAL transition is always a little hairy as I don't know what the control surfaces are doing at the point of changeover.

I had never read the details on AF447. Crash logs are always interesting to read, and this is really a human failure more than a mechanical one - the pitot tube only remained blocked for one minute. All they needed to do was maintain level flight. It really does sound like what happens in RC, where you can regularly watch models hit the ground at full up elevator. It's a warning about the dangers of instrument paralysis and panic. Three experienced pilots on board, and yet they still pulled up elevator for 3 minutes at 35-40 degrees AOA, while presumably looking straight up into the sky and watching the altimeter spin. Scary.


Well-known member
I have done a few surveys in a hilly region of Minnesota (Winona area) and was surprised how even moderate wind could wreak havoc with all manner of up/down/crazy turbulence. At one point I was doing a circle hold at 25 kts airspeed and not making any substantial upwind progress! The forecast was for winds < 10 mph and I got there and the flags were standing straight out. Having scheduled several other people to meet me there and making arrangements with the private land owner, I went ahead and flew in the conditions. We did a 30 minute flight, got some pictures, landed, and decided it wasn't worth risking more flights.

In my system I have a post process script that runs through the flight log and matches up all the trigger events with images and applies the geotag. That's a little bit of a work in progress, but when the automated correlation fails I can usually figure out the manual offset pretty easily from a time history plot.

I guess I don't know enough about ardupilot pitch control and pitot tube error handling to make any comments about that. I can talk all day about what I do, but the cumulative time on our in-house system is far less than the cumulative time of all ardupilot systems ... so it's really hard to compare failure scenarios. Just because I haven't seen something in my couple hundred hours doesn't really say much compared to the probably 10's of thousands of hours ardupilot systems have racked up over the years. And like you rightly point out ... many problems are setup related or equipment maintenance related.

Well anyway, good luck with your motor/prop mods. My only advice is to go wrangle with ecalc for a while ... but you really have to run ecalc on a few systems that you are very familiar with so you can interpret the results in a meaningful way for your own style of flying. Ecalc seems to assume pretty aggressive aerobatic type flying, while we UAS'ers tend to throttle way back to a comfortable cruise and try to stretch our battery out as long as we can. Aerospace engineers (which I pretend to be) are supposed to go crunch numbers and make choices based on math, but sometimes with this stuff it's easier to take a wild guess and make modifications from there. In the case of selecting our power system we had a student actually spend several hours wrangling ecalc and in the end the choices worked out actually quite well.



Well-known member
Yup, in my area there is alway some risk involved unless it's a truly calm and beautiful day (twice a year). Calm evenings are great for hobby flying, but lousy for photography.

I'm planning to order the Aerodrive SK3 3542-1000. It looks like it will do the job and is pushing its rated current with the recommended 12x6 from Bormatec. eCalc says 489W at 84% efficiency.

Since props are so cheap, I might pick up a few larger ones as well. Now that I'm on skis and not the belly I can swing a 13" or larger. eCalc says these will be overcurrent by a couple amps static, but this motor has great reviews and a lot of reports that do not correspond with eCalc. Most are showing lower currents. There is someone who claims to swing 14x7 on 3s at 480W (perhaps he is bogging it down the same way my 12x6 was doing to my old motor, his thrust is pretty low too), and a lot of people who are badly abusing it, running it up into the 60A range with no damage.

Might at least try a 12x6 and 13x5 and measure currents. The 13x5 has a much better match for pitch speed even though it is technically a few amps overcurrent at static. Edit: HK is a joke for having things in stock. No props above 12"?

I tracked down a couple manuals for building the Maja. Interestingly they originally specced a 400W motor with an 11x6, then changed to 400-500W with a 12x6 or a 10x7 3-blade. People must have complained about the lack of thrust.
Last edited:


Master member
And don't forget to use at least a 60 A ESC with the Aerodrive SK3 3542-1000 particularly if you are going to try bigger props.
Motors can be significantly over loaded for short periods but not so with an ESC, it just "blows" and dies! The recommendation is to have a 20% ESC 'headroom' above the maximum motor current to allow for manufacturing variations and any marketing optimism!