realtime PID tuning over mavlink

[Andrew Tridgell]

Hi Leonard and Randy,

Rob and I have been doing some development on PID logging, including
doing realtime PID tuning over MAVLink. I flew it for the first time
today on both plane and heli and it works very nicely.

What it does is:

- replaces RATE DF message with PIDR, PIDP, PIDY and PIDA
messages. These per-axis messages contain the contribution of P, I,
D and FF to each PID, so you can see exactly how much impact each of
the PID tuning components is having

- added a PID_TUNING MAVLink message. This message is disabled by
default, but you can enable it with the GCS_PID_MASK parameter. That
is a bitmask of what axes you want PID_TUNING messages for.

- to tune an axis you can either use DF messages and post-flight
tuning, or you can set GCS_PID_MASK to the axis you are interested
in and watch the PID components plus desired and achieved rates in
real time on a GCS. This gives live PID tuning in a way we've never
had before - you can see immediately what impact a PID change is
having on the desired/achieved rates, plus on the individual
components. It makes manual tuning a lot easier.

To get a high mavlink stream rate I adjusted the rates on my GCS to give
20Hz for SR1_EXTRA1 stream, and lowered to 2Hz for other streams. That
gave me plenty of time resolution for tuning a Trex500 heli in yaw
today.

The branch is here:

https://github.com/tridge/ardupilot/commits/Attitude_Rate_Logging

I'll definately be pushing this for plane, but want to check that you
are OK with this change for copters and you don't mind the new RATE
message being removed and replaced with the separate PID messages.

Cheers, Tridge

[Leonard Hall]

Hi all,

I don't have a problem with changing the RATE logs to individual PID logs provided we don't loose the information. Time ms, Desired Rate, Measured Rate, Output (we can add up the P I and D terms if needed).

However, I am a little concerned about how large the logs are growing. It is getting difficult to do support because of how long it takes to view logs in the mission planner. It is also a relatively time consuming process for users to download their logs to mavlink. 

It may be a better idea to keep the RATE log but only turn on the individual PID logs when we need them.

Leonard

[john...@gmail.com]

Compression? Even simple RLE would probably give a nice result on the data in question. Or even better considering the nature of analog sensor signals, use u-law or a-law.

[Robert Lefebvre]

That's not a bad idea.  Maybe it could be set up so that by default we are logging only the old RATE message.  However, if we turn on PID tuning, for a PID tuning session, then we stop the RATE message, and log the PID messages instead.

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.