Debogage des scripts LUA - quid d'un émulateur

Première idée que j'ai eu cette année : développer un émulateur qui permettent de déboguer les scripts LUA dans une IDE traditionnel.

J'utilise de plus en plus ZeroBraneStudio qui me permet déjà d'avoir un contrôle syntaxique, ce qui est déjà pas mal. Mais je suis demandé s'il était possible d'aller un peu plus loin et d'essayer de développer une solution pour pouvoir déboguer pas à pas les scripts pour OpenTx.

N'ayant pas grande expérience de LUA, j'ai tout à découvrir, entre autre toute la partie graphique mais ça n'a pas l'air trop compliqué si l'on reste dans quelque chose de simple. Voici le résultat après deux soirées d'exploration.



Pour l'instant, à part cet affichage, rien ne marche mais je vais essayer sans garantie de faire quelque-chose d'utilisable.

Si l'envie vous prend d'y contribuer, c'est bien volontiers, plus y'aura de bonnes idées, plus ça ira vite et ce sera bien.

En attendant, voici le bout de source sur lequel je travaille, n'hésitez pas, tous vos commentaires gentils ou pas seront les bienvenus.

Code:


-----------------------------------------------------------------------------
-- Name:        taranis.lua
-- Purpose:     OpenTx Taranis LUA emulator
-- Author:      Marco Ricci
-- Modified by:
-- Created:     01-Jan-2015
-- Copyright:   (c) 2015 Marco Ricci. All rights reserved.
-- Licence:     ???
-----------------------------------------------------------------------------

-- Load the wxLua module, does nothing if running from wxLua, wxLuaFreeze, or wxLuaEdit
package.cpath = package.cpath..";./?.dll;./?.so;../lib/?.so;../lib/vc_dll/?.dll;../lib/bcc_dll/?.dll;../lib/mingw_dll/?.dll;"
require("wx")

local frame, panel, bitmap = nil, nil, nil
local brush, pen
local mdc = wx.wxMemoryDC()
local lcd_width, lcd_height = 212, 64
local lcd_ratio, lcd_color = 2, "Blue"
local lcd_lock = false

local MENU_BUTTON_ID = 1
local PAGE_BUTTON_ID = 2
local EXIT_BUTTON_ID = 3
local PLUS_BUTTON_ID = 4
local MINUS_BUTTON_ID = 5
local ENT_BUTTON_ID = 6

lcd = {
  lock = function ()
    lcd_lock = true
  end,
  
  clear = function ()
    brush = wx.wxBrush("Blue", wx.wxSOLID )
    pen = wx.wxPen("Blue", wx.wxSOLID, 1)
    mdc:SelectObject(bitmap)
    mdc:SetBrush(brush)
    mdc:SetPen(pen)
    mdc:DrawRectangle(0, 0, 1 + lcd_width, 1 + lcd_height);
    mdc:SelectObject(wx.wxNullBitmap)
    brush:delete()
    pen:delete()
  end,
  
  drawPoint = function (x, y)
  end,

  drawLine = function (x1, y1, x2, y2, path, flags)
  end,

  drawRectangle = function (x, y, width, height)
  end,

  drawText = function (x, y, text, att)
  end,

  drawSwitch = function (x, y, switch, att)
  end,

  drawPixmap = function (x, y, path)
  end,

  drawScreenTitle = function (title, idx, cnt)
  end,

  drawGauge = function (x1, y1, w, h, fill, maxfill)
  end,

  drawChannel = function (x, y, source, att)
  end,

  drawNumber = function (x, y, number ,att)
  end,

  drawTimer = function (x, y, value, att)
  end,

  getLastPos = function()
  end,

  drawFilledRectangle = function (x, y, w, h, flags)
  end,

  drawSource = function (x, y, source, att)
  end,

  drawCombobox = function (x, y, w, list, idx, flags)
  end
}


-- paint event handler for the frame that's called by wxEVT_PAINT
local function OnPaint(event)
  -- must always create a wxPaintDC in a wxEVT_PAINT handler
  local dc = wx.wxPaintDC(panel)
  local wrk_image = bitmap:ConvertToImage()
  wrk_image:Rescale(lcd_ratio * lcd_width, lcd_ratio * lcd_height, wx.wxIMAGE_QUALITY_NORMAL)
  local wrk_bitmap = wx.wxBitmap(wrk_image)
  dc:DrawBitmap(wrk_bitmap, 100, 5, true)
  wrk_image:delete()
  wrk_bitmap:delete()
  dc:delete() -- always delete any wxDCs created when done
end

-- Create a function to encapulate the code, not necessary, but it makes it
--  easier to debug in some cases.
local function main()

    -- create the wxFrame window
    local size = wx.wxSize(640, 220)
    frame = wx.wxFrame( wx.NULL,            -- no parent for toplevel windows
                        wx.wxID_ANY,          -- don't need a wxWindow ID
                        "OpenTx Taranis LUA emulator", -- caption on the frame
                        wx.wxDefaultPosition, -- let system place the frame
                        size,  -- set the size of the frame
                        wx.wxDEFAULT_FRAME_STYLE ) -- use default frame styles
    size:delete()

    -- create a simple file menu
    local fileMenu = wx.wxMenu()
    fileMenu:Append(wx.wxID_EXIT, "E&xit", "Quit the program")

    -- create a simple help menu
    local helpMenu = wx.wxMenu()
    helpMenu:Append(wx.wxID_ABOUT, "&About", "About the OpenTx Taranis LUA emulator")

    -- create a menu bar and append the file and help menus
    local menuBar = wx.wxMenuBar()
    menuBar:Append(fileMenu, "&File")
    menuBar:Append(helpMenu, "&Help")

    -- attach the menu bar into the frame
    frame:SetMenuBar(menuBar)

    -- create a single child window, wxWidgets will set the size to fill frame
    panel = wx.wxPanel(frame, wx.wxID_ANY)
    
    -- create MENU, PAGE and EXIT button
    local position = wx.wxPoint()
    local button
    position.x = 5
    position.y =20
    button = wx.wxButton( panel, MENU_BUTTON_ID, "MENU", position)
    position.y = 56
    button = wx.wxButton( panel, PAGE_BUTTON_ID, "PAGE", position)
    position.y = 92
    button = wx.wxButton( panel, EXIT_BUTTON_ID, "EXIT", position)
    
    -- create and clear bitmap
    bitmap = wx.wxBitmap(lcd_width, lcd_height)
    lcd.clear()
    
    -- create PLUS, MINUS and ENT button
    position.x = 530
    position.y =20
    button = wx.wxButton( panel, PLUS_BUTTON_ID, "+", position)
    position.y = 56
    button = wx.wxButton( panel, MINUS_BUTTON_ID, "-", position)
    position.y = 92
    button = wx.wxButton( panel, ENT_BUTTON_ID, "ENT", position)
    position:delete()
    
    -- connect the paint event handler function with the paint event
    panel:Connect(wx.wxEVT_PAINT, OnPaint)

    -- create a simple status bar
    frame:CreateStatusBar(1)
    frame:SetStatusText("Welcome to Taranis LUA emulator.")

    -- connect the selection event of the exit menu item to an
    -- event handler that closes the window
    frame:Connect(wx.wxID_EXIT, wx.wxEVT_COMMAND_MENU_SELECTED,
                  function (event) frame:Close(true) end )

    -- connect the selection event of the about menu item
    frame:Connect(wx.wxID_ABOUT, wx.wxEVT_COMMAND_MENU_SELECTED,
        function (event)
            wx.wxMessageBox('OpenTx Taranis LUA emulator V0.1\n'..
                            'Copyright 2015 - Marco Ricci',
                            "About OpenTx Taranis LUA emulator",
                            wx.wxOK + wx.wxICON_INFORMATION,
                            frame)
        end )
  
    -- center and show the frame window
    frame:Center()
    frame:Show(true)
end

main()

-- Call wx.wxGetApp():MainLoop() last to start the wxWidgets event loop,
-- otherwise the wxLua program will exit immediately.
-- Does nothing if running from wxLua, wxLuaFreeze, or wxLuaEdit since the
-- MainLoop is already running or will be started by the C++ program.
wx.wxGetApp():MainLoop()


Bonsoir Sacre100

Peut tu detailler ce que tu pense faire, ainsi que ce que tu attend du code que tu a poste.

Avant de se lancer dans la programmation tout azimuts je pense qu'il faut poser un plan de travail, les outils et programme que l'on va utiliser pour que tous ceux qui vont s'investir travaillent sur les memes choses.

Très bonne idée je vais suivre ce post avec attention

dans les chose a ajouter

un écran avec des capteurs virtuels sur les quels on peut simuler de valeur

et quelque chose de sympa pour positionner text et image

Merci

blonblon a écrit:Bonsoir Sacre100

Peut tu detailler ce que tu pense faire, ainsi que ce que tu attend du code que tu a poste.

Avant de se lancer dans la programmation tout azimuts je pense qu'il faut poser un plan de travail, les outils et programme que l'on va utiliser pour que tous ceux qui vont s'investir travaillent sur les memes choses.

Tu as raison, faut que je précise l'intention derrière tout ça.

Dans les grandes lignes, c'est d'écrire un module qui émule les fonctions d'OpenTx pour LUA :
- toutes les fonctions de base (getValue, getVersion, etc ...)
- toutes les fonctions lcd (lcd.drawPoint, lcd.drawText, etc..)
- et toutes les fonctions model (model.getInfos, model.setInfos, etc...)
et émule les appels que fait OpenTx :
- init()
- background()
- run(...)

De plus, il faudra définir une convention pour activer ce module lorsque le script n'est pas exécuté sur la radio ou dans le simulateur. Je pense à quelque chose comme cà en début et en fin de script :

Code:


    if not lcd then require "emulator" end
    ...
    ...
    ...
    if emulator then
       emulator.start({init=..., run=..., background=..., input=..., output=...})
    else
       return {init=..., run=..., background=..., input=..., output=...}
    end


L'idée c'est que lorsque l'on tourne avec l'émulateur dans un IDE comme ZeroBraneStudio, on puisse mettre des points d'arrêt, consulter des valeurs ou mettre de print(...) pour aider au débogage d'un script.

En dehors de la mécanique de base pour émuler le fonctionnement d'openTx, y'a une cinquantaine de fonction à développer.

En gros, voilà mes idées.

Au niveau language a quoi pense tu.

D'apres ce que j'ai vue sur le net et si je ne me suis pas trompe ZeroBraneStudio est payant.

Lua est fourni avec wxLuaEditor donc gratuit peut on l'utiliser.

Lua peut s'interfacer avec un language C ou C++ est-ce utile

djsyl a écrit:Très bonne idée je vais suivre ce post avec attention

dans les chose a ajouter

un écran avec des capteurs virtuels sur les quels on peut simuler de valeur

et quelque chose de sympa pour positionner text et image

Merci

Très bonne idée, surement pas facile à réaliser mais à retenir.

Une idée que j'avais, c'était l'exploitation des logs de la Taranis pour simuler un vol, il y a la télémétrie et les entrées, c'est déjà beaucoup.

blonblon a écrit:Au niveau language a quoi pense tu.

D'apres ce que j'ai vue sur le net et si je ne me suis pas trompe ZeroBraneStudio est payant.

Lua est fourni avec wxLuaEditor donc gratuit peut on l'utiliser.

Lua peut s'interfacer avec un language C ou C++ est-ce utile

Je préfère de loin un langage de script comme LUA (ou REBOL) car je ne suis pas du tout un fan des make qui me donnent des boutons.

ZeroBraneStudio est aussi gratuit si en échange on supporte le projet (en lui faisant de la pub, en participant au forum ou à la documentation, etc...).

Par contre, pour s'assurer que ce que l'on fait est compatible avec plusieurs IDE, c'est excellent si quelque-uns développent avec wxLuaEditor et d'autres avec ZeroBraneStudio ou un autre IDE.

Hello Sacre,

Excellente idée... Par contre, comme le propose Blonblon, il serait peut-être  bon de poser le clavier et de réfléchir un peu à ce que tu veux obtenir.
Les scripts LUA interagissent +- intimement avec la Taranis (selon le type de script).
Pour pouvoir tester un script il va donc falloir fournir un environnement de fonctionnement qui va simuler la Taranis ce qui ne va pas être une mince affaire, sans compter qu'il va falloir adapter cela au fur et à mesure qu'OpenTx évolue.
De plus, comme l'indique

Hors, il existe déjà un émulateur de Taranis, fonctionnel et maintenu par l'équipe d'OpenTx qui se trouve dans Companion ...
Dès lors, une piste de réflexion pourrait être de voir dans quelle mesure il n'est pas possible d'utiliser ce qui existe déjà à ce niveau et implémenter le débuggeur dans Companion, ce qui pourrait représenter moins de travail que d'émuler un environnement complet...
Mais ce n'est qu'une piste, bien évidemment...

Bons vols,

Coyotte

Je pense comme toi CoyotteDundee, cependant l'émulateur Taranis ne possede pas de debugger et LUA est interfacé avec un language C ou C++, ce qui n'est pas simple meme avec les sources.

L'idée de Sacre100 est plutot de faire un programme indépendant de compagnon qui utilise le debugger d'un editeur LUA, cependant il faut je pense réecrire les fonctions de gestion Taranis pas simple non plus.

si ça peut aider
http://www.eclipse.org/koneki

Après quelques recherches sur le net, il appert que LUA dispose d'une interface de débogage (Un moyen de retrouver de l'info lors d'une exécution, pas un IDE !) qui devrait permettre d'être notifié lorsque certains évènements se produisent...
(Appel de fonction, retour de fonction, ...)
Le "problème" va être de "figer" le fonctionnement de la radio lorsque l'IDE attends une instruction pour poursuivre l'exécution d'un script...
Pas simple...
De plus il faut trouver le moyen de simuler les paramètres d'entrée autres que les manches et les interrupteurs ( GPS, Vitesse, tenson de batterie, ...)
A ce titre, "rejouer" un fichier de log en tant que paramètres d'entrée (cf idée de Sacre ) serait une belle approche globale, indépendamment d'un débugger.

Coyotte

Vous mettez le doigt sur un point tout à fait pertinent :
- soit travailler sur le simulateur d'OpenTx pour y ajouter l'édition et le débogage des scripts
- soit développer une solution indépendante en s'appuyant sur les éditeurs existant.

Honnêtement, je ne sais pas ce qui est mieux, d'un côté, il faut comprendre dans les sources en C/C++ le fonctionnement du simulateur, de l'autre, il faut réinventer (partiellement) la roue.

Même si cela fait plus de 30 ans que j'écris occasionnellement des programmes en C, ce n'est pas ma tasse de thé et je préfère de loin LUA ou un autre langage de script.

Ce qui est bien en tout cas, c'est que cela fait émerger des idées, ça c'est bien.

Idée à creuser

Si je comprends bien, tu parles de faire un simulateur, le debugger LUA étant déjà présent dans l'IDE (que ce soit ZeroBrane Studio ou wxLUA)

Pour ma part, j'utilise le debugger de l'IDE pour faire les vérifications syntaxiques et le débogage de base en construisant des jeux de données spécifiques (soit sous forme de fonctions spécifiques, soit en chargeant des fichiers externes)

Ensuite, j'utilise le simulateur d'OpenTX en sortant quelques variables pour vérification.

Vouloir refaire le simulateur d'OpenTX va être très compliqué.

Une piste à creuser : la Taranis se connecte au PC comme une manette sur port USB. Est ce que le boulot ne consiste pas à créer une bibliothèque (API) qui reprend les paramètres de cette "manette" ?

EDIT :
Je n'ai pas encore toucher aux pages d'affichage via LUA, alors je parle peut être dans le vide absolu.
Est ce qu'il n'y a pas matière à faire une bibliothèque de composants plus simple à utiliser, du genre Afficher_Tension(x,y) qui dessine dans le rectangle, positionne en x,y, aligne à droite, etc. ?

Refaire un simulateur, non, non, en tout cas pas, je ne me vois pas écrire la lecture d'un fichier EEPE ni simuler toutes les phases, entrées, mixages, etc...

Par contre, si on pouvait déjà émuler toute la partie lcd, ça faciliterait la mise au point des écrans (telemetry, wizzard et function script) et ça serait déjà pas mal.

Récupérer l'entrée manette USB de la Taranis, ça c'est aussi une bonne idée à retenir.

Belov a écrit:
EDIT :
Je n'ai pas encore toucher aux pages d'affichage via LUA, alors je parle peut être dans le vide absolu.
Est ce qu'il n'y a pas matière à faire une bibliothèque de composants plus simple à utiliser, du genre Afficher_Tension(x,y) qui dessine dans le rectangle, positionne en x,y, aligne à droite, etc. ?

Malheureusement, la gestion des bibliothèques n'est pas activée dans OpenTx et l'usage du require provoque une erreur. J'aurais bien aimé avoir ça quand j'ai écrit predimrc.lua car l'expérience acquise à ce moment aurait pû être facilement réutilisé par la suite. Bon, c'est compréhensible vu le peu de mémoire disponible dans la Taranis mais c'est quand même dommage.

Pour ce qui est de récupèrer les infos via le port usb c'est tout a fait possible mais il faut utiliser un langage je l'ai fait avec une librairie " rawinput ".

