This section includes Acknowledgments and Getting Started.

Join the chat on Discord

Go to https://doc.open-tx.org/opentx-2-3-lua-reference-guide/ for the latest published version of this guide.

This guide covers the development of user-written scripts for R/C transmitters running the OpenTX 2.3 operating system with Lua support. Readers should be familiar with OpenTX, the OpenTX Companion, and know how to transfer files the SD card in the transmitter.

Part I of the guide shows how to enable Lua support for Taranis and includes basic examples of each types of script.

Part II is a programming guide that introduces the types of OpenTX Lua scripts and how to use them.

Part III is the OpenTX Lua API Reference

Part IV addresses common issues in converting Lua scripts that were originally written for OpenTX 2.0

Part V addresses common issues in converting Lua scripts that were originally written for OpenTX 2.1

Part VI covers advanced topics with examples

last updated on 2021/01/09 17:57:00 UTC

WARNING - Do not use Lua mix scripts for controlling any aspect of your model that could cause a crash if script stops executing.

Description

Each model can have several mix scripts associated with it. These scripts are run periodically for entire time that model is selected. These scripts behave similar to standard OpenTX mixers but at the same time provide much more flexible and powerful tool.

Mix scripts take one or more values as inputs, do some calculation or logic processing based on them and output one or more values. Each run of a script should be as short as possible. Exceeding the script execution runtime limit will result in the script being forcefully stopped and disabled.

Typical uses

• replacement for complex mixes that are not critical to model function

• complex processing of inputs and reaction to their current state and/or their history

• filtering of telemetry values

Limitations

• cannot update LCD screen or perform user input.

• should not exceed allowed run-time/ number of instructions.

• mix scripts are run with less priority than built-in mixes. Their execution period is around 30ms and is not guaranteed!

• can be disabled/killed anytime due to logic errors in script, not enough free memory, etc...)

Location

Place them on SD card in folder /SCRIPTS/MIXES/. File name length (without extension) must be 6 characters or less (this limit was 8 characters in OpenTX 2.1).

Lifetime

• script is loaded from SD card when model is selected

• script init function is called

• script run function is periodically called (inside GUI thread, period cca 30ms)

• script is killed (stopped and disabled) if it misbehaves (too long runtime, error in code, low memory)

• all mix scripts are stopped while one-time script is running (see Lua One-time scripts)

Disabled script

If as script output is used as a mixer source and the script is killed for what ever reason, then the whole mixer line is disabled! This can be used for example to provide a fall-back in case Lua mixer script gets killed.

Example where Lua mix script is used to drive ailerons in some clever way, but control falls back to the standard aileron mix if script is killed. Second mixer line replaces the first one when the script is alive:

CH1  [I4]Ail Weight(+100%)
  := LUA4b Weight(+100%)

Script interface definition

Every script must include a return statement at the end, that defines its interface to the rest of OpenTX code. This statement defines:

• script input table (optional, see Input Table Syntax)

• script output table (optional, see Output Table Syntax)

• script init function (optional, see Init Function Syntax)

• script run function (see Run Function Syntax)

Example (interface only):

local input {}

local output {}

local function init_func()
end

local function run_func()
end

return { input=input, output=output, run=run_func, init=init_func }

Notes:

• inputs table defines input parameters (name and source) to run function (see Input Table Syntax)

• outputs table defines names for values returned by run function (see Output Table Syntax)

• init_func() function is called once when script is loaded.

• run_func() function is called periodically

TODO: describe how theme scripts work on Horus type transmitters.

Overview

One-Time scripts start when called upon by a specific radio function or when the user selects them from a contextual menu. They do their task and are then terminated and unloaded. Please note that all persistent scripts are halted during the execution of one time scripts. They are automatically restarted once the one time script is finished. This is done to provide enough system resources to execute the one time script.

WARNING! -

• Running a One-Time script will suspend execution of all other currently loaded Lua scripts (Mix, Telemetry, and Functions)

File Location

Place them anywhere on SD card, the folder /SCRIPTS/ is recommended. The only exception is official model wizard script, that should be put into /SCRIPTS/WIZARD/ folder that way it will start automatically when new model is created.

Lifetime of One-Time scripts

Script is executed when user selects Execute on a script file from SD card browser screen.

Script executes until:

• it returns value different from 0

• is forcefully closed by user by long press of EXIT key

