In my view there is quite a difference between revisions of a mature system that's been out there for years and revisions to develop functionality. It wasn't long ago that the APM code didn't have issues with vibrations. Until they implemented code that worked like other controllers. Then the users were totally caught out by vibration issues. It wasn't that long ago they discovered that light and heat on the baro caused issues. They wrote code to deal with that. It wasn't that long ago they had issues with possible fly aways that they determined could be from GPS glitches so they wrote code to deal with that. They really added a lot of sanity checks. Now they are going further and going with dual sensors etc. It's' all very impressive.
To be clear, much of these issues are actually hardware problems, not software. I'm not sure what "not long ago" is in this environment, but AC2.9, which is what brought out inertial alt-hold and started the vibration problems, is about 2 years old. And it's not even correct that to say that Arducopter never had vibration problems before that. You may recall the term "the leans", which was something that happened under heavy vibrations, and was a problem all the way back to when I started 3 or is it 4 years ago?
The root cause of this is that 3DR never understood the need for hardware vibration damping, or wasn't able to implement it. This left users to figure this out all on their own. The changes to the code which made the need for damping more critical did not cause the problems, they just exposed the fact that 1) The APM needed vibration damping, and no solution was provided by the hardware maker. And 2) many people had copters that are built really poorly, and vibrate really really badly.
The problems with the baro, are again, hardware problems. The chip OEM promised the chip is insensitive to light, but obviously that was not the case. This necessitated the system be designed to shield the baro from light with a proper case. Again, not a software problem, but a hardware problem. And software did not fix the problem, other than that it now ignores the baro if it thinks it's gone really bad. That is not a great solution, rather more like a band-aid on a shot-gun wound.
I think if Randy and Tridge were on this forum they would be the first to say that the APM/Pixhawk has been a very fast development project. Apparently it's been going for about 5 years with about 50 people contributing to the code. But it didn't really take off until about two years ago. By comparison DJI and others had software out there actually flying copters for commercial systems earlier. Like it or not, they were ahead and worked out some issues long before 3DR even knew what the issues were. That's just normal.
Even longer than that in fact. I would agree that it didn't really get good until about 2 years ago. Not coincidentally, that is about the same time that Randy and Tridge started working on it full-time. That's when it turned a corner. They didn't do all the work, but have been able to check the work of others to make sure that it does not bring in new bugs, and make sure that all the bits that people are working on play nicely with the bits that other people are working on.
However, it has now gotten to the point that I believe the project has outgrown it's current organization. It's too big for two people to manage. Arducopter in particular is moving very slow, something like 6 months (or is it approaching a year?) between stable releases. I don't know what the solution is, but something has to change. There's recently been an announcement about this "Dronecode" thing, which is intended to move Ardupilot out from under 3DR's umbrella, and make it it's own entity. It should help to attract funding from more than just one source (3DR). But I have no idea what is really happening with it. There's been almost zero information about this, even amongst the developer group. From what I can see, it's only created even more work for Randy and Tridge, as now they have to manage this organization, while also managing Ardupilot. With no extra resources at all, at least from what I can see. I hope that this can be sorted out soon. When the Dronecode announcement was made on Monday, it was claimed that there are 1200 developers. This is a gross overestimation IMO. I can't think of more than 12. Actually, I can only name 6 people seriously working on the main body of code, with me being one of them. There are maybe 50 or so doing various things, including porting the code to run on other hardware, etc.
I recently had to make the very difficult decision that I'm going to have to quit the group. I've been heavily involved for 3 years now, and over the past 12 months devoted every minute I could to the project, every evening, weekend, and even my vacation time. My family and home have suffered from neglect. I've been trying to figure out how to get in a position to leave my day job so I can work on it full time, but I just haven't been able to put it together. The disappointment includes $4000 in unpaid work by one company. And I can't just keep doing this forever, meanwhile Richard Branson and whoever else gets to profit off the project that I've helped create. It really sucks as I feel like I bet the farm, and now am folding. But I can't just keep doing this forever, my kids are complaining about daddy never being around... while I watch multi-million dollar companies selling hardware with a program I helped build.