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
The telemetry is not compatible with our XRF's apparently. My colleague would be better suited to respond to this, as he is the one that tried a pixhawk, but he is away at the moment with a family crisis.
He also had issues with the receivers and using the spektrum telemetry. Again, I can't comment as I was not involved, just repeating what he told me.
It certainly caused him several headaches trying to set it up!
Hi Randy - my 5c.
Firstly, thanks to you and the merry developers for your selfless efforts.
I use the copter, plane and rover code from APM2 through Pixhawk. I would prefer rock solid simpler software than programs with many features that still need to grow out of it's aches and pains. So for me, in order of priority, sorting bugs (80%), safety (15%) and new features at 3% and gardening the balance.
Thanks,
When losing one motor on the X8, shouldn't it be enough to throttle down exactly one opposite motor? That means we have lost 2/8 (25%) of power, not 50%. But probably we need the ESC feedback here to find out what motor has failed.
Overpowering the copter by 100+x% works nicely (I do that currently for certain purposes), but it is far away from an efficient drive setup. Additionally, it causes other strange effects, like trouble with the landing detector during some maneuvers (e.g. during braking from high speed flight while maintaining a slight descent - certain motors may reach min throttle here).
Hi Holger,
You are correct. Because we don't detect a sick motor and we have a fixed mix for each rotor setup, we get a 50% drop instead of a 25% drop. We may not need to detect which motor is sick to get that back but we would need to add a bunch of complexity to the system.
We have improved the landing detector a great deal and it won't cause trouble like it did before.
I don't understand this. If a coax eight is being treated logically as a four motor quad then wouldn't that mean if one of the eight motors failed it would be the equivalent of a quad with a motor dropping to 50% power? In that case wouldn't the opposite motor just match that reduced power?
I doubt many X8 copters with payloads will hover at 50% which essentially means that you have lost the advantage of redundancy. Is that correct?
I did throw a prop on my X8 once and it flew totally normal. But it didn't have any payload at the time.
Hi Darrell and Holger,
I have got out my matlab and been a little more through with my matrix calculations.
Hover throttle will increase by 25%.
Maximum lift will decrease by 50% but if we could detect the motor using the existing mixing with a small modification to the motor matrix the maximum lift would only drop by 33.333%.
If we were able to calculate the optimal motor mixing after a loss of 1 motor we would lose a minimum of 25%.
So Darrell, you are correct. A heavily loaded X8 doesn't have the redundancy people might think. It doesn't get any better for a standard octo though.
A Y6 loses 66.666% of it's lift without detecting a motor out and 50% if it can detect the lost motor.
I got an Octocopter off the ground with 3 motors disabled. But barely. With 2 disable, it flew well, of course, the two motors were strategically selected. :)
With only a single motor disabled, you would be hard-pressed to know anything was wrong. This was a moderately loaded copter, however, hover throttle around 50%.
Randy, you already know what my answer would be: safety + bug fixes...and they go hand-in-hand hence our weird hybrid that has some things dating back to v2.6). Can't do one vs. the other if you want consistency and predictability when something unexpectedly happens in the air.
I think the team's current 3.2+ feature set is future proofed for the coming year from my point of view. One thing to keep in mind is if you proceed with bug fixes as top priority--APM2.x support will likely be impossible--assuming that typical optimization (usually a result of bug fixes) typically creates even tighter coupling to the hardware [e.g. the newer 32-bit boards].
Another question you can ask is how big of a monolith do you want the APM core (not necessarily ./libraries) to grow? Same challenge the linux kernel, mozilla, and other F/OSS projects...
It would be great to have some new people come forward and offer to carry on supporting the APM series of boards.
After some years of experience with ArduCopter, I would characterize the reliability aspect of ArduCopter as good, while the functionality aspect is outstanding (IMHO).
When looking at my past crashes caused by ArduPilot (about 10 or so in about 200h of flying, not including any pilot-induced stuff), these fall into two categories:
1. Failure of components, especially drives
A nice long term safety goal would be to detect faulty drives or other components and to do the best to achieve a safe (or at least as soft as possible) landing. ArduPilot is here far from the point that is theoretically possible with a given number/layout of drives. That would require that ArduPilot is able to detect drive failures reliably, which probably needs real two way communication between ESC and ArduPilot (we already have that with UAVCAN). The next step would be to give up control functions in a prioritized manner, e.g. when necessary to reduce the sink rate. Currently even an X8 crashes rather hard when a single drive has failed, due to the fact that ArduCopter seems to prevent uncontrolled yawing at any cost and therefore reduces throttle way to far instead of allowing a certain amount of yawing.
2. GCS-related crashes, e.g. due to a GCS that had trouble with number format handling and sent a P, I or D value that was 1000 times to large.
Unfortunately, these crashes seem to be a thing that is repeating again and again, with different GCSes involved. Of course it is primarily a fault of the GCS used that allow bogous user input, but I think ArduPilot could do more parameter range checking and/or cross-parameter checking than it currently does. Rejecting obviously wrong parameter values would be a huge safety/reliability improvement IMHO.
-
6
-
7
-
8
-
9
-
10
of 18 Next