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: 3104

Reply to This

Replies to This Discussion

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.


Yes, the design in my head is as follows:

1- Use a switch on the transmitter to flip between one of two controllers connected to the MUX.

2- Fly normally with one controller, selected, but but both turned on and running.  Both controllers are getting the yaw/pitch/roll/throttle, so they both are calculating attitude relative to controls.

3- In case of emergencies, that I suspect is controller related, flip the switch and let the other controller take over.  Since it's a hot spare already running, it should be able to almost immediately take over.

Very experimental of course, so I'll have to take all the precautions, maybe even a tether for the testing.

Also, I'm planning to do a comparison between how a Naza and APM1 can fly the same frame, so having this setup allows me to easily switch between controllers using the same frame between tests.

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.

So Jake, are you volunteering to create and maintain a stable branch?  It will be a LOT of work, but I think you're up to the challenge.

If I thought I had the time to do it justice I sure would give it a try.  But, I don't have the time and my coding skills are fairly weak as I've only had two college level programming classes quite a few years ago and haven't done much since.

I will volunteer to help with the software engineering though!

I don't really think it would be all that hard to strip out everything but the basics then spend a month or two testing and tuning it until it works perfectly.

As easy as it is to load firmware on the APM, I would think a lot of people would be interested in stabilization only firmware, at least to run some of the time.  A stabilization only firmware could run faster and probably do a better job at certain things.

A "back to basics" branch would also be the perfect opportunity to implement new features since it would be a good test bed to vet new code on and easier to work with.  Adaptive control loops, a RTOS, or other features could be implemented easier on a basic branch, tested, optimized, then moved to the full feature branch.  With more speed and memory it would be easier to get things working and debug them.  Even a whole debug branch might be nice since you could more easily add debugging code.

I understood it was experimental.  BUT I think most people get mislead by the features list and the versioning of the software.  I was really surprised at the PPM issue.

If it was version 0.98 beta... I would wonder if the PPM encoder might still have some bugs to be worked out.  But with version 2.34 I expect that all the basics are worked out and fully stable.

I think people also expect that with all the advanced features advertised the basics must be rock solid.

I don't fly quads, but I've noticed quite a bit of bitching about the APM on other RC forums.  Many seem to suggest that the more basic stabilization boards do a better job of stabilization.  I would think that we would want the stabilization to be at least on par with the cheaper boards, and would work almost exclusively on that until it is.

I like the APM and it really does have a lot of features I need that can't be found anywhere else.  These are just my thoughts on how the engineering process could be focused more effectively and why it might be good to have a basic core version of the firmware.

How many times must I repeat that the design flaw was known from day one, and decided to be at an acceptable level since the weird/unstandard FS behavior of the 9x was unknown at the time. In practical engineering you must balance the features you want with the capability of the hardware available. Would you be happy if the failsafe was 'perfect' detecting any and all possible problems, but as a result stick movement would be jerky and move all over the place?

I posted this before I noticed your reply in the other thread.

Maybe I just don't understand things well enough, so you'll have to forgive me for not fully comprehending everything right away.  I'm just throwing out my thoughts and ideas.

One thing that would be helpful is a more thorough and technical descriptions of the way things operate.

My understanding was that the "PPM encoder chip" in manual mode takes the PWM inputs and does whatever it needs to do, but was supposed to re-output them the same to the outputs.

This has never been made particularly clear in my reading.  I'm guessing that it takes the PWM, then encodes a PPM signal that it passes to the main chip, then the main chip outputs the final signals?

Reply to Discussion


© 2017   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service