Radio Controllers
- Anthony Luo
Overview
Radio Controllers refer to our RC controllers. These include our TX16s mk ii, tx12, and (hopefully in the future) boxer radios! This guide really only explains warg-specific setup, and so I would highly recommend watching youtube or reading up on the internet how to operate these radio controllers in general. Oscar Liang, Joshua Bardwell, Painless 360, and RC Video Reviews are all great sources.
In this document, you will learn our model setup, some warg “best practices”, and current model hierarchy. For all of the following discussion, we’ll use a “WARG_template” model which can be found on the blue tx16. Highly recommend copying this model and re-naming it as a basis for future models, instead of trying to set-up all the special functions over and over again.
Currently, this model has the ‘WARG’ and ‘warganni’ labels, as does Pegasus, Houston, Vanguard, and Gemini models.
Model Hierarchy
WARG maintains global models for our advanced/competition pilot roster, these will contain the WARG label. These models are used globally and should be synced regularly between both controllers. The standard operation for WARG involves AETR, with either SF or SA as arm, momentary SH as pre-arm, and SG as trainer. Pilots may change i/o as long as they revert back to the recommended settings.
Other models can be created as needed, but all models should be labelled either with a subteam or globally with WARG. Generally, create only the model that you need, name it clearly (E.G: tubie, vanguard, judie, etc) and back-up models often. Try not to create multiple models for the same airframes, instead try to use our I/O interfaces to remap controls as you see fit. Try to revert any changes after you fly, and double check your inputs before you fly!
It is best practice not to create many labels, generally only WARG global labels, subteam labels, and competition pilot labels should exist. Do not apply a generic WARG label to a model that you have created, unless it is applicable to WARG globally.
Understanding your screens
In general, you can setup your “home” screen however you like. Warg prefers the following primary layout shown below, with 9 channels of input/output, as well as two timers and either the model name or the model image. This means that everyone is clear and familiar on the presented data, and surprises are few and far between. You should see something like this when you enter a model.
Across the top, you’ll see transmit power, transmit link quality, trainer signals, and RSSI. Of these, transmit power, transmit link quality, and received signal strength indicator tell you how well your RC link is being understood and decoded, while the trainer signal lets you know whether or not your controller is receiving a valid trainer signal. Highly suggest setting the trainer channel to the trainers “flight mode” channel so that you are able to ensure both controllers are on the same flight mode when doing handovers.
There are more screens which can be added, these are the ones that you should edit to your preference. Remember that if you make a different screen standard across all models, you should change it across all active airframes and update this document as well!
Notice how the top bar does not change between telemetry screens. You can use this to display persistent information.
Generic Model Setup
Whenever you get a model, there’s some basic items that you need to setup. This includes the name, choosing internal vs external RF modules, pre-flight checks, trainer options, timer options, and trims. They can be found on the main page. In most of wargs cases, you will want to use the internal RF, and setup one timer to track your current flight lifetime, and one timer to track total flight lifetime. This allows you to quickly see and estimate remaining battery life, or cross-compare actual motors-on time of your drone. This is particularly important if you do not have mavlink logging onboard.
Please refer to our ELRS documentation for setting up internal & external RF modules.
Input-Output Mapping
In general, warg prefers all inputs from switches to be clearly labelled in the inputs section of the controller. This means that any warg pilot is able to quickly look at the switch → input mapping, and make adjustments as necessary without creating brand-new models. WARG also, for the same reason, recommends that any curves (expo, etc) be applied at the input stage, and not at the mixer stage.
We’ll talk a bit more about curves in the Global Variables section, but all you need to know is that they’re expo curves that can change depending on the flight mode.
Take a look at some example inputs below. Note that inputs appear in the order of creation, and are labelled 1-32, but this has no real implication on channel maps.
In these scenarios, arm and pre-arm inputs aren’t shown, but I promise you that they’re there.
Once the inputs have been made, we can map our channels in the mixes section. You can see some examples here:
Note that this particular mode mix has an override enabled. This is optional, and can be setup with logical switches (Maybe that’s already been changed by the time you receive the model. Maybe it’s a good first-exercise for you to take a look at).
Global Variables
WARG prefers taking advantage of global variables when possible, it allows us more functionality in a much clearer way compared to individual curves and switch logic.
Flight Modes
We prefer setting the flight mode using 6-position switch at the top of the tx16 since this allows for GVAR usage, with default Ardupilot flight modes usually being Stab, AltHold, Loit, RTL, Auto, Land.
Note that the tx16 supports more than 6 flight modes, but ardupilot only supports 6 and there’s only a 6-position switch. It’s possible to use FM0 and FM7/8 is default (not-possible-to-arm) or reversionary (i.e. same as FM1 but with different rates) should you wish. This is entirely pilot preference.
The output to the MODE input is from GV1 “MOD”. It outputs a particular % for each flight mode that we have selected, and thus the flight mode we are in relates directly to the output on channel 8 or 12.
Expo
Expo is applied using GV2 and GV3, one for throttle and one for control. Throttle expo is only applied in altitude-controlled modes, giving the pilot a little bit more deadband in order to ascend/descend slowly. Control expo is only applied in non-position hold modes, giving the pilot a bit more control. It may be desirable to add a bit of expo to position controlled modes. Pilot preference is key. Expo can be set directly by selecting a GV as the source for a curve.
Logical Switches + Special Functions
This is where the magic really happens…and it can be a bit …. much. Logical switches are just logic that you can program, and special functions are special functions that you can program. Pretty easy and self explanatory.
Safe-Arm
Our arm occurs on ch5. A pilot is only allowed to arm if the following conditions are met:
Throttle is < 98 (all the way down)
Pre-arm switch is toggled
arm-switch is then moved to the arm position.
Note that all of these arm/pre-arm functions are listed as inputs, and logical functions have been created to allow any pilot to change their choice of arm/pre-arm. Our safe-arm function takes 8 logical switches, and looks as follows:
The logic is as follows:
L58 + L61
L58 checks that your pre-arm is high
L61 checks that your throttle is below 0
L64 moves high
You have moved the arm switch to be in position
L63 captures L64 only if L58 is high
You will capture the transition from low to high on your arm switch ONLY if your pre-arm is ready.
L60 goes high if L61 and L63
You will capture the transition from low to high on your arm switch ONLY if your throttle is below 0
L59 capture edge of L60
L62 captures a sticky of L59 as long as L64 is high
As long as your arm switch is > 98, L62 will remain high.
As soon as you move your arm switch < 99, you will disarm.
L62 will lockout Ch3 (throttle) and Ch5 (arm) from being anything other than -100 unless it goes high. This is done using the Special Functions page:
Telemetry Logging + Voice prompts
Telemetry logging can be enabled using the log switch, voice prompts can be enabled using voice prompts. <Add some more screenshots.>
It is possible to use globally enabled functions for these, however it is recommended that you turn off global functions and re-build them per-model to prevent accidentally overwrites/duplicate actions from one switch movement.
Draft section ~~ ignore~ ~