Auteur Sujet: Un nouveau composant prometteur : le VL6180  (Lu 25640 fois)

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2889
  • 100% Arduino et N
    • Voir le profil
Re : Re : Un nouveau composant prometteur : le VL6180
« Réponse #15 le: mai 15, 2020, 07:33:44 pm »
... donné pour une détection à plus d'un mètre (... de quoi réaliser des arrêts sur ralentis de rêve)

Mais je fais la même chose (un ralenti de rêve) avec de simples détecteurs de consommation de canton et un peu de mesures et de calculs (voir mon va-et-vient).
 ;) :D
Cordialement,
Dominique

simontpellier

  • Full Member
  • ***
  • Messages: 115
    • Voir le profil
Re : Un nouveau composant prometteur : le VL6180
« Réponse #16 le: juin 07, 2020, 07:14:05 pm »
@ Dominique... et à tout le monde !

Je suis allé re-regarder ce va-et-vient : vraiment super !
Il me manque quelques éléments pour comprendre ce qu'il est capable ou non de faire, par exemple si ça marche avec un convoi poussé ?

Et depuis j'ai avancé sur le capteur laser VL53L0X puisque j'en ai (enfin) reçu deux exemplaires.
Voici un petit compte rendu, rapide, plus une vidéo pour illustrer.

En résumé, il peut trouver son usage. Avec de grosses limites, mais pour ce qui est d'un joli arrêt sur ralenti il peut le faire !

