Request: presets for tuning about mavgcl HOT 15 CLOSED

@dagar Of course I am! Should not be too difficult, as MAVGCL has its own data model (defined in MAVComm) storing key figures. Should the graph base on MAVlink data for in-flight display? (I am not aware of topics which represent 'command' in your mock-up). Response, I assume, are actual angles, etc. Are those key figures already in the PX4Log? In that case it would be easy to add them to the model, if you provide me the (sometimes cryptic) key-figure names.

from mavgcl.

Initially I was thinking just mavlink for tuning in flight, but I'd be very impressed if it could be abstracted to work with mavlink and a px4log.

Mavlink is a bit inconsistent with the naming. I just called it command here, but I don't personally care if it's called command/setpoint/target.

There's a little bit of conversion to be human friendly and intuitive. I think everything should probably be displayed in degrees. Most of these are in radians, and the attitude target is a quaternion.

For the displayed mockup it would use -
ATTITUDE - http://mavlink.org/messages/common#ATTITUDE
ATTITUDE_TARGET - http://mavlink.org/messages/common#ATTITUDE_TARGET

Actuator would be from ACTUATOR_CONTROL_TARGET - http://mavlink.org/messages/common#ACTUATOR_CONTROL_TARGET

The TECS tab (altitude, throttle controller tuning) is weirder because the mavlink spec only has altitude error and airspeed error. We could combine that with airspeed and altitude to plot command/response in the same way.

Then there's showing the appropriate params for each tuning tab. Maybe we could just stupidly filter as these things can change over time.
Pitch: FW_P*, etc

from mavgcl.

@dagar I'll have a look on this tomorrow. Most of it needs to be done in MAVComm, as the data model and the MAVLink parser is implemented there. PX4 log, of course, does not work in-flight and is very slow, so I think it makes sense to stick to MAVLink in the first step.

Regarding the params, I am not quite sure, whether an implementation as you suggest makes sense, as in MAVGVL params are shown as tree in a separate tab, so switching to that tab and scrolling to the corresponding tree items should not be too inconvenient. Maybe a filter in this view is sufficient. For in-flight tuning, The best way would be to adjust PIDs via RC.

So let's start with adding the key figures..

from mavgcl.

@dagar by now I added the following key figures (transforming them into degrees):
Roll, Pitch, Yaw, RollRate, PitchRate, YawRate, SetPoint Roll, SetPoint Pitch, SetPoint Yaw

Maybe it is a good idea, to add an additional time-graph to the screen to allow all three axes being visible at one time..

from mavgcl.

You're fast. Two simultaneous plots is probably sufficient. Seeing what the actuators are doing isn't critical.

I agree the best way to adjust PIDs solo is with an RC knob, but my ideal tuning setup has been one person flying and a friend on the laptop plotting and modifying gains. Then you can coordinate the type of flying, specifically test roll at different frequencies, etc. It was because of how annoying we found it to jump between the plot and param editor in QGC that I did the mockup. The other cool feature would be if changing a param (eg FW_PR_P) was annotated, but one step at a time. The overall goal is making it as easy and fast as possible to tune each loop.

Is there anything I can do to help?

from mavgcl.

@dagar I think, I'll do a kind of overlay for the relevant parameters similar to the details-overlay. On top of the overlay, there could be a drop-down with the parameter-groups and below that, the selected params. This would make the parameter-tab obsolete. (Not too bad, as the parameter-tab implementation is really ugly). What do you think?

from mavgcl.

That sounds good.

from mavgcl.

Would look like this:

Maybe Spinners would also help..

from mavgcl.

Nice.
It looks like you have access to the param metadata. Are you aware of the decimal/increment fields?
https://github.com/PX4/Firmware/blob/master/src/modules/fw_att_control/fw_att_control_params.c#L78

from mavgcl.

The decimals I already have (no increment, as I currently have no spinner):
https://github.com/ecmnet/MAVGCL/blob/master/MAVGCL/src/com/comino/flight/parameter/ParameterFactMetaData.java#L106

from mavgcl.

@dagar
Here's how it looks like currently:

Spinners occur only if increments are defined.
I committed the current status. Feel free to play around and test it a bit. Please double-check param updates with QGC. Updates are sent to the device, when ENTER is pressed. A message is shown in the status-line, when the acknowledgement is received from the device.

Known issues:

• Sorting of params
• Decimal places as defined in metadata
• Defaults should have a different color.
• Context-Menu does not work for Spinners.
• Main panes should be resized according to the width of overlays.
• Spinner does not increment at certain params.
• Additional key figures (Actuator, TECS).
• Warning for param changes that need reboot.

from mavgcl.

@dagar Simple LogMessage annotation in time charts include also parameter changes (you have to switch to 10sec frame resolution to see annotations; text by click):

from mavgcl.

@dagar I added now actuator control target. What is the corresponding actual? Is it servo_raw output normalized by (x-1500)/1000?

from mavgcl.

Yes it's normalized, but the PWM value is going to depend on the specific mixer. Ideally someday I'd like to calibrate it.

from mavgcl.

Closing this for now. Further key figures with general key-figure refactoring.

from mavgcl.