EZnov Neuron - Fonction attendues par les utilisateurs

[JcC 81]

Bonjour,

 

Un nouveau module apporte toujours son lot de nouvelles fonctions.

 

Qu'attendez vous comme fonctions ou nouveautés ?

 

Cdt

 

Jc

[helico33 289]

Bonsoir GODJC,

Sans répondre directement à ta question, j'en pose une autre: ce module remet en "position de sécurité" la machine ......Mais le fait-il quand il le juge nécessaire ou quand on actionne un inter ?

Donc, et tant qu'on y est: ne pourrait-il faire atterrir l'hélico tout seul?

Bien sûr, il n'y aurait plus trop place pour le pilotage mais cela en rassurerait certains....

[Myster Mask 92]

Un peu de data-loging peut-être, histoire de pouvoir investiguer au niveau des vibrations, de ce que le module demande aux servos (à quelle vitesse il les fait bouger, amplitude min et max, etc....). Ça pourrait permettre d'affiner la longueur des palonniers, de voir si des servos sont anormalement sollicités.

 

Un autre truc sur les gains: on les monte jusqu'à ce que toute la machine chope la gigite, puis on les rebaisse un poil. Il ne saurait pas repérer tout seul la gigite (mouvement oscillatoire non commandé) et se régler son gain son gain tout seul comme un grand?

 

Après, je ne sais pas. L'expresso? Le mouchoir automatique après crash? (facile, suffit de mettre une détection seuil sur le nombre de g)

[Kudzum 6]

Hugh,

 

la rigidité en statio pour faire du F3C.

A+

 

Boris

[JcC 81]

Salut,

 

Le governor désactivante depuis la radio (façon gov Align) afin de régler les moteurs nitro sans devoir utiliser l'ordi et changer les courbes de gaz.

 

Cdt

 

Jc

[Myster Mask 92]

Moi j'ai 2 requêtes:

 

1/ Sur le Brain, il faut ajuster les courses des voies à la radio pour qu'elles correspondent avec ce qu'attend le module. Je préfèrerais que ce soit l'inverse. On laisse tout à 100% dans la radio, on passe en mode calibration, on secoue les manches dans tous les sens (comme sur les simus), et c'est le module qui apprend. 

 

