Bonjour à tous, Je pense que ma question pourrait rentrer dans plusieurs catégories de ce Forum mais je vais commencer par ici car je pense que la plus grosse partie de mon projet se base sur des compétence électronique, domaine dans lequel je n'ai pas de connaissance. J'entame cette discussion dans le but de trouver les meilleurs composant et technologie à utiliser. Je mettrais en place un sujet de recrutement par la suite. Bref passons à la partie intéressante :
Quel est mon projet ?
Alors c'est un projet libre qui à pour but de rendre la télémétrie embarqué abordable à tous et ce à "moindre coup". Quand je parle de télémétrie je parle de la transmission de donnée d'un objet en mouvement vers une zone de traitement de ces données. C'est à dire qu'un ensemble de capteurs de mesure (température, vitesse, régime moteur, force gravitationnel, position gps) seront placés sur un véhicule (une moto par exemple), un émetteur transmettra les données "en temps réel" vers un récepteur qui les transmettra à son tour vers un programme de traitement qui les affichera.
Problème de conception :
Pour ma part je fais des études d'informatique donc pas de soucis pour la partie "front face" c'est à dire traitement et affichage des données, en revanche pour toute la partie envoie et réception des données je n'y connais rien, je me suis quand même renseigné et je suis tombé sur système créer par des étudiants d'Orléans très intéressant.
Partons sur deux données simples : - La vitesse (Utilisation d'un compte tour ?). - La Température moteur (sonde de température).
Question :
Quel son les composant à utiliser pour émettre et recevoir les données récupérer par les différents capteur ? Si vous avez n'importe quel ressource ou documentation qui vous parait intéressante pour mon projet je suis preneur ! Si mon projet vous intéresse n'hésitez pas à me le faire savoir !
d'abord, chose à se demander à chaque fois qu'on parle d'une transmission de données, quelle distance? ensuite, dans ton cas, est-ce que ça a VRAIMENT un intérêt d'avoir l'affichage en temps réel? (parce que sinon, tes données tu les enregistre avec un horodatage dans un .CSV et tu le passe à ton programme sur PC en rentrant). ensuite, tu parles d'une liaison de données "temps réel", ce qui implique un débit d'infos. si 1/4 d'h suffit, ou s'il te faut plusieurs échantillons par seconde.
en bref, quel est le cadre réel d'utilisation de ton montage?
Je pense que tu pourrais regarder du côté de l'arduino avec un shield WiFi qui enverrai les donnés sur un mini serveur web qui serai installé sur un Pc portable par exemple
A partir de là il est très facile de récupérer les données
Fixe : Intel Pentium G3258@4.0GHz, Asrock B85M Pro3, G.Skill NS Series 8 Go (2 x 4 Go) DDR3 1333 MHz CL9, ASUS GTX560Ti 1Go, Alim FSP 700W, Boitier Zalman Z3 PlusPortable : MSI GE72 6QD Apache Pro - Intel Core i7 6700HQ Skylate, 8Go DDR4, NVidia GTX 960M, SSD Crucial M.2 SATA 275Go, HDD 1To
d'abord, chose à se demander à chaque fois qu'on parle d'une transmission de données, quelle distance? ensuite, dans ton cas, est-ce que ça a VRAIMENT un intérêt d'avoir l'affichage en temps réel? (parce que sinon, tes données tu les enregistre avec un horodatage dans un .CSV et tu le passe à ton programme sur PC en rentrant). ensuite, tu parles d'une liaison de données "temps réel", ce qui implique un débit d'infos. si 1/4 d'h suffit, ou s'il te faut plusieurs échantillons par seconde.
en bref, quel est le cadre réel d'utilisation de ton montage?
Alors je vais mettre mon projet dans un cadre réel que je connais. Disons une course de motocross, ce qui m'intéresse c'est que mon mécanicien est les informations pendant que je roule pour préparer les réglages avant que je rentre au stand (pas perdre le temps à retraiter toutes les données), donc le temps réel est très important, je dirait comme ça allé peut être un envoie des infos 10 fois par seconde. Donc cet aspect de temps réel est vraiment essentiel. Après en effet la distance on va dire entre 2 et 3 km, c'est peu être énorme non ? mais pour les phases de test je verrais ça à beaucoup plus petite échelle.
electronic100 a écrit:
Salut,
Je pense que tu pourrais regarder du côté de l'arduino avec un shield WiFi qui enverrai les donnés sur un mini serveur web qui serai installé sur un Pc portable par exemple
A partir de là il est très facile de récupérer les données
Je ne pense pas pouvoir disposer d'un réseau WIFI dans tous les situation d'utilisation de mon montage.
Merci pour l'intérêt porté à ma question, cordialement.
Pour mesurer la vitesse, je pense que la solution la meilleure serait d'utiliser soit un accéléromètre, soit un GPS et de la calculer grâce à leurs données. Pour la force gravitationnelle, tu pourras utiliser l'accéléromètre aussi!
Pour la collecte de différentes données, je te conseillerais de te baser sur une carte faite maison avec un microcontrôleur, ou alors si tu as vraiment besoin de beaucoup de puissance de calcul une du type Raspberry Pi. Tu crées un petit boîtier solide, ce sera protégé des différents chocs, de la boue, etc...
Quant à l'envoi des donnés, une solution (pas la meilleure, pas la moins chère sûrement, mais ça marche) serait d'utiliser des module XBee, de mémoire il y en a (des versions PRO?) qui peuvent envoyer des données à plus de 5km. Côté mécanicien, il existe des adaptateurs pour brancher le module Xbee sur un ordinateur par USB: après, ce n'est qu'une simple liaison série. Sur l'ordinateur du stand, tu crées un logiciel client qui récupère les données du port série, et les affiches pour que ton mécano puisse les comprendre. Si tu fais du c++, la bibliothèque Qt et très pratique avec sa classe QSerialPort, par contre si c'est du java je te déconseille, c'est une vraie galère l'accès aux ports séries avec...
tout d'abord, est-ce que les capteurs ont déjà été choisis (l'accélérometre, comme le GPS sont des mauvaises idées, pour des raisons sensiblement identiques: l'accélérometre dira n'importe quoi, étant donné que pas mal de temps, la moto est ni en ligne droite, ni à terre. donc ça donnera jamais la vitesse de la roue. et pour le GPS, bah c'est une intégration de données peu précises. du coup, j'ai du mal à croire qu'un gps fasse de bonnes estimations dans le cadre d'une course de motocross, ou la moto est jamais à terre, et fait des courbes paraboliques en permanence, des courbes que le gps aurait du mal à interpréter, je pense.
donc le seul type de capteurs auxquels il peut faire confiance, c'est ceux qui mesurent les choses sur la moto. en n'ayant pas de référence ailleurs (donc exit GPS, accélérometre, etc...). maintenant, je pose la question qui fâche, quels capteurs va-tu utiliser pour récupérer les données?
parce que rien que là, le capteur de température moteur, bah pour en rajouter un autre, bonjour. et pour lire la communication entre celui-ci et le tableau de bord, bonjour aussi. ou alors sur ta moto y'a une prise pour communiquer avec l'ordinateur de bord, et collecter des infos, et par bonheur elle est bien documentée. mais j'y crois pas trop.
à la limite, le media de communication c'est pas le plus dur à trouver des compromis, ou à trouver un bon gros systeme qu marche bien. c'est surtout toute l'instrumentation qui est difficile dans ce projet.
mais si tu tiens à parler de portée et de média de communication, est-ce que tu peux envisager si, mettons que la course dure 50 tours (j'en sais rien, j'ai jamais fait de motocross sur circuit de ma vie). et que tu t'arrête au 20e tour, est-ce que c'est possible d'envoyer les données de tout le tour dès que tu passe devant les stands: ton mécanicien sait que tu t'arrête vers le 20e tour, il peut figer le graphique des 15 premiers tour et commencer les calculs pour vérifier que la moto est bien réglée? en tout cas ça parait un bon compromis entre distance et réactivité, vu qu'un tour de circuit doit pas dépasser 2-3 min, etc...
surtout que je sais pas trop ce qui est regardé, mais disons que faire des zones rouges sur le graphique, ça se fait facilement dans le code de la face avant, donc pour la vitesse et le compte tour ça se fait facilement, et vérifier la présence d'une valeur dans un intervalle autour d'une moyenne ça se fait bien aussi, donc pour la température, c'est bon. il faut savoir que ce que tu fais sur le circuit ne variera pas beaucoup d'un tour à l'autre. donc si quelque chose d'inhabituel est détecté, déjà tu peux y ajouter des marqueurs visuels, avec la possibilité de mettre un système de commentaires pour le mécanicien qui note des trucs à chaque tour, et qui en tient compte au moment de revoir la moto...
Alors pour le calcul de vitesse je dois me baser sur le régime moteur (le nombre de tour par minute du moteur ) pour le moment je n'en sait pas plus sur comment faire pour calculer le régime moteur. ensuite pour la température une simple sonde pt100 fait l'affaire je pense (dite moi si je me trompe). On va commencer par là, on va laisser de côté les autres instruments pour le moment .
Je ne veux pas brancher mon système sur la moto (de toute manière il n'y à pas d'électronique dans une motocross), juste récupérer des mesures.
Afin d'être plus illustrer prenons un exemple, comment faite vous pour récupérer la température d'une sonde pt100 et l'envoyer de manière "sans fils" vers un ordinateur.
Je n'avais pas vue l'édition de ton message au moment de poster le mien, j'édite donc le mien à mon tour.
L'aspect temps réel est vraiment essentiel dans ce projet, un petit un exemple : Admettons que nous pouvons contrôler la pression des pneus. Le pilote subit une crevaison lente, le pneu se dégonfle peu à peu, il ne faut pas que le pilote sans rende compte quand son pneu à plat, car si il est ai en début de tour il va perdre beaucoup de temps avant de revenir au stand. Le but serait que le contrôleur remarque une baisse de la pression des pneus et demande au pilote de s'arrêter, comme sans aucun tour à plat.
On ma orienté vers le protocole GPRS, qu'en pensez vous ?
pneu crevé ou pas, il faut de toute façon faire un tour non? y'a pas le droit de rouler en sens inverse, si je me trompe pas. pis suivant le module de communication, y'a moyen de faire quand mêem 100m de portée, du coup, tu as les infos avant de resrer dans les stands.
mais je tiens quand même à attirer ton attention sur quelque chose. avant de vouloir envoyer des données, il faut les capter. par exemple, l'éventuelle PT100, je vois pas bien ou tu veux la mettre... faire un trou dans la culasse?(question rhétorique évidemment, on fait jamais un trou dans une culasse...)
lilrom13 a écrit:
On ma orienté vers le protocole GPRS, qu'en passez vous ?
- Edité par lilrom13 il y a 17 minutes
GPRS c'est ce qu'il y avait dans les téléphones portables avant edge et la 3G. je sais pas comment ça marche et si y'a pas besoin d'une carte sim pour le faire marcher. sinon, ça parait pas mal, mais je sais pas si toutes les zones rurales (là ou y'a des terrains de motocross) sont couvertes... ceci dit, Spirine t'a parlé de XBee, c'est une bonne idée, et c'est surement plus pratique que GPRS.
sinon, pour le compte-tours, y'a des chances que tu aie de quoi installer un capteur à effet hall vers le vilebrequin, ou vers l'arbre de sortie de boite, en y mettant un capteur à effet hall, tu aurais de quoi remonter respectivement à ta vitesse de roue ou à ta vitesse moteur. après ça, 'suffit de compter, et appliquer le rapport de réduction.
pour les roues, une crevaison lente ça se rebouche en course: il y a maintenant des produits qui se mettent dans le pneu, au gonflage, qui rebouchent les trous de l'intérieur quand ils arrivent. et apparemment ça coute pas très cher. j'avais vu ça dans High-side, le numéro de septembre à la fin je crois.
à tout hasard, c'est quoi comme moto que t'as? histoire de vérifier qu'il y a pas 2-3 personnes qui aient bricolé des instruments de bord, et qui auraient su dire comment sur internet.
Pour le moment récupérer des valeurs "précise" n'est pas mon but, pour le moment je suis à la recherche de la meilleur méthode pour envoyer des données de manière "sans fil" de la moto au point de contrôle. Donc que la sonde soit placé à la sortie de l'échappement ou ailleurs n'a pas trop d'importance.
Je dois adapter la technologie aux besoins et non l'inverse, le temps réel est l'aspect principal de ce projet je ne peu donc pas le laisser tomber en dépit de la distance. Si le meilleur moyen de couvrir une distance de 2 à 3km est le GPRS alors je vais devoir creusé de ce côté (et dieu sait que j'aime pas jardiner).
Je me suis un peu renseigné sur ce protocole et apparemment oui ça fonctionne avec un carte SIM (implique une carte prépayée ect ) donc déjà ça fait un mauvais point.
Je vais traité du côté XBee alors.
Merci encore pour vos réponses je me sens déjà moins bête qu'au moment du post de ce sujet . Cordialement.
GPRS ??? C'est un protocole pour téléphone portable, je ne vois pas l'intérêt d'utiliser un système où l'antenne peut se trouver à plusieurs kilomètres, qu'ensuite les données passent par le réseau d'un opérateur avant d'être retransmises à l'ordinateur qui se trouve à 500 m à tout casser de l'engin.
Comme il a été évoqué, le protocole Zigbee (les cartes Xbee sont chères mais il y en a qui débutent à 15-20€) me semble adapté : portée potentiellement importante, débit pas forcément très élevé mais suffisant pour des données de télémétrie.
Il y a aussi le 6LoWPAN comme "concurrent".
Pour calculer la vitesse tu peux faire comme les capteurs utilisés en vélo : un petit aimant permet de compter les tours de roue, il faut ensuite indiquer le périmètre de la roue, tu as donc une distance et tu calcule la vitesse grâce à un delta de temps.
GPRS ??? C'est un protocole pour téléphone portable, je ne vois pas l'intérêt d'utiliser un système où l'antenne peut se trouver à plusieurs kilomètres, qu'ensuite les données passent par le réseau d'un opérateur avant d'être retransmises à l'ordinateur qui se trouve à 500 m à tout casser de l'engin.
bah lis toi-même ce qu'il demande, il veut 3km de portée...
XBee tu as une portée jusqu'à 1km si je me rappelle bien avec des modules semi-pro, et encore un peu mieux avec des modules pro (qui coûtent un bras par contre). je te laisse chercher. 3km t'es déjà dans un cas plus que limite, même en terrain ouvert. ou alors tu te fais des bornes xbee tout le long du parcours, tous les 100m.
sinon, autre point faible du GPRS (GSM a les mêmes) pusiqu'il fait pas trop peur, y'a un délai de quelques secondes entre l'envoi depuis la moto et la réception sur l'ordi (ça passe par tout plein d'intermédiaires lointain, comme une demi-douzaine de satellites, les serveurs de ton fournisseur d'accès,etc...).
je te parle pas d'adapter le besoin à la technologie (quoique...) je et parle de penser à une application que la technologie "grand public" est capable de traiter. et je parle pas de la technologie que tu trouve chez ferrari en F1, parce que c'est peut-être 100 ingénieurs qui bossent sur la télémétrie pendant un an avant que ça sorte.
Pour ce qui est de la partie "centralisation des données" sur la moto, je pense qu'un arduino peut suffire et après il restera la communication sans fil à régler
Je suis en train de regarder ce que je pourrai te proposer
- Edité par electronic100 30 octobre 2014 à 18:05:14
Fixe : Intel Pentium G3258@4.0GHz, Asrock B85M Pro3, G.Skill NS Series 8 Go (2 x 4 Go) DDR3 1333 MHz CL9, ASUS GTX560Ti 1Go, Alim FSP 700W, Boitier Zalman Z3 PlusPortable : MSI GE72 6QD Apache Pro - Intel Core i7 6700HQ Skylate, 8Go DDR4, NVidia GTX 960M, SSD Crucial M.2 SATA 275Go, HDD 1To
En effet Xbee est trop limité niveau portée, sur certain terrain le point le plus éloigné peut se trouver à 1 km quand sur d'autre terrain ce sera 2 ou 3km donc la le facteur distance est trop variant, de plus je parle de motocross dans mon cas donc des terrains avec des montés des descentes donc pas mal d'obstacle potentiel.
Pour ce qui est du compte tour de roue, j'y avait pensé mais la encore trop de contrainte, la boue pour commencé, à cet endroit là elle peut vite obstruer et endommager l'appareille.
Pour ce qui est du délai du GPRS je l'ai pris en compte, mais c'est le seule protocole pour mon projet pour le moment. Et si j'avais le budget de ferrarri pour mon projet ça serait bien trop facile .
Je vais commencé à bidouller des cartes arduino pour essayer d'en tirer quelque valeur dans ce cas
En effet Xbee est trop limité niveau portée, sur certain terrain le point le plus éloigné peut se trouver à 1 km quand sur d'autre terrain ce sera 2 ou 3km donc la le facteur distance est trop variant, de plus je parle de motocross dans mon cas donc des terrains avec des montés des descentes donc pas mal d'obstacle potentiel.
Pour ce qui est du compte tour de roue, j'y avait pensé mais la encore trop de contrainte, la boue pour commencé, à cet endroit là elle peut vite obstruer et endommager l'appareille.
Pour ce qui est du délai du GPRS je l'ai pris en compte, mais c'est le seule protocole pour mon projet pour le moment. Et si j'avais le budget de ferrarri pour mon projet ça serait bien trop facile .
Je vais commencé à bidouller des cartes arduino pour essayer d'en tirer quelque valeur dans ce cas
Bah 3km de portée, tu veux te trimbaler avec un émetteur de 10kg sur la moto ? (Pour du 2.4GHz)
Il faut savoir faire des concessiosn, car je parie que tu voudrais que ca coûte pas cher, non ? Et aussi que ca soit simple à mettre en oeuvre ?
Bref les Xbee ont deux modes de fonctionnement : "Wireless serial" ou "Zigbee" (qui est un protocole).
Or le protocole Zigbee permet d'avoir un fonctionnement décentralisé : un réseau mesh.
Donc pour contrer ton problème de portée, tu fabrique une petite balise à base d'une carte gérant le protocole Zigbee qui servirait de relais et tu l'installe à mi-chemin de ta portée maximale ou alors tu peux même mettre plusieurs balises.
Quand ta moto serait hors de portée du récepteur qui se trouve dans les stands, la communication pourra toujours s'établir grâce aux balises relais.
La mise en oeuvre est un peu plus compliquée mais faire une petite balise pour un week-end de course, je pense qu'il suffit d'une carte Zigbee avec une petite batterie vu que c'est pensé pour une faible consommation.
Concernant la portée, comme je l'ai expliqué dans un autre poste, cela dépend de beaucoup de paramètres et notamment de la puissance de l'émetteur ainsi que la sensibilité du récepteur.
D'autre part, plus on descend en fréquence et moins l'atténuation du signal sur la distance sera importante. Un signal de 1 kHz portera donc plus loin qu'un signal à 2.4GHz.
Le protocole Zigbee est défini sur le 2.4GHz mais aussi autour de 900MHz (868 MHz en Europe) or avec cette seconde fréquence, 3 km de portée est largement atteignable surtout en extérieur.
Si tu as des terrains vallonné et donc tu es susceptible d'être "caché", bah il faut avoir une balise qui se trouve en hauteur, et potentiellement les antennes de téléphone et le satellite répondent à ce critère.
L'autre solution c'est d'arrêter de vouloir absolument du "temps réel" et d'avoir un petit buffer de données et quand tu as une connexion établie tu transmets les données sinon tu les met en buffer.
Est-ce que 10 à 30 secondes sans données c'est grave ? Ton mécano ne se prépare pas 30 secondes à l'avance.
Je tiens à préciser une chose, ce projet n'est pas quelque chose de personnel dans le sens ou, je le fais exclusivement pour moi, j'ai réellement envie de mettre en place un projet open source afin qu'une personne lambda puisse se document et utiliser la télémétrie embarquée car je n'ai pas vue cette technologie être utilisé en dehors des paddoks de formule 1, j'aimerai la rendre un peu "grand public" sans aucune prétention.
Après oui j'ai vraiment avis que le gros point fort de ce projet soit le temps réel, après au niveau du coup je sais que c'est difficile de racheter Las Vegas avec un smic, donc il faudra faire des concessions la dessus, mais je préfère mettre un peu d'argent dans mon projet et répondre à mes attentes que de faire un trop abordable et donc limité.
Ensuite un point sur lequel je veux encore insister c'est le public que va toucher ce projet, je ne vais pas chercher à faire quelque chose qui gère le cour et moyenne porté, car dans le domaines des système pour modélisme existe déjà, je veux faire ça à long et très long portée.
Ton idée des bordes relais me plais c'est vrai que trois ou quatre balise pourrait faire l'affaire pour couvrir l'ensemble de la distance d'un terrain de motocross par exemple. En revanche prenons une autre discipline qui est l'enduro la par contre les course relis un point A à un point B espacé de 15 à 20 km, dans ce cas je devrait sans doute me tourner vers la technologie gprs.
post initial(que je voulais poster... "il y a environ 4h, ce qui donne 18h)je pense que tu vas un peu vite en besogne. une moto c'est un des pires nids à parasites possible et imaginable pour une application sans fil. je sais de quoi je parle, mon pere avait refait tous ses allumages de moto (les mécaniques commencaient à fatiguer, du coup il a bricolé des allumages électroniques), et les boitiers d'allumages marchaient très bien sur le banc de tests, et une fois sur la moto, plus moyen de faire marcher quoi que ce soit (il a même cramé plusieurs microcontroleurs et transistors avant de construire un autre banc de test sur lequel il a installé une centrale d'allumage comme il y a sur la moto, et fini par trouver la source de parasites)
EDIT (il est 22h45 maintenant):
en enduro, t'arrive à faire plusieurs fois le "circuit"? 20 bornes à 50 à l'heure dans la boue, y'a vraiment plusieurs manches d'affilée à moins d'1h de pause? le mécano a vraiment le besoin de te suivre à la seconde sur une course ou de toute façon il ne peut rien pendant les manches, à part venir chercher la moto qui est en panne critique après ton abandon? la prochaine étape, c'est quoi? le paris-dakar, supervisé depuis Paris?
je veux pas avoir l'air agressif, ou moqueur, ou n'importe quoi que tu puisse penser en lisant ça, (en clair, le prends pas mal) mais ton projet est pas assez fixé, y'a pas de cadre, pas d'utilité démontrée proprement, rien. si ton projet c'est d'envoyer des données random depuis une moto random vers un mécano (random) à une distance random, bah le mieux c'est encore une oreillette bluetooth branchée à ton téléphone et tu parle direct au mecano, la technologie actuelle peut pas beaucoup mieux pour toi (vraiment).
l'avantage que ferrari a sur toi, c'est que le circuit est borné et qu'il y a des relais d'antennes partout. je sais même pas si c'est pas mutualisé pour toutes les écuries, vu que les communications sont chiffrées
Je tiens à préciser une chose, ce projet n'est pas quelque chose de personnel dans le sens ou, je le fais exclusivement pour moi, j'ai réellement envie de mettre en place un projet open source afin qu'une personne lambda puisse se document et utiliser la télémétrie embarquée car je n'ai pas vue cette technologie être utilisé en dehors des paddoks de formule 1, j'aimerai la rendre un peu "grand public" sans aucune prétention.
Après oui j'ai vraiment avis que le gros point fort de ce projet soit le temps réel, après au niveau du coup je sais que c'est difficile de racheter Las Vegas avec un smic, donc il faudra faire des concessions la dessus, mais je préfère mettre un peu d'argent dans mon projet et répondre à mes attentes que de faire un trop abordable et donc limité.
Ensuite un point sur lequel je veux encore insister c'est le public que va toucher ce projet, je ne vais pas chercher à faire quelque chose qui gère le cour et moyenne porté, car dans le domaines des système pour modélisme existe déjà, je veux faire ça à long et très long portée.
Ton idée des bordes relais me plais c'est vrai que trois ou quatre balise pourrait faire l'affaire pour couvrir l'ensemble de la distance d'un terrain de motocross par exemple. En revanche prenons une autre discipline qui est l'enduro la par contre les course relis un point A à un point B espacé de 15 à 20 km, dans ce cas je devrait sans doute me tourner vers la technologie gprs.
Le problème c'est que tu veux un truc universel qui répond à tous les cas. Ce n'est pas possible ou alors ca devient une usine à gaz.
Que ce soit en soft ou en hard on spécifie un besoin et on répond par une solution adaptée à ce besoin/spécifications.
Se dire "je vais faire un truc qui couvre des distances de moins de 2 km mais aussi jusqu'à 20 km" au niveau technique la solution n'est pas la même surtout si tu pense utilisé du GSM/GPRS qui nécessitera l'utilisation d'une carte SIM (donc un certain coût fixe supplémentaire pour un utilisateur).
Il faut aussi se rendre compte que la technologie a ses limites.
Faire de la communication radio dans un environnement boisé et vallonné comme en enduro ce n'est pas forcément très facile car tu reste dépendant de la physique.
Alors tu peux me dire que les radios pour communiquer peuvent avoir de grandes portées, oui c'est vrai, mais tu as vu la taille de l'objet ? Déjà l'antenne est d'une taille importante (même si ca tend à diminuer) et surtout c'est principalement la batterie qui occupe la place car émettre loin nécessite d'émettre de manière puissante pour contrer l'atténuation des ondes. (et il y a aussi l'autonomie)
Les réseaux mesh permettent de contrer ce problème de puissance : plutôt que de reposer sur un système centralisé autour d'une antenne, chaque élément du réseau peut communiquer avec un autre et il n'y a pas besoin d'être à distance d'un noeud pour communiquer avec lui, les noeuds du réseau peuvent transmettre le message jusqu'au bon noeud.
Ensuite vouloir absolument que les données soient transmises en temps réel est aussi une aberration. Si tu fais de l'enduro sur 15 à 20 km, ne pas avoir de données pendant 1 min je doute que ce soit très pénalisant (sachant que si tu bufferise, tu peux avoir les données "anciennes" c'est juste qu'elle arriveront avec du retard). Et pour le coup ça permet de palier des problèmes de transmission.
Mes exemples ne sont peu être pas les meilleur c'est vrai, mais je le rappelle une dernière fois, ce n'est pas pour moi. Je veux un projet qui marche dans différente situations. Même si il faut proposer deux systèmes avec des portées différentes.
Je sais que l'électronique sur les moto son pas toujours des plus simple et très documenté, c'est pourquoi mon système ne relèvera pas (pour le moment) de données extraite des tensions de la moto.
Après d'accord bufferiser des donnée sur une ou deux minutes c'est pas la mort mais je préférerai que ça arrive que dans des situations particulière, perte du signal.
Bon on va prendre un cadre simple et basique pour le moment :
________________________________
Expression du besoin :
Afin de mieux analyser les performances durant les entrainements et la compétition, un système télémétrique placé sur la moto serait un gain de productivité. Il permettrait aux mécaniciens de contrôler les performances de la moto, et au pilote de comparer ses temps au tour. Dans un premier temps, il s'agit de valider une technologie permettant de récupérer sur un PC, à travers une liaison sans fil, les valeur instantanés de la vitesse, le régime moteur, la température de la moto ainsi que le temps pour faire un tour de piste. Une fois ces données récupérées elles seront traitées dans toute leur forme possible (moyenne, meilleur temps .. )
Spécification technique :
Évaluation de la distance
Sur ce circuit la distance la plus proche est de quelques mètres à environs 650 mètres pour la plus eloigné, Notre système doit donc fonctionner dans une fourchette de 1 à 1000 mètres en terrain plus ou moins dégagée.
L'émetteur doit fonctionner sur batterie et posséder une autonomie de 40 minutes minimum. L'alimentation du récepteur se fera via USB.
________________________________
Voilà je pense que ça fait un bon point départ, maintenant réfléchissions de manière efficace :
Étape 1 : récupération des valeurs.
Sincèrement je ne sais pas encore comment faire mais je vais chez un mécano pour en parler et voire si je peux trouver une solution. Pour ce qui est du chronométrage pense que ce doit être possible d'activer un timer au premier passage de la moto et enregistrer la temps quand la moto repasse, l'infra rouge est mon amis ?
Après vraiment le top du top serait un GPS qui récupérer des position puis faire un traitement avec google map pour afficher les tours avec des codes couleurs en fonction de la vitesse de la moto à ce moment la (je rêve ? ).
Étape 2 : traitement des valeurs.
Pour cette étape je me tourne vers vous mes amis . Pour le moment de ce que j'ai compris : il me faut un circuit avec un microcontrôleur afin de transformer mes valeurs analogiques en valeurs numériques. Ou alors l'utilisation d'un arduino ?
Étape 3 : envoie des données.
Ahah on y arrive. Pour le moment l'orientation va dans le sens, Deux émetteur xBee (un sur la moto, un au stand) + deux ou trois autres qui servirons de relais si la l'émetteur moto sort du champs de l'émetteur paddock. J'ai vue que xBee était vraiment bien documenté, il y a beaucoup de tutos et de vidéos sur le sujet.
Étape 3 : réception des données.
L'émetteur paddock aura donc comme mission de récupérer les données, après la c'est un peu sombre sur le moment auquel je dois traité mes données, avant ou après le transfert des données part le port série (Rs232 je pense) vers l'ordinateur ?
Étape 4 : Affichage des données.
La c'est mon domaine, je vais voir au niveau du langage si je pars sur du C++ ou du java, mais cette partie ne devrait pas être la plus difficile.
Voila c'est tout ce que j'ai appris de notre discussion. Maintenant que le cadre est fixé, la technologie xBee vous semble tel adaptée par rapport à la description que je vous est faites ?
Pour cette étape je me tourne vers vous mes amis . Pour le moment de ce que j'ai compris : il me faut un circuit avec un microcontrôleur afin de transformer mes valeurs analogiques en valeurs numériques. Ou alors l'utilisation d'un arduino ?
Un arduino est une carte microcontrôleur donc la programmation est "facilité". C'est donc une bonne solution pour commencer ton projet sans trop devoir investir sur ce point et avec une certaine facilité de développement :).
Étape 3 : envoie des données.
Ahah on y arrive. Pour le moment l'orientation va dans le sens, Deux émetteur xBee (un sur la moto, un au stand) + deux ou trois autres qui servirons de relais si la l'émetteur moto sort du champs de l'émetteur paddock. J'ai vue que xBee était vraiment bien documenté, il y a beaucoup de tutos et de vidéos sur le sujet.
Pour ce qui est de l'envoi des données, le plus compliqué est évidemment la question du "temps réel".
Si on pouvais bufferiser le temps du tour ce serait trop simple, dans ce cas on pourrait éventuellement ( si ce que je pense est possible, mais je détaillerai plus tard ) transmettre en 433 ou 868 Mhz directement sur le récepteur dupaddock lors du passage de la moto avec un second arduino et un module de réception 433 ou 868 Mhz (voir la dernière partie de mon message).
Je me demande même si avec un ampli en réception, on pourrait peut-être l'utiliser en temps réel, je parle d'un ampli en réception car les puissance sont limités en émission et il faudrait une licence pour monter plus haut, par contre, ayant toujours des doutes, est-ce que quelqu'un connaissant mieux ce système pourrait apporter des précisions ?
Ne connaissant pas xBee je ne peut te guider sur ce point.
Je continu de regarder car avec des modules de conversion (par exemple RS232 -> Ethernet) on peut effectuer la transmission sur un "protocole" et convertir vers un autre afin de facilité l'envoi des données côté moto et réception côté paddock.
Étape 3 : réception des données.
L'émetteur paddock aura donc comme mission de récupérer les données, après la c'est un peu sombre sur le moment auquel je dois traité mes données, avant ou après le transfert des données part le port série (Rs232 je pense) vers l'ordinateur ?
Étape 4 : Affichage des données.
La c'est mon domaine, je vais voir au niveau du langage si je pars sur du C++ ou du java, mais cette partie ne devrait pas être la plus difficile.
Pour la réception et communication avec le PC, suivant la solution retenu pour la communication sans fil, on pourrai imaginer un second arduino à la réception avec un shield ethernet qui serai connecté au PC sur lequel serai installer un programme de serveur WEB (WAMP Serveur) et là aussi un développement facilité au niveau du traitement, de l'affichage et de l'éventuelle sauvegarde des données car là pas de gestion d'une liaison série RS232. Les languages utilisé serai du langage serveur pour le traitement et la sauvegarde : PHP le plus "simple" et le plus "rapide" à apprendre, pour l'affichage du HTML et du CSS (pour une éventuelle mise en forme sur l'affichage). On pourrait rajouter du JS si on veut une actualisation automatique. L'interface serai un simple navigateur internet. Je précise qu'il n'y aurait pas besoin de connexion internet puisque que le système fonctionnerai en "réseau local".(Si tu choisi cette solution, je pourrai éventuellement t'aider car c'est mon domaine) :).
- Edité par electronic100 31 octobre 2014 à 22:12:16
Fixe : Intel Pentium G3258@4.0GHz, Asrock B85M Pro3, G.Skill NS Series 8 Go (2 x 4 Go) DDR3 1333 MHz CL9, ASUS GTX560Ti 1Go, Alim FSP 700W, Boitier Zalman Z3 PlusPortable : MSI GE72 6QD Apache Pro - Intel Core i7 6700HQ Skylate, 8Go DDR4, NVidia GTX 960M, SSD Crucial M.2 SATA 275Go, HDD 1To
haaaaaa enfin un projet faisable et pas trop vague et pas trop inutile: circuit fermé (donc le mécano y peut quelque chose), distance de transmission bornée (bah c'est un circuit quoi...)
1) quand c'est en extérieur, l'infrarouge n'est jamais ton ami. sauf quand t'es sur que la luminosité va pas trop varier, que t'es seul sur la piste, bref trop de contraintes.
2) un microcontroleur, quel qu'il soit, ferait l'affaire (donc arduino aussi, même si j'aime pas...)
3) pour moi le plus simple, c'est XBEE, il faudra bien faire attention à la portée des modules que t'achete pour en avoir le bon nombre... pense bien à regarder sur la doc de la version du module tu achete, vérifier que tu peux faire des réseaux maillés avec, et pas seulement du point à point. ensuite, bah un sur la moto, et à chaque fois que tu perds le signal, bah tu remets une nouvelle balise par terre.
4) il y a un truc qui permet de faire interface xbee/PC par usb, donc pas besoin d'arduino.
5) tu dis que c'est ton métier, donc le choix je te laisse le faire, mais pour ma part, si j'avais à choisir, je partirais sur du C++/Qt. mais c'est totalement arbitraire et basé sur ce que j'ai déjà fait. PAS DE WEB C'EST NUL A CHIER POUR FAIRE DU TEMPS REEL.
@remace : Pourquoi dis-tu que le WEB est "NUL A CHIER" pour faire du temps réel ?. Si la fréquence d'actualisation est suffisante, il convient parfaitement, sachant que l'on peut "choisir" cette fréquence d'actualisation. J'ai également préciser que le système fonctionnerai en mode "réseau local" donc pas d'envoi sur un véritable serveur ni besoin de connexion internet.
- Edité par electronic100 1 novembre 2014 à 15:50:28
Fixe : Intel Pentium G3258@4.0GHz, Asrock B85M Pro3, G.Skill NS Series 8 Go (2 x 4 Go) DDR3 1333 MHz CL9, ASUS GTX560Ti 1Go, Alim FSP 700W, Boitier Zalman Z3 PlusPortable : MSI GE72 6QD Apache Pro - Intel Core i7 6700HQ Skylate, 8Go DDR4, NVidia GTX 960M, SSD Crucial M.2 SATA 275Go, HDD 1To
si tu tiens vraiment que je te cite ce qui va perturber le systeme:
apache (bah oui, php, sans un serveur php... bah ça sert a rien): ça prend du temps processeur en plus de l'affichage de la page
générer 10 fois la page complete par seconde, ça prend du temps, temps qui pourrait être consacré à autre chose.
tu sais faire qu'un site se mette à jour plus de 10 fois par seconde, (on parle d'un site local là hein...)
y'a des fonctions en PHP pour aller lire sur un port série? j'en doute.
et si tu tiens vraiment à faire de l'ajax, dans ce cas précis, bah c'est beaucoup moins pratique à coder que du java ou du C++.
bref pour moi le web c'est un bon outil pour faire des IHM distantes. mais franchement quand t'as le choix, faire uen IHM en langages web pour un usage local... je trouve ça limité. surtout pour faire de l'électronique
tu sais faire qu'un site se mette à jour plus de 10 fois par seconde, (on parle d'un site local là hein...)
y'a des fonctions en PHP pour aller lire sur un port série? j'en doute.
Voilà une page qui est programmée pour s'actualiser 20 fois par seconde : http://develop.franceserv.fr/TempsReel/tr.html
Je l'ai testé en local et elle fonctionne parfaitement, les valeurs sont fausses mais elle simulent les résultat affiché (elle sont générées aléatoirement en PHP). Si tu veux le ZIP avec les fichiers pas de problème.
Je ne te parle pas de lire sur le port série mais ont peu recevoir xBee sur un arduino qui traitera les données et les enverrait en ethernet au PC.
remace a écrit :
et si tu tiens vraiment à faire de l'ajax, dans ce cas précis, bah c'est beaucoup moins pratique à coder que du java ou du C++.
Regarde le code de la page, le trouve-tu compliqué ?
- Edité par electronic100 1 novembre 2014 à 19:56:14
Fixe : Intel Pentium G3258@4.0GHz, Asrock B85M Pro3, G.Skill NS Series 8 Go (2 x 4 Go) DDR3 1333 MHz CL9, ASUS GTX560Ti 1Go, Alim FSP 700W, Boitier Zalman Z3 PlusPortable : MSI GE72 6QD Apache Pro - Intel Core i7 6700HQ Skylate, 8Go DDR4, NVidia GTX 960M, SSD Crucial M.2 SATA 275Go, HDD 1To
Je savais que mon dernier message allé vous plaire, il m'a aidé à "m'auto orienté" dans mon projet il à fixé une vrai utilité et je sais vers quoi m'orienté.Pour ce qui est du débat de l'affichage des données je vais m'orienté vers du C++/Qt, n'y voit pas une offense @elecronic100 je ne doute en rien de la viabilité de ta solution, c'est juste que j'ai plus de compétence en ce domaine. (Le java me parait bien pour son aspect multiplatformes)
Bon je vais partir sur une petit étude des coûts, donc si vous voulez bien me donner un coup de main :).
Matériel de mesure :
On va partir simple une sonde de température.
Je partirai sur une sonde Pt100.
Emetteur / récepteur :
Arduino (en attendant que @remace me propose ce qu'il préfère ).
Edit : j'ai trouvé un autre kit "tout prêt qui a l'air un peu plus sympa que l'autre !
Et pour les balises de relais : https://www.sparkfun.com/products/8742 (faut t'il ajouter un arduino pour chaque relais ?)
Voyez vous des problèmes de compatibilité ?
Cordialement les amis !
- Edité par lilrom13 il y a environ 15 heures
1) une PT 100, je sais pas trop quelle taille ça fait, mais celles que j'utilisais au lycée étaient dans une gaine en inox, mesuraient 10cm de long, et y'avait un boitier gros comme un nokia 3310. je suppose qu'il faudra que tu en cherche une qui a un form factor adapté à ton application. à toi de voir, je te laisse faire :P. si tu trouve pas, regarde du coté des thermocouples, y'a des chances que ça ait un form factor un peu plus arrangeant.
2) moi je préfere ce que tu es sur de savoir te servir. moi j'aime pas arduino parce que j'ai appris sur un microcontroleur similaire, mais sans le framework arduino, qui selon moi est plus un frein à l'apprentissage poussé des choses qu'une vraie aide. (quand je dis poussé, c'est vraiment poussé). maintenant pour un débutant, c'est un outil comme un autre.
3) pour les "antennes relais", il faut choisir la même fréquence qu'entre les terminaux du réseau donc bien faire attention à ça j'ai déjà vu des modules 800 Mhz et 2.4 Ghz. il n'y a pas besoin d'y avoir un arduino sous chaque xbee, par contre, il faut une alimentation par balise (sinon on perd le principe "sans fil"). par ailleurs il y a des lois en france sur l'émission de puissance, renseigne-toi pour savoir combien tu peux émettre.
en conclusion, je ne saurais pas vraiment te conseiller sur le matériel précisément, à ta place je prendrais:
des modules de communication XBEE avec le connecteur antenne RPSMA (assez pour couvrir ton terrain de cross, donc 3-4, pour être large, au pire, si y'en manque y'a qu'à en racheter par après, ça se programme et après ça vit en autonomie.) toutes de la même fréquence (800 Mhz, mais je saurais pas expliquer rationnellement que ce choix est meilleur que 2.4Ghz, a part en sortant l'équation de friis qui dit que la puissance nécessaire pour faire parvenir une donnée d'un point A à un point B est plus grande quand la fréquence de la porteuse est plus grande, et le fait que la bande 2.4 GHz est déjà bien encombrée. mais je sais pas si ces arguments sont vraiment bons, vu que les fabricants de XBee semblent donner les mêmes portées aux 2 types de modules)
des antennes dipôle omnidirectionnelles RPSMA (ça ressemble un peu aux vieilles antennes sur les box internet) (même nombre que les modules XBEE)
une carte XBEE/USB (j'ai plus le nom)
un shield arduino sans le module (tu l'as déjà acheté plus haut)
un microcontroleur, arduino ou non...
ta PT100 ou n'importe quoi qui serve de proof of concept en attendant. (de mémoire, c'est cher une PT 100)
du coup, je pense pas que ce genre de lot existe, donc bien tout acheter à part. je connais pas de vendeur où c'est plus intéressant que les autres.
EDIT: j'oubliais, mais prends aussi des supports de piles ou des batteries avec leur chargeur, c'est important d'alimenter les montages, sinon ils servent a rien
Je fais un peu la même chose sur ma moto mais pas d'envois juste du stockage sur carte SD.
Mettre une PT100 , c'est pas le plus simple , thermocouple idem , faut les bons signaux courant/tension , gérer les tables de conversions ,tc ..
perso je suis parti sur des DS18B20 .. Ils montent jusqu´à 127,94°C .. Ça suffit pour moi ... Après l'huile chauffe peut être plus sur une moto cross ..
bah perso j'ai pas eu de nouvelles depuis mon dernier post.
j'ai envie de dire "have fun" pour ton projet, tu compte faire comment le traitement des données, une fois descendu de la moto et la carte dans l'ordi? "zou dans excel"? ou une interface un peu plus travaillée?
sinon... c'est pas un thermocouple dans ton bazar à mèche? (enfin dedans, avant l'ADC qui envoie les valeurs au microcontroleur qui est chargé de la communication 1-wire...)
Je ne prévois rien d'extraordinaire pour les données , je veux juste voir comment fonctionne le refroidissement de ma moto et éventuellement voir si qqch ne va pas ( chose impossible avec la pauvre instrumentation d'origine ) ainsi que le comportement de mon huile .
Bref j´ouvre mon txt avec Excel je fais une belle courbe et ça me suffit .
Normalement j'installe tout ça ce weekend .
Pour la nature du capteur du DS18B20 , honnètement je ne sais pas , mais peu importe comme tu l'as dit c'est pas moi qui m'occupe de convertir le truc en température . Après ćest surement pas une PT100 , j'ai du mal à croire à un thermocouple ( pas de CJC ?? ) , sans doute une thermistance ...
Alors je suis vraiment désolé d'avoir totalement déserté ce post, mais j'ai repris les cours juste après et je n'est plus eu une minute, ni pour moi, ni pour mes projets perso !!
Pour le moment ce n'est pas d'actualité pour moi de reprendre le projet car j'ai encore beaucoup de travail à l'école, néanmoins, je tiens à te remercier remace car c'est vrai que je ne l'ai pas fais et pourtant tu ma énormément aidé, donc excuse moi encore une fois et vraiment merci.
oui. non. enfin je regarde et je te dis.
oui. non. enfin je regarde et je te dis.
oui. non. enfin je regarde et je te dis.
oui. non. enfin je regarde et je te dis.
oui. non. enfin je regarde et je te dis.
oui. non. enfin je regarde et je te dis.
oui. non. enfin je regarde et je te dis.
oui. non. enfin je regarde et je te dis.
oui. non. enfin je regarde et je te dis.
oui. non. enfin je regarde et je te dis.