New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add controller tuning widget #2878
Comments
Here's a rough mockup of what we were thinking. If someone could help establish the initial framework (controller selection screen, realtime plotting, etc) I could help with the specifics (setup plots and params for each) and testing of course. |
My PixRacer shows up today. If I end up having to tune it myself you may end up seeing this sooner than later :) |
Does Qt have no "spinner" widgets for incrementing/decrementing values? On Wed, Feb 24, 2016 at 12:29 PM Don Gagne notifications@github.com wrote:
|
It does now with the Qt 5.5 we switched to a few months back. |
It would be nice to be able to spec a floating point increment/decrement On Thu, Feb 25, 2016 at 11:14 AM Don Gagne notifications@github.com wrote:
|
Right spin buttons don't work on tablet. Need a more custom spin button style implementaion like tower. |
I copy this from another issue #2328 I just stumbled there on the topic: The current implementation of "Set to RC" is very basic and sometimes tedious to use. First once I assign knobs to params, and then I reassign the knob to other param and vice versa and I loose track of what the assignment is, I cannot see what is the current assignment. So I have to reset all the assignments in order to be sure I reassign them the correct way. Second there is no visual clue what I'm changing... The only way I can see what the current value is once I land and do refresh of the parameters. This is very inconvenient when I have to make the final fine tinning, where I have to move just a minute steps up or down. My Taranis slider visualization does not allow me to see this small movements. I agree with most users that @Tumbili cited. We need a Tuning view with some visualization. What I mean is probably different visualization for the MC and FW. Because they are tuned in a different way. For example now the tuning procedure for MC includes holding the MC in your hand and tuning the P and D gains. Once you get the MC in your hand and start to tune the gains with knobs you can pretty much eliminate totally the osculations and vibrations, because you feel in your hand the tiny tiny first signs of osculation and cut them. This tiny oscillations in reality are not visible, so if I have to tune the MC visually flying it, it is not possible see or detect this oscillations. So very often you visually tune the MC perfect, until you see the logs. Also you can feel the difference between the P oscillation and D oscillation with your hand, which is sometimes visually hard to differentiate. So tuning the MC holding it in your hand for perfection, you become some sort of sensor for the tuning process. But now imagine I already tuned my machine in this way and then change some camera equipment etc. I have to re-tune the MC but just a little. The chances are that you can smash your tuning if done in the air in the current situation. Imagine one even worse situation. I have a 1.3m Octo and how do I tune this thing? I cannot hold it in my hand. I have to fly it and tune it in flight. So what I'm saying is on this Tuning tab we need some sort of indicator for the oscillations left and right and we should see their magnitude. In the Audio recording there is similar instrument that shows the de-phased sound that you should fight in the mix. It is just meter with a centered indicator. The moment we have a de-phased sound it starts to shake between left and right. The larger the amplitude the larger the de-phase. At the center when the meter is not moving there is no de-phase. We could use this for the oscillation indication. There could be 2 indicators one for the p oscillation and one for the d oscillation. For the airplanes it is the same story but we have a different problems tuning. Visually very often the plane flies pretty decent but in reality once you open the logs it is different story. So visually again you cannot tune very well the airplane. There are again oscillations if gains not correct. If we assume we tune the machine in dead calm weather, to eliminate the external factors We could pretty much see the oscillation the moment we see the servo movements. Their delta between up and down movement can show if there is oscillation. It could be the SP delta as well. In reality if a plane is good in dead calm weather it should fly with almost no correction from the PX4 and thus not many servo movements. There is another thing. Tuning in dead calm weather often leads to giving pretty high gains or tight as we call them. So the first time we are in strong weather with and aircraft we have to re-tune the gains. So it is very hard in this conditions to visually differentiate between corrections from wind or oscillation from higher P gain are the cause. We have to fly tune, see logs, fly tune again see logs etc. If we could somehow visually see the oscillations in the plane vs external factors (wind) corrections it would be much easier and have better tuned machines. Better flying, better reliability. This view will be mandatory for larger machines! We work on couple of 3+ meter airplanes and a VTOL with this size, and we just could not find any easy solution for the tuning. BTW for the planes there is not a bad idea for the general AETR or AERT during the frame setup in QGC to ask the user for the size of the plane and then suggest approximate PIDs appropriate for that size. |
@DonLakeFlyer Is that a live plot? Looks very useful. |
Yup, live. |
Response is actual value. Command is setpoint. |
Coming to a daily build very soon. See #6295 for details... |
This looks great! |
First cut is in |
@DonLakeFlyer @kd0aij @dagar This would have the parameters on the left, with a drop-down selecting between different controllers (rate, attitude, position, etc) and a realtime graph on the right showing desired vs. actual.
It might also have for the tuning parameters drop-down to map to a RC channel. With the UI setting that in realtime would be feasible for RC tuning, so I would argue that this is not blocked on Firmware support. Probably APM has similar needs and the instrument could be shared and jointly maintained.
The text was updated successfully, but these errors were encountered: