Is safe flight possible with diydrones gear?
by Zen [ http://diydrones.com/profile/Zen ]DIYDrones.com
June 4, 2012Ok, 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 [ http://diydrones.com/forum/topics/my-4-day-experience-w-ardu-3dr-kit-a-newbs-review ].
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:
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 [ http://diydrones.com/forum/topics/help-with-new-first-tx-rx-purchase-budget ] 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 [ http://diydrones.com/profiles/blogs/housekeeping-note-kevin-finisterre ] 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 [ http://www.youtube.com/watch?v=aSMiFup3HZg&feature=related&hd=1 ], which was the whole point of bringing this APM bug to light [ http://www.youtube.com/watch?v=axUwRs2oCck&hd=1 ]. 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)
8:31am
By Jake Stew [ http://diydrones.com/forum/topic/listForContributor?user=2egm7fj1oj7qk ]
June 4, 2012
I think the new PPM encoder firmware should fix the problem. It loads with a USB boot loader, so I think it's probably not that difficult to flash. I'd also assume with all the heated discussion that it will be included on new APMs very shortly.
But nothing is going to have the safety you're looking for. Everything is still very experimental and there are lots of bugs that occasionally pop up even after dozens of perfect flights. Just read some of the threads here!
This makes it very hard to call anything "safe". I'd suggest that you better take lots of safety precautions AND be willing to accept the fact that you might loose your gear. That's why I fly with dirt cheap gear as much as possible. If you build your quad from some simple wood or aluminum from the hardware store you don't have to worry as much because the cost is low and you develop the skills to fix and rebuild anything that breaks.
As far as trying to make things as safe as possible I suggest that manual control is a must. If the APM fails you have to have a backup. I'd suggest starting with a quad that can actually be flown manually, then adding an APM. That would mean having a RX->stabilizer system->APM setup. The APM is a complex setup, so there's tons of things that can go wrong. When people fly with a quad that can only fly if the APM is working perfectly they are asking for trouble IMHO.
I love watching youtube and reading guides on building stuff for cheap. Look at PBFs (pizza box flyers) and oldskool quads. These guys are literally building stuff out of scrap and risking very little. Almost everyone I know crashed their first handful of flights. That's totally to be expected. You see people flying like pros and it looks easy, but they got there by crashing MANY times. I just crashed myself a couple weeks ago from a stupid mistake.
Since you haven't run crying to mommy I think you've got what it takes to fly. My best suggestion is to learn on a simulator and forget about performance/range, or having nice gear until you're good at flying. Build a quad out of two sticks and the cheapest stabilizer board you can get. Order spare parts ahead of time and keep at it until you're good enough to need, and willing to risk, a larger investment.
9:06am
by John Arne Birkeland [ http://diydrones.com/forum/topic/listForContributor?user=06y3ki3y983p5 ]
June 4, 2012
>> 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.
2:24pm
by Brad Hughey [ http://diydrones.com/forum/topic/listForContributor?user=22dwubfcdzj38 ]
June 5, 2012
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.
5:05am
By John Arne Birkeland
June 5, 2012
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.
7:18am
By Brad Hughey
June 5, 2012
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?
7:49am
By Jake Stew
June 5, 2012
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.
3:22pm
By Rob_Lefebvre [ http://diydrones.com/forum/topic/listForContributor?user=2ah4ml3io2sp6 ]
June 5, 2012
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.
3:41pm
By Jake Stew
June 5, 2012
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.
4:07pm
by Jake Stew
June 5, 2012
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.
5:17pm
By John Arne Birkeland
June 6, 2012
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?
12:03am
Copyright 2012 http://diydrones.com/forum/topics/is-safe-flight-possible-with-diydrones-gear?id=705844%3ATopic%3A880958&page=1#comments