forum PM: "Just know that the 'imaginary' group you represent isn't so imaginary at all. But I guess you already know that" - silent DIYDrones user
This topic was setup in order to move degenerative conversation points away from the "Hex decided to leave and never come back" thread to a more appropriate location. http://diydrones.com/forum/topics/hex-decided-to-leave-and-never-come-back
The original post wording stated that it "should be used as a sounding board to discredit the abrasive comments made by myself and others that operate the DIYDroneSafety website, twitter feed, and the Drone Savant forum persona. Either take it off list or put it here... It appears as if we need a special topic to discuss WHY some people feel the need to be abrasive around here in order to get critical safety issues fixed. Some claim slander, damage, abusive behavior, libel etc., while others claim simply claim awareness and safety from half truths and lies by omission..."
^--- This was simply a conversation starter which had wonderful results. Discussing the "need to be abrasive" really was not the point. This comment nails the actual point http://www.diydrones.com/xn/detail/705844:Comment:1009087
I think there are specific and real issues, which Kevin is raising. Most of his complaints about the code are at least valid, even if not easily solved. His complaints about the documentation are also valid, and are easily solved.
Traditionally the following topics have produced some contention amongst the ranks of developers, moderators and end users. As such user understanding, vs. documentation, vs. code has been confusing at best and at times unsafe:
PPM Encoder
Watchdog functionality for code lockup situations
Powering the APM with cheap ESC's via input rail (brownout problems)
These topics are *NOW* being actively investigated in a variety of forms and are producing valuable information.
Safety Watchdog - http://www.diydrones.com/xn/detail/705844:Comment:1007583
Watch dog added to shutdown motors if main loop feezes for 2 seconds (Randy) -
Brownouts - http://diydrones.com/xn/detail/705844:Comment:1010389
We're going to be shipping a stand-alone power supply (and voltage/current sensor) that will ensure that brownouts never happen. Hopefully in a few weeks.
PPM Encoder logic explained - http://diydrones.com/forum/topics/kevin-finisterre-diydronesafety-and-drone-savant-persona?commentId=705844%3AComment%3A1009804
With the discovery that the Turnigy 9x radios using original receivers and firmware, would act in a non-standard way and completely drop the throttle signal during fail-safe (same effect as a broken wire). The detection of single channel loss became a real problem, and a patch was made to detect single channel loss (throttle only) at the expense of some jitter and stick resolution.
New Original Paparazzi & APM PPM (servo2ppm?) logic flaw brought to light
Olivier found and documented some very real and very serious problems with the original Paparazzi PPM Encoder used by APM 1.x. What Olivier found and proved by extensive testing, was that that PWM channel sequences from certain R/C receivers would confuse the Paparazzi PPM Encoder. Resulting in the throttle channel (among others) locking up.
Hats off to developers like R_Lefebvre and people Monroe for stepping up (even if begrudgingly in Monroe's case) to help get to the bottom of these potentially serious safety issues - http://diydrones.com/forum/topics/fly-aways-the-failsafe-and-the-9x
When you are "The largest amateur Unmanned Aerial Vehicle (UAV) community", it doesn't matter what everyone else is doing. "Well they have flyways too" aren't the words of someone leading the head of the pack. Well can do better and deserve it.
Stay Vigilant.
Replies
It's disappointing, and troubling, that some of the most uncivil discussion, including personal attacks, has come from a diydrones moderator. It might be a good idea to give moderators pointers to resources on healthy community management.
Well, let's try talking about something constructive for a change.
I had some free time and had a look at the ArduPPM and single channel fail-safe detection. I am not promising anything right now since I haven't finished testing jitter. But I think I found an acceptable compromise that will allow single channel detection on all channels and still maintain good general performance with regard to jitter and stick resolution. Trick was to migrate most of the fail-safe detection to the more timing deterministic PPM output generator, instead of doing it all in the PPM input interrupt.
This is going to be my first and only post in this thread, and is in regard to the DIYDroneSafety articles about ArduPilot and PPM. I found those articles to be a very funny read btw. Weird in a reality distorted way, but still funny.
Here are some simple facts to keep in mind if/when you read those articles.
- ArduPPM, the current PPM encoder used in all APM2.x boards and APM1.4 board when firmware updated. Does not contain a single line of code from the original Paparazzi PPM Encoder. It is a complete rewrite, using a completely different approach to deal with PWM pulses, interrupts and timing issues.
- The primary goal and origin of the rewrite/recreation was to move the PPM encoder from the APM1.x 328p chip to the new APM2.x 32u2 (8u2 in original Arduino boards) chip used in newer Arduino boards to replace the costly FTDI USB to serial conversion chip. That meant that we could get away with one less chip, since the PPM encoder and USB to Serial conversion would be running on the same processor (32u2). But the design of the Paparazzi PPM Encoder would not play nice together with the Arduino USB-To-Serial code. So a complete redesign was necessary.
- The second reason we did a complete rewrite. Was that Olivier found and documented some very real and very serious problems with the original Paparazzi PPM Encoder used by APM 1.x. What Olivier found and proved by extensive testing, was that that PWM channel sequences from certain R/C receivers would confuse the Paparazzi PPM Encoder. Resulting in the throttle channel (among others) locking up.
So on the one hand we have the Paparazzi PPM Encoder with a confirmed and very real safety issue (throttle channel sporadically locking up during normal flights, with certain receivers).
On the other hand we have the new ArduPPM encoder whose that has been designed from scratch to have less input jitter and handle any sequence of PWM channel inputs. Performance that has been proven with extensive testing over long periods of time.
In fact the only known (and reported) weakness for the ArduPPM, is that it will not enter a "single channel" fail-safe if there is a problem with a receiver wire. If the receiver dies completely fail-safe will active, but a single channel disappearing will not activate fail-safe. Instead the last known position if that channel will be used. This has always been a known weakness, and has to do with how much code we can run in each interrupt and still maintain low jitter and good stick resolution. With the discovery that the Turnigy 9x radios using original receivers and firmware, would act in a non-standard way and completely drop the throttle signal during fail-safe (same effect as a broken wire). The detection of single channel loss became a real problem, and a patch was made to detect single channel loss (throttle only) at the expense of some jitter and stick resolution.
So that's it. The complete history of the ArduPPM and the reason behind the "storm in a glass" regarding PPM.
It all kinda feels like this :
I wish this whole conversation, and the majority of the previous one in the lost hex thread would die a quick death, just like the psycho convict did in tonights Walking Dead. Machete to the skull. I'm cursing myself for adding to the drivel.
The great thing about this board has been the COMMUNITY. Since it started up, there has been an ebb and flow of awesome people coming in here and adding awesome shit to the functionality of the 3DR hardware. FOR FREE.
You cannot complain about work that people are doing FOR FREE.
Take the code, use it, augment it. Fix the shit you think is broken. (Thanks again GPL!) Test and provide constructive feedback if you want.
Or don't. Go use some other variant that has its own set of issues. No one is forcing anyone to be here, and repetitively ranting doesn't help fix things. It detracts from the community and disenfranchises not only the new guys who just see people bickering and trolling, but also those that have been here forever and done everything they can to make a reliable product for us laymen to enjoy. FOR FREE.
You're going to crash. You're going to lose stuff. It's happened to every single one of us. If you wanna play, you're gonna pay.
If we could have harnessed the thought power and keystrokes that went into all of this BS, not only would we have the best AP....we would have world peace and fed every hungry child in the world.
JC
SO, I'd like to hear from the Mods / Devs...are there specific and real issues here? This seems to me to be a set of rants that could be easily remedied with a mention in the documentation. Perhaps a "Best Practices" section that says, "Hey, it is pretty likely a bad idea to do X...or some users have reported Y problem, we believe this can be avoided by doing the following...or even Turnigy 9X radios are inexpensive, and ok for beginners with very small budgets, but sometimes you DO get what you pay for."
I know documentation is the LEAST sexy job in these projects but it COULD be the MOST important.
There are some moderators that think that freedom of speech means you can post what ever you like, can I remind all who post there under the terms of service freedom of speech does not extend to posting "in a manner that is libelous or defamatory, or in a way that is otherwise threatening, abusive, violent, harassing, malicious or harmful to any person or entity, or invasive of another's privacy;"