Côté distance de détection (je parle uniquement pour l'échelle N) il faut compter 25cm grand max. Il vaut mieux compter sur 20cm. Mais sur une voie de garage où l'on est déjà, logiquement, en marche lente, ça permet de finir très proprement.
Autre défaut : le réglage de visée est extrêmement pointu ! Mais sa qualité, à l'inverse, c'est qu'il n'est pas significativement influencé par ce qui se passe à côté. Du moins dans ces 25cm utiles. Et même pas du tout dans les 10 derniers centimètres (sur la vidéo, les valeurs sont bien sûr des cm, plus facile à lire).
L'autre contrainte, il me semble mais je n'ai pas tout testé, c'est que le capteur doit être dans l'axe de la voie, ce qui le limite(rait ?) donc aux voies de garage... bien droites.

Voilà une idée de la taille une fois monté (à la sauvage)



Et le résultat sur vidéo : une première approche avec entrée dans la zone de détection à vitesse "relativement 'rapide" (pour une voie de garage), puis une seconde à vitesse nettement plus faible. Celle-ci avec un convoi sur la voie adjacente.

https://youtu.be/EF1OOA5fp7k/

C'est une toute première mise en œuvre, à peu près opérationnelle. Le code n'est pas sorcier : "photographie" de la vitesse PWM au moment où le train est détecté puis un ralentissement proportionnel à la distance restante jusqu'à la PWM limite inférieure de déplacement de la motrice (paramètre obligatoire, propre à chaque motrice, en EEPROM dans mon cas).

Merci par avance à tous les autres retours expériences, il y a forcément moyen de tirer de ce capteur mieux que ce premier essai.

Cordialement
PS

« Modifié: juin 07, 2020, 07:34:43 pm par simontpellier »

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2889
  • 100% Arduino et N
    • Voir le profil
Re : Un nouveau composant prometteur : le VL6180
« Réponse #17 le: juin 08, 2020, 08:47:14 am »
Merci pour ce compte-rendu détaillé  (mais il manque le schéma de montage, l’interaction avec la centrale et le programme qui pourraient intéresser d’autres modélistes).

C’est vrai que mon va-et-vient, tel qu’il est ne fonctionne pas avec un train en pousse, sauf à équiper le wagon de queue d’une lumière qui activerait les détecteurs de consommation.

Ce type de détecteur optique est effectivement intéressant pour une zone d'arrêt devant un heurtoir où le détecteur doit être placé bien en face de la voie. La question qui reste est de savoir quelles détections latérales peuvent perturber son rôle.

Merci encore d’avoir partagé cette expérience, je vois qu’il existe une version plus compacte du détecteur.

Bien cordialement
Dominique
Cordialement,
Dominique

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1691
    • Voir le profil
Re : Un nouveau composant prometteur : le VL6180
« Réponse #18 le: juin 08, 2020, 10:23:21 am »
Bonjour

Expérience intéressante et qui m'intéresse d'autant plus que je voudrais détecter la distance au fond des remises à locomotive, que l'arrêt soit automatique ou non reste à déterminer mais avoir juste un affichage est déjà pas mal.

Dans la vidéo on voit dans le second cas, lorsqu'une rame est présente sur la voie de garage voisine, une lecture de 34 ? cm ?
À quelle distance est la voie de garage voisine ? 40 mm ?
Cordialement

simontpellier

  • Full Member
  • ***
  • Messages: 115
    • Voir le profil
Re : Un nouveau composant prometteur : le VL6180
« Réponse #19 le: juin 08, 2020, 12:02:57 pm »
Bonjour,

Pour répondre à Jean-Luc :
- lorsqu'il n'y a rien à voir, la détection renvoie dans tous les cas une valeur de l'ordre de 35 à 40cm. Je suppose que vue la faible hauteur d'implantation, c'est le plateau qui rentre dans l'angle de vision. Mais dans le code, toute valeur supérieure à 25cm étant éliminée c'est donc sans effet.
- et je viens de mesurer l'entraxe entre mes deux voies : 39mm, très précisément.
Je précise, c'est aussi un élément de réponse à Dominique, que j'ai posé une voie "volante" de l'autre côté pour avoir deux convois encadrant celui visé par le détecteur, ceci sans influence sensible sur l'asservissement de freinage.
(je crois effectivement qu'un arrêt en fond de remise sera la meilleure utilisation possible de ce capteur)

et donc pour répondre à Dominique et compléter le précédent post :

- schéma de montage : bien qu'on voit 6 broches soudées je n'ai utilisé que VCC (3,3V mais prend le 5V), GND et le signal I2C (SDA/SCL, via un multiplexeur tca9548a mais tout à fait falcultatif), c'est tout.

- je crois que je réponds aux deux autres questions avec ceci ?
L'interaction à la centrale ? Conformément à la library, le détecteur s'intègre par :
   - la création d'instance(s)
       VL53L0X laserSensor = VL53L0X();   - et l'initialisation dans le setup :
     laserSensor.setTimeout(500);
if (!laserSensor.init())   {
  Serial.println("Failed to detect and initialize laserSensor!");
  while (1) {}   }
laserSensor.startContinuous(100);  // ( l'argument "100" reste à valider...) 

Puis dans le reste du code : Supposons, pour une section "voie de garage" (siding) donnée :
- d'une part, une fonction qui surveille qu'un CONVOI y est engagé (autrement dit, pas forcément une motrice), LEQUEL, son sens de déplacement et sa vitesse ;
   selon conditions, notamment que le convoi entre (et/ou "recule") sur cette section,  cette fonction en appellera une autre, dédiée par exemple aux sidings équipés de détection laser, laquelle contiendra une instruction de ce type :
engine[train].siding2(laserSensor.readRangeContinuousMillimeters() / 10) ;  // envoi d'une lecture à une instance engine[x] de la classe "HandleEngine"
- d'autre part donc : la classe "HandleEngine" qui gère les paramètres MOTRICE, accélérations, vitesse, arrêts etc ;
Dans cette classe il y aura :
  float _speedRef ;             // variable de calcul (signée)
  byte _latency ;               // sets a minimum PWM ("voltage") applied to the engine (!obligatoire! à prédéterminer pour chaque motrice) (pas "cste" car ajustable dans ma classe)
  (byte _velocity ;             // le pendant de "latency", bride la Vmax à une valeur réaliste (facultatif !)

public :
  float iniSpeed ;              // vitesse relevée au moment où le convoi entre dans le champ de prise en charge (25 cm... dans ma config) du laserSensor
  int speedRef ;                // consigne PWM (signée à ce stade)
  -----------------------------------------------------------------------------------------------------------
  (void siding1() ;             // éventuelle méthode dédiée aux sidings sans détection laser)
  void siding2(int laser) ;     // méthode dédiée aux sidings équipés

et donc la méthode siding2, qui recevra la mesure laser en argument et pourra ressembler à :
void HandleEngine::siding2(int laser)
  { if (joysXaxis > -200 || joysXaxis == -999)                 // ...ou autre chose, signifiant "vas-y, pas de reprise en manuel"
    { if (laser < 25 && joysXaxis < 200)
        { iniSpeed = min(iniSpeed peed, _speedRef) ;               // dans MON CAS, en marche arrière _speedRef augmente lorsque le train ralentit, d'où le "min", qui fige la vitesse initiale
         _speedRef = max(iniSpeed, (0.8*_latency + iniSpeed peed)*(laser-2)/23-0.8*_latency) ;  // idem, la valeur "max" correspond au plus petit des deux termes, le second étant un bête vitesse=a*laser+b
        }
      if ( abs(_speedRef) < 0.8 * latency)  { _speedRef = 0 ; iniSpeed = 0 ; }                       // extinction de la PWM, reset de iniSpeed
      speedRef = _speedRef ;
    }
  }

Quant-aux perturbations latérales, j'ai fait le test en encadrant la voie d'essai avec deux convois, sans perturbation sensible de la mesure.

Cordialement à tous
Phlippe
« Modifié: juin 08, 2020, 01:42:20 pm par simontpellier »