Ok, I'm just going to cut to the chase here...  I bought into this gear because of what I thought it would/could do and as everyone should know by now I lost my quad on day-2.

My intentions for building this thing in the first place was that I wanted to do FPV flying while simultaneously recording HD video.  Clearly I needed to build my gear, learn to fly, and get comfortable with FPV first, but the desired end-state is the same.

The gear I ended up with was:

  • 3DR Quadcopter kit from DIY w/APM 1  (APM2 was still buggy)
  • 2x Turnigy Nanotech 2650mAh 35-70C batteries
  • Turnigy TGY9x tx/rx (borrowed from the late Kevin Finisterre)
  • GoPro HeroHD Camera

My plan was to later include hardware to extend my range (amps, tracking, ground-station, etc), telemetry, and probably a laptop/ground-station setup running Mission Planner.

After losing my gear to what we thought was a problem with my shoddy solder job I posted here, and after a bit of noob bashing it was my cheap radio equipment that was to blame, or so we thought.  Based on the comments we later determined that it was a "bug by design" in the APM that more than likely led to my quad pulling a Houdini.

Since then I have purchased a small cheap laptop to run the MP, another 3DR kit, and more batteries.  However, there has been a LOT more discussion, bashing, blaming, banning, and general covering up of the fact that the APM may actually be responsible for serious safety issues, fly-aways, etc.

The bitch of it all is that I'm sitting here wondering WHAT if ANY hardware could be used to make this thing (relatively) safe to fly, let alone accomplish my initial desired end-state.  Some suggested spending some loot on a nice Spektrum rx/tx, but we've clearly determined that even it's failsafes do not work in certain scenarios, which was the whole point of bringing this APM bug to light.  Having demonstrated a properly working failsafe on an expensive radio apparently being blocked by the APM PPM encoder behavior, could someone please explain this to me because I'm confused - this demo is in direct contrast to all the bashing I have received lately.


So despite all of this, low and behold patches are being developed and released to address this issue, but where does that leave me?

Based on my observations on this board for the last few weeks I don't see any way around this issue. It would appear that no matter what gear is used a fly-away could still be experienced.  The patches mentioned above wont do anyone any good if they don't have the knowledge or the hardware to flash the PPM encoder.  I've already lost 600$ in gear and I have purchased another 600$ in gear to help mitigate a problem that I apparently cannot solve.  If a fly-away is still possible I don't even want to attempt flying this gear.

So another observation that I have made is that a lot of people seem to be doing exactly what I would like to do.  How is it that their gear isn't flying away?  Are they just taking the risk or are they truly safe?  Do they even know about the issue?  Are they even using diydrones gear?

So time for the BIG question for all the "experts" in this community...  What gear would you recommend to ensure that this type of thing doesn't happen again?  

I would like to see more than just a preferred list of gear; I want to know WHY you think it's better than any other.  Price/budget is a factor so don't just toss out all the expensive shit because it's "better."

My plan of action included the FrSky modules for the Turnigy9x that I already have, a 2.4ghz amplifier, a directional/tracking antenna and ground station, a laptop with a ground station module for the use of MP if all else fails, long distance telemetry gear, et al.

I would also like to make the APM loiter (gps/altitude hold) if radio signal is lost with the option to auto-land exactly where it's at if control cannot be regained.  Hopefully this wont be an issue with MP active on-site.

So post em up, lemme know your thoughts on enabling me to fly without the fear of hardware failure, and the possibility of losing more money and gear. (related safety issues aside)

Views: 2997

Reply to This

Replies to This Discussion

Hello Mark,

I have been trying to understand the differences between 3DR and FrSky and which one is more reliable or works better with the APM 2.5. I am considering buying the ready to fly hexa kit that comes with the FrSky and the 9ch TX/RX, but I want to know if the 3DR is better.

I know... you will probably say: research more. and you are probably right. But nothing compares to the word of the guys that know.

Thank you!

I needed to know what each did better. I wasnt sure what the FrSky did. now I know.

Hi estebanflyer,

The two radios are used for two different things:

  • FrSky for flying, from the transmitter ("remote control") to the aircraft.  The transmitter needs a FrSky module to transmit to the receiver on the aircraft.
  • 3DR for telemetry, downlinked from the aircraft to the PC.  It's pretty much a replacement for the USB cable.