A partir des sources du simulateur PC OpenTx je ne sais pas si cela est faisable assez facilement.

Content de ces quatre soirées car j'obtiens un premier résultat qui me plait bien.

C'est ici : www.quetzal.homepage.bluewin.ch/OpenTxEmulator.zip

Pour ZeroBraneStudio, il faut :
- décompresser le .zip dans le répertoire myprograms
- s'assurer que le "Project Directory" soit bien le répertoire OpenTxEmulator

Pour tester, il faut lancer le script telem1.lua
On peut mettre des points d'arrêt, surveiller des variables ou afficher le stack, c'est pas mal.
J'ai vérifié, il marche aussi dans le simulateur ce qui montre que le protocole d'appel semble correct.
Par contre, je n'ai pas vérifié si les print(...) boguent sur la radio, c'est encore à contrôler.
Parfois, ça bogue lors de la fermeture de la fenêtre, c'est aléatoire et je n'ai pas encore compris pourquoi.

Pour wxLua, je ne sais pas, je n'ai pas testé.

Bravo excellent début !

Vivement la suite

Hello !
Les grands esprits se rencontrent :

Lu sur le RC groups "Discussion LUA scripting - Technical discussion" :

First version of Companion with debug output is available at http://jenkins.open-tx.org/nightly-20/01_03_2015/companionInstall_2.0.14.exe

Il ne s'agit que d'une première version et il reste peut-être des soucis à résoudre...
Mais c'est un (bon) début...

Bons vols,

Coyotte

Je suis aussi tombé dessus hier soir, c'est très positif, ça va bien aider à déboguer les script. Je n'ai pas testé mais si la 14 ne sort pas dans quelque temps, je ferai un essais.

Bonjour,
je me pose la même question comment faire pour debogguer rapidement des scripts LUA destinés aux radios sous OPENTX/EDGETX.
Actuellement je viens d'acquérir un petit récepteur FRSKY SR6Mini (capable de fonctionner sur ACCST D16 V2 ou ACCESS), dans mon cas je suis sous ACCST D16 V2.  J'ai réussi à binder le récepteur avec ma radio TX16S carte interne flashé en  version  V13.3.33 (mm-stm-serial-aetr-v1.3.3.33.bin)  
(voir sujet à ce propos https://frskytaranis.forumactif.org/t14001-compatibilite-firmware-du-module-interne-4in1-sur-tx16s-avec-opentx.

Les scripts LUA (OPTX FrSky_AP_STAB_RX_v2.04.zip) fournis par FRSKY permettent de faire le calibrage et la configuration presque comme avec les anciens S6R/S8R). Et cela fonctionne bien (calibrage réussi avec script LUA AP Stab Rx Cali_OPTX.lua, paramétrage voies 1 à 6, et opération simulée de SELF CHECK avec script AP Stab Rx_OPTX.lua) pour le moment sur un banc d'essai pas encore d'avion/planeur équipé.