2/ Toujours sur Brain (forcément, je le prends comme point de comparaison, vu l'historique, et pour faire un produit qui se démarque), les gains sont des pourcentages. Or il me semble que dans la théorie du PID, les valeurs des paramètres n'ont pas de limite. Alors 100%, c'est 100% de quoi? Et si je veux mettre plus?

Pour moi, des pourcentages n'ont pas de sens. Les gains devraient être des valeurs. 

En tout cas, s'il y a une bonne raison pour utiliser des pourcentages, j'aimerais la connaître, parce que je me sens comme dans un carcan, même si je reconnais que ça marche.

[Myster Mask 92]

Je reviens à la charge sur l'auto-calibration, car si un constructeur veut marquer un avantage décisif sur la concurrence, là il y a de quoi faire!

 

La recherche ne s'est pas arrêtée au PID il y a 30 ans. Il est sorti des algorithmes d'asservissement auto-adaptatifs capables d'analyser la réponse des systèmes qu'ils contrôlent et de faire évoluer leur paramétrage tous seuls comme des grands pour maintenir un comportement attendu. C'est ultra-fort.

 

Il y a des avions (pas civils), tu leur plies un aileron, et ben les ordinateurs ils voient que la réponse est différente, ils adaptent les neutres et la loi de pilotage et le truc continue à voler droit comme si de rien n'était.

 

Chez nous ça pourrait se concrétiser par un module dont on programme des taux de roulis et la souplesse, que l'on monte dans n'importe quel sens de traviole sur l'hélico, et il se débrouille pour repérer les axes et ajuster ses gains. On augmente les rpm? On le change de machine? En un rien de temps ça se recalibre et ça donne le même comportement.

L'auto-adaptation, ça ce serait nouveau.

Parce qu'après tout, nous ce qu'on veut, c'est un comportement, un taux de roulis et un feeling. Ce qu'il y a dans le machin, PID, PI, ça ne m'intéresse que par ce j'y suis obligé, sinon c'est juste une prise de tête à régler, un "mal nécessaire". Dommage que l'on soit obligé d'aller tripatouiller dans ce cambouis informatique qui dépasse la plupart d'entre nous.

 

Les filtres et algorithmes existent. Le premier qui mettra ça en oeuvre prendra une sacrée longueur d'avance.

 

Mais bon, je rêve....

Mais je suis sûr que ça arrivera... Reste à savoir qui sera le premier...

[KoRn_BeeF 3]

Moi j'ai 2 requêtes:

1/ Sur le Brain, il faut ajuster les courses des voies à la radio pour qu'elles correspondent avec ce qu'attend le module. Je préfèrerais que ce soit l'inverse. On laisse tout à 100% dans la radio, on passe en mode calibration, on secoue les manches dans tous les sens (comme sur les simus), et c'est le module qui apprend.

Pour repondre, c'est exactement le cas du neuron sauf qu'aucune calibration n'est nécessaire

On reste sur un programme vierge sur la radio, aucun reverse et aucun end point à modifier

2/ Toujours sur Brain (forcément, je le prends comme point de comparaison, vu l'historique, et pour faire un produit qui se démarque), les gains sont des pourcentages. Or il me semble que dans la théorie du PID, les valeurs des paramètres n'ont pas de limite. Alors 100%, c'est 100% de quoi? Et si je veux mettre plus?

Pour moi, des pourcentages n'ont pas de sens. Les gains devraient être des valeurs.

En tout cas, s'il y a une bonne raison pour utiliser des pourcentages, j'aimerais la connaître, parce que je me sens comme dans un carcan, même si je reconnais que ça marche.

Oui le pourcentage n'est pas une valeur de PID mais juste le reflet de la plage pour lequel le module est configuré

Les valeurs par défaut ont été choisis pour que ça vol dès la mise en service sans avoir à y toucher dans la plupart des cas

Florent

[ricobert 0]

Bonjour, 

 

Pourquoi s'approcher d'un naza V2 avec GPS qui permettrait au pilote en cas  de rescue que la machine  se remette à plat et se stabilise à une altitude donnée. 

 

Et pourquoi un retour to home  qui pour un débutant qui s'est éloigné et ne voit plus dans quel sens est son hélico ( vécu dans mon ancien club ) lui permettrait de revenir quelque soit la position de la machine.... 

 

@+

[Otatiaro 6]

Hello,

 

Je vais essayer de répondre dans l'ordre :

 

- le rescue se fait avec un inter, ce n'est pas le neuron qui prend la décision mais le pilote, dans le destroyer il existera une option pour l'activer automatiquement grâce au baromètre.

- poser automatiquement : deux raisons, d'une il faudrait au moins un capteur de distance verticale pour savoir quand on pose, de deux c'est un problème de sécurité, une batteuse de 1m50 qui vient se poser seul en passant a hauteur d'humains, je ne tient pas à en prendre la responsabilité.

- data logging : c'est dans le destroyer, et moi qui ne croyait pas a l'utilité de la fonction, c'est vraiment chouette

- calibration récepteur : pas besoin, maintenant tout se calibre tout seul au démarrage en fonction du type de récepteur détecté.

- return to home et position hold via GPS : oui ca sera dans le destroyer

 

 

Ensuite la grande question du réglage automatique du module ... il y a plusieurs frein qui l'empêchent :

- Est-ce que tu accepterais qu'au premier décollage ta machine parte complètement en sucette (quitte a crasher) le temps que le réglage se fasse ? moi j'aurais grave les foies !

- Les méthodes connues renseignent sur les constantes de temps du système, etc., qui permettent d'en extraire un modèle et d'en déduire les paramètres idéaux dans une condition particulière. Deux problème à ca : "les paramètres idéaux" ne sont pas les paramètres qu'on veut, en FBL on cherche les paramètres "agréables aux manches", pas les paramètres idéaux, et c'est souvent assez différent, ensuite "dans une condition particulière" est très limitant, des gains qui marcheront très bien en stationnaire sans vent mettront la machine complètement en vrac en translation par exemple.

- Quand le système configure lui-même des réglages sans en avertir l'utilisateur, le comportement de la machine change. Ce qui sous-entend que en faisant deux fois les mêmes actions aux manches, on aurait potentiellement pas deux fois la même réaction de la machine, et ca c'est rédhibitoire pour la plupart des pilotes.

 

Donc ca viendra peut-être, mais ce n'est pas encore pour demain je pense (en tout cas j'en suis encore loin ... je préfère me focaliser sur "pas de réglages" que "réglages automatiques", je trouve ca encore plus sympa ).

 

Thomas.

[Myster Mask 92]

Ah ben en voila une belle réponse argumentée!

 

Je note avec bonheur que le grand frère "destroyer" devrait répondre à pas mal d'attentes. Très bien joué!

 

Tu dois être débordé de travail  (je me demande d'ailleurs ce que tu fais ici), mais quand ça se calmera il faudra que l'on reparle de l'auto-adaptatif, qui à mon avis est une évolution sur le fond.

Parce qu'il est évident que si j'ai forci le trait dans mon discours (si dans la théorie un module saurait se reconfigurer tout seul, il lui faudra un minimum d'informations  pour ne pas retourner la machine au premier décollage,le sens de montage me semble être un minimum), il y a quand même de la marge de progression.

 

D'après ce que tu as écrit, le destroyer a l'air déjà calé dans cette philosophie par rapport à la config radio: il s'y adapte tout seul. 

 

Comme tu l'as souligné "l'asservissement idéal" n'a pas de sens, mais le comportement idéal en a (pour un pilote donné, nous avons tous un ressenti perso). Au lieu de rentrer des paramètres d'asservissement, on paramètrerait donc un feeling désiré (comme sur simu), ce qui justement permettrait de conserver le même comportement quelque soit la machine, le nombre de rpm, etc.... La cible est bien d'atteindre une invariance de comportement.

 

Pour faire un parallèle parlant (que je sois compris de mes confrères profanes, qu'on ne me prenne pas pour un fou):

Avant on réglait des courbes de gaz pour obtenir un régime rotor à peu près constant pendant le vol, maintenant on utilise des régulateurs et des gouverneurs. Quand on utilise un ESC en mode governor store, c'est bien régime moteur qu'on règle une fois pour toute, et il le maintiendra même en cas changement de taille ou de nombre de pales, de type d'accus, pignons, etc... (dans une certaine limite évidemment, ils sont bien braves, mais ils font ce qu'ils peuvent avec ce qu'on leur donne). On a bien atteint une invariance du comportement de la motorisation. Mine de rien, ça a été une petite révolution.

 

PS:

L'algo n'aurait pas besoin d'être en permanence en train d'analyser, ça pourrait être un mode particulier de calibrage, à ne relancer qu'en cas de changement, à l'instar des modes gouverneurs des ESC qui démarrent en mode calibrage selon une loi "normale" et basculent en mode gouverneur une fois le régime stabilisé.

 

Bref, tu voulais des idées, et ben maintenant tu nous as sur le dos! 

Pas de pétrole, pas de pognon, mais des idées, ah ça on en a!

 

Ps de ps:

"Destroyer", je ne sais pas si c'est de bonne augure pour monter sur un hélico à plus de 1000€.... Mais je suis nul en marketing. 

Après le beast, pourquoi pas le beauty, après le brain, le cortex, après le spirit, le mind, après le Vbar, le Xcube.

Ok je te laisse bosser...

Mais si tu n'as besoin de rien, n'hésite pas à m'appeler.

Je serai toujours là pour critiquer ou demander la lune...

Mais je t'achèterai quand même un module....

[ricobert 0]

Hello,

 

Je vais essayer de répondre dans l'ordre :

 

- le rescue se fait avec un inter, ce n'est pas le neuron qui prend la décision mais le pilote, dans le destroyer il existera une option pour l'activer automatiquement grâce au baromètre.

- poser automatiquement : deux raisons, d'une il faudrait au moins un capteur de distance verticale pour savoir quand on pose, de deux c'est un problème de sécurité, une batteuse de 1m50 qui vient se poser seul en passant a hauteur d'humains, je ne tient pas à en prendre la responsabilité.

- data logging : c'est dans le destroyer, et moi qui ne croyait pas a l'utilité de la fonction, c'est vraiment chouette

- calibration récepteur : pas besoin, maintenant tout se calibre tout seul au démarrage en fonction du type de récepteur détecté.

- return to home et position hold via GPS : oui ca sera dans le destroyer

 

 

Ensuite la grande question du réglage automatique du module ... il y a plusieurs frein qui l'empêchent :

- Est-ce que tu accepterais qu'au premier décollage ta machine parte complètement en sucette (quitte a crasher) le temps que le réglage se fasse ? moi j'aurais grave les foies !

- Les méthodes connues renseignent sur les constantes de temps du système, etc., qui permettent d'en extraire un modèle et d'en déduire les paramètres idéaux dans une condition particulière. Deux problème à ca : "les paramètres idéaux" ne sont pas les paramètres qu'on veut, en FBL on cherche les paramètres "agréables aux manches", pas les paramètres idéaux, et c'est souvent assez différent, ensuite "dans une condition particulière" est très limitant, des gains qui marcheront très bien en stationnaire sans vent mettront la machine complètement en vrac en translation par exemple.

- Quand le système configure lui-même des réglages sans en avertir l'utilisateur, le comportement de la machine change. Ce qui sous-entend que en faisant deux fois les mêmes actions aux manches, on aurait potentiellement pas deux fois la même réaction de la machine, et ca c'est rédhibitoire pour la plupart des pilotes.

 

Donc ca viendra peut-être, mais ce n'est pas encore pour demain je pense (en tout cas j'en suis encore loin ... je préfère me focaliser sur "pas de réglages" que "réglages automatiques", je trouve ca encore plus sympa ).

 

Thomas.

 

Je ne parlais de se poser automatiquement mais de se mettre en stationnaire à une altitude donnée comme le fait un drone équipé naza 

Et le retour TO home sur le meme principe, en cas de panique pour un débutant on tire sur le manche et quelque soit la position de l'hélico il revient vers le pilote !

 

Le module sera dispo quand et ou ? 

 

Merci 

[Otatiaro 6]

Hello,

 

Oui Destroyer c'est le nom de code du projet, mais ca ne sera pas le nom définitif (on est ouvert aux propositions ).

 

Faire du position hold (rester en stationnaire), ou du return to home (sans poser, mais retour au point de départ avec une altitude de sécurité), c'est au programme avec le gros.

 

Thomas.

[shcfaro 0]

Hello Otatiaro

 

j'ai eu l'occasion d'avoir les retours des béta testeurs qui ont l'aire conquis par le nouveau module.

Personnellement je me considère toujours comme débutant et la fonction Autolevel est la raison qui fait que j'ai des Brain sur toutes mes machines.

J'récupéré un beau nombre de crash mais mes réflexes ne m'ont pas permis de tout rattraper 

 

Si je comprends bien, la grande version du module pourrait permettre de définir une hauteur de sécurité grâce au baromètre ?

En gros pourrions nous définir qu'en dessous de 2,5m (au choix) l'hélico se rétablis automatiquement à plat et prenne de l'altitude à la verticale ? Et si l'hélico est sur le dos, le faire monter, puis réaliser le flip pour éviter un retournement à basse altitude?

 

bref ces possibilités me font carrément rêver ! si ça se réalise , bye bye les brain 

 

Encore bravo pour ton travail

[Otatiaro 6]

Hello,

 

Il est très difficile (et très risqué !) de s'avancer aujourd'hui sur les fonctions a venir du Sentinel (yes, c'est le nom définitif maintenant ) ...

 

Par exemple on travaille en ce moment sur le baromètre, les résultats sont très sympas, mais le problème du baromètre c'est qu'il drift pas mal (il donne bien les variations d'altitude mais sur le long terme il peut se décaler de plusieurs mètres) et qu'il est très sensible à l'effet de sol.

 

Donc déjà SI on avait a terme un rescue automatique (je prend des gants ...), le plancher mini serait plutôt dans les 10m (pour compenser le drift potentiel ou un terrain pas droit, et laisser le temps de récupérer la machine).

 

On expérimente aussi avec des capteurs de distance (leddar et lidar lite) pour compenser les faiblesses du baromètre, mais c'est du bordel à emporter en plus, et ca a des inconvénients aussi (sur le dos le capteur de distance ne sert pas vraiment ).

 

Il va falloir être un peu patient, on doit aussi s'occuper au mieux de ceux qui ont déjà fait le pas avec le Neuron, travailler sur les nouvelles fonctions, assurer la production et les expéditions, etc. On a plusieurs projets à gérer, et les journées ne font que 24h (dont environ 14h par jour au boulot en ce qui me concerne ...).

 

Thomas.

[Myster Mask 92]

De Dieu...14h de boulot par jour.....

 

Les gars, la bonne nouvelle, c'est que Thomas a encore de la marge!

[Myster Mask 92]

Bon, histoire de faire un post constructif:

(une fois de temps en temps, ça ne peut pas nuire)

 

Je ne suis pas du tout fan des réactions automatiques. 

 

D'une part, il va falloir barder le truc de capteurs en tout genre, qui peuvent et vont tomber en panne, très probablement sans que l'on s'en aperçoive, et foutre une zone pas possible (à moins de mettre en place des boucles de monitoring et des redondances sur les éléments critiques, bonjour l'usine).

 

D'autre part, cela va générer plein d'effets indésirables à des moments inopportuns.

 

Dans notre monde très procédurier, je vois déjà des dépôts de plainte "Ben y'a écrit que la boîte que ça doit rattraper, et mon hélico est quand même allé au tas, ce n'est pas normal, Thomas doit me rembourser la machine!". Si si, y'a des gens comme ça.

 

Je vous laisse imaginer le nombre de mois, voire d'années d'investigations des crashs pour déterminer le vrai du faux, la vraie raison du crash, bug, capteur défaillant, ou mal monté, mal paramétré, initialisé, etc....  Je ne veux pas d'un truc comme ça qui prenne la main sur ma machine et la mette au tas à ma place. Je le fais très bien tout seul.

 

Je rappelle que le rescue remet la machine à plat, mais en aucun cas ne la fige en stationnaire ou n'est conscient de l'environnement. Imagine simplement que le truc se déclenche dans un virage ou une translation (en passant au-dessus d'un talus ou un arbuste par exemple), qu'on ne puisse plus changer la trajectoire de la machine et que celle-ci viennent percuter quelque chose... ou la tronche d'un gamin, pour faire plus clair....

 

Comme d'hab, rien ne sert d'espérer être plus fort que ceux qui ont réfléchi à ce genre de système depuis des décennies, avec toutes les implications légales incluses: l'aviation grandeur.

Et ben sur un Boeing (et même un Airbus, dont la réputation d'automate volant n'est plus à faire), les constructeurs sont à peu près d'accord sur les procédures: quand ça commence à merder sévère, les commandes aux pilotes! (et si ça finit mal, c'est pas moi m'sieur le juge, c'est le pilote )...

Pour info, ils ont testé bien des systèmes, et à la fin ils n'ont conservé que ceux dont ils ont pu prouver que la réaction était soit sans faille, soit ne pouvait pas rendre la situation pire que ce qu'elle n'est déjà (tellement elle est catastrophique, on ne peut plus dégrader la situation, donc on ne peut que l'améliorer). Par exemple: système anti-décrochage, descente d'urgence automatique sur les bizjets (qui croisent si haut que le temps de conscience en cas de dépressurisation est de quelques secondes), rudder boost pour aider à tenir la ligne de vol en cas de perte d'un moteur.

 

En fait, le problème intrinsèque d'une telle fonction, c'est de trouver les critères qui permettent de garantir que la situation ne peut pas être plus dégradée par une reprise automatique. Et accessoirement que ces critères soient traduisibles en logique de paramètres détectables par des capteurs à la fiabilité irréprochable, malgré l'idiot qui les emploie. 

 

Je reconnais qu'à titre expérimental, c'est un sujet passionnant.

A titre industriel... Chaud....

C'est peut-être pour ça que je n'ai pas développé beaucoup de neurones....

 

Je ne détiens pas la vérité, c'est juste un avis et des arguments, parmi d'autres, pour maturer le sujet.  

Et faire progresser la Science. 

On discute quoi....

J'aime bien discuter, comme ça ça se voit que je n'ai rien d'autre à foutre....

[Otatiaro 6]

Hello,

 

Je suis 100% d'accord avec toi, et c'est (avec l'aspect technique), le point clef pour le développement de nos produits : quoi faire quand.

On privilégie toujours la sécurité, on est capables de détecter quand un capteur part en sucette par exemple, et basculer automatiquement sur le mode manuel correspondant.

 

Pour un rescue vraiment efficace il faudrait à la fois la baromètre et le GPS (pour arrêter la machine, pas simplement la mettre à plat), c'est ce qu'on a sur notre drone autonome, mais je vois mal monsieur tout le monde monter sur son hélico tout le matos pour que ca marche (et même si c'est le cas ... en cas de mauvais montage qui est responsable ?). Même le GPS est dans les choux pour l'altitude (c'est pour ca qu'on intègre un capteur de distance, mais qui n'est utile que lorsqu'on est bien à plat).

 

Tu as du remarquer que je ne fais pas vraiment la promotion du rescue sur le Neuron, il marche très bien et les pilotes de test adorent me faire peur quand ils l'utilisent ... mais je ne suis pas personnellement fan non plus. Si je suis en train de vautrer, soit j'essaye de récupérer jusqu'au dernier moment, soit j'y vais franco dans le joie et la bonne humeur (c'est pas moi qui répare les hélicos d'EZNOV, on dit merci Fred  ).

 

Mais c'est une fonction qui est devenue plus ou moins standard, donc il faut le proposer (je suis un peu coupable, à l'époque de la sortie du BRAIN ce n'était pas vraiment standard ...).

 

Par contre en informatique on a coutume de dire que la plus grosse source de problèmes, c'est l'interface chaise - clavier. C'est pour ca que sur le Neuron et le Sentinel, on a essayé d'automatiser un maximum de choses (governor, récepteur, etc.). Tout ce que le Neuron peut configurer seul, c'est autant de moins à faire pour l'utilisateur, et autant moins de risques d'erreurs (l'erreur est humaine, c'est bien connu !).

 

Pour autant je me suis toujours opposé aux demandes du style les gains qui se règlent tout seul, on a pas aujourd'hui suffisamment de recul pour savoir le faire de façon systématique sans aucun risque (les méthodes type Ziegler Nickols impliquent de mettre volontairement la machine en oscillation et de regarder la fréquence d'oscillation ... perso j'ai pas envie que mes hélico se mettent à frétiller de leur propre initiative). Dans le Neuron en quelques clics on donne assez d'info au module pour configurer correctement des gains qui conviendront a 99% des hélicos et des pilotes, sans aucun risque.

 

Thomas.

[Myster Mask 92]

Et sur les 10h qui lui restent, il trouve le moyen de faire du forum....

Allez-y les gars, il bouge encore.

 

Allez, reste, ça n'en a pas toujours l'air, mais c'est de l'amour.

Dans le sens "sympathie". Ne va pas t'imaginer des choses.

 

PS:

​T'as un pb avec les hélicos qui ont la gigote?

Moi le mien avec son Brain le fait souvent. J'ai cherché partout, mais en fait ça vient des manches de ma radio, ils captent la vibration de mes genoux. On m'a dit qu'on ne pouvait rien pour moi.

[Otatiaro 6]

Allez je rentre chez moi, j'ai fini pour cette semaine

 

Thomas.

 

PS : je compte les réponses sur les forum comme du temps de boulot ... chacun son taf

[Myster Mask 92]

Ça y est j'ai trouvé. J'ai trouvé un cas, avec un critère détectable et non ambigu, où une remise à plat sans demande du pilote peut être défendue comme la meilleure des réactions: quand la liaison avec le pilote est interrompue, perte du signal radio.

Du point de vue du module (de Thomas devant Mr le Juge, pour caricaturer), il ne va à aucun moment contre la volonté du pilote, puisqu'il n'est plus en mesure de recevoir ses ordres. Le module n'est non seulement pas responsable, mais en plus a adopté la réaction réputée la meilleure (par le pilote lui-même, puisqu'il a pré-programmé cette réaction).

Ça serait un bon avertissement pour quelqu'un qui aurait des problèmes de portée de radio.

En prime, si on règle bien le pas et que la perte de liaison s'éternise, la machine pourrait descendre pas trop vite, voir même poser-pas-casser.

[KoRn_BeeF 3]

y a bon ça

 

plus besoin d'interrupteur ou de voie dédiée au rescue, il suffirait de couper la radio pour avoir le rescue

[Pitaud Jerome 1]

Bonjour

Sur quelle voie de la radio faut il programmer l inter 3 position pour les différentes configurations de vols ?

Merci jerome

[Otatiaro 6]

Je vous ai compris ! (à lire avec une grosse voix ).

 

Le firmware heli 1.0.2 est en route avec une voie de gain secondaire pour activer le rescue séparément.

Aussi normalement la fin bind satellites un peu pointilleux, et quelques bug fix mineurs.

 

Une mise à jour du terminal Maestro est aussi en cours, avec le fix pour le load/save des configurations sur PC, le texte des explications un peu plus gros, et normalement la fin des problèmes OpenGL pour les vieilles carte graphiques Intel.

 

Je vous tient au jus quand tout ca est disponible.

 

Thomas.

[JcC 81]

Good job.

 

Merci

jc