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
Me too, but many users will, appreciate the graphical display than the "browse log", which i haven't yet figured out why continues to reside in "Terminal" in the Planner, would require a "dedicated log section" (download, clear, view, convert, etc.).
In some situations it's very comfortable "see the drone flying", while viewing such as RC-IN and other things, is much more intuitive to see what happened, if only for the reason that you see the drone on the map and the HUD with a lot of realtime information, more intuitive.
Most users don't know how how download the log... ;-)
For me (unexpert pilot) it's easier to know what happened during a fly watching the graphic logs where you can see the hole fligth in only one graph,I hope it's more noticeable when something went wrong for an untrained eye, It's very usefull for me the instructions sections where you show with graphics different common issues or when devs and others explain issues with graphics too and not only the comment, but, sometimes it's usefull the tlogs too or the klm graph to understand what happened, ej, the exact position were the things become wrong. Logs It's an impressive usefull tool to fly safe after a crash or sometimes to avoid the crash.. Perhaps more complete instructions about how to analize each param is going to be well apreciated but day to day we find more complete instructions, good job, Many thank's for that efford :)
Disclaimer: I have not read through this rapidly growing thread. So bear in mind that may already have been raised.
In my experience, starting off in the MultiWii world, then over into Baseflight and OpenPilot and spending a lot of time testing and flying various PID AHRS controller tweaks and versions on sports quads. I've spent many hours assisting with university projects with first APM 2.5, 2.6 and then Pixhawk 1. I've been dumbfounded with what appears to be extremely difficult PID tuning in APM:Copter or and poor performance even after multiple iterations of tuning, etc (autotuning never produced great results). There is a reason you don't really see sports flying with APM:Copter, it just doesn't easily get anywhere near the "locked in" results you get on these vastly simpler PID implementations right out of the box even with hard mounted PCBs.
I've heard on numerous occasions how APM:Copter PID implementation models the real world etc, and yet the results speak for themselves. It's difficult and the results for the effort are disappointing. I would like to see options to switch PID controllers introduced into APM:Copter/Rover/Plane.
hi Felixrising,
You are the first person here to comment on control problems. I am interested to hear more.
What other PID designs would you like to see implemented and why those ones?
In what way do you find manual tuning difficult with arducopter?
The process I use for manual tuning is: Increase Rate D until you get some oscillation, decrease until you don't. Repeat for Rate P. set Rate I equal to Rate P. Repeat for Stab P. It is interesting that you are having trouble with both Autotune and manual tuning.
I am personally involved with Arducopter for FPV racing and aggressive flight. (and a little holiday photography on the side). So I am very interested in any feedback you can give me on the control and tuning aspects of Arducopter.
A couple of points.
Soft mounting only does bad things to control and should be avoided unless the frame design and construction sucks. Solid, well built and designed frames don't have enough vibrations to cause issues. All my copters have the APM or pixhawk mounted with a single square of solid foam tape.
I got involved with Arducopter because I like FPV and agressive flight but wanted RTL and loiter to get me home if I got into trouble. I personally find ALL my copters are extremely locked in. I do most of my testing and development on my QAV250 and love it. My 3d printed copter will take anything I can throw at it even at it's top speed of 140km/h and I have the maximum lean angles set to 60 degrees on that thing. I also have a 3dr quad, Y6, X8 and hex, a monster tarot t960 that hovers at less than 50% at 10kgs and 16" props (designed for 18" max) and a quad with 16" props. All are rock solid in high turbulence winds and can have the sticks smacked around in any flight condition without any noticeable deviation from the desired angle.
I do fly fpv racing with people using other flight controllers but I haven't seen anything that makes me remotely gelous of their control ability. Having said that I do want to get support for oneshot into arducopter and I believe we can reduce a little latency and jitter on our outputs (we won't know if it makes a difference until we try).
>Increase Rate D until you get some oscillation, decrease until you don't
I could never understand this method - what is considered 'some' here? How do you quantify it? What metric in the log is going to show a factual difference and deviation from the optimal setting? How should it translate in the level of acceptable vibrations?
How am I supposed to hold in my hand a 3kg 750mm frame with 6 14" props and wait for 'some oscillation' to occur then then tune it down? Holding in the hand is the method I saw on youtube video where this 'tuning' method was illustrated.
So far only method that seems to be usable is the autotune, and it works more or less OK for what I can see.
IME, "some" is basically as soon as an attentive human can see and/or hear the oscillation in the frame and/or motors.
Hi Paul,
Sorry, I didn't make it clear. I do all this while in flight. I don't do this while holding the copter in my hand. That is why I set the minimum on my slider to something I know is safe. If something goes wrong I bang the slider back to the minimum setting and recover the copter. Then I can start again, more carefully this time....
I agree with you concerns about the term "some". This is why manual tunes then to result in Rate D being a little too small, Rate P being a little too large, then as a result Stab P being much lower than it is on an ideal tune.
How do you quantify it, you can't, that's the problem. That is where Autotune comes in. It is making it's decisions based on quantifiable data taken from each twitch test. That is why I can look at the autotune logs and see when a copter is behaving strangely. I just can't get that level of feedback when flying or looking at a normal flight log.
so, may I suggest one thing here - a proper procedure then should be to let an auto tune procedure to do its job.
Then we need to define how exactly next steps should be performed. I assume we need to use channel 6 setup, considering it is connected to variometer, like a S1 or S2 or L1/R1 levers on Taranis.
Then it gets to a very simple and same time very complicated question to which unfortunately there is no information available at all - try to google it. What actual item from the dropdown selector for channel 6 we need to choose to be able to do this kind of tuning you described above and what _exact_ values for limits should be set?
To add more, I found it almost impossible to figure out - like there is a loiter speed in there for Ch6 setup. I know my channel 6 works correctly. I was never able to see any effect on loiter speed using this input. So I am hesitant even to try anything related to Rate P tuning using this Ch6 method as I have no idea at all how to set it up safely around current autotune produced results, so I could have autotune value in the middle and then play with levers to go lower or higher, but in the acceptable range of deviation.
Does it make sense?
Actually, the fact that Loiter Speed doesn't work well on Ch6 is not surprising, because of how it's done. I think you would see an effect if you switched from Loiter to Stab and back every time you changed the knob position.
If I've done a complete firmware reset (copter->plane->copter) or built a new quad, I always set set ch7 to Autotune and ch8 to RTL, and ch6 to CH6_RATE_KP for the first flight and set ch6 dial to quite low (about 10 o'clock on the dial) - I find this the best way to take off without it heading towards the nearest tree (or me). If it doesn't respond enough you can very quickly turn the dial up as it's taking off until it does respond well, or if it oscillates or is completely uncontrollable you can quickly turn it down. Once it's stable-ish in stabilize hover I then move to alt-hold and then flick autotune on and do two or three rounds of autotune (I tend to find the second or third autotune much quicker and seems to just dial in a little better). This procedure works perfectly for me, it's only now after 6 months or so of learning to fly I'm just getting interested/capable of tuning manually. Oh, and I also try and do an autotrim before and after the autotune.
-
4
-
5
-
6
-
7
-
8
of 20 Next