We're moving to a new documentation platform and this is your opportunity to give us feedback and help. There has been a huge amount of work going on behind the scenes on these over the past three months, including the 30 volunteers working within the Documentation User Group. It's now time to include the full community.
You can see a glimpse of the team's work in the betas of the new ArduPlane, ArduCopter and ArduRover sites. Click on the "Instructions" tab to see what the new manuals will look like.
Right now most of the work has been in creating new graphics and design elements to make the manuals easier to read and use, with some work on simplifying and updating the content. But because they're based on a Wiki-plugin for WordPress, it's also a much more powerful and flexible collaboration environment than the current Google Code wiki for community participation, and we can now take this opportunity to update and improve every page of the manual.
Just a reminder that these sites are still in beta, and we won't be steering users to them until the documentation team has had an opportunity to scrub every page. We'll continue to maintain the Google Code wikis for legacy purposes, but the new sites are designed to reflect the model we'll be moving to in the future.
Please give us feedback in this thread. If you'd like to participate, please join the Documentation User Group linked above.
Replies
I have a question regarding the X8 Quad configuration, I've seen the questions posted before but no real definitive answer as to whether I can swap out an XAircraft controller with a new APM 2.5+. The old manual shows X8 Quad pictured but no Icon in the mission planner when you go to grab the firmware. See pics below-
Lot's of great feedback here. As Paul just mentioned, it's all starting to get buried in this long thread.
I encourage everyone interested in this work to register over at the new forum and start participating in this effort over there. It's a blank slate waiting for our inputs.
Hello,
Having built my 3DR quadcopter, and having therefore gone through the wiki and forum extensively for more than two months to find every bit of required information to build.assemble the quad (correctly with a minimum of understanding so as to be able to interpret /analyse the Quad behaviour), I would like to highlight what information I found to be the most difficult to find on the existing wiki and documentation (for ex some info is not on the wiki, neither in the manual but hidden in a blog post somewhere) :
1-First and foremost : information and explanation about the Power & circuitry: PDB - ESC - Motors - APM . What powers what and why and with which inputs/outputs. The actual page about the power module and alternate power methods are not extensive and not explicit/complete enough : they do not give power schemes for a bird eyes view, they do not explain the "why" of JP1 (it just says when to remove it but no explanation why). Also more information needed about the BEC role and uses of one of the four ESCs, when and why to connect it to the ouput rail, why not connect servos on AN outputs, how to power AN connected devices (with output rail or secondary BEC), etc. I personally found out with many trials and errors. I lost two weeks on that kind of information.
2-In optional additions, there is nothing in the documentation about LEDs (not talking about the color code of the APM leds, tlaking about the way to use the ANxx outputs to drive external LEDs in function of the GPS statuts, Motors status, etc). Although there is a superb blog about this : http://diydrones.com/profiles/blogs/adding-external-led-indicators-...
This should be added to the documentation.
3-How to assemble the following components/options : best practices on sonar (with all of the Maxbiotic recommendations), best practices on APM vibration dampening, best practices on an optimum positionning of antennas (Telemetry, Rx Receiver, Video fpv) to answer such questions as : should they be positionned horizontal/vertical, how far from each other, how far from potential interfering electronics, etc
4-A Test section is completely missing in the documentation. But this is probably the most important section that we should have in the documentation. I mean testing , step by step, of all critical elements in the quad before even trying to fly and then testing necessary at first flight(s). Testing documentaiton should include a checklist of points to verify before each flight, such as : are your collets properly attached on the motors (especially if you have the 3DR ones, I know what I'm saying after three crashes), are your batteries full, is your APM correctly attached, is your main battery correctly attached, etc, etc
5-An extensive section explaining the chronological and logical steps to flying an auto mission. We find here and there on the wiki some information but it has to be mentally compiled in one sequence. I would write a dedicated section on preparing an auto mission : first try alt hold, then try loiter, then find a wide field (without people or houses or cars), then program simple waypoints, etc, etc
Just some ideas,
John C, I'll fix those.
Robert, I agree, I never let anybody between me and my copter. I also agree that GeoFence is a good safety device, but not one I would trust to extend control to others under circumstances where I would not otherwise do so.
I really prefer, a trainer transmitter or an experienced pilot.
And Josh, the New Wiki is very much a work in progress.
It is a bit tricky to port stuff over to it, but also they are really working to greatly improve the ease of understanding through the use of effective illustrations, consistent format and as little text as possible.
We will eventually get it all in there, but in the meantime, the old one still needs to be referenced too.
I will make a PDF version of the Safety section.
I have already produced a few downloadable printable PDF files for the Old ArduCopter Wiki and I think that a good set of those with appropriate coverage for field, tuning or assembly work can be useful.
Finally, Troy, you bring up a good point, So far, non PC use hasn't been addressed, but the reality is Nexus's, IPads and Windows 8 Tablets are going to be important for in field use.
At some point we will at least have to address tablets for actual in the field use and for at least some of the functionality of the Wiki.
A LOT is going to be happening this year, I expect that serious incorporation of Tablet functionality will fit in there somewhere. - Volunteers would be good!
In terms of usability the removal of of the navigation plane on the left is a huge loss.
I wish to volunteer to improving the documentation and give back to the community... Can I get access?
I like the new format. I'm hoping that this could be put into a PDF format so I can take it to the field with me. Some of the places I go to fly don't have Internet access.
Have Revamped the text in the Safety Wiki Section quite a bit and added Roberts "throwing in the towel" tip.
So, check it out and see what you think Here: https://code.google.com/p/arducopter/wiki/AC2_Safety
Still needs a bit of editing and some illustrations, but I think at least most of what needs to be in there is in there.
Any thoughts or considerations appreciated.
Chris, that is a step in the right direction. People need to have a resource they can tap into for setup that is up to date and matching whatever code they are using. You owe them that much. Reading through a 275 page thread to figure out how to fly the latest code is not the way to go.
Drone Savant`s suggestion of a RED safety button is great, it should be visible at all times on all the pages. Some people have a head on their shoulders and will naturally doubt things and apply caution regardless but the majority will assume that reading those steps will be sufficient to have them covered. We all know what that can lead to. How many more reports do we need?
We have had too many of them pouring in as of late with unpredictable behavior, for the sake of this hobby and the community at large, and also for your customers, you need to have safety banners on all sections of these manuals. People need to be reminded that they are playing with some very high power toys that have the capacity to seriously injure someone or cause serious damage. In doing so, you demonstrate that 3DR cares about making sure that the product is used in a responsible fashion.
People also need to be reminded that this is NOT and OUT OF THE BOX SOLUTION. It is merely a development platform with the capacity to *possibly* do things like RTL, position Hold, waypoints, geofence and all sorts of other great tricks but as such, none of these functions are guaranteed to work from the get go. They require testing and involve RISK.
People also need to be reminded that FAILSAFE does not work properly and should not be relied upon. That in itself is the subject of another conversation. APM in its current hardware configuration has serious issues with that, flyaways, random arming, failure to disarm etc... etc.... The members of this site, your customers, this community, rely on you and your peers to make sure that all of this can be done in a safe manner. Selling APMs like hotcakes is cool, selling a safe, fun, reliable and properly tested product is even cooler. My two cents worth.
You guys have the capacity to make something great, you have the resources, basically everything you need to make magic, focus on quality, not numbers. If you have the quality, the numbers will follow.
Chris, is it easy enough to re-port the TradHeli stuff to the new site? A number of us did a whole lot of changes to the old wiki pages, not knowing that the new pages were actually being worked on. If you look the old pages have been almost completely revamped, with user submitted imagery as well.
-
1
-
2
of 2 Next