At a glance, it appears it should continue to work after the first pass.
You have potential scope issues with the pwmXX variables as well as r, g, and b. Declare them as local to the update function.
Rather than nesting the logic so deeply, perhaps declare a function for each behavior. This may make debugging easier. Like so:
local function color_blend(pwm_brt, pwm_r, pwm_b, pwm_g)
local LED_br = math.floor((pwm_brt - 982) * 255 / 1024)
local r_val = math.floor((pwm_r - 982) * LED_br / 1024)
local g_val = math.floor((pwm_g - 982) * LED_br / 1024)
local b_val = math.floor((pwm_b - 982) * LED_br / 1024)
if msg_sent == 1 or msg_sent == 0 then
gcs:send_text(6, "LED Function = 0, Custom color")
msg_sent = msg_sent + 1
return r_val, g_val, b_val
Then your update function would have the statements:
elseif led_function == 0 then -- Calculate color blend based on RC input
r, g, b = color_blend(pwm11, pwm12, pwm13, pwm14)
Your function increment variable can be made to wrap around using the modulo operator, avoiding the entire first conditional logic below its assignment.
led_function = (led_function + 1) % 6
Additionally, you can use the
RC_Channel_ud:norm_input() binding to get a value for each channel between -1.0 and 1.0, thus avoiding the pwm math that you’re doing. Like so:
local norm11 = rc:get_channel(11):get_norm_input()
To avoid dynamic object creation with this method, you can assign the
RC_Channel_ud variables in the initialization section like this:
local chan11 = rc:get_channel(11)
And then use it in the update function like this:
local norm11 = chan11:norm_input()
Similarly, there is a
get_aux_switch_pos() binding as well, so you could get channel 7’s value as a discrete 0, 1, or 2 rather than raw pwm.
Lastly, consider your naming convention a bit better. If
pwm11 is intended to be the brightness factor, simply name it