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
>Forking and no enhancements. To do this you need fixed hardware and we pretty much
>have that for APM 2.X. I am not seeing any interest from people to make commits to fix any
> bugs or take responsibility for the massive amount of testing required before each release.
Do you suggest any APM based build should be operating on 2.x firmware only?
It is really a sore topic. It is understood that new features and functionality may not be available on the older platform, but when we talk about safety features, an ability to do a kill switch and shutdown for motors and all this is coming to 3.3 _only_ and 3.3 is not going to run on APM - what all the people who have APM powered builds are expected to do?
It is directly the topic related to safety and reliability as it is. If it is a general statement - any APM build will never be reliable and safe as it will never have an updated firmware to address any existing issues - then it is has to be formalized and stated as it is.
As of an example of 'bug' - inability to shut down craft`s props when it crashes and destroys property around itself is a bug. How am I expected to fix it on my APM powered build?
By removing APM and installing PX4 with 3.3 only? Is that an official position?
Hi Paul Atkin,
I realise that pilots that only fly in Alt Hold and Loiter may not know this but you can shut down the motors using Stabilize and zero throttle if you set mot-spin-when-armed off.
So if you believe this is an important issue then you have all you need to fix your problem. That combined with a buzzer to warn of motor start up and you are as safe as you ever were.
As for you question: "How am I expected to fix it on my APM powered build?"
This is easy. You add kill switch code to the APM code base. You either do it very efficiently or go through the code to save enough memory to make it fit. You then spend a few weeks flight testing your code. Then you get 20 or 30 other APM users to flight test your code. You fix any problems you find then we can do a new release with the features added.
This is time consuming but I can see you think it is important.
And just to clarify. A bug is when the code doesn't work as it is intended to do. Fixing a bug is when you make the code work the way it is intended. Adding a feature is when you make the code do something new that it didn't do before.
Perhaps this is something that follows cycles. For instance the move to 3.2 was a big one and involved many new features and improvments. And these are necesary, to compete, to provide long required safety features, stability etc.
But once a major move has been made, time should be taken out to clean up all the details. For instance, poshold was a great new feature, but other than making life "somewhat easier for newbies", it's practically useless for serious photographers. It's twitchy. Well that's just one. We are all content with the new features so we "get used" to slight defects. It's understandable that things are "never?" going to be perfect. But while it's fine to brush over the slight imperfections initially to move ahead, we shouldn´t leave them there forever, carrying them over into each new release.
If we use poshold as an example, as I said its not the only one, we kind of shoot ourselves in the foot. This was a feature that went directly at the competition. Loiter didn't compete for photography. So now we have it. But I know at least one professional in arial photography that won't use 3DR because of the poshold / loiter issue.
I of course agree with most here, that the developers are doing an incredible job. But since the question was raised, I understand that you see this as an opportunity to "see" a larger vision of what is needed in terms of development.
Right now is a good time to put a slight hold on advancement and clean up the great work that we've got to this point. It's really not a lot, but it would make a lot of difference... to have a good clean, solid unbeatable product.
Thanks for the question!
+1
Maybe one thing to consider is alternate releases - features vs bugfix/stability
Yes, we could do that, but at the cost of cutting the total pace of development in half roughly.
I think this is kind of what beta firmwares are for. New features that may have bugs/stability issues, but, allow users to test them knowing there is a risk. While stable versions have the features that have been out for a while but have been well tested by beta users.
Hey David,
Thanks for the feedback. I think this is one of the only real bug/fix issues that have been raised here.
I have two questions I would like you to explain to me if you don't mind.
1. You said that Loiter didn't compete for photography. What do you mean by this? Loiter is very smooth and predictable and you can make very fine adjustments in position. It would be great if you could explain further.
2. Can you go into a little more detail about your issues with PosHold.
PosHold is one of the few parts of the control code that I didn't design and I don't think it has evolved since it was first introduced. I have a plan to improve it (twitch free shouldn't be a problem), however I am not a fan of this mode concept so I don't use it myself. Any help you can give me to get a better idea what people really expect from this mode would be helpfull.
Hi Leonard,
I seem to remember that among the claims of poshold, was it's abibility to close the gap between Loiter, and the parallel funtionality the DJI offered. I'd really have to go back and search the files to get the details, but the main drawback to Loiter was that it was too slow in re-positioning. If you wanted to get from one shot to another you had to switch to some other mode, reposition and then back to Loiter.
I had Loiter out of my switch combinations until just recently. I decided to put it back to re-familiarize myself with it. As you say, I think it's much better for taking shots, it allows a smooth run from beginning to end of a sweep, much smoother than poshold anyways, although now that we're discussing it, perhaps I should give the two a real hard test.
I'm not a photographer though, but the problem with Poshold seems to be around the "hover envelope". For instance, I think it's fine "on the run", works like alt hold and seemingly without twitches. But from the breaking phase on there are problems. Transitions seem to twitch. Where this is really obvious and complicated is close to hover. As external forces tend to move it around, there are audible clicks and twitchy movements as it reacts.
I haven't looked at it, but my impression is that these twitches occur as it transitions from sub-mode to sub-mode, and the transition point is quite close to "hover".
I thought for instance that the autotune and/or feedforward settings were at fault, but I removed or softened those down to where the machine is overly "sluggish" and the twitches still show through.
As you suggest, I really think that it should be easy to fix, one or two hours and it would be ready. I was even thinking about giving it a go, but just haven't been able to get the time. (I did see a couple of "switching times" in the software, some of which seem a bit short, but I didn't get much deeper than that.)
I think that most of the little things, that could make a big difference in the overall stability and confiability are small and could be managed "fairly quickly". There's just a lot of them I know!
The photographer I mentioned has taken a turn to 3DR in the last little while. He has a little help on this end from a few of us, and I think he generally likes the Pixhawk and where it is going. But he commented about poshold the other day, and refered to his DJI in the process. I think the clicks/twitches were scary for him. It's those small things that influence those snap decisions on someone who has a long and hard day in the field and needs something that just works, now.
Priorities up to now have put many of these small things on the back burner. Perhaps now is the time to turn up the back burners for a bit.
I'm a really big fan of 3DR, and it's painful to see someone even looking sideways at something else.
Thanks for all your excellent work BTW.
I just came back from another test with my X8 and 3.2.1. I started by taming down the gains, they were at autotune values from a 3.2 autotune.
This test was with standard X8 gains plus ATC_ACCEL:RP_MAX at 72000, ATC_RATE_RP_MAX at 18000 and ATC_RATE_Y_MAX at 9000, which are all fairly tamed down as well.
The twitching was negligible, but unlike the IRIS, I could see it pitching and rolling (as you would expect) as it tried to keep itself over the hover-point. These were the points where it used to "twitch".
After the initial autotune, the X8 was quite crisp, and while I liked it, it was like too much honey, so I tamed it down, mostly with the ATC values. Then for this test, I tamed it down quite a bit more with the PID gains.
What it seems like, is that when the gain is like I like it (for feel and responsiveness) it twitches in poshold. The twitches seem like transients, getting through, even being amplified at the fairly fast transitions to maintain position.
When I turned off feed forward during tests before this test it improved, but the twitches were still quite pronounced. FF was off as well for this test.
I feel as though these transients could be softened without overly affecting the solid response that poshold has to maintaining position.
Being that I was working with standard PID configurations and settings, the loiter response was extrememly sluggish. The speed is turned down. I'll next do some tests in an effort to try to improve it beyond the previous IRIS loiter response.
Once I've got it tuned in a best possible I'll load 3.3-rcx
Again, zero wind for today. Why is it that when you want wind you can't find it?
Hi David,
Thanks for the feedback. I will be interested to hear your thoughts as you continue to experiment with these modes.
Stopping in Loiter: Loiter doesn't break when you let go of the sticks. Loiter is an artificial Stabilize mode. So like in Stabilize, if you let go of the sticks you drift forward and slowly stop. To quickly stop you need to pull your sticks back in the opposite direction, just like you would in Stabilize.
Yeh, I agree that Loiter got a bad rap when it was first released. This was when the devs/community was only just starting to get used to relying on Auto Modes for fast flight. So the defaults were set to something like 7.5m/s (I was running around at 20m/s). Many people never took the time to turn up the maximum speed and didn't realise it felt much better when it was set closer to the natural maximum speed of the copter.
PosHold: Thanks for your feedback here. You may be correct that wind brings out a couple of problems with switches between sub modes.
Just to give you an idea of how long I would expect it to take to make the improvements I have in mind. I would take a day to fully understand how it is done now. A day or two to formalise my design and run some simulations in matlab to make sure all internal transitions are smooth and I have the maths correct. Probably about 2 days to do the coding and basic test flights to make sure each bit works as it should. Then there would be a half day with Randy to make sure everything is coded correctly, optimised, commented, properly integrated. Then Randy and I would start running tests both in SITL (simulation) and in real life to make sure the feel matches the old version (and look for problems). Then it would go into master and the flight test crew would start to give feedback. Hopefully this wouldn't be too much at this point but it generally results in a couple of edge cases or tweeks, say another day of work over a couple weeks. Finally it goes into a release candidate and onto formal release. And that would be if everything goes to plan....
Thanks again for your feedback!!
-
9
-
10
-
11
-
12
-
13
of 18 Next