1. #21
    Membre à l'essai
    Inscrit en
    mai 2009
    Messages
    80
    Détails du profil
    Informations forums :
    Inscription : mai 2009
    Messages : 80
    Points : 16
    Points
    16

    Par défaut

    Salut à tous,

    @Kannagi, on partage la même éthique: Si un truc à 10 euros le fait, je prends. Je préfère garder du budget pour plus d'expérience. On a une enveloppe pour le projet, le moins je dépense au départ, le plus je peux faire à la fin. ce que je voulais dire est que si on a besoin d'une grosse configuration embarquée (et seulement si), il y a n'y aura pas de problème à le commander.
    Si vous connaissez des mini-PC, equivalent raspberry Pi, capable de gérer ce flux de données, je prends.

    Cam 1 et cam 2 nécessite le MacPro (64GB, avec Matlab)
    cam 3 tourne sur un MacBook Pro, sur le port ethernet ou thunderbolt mais pas sur USB
    Cam 2, cam 3 + un autre port ethernet nécessite le MacPro (64GB, avec Matlab)
    Cam 1, Cam 2, cam 3 + un autre port ethernet nécessite le MacPro (128GB, avec Matlab)

    Cela vient peut être de Matlab ou d'un mauvais code.

    @ Vincent, on a besoin de cela. Pour la cam 1, on est passé de 1 at 9 MPix, on est passé de 10 mm à 1 mm sur la précision de la géométrie interne. On a besoin de cette précision.

    @ Auteur, cam 1 et cam 2 sont dans le visible. On a en plus une camera IR. Qu'est ce que le projet OpenCV?

    Cordialement

    Mathieu

  2. #22
    Expert éminent
    Avatar de Auteur
    Profil pro
    Inscrit en
    avril 2004
    Messages
    6 769
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2004
    Messages : 6 769
    Points : 9 245
    Points
    9 245

    Par défaut

    OpenCV est une bibliothèque de fonctions qui te permet de faire du traitement de l'image en C++, Java, Python. Je pense que pour ton projet elle peut te rendre des services.
    https://fr.wikipedia.org/wiki/OpenCV
    http://opencv.org/documentation.html

  3. #23
    Modérateur

    Avatar de Vincent PETIT
    Homme Profil pro
    Ancien développeur matériel électronique (Hard/Soft)
    Inscrit en
    avril 2002
    Messages
    1 909
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Pas de Calais (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ancien développeur matériel électronique (Hard/Soft)
    Secteur : Service public

    Informations forums :
    Inscription : avril 2002
    Messages : 1 909
    Points : 6 042
    Points
    6 042

    Par défaut

    Citation Envoyé par xe4b4ct Voir le message
    @ Vincent, on a besoin de cela. Pour la cam 1, on est passé de 1 at 9 MPix, on est passé de 10 mm à 1 mm sur la précision de la géométrie interne. On a besoin de cette précision.
    Vous faites la cartographie interne de la canalisation à l'aide d'une caméra ? Puis j'imagine que vous faites un traitement d'image de type reconnaissance de forme/contour/arrête/maillage pour faire une carto 3D ?
    La science ne nous apprend rien : c'est l'expérience qui nous apprend quelque chose.
    Richard Feynman

  4. #24
    Membre à l'essai
    Inscrit en
    mai 2009
    Messages
    80
    Détails du profil
    Informations forums :
    Inscription : mai 2009
    Messages : 80
    Points : 16
    Points
    16

    Par défaut

    Bonjour Vincent,

    le but de ce projet est de fournir de la donnée non-biaisé et précise pour ce genre d'application. Mais ce n'est pas l'objet de ce projet de recherche.

    Cordialement

    Mathieu

  5. #25
    Modérateur

    Avatar de Vincent PETIT
    Homme Profil pro
    Ancien développeur matériel électronique (Hard/Soft)
    Inscrit en
    avril 2002
    Messages
    1 909
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Pas de Calais (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ancien développeur matériel électronique (Hard/Soft)
    Secteur : Service public

    Informations forums :
    Inscription : avril 2002
    Messages : 1 909
    Points : 6 042
    Points
    6 042

    Par défaut

    Ok, je demande ça car il existe d'autres solutions pour établir un cartographie 3D (calcul et représentation des distances etc...) Une solution comme la télémétrie laser, le LIDAR par exemple, permet d'obtenir un nuage de point, qui une fois reliés entres eux donnent un maillage représentant la cartographie 3D de ce qu'on a mesuré. Chaque point du nuage étant une coordonnée bien sur.

    C'est ce qui est utilisé en topographie.
    La science ne nous apprend rien : c'est l'expérience qui nous apprend quelque chose.
    Richard Feynman

  6. #26
    Membre à l'essai
    Inscrit en
    mai 2009
    Messages
    80
    Détails du profil
    Informations forums :
    Inscription : mai 2009
    Messages : 80
    Points : 16
    Points
    16

    Par défaut

    Bonjour Vincent,

    le LIDAR le fait: mais souvent lourd, souvent cher et avec des pièces mécaniques: jugé par assez robuste pour le long terme.
    Ce qu'on a fait marche très bien.

    Reste à trouver un PC embarqué ou en construire un pour monter sur la plateforme.

    Toujours à la recherche de la solution idéale: cloud de petits PCs ou une grosse bête surviatminée.

    Cordialement

    Mathieu

  7. #27
    Membre à l'essai
    Inscrit en
    mai 2009
    Messages
    80
    Détails du profil
    Informations forums :
    Inscription : mai 2009
    Messages : 80
    Points : 16
    Points
    16

    Par défaut

    Salut à tous,

    Je crois qu'il faut abandonner la solution tout en un.

    En cherchant des cousins du Raspberry Pi, je suis tombé sur:
    - l'Odroid C2
    - les Banana Pi M2/M2+/M3

    Que pensez-vous de ces petites bêtes? Dans la perspectives de les intercalés entre les capteurs et un PC maitre (petite config) sur la plateforme.

    Cordialement

    Mathieu

  8. #28
    Modérateur

    Avatar de Vincent PETIT
    Homme Profil pro
    Ancien développeur matériel électronique (Hard/Soft)
    Inscrit en
    avril 2002
    Messages
    1 909
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Pas de Calais (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ancien développeur matériel électronique (Hard/Soft)
    Secteur : Service public

    Informations forums :
    Inscription : avril 2002
    Messages : 1 909
    Points : 6 042
    Points
    6 042

    Par défaut

    Je pense aussi que tu ne trouveras pas de solution embarquée, qui répond à une config non embarquable.

    La question est plutôt, qu'est ce que tu vas leurs faire faire à ces cartes Raspberry & Consorts ?

    Dans les nanoPC destinés a des systèmes embarqués (ton téléphone portable), tu trouveras majoritairement des micro ARM car ils sont le meilleur compromis entre performances et consommation. Peu importe le micro ARM, il faut prendre en compte qu'il ne sera jamais à la hauteur d'un processeur Intel. Donc tout dépend de ce que tu souhaites qu'ils fasses entre les capteurs et le PC maître.
    La science ne nous apprend rien : c'est l'expérience qui nous apprend quelque chose.
    Richard Feynman

  9. #29
    Membre à l'essai
    Inscrit en
    mai 2009
    Messages
    80
    Détails du profil
    Informations forums :
    Inscription : mai 2009
    Messages : 80
    Points : 16
    Points
    16

    Par défaut

    Bonjour Vincent,

    le but est de contrôler la plateforme, d'acquérir les données et si possible de les compresser.

    Ces petites plateformes permettraient de collecter les données brutes, compresser et renvoyer par USB les données compressées vers un système embarqué qui centraliserait le tout.

    exemple:
    un odroid XU4 pour cam 1 qui renverrai les données, (quelques KB/s au lieu des 216 MB/s) vers un PC embarqué.
    objectif: reduction du debit de données, USB au lieu d'ethernet sur PC maitre.

    J'espère être clair dans mes propos.

    Est ce que cela vous semble une solution fiable?

    Cordialement


    Mathieu

  10. #30
    Membre confirmé
    Avatar de deletme
    Homme Profil pro
    Inscrit en
    janvier 2011
    Messages
    257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Indre et Loire (Centre)

    Informations professionnelles :
    Secteur : Industrie

    Informations forums :
    Inscription : janvier 2011
    Messages : 257
    Points : 519
    Points
    519

    Par défaut

    Sinon tu as la solution des cRIO de chez National Instrument qui sont pas mal durcis et robustes.
    "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."
    - Martin Golding
    Traduction obligatoire : "Toujours écrire du code en gardant en tête que le mec qui en assurera la maintenance est un psychopathe violent qui connait votre adresse"

  11. #31
    Modérateur

    Avatar de Vincent PETIT
    Homme Profil pro
    Ancien développeur matériel électronique (Hard/Soft)
    Inscrit en
    avril 2002
    Messages
    1 909
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Pas de Calais (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ancien développeur matériel électronique (Hard/Soft)
    Secteur : Service public

    Informations forums :
    Inscription : avril 2002
    Messages : 1 909
    Points : 6 042
    Points
    6 042

    Par défaut

    Citation Envoyé par xe4b4ct Voir le message
    un odroid XU4 pour cam 1 qui renverrai les données, (quelques KB/s au lieu des 216 MB/s) vers un PC embarqué.
    objectif: reduction du debit de données, USB au lieu d'ethernet sur PC maitre.
    En effet c'est un premier levier, faire un tampon (bufferiser les données) pour ne pas a avoir à déployer une énorme puissance de calcul en temps réel. En faisant cela on accepte de perdre un peu de temps réel pour mieux répartir ou lisser les calculs. Ce qui pose la question de l'utilité d'embarquer un OS, par définition peu rapide car multitâches, pour faire de l'acquisition-> compression-> émission ? Un bonne algorithme bien pensé sur une cible mois gourmande comme un microcontrôleur, sera nettement plus efficace et plus rapide qu'un gros ARM non temps réel, qui fait tourner je ne sais combien de tâche inutile.

    Un deuxième levier et de s'intéresser à Matlab puisqu'il ne fait que exécuter un algorithme pourquoi ne pas avoir écrit en C par exemple, l'algo que Matlab utilise et avec une interface graphique bien plus légère ? D'ailleurs y a t-il une interface graphique ? Quelqu'un descend dans la canalisation avec le drone pour regarder un écran ?
    La science ne nous apprend rien : c'est l'expérience qui nous apprend quelque chose.
    Richard Feynman

  12. #32
    Membre à l'essai
    Inscrit en
    mai 2009
    Messages
    80
    Détails du profil
    Informations forums :
    Inscription : mai 2009
    Messages : 80
    Points : 16
    Points
    16

    Par défaut

    Bonjour Vincent,

    Du coup, un micro-controlleur en lieu et place des Odroid ou autre? L'idée me plait mais où cela se trouve? en quel language cela se programme?
    Il faudrait un model avec une entrée ethernet, une sortie USB (et un peu de RAM? pour stocker si le MC tourne dans la semoule).

    Matlab? C'est le seul language que je connaisse: 90 % du code d'acquisition et aussi de celui de traitement des données a été déjà écrit. Pour être franc, ni le temps ni vraiment l'envie de tout ré-écrire en C ou autre.
    On a une interface graphique presque finie (sous Matlab) pour le paramétrage, l'acquisition et le contrôle du bon lancement des capteurs: indispensable.

    @deletm: j'adore le hardware NI et j'en ai déjà essayé sur le projet (mais pass assez rapide)> En plus leur soft et SAV sont en dessous de tout.

    Cordialement

    Mathieu

  13. #33
    Membre confirmé
    Avatar de deletme
    Homme Profil pro
    Inscrit en
    janvier 2011
    Messages
    257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Indre et Loire (Centre)

    Informations professionnelles :
    Secteur : Industrie

    Informations forums :
    Inscription : janvier 2011
    Messages : 257
    Points : 519
    Points
    519

    Par défaut

    @xe4b4ct,

    Leurs produits embarquent quand même un FPGA, ça doit quand même bien tourné. Après il est vrai que c'est un coût non négligeable.

    As-tu regardé du côté des cartes équipés d'un DSP + µC/P ou d'un FPGA + µC/P ?
    "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."
    - Martin Golding
    Traduction obligatoire : "Toujours écrire du code en gardant en tête que le mec qui en assurera la maintenance est un psychopathe violent qui connait votre adresse"

  14. #34
    Membre à l'essai
    Inscrit en
    mai 2009
    Messages
    80
    Détails du profil
    Informations forums :
    Inscription : mai 2009
    Messages : 80
    Points : 16
    Points
    16

    Par défaut

    Salut deletme,

    On avait essayer cela: NI CVS-1458. Trop lent pour cam 1 et cam 2. Renvoyé à NI.

    je vais regarder un peu ce que tu conseille.


    Cordialement

    Mathieu

  15. #35
    Modérateur

    Avatar de Vincent PETIT
    Homme Profil pro
    Ancien développeur matériel électronique (Hard/Soft)
    Inscrit en
    avril 2002
    Messages
    1 909
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Pas de Calais (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ancien développeur matériel électronique (Hard/Soft)
    Secteur : Service public

    Informations forums :
    Inscription : avril 2002
    Messages : 1 909
    Points : 6 042
    Points
    6 042

    Par défaut

    Citation Envoyé par xe4b4ct Voir le message
    Pour être franc, ni le temps ni vraiment l'envie de tout ré-écrire en C ou autre.
    Ok je comprends mais du coup on ne peut pas se tourner vers les solutions plus bas.

    Citation Envoyé par xe4b4ct Voir le message
    Du coup, un micro-controlleur en lieu et place des Odroid ou autre? L'idée me plait mais où cela se trouve? en quel language cela se programme?
    Il faudrait un model avec une entrée ethernet, une sortie USB (et un peu de RAM? pour stocker si le MC tourne dans la semoule).
    Oui l'idée était de confier à un microcontrôleur la tache "acquérir > compresser > envoyer". Pas de système d'exploitation multitâche, juste un programme qui tourne en boucle pour faire simplement le job.
    Problème, beaucoup de boulot et de temps car prendre en main de tels composants n'est pas simple.

    Citation Envoyé par deletme Voir le message
    Leurs produits embarquent quand même un FPGA, ça doit quand même bien tourné. Après il est vrai que c'est un coût non négligeable.
    En effet, je pense aussi que c'est ce qu'il y aura de plus rapide mais c'est du gros boulot aussi.


    Comme tu es sur la fin de ton projet visiblement (embarquer un système qui fonctionne déjà), tu ne peux plus te permettre de te relancer dans du développement aussi conséquent..... et je n'ai pas de solution.
    La science ne nous apprend rien : c'est l'expérience qui nous apprend quelque chose.
    Richard Feynman

  16. #36
    Membre à l'essai
    Inscrit en
    mai 2009
    Messages
    80
    Détails du profil
    Informations forums :
    Inscription : mai 2009
    Messages : 80
    Points : 16
    Points
    16

    Par défaut

    Re bonjour Vincent,

    Si le micro-controlleur peut gérer les données caméras, extraire les pixels d'intérêt et renvoyer cela vers le PC maitre je prends.
    Je peux prendre un étudiant voire une entreprise extérieure pour coder ce micro-controlleur. Ou le faire moi-meme si le jeu en vaut la chandelle.

    Un MC pour cam 1, un autre pour cam 2 et un dernier pour cam 3 serait bien: on réduirait le flux de données et on pourrait utiliser un PC embarqué standard en maitre.
    Si on prends une cam 4 et une cam 5, MC aussi.

    On est au début du projet, mais j'ai déjà pas mal bossé (en encadrant des étudiants) sur les différentes parties du projet (capteurs): tout reprendre en C prendrait un temps fou. Je viens de passer deux semaine chez un fournisseur pour utiliser leur capteur avec Matlab.
    Par contre adapter les interfaces graphiques (la principale et les secondaires) et des codes d'acquisition pour récupérer les données des MC au lieu des caméras, je pourrai le faire rapidement.
    Deux des capteurs nécessitent une interface pour leurs paramètrages: spécifiques à la conduite et aux conditions d'écoulement.

    En PJ, une architecture possible (faite à la main).

    Cordialement

    Mathieu

    20170209124354.pdf

  17. #37
    Modérateur

    Avatar de Vincent PETIT
    Homme Profil pro
    Ancien développeur matériel électronique (Hard/Soft)
    Inscrit en
    avril 2002
    Messages
    1 909
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Pas de Calais (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ancien développeur matériel électronique (Hard/Soft)
    Secteur : Service public

    Informations forums :
    Inscription : avril 2002
    Messages : 1 909
    Points : 6 042
    Points
    6 042

    Par défaut

    Pour les caméras 1 à 5, je vois les débits mais quelle est le format de sortie ? Éthernet uniquement, pas d'autres possibilités à tout hasard ?
    La science ne nous apprend rien : c'est l'expérience qui nous apprend quelque chose.
    Richard Feynman

  18. #38
    Membre à l'essai
    Inscrit en
    mai 2009
    Messages
    80
    Détails du profil
    Informations forums :
    Inscription : mai 2009
    Messages : 80
    Points : 16
    Points
    16

    Par défaut

    Bonjour Vincent,

    Cam 1, 2 et 3 sont en ethernet
    Cam 4 le sera probablement aussi
    Cam 5 est une petite webcam, peut être de l'USB: pas sur que l'un ait besoin d'un MC pour celle-ci.

    Est ce que le schéma semble logique?

    Cordialement

    Mathieu

  19. #39
    Modérateur

    Avatar de Vincent PETIT
    Homme Profil pro
    Ancien développeur matériel électronique (Hard/Soft)
    Inscrit en
    avril 2002
    Messages
    1 909
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Pas de Calais (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ancien développeur matériel électronique (Hard/Soft)
    Secteur : Service public

    Informations forums :
    Inscription : avril 2002
    Messages : 1 909
    Points : 6 042
    Points
    6 042

    Par défaut

    Salut Mathieu,
    Petite question: le débit de ta caméra est en Mo/s ou en Mbit/s ? Ça me paraît énorme 256Mo/s sur ethernet même si c'est possible, tu aurais un lien vers la doc de cette caméra ?


    Citation Envoyé par xe4b4ct Voir le message
    Un MC pour cam 1, un autre pour cam 2 et un dernier pour cam 3 serait bien: on réduirait le flux de données et on pourrait utiliser un PC embarqué standard en maitre.
    Si on prends une cam 4 et une cam 5, MC aussi.
    Oui ça réduirait considérablement le flux de données surtout si tu en rejettes beaucoup.
    Le problème c'est que la caméra 1 nécessite un microcontroleur avec un port ethernet très rapide et c'est très difficile à trouver car à ces vitesses là c'est du FPGA qu'on utilise.


    Citation Envoyé par xe4b4ct Voir le message
    On est au début du projet, mais j'ai déjà pas mal bossé (en encadrant des étudiants) sur les différentes parties du projet (capteurs): tout reprendre en C prendrait un temps fou. Je viens de passer deux semaine chez un fournisseur pour utiliser leur capteur avec Matlab.
    D'accord donc il ne faut pas faire marche arrière.


    Citation Envoyé par xe4b4ct Voir le message
    Est ce que le schéma semble logique?
    Oui il est logique car il ressemble à une chaîne de traitement du signal. Filtre antirepliement(caméra)->acquisition(caméra)->traitement(MC qui fait presque de la decimation)->traitement(PC) et parce que ça disperse la charge total sur des techno pertinente.

    Pour moi c'est une très bonne solution si le prétraitement confié au MC/FPGA est simple dans le sens pas trop de calcul gourmand.
    La science ne nous apprend rien : c'est l'expérience qui nous apprend quelque chose.
    Richard Feynman

  20. #40
    Membre à l'essai
    Inscrit en
    mai 2009
    Messages
    80
    Détails du profil
    Informations forums :
    Inscription : mai 2009
    Messages : 80
    Points : 16
    Points
    16

    Par défaut

    Bonjour Vincent,

    Voici le doc pour la camera 1: ici
    Celui de la cam 2 est .
    Les deux sont utilisées en 12 bit, 12 fps, résolution max et en couleur.

    Ici, une partie des articles déjà publiés:
    Part 1
    Part 2

    Je suis heureux de lire qu'il ne faut pas tout jeter.

    De plus, j'ai trouvé un étudiant pour 6 mois: robotique et ICT . Il va pouvoir s'occuper de cela, mais j'aurai toujours besoin de vos conseils pour l'architecture du système d'acquisition.
    Des idées des MC/FPGA qui puissent gérer les caméras?

    Cordialement,

    Mathieu

Discussions similaires

  1. [2012] Recherche un avis index sur grosse table en 2012 Standard
    Par Donpi dans le forum Développement
    Réponses: 6
    Dernier message: 01/08/2016, 18h48
  2. [SILOG] Recherche aide sur macro embarquée
    Par cerede2000 dans le forum Forum général ERP
    Réponses: 0
    Dernier message: 23/06/2016, 16h29
  3. Réponses: 1
    Dernier message: 09/01/2013, 12h45
  4. Réponses: 3
    Dernier message: 05/12/2007, 23h19
  5. Recherche script d'analyses de la configuration d'un PC
    Par patine31 dans le forum Scripts
    Réponses: 2
    Dernier message: 31/03/2006, 18h11

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo