LUA Scripting sur V2.1.x

Protocole des récepteurs D, avec le hub...

D'accord la série D, j'étais pourtant dans un prog frsky_sport.cpp, donc dans le protocole s.port mais à priori pas dans le protocole hub 



C'est magique  
Je rentre cell1=4, cell2=4, cellNum=2
J'obtiens cellData= 0x7d07d020 que je rentre dans le simulateur qui me retourne Cels = 8.00V

C'est mon 1er prog en C++, j'ai pompé le bout de code là: http://www.rcgroups.com/forums/showthread.php?t=2245978
L’aéromodélisme, la Taranis, OpenTX, la curiosité, ça conduit à tout !

Reste + qu'à faire un utilitaire !

Joli

dev.fred a écrit:D'accord la série D, j'étais pourtant dans un prog frsky_sport.cpp, donc dans le protocole s.port mais à priori pas dans le protocole hub 

C'était mal séparé à l'époque, les 2 étaient un peu mélangés. Ca a changé depuis, c'est pour ça que je t'ai dis que tu te référais à une vieille version du code

J'ai écrit le petit outil qui permet de renseigner correctement le champs CELLS de la fenêtre de Télémétrie du simulateur déclenché par F4.
Difficile de faire un outil plus spécialisé pour un besoin très marginal.



Je me suis amusé à programmer en MVC++ express 2010, c'était le but .
La partie design de la fenêtre se fait de façon complétement graphique avec une toolbox, c'est facile grâce à quelques vidéos de tuto youtube.
Par contre la conversion d'un texte renvoyé par une textbox en nombre est une vrai galère.
J'ai trouvé 3 ou 4 façons de la faire mais dans express 2010:   this->textBox3->Text = System::Convert::ToString(cellData);
a fonctionné: bonjour la syntaxe !!

Code:


  float cell1,cell2,cell;
  _int16 cellNum;
  float::TryParse(textBox1->Text,cell1);
  float::TryParse(textBox2->Text,cell2);
  cell=cell1+cell2;
  if (cell == 0) {cellNum=0;}
  else {
  if ((cell1 > 0) & (cell2 == 0)) cellNum=1;  
  if ((cell1 == 0) & (cell2 > 0)) cellNum=1;
  if ((cell2 > 0) & (cell1 > 0)) cellNum=2;
  }

  _int16 cell1Data = cell1 * 1000 / 2;
  _int16 cell2Data = cell2 * 1000 / 2;
  _int32 cellData = 0;
  _int32 firstCellNo = 0;
  
  cellData = cell2Data & 0x0FFF;
  cellData <<= 12;
  cellData |= cell1Data & 0x0FFF;
  cellData <<= 4;
  cellData |= cellNum & 0x0F;
  cellData <<= 4;
  cellData |= firstCellNo & 0x0F;
  
  this->textBox3->Text = System::Convert::ToString(cellData);
  this->label5->Text = System::Convert::ToString(cellNum);
  this->label7->Text = System::Convert::ToString(cell);

Ca fonctionne très bien, mais les Lua plantent si je tente de récupèrer la valeur Cells :

getValue("CELLS")

Pareil !

Si je dé-commente cette ligne l'écran1 exécutant le script de la télémétrie est planté !
--lcd.drawNumber(130, 38, getValue("Cels"), PREC2+LEFT+SMLSIZE)

Si je mets
lcd.drawNumber(130, 38, getValue("CELLS"), PREC2+LEFT+SMLSIZE)

Je ne plante pas et j'ai 0 comme valeur (de même que si je fais getValue("toto"))

Alors que par ailleurs si j'affiche la valeur "Cels" dans l'écran2 de la télémétrie, c'est OK.

Ok, donc, ça ne vient pas d'un défaut de chez moi et ça m'arrange, ça me fait tout pareil, sur un écran chiffre, c'est bon, sur un écran Lua, ça ne va pas.

A part ça, ton message clair et concis avec exemple qui concernait le mélange VG + Script modèle me parle bien Français et devrait m'aider à progresser tout en douceur.

dev.fred a écrit:
Je pense qu'un exemple utilisant ton script de télémétrie avec simplement l'utilisation de la variable globale glipo pour afficher la valeur de Li-Po provenant d'un script model .../... Donc la combinaison des 2 scripts est générique sur les sources..../...


1000 merci.

