Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - simontpellier

Pages: 1 ... 5 6 [7] 8
91
Discussions ouvertes / Re : Clavier analogique multiple
« le: août 23, 2020, 06:03:29 pm »
Hello Antoine,
ah ben je suis heureux que ça marche ! Un peu surpris car sans bien savoir ce que ça fait ça me semble miraculeux... mais finalement pas surpris car je n'avais en fait pas besoin de le savoir !
Car c'est TON code et rien que ton code, je n'ai rien fait d'autre que l'organiser différemment.

Avec deux N.B. :
- dans le zip joint j'ai ajouté, juste pour la bonne forme, un "destructeur" car utiliser "NEW" implique de l'allocation dynamique de mémoire, qu'il faut absolument libérer si nécessaire sinon à force d'allouer sans libérer on crée de la "fuite de mémoire". Ça n'est pas le cas dans le présent sketch, on alloue une fois dans le setup et tout se libère automatiquement avec la fermeture du programme. Mais je ne sais pas si tu ne vas pas intégrer ce bout de sketch dans un autre, ni alors, comment, d'où l'avertissement en commentaire.
- et à cause de cette allocation dynamique qui implique des pointeurs pour la localiser, la fonction "switch" de ton code d'origine ne peut pas être utilisée (je saurai peut-être un jour expliquer pourquoi !), voilà pourquoi elle est remplacée par trois "ifs"

C'était vraiment un cas d'école ! Idéal pour te permettre de voir très vite comment passer de ta version à celle-ci car encore une fois, c'est ton code dans les deux cas.
Amicalement
Philippe

92
Bus CAN / Re : Mémoire circulaire à l'émission pour un Bus Can
« le: août 22, 2020, 04:46:52 pm »
Bonjour Patrick,
Peut-être suis moi aussi bon pour passer à une mémoire circulaire ?
J'ai en effet un arduino qui pousse des données plus vite qu'un de ses clients ne les consomme, ce qui fait que je sature très vite le buffer de réception et que le code se bloque. Je n'ai trouvé aucune solution pour consommer plus... produire moins oui, mais c'est pas vraiment le but !
"RingBuffer" est-il bien la solution à ça ? (gain de temps certain pour moi si vous me le confirmez !)

si oui, la seconde question est plus chère !... en regardant rapidement les méthodes (ainsi que le projet "labox" de Thierry), je ne vois pas comment greffer ça pour gérer des buffers CAN de MCP2515...
si vous l'avez fait et que je puisse avoir ce travail comme exemple, le gain de temps exploserait !

Merci par avance
cordialement
Philippe


93
Discussions ouvertes / Re : Clavier analogique multiple
« le: août 22, 2020, 04:25:44 pm »
Bonjour Antoine,
n'étant pas (pas encore je veux dire) un champion du C++ le problème, je le vois pas comme ça... d'autant qu'il faudrait faire le montage pour tester !

Mais une façon de régler ça serait probablement de sauter le pas vers un code "orienté objet" avec une classe très simple, par exemple "Poussoirs", dont tu lancerais 5 objets/instances "huit",
Poussoirs huit[5] la classe contenant deux méthodes :
int Poussoirs::lirePoussoirs()
  {...
      return nouvelEtatPoussoir ;
  }

byte Poussoirs::lireEvenement(int *numPoussoir)
  {...
     return evenement ;
  }

Si ça te branche on peut en parler.
cordialement
Philippe

94
Attention Dominique,
ce NOA1305 fait uniquement détecteur d'ambiance et pas détecteur de proximité ; ça n'est pas le même capteur.

95
Bonjour,

Je viens compléter et clôturer (pour ma part du moins) ce fil avec le rapport de mes dernières expériences concernant ce capteur CJMCU-3216.

Et ça n'est que du bon, avec un fonctionnement absolument impeccable.
Ceci en combinant bus I2C et bus CAN.

Ici une parenthèse pour commencer par remercier Jean-Luc sans qui etc... mais c'est "trop" vrai : sans ses articles, les chances de découvrir le CAN et surtout que je parvienne à le mettre en œuvre étaient quasi nulles !

Un "bus" I2C donc, ou plutôt un nœud, pour regrouper les détecteurs sur un multiplexeur TCA9548A (puisque l'adresse des détecteurs n'est pas configurable), en interface avec un nano "satellite", et autant de satellites que de besoin dans une logique de proximité nano-détecteurs. Chaque nano lui-même connecté pas bus CAN pour remonter ses données au "maître".
(une autre solution pour éviter le multiplexage, et à condition que le code ne demande pas une lecture en continu, pourrait être de créer une instance "AP3216" par détecteur et de les utiliser chacun en interruption...? je n'ai pas testé).

En résumé, voici les avantages de ces modules :
- la discrétion : pas plus large qu'une voie N, ils se glissent dessous, le détecteur en lui-même se loge entre deux traverses, au final ils sont quasiment invisibles (peuvent probablement l'être avec un ballastage)
- ceci, allié à leur coût modique, permet d'en mettre "à volonté" : un à chaque frontière de section/canton pour la gestion du trafic + (par exemple) deux autres, de part et d'autres, pour un arrêt précis au signal après approche préalable en marche lente. Ceci sans créer "une forêt" comme ç'aurait été le cas avec des barrières IR classiques.
- autre énorme avantage sur les barrières : la détection est suffisamment fine pour qu'un convoi à l'arrêt reste détecté même lorsque c'est un attelage qui est en surplomb du détecteur. Le risque de "trou" est donc éliminé.
- l'utilisation d'un bus CAN est certes une contrainte, mais remboursée par les communications double-sens qu'il permet par ailleurs et, surtout, elle élimine les aléas des transmissions I2C. Le comportement global est exempt de toute fausse détection au point que tout filtrage logiciel est devenu inutile.

Je pense donc pouvoir répondre définitivement par l'affirmative à la question "CJMCU-3216 : Le détecteur de proximité parfait ?"

Ce qui me semble une excellente nouvelle dans le domaine de la détection!







96
Trucs & astuces / Re : Câblage I2C et servos
« le: juillet 26, 2020, 07:05:35 pm »
... une solution extrême
https://shop.mchobby.be/fr/cartes-breakout/1079-extension-bus-i2c-differentiel-longue-distance-3232100010796.html

Mais bon à savoir tout de même, non?
(pour encore mieux apprécier le CAN)

97
Trucs & astuces / Re : Câblage I2C et servos
« le: juillet 15, 2020, 01:48:21 pm »
Bonjour,

étant ces temps ci particulièrement sensible à ce qui touche à l'I2C, j'étais obligé de regarder de quoi il était question !

et constater que je ne sais pas répondre aux questions, sauf pour la dernière : oui bien sûr, sous réserve que j'ai bien compris la question, peu importe que la tension provienne d'un nœud ou d'une antenne. Et aussi confirmer que, en effet, l'I2C est chatouilleux.
Pour le reste... chaque configuration ayant sa spécificité, j'imagine qu'il n'y a pas de réponse absolue. Je peux néanmoins confirmer qu'un bus I2C n'est pas sans surprises, mais je vois que vous êtes averti. Dans mon cas pourtant, ça n'est jamais sur le PCA9685 que j'ai eu des soucis.

Je signale au passage qu'il y a sur LOCODUINO des articles sur un sujet "satelliteV1" qui donnent à la fois à réfléchir sur l'organisation générale du contrôle commande et une parade possible aux problèmes récurrents des bus I2C. Solution qui répond de plus au souci de réduction du câblage.

Bonne lectures

98
Infos et bonnes affaires / Re : Capteur de proximité VL6180X
« le: juillet 10, 2020, 11:43:02 pm »
Bonsoir Tony
à peu près la même expérience...
Petit réseau de test équipé au départ avec des barrières IR (huit). Sauf que je n'avais pas pensé à la judicieuse mise en travers "haut-bas"...
Ça marchait... ou pas, mais au moins c'était clair : le montage n'étant guère stable, quelque chose avait bougé. Après... pas évident à régler quand même ces barrières !

