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
In regard to loiter - I had this only once, but there is a condition where while in loiter you suddenly lose GPS or GPS sensor gets blocked by an object - drone moves extremely erratically, probably due to sudden distortion of GPS data feed and wrecks havoc to all around it.
I had literally throw my radio at it and knock it down to the grass where it continued to engage props at 100% power (with me having all throttle cut on the remote) and destroying grass for at least a minute until it finally gave up and shut itself down acknowledging 'crash'.
It was all on 3.2. version on APM, so, not sure if it applies to the discussed scope, but, as I intend to keep this APM FC - I really wonder if any of those proposed safety measures will be retrofitted into previous APM compatible builds?
I had problems with 3.2.1, so I really wonder about 3.2 here, specifically.
I'm sure my X-8 is worse with this, and right now it has 3.2.1 on it. My IRIS has 3.3rc5. So I'll test with the same firmware on both and try to get the parameters as close as possible.
Sorry about the Loiter braking comment. I haven't used Loiter in a while and forgot that it doesn't have braking. :p
I'll test with 3.3rc5 then. Seems to work well on the IRIS.
Though Loiter *can* have braking. Just set WPNAV_LOIT_MIN_ACCEL (or something like that) higher than the default of 50. I've run 2-300, and it stops quick. The only problem is, it behaves well from a high speed. But I find it becomes over-reactive when making small movements at low speed. It tends to bob around.
To be honest, I just came back from a short test (6 min) comparing poshold and loiter.
Everything worked perfectly!! Go figure?? It's a pretty calm day though, it's incredible what a bit of wind can do.
I'm using 3.3rc5 right now. Since I really haven't "specifically" gone out to test poshold in a while, I couldn't say if it's only with 3.3rc5 that its better. I mentioned poshold here though because only a very short while ago I saw the same twitchiness. like last week or the week before.
I'm going to keep looking, it's got my curiosity up. Maybe a little more wind takes it over some kind of a threshold.
In these tests BTW, the loiter stop response was a little sluggish. Even slowing from 4 km/hr it took a whole 6 meters or more, while poshold brakes nicely in about half the space.
The only other thing I saw was that tendency to drop a meter or two on horizontal runs. That airspeed bubble effect. I know that's a toughy, but would nice to get rid of it somehow.
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.
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.
-
10
-
11
-
12
-
13
-
14
of 18 Next