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
Hey Devs all your troubles are over I found the perfect compass LOL Sorry... couldn't resit. But speaking of compass... ever since I turned EKF back on and waited for at least a few sats I can no longer get DCM bad heading warning. I am still on 3.2... Turning EKF back on DEFINITELY had a lot to do with no more warnings.
Great Richard :)
As a commercial drone user, it is paramount that the software is stable, works as advertised and safe. It is really irritating to have to go through an almost total reset when the software changes. As a result we don't upgrade quickly, but instead wait until it is a very tested stable release!
I think you guys do a terrific job at the programming, but am not looking forward to changing to a pixhawk, which we would have to do for any new releases. We tried it with one drone and ended up going back to an APM 2.6 to get back our telemetry functionality, which isn't supported on a pixhawk apparently, among other features.
But keep up the good work guys :)
Could you be more specific. All features available on the APM are available on the Pixhawk. The inverse is not true.
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.