Replies to This Discussion

Permalink Reply by Jake Stew on May 14, 2012 at 9:59am

   I guess that's one way of looking at it, but probably not the most legally sound, and certainly not in the spirit of open source.

   What you're essentially saying is that you're taking responsibility for the content since you have 100% control.  So any errors in the docs that cause property damage or injury are legally your responsibility alone.  You're also responsible for any omissions you know about and don't immediately add to the documentation.  That's kind of dangerous since it would be easy to find some buried warning post on the forums here that you didn't add to the wiki.  When someone gets hurt they'll be pissed it wasn't in the docs and they could potentially sue you for knowing about a problem and failing to notify people.

   For example, my APM 2.0 frequently throttles up to around 80% for several seconds when I first power it up.  You now know about this problem and you also know this could easily cause injury to someone.  I didn't see a warning about this in the docs.  If someone does get hurt they can now say you acted negligently or maybe even recklessly by not including a warning in the docs.  They could even make a case that you actively prevented this warning from being included.  When someone (judge/jury) thinks wiki they think of wikipedia and would think if very strange that the only way to edit a page is to send you a personal email asking for access (if that user even knew that was an option).

   OTOH if the wiki was open it would be hard to point the finger at you.  This is just my way of thinking and some of the court scenarios I can imagine.  I'm not trying to be a complaining ass, and I mention these things only to be helpful and get the project to it's full potential.  Personally, I'd be happy to help edit the wiki, but I'm not really interested in working in a closed environment.  The closedness, and closed attitude, is a barrier to more aggressive participation by myself, and I assume others.

• ▶ Reply

3D RoboticsPermalink Reply by Chris Anderson on May 14, 2012 at 10:15am

Jake: I'm not sure who you're referring to by "you". The dev teams are a group of about 100 volunteers, with many project managers, individual team leaders and other  contributors. Many of us have sysadmin privilages and can invite in/approve others to join (I'm just one of them). 

This dev team is not a company or even a formal organization. It's just a group of volunteers from around the world. Since you seem to be familiar with open source models, you will recognize that volunteers giving away free software is not subject to the sort of legal liability that you describe. 

I hardly think that potentially lowering the quality of the documentation by allowing unverified contributions to the wiki would lower the risk of catastrophic error. Instead, our model is exactly like most other open source hardware projects, which is to say that there is a very simple process for vetting and approving people who would like to contribute.

Do you know any other open source hardware company that does what you describe (opening their wiki to all)? MakerBot did for a while and it was a disaster for just the reasons I've described, and they've now made it invitation-only, like us. It took them ages just to clean up the damage from the open access period.  

• ▶ Reply

Permalink Reply by Jake Stew on May 14, 2012 at 11:17pm

Paparazzi for one.  There's also wikipedia and countless others (I now that's kind of a cop out).  I'm not saying that a valid registration or forum post minimum or actually having ordered the hardware or some other requirement not be used.

But I think you really are missing out on a lot of valuable contributions.  If you look at the wealth of information on the forum compared to what could be available on the wiki I think you might see how awesome the docs could become.

When I'm actually figuring things out is when I would add info to the wiki.  It's easy to forget the difficulties or not bother after you're experienced with tech.

With regards to the responsibility, you're taking a lot on when you maintain iron clad control.  When it's totally open there's shared responsibility for all.  Hard to say something should have been mentioned when anyone could have mentioned it and didn't.

It's hard to see how that much trouble could come of opening up the wiki in some fashion.  Wouldn't be too difficult to have a user wiki and an official wiki.  If someone vandalizes it it's not too hard to delete/revert all changes by a specific user or entirely roll it back to an earlier date.

Just saying it's worth trying, and something I would be likely to participate in.

3D RoboticsPermalink Reply by Chris Anderson on May 15, 2012 at 10:53am

Jake, I'm less concerned about vandalism as I am by well-meaning but wrong/confusing/unnecessary/outdated/contradictory contributions, which are much harder to check. Basically, we would have to assign a team the task of verifying every user contribution to the wiki, which simply adds to our workload.

We do, of course, do just that with software: contributors submit patches which are then code-reviewed by dev team members and then scheduled for testing and then merging into the trunk in the next merge window. But that process requires people to apply for contributor status, which is a useful filter to select for the people who are best suited to being productive contributors. 

The Paparazzi wiki is a great example of what not to do. As much as I admire the technology, the wiki is a total mess and the project, as you know, has essentially stalled due to lack of community participation (unless I'm mistaken, the hardware is no longer available, or at least none of the links I can find in the wiki, many of which are simply dead, lead to products I can buy).

Wikipedia is not a hardware project, so the consequence of the inevitable errors there is not as severe. 

Your own issue is actually a good example of the problem. As far as I know, you're the only person (out of about 10,000 APM users) to have this issue, which may be unique to your setup (RC+ESC combination)--at least nobody else has reported it as far as I know and the dev team can't replicate it. This is exactly the sort of one-off issue that should not be in a manual, at risk of making it totally cluttered and unusable for the average user. Just imagine what a mess it would be if every edge case and tech support issue was mixed into the basic getting started guide for all users. 

Thus the distinction between forums and a manual. The Manual should the basics for most users; forums are for edge cases and unique tech support issues. If an issue that crops up in the forums turns out to lead to a recommend change in the manual, we have a process for doing that, involving a verification step by a dev team member. 

Finally, I'm really glad we're having this discussion and value your input. If you'd like to be given wiki access privileges, just say the word and I can set you up with what you need to contribute. 

3D RoboticsPermalink Reply by Chris Anderson on May 14, 2012 at 10:19am

PS--regarding your throttling up at startup. Are you using the latest code (ArduCopter 2.5.5 or ArduPlane 2.34)? If so, have you filed an issue? The only way the dev team will accept issue reports is via the Issue Tracker (just like all other open source projects).

• ▶ Reply

Permalink Reply by Jake Stew on May 14, 2012 at 11:24pm

I did just update to the 2.34.  It seems perhaps better, but I'm also more careful to level my plane now (wheels vs flying aren't quite the same) and wait for a bit.