Et puis passage aux CJMCU-3216 sur lesquels j'ai posté mes commentaires. Produit absolument parfait en lui-même, mais avec juste le défaut de communiquer via I2C, avec les soucis que tout le monde rapporte. Je m'en suis néanmoins tiré avec des lignes de code supplémentaires mais me voilà bien inquiet pour entreprendre un "vrai" réseau avec détection sur la base de ces modules.
Alors "adieu la belle technologie" ?
Et retour aux barrières IR, pas vraiment gracieuses avouons le... ?

Je pense à une solution mixant I2C et bus CAN (que j'ai juste commencé à expérimenter, c'est donc théorique mais sans rien de particulier)
- constituer des groupes avec ces détecteurs, idéalement de 8 (*) mais pourquoi pas moins, groupes basés sur la proximité géographique ;
- chaque groupe émettant sur un indispensable multiplexeur TCA9548A (* à 8 canaux), indispensable du moins pour les modules CJMCU-3216 qui ne sont pas adressables, pas indispensable dans le cas des VL53L0X qui le sont ;
- chaque groupe (ou chaque multiplexeur) étant lu par un NANO dédié ;
- et chaque NANO doublé d'une carte d'interface CAN, déversant sur un réseau CAN.
Une architecture modulaire donc et avec des composants très bon marché.

