Skip to content

Add support for second transmitter-tuning control channel #30042

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

Open
wants to merge 15 commits into
base: master
Choose a base branch
from

Conversation

peterbarker
Copy link
Contributor

There are several pre-cursor PRs to merge before this one.

Closes #2125

@@ -283,6 +283,8 @@ class RC_Channel {
MOUNT2_YAW = 217, // mount4 yaw input
LOWEHEISER_THROTTLE= 218, // allows for throttle on slider
TRANSMITTER_TUNING = 219, // use a transmitter knob or slider for in-flight tuning
TRANSMITTER_TUNING2 = 220, // use another transmitter knob or slider for in-flight tuning
TRANSMITTER_TUNING3 = 221, // use yet another transmitter knob or slider for in-flight tuning
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we don't need TRANSMITTER_TUNING3?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we don't need TRANSMITTER_TUNING3?

I decided to reserve an additional value just to keep things consecutive if someone did want another one.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.. until muramura comes along in 5 minutes and removes it :-). We have a golden rule in AP that we don't think about the future too much because it's hard to predict so let's remove it. users don't care about the numbers much anyway now that we alphabetise the param values that are shown in the GCSs

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.. until muramura comes along in 5 minutes and removes it :-). We have a golden rule in AP that we don't think about the future too much because it's hard to predict so let's remove it. users don't care about the numbers much anyway now that we alphabetise the param values that are shown in the GCSs

Fair enough, I've removed it.

Note I'm not wedded to adding this second channel, but it's always vexed me that there was only one (and that it was fixed at CH_6, of course ;-) )

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@peterbarker, thanks for your efforts. If you really want it then I'm happy to go along with that. Can I ask though when was the last time that you (or anyone else on the CanberraUAV team) actually wanted to manually tune a copter from the transmitter? I personally never tune using transmitter knobs anymore, I always just do the updates from the GCS.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@peterbarker, thanks for your efforts. If you really want it then I'm happy to go along with that. Can I ask though when was the last time that you (or anyone else on the CanberraUAV team) actually wanted to manually tune a copter from the transmitter? I personally never tune using transmitter knobs anymore, I always just do the updates from the GCS.

Weelll.... I don't think the CanberraUAV people are typical fliers :-)

I don't think I've personally used this stuff in a very long time. Mostly because I do usually have a friendly GCS operator to change values while I'm flying.

I have seen tridge use transmitter-based tuning within the last couple of years - but not this sort. The sort that's only present in Plane and allows you to rotate through PID values using a switch.

If we want to start to ease this out of the code instead we can do that. I think this would make sense as a build-server option anyway. Still useful on 1MB boards but not vital.

This PR costs 136 bytes on CubeOrange.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, so the short answer is that even CanberraUAV won't use this feature. If we have time, let's ask at the dev call what other devs think.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... compiling the feature out saves 1,400 bytes. I've added defines for that in this PR now.

@rmackay9
Copy link
Contributor

Txs, the issue linked is from 2015 though so I wonder if perhaps things haven't moved on so much as to make this unnecessary. Back in those days we had limited interface options for most users (e.g. less users of telemetry, no lua scripting, less sophisticated GCSs).

I'm not blocking this but I think we should carefully consider whether we really want this

@peterbarker
Copy link
Contributor Author

Txs, the issue linked is from 2015 though so I wonder if perhaps things haven't moved on so much as to make this unnecessary. Back in those days we had limited interface options for most users (e.g. less users of telemetry, no lua scripting, less sophisticated GCSs).

I'm not blocking this but I think we should carefully consider whether we really want this

I believe people still do actually use these.

image

@peterbarker peterbarker force-pushed the pr/multi-tuning-channel branch 2 times, most recently from 64897eb to 2e1dbd2 Compare May 12, 2025 04:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging this pull request may close these issues.

Copter: Smarter CH6 tuning
2 participants