• is forcefully closed by system if if it misbehaves (too long runtime, error in code, low

  memory)

TODO: Need to determine status of wizard in 2.2

General description

Widgets are small scripts that show some info in a 'zone' in one of the model specific user defined (telemetry) screens. You can define those screens within the telemetry menu on the HORUS.

Each model can have up to five custom screens, with up to 8 widgets per screen, depending on their size and layout. Each instance of a widget has his own custom settings.

File Location

Widgets are located on the SD card, each in their specific folder /WIDGETS/<name>/main.lua (name must be in 8 characters or less).

Lifetime of widgets

Widgets need to be registered through the telemetry setup menu.

• widget create function is called

• widget update function is called upon registration and at change of settings in the telemetry setup menu.

• widget background function is periodically called when custom telemetry screen is not visible. Notice:

  • This is different from the way telemetry scripts are handled

• widget refresh function is periodically called when custom telemetry screen is visible

• widget is stopped and disabled if it misbehaves (too long runtime, error in code, low memory)

• all widgets are stopped while one-time script is running (see Lua One-time scripts)

Once registered, widgets are started when the model is loaded.

Script interface definition

Every widget must include a return statement at the end, that defines its interface to the rest of OpenTX code. This statement defines:

• widget name (name must be a string of 10 characters or less)

• widget options array (maximum five options are allowed, 10 character names max, no spaces!)

• widget create function

• widget update function

• script background function

• script refresh function

Example (draws a moving counter that counts only when not visible):

local defaultOptions = {
  { "ControlX", SOURCE, 1 },
  { "ScrollZ", BOOL, 1 }, -- BOOL is actually not a boolean, but toggles between 0 and 1
  { "StepZ", VALUE, 1, 0, 10},
  { "COLOR", COLOR, RED },
}

local function createWidget(zone, options)
  lcd.setColor( CUSTOM_COLOR, options.COLOR )
  --  the CUSTOM_COLOR is foreseen to have one color that is not radio template related, but it can be used by other widgets as well!
  local someVariable = 0
  local anotherVariable = {xWidget=0, yWidget = 0}
  return { zone=zone, options=options , someVariable = someVariable, anotherVariable=anotherVariable }
end

local function updateWidget(widgetToUpdate, newOptions)
  widgetToUpdate.options = newOptions
  lcd.setColor( CUSTOM_COLOR, widgetToUpdate.options.COLOR )
  --  the CUSTOM_COLOR is foreseen to have one color that is not radio template related, but it can be used by other widgets as well!
end

local function backgroundProcessWidget(widgetToProcessInBackground)
  local function process(...)
          return ... + 1
        end
  widgetToProcessInBackground.someVariable = process (widgetToProcessInBackground.someVariable)
end

local function refreshWidget(widgetToRefresh)
  local counterLength = 50
  local counterHeight = 30

  --backgroundProcessWidget(widgetToRefresh) 
  --background is not called automatically in display mode, so do it here if you need it.

  local function anotherProcess(parameter,step,maxParameter)
          return (parameter + step) % maxParameter
        end

  widgetToRefresh.anotherVariable.xWidget 
    = anotherProcess ( widgetToRefresh.anotherVariable.xWidget
      ,getValue(widgetToRefresh.options.ControlX)/10.24/20 
      ,widgetToRefresh.zone.w-counterLength)

  widgetToRefresh.anotherVariable.yWidget 
    = anotherProcess ( widgetToRefresh.anotherVariable.yWidget
      ,(widgetToRefresh.options.ScrollZ==1) and widgetToRefresh.options.StepZ or 0
      ,widgetToRefresh.zone.h-counterHeight)

  lcd.drawNumber(widgetToRefresh.anotherVariable.xWidget + widgetToRefresh.zone.x
    , widgetToRefresh.anotherVariable.yWidget + widgetToRefresh.zone.y
    , widgetToRefresh.someVariable
    , LEFT + DBLSIZE + CUSTOM_COLOR);
end

return { name="MovingCntr", options=defaultOptions, create=createWidget, update=updateWidget
  , refresh=refreshWidget, background=backgroundProcessWidget }

Notes:

• options are only passed through to OpenTX to be used on widget creation. Don't change them during operation, this has no effect.

• create() function is called once when widget is loaded and begins execution.

• update() function is called once when widget is loaded and begins execution.

• background() is called periodically when custom telemetry screen containing widget is not visible.