Both FrSky and the 3DR radio are excellent and I can recommend both.

I see!! Frsky is for flying and telemetry, while 3dr is only telemetry. great. thank you!

Having demonstrated a properly working failsafe on an expensive radio apparently being blocked by the APM PPM encoder behavior, could someone please explain this to me because I'm confused - this demo is in direct contrast to all the bashing I have received lately.

Not entirely true, the demonstration shows the PPM encoder having a design weakness by keep the last known value when there is a physical signal wire loss.

The price of you radio has nothing to do with it simply because the throttle channel of the receiver is disconnected, preventing any failsafe value from reaching the APM board. When the throttle channel is reconnected the Spektrum failsafe clearly works as intended again.

The only radio receiver I know of that supposedly stops sending a signal on the throttle channel (same effect as physical wire loss) is the 9X. And even here there are conflicting reports depending on firmware and receiver revisions. All other radio systems that I know of, will either transmit last known or failsafe throttle value when the radio is turned off.

So to make it clear. The design flaw (I will admit that, but it was by design for technical reasons mentioned in the failsafe thread) is only in effect when there is a broken throttle wire, or with certain 9X radios/receiver combinations having uncommon failsafe throttle handling.

Anyways, with the new firmware the wire loss/9X throttle problem should be solved.

I have experienced this as well, had a loss of control that saw my quad fly away. I am on here almost every day and knew of the issue and have been following it closely, yet i still continued to fly with my stock 9x.

the wakeup was when i lost my quad, i was very lucky that when i walked (kinda running and panicing) to the way the quad dissapeared i got the signal back to the xbee's then after working out where it was from the GPS i drove till i got the video signal back too. found the quad undammaged on someones front lawn, luckily it didnt hit their BMW in the drive.

Who knows how far it would have gone if the battery had more charge left i guess i was lucky on more levels than one!

Since then i have modded my 9x and set the failsafes. and i guess another thing is having the xbee's and making sure the battery is secure so it doesnt get ripped off in a crash.

I have been considering getting a GSM GPS tracker, they are small and light, independant battery etc. 1 quick sms and it will send you a sms back with its gps position speed etc. they have about 48hr battery life (rechargable) and work almost everywhere.


Another option along those lines... There are quite a few people on ebay selling "GPS trackers" which are simply Boost Mobile phones with a GPS tracking app (free).

From what I remember getting a prepaid Boost Mobile phone and using one of the free or pay apps is the cheapest way to do GPS tracking.  I haven't used them, but I think they're a lot cheaper ($35) and have longer battery life and better tracking capabilities (maps and internet location).

It would seem Zen's question about most stable/reliable/dependable gear has substantially been answered regarding R/C equipment.  However, I for one would like to know from this group what they think offers the most predictable baseline functionality for flight stability and fault-tolerance (or fault avoidance).

For example, I added the GPS and compass options to my APM 1.4 thinking that it would be interesting to play around with the navigation features at some point, but if those ancillary components increase the risk of anomalies in the basic flight control functions, should they be turned off?  Some have said that the DJI NAZA is a better turn-key control solution if you want basic stability and are willing to sacrifice some (most?) of the autonomy.  HK has a very basic unit too, and while it has almost no features at all, it's as cheap as dirt.

Let's face it: even in their most minimally functional configuration, these are complex devices, and it doesn't take much to send things askew during initial flying.  Perhaps it IS a good approach to vet the whole rest of the craft with a minimalist control solution before advancing to whole "tuning your loitering" thing.

What does that roadmap look like?  Is there a sans GPS basic stability configuration for the APM that removes most of the variables?  Should one start with the HK, and only if a stable hover can be established, then the APM should be implemented?  Is the DJI NAZA simply "the one to get", unless one DOES have a desire to extend the experimentation into the realm of true aerial robotics?

Considering the stated openness objective of both the APM platform and this forum, we owe it to ourselves to have a candid discussion of where the state of this art fits with the needs of the community.  If we don't have a fundamentally stable ship as a result of our efforts, nothing else really matters.

The APM platform is by definition experimental. Meaning that new features and updates are constantly added. And as we all now, new features and updates means there will be bugs in the system.

