Comment traiter données issues d'un capteur

[redscreen]

Merci beaucoup pour les précisions
J'ai donc mis un: if (UDPData.length === 29) avant chaque utilisation d'un UDPData
Tout fonctionne maintenant mon servo bouge en temps réel !

Si je prend ton explication (logique inverse, on ne fait pas si UDPData n'a pas été initialisé) (je l'utilise surement mal), mais le {return ;} empêche l'exécution de tout le reste du code


J'ai peaufiner le petit site web de conf que j'avais initialement créé pour apache php sql,
et j'ai un peu de mal pour adapter les méthodes que je connais en php vers js.

Ma page "conf.php" utilise un formulaire "post" avec un input type "range" qui lit et envoi la valeur en dbsql.
C'est certainement plus simple de la faire en js, d'autant plus que je ne passerai plus par la dbsql mais par une simple variable dans programme.js
Je cherche dans tes tutos, pour l'instant sans succès.
Je ne vois pas d'allusion au formulaire..

J'ai déjà compris qu'il fallait déclarer toutes les pages html dans programme.js,
car je n'avais déclaré que index.html et j'avais mis tous les chemins /templates/.. dans mes liens, mais ça ne récupèrait pas les paramètres <%=credit%>

[Bud Spencer]

Si je prend ton explication (logique inverse, on ne fait pas si UDPData n'a pas été initialisé) (je l'utilise surement mal), mais le {return ;} empêche l'exécution de tout le reste du code

Ouais, c'est ca. En fait c'est soit

if (data ok) {
...
...
}

ou

if (Data pas ok){ je sort }
...
...

Pour les requêtes post, c'est comme pour les requêtes get. le si le form de ton formulaire dans la page web est de type post tu leves un évènement dans un app.post dans ton code nodejs plutôt que dans un app.get. Pour récupérer les données post du formulaire il faut utiliser le npm bodyparser . Il y a un petit exemple ici ou une sonde dht connecté a un esp8266 envois des requête post au serveur nodejs : viewtopic.php?f=44&t=3033&start=110#p30136

Tu peux aussi te simplifier la vie en transférant tes données sur un socket.io, c'est beaucoup plus rapide et sans rechargement de la page coté client . Les première leçons du tuto font ca (le client envoi des donnes au serveur)

[redscreen]

Ok, ça fonctionne maintenant à merveille
J'ai même rajouté une lecture/écriture json pour un paramètre que je voulais persistant.
Je te remercie encore pour tous les conseils et explications que tu as pris le temps de me donner

[Bud Spencer]

Nikel

[redscreen]

Hello Mr Bud Spencer.
De retour 2 mois plus tard, après avoir enfin récupéré les 2 modules pour "driver" les 2 vérins :
2x BTS7960 : https://cdn.instructables.com/ORIG/FYD/ ... L8W2ZW.pdf

Je vais pouvoir mettre en pratique et apprendre la régulation PID...

Mais tout de suite une question me vient après avoir lu ce sujet :
https://electronics.stackexchange.com/q ... ithout-pwm

Puis je brancher ces 2 BTS7960 sur le rail 3.3V de la Rpi3B sans rien risquer pour celle-ci ? :
certain disent que le BTS7960 fonctionne uniquement en 5V (mais le PWM Rpi est en 3.3V), d'autre disent que c'est OK si tout est branché sur le 3.3V, mais à éviter sur Rpi car tirera trop de courant... ?

Bref j'ai déjà testé avec un seul BTS7960 :
VCC, L_EN, R_EN : sur le 3.3 V Rpi
GND : GND Rpi
L_PWM : GPIO 12 Rpi
R_PWM : GPIO 13 Rpi
et j'envoie du PWM soit sur GPIO 12, soit sur GPIO 13 :
ça fonctionne, mais pour l'instant aucune charge, et je vais devoir brancher 2 contrôleurs.