Ça devrait marcher qu'en penses tu ?
Si je parviens à mettre en pratique, je tam-tam ça tout de suite. (Mais ça n'est pas pour demain !)

99
Infos et bonnes affaires / Re : Capteur de proximité VL6180X
« le: juillet 10, 2020, 12:47:45 pm »
@ Tony04 :

Au sujet de ce problème de double adressage, connais tu ces tutos ?




100
Composants / Re : CJMCU-3216 : Le détecteur de proximité parfait ?
« le: juillet 09, 2020, 03:20:55 pm »
Bonjour,
Je reviens sur ce sujet pour le compléter d'un retour d'expérience plus approfondi. (et en profiter pour glisser une question... bête de bête j'en ai peur)

D'abord le REX sur les CJMCU-3216. En condensé : totalement positif... mais.
Totalement positif car du point de vue du capteur la fiabilité/reproductibilité est sans faille. Réellement.
Les problèmes, car il faut le dire il y en a, proviennent du bus I2C. Parasitages et amplification des problèmes (je crois... je n'affirme pas) du fait de l'usage de multiplexeurs I2C "TCA9548", indispensables de mon point de vue pour profiter réellement de l'intérêt de ces capteurs CJMCU-3216, c'est à dire en en faisant un large usage.

Ces problèmes ont-ils une solution ?
Ne pouvant parler que de mon expérience, il ne m'est pas possible de donner une réponse absolue car elle sera probablement propre à chaque configuration du réseau.
Je peux néanmoins dire qu'il est possible de parvenir à un fonctionnement parfait moyennant un bon filtrage. Dans son principe, celui qui fonctionne pour moi devrait pouvoir s'adapter avec profit.
Avant de le détailler, je dois probablement préciser que j'ai choisi une logique de gestion par canton, en analogique donc. Un détecteur situé à chaque frontière de canton commande :
- l'application du courant traction spécifique au convoi concerné sur le canton C+1 dès détection d'un convoi, qu'il soit poussé ou tiré ;
- l'extinction du courant traction sur le canton (devenu) n-1 dès que la totalité du convoi à franchi le détecteur (extinction légèrement temporisée).
Par ailleurs, et fort d'une expérimentation concluante, je pense tripler le nombre de détecteurs de façon à avoir en amont de chaque détecteur frontière un autre détecteur, pour ralenti final et arrêt au signal.

C'est l'ensemble de ces détecteurs, ou plutôt je le redis, des transmissions de données, qui demande à être filtré. D'abord par l'installation de condensateurs sur chaque alimentation canton, par précaution mais avec un effet pas vraiment vérifié.
Et essentiellement par un indispensable filtrage logiciel, en trois points.

Suivant l'occupation des cantons par les convois, une fonction en boucle scanne chaque canton (toutes les 25ms dans mon cas) à la recherche d'une éventuelle détection : un train T sur un canton C entraînera la surveillance du détecteur frontière entre le canton C et le canton C+1 pour CE train.

Une première détection (par seuil "haut" réglé chez moi à 200) étant censée mettre un canton donné sous tension (et l'affecter à un convoi précis), cette détection est-elle réelle ?
- dans tous les cas, une fonction de "switch" vers le canton suivant est appelée ;
- une variable booléenne "switched" enregistre ce fait.
- faute de pouvoir décider de la réalité de la détection, la fonction de switch rejette la détection mais enregistre dans une variable booléenne "IRDtoFilter[train]" le fait que le détecteur D a, pour le train N, été vu "détectant" et le met sous surveillance.

A la loop suivante, de deux choses l'une : soit le train est en pleine voie. Il n'y a donc pas de seconde (fausse) détection (cas heureusement jamais rencontré) et il faut donc le concrétiser en annulant la surveillance du détecteur fautif :

=> par exemple en tête de la fonction en loop :
    switched[train] = false ;
et à la fin de la fonction en loop :
for (byte i(0) ; i < TRAINS; ++i)
     { if (switched[i] == false)          // pas de switch pour le train i dans la boucle => une éventuelle fausse détection doit être effacée
        { if (IRDtoFilter[train] == frontIRD[train] )    // frontIRD : numéro du détecteur de sortie du canton, compte tenu des positions d'aiguille et du sens de circulation
            { firstDetection[i][IRDtoFilter[i]] = true ;   // la prochaine détection sera à nouveau vue comme étant la première
              IRDtoFilter[i] = 222 ;                             // aucun détecteur 222 ! signifie qu'il n'y a aucun détecteur à surveiller...
            }
        }
     }

- soit le train est SUR un détecteur et, dans ce cas deux loop, consécutives passeront toutes deux par la fonction de switch qui est alors chargée de faire le ménage :
void switch_to_section(byte train, byte currentSection, byte newSection, byte wichIsCutIRD)
  { // filtrage des fausses détections : second test : si 1er passage, mise sous surveillance du détecteur responsable et sortie de la fonction / premier test : si en seconde lecture ce détecteur est < seuil, il a été filtré et redevient vierge pour action à la seconde détection.
    switched[train] = true ;
    if (wichIsCutIRD != IRDtoFilter[train] && proxSensor.getProximity() < proxThreshold)
      { firstDetection[train][IRDtoFilter[train]] = true ;
        IRDtoFilter[train] = wichIsCutIRD ;
      }     
    if (firstDetection[train][wichIsCutIRD] == true)
      { IRDtoFilter[train] = wichIsCutIRD ;
        firstDetection[train][wichIsCutIRD] = false ;
        firstDetection[train][IRDtoFilter[train]] = false ;
        return ;
      }

       // suit la fonction de switch en elle-même
      }

- troisième patch de filtrage :
il arrive aussi qu'un canal I2C, aléatoire, se bloque sur une valeur... également aléatoire.
Pour pallier ce problème, chaque "loop" reset un des détecteurs, à tour de rôle :
    reset = (reset +1)%NbDeDetecteurs ;
    tcaselect(reset) ;
    proxSensor.init() ;
    proxSensor.setMode(PS);

A noter que le seul paramétrage "proxSensor.setMode(PS)" m'a finalement paru nécessaire et utile.

A l'usage donc, une fois ce filtrage OK :
- toute vraie seconde détection au dessus d'un seuil "HAUT" applique le courant traction du train N au canton C+1 et initialise une temporisation liée à ce détecteur ;
- ensuite, toute détection au dessus d'un seuil "BAS" (20 dans mon cas), réinitialise une temporisation qui signale ce détecteur comme "actif" ,
- à l'extinction de cette temporisation, cad le convoi passé, le courant traction est coupé sur le canton "arrière" qui est libéré pour un autre convoi.
De cette façon, et même convoi à l'arrêt avec un attelage en surplomb du détecteur, LE CONVOI RESTE VU ET AFFECTE AUX DEUX CANTONS encadrants. Ceci a comme avantages :
- de pouvoir repartir dans les deux sens, que la motrice ait été en poussé ou en tiré
- de conserver en permanence un feu de fin de convoi (convoi roulant s'entend ! on parle ici d'analogique).

(Accessoirement et avec un code un peu boosté, cette logique marche également pour un convoi trop long pour un canton et qui occupe donc simultanément trois cantons)

Maintenant la question.
Ce site m'a apporté et m'apporte beaucoup. Un apport absolument essentiel. J'ai lu, je lis beaucoup... mais je ne comprends pas tout !
Notamment sur cette question car elle est en rapport :
J'ai lu beaucoup de choses sur la rétrosignalisation. Je me demande... ces détecteurs 3216, ou d'autres car ils ne font en fait rien d'autre (mais avec quelques fameux avantages) que ce que font des barrières infra-rouge, n'est ce pas de la rétrosignalisation ? pour bien moins cher, bien moins compliqué que des détecteurs de consommation dont l'exploitation me semble finalement plus limitée ? C'est ça qui m'intrigue. Mais de que j'ai lu à propos des détecteurs de consommation, je m'en suis fait l'idée (éronnée ??) qu'ils étaient associés aux réseaux exploités en digital. Bien que je ne vois pas pourquoi. Il y a en tous cas une donnée qui m'échappe gravement et avant de me lancer dans un réseau digne de ce nom j'aimerais tirer ça au clair. Si quelqu'un peut m'y aider...

101
Composants / Re : Alimentation 12v
« le: juin 18, 2020, 04:17:04 pm »
Bonjour,

personnellement, après avoir fait le choix d'éliminer les alims à découpage pour la source principale (et donc d'accepter d'y mettre plus cher), j'ai choisi ceci (en N on peut faire beaucoup de choses avec 10A) :

https://www.manomano.fr/catalogue/p/alimentation-fixe-138-vcc-10-a-fps1310-1520229?product_id=2981296

mais derrière, ça découpe pour pas cher avec autant de modules que de tensions (12, 9, 5, 3.3) et que de besoins ; ceci par exemple
https://fr.aliexpress.com/item/32629860159.html?spm=a2g0w.search0303.3.86.6fe44396TFdF0z&ws_ab_test=searchweb0_0,searchweb201602_0,searchweb201603_0,ppcSwitch_0&algo_pvid=4c634779-dc39-491f-8adf-6858a806a52d&algo_expid=4c634779-dc39-491f-8adf-6858a806a52d-13

Pour ce qui est des masses, le problème survient précisément quand elles ne sont PAS interconnectées !
Ou alors du fait de fils en antenne, longs... vraiment longs.

102
Composants / Re : Un nouveau composant prometteur : le VL6180
« 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

103
Composants / Re : Un nouveau composant prometteur : le VL6180
« 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


104
Infos et bonnes affaires / Re : Capteur de proximité VL6180X
« le: mai 24, 2020, 10:57:34 pm »
Bonsoir Antoine,

Je suis ces essais avec beaucoup d'intérêt étant de mon côté en test sur un détecteur voisin (CJMCU3216) en remplacement de barrières IR. Tests très encourageants et dont les résultats rejoignent les vôtres.

Si j'interviens, c'est en fait pour savoir pourquoi ne pas avoir utilisé ce module :
https://learn.adafruit.com/adafruit-tca9548a-1-to-8-i2c-multiplexer-breakout
pour régler ce problème d'adresse unique des capteurs (pareil avec ceux que je teste). Un module = 8 sorties I2C, chaque module pouvant avoir 8 adresses, on peut donc avoir 64 capteurs, même ayant la même adresse. De quoi voir venir !
(et pas de pins "consommés" sur l'arduino).



105
Composants / Re : Un nouveau composant prometteur : le VL6180
« le: mai 15, 2020, 02:56:36 pm »
Bonjour,

suivant avec un intérêt particulier tout ce qui a trait à la détection, je me suis bien sûr arrêté sur ce fil.

Sans avoir été y regarder de plus près, notamment la datasheet, en quoi ce composant est-il différent du VL53L0X  qui y ressemble à s'y méprendre mais est donné pour une détection à plus d'un mètre (... de quoi réaliser des arrêts sur ralentis de rêve) ?


J'en attends un exemplaire (2euro50... ça ne peut dont pas être le même !), je pourrai peut-être bientôt rapporter mon expérience

Pages: 1 ... 5 6 [7] 8