Warning #1: PX4/Pixhawk users upgrading from AC3.1.5 (or earlier) may need to re-do their compass and accelerometer calibration because AC3.2 also uses the backup compass and accels. Pre-arm checks have been added to ensure this has been done.
Warning #2: on the APM2.x the logs must be downloaded using MAVlink instead of the terminal.
AC3.2-rc14 is now available for BetaTesters through the mission planner’s Beta Firmwares link. The full release notes can be found in ReleaseNotes.txt and changes from -rc13 can be seen below.
Feel free to raise issues found during testing on this discussion or in the new support section in the APM Forum.
It’s a big release with “the onion” restructure and a bunch of new features (including these 57 closed items) so we need to re-test almost everything including all flight modes, all mission commands and all the new features. Marco and I will be maintaining (and adding to) this testing list. Issues reported will first be checked by Jonathan, Marco and I and then confirmed bugs/issues will be put on the github issues list (and then hopefully fixed).
Thanks especially to the beta testers who put their copters at risk testing each release. Enjoy!
Changes from 3.2-rc13
1) Safety Features:
a) fail to arm if second gyro calibration fails (can be disabled with ARMING_CHECK)
2) Bug fixes:
a) DCM-check to require one continuous second of bad heading before triggering LAND
b) I2C bug that could lead to Pixhawk freezing up if I2C bus is noisy
c) reset DCM and EKF gyro bias estimates after gyro calibration (DCM heading could drift after takeoff due to sudden change in gyro values)
d) use primary GPS for LED status (instead of always using first GPS)
Replies
An explanation of the dataflash log output is in the following document. http://copter.ardupilot.com/wiki/downloading-and-analyzing-data-log...
Thanks.
Seems an incomplete document at the moment. INAVErr has no reference.
Others do, looks like the CPU load is high maybe.
Martin
Ah, I posted the wrong link. The log messages generated by the EKF is detailed at http://planner.ardupilot.com/wiki/common-apm-navigation-extended-ka...
Well, quite a bit of the detail in that first Wiki link is outdated, it hasn't kept up with the changes in MP. And now this new set of information is off by itself in a separate location. I wonder when 3DR is going to start providing usable organized timely documentation for their products so we end users don't have to pester each other or bother the Dev Deities every time we have questions or problems (and sit around waiting for answers that may or may not be forthcoming). It's a disorganized mess as it stands, unsearchable and scattered. For a short time it seemed to improve, but that apparently has stalled since Gary M. stopped writing/editing the Wiki. As we transition to the Pixhawk and to 3.2 with scads of new features it's going to become even more critical. The most brilliant hardware/software on the planet can become nearly useless (or worse) if the instructions aren't accessible and clear. One would hope that this is an overriding priority for whoever is in charge of the basic business side of 3DR, and that major, much-needed improvements will be made soon.
yes, i have it on my list to update all the docs before the official release to reflect the changes that are going into AC3.2. It's a bit tough to balance everything at the moment. The AVC competition is also taking a fair bit of my time as I plan for my copter to pop those red balloon.
Oliver, perhaps you're unaware of this, but 3DR doesn't make either the software or the wiki (we only donate funds to pay the costs, as part of our contribution to the community). They're both built and maintained created by volunteers in the open source community here.
If you'd like to participate in helping improve the wiki, please join the wiki editors group here.
Hi Chris
Thanks for the DIYD and APM communities that you've helped to create. The hardware and the software is truly awesome!
I'm a newbie to all this but fairly tech savy and have recently built a flamewheel quad using 3DR pixhawk/radios/gps. It's taken me two solid months to get reliably flying (and got through a lot of props/arms in the process) and the only reason I've got this far is because of the wiki. The 3DR products would be near on useless without the wiki and the 'community' sites - the 3DR product documentation for these products is next to non-existent. I've had to make repairs to broken wiring using documentation from the pixhawk/apm sites and work out how to connect (official) peripherals using community documentation. If these didn't exist, I would have had no choice but to send these products back as unuseable paperweights.
The 3DR support is very confusing as well to newbies. It took me quite a while to work out that ardupilot.com is really a 3DR website and the place for official 3DR support, and diydrones is more for the opensource/community/dev side of things. 'Sponsored' is really a euphemism given the control over the site, content, software and forums by 3DR - it is a 3DR site in all but name. And the official support here could do with some improvement, from a customer point of view - I've felt quite frustrated at times especially when for example the radios only worked for a day or two and it's taken a month so far and waiting to get replacements.
Perhaps making things clearer, with a clearer separation would reduce some of the confusion.
Keep up the great work, I'm really looking forward to some of the innovations that you're helping to bring to market like the lidar.
Chris, I'm aware of that. I'm also aware that if it were not for the open source community you would not have any products to sell. That's fine, but at what point does creating and even (gasp!) paying for proper documentation become in your best interests, if not outright your responsibility? I own a new Ford Focus ST with a full electronics package. It has a Microsoft badge on the dash. It comes with a very good professional manual created by Ford, not MS. My point here is that apparently development has become too rapid and dynamic for a scattered approach at documentation. So without a professional being paid for the job, and with the one volunteer who really had his teeth in it sent down the road, it's left to the developers themselves to try to somehow conjure up documentation? Randy's comment below shows where that's headed.
As for participating, I'm tying to do that here, but to be blunt I wouldn't want to be subject to the same things that happened to my friend Gary M. So no, thanks.
Oliver, we have a team of professional that make the 3DR hardware documentation. It's all here and I think you'll agree that it's quite good.
We also donate one full time professional to helping out with community software documentation (remember, we don't make the software ourselves, so this is just assigning someone to help out the community). I agree that it's not as good as it should be, and could probably use a team of perhaps five full-time professionals, on top of the volunteers. But given that we already donate more than a million dollars a year to the open source dev teams, this starts to get very expensive. And of course the cloners don't contribute a penny, although this benefit them as much as it does us.
In short, this is a very big job, and 3DR can't do it all alone. That's why we're helping set up the DroneCode Foundation, to properly fund and manage these sort of big projects, including combining forces with other companies in the ecosystem to subsidize the community.
I decided to participate in this thread because I too have serious concerns about 3DR's approach to managing the intersection between an open source code base, and your own commercial product distribution and documentation.
Upfront, I absolutely say bravo to you for your initiative and success in building this brand. I'm 100% behind your efforts! But to be blunt, I fear you may lack the software engineering background you need to fully appreciate these issues.
While I do think Oliver's frustration is coming through in his posts, and perhaps is a bit out of place in a beta thread, he's quite right that 3DR's approach to commercializing an open source code base is entirely, technically speaking, half-ass.
Please go see, for example, how Barracuda manages its use of the Freeswitch telephony project in its Cudatel commercial offering. You won't find them sending people off to the Freeswitch IRC channel, or suggesting that, actually, it's the community's job to provide in depth documentation of things like you describe in the disclaimer (Important Note) at end of the quick start guide.
So, as much of an improvement as the current "quick start" guide is.... A "quick start" guide is not remotely sufficient in the documentation department, pretty much by definition, and no, I don't agree, at all, that your documentation is 'quite good.'
But beyond documentation, You must create a degree of separation between your published and approved versions of the software, and the underlying trunk. You must have competent developers to make decisions about when to advance features from the open source trunk into the released products, and you must have competent technical writers to maintain the related documentation. I gather you don't, or that you (the manager) fail to assign enough resources to the task.
That's not to say folks shouldn't be able to use other branches at their own risk, but that you need to have a sanctioned, conservative, release that you maintain, thoroughly document (read, accuracy and continuity), and have qualified confidence in.
Yes that means added liability. And yes, that's a necessary cost of your business because not doing so creates its own liability in a critical human-factors product. In short, if you're going to make things that weigh several pounds and fly, and sell them to consumers... You need to up your game in this area.
Finally, and this isn't meant to sound too rhetorical, but didn't you just raise $13M? My advice... Don't get out in front spending that on marketing, because you can't handle a flood of new consumers in this situation. People are going to get hurt, and fair or not, you're going to get blamed. Perhaps not as reckless as flying drones into trees at nuclear facilities, but you get my point.
I hope I don't get overly flamed for this post, and it is just one guy's opinion. The real point is, this an advanced hobby suited for those of us with the engineering perspective (and patience) to engage in and respect the risks involved. If you want to sell to consumers, you need to take more responsibility for educating and protecting them (and bystanders)from themselves and your products. That means documentation and code control. Perhaps your counsel disagrees with me on this.
Yes, it's a big job, and as a commercial venture promoting it for profit, you need to own it and not pass the buck to the community of uncompensated developers making 3DR's business possible. I read what you said about donating to the community, and that's laudable. But it doesn't cut it.
Thanks for listening, and I hope you receive this as the positive criticism it's meant to be!
Best Regards,
Erich Greenebaum
-
351
-
352
-
353
-
354
-
355
of 373 Next