( au passage j'ai réglé la fréquence PWM sur 1.2kHz comme conseillé pour moins chauffer, mais ça siffle fort... un intérêt ? )

Je préfère te demander ce que tu en penses de peur de griller notre seule Rpi...
Merci d'avance!

[Bud Spencer]

Salut RedScrean.

Sur la carte que tu mets en liens, on peut voir qu’il y a un buffer (74hc244). Je n’ai pas le schéma mais si tu utilises juste les pins IN et INH, ce sont des sorties vues du coté du PI donc elles sont parfaitement compatibles avec la logique 5v en entré du buffer. Si tu veux cependant aussi utiliser les pins de contrôle de courant (SR et IS), là ce serait des entrées coté PI et la logique 5v n’est pas tolérée sur ses gpio. Dans ce cas il suffirait simplement de placer un diviseur de tension sur ces lignes pour abaisser la tension des signaux (*). Quoi qu’il en soit il est impératif d’alimenter cette carte en 5v et non pas en 3.3 puisque d’une part, c’est très certainement cette tension qui est utilisée comme tension de grille et d’autre part, parce qu’il faut exclure tout usage du 3.3v (tension et sorties de gpio) du PI vers l’extérieur à l’exception d’ échanges de signaux logique

Pour la fréquence des pwm, cela dépend aussi beaucoup de la puissance consommée par tes moteurs. Le plus simple est de commencer à 1.2khz comme préconisé et voir à l’usage en faisant des essais a des fréquences plus base.

(*) regarde sur le tuto NodeJs (en haut de la page 8 sur le projet du datalogger) ou j’utilise un composant SPI connecté directement au PI alors qu’il est alimentés en 5v. Seul la ligne MISO (Maser Input Slave Output, donc en entrée sur le PI) est ramenée à 3.3v par une paire de résistance montée en diviseur.

[redscreen]

il faut exclure tout usage du 3.3v (tension et sorties de gpio) du PI vers l’extérieur

c'est bien ce dont j'avais peur...

L_IS et R_IS je ne les branche pas (ce sont des sorties d'alarme de courant d'après : https://www.amazon.fr/moonWANG-BTS7960- ... B07WFP9VLY)

Il me faut brancher (et pour l'instant j'ai fait comme ça):
VCC -> 3.3V
GND -> GND
L_EN -> 3.3V
R_EN -> 3.3V
L_PWM -> GPIO 12
R_PWM -> GPIO 13

J'ai pensé à utiliser une alim extérieure 5V (comme j'avais fais lors de mes test avec un servo de modélisme Futuba S3003),
mais les sortie PWM du Pi sont en 3.3V, mais dans ce cas il faudrait qu'ils soient aussi en 5V...

Tout est "en sortie" vu du Pi

En tout cas je vais regarder ta page 8, voir si je peux trouver des infos, merci.

[Bud Spencer]

Il me faut brancher (et pour l'instant j'ai fait comme ça):
VCC -> 3.3V -> 5v
GND -> GND OK
L_EN -> 3.3V -> 5v
R_EN -> 3.3V -> 5v
L_PWM -> GPIO 12 OK
R_PWM -> GPIO 13 OK

Quoi que tu fasses avec le PI, proscris tout usage du 3.3v en sa provenance à l'exception d'états logiques haut en sortie vers d'autres composants en entré (ttl 3.3 ou 5v ou en commande de base ou de gate (spécifiquement compatible 3.3v) de transistor) et ca, quoi que tu lises sur ce forum ou ailleurs. Pour tes signaux pwm, ils seront bien évidement en 3.3v vers une logique 5v, mais cala ne te posera aucun problème et cela ne servirait a rien de vouloir les convertir avec je ne sais quel adapteur de je ne sais quoi.

J'ajoute à ca que vue que tu parles d'alimentation extérieure, elle est impérative, mais uniquement pour l'alimentation des moteurs, qui eux ne doivent absolument pas etre alimenté par le PI

[redscreen]

merci pour les précisions!
j'ai du trop lire de contradictions sur ce forum anglais en recherchant les branchements corrects... ça m'a persuadé que brancher "L_EN et R_EN" en 5V m'obligerait à utiliser des PWM 5V...
comme tu as corrigé c'est OK ! , et au moins la Pi ne risque rien ( bien souligné en rouge, au moins ça pourra servir à quiconque lira ce forum )

quand je parle d'alim extérieure, ce serait d'une 5V uniquement pour les 2 BTS7960, afin de ne pas trop "tirer" sur celle du Pi (pas forcement nécessaire du coup ?..., au moins de câbles au mieux...)
bien-sur, pour les moteurs, j'utilise une alim 24V.

hier j'avais des problèmes avec les 2 BTS7960 en simultané, (le 1er ne fonctionnant plus correctement, mais 1 seul à la fois était OK):

Code : Tout sélectionner

rpio.open(12, rpio.PWM); // GPIO 12 sur pin 32 // 1er module BTS7960
rpio.open(13, rpio.PWM); // GPIO 13 sur pin 33 // 1er module BTS7960
rpio.open(18, rpio.PWM); // GPIO 18 sur pin 12 // 2ème module BTS7960
rpio.open(19, rpio.PWM); // GPIO 19 sur pin 35 // 2ème module BTS7960

rpio.pwmSetData(12, x);
rpio.pwmSetData(13, 0);
rpio.pwmSetData(18, y);
rpio.pwmSetData(19, 0);

j'ai pensé à un problème sur les "channels PWM" (trop tard, je ne peux tester que 2 jours / semaine) et j'essaierai d'inverser (GPIO 12 avec 18) et (13 avec 19)

[Bud Spencer]

quand je parle d'alim extérieure, ce serait d'une 5V uniquement pour les 2 BTS7960, afin de ne pas trop "tirer" sur celle du Pi (pas forcement nécessaire du coup ?..., au moins de câbles au mieux...)

Franchement c'est techniquement totalement inutile. La conso sur le 5v va etre dérisoire. Le buffer ne va quasi rien consommer grâce au mosfets qui sont derrière. En plus ce buffer (74244) joue un double rôle puisqu'il va servir d'une part de convertisseur de tension (pwm 3.3v vers tension de porte 5v des mosfets BTS7960) et en plus il permet d'isoler la commande des BTS7960 des GPIO du PI.

bien-sur, pour les moteurs, j'utilise une alim 24V.

La dessus on est d'accord. L'alimentation des moteurs, c'est la partie 'puissance' donc elle ne doit en aucun cas (court circuit, moteur qui force ect ...) avoir de l'incidence sur l'alimentation du PI.

hier j'avais des problèmes avec les 2 BTS7960 en simultané, (le 1er ne fonctionnant plus correctement, mais 1 seul à la fois était OK):

ATTENTION ! il y a bien 4 pins GPIO sur le PI qui peuvent servir en PWM mais seulement 2 canaux.
Les pins 12 et 32 pour le canal 0 et 33,35 pour le canal 1 (voir ce que j'ai écris page précédente). Ce qui veut dire que si tu passes par exemple les pins 33 et 35 (canal 1) en PWM, tu auras le meme signal pwm sur les 2 pins. Si tu as besoin de 2 moteurs avec des vitesses différentes, ca le fait, mais au delà, il faut passer par un contrôleur PWW (en I2C (ex: PCA9685) ou mieu préférence en SPI (ex: TLC5947)). Il y a aussi la possibilité de passer par du PWM Soft, mais pour des moteurs ou la vitesse doit etre plutôt bien contrôlée ce n'est pas carrément pas une bonne idée.