The alternative is to have a stable branch with focus on code quality and a proven feature set. New features would be added much less frequently and only if they do not impact core performance and have been proven during extensive testing. More like how commercial products (from a serious manufacturer) is maintained. But a stable branch will not just spring into life by itself. it would require a lot of work making and maintaining. Compared to the experimental branch, development would move at a snails pace. And the resources required would most likely also affect general speed of development on the APM platform.

Mr. Birkeland: I agree with you completely.  In fact, I would even go one step further by saying that all non-turn-key solutions in kit form, and especially those cobbled together from piece-parts (frame from this guy, motors from someone else) are highly experimental.  

The guiding philosophy of "Do It Yourself Drones" perhaps is the question, and most specifically, what would provide the greatest good for the widest interests of the group?

Not everyone here is interested in bleading-edge robotics experimentation, where the risk of failure might be hundreds of dollars of lost investment.  I'd say Mr. Zen is just such an example.  Some are here to learn, experiment, and ultimately carve their own path to enlightenment, but I'm guessing they're a small minority.  Most want the functionality of a drone and are willing to put forth the integration effort to keep the price down below $5K USD.

A good analogy here is the manned EAA/experimental aircraft market.  Those folks aren't all aeronautical engineers, but rather pilots on a budget willing to devote lots of time to the project but not a lot of money.  The resulting product is still officially experimental, but not to the point where they have to worry about the wing shearing off in a 2G turn.

I am also not suggesting that DIYD (or 3DR) necessarily needs to have multiple coding paths for the APM; the basic "ultimate stability with training wheels" solution might not include the APM at all.  Rather, why don't we flush out what the options are, and the risks and benefits associated with each?

Brad,  check out the Multirotor forum on RCGroups:


Just about every multirotor controller project has a dedicated thread with lots of good information.  I've got a KKBoard (no hobby king version for me, this is back from when they were $150! :-/) and MultiWii, and it's been very interesting to compare and contrast the philosophies, designs, and flying results of the various models as you've said.

Here's the slides from a presentation I gave a while back... it was an arduino-centric group, so I included notes on all the above systems... you might find it interesting.


I think there is somewhat of a problem the way APM went with the design.  There really should be a basic and a stable branch.

A lot of the difficulty seems to have come from the fact that there never really was a basic stabilization period of development.  As I've said before, the APM has a lot of bells and whistles that work great, but some of the basic things aren't mature yet.

The PPM encoder flaw is a perfect example.  The devs never worked out the very first step of the whole system correctly.  So we have a great GCS, good navigation, sonar, optical flow, current/voltage sensing, GPS, loiter, FBW, multiple flight modes, takeoff, landing, etc., etc.  But the damn thing still can't properly pass PWM in one side and out the other!

Nobody even seems interested in working this out all the way either!  It took a very heated thread that actually got a member banned for anyone to even admit there was a problem.

JB coded a workaround that will probably work great for most people, but it still will not faithfully pass PWM from one pin to another.

Maybe the way it's done is for the best, BUT... if someone bought our ultra-fancy APM, with all it's bells and whistles, and actually needed it to faithfully pass PWM through they'd be out of luck!

Perhaps with the upcoming 32-bit ARM processor switch we can go through everything again with a ground up philosophy.  I haven't seen much discussion on this, so I can only assume the dev team is working on this in secret, which is another big problem with this project.  Without input from everyone a lot of things get missed and better ideas fail to be brought up until it's too late.

Last September, when I suggested building a radio around the Si1000 chip (now known as the "3DR radio") only one other member even replied to my thread.  Instead of discussing it openly the 3DR team started working on the project in secret.  When the 433mhz version turned out to have a major design flaw it was a total facepalm for me!  Had they bothered to ask me I would have told them to put the TTL converter in the cable, or just use an off-the-shelf one, right from the get-go.  Instead, I only found out the radios even existed when a friend from the open pilot project emailed me, "Hey DIYclones stole your idea!"

Throwing a HopeRF module on a carrier board is not some brilliant idea you have to hide from others and develop in secret.  But because of the current culture they paid the price and are now sitting on a bunch of garbage boards they can't sell.

Hopefully that, and the PPM encoder flaw, will prompt the powers that be to adjust their philosophy a bit and open things up to everyone so they can reap the benefits.


DIY Drones Monthly


Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2016   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service