Mais en théorie (et cela semble bien être indiqué dans les spécifications FRSKY pour ce  recepteur), ce petit récepteur est équipé pour permettre d'utiliser les voies 7 à 11 avec ou  sans stabilisation en utilisant le port S.PORT/F.BUS). Mais seulement avec le protocole ACCESS et avec une radio sous ETHOS).
FRSKY founit un autre jeu de scripts LUA pour cela (ETOS FrSky_AP_SR6mini_STAB_RX_v2.06.zip avec 2 scripts: FrSky_AP_SR6mini_STAB_RX_v2.06/Scripts/SR6MiniE_Cali/main.lua pour la calibration
FrSky_AP_SR6mini_STAB_RX_v2.06/Scripts/SRX_Stab/main.lua pour le paramétrage complet (ensemble des voies 1 à 6 ET voies 7 à 11).
Sans être un expert en regardant le second script (paramétrage complet) on voit bien l'ensemble des paramètres possibles).
Mais bien sur ces deux scripts ne tournent pas sous OPENTX/ni EDGETX!!!!

Je voudrais donc m'inspirer du second scriptACCESS/ETOS FrSky_AP_SR6mini_STAB_RX_v2.06/Scripts/SRX_Stab/main.lua pour corriger le script LUA AP Stab Rx_OPTX.lua qui lui fonctionne sous OPENTX (mais avec seulement une partie du paramétrage voies 1 à 6).

Donc je cherche une solution pour arriver à déboguer intelligemment mes corrections dans le script LUA.
Je travaille bien sur avec l'environnement Companion  (sur PC sous LINUX) Companion pour OPENTX 2.3.8 (je sais que je ne suis pas à la dernière version) ou Companion pour EDGETX Version 2.9.2)

et après quelques recherches j'ai également installé ZEROBRANE Studio (qui permet le débogage à distance de scripts LUA!, j'ai tout lu et relu; cela fonctionne pour d'autres environnements de développement de jeux ou autres...). Pourquoi ne fonctionnerait-il pas pour l'environnement Companion/OPENTX (ou EDGETX)?  
A priori le simulateur Companion peut-être considéré comme un environnement de développement (il embarque un interpréteur de code LUA, et si j'ai tout compris c'est la version 5.2 qui est embarqué dans le simulateur Companion/ et sur le firmware de la radio aussi).

J'en suis à ce stade de mes investigations.
ce que je peux dire après quelques essais.
j'arrive à faire dialoguer un script modifié (voir plus bas la simple opération) tournant sur un interpréteur de code LUA local (j'ai chargé sous mon PC l'interpreteur LUA 5.2) avec Zero Brane Studio.
Par contre cette même modif ne permet plus le dialogue avec ZeroBrane Studio lorsque le même script est lancé sous le simulateur Companion!!!!

script corrigé pour permettre le debug à distance (remote debugging) (voir fichier complet attaché extension à corriger pour exécution .txt par .lua)
-- ligne ajoutée en début de script pour connexion en remote debugging avec ZeroBrane Studio
-- avec adaptation de l'environnement LINUX: variables globales LINUX ajoutées
--export ZBS=/opt/zbstudio
--export LUA_PATH="./?.lua;$ZBS/lualibs/?/?.lua;$ZBS/lualibs/?.lua"
--export LUA_CPATH="$ZBS/bin/linux/x64/?.so;$ZBS/bin/linux/x64/clibs52/?.so"

require('mobdebug').start()

--version modifiee pour seconde partie des parametres voies 7 à 11
local VALUE = 0
local COMBO = 1

local isHorus = (LCD_W == 480)
local pageCount = isHorus and 11 or 7
local edit = false
......

Bonjour,
Donc à la lecture de mes investigations est-ce que l'un d'entre vous aurait des pistes (ou simplement me dire que je fais totalement fausse route à cause d'une erreur d'interprétation de ce que j'ai pu lire auparavant)?

J'ai vu que Sacre100 avait également eu une démarche en partie similaire à la mienne (il y a quelques années de cela puisque le sujet date un peu!!)

Cordialement
didier

Bonjour,
une autre de mes reflexions.
on arrive (avec un peu de mal) à debugger sous Companion (avec le simulateur), en insérant dans le code source des scripts LUA des commandes print (xxxx info de debug), qui s'affichent dans la fenêtre de déboguage.  Cependant on arrive vite au limitation car on n'a aucune liaison avec le récepteur (et les capteurs éventuels) du modèle (et donc aucun retour Télémétrie).

Donc:
Pourquoi lorsque l'on est connecté en USB avec la radio en marche (mode mise à jour de la carte SD ou mode console de jeu simulateur), ne pourrait-on pas envoyer au module RF radio les ordres en provenance du simulateur (plutôt que ceux des manches de la radio et du modèle sélectionné sur la radio qui peut être différent de celui en cours de simulation sous Companion.

Le résultat:
Imaginons que le module RF dans cette configuration de simulation sous Companion d'un modèle en cours de paramétrage (ou de test) reçoive les voies (simulées) de ce qui se passe sous le simulateur de Companion: On pourrait ainsi voir sur le modèle réel les actions effectués sur le simulateur (puisque le récepteur recevrait les infos transmises par le module RF).
ET si en plus les données de télémétrie du récepteur (et des éventuels capteurs) étaient retransmises jusqu'au simulateur de Companion dans ce cas de figure.  Alors on pourrait d'une part faire un test en vraie grandeur de l'avion/du planeur. Et surtout ou pourrait voir le comportement des scripts LUA (en totalité).

Est-ce stupide d'imaginer une adaptation de OPENTX/EDGETX pour arriver à ce fonctionnement (finalement juste un réaiguillage des voies du simulateur Comapnion vers module RF (au lieu des manches) lorsque le cable USB est branché au PC avec Companion)?

Bonne année
didier