It still does goose the throttle for a sec. when I flip my 9x on.  Usually just the first time after boot though.

I also got a surprise when I accidentally flipped it to auto mode and it took off on me.

Luckily I did proper testing without a prop and realized I better hold onto the plane when I fire up the APM or transmitter.

It could be entirely a Turnigy 9X transmitter problem.

DeveloperPermalink Reply by R_Lefebvre on May 15, 2012 at 1:17pm

Jake, I STRONGLY recommend you separate your power system, for safety.  You should be able to power up your APM *and* the Rx, and do a quick systems check before supplying power to the ESC/Motor.  That's what I do, for safety.

This has a bonus safety feature that any good ESC, if it is being sent anything other than low throttle when it is powered up, will lock out and not turn the motor.

I have not once had an unintentional propeller wind-up using this method.

Permalink Reply by Mike Estee on June 27, 2012 at 12:33pm

(this is a somewhat out of date of thread, but i'm going to pile on here anway ;) )

Chris,

You raise a bunch of good points about the dangers of UAV flying. There are a bunch of communities that run into this general problem. The fire arts & the aerial circus rigging communities are two I've experienced this in. The sentiment that these are dangerous activities where someone can get hurt or killed easily with bad knowledge is a prevalent one. Usually there is someone who falls heavily on the "too much knowledge is confusing and dangerous" side, and someone who falls on the "more knowledge is safer than less" front.

I fall strongly on the later, rarely is the solution a less informed public. We're probably in agreement.

The question then becomes, what is the best way to go about solving this problem? The DIYDrones community has largely chosen the forum model. "Check the forums" is a common message one will hear as a noob exploring the world of RC in general, not just here. Forums are an excellent method for collecting collective knowledge, but they're not so great at organizing it and making it accessible. There are a few reasons for this:

No strong indicator of good vs bad advice - one needs to read quite a bit of context to (hopefully) make an informed decision about what the common best practice is for a given activity. Important insights must fight the stronger signal, they don't always win over, not because people don't agree with them.

Outdated information lives too long - Due to the nature of search engines, and link propagation, outdated information will often become more entrenched over time making it easier to find than timely correct information. 

High signal to noise - The need to use google search is predicated on there being a very high signal to noise ratio in forum discussions. One has to sift though a large amount of noise and irrelevant information. Implicit organization is temporal, not topical. TL;DR usually wins out.

Given that, I would like to offer the following observation, as a late comer to your community: I have found the APM's current level of documentation to be seriously wanting. There is a lot of missing or out of date information on the wiki, which is less a criticism of the wiki, and more praise of the speed at which the dev team moves.

You guys are going faster than your documentation can keep up. An unfiltered publicly editable wiki is not the right answer, but asking your community to ask for permission before editing is going to demotivate pretty much mostly everyone with something useful to contribute. I know you're familiar with the old saw about permission and forgiveness.

The trick becomes lowering the barrier to entry, and increase the speed at which contributions are vetted by more experienced members.

Just having a system where one can add "preliminary" documentation that is then rolled up into the main wiki after being reviewed would be an improvement. There's no visible way for that to happen on the wiki at the moment.

--mikest

• ▶ Reply

3D RoboticsPermalink Reply by Chris Anderson on June 27, 2012 at 12:46pm

Mike: thanks for the feedback. There actually is a method to add preliminary information to the wiki, one that is used dozens of times a day: the comments on each wiki page. We read all of them, and when suggested changes are offered, we implement them. 

As for your own experience with the wiki and missing/outdated information, please leave a comment with a suggested correction on each page where you've found a problem and we'll try to correct it in a day or two. (Unless you're asking for a whole new tutorial on something, rather than just correcting something out of date or confusing)

• ▶ Reply

Permalink Reply by Serge on May 14, 2012 at 7:23am

A while ago we initiated a similar initiative; www.dronepedia.com, however it never really got of the ground. It was intended to be a bit broader than only APM, and mission planner; but they should definitely be featured. 

Maybe a good moment to re-try. It's open for everyone to edit, and was intended to be an up to date knowledge base for AP enthusiasts. Zach Bayne is the one who set it all up. A link to the original initiative is here.

• ▶ Reply

Permalink Reply by Jake Stew on May 14, 2012 at 9:36am

Just checked it out.  Looks awesome.  Can we put up some links on the left for the docs?

• ▶ Reply

Permalink Reply by Stephen R Mann on May 15, 2012 at 8:23am

"But I think you really are missing out on a lot of valuable contributions.  If you look at the wealth of information on the forum compared to what could be available on the wiki I think you might see how awesome the docs could become."

I will check out the dronepedia.com site.

Here's another unseen problem.  I am a newbie - so much that I have yet to assemble my first aircraft, let alone fly it.  Whenever I have a question, my mentor sends me to yet another website.  There is no single point of information.  A broad-based wiki would really help me with my apprehension about spending upwards of a thousand dollars on an entirely new hobby.

Flying has always been my favorite hobby and I have over 1200 hours in my Cessna.  But for health reasons, my piloting days are over.  (sob).  And I had to sell my Cessna Cardinal.  But I really miss being "up there".  So, I have ordered a Hexacopter kit and an APM to take my GoPro camera up a hundred feet or so to get back that view that I miss.

• ▶ Reply

• ‹ Previous
• 1
• 2
• 3
• 4
• Next ›
• Page