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.
I've been busy on another project and finally decided to check in with DIYdrones... And this is what I find!
I'm not sure why this thread exists, or why it is the "Top Content" on the site. I certainly don't have time to sort it all out.
But I will say this, Chris and the other management on this site have shown that they support free speech at about 70-90%, depending on the day of the week. That is to say that they are not perfect, but pretty lenient all things considered, with the site/store being what it is.
So the users that constantly gripe and complain and cry and troll and flame Kevin (Drone Savant) REALLY need to quit!
If you have a logical and reasoned argument against something he's posted, then post it! If you think some argument is repetitive then state your argument and in the future just respond with a simple link to your "position paper" on the subject.
It's really not that hard to deal with people you disagree with when you act like an adult.
From what I've seen, Kevin makes many valid points and has contributed a lot to the site. It seems to me that most of the time he's responded to with asinine drivel from people who have past beefs with him. Then when he responds the diehard fanclub piles on with their crap posts. Then some big babys try to make the whole thing an issue with moderation.
My advice is to quit turning everything into such an argument and then crying about it! If your argument holds any water at all then a simple post saying you've discussed the issue before, along with a link to the previous thread or a webpage with your response, will win the argument far better than all this crying and griping.
In the interest of improving things here I'm extending an open invitation to anyone who would like to have a webpage containing all their gripes and arguments. I'll provide you a nice short link where you can post anything you want, excluding hardcore pornography (send that directly to me) and copyrighted material. No other rules whatsoever! You can then post than link whenever you encounter something here that is best addressed with a stump speech, or argument that needs to be supported with a full web page.
There should be no excuses now. If someone posts something that doesn't dignify a response, then don't dignify them with a response. State that you object and point them to your page containing your well reasoned argument against them. It will save you the typing and I'll also be happy to help get your info online.
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.
probably smoking a bad batch
It all kinda feels like this :
Can't we just ignore Drone Savant? He's pretty much ruined his cred here. Replies just encourage.
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.
-
1
-
2
of 2 Next