This is a discussion related to the Copter development priority debate that popped on the Copter-3.3 beta testing thread. A quick categorization of the things we work on in each release include:
- bug fixes (i.e. fixes to existing features that have a defect)
- safety features (i.e. new features that improve reliability)
- other new features (i.e. non safety features like landing gear)
The basic question might be, "are we spending too much time on new features, time that should instead be spent on bug fixes or safety features?". Let the debate continue!
Replies
Yes, Thank you all. tremendous effort! Agree with David, Yes ++ on the "bubble of death" effect. I remember you we're doing a lot of troubleshooting with this a while back but everyone else seemed real busy and it never really was resolved was it? I was also and got it somewhat mitigated by making a full blown canopy with tweaked tuning and settings that were recommended here but could never get rid of it. I go out and fly a similar type / size / weight quad as the Pixhawk with a NAZA and am disappointed because whatever they have done it does not exhibit this behavior. the Inspire is even more solid at remaining level, so much so I hate it as it acts very much like an air hockey puck and is easily pushed around but the ability to maintain a steady and level altitude is impressive.
Not so fast. This entire thread is about the DJI A2 doing the exact same thing.
http://www.rcgroups.com/forums/showthread.php?t=2300970
Some of them are actually talking about coming over to Pixhawk. I tried to explain that this is a physical problem, not programming, and we have the same problem, but they are unconvinced.
Yeah, this is indeed complex and not to say the other systems don't have a whole load of other problems and outright deficiencies as contributing factors. My generalized observations are that when my frames got to the 6-10 lb weight range at around about the time the copter code was version 3.?.? Shortly after Pixhawk came out maybe in February -March that year running 3.1.2 - 3.1.4 -ish? The behavior became real apparent.
Rob, since you are the heli person it may be a rabbit hole but I've been wanting to ask someone who might know something about this:
I've noticed the I1 has the very same characteristic of what I call "bobbing" up and down in their alt hold type mode (separate from weaving side to side as course correction) very similar to what I observe the full size Apache's and Chinook's perform in forward flight, especially in cross wind. I'm not a helicopter person so I was wondering if this is a characteristic of a pitched blade system making pilot or mechanical lift compensation or loosing it in cross wind? and is it due to just the way they have tilted the Inspire rotor configuration that mimics this from a full sized pitched blade craft or if is actually a carryover from some code borrowed from the first controller they developed which was for heli's? This is probably wayyyy off topic, sorry. The control routine, whatever it is and I'm guessing is not all that complex, seems to be running an observable correction for altitude error I don't observe with the PixHawk or in smaller, lighter, higher rpm systems were it is maybe not so obvious from just visual observation.
Hi Steve, sorry, I don't understand the question at all. I doubt there is a single line of code in the I1 controller that came from the Ace One.
Ahhh-Haaa. Great! So it behooves us to be the first to resolve this.
My bigger X-8 behaves similarly to the video they show there. All very familiar. I did manage to improve it with some adjustments, but just got it down to 2 or 3 m drops. They highlight the X-8 frame, but my IRIS does it as well.
I fully understand Leonard's position about the complications of the software approach, but my feel was that although it isn't easy, it's easier than expected. There seems to be a quite predictable response given a couple of measurements and some calculations. I'll have to dig up my work. I really would LOVE to work on this, but am crazy to find time these days.
Meantime, ANY solution would be extraordinary. The problem is debilitating, at least in the close in "manual modes". For some reason, in auto (or in longer "manual runs") it recuperates the altitude. (By manual I mean poshold, loiter and althold)
We can fix this, I know we can! :D
Why not low-tech? Simply add altitude at a fixed rate for forward movement. I'd much rather my copter gained 2m than lost 2m.
It's really quite a complex issue (nonetheless important).
The theme was looked at fairly intently. In the end investigations basically proved that it IS an aerodynamic effect of pressure modification in a bubble around the craft. One would think that "knowing the dynamics, it should be resolvable in software. I actually did some experimentation with software, but due to limited time resources, the approach was one that just permitted to see if a software approach could be feasible. It was not intended to be a solution.
The result of that investigation was, "yes" it should be feasible. My software mods showed that it was possible to flatten out the pressure anomolies, however there were many corner cases which would have to be handled. A copter has six degrees of freedom, and each one has different distortion parameters. What I "developed" permitted flat movement in about 80% of the cases, but may not be similarly effective for other physical congifurations.
I felt that a properly designed EKF of the situation could manage it though. But I didn't have time to go any farther than that.
A second solution would be physical, and probably easier, an external static pressure sensor. However, such would also be subject to differing physical configurations. My preference would be to resolve it in software. Once done, it would be done! No extra hardware to fail on an already increasingly complex machine.
The fact that other machines have resolved the problem shows that it can be done.
BTW, since we are an Open Source solution, and therfore applied to a large range of physical configurations, it isn't the same as resoving the problem for a particular model like a closed source manufacturer can do. We would need a solution that is generically applicable.
Hi David,
I am not convinced that we can solve this problem effectively in software. However, if we could it would not be just done. It would require a very large amount of tuning over more than 6 axis because each axis would have a non-linear velocity component.
I have a number of boat cooling tube outlets that I am going to set up to test as static ports and see how much better I can do. I have seen one other person do this and reported great results.
I personally believe that a simple static port would be a fix for everybody that chose to use it. However, I need to do more work to check it for myself.
As to why NAZA is reported to not have such a significant effect. I suspect this is because of their package design. I would be interested to see naked board in the same airframe back to back.
You guys are doing great job! I would simply say if while developing the next beta and you fix a known issue no matter how minor please take the time to go back to the last stable version and implement the fix with a note in red [ like I have seen you do sometimes ] to indicate people flying that version might want to re-flash for an even more stable version. Maybe even have a place to enter your email if you wish to get updated info if there has been a change to that FW.
Might want to have a larger section in the wiki [ but it's WAY better these days! ] about troubleshooting that could go hand in hand with error messages saying things like, " Please see compass troubleshooting" or "Please check esc low voltage troubleshooting " Instead of a more technical description of the error that might not be as clear to the user what the issue is. That might reduce the amount of posts looking for answers. If you haven't noticed it can get a little cluttered :]
But I salute you all developing this my quad flies amazingly SMOOTH yet aggressive when wanted. Very very good flight control FW!
I still contend that reliability is everything becuase a system with wonderful state of the art bells and whistles that crashes all the time is not useful but...
I have been pondering this question further and reading the responses. One of the major problems is that of separating software bugs, hardware bugs and operator error. In monitoring the forums this takes up a lot of time and effort. Unfortunately most of us are not in the market for mil-spec equipment. That leaves us with lowest cost competition with probably a lot of cost cutting and seconds. Just the reality. So it is hard to have a discussion about reliability of software without dealing with the hardware problems. 3DR is in the position of influencing the hardware. The whole of the opensource apm/pix hardware world is not controllable but if 3DR were to consider making an equavalent of a "Tuned propulsion system" where the FC, Rec, ESC's were all designed to go and work together. Then maybe the third party folks would be copying it. Users would certainly be attracted if it improved their chances of a successful build. Think about eliminating as much of the hardware problem from the equation to make it easier to separate the issues. Lets get rid of Dupont connectors in favor of a connector that can't be installed upside down! Lets get rid of bullet connectors in favor of a locking connector. Define the system and it's connectors from one end to the other.
Work in everyway to limit the operator error by having levels. DJI gets by because they don't offer options. But instead offer basic, advanced, expert views to reduce the bad setups.
What about a blackbox to record flight data and off-load this from the fc proc. Full logging all the time with all the memory needed and any user that buys it and plugs it in can have his build troubleshot without having to go throught the time and efffort to explain how to turn on the logging, how to download it and analyse it. No cards to install, self-contained. Plug it into the FC, after flight plug it onto the PC an APP gets the logs, transfers them into a database for query and analysis. User doesn't have to know anything about it. But if they want help they need to buy it an plug it in. Dev's can go look at the historical data, captured the same way every time.
Thanks for making this project available to common folks like myself. A few brilliant people dedicated to this open source project are changing peoples lives all over the world. Sure it is not world peace but it is very important to me and I am grateful to the dev team.
-
12
-
13
-
14
-
15
-
16
of 20 Next