• refresh() function is called periodically when custom telemetry screen containing wodget is visible.

• in the example given, you can see that no global variables or functions are needed to operate the widget.

• variables that are used throughout the widget, can best be declared inside the create function as local variables

• those local variablkes can then be passed through to the other functions as an element of the widget array that is returned

The OpenTX team has no intention of making a profit from their work. OpenTX is free and open source and will remain free and open source. But OpenTX is more expensive to maintain than most open source projects. The reason is that there is a never ending flood of hardware to integrate and maintain code for. Hardware that costs.

Another reason is that OpenTX maintains a build server that serves firmware compiled on demand. This is where OpenTX Companion orders your customized firmware. The server is not for free and the bandwidth is ever increasing with tens of thousands of firmware downloads each month.

The OpenTX team is grateful to those who have donated to the project. You have helped making OpenTX and OpenTX Companion great.

The Github Donor List is updated at each OpenTX release.

If you would like to contribute to OpenTX, donations are welcome and appreciated:

Overview

Function scripts are invoked via the 'Lua Script' option of Special Functions configuration page.

Typical uses

• specialized handling in response to switch position changes

• customized announcements

Limitations

• should not exceed allowed run-time/ number of instructions.

• all function scripts are stopped while one-time script is running (see Lua One-time scripts)

• Function scripts DO NOT HAVE ACCESS TO LCD DISPLAY

Location

Place them on SD card in folder /SCRIPTS/FUNCTIONS/

Lifetime

• script init function is called once when model is loaded

• script run function is periodically called as long as switch condition is true

• script is stopped and disabled if it misbehaves (too long runtime, error in code, low memory)

Script interface definition

Every script must include a return statement at the end, that defines its interface to the rest of OpenTX code. This statement defines:

• script init function (optional, see Init Function Syntax)

• script run function (see Run Function Syntax)

Example (interface only):

local function init_func()
end

local function run_func()
end

return { run=run_func, init=init_func }

Notes:

• local variables retain their values for as long as the model is loaded regardless of switch condition value

Advanced example (save as /SCRIPTS/FUNCTIONS/cntdwn.lua)

The script below is an example of customized countdown announcements. Note that the init function determines which version of OpenTX is running and sets the unit parameter for playNumber() accordingly.

local lstannounce
local target

local running = false

local duration = 120 -- two minute countdown
local announcements = { 120, 105, 90, 75, 60, 55, 50, 45, 40, 35, 30, 29, 28, 27, 26, 25, 24, 23, 22, 21, 20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0}
local annIndex

local minUnit

local function init()
  local version = getVersion()
  if version < "2.1" then
    minUnit = 16  -- unit for minutes in OpenTX 2.0
  elseif version < "2.2" then
    minUnit = 23  -- unit for minutes in OpenTX 2.1
  else
    minUnit = 25  -- unit for minutes in OpenTX 2.2
  end
end

local function run()

  local timenow = getTime() -- 10ms tick count
  local remaining
  local minutes
  local seconds

  if not running then
    running = true
    target = timenow + (duration * 100)
    annIndex = 1
  end

  remaining = math.floor(((target - timenow) / 100) + .7) --  +.7 adjust for announcement lag

  if remaining < 0 then
    running = false -- we were 'paused' and missed zero
    return
  end

  while remaining < announcements[annIndex] do
    annIndex = annIndex + 1 -- catch up in case we were paused
  end

  if remaining == announcements[annIndex] then
    minutes = math.floor(remaining / 60)
    seconds = remaining % 60
    if minutes > 0 then
      playNumber(minutes, minUnit, 0)
    end
    if seconds > 0 then
      playNumber(seconds, 0, 0)
    end
    annIndex = annIndex + 1
  end

  if remaining <= 0 then
    playNumber(0,0,0)
    running = false
  end

end

return { init=init, run=run }

Downloading OpenTX Companion

OpenTX Companion 2.2 is available for download at http://www.open-tx.org/downloads.html

Updating firmware with Lua option selected

If you intend to use mixer scripts, when updating the firmware on your transmitter you need to make sure the lua option is checked in the settings for your radio profile (Main menu -> Settings ->Settings...) as shown below. This is not required if you only intend to run telemetry, one-time and function scripts, support for those is included by default.

Also note that the SD Structure path should contain a valid path to a copy of your transmitter's SD card contents, although that's not specific to Lua.