Parfait et je fais d'1 pierre 3 coups : toi, moi (j'apprends mieux qd c'est bien écrit et le forum est moins bordélique que mes notes)  et peut être un tuto sur le forum
Sinon, attention de ne pas confondre les VGn avec une variable globale LUA (VG m'évoque les VGn) parce-que on peut également les utiliser pour passer des valeurs mais le problème, c'est qu'elles sont liées aux phases de vol)


Sinon
local CelsId = getFieldInfo("Cels").id
lcd.drawText(88,38, "Cels :",SMLSIZE,0)
lcd.drawNumber(130, 38, getValue(CelsId), PREC2+LEFT+SMLSIZE)

Plante pareil.

Si Marco est dans le coin, il pourra peut être confirmer ?

dev.fred a écrit:
local CelsId = getFieldInfo("Cels").id
lcd.drawText(88,38, "Cels :",SMLSIZE,0)
lcd.drawNumber(130, 38, getValue(CelsId), PREC2+LEFT+SMLSIZE)

Si Marco est dans le coin, il pourra peut être confirmer ?

J'allais essayer
CELL-SUM-MIN plante aussi
Cmin ne m'offre que 0 alors que Cmin sur écran chiffre (non Lua) fonctionne.

Décomposez vos lignes ça vous permettra de mieux trouver le problème.

local CelsId = getFieldInfo("Cels").id
local CelsValue = getValue(CelsId)
lcd.drawNumber(130, 38, CelsValue, PREC2+LEFT+SMLSIZE)

Ca vous permettra de voir quelle ligne plante.

Ensuite, vous pouvez ajouter des print qui vont s'afficher dans la console (F6).

Merci Marco,

Depuis la console de debug, il n'y a pas d'équivoque, j'ai un beau message d'erreur sur drawnumber :
Script    test1 error: /SCRIPTS/TELEMETRY/test1.lua:13: bad argument #3 to 'drawNumber' (number expected, got table)

et le problème disparait dés que je commente:
lcd.drawNumber(130, 38, getValue(CelsId), PREC2+LEFT+SMLSIZE)
ou:
lcd.drawNumber(130, 38, getValue("Cels"), PREC2+LEFT+SMLSIZE)

Grâce au print, je vois ce qui se passe:

print(getvalue("SWR"))
30
30
30
30

print(getvalue("Cels"))
table: 02FD5B60
table: 02FD5C78
table: 02FD5C78
table: 02FD5D90
table: 02FD5E08

Comme le message d'erreur l'indique, getvalue récupère une table au lieu d'une valeur!
Je vais créer une "issue" sur github.

N'ouvre pas une issue sur Github, ça me parait normal, si tu as cinq cellules, tu obtiendras une table de 5 éléments, si tu n'en as que 4, tu devrais en obtenir 4.

Il te faut faire une boucle pour traiter élément par élément.

[EDIT]
Pareil avec getValue("GPS"), tu obtiendras une table avec deux éléments : latitude et longitude
Et aussi pour la date et l'heure, tu obtiendras une table.
[/EDIT]

Sacre100, à ton avis il n'est donc pas possible de simuler Cels correctement ?
Un nouveau Companion avec les champs Cel1, Cel2 Cel3 etc.. ne peut-il être envisagé sur les futures versions ?

Heisenberg a écrit:Sacre100, à ton avis il n'est donc pas possible de simuler Cels correctement ?
Un nouveau Companion avec les champs Cel1, Cel2 Cel3 etc.. ne peut-il être envisagé  sur les futures versions ?

Je pense que c'est déjà le cas, il fautjuste comprendre comment c'est fait.

Fred a déjà donné un moyen de rentrer des valeurs correctes pour CELLS, maintenant, il comprendre ce que contient la table retournée par le getValue. Il suffit de mettre quelques print :

local celsValue = getValue("Cels")
print celsValue[1]
print celsValue[2]

Trop tard, je prends juste le risque de dire une bêtise (j'ai l'habitude, je fonctionne par erreurs corrigées) : https://github.com/opentx/opentx/issues/2915

Je n'ai pas essayé de simuler une lipo 3S ou plus; je peux juste tester une 1S ou 2S avec le code que j'ai, donc j'envoie un seul int32 qui peut coder 2 cellules (les bits 5 à 8 codent le nombre de cellules et ici c'est 1 ou 2).
Les écrans de télémétrie interprètent correctement la valeur fournit dans CELLS, la valeur de Cels correspond bien à la somme des 2 cellules, il n'y a que le getValue qui semble déconner.

Nous verrons bien.

Bon ben voilà un bout de code qui illustre la chose.

Code:

local function run(event)
  lcd.clear()

  local CelsInfo = getFieldInfo("Cels")
  if not CelsInfo then
    lcd.drawText(50,20, "CelsInfo = nil",SMLSIZE,0)
    return
  end

  local CelsValue = getValue("Cels")
  if type(CelsValue) ~= "table" then
    lcd.drawText(50,20, "CelsValue not a table",SMLSIZE,0)
    return
  end

  lcd.drawText(50,10, "#CelsValue :",SMLSIZE,0)
  lcd.drawNumber(130, 10, #CelsValue, PREC2+LEFT+SMLSIZE)
  lcd.drawText(50,20, "CelsValue[1] :",SMLSIZE,0)
  lcd.drawNumber(130, 20, CelsValue[1], PREC2+LEFT+SMLSIZE)
  lcd.drawText(50,30, "CelsValue[2] :",SMLSIZE,0)
  lcd.drawNumber(130, 30, CelsValue[2], PREC2+LEFT+SMLSIZE)
end

return {run=run}


Une chose que j'ai constaté, c'est qu'on ne peu pas utiliser la mécanique de getFieldInfo en dehors de la fonction run car le champs peu ne pas encore exister lors de l'initialisation du script si le capteur n'a pas encore été découvert.

[EDIT] NON, c'est faux l'id pour Cels, c'est 205
Ensuite, on voit que "Cels" est un capteur un peu spécial car quand tu fais un getFieldInfo("Cels").id, ben cela retourne nil au lieu de retourner un valeur.
[/EDIT]

Voilà, voilà ...

Sacre100 a écrit:
Une chose que j'ai constaté, c'est qu'on ne peu pas utiliser la mécanique de getFieldInfo en dehors de la fonction run car le champs peu ne pas encore exister lors de l'initialisation du script si le capteur n'a pas encore été découvert.

Ca n'a pas de sens, ce cas ne se présenterait qu'une fois... si la première fois que tu utilises ce modèle tu décides d'essayer de lancer le script avant d'avoir configuré la télémétrie sur la radio.

Kilrah a écrit:

Sacre100 a écrit:
Une chose que j'ai constaté, c'est qu'on ne peu pas utiliser la mécanique de getFieldInfo en dehors de la fonction run car le champs peu ne pas encore exister lors de l'initialisation du script si le capteur n'a pas encore été découvert.

Ca n'a pas de sens, ce cas ne se présenterait qu'une fois... si la première fois que tu utilises ce modèle tu décides d'essayer de lancer le script avant d'avoir configuré la télémétrie sur la radio.

Non, ça a du sens si l'on veut mettre un message indiquant à l'utilisateur qu'il doit configurer sa télémétrie pour que le script donne le résultat espéré. Et même avec un tel message, si tu mets ça à l'extérieur et que l'utilisateur configure sa télémétrie alors que le script est déjà chargé en mémoire, ça ne va pas mieux marcher et il ne va pas comprendre pourquoi.

Autant faire un truc propre si l'on souhaite partager ses scripts, ça évite bien des problèmes.

Sacre100 a écrit:...
[EDIT] NON, c'est faux l'id pour Cels, c'est 205
Ensuite, on voit que "Cels" est un capteur un peu spécial car quand tu fais un getFieldInfo("Cels").id, ben cela retourne nil au lieu de retourner un valeur.
[/EDIT]

Encore faux, les Id peuvent changer en fonction de l'ordre de découverte, donc non seulement, les capteurs peuvent ne pas avoir encore été découverts mais en plus leurs noms et leurs Id peuvent varier. Il faut en tenir compte dans l'écriture des scripts LUA.

A noter quand même que Cels est un capteur un peu spécial qui me semble-t-il ne peut pas être créé manuellement. Il faut passer obligatoirement par la détection du capteur sinon ça ne marche pas bien.



Je ne sais pas s'il y a d'autre capteurs dans ce style, a voir.

Sacre100 a écrit:Non, ça a du sens si l'on veut mettre un message indiquant à l'utilisateur qu'il doit configurer sa télémétrie pour que le script donne le résultat espéré.

C'est un prérequis d'office pour tous les scripts lua en 2.1, donc ça va "de soi". C'est bien de le mentionner dans la doc, mais ça sert pas à grand chose de faire quelque chose dans le script lui-même. Les outils pour le faire bien dans le script n'existent pas encore à ce stade.

Heisenberg a écrit:Sacre100, à ton avis il n'est donc pas possible de simuler Cels correctement ?
Un nouveau Companion avec les champs Cel1, Cel2 Cel3 etc.. ne peut-il être envisagé  sur les futures versions ?

Pas besoin d'un nouveau OpenTx / Companion, ça existe déjà.

En fait, dans la télémétrie, on peut créer des champs calculés comme ça (cas de la première cellule) :



En indiquant :
- que c'est un capteur de type "Calculé"
- que la formule est "Elément"
- que le capteur d'élément est "Cels"
- que l'index de l'élément est 1 (ou 2, ou 3, ou 4, ou 5, ou 6)

Donc en fait dans un script LUA, on peut soit accéder à "Cels" et exploiter la table retournée par getValue, soit faire des getValue sur ces champs calculés mais je vous laisse vérifier, il est déjà tard.

Sacre100 a écrit:En fait, dans la télémétrie, on peut créer des champs calculés comme ça (cas de la première cellule) :



En indiquant :
- que c'est un capteur de type "Calculé"
- que la formule est "Elément"
- que le capteur d'élément est "Cels"
- que l'index de l'élément est 1 (ou 2, ou 3, ou 4, ou 5, ou 6)

Donc en fait dans un script LUA, on peut soit accéder à "Cels" et exploiter la table retournée par getValue, soit faire des getValue sur ces champs calculés mais je vous laisse vérifier, il est déjà tard.

Ça revient à utiliser le même système que pour Celmin ou Celmax, et les appels de ces valeurs plantent Companion. Ca marche sur la radio mais pas en simu. Il serait quand-même un peu plus simple d'avoir les champs de chaque cels dispo à remplir sous Companion. Les possesseurs de cette radio ne sont pas tous à l'aise avec la prog et n'ont pas tous un Dev.Fred sous la main pour coder un utilitaire ni même un forum comme celui-ci avec toi et les autres pour aider à s'en sortir.

Je vois pas mal de Turnigy aussi qui tournent sous OpenTX, elles sont rarement utilisées à + de 10 ou 20% de leurs possibilités faute de simplicité. Tout ça pour dire que si c'est possible avec complications, une simplification permettrait à pas mal d'utilisateurs de bénéficier de plus de potentiel d'OpenTX plus ou moins réservé à ce jour à une population curieuse, qui a du temps et qui comprends vite un minimum de logique.

Sacre100 a écrit:
N'ouvre pas une issue sur Github, ça me parait normal, si tu as cinq cellules, tu obtiendras une table de 5 éléments, si tu n'en as que 4, tu devrais en obtenir 4.
Il te faut faire une boucle pour traiter élément par élément.
[EDIT]
Pareil avec getValue("GPS"), tu obtiendras une table avec deux éléments : latitude et longitude
Et aussi pour la date et l'heure, tu obtiendras une table.
[/EDIT]

Tu as raison, c'est pas un bug mais une feature, c'est fait exprès mais peu de monde est au courant que dans ces 3 cas, getvalue retourne une table : https://github.com/opentx/opentx/pull/2826
J'ai essayé de rentrer une des valeurs de la table dans CELLS, il ne comprenait pas, ce n'est plus du codage s.port apparemment.

Donc pour simuler la valeur de Cels dans LUA , il faut un programme pour coder au format s.port, non publié, la valeur à entrer dans la case CELLS du simulateur de télémétrie :

Code:

_int16 cell1 = 5;
_int16 cell2 = 0;
_int16 cellNum=1;

  _int16 cell1Data = cell1 * 1000 / 2;
  _int16 cell2Data = cell2 * 1000 / 2;
  _int32 cellData = 0;
  _int32 firstCellNo = 0;

  cellData = cell2Data & 0x0FFF;
  cellData <<= 12;
  cellData |= cell1Data & 0x0FFF;
  cellData <<= 4;
  cellData |= cellNum & 0x0F;
  cellData <<= 4;
  cellData |= firstCellNo & 0x0F;
return cellData;


Et un autre programme pour décoder la valeur dans LUA:

Code:

local cellValue = "unknown"
local cellResult = nil
local cellID = nil

local function rnd(v,d)
    if d then
     return math.floor((v*10^d)+0.5)/(10^d)
    else
     return math.floor(v+0.5)
    end
end

local function getTelemetryId(name)
    field = getFieldInfo(name)
    if field then
      return field.id
    else
      return -1
    end
end

local function init()
  cellId = getTelemetryId("Cels")
end

local function background()
  cellResult = getValue(cellId)
  if (type(cellResult) == "table") then
    cellValue = ""
    for i, v in ipairs(cellResult) do
      cellValue = cellValue .. i .. ": " .. v .. " "
    end
  else
    cellValue = "telemetry not available"
  end
end

local function run(e)
  lcd.clear()

  lcd.drawText(1,1,"OpenTx 2.1.1 testing",0)

  lcd.drawText(1,11,"Cels:", 0)
  lcd.drawText(lcd.getLastPos()+2,11,cellValue,0)
  lcd.drawText(1, 56, "Mem:", 0)
  lcd.drawText(lcd.getLastPos() + 4, 56, rnd(collectgarbage("count"), 4), 0)
end

return{init=init,run=run,background=background}

C'est à peu prêt inutilisable donc.

Salut Heisenberg,
Je ne sais pas si tu lis l'anglais mais j'ai eu une réponse à mon "issue" sur github : https://github.com/opentx/opentx/issues/2915

Pour le moment la simulation de CELLS, GPS-T et GPS-LL dans un script LUA, c'est bon pour les geeks !

Es-tu arrivé à avoir quelque chose de correct avec GPS-LL, ça m'intéresse pour adapter mes scripts.