Scripts to readout pid values to support using adjrange in-flight

[pulquero]

The idea of this script is to have the P values read-out when you are adjusting P, and likewise for I, D and D setpoint, when using adjrange. This is to make in-flight adjustment easier. Yes, you can have them displayed on the OSD but maybe you don't have a PC at hand to reconfigure your OSD.

For ref, here's the adjrange settings I'm using. I have a function configured on aux 5/trmt to run the script.

adjrange 0 0 4 1450 1550 0 5
adjrange 1 0 4 1575 1625 18 5
adjrange 2 1 4 1575 1625 15 6
adjrange 3 2 4 1575 1625 9 7
adjrange 4 0 4 1675 1725 19 5
adjrange 5 1 4 1675 1725 16 6
adjrange 6 2 4 1675 1725 10 7
adjrange 7 0 4 1775 1825 20 5
adjrange 8 1 4 1775 1825 17 6
adjrange 9 2 4 1775 1825 11 7
adjrange 10 2 4 1375 1425 22 7
adjrange 11 0 4 1375 1425 23 5
adjrange 12 0 0 900 900 0 0
adjrange 13 0 0 900 900 0 0
adjrange 14 0 0 900 900 0 0

The tx config I'm using:
trim step: coarse
channels/mixes:
ch9 trmt 305% (aux 5 used to select p,i,d or d setpoint)
c10 max 200% * trma 500% (adjust in roll axis)
ch11 max 200% * trme 500% (adjust in pitch axis)
ch12 max 200% * trmr 500% (adjust in yaw axis)
switches/functions:
L11 |a|>x trmt 3 / play script pids

So throttle trim up 1 notch to alter P, 2 notches for I, 3 notches up for D, down 1 notch for D setpoint. Then you can use roll, pitch, yaw trims to alter the selected value.

[mikeller]

I'm not sure if the presence of the telemetry background.lua script is going to conflict mixing up the requests and responses.

The background.lua script is disabled while the foreground script is running, so this will not cause conflicts.

[pulquero]

At one stage, I was trying to handle the request and response across different invocations to avoid spinning on waiting for a reply in the same invocation. Given what you said, that was a bad idea then.

[mikeller]

@pulquero: The background script could always be changed to do that. The intention behind disabling it when the foreground script is active was to nip the potential for concurrent requests in the bud.

[pulquero]

Having had a look at the opentx source code, I now believe the sportTelemetryPush/Pop functions don't cause any I/O to occur during script execution - it all happens between script executions. So it looks like I do have to handle it across the comms across multiple invocations.

[pulquero]

Good news! I found the issue, it is all working nicely now!

[stale]

This issue / pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.

[mikeller]

This looks like it needs a rebase.

[stale]

This issue / pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.

[mikeller]

@codecae, @raphaelcoeffic: What's your thoughts on this?

[raphaelcoeffic]

@mikeller sounds fun to me. I haven't tried it though. And I'm not quite sure it is really necessary to have 4 different scripts being run to work properly. I believe this could be done in only one script, which would detect which value has changed, but that's just my gut feeling.

@pulquero have you tried to make it only one main script, instead of 4?

[pulquero]

@raphaelcoeffic Nope, haven't tried that, but I can give it a go. I can just have one logical switch that triggers if trmt != 0, then read the channel value in the script and move the value checks in the script. Should save some resources.

[stale]

This issue / pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.

[mikeller]

@pulquero: Are you still working on combining this into one script as per @raphaelcoeffic's advice?

[pulquero]

Already done: pids.lua