Discussion :

[xe4b4ct]

salut,

le test du PC embarqué n'est pas bien concluant. Du coup, nouvelle stratégie ...

un PC sur mesure, qui peut être évolutif en fonction des besoins.
Première idée de configuration: réseaux à fond, PoE, enregistrement de données brutes sans pré-traitement. Doit pouvoir décharger les données super rapidement.
CM: MSI X99A XPOWER TITATIUM
Processeur: Intel i7 6800K
Carte réseaux: Startech SP2000PEXPSE (Qté 2)
SSD OS: Samsung M.E EVO 960 250 Go
4 SSD data: Samsung EVO 850 1 To chacun, disposé en bloc RAID (2 x 1 To) en RAID 0, doublé en RAID 1
RAM: 8 x 16 Go, Crucial DDR$ ECC 2400 MHz

Que pensez vous de cette configuration?

Cordialement

[Vincent PETIT]

Salut,

CM: MSI X99A XPOWER TITATIUM
Processeur: Intel i7 6800K
Carte réseaux: Startech SP2000PEXPSE (Qté 2)
SSD OS: Samsung M.E EVO 960 250 Go
4 SSD data: Samsung EVO 850 1 To chacun, disposé en bloc RAID (2 x 1 To) en RAID 0, doublé en RAID 1
RAM: 8 x 16 Go, Crucial DDR$ ECC 2400 MHz

Lorsque je vois cette configuration pour l'application derrière, je me dis qu'il y a un problème quelque part et qu'il faut revenir en amont du projet pour trouver où est "l'étranglement" qui est entrain de t'amener vers la construction d'un second télescope spatiale Hubble alors que tu veux observer le fond de ton jardin ! J'exagère évidemment mais en tout cas cette configuration m'interpelle.

Par exemple, un oscilloscope Lecroy comme celui-ci (~20 000€ et 35 000€ suivant les options):

Une bête de course : bande passante 4GHz, capable de chopper 40 GS/s, il peut faire des FFT, du filtrage numérique, du décodage de trame et beaucoup d'autres calculs mathématiques et pourtant il est équipé d'un processeur Intel i5 3610 Dual Core 2.7GHz et 16Go de RAM. http://cdn.teledynelecroy.com/files/...-datasheet.pdf

Toi tu as une configuration encore plus importante et je pense sincèrement qu'il y a un problème quelque part. Soit ton algo sous Matlab te fait perdre tellement de temps qu'il faut compenser par un PC haute performance, soit tu réceptionnes beaucoup trop d'informations.

[xe4b4ct]

Bonjour Vincent,

La Config est clairement due à la quantité de données que l'on récupère. On a deux options:
Opt1: enregistrement des données brutes
Opt2: prétraitement des données pour retenir pour deux caméras, les pixels presque à saturation dans le rouge

Opt1-2: on a besoin de toute façon d'entrées indépendantes capables de gérer du 1Gbps.
Opt1: pas besoin de grosse puissance de calcul, mais d'un proc capable de gérer les flux de données mais on a besoin de capacité de stockage. La camera 9Mpix génère un peu de plus de 1To de données brutes pour 1 heure d'enregistrement. On ajoutant la 3 MPix et la camera IR, on est au totale à 1.6 To / heure.
Opt2: avec le prétraitement, on génère plus que 40 à 50 Go / heure. Par contre, on a besoin de au moins 12 coeurs de calcul et de 128 Go de RAM pour bufferiser le tout. Et là, on peut exploser la consommation électrique.

La configuration proposé est pour l'Opt 1. La RAM est pour l'instant surdimensionnée mais il se peut que l'on ai besoin de monter aussi haut. Pour les SSD, je pense qu'il faut clairement cela pour enregistrer les données: 1.6 To /h on arrive à 444 Mo/s en écriture, juste sous la limite théorique de l'écriture de SSD (ca 520 Mo/s).
Avec deux SSD en RAID0, on aurait bien plus de marge pour la vitesse d'écriture (1 Go/s) et les doubler en RAID1 permettrait de sauvegarder les données.

Pour la config proposé, on arrive à un peu de moins de 5000 euros. C'est cher, trop cher peut être mais si on réduit un peu la RAM et le proc, on devrait passer sous les 3500 euros. Toujours cher, mais compte tenu du prix des autres appareils sur le drone et du temps que j'ai déjà perdu pour essayer l'odroid, ce n'est pas si un mauvais calcul.

On peut réduire la taille du télescope, mais je veux bien au moins conserver la carte mère (qui est souple sur la RAM max).

Pour les raisons qui m'ont fait venir à cette configuration Opt1. J'ai testé un PC embarqué (i7, 32Go de RAM, SSD M.2. Windows 10 et Matlab) pour les trois plus grosse caméra. Le réseau sature, la RAM pas encore, la CPU et à 85-90% d'utilisation. L'ouverture des ports à fond, la taille du buffer à fond et l'activation des Jumbo packets - l'ordinateur à tellement demander de jus que l'alimentation à cramer.
L'Opt2. Mac Pro full option 64 Go de RAM - La RAM sature, cela passe avec 128 Go.

Donc je pense que l'on peut réduire à 32Go de RAM, peut être descendre un peu le proc mais pour le reste, je suis plutôt septique.
J'ai de plus regardé dans la cam si l'on peut enregistrer les données brutes avant Debayeurisation. Pas possible.

Pour être franc, je commence à être un peu perdu dans ces config et les retards s'accumulent. Sur quoi partirez vous comme configuration?

Cordialement

[xe4b4ct]

Re bonjour,

une nouvelle configuration pour l'Opt 1.

Carte mère: Gigabyte GA-H270-HD3
Processeur: i5-7600
Cartes réseau: 2 Startech ST2000PEXPSE
RAM (pour commencer): Corsair Vengeance LPX Low Profile (2 x 16 Go)
SSD: même configuration qu'avant: M.2 250 Go + 4 x 1To

A la louche, 2700 euros.
Est ce que cette configuration pourrait convenir? Si besoin, on peut monter la RAM à 64Go si besoin.

[Vincent PETIT]

Salut,
Le débit de ta caméra principale est de environ 300Mo/s c'est à dire que en 1s tu as 13.2 images à traiter.
As tu déterminé la vitesse de tes algorithmes ? Une image est traiter en combien de temps ? C'est hyper important de connaître la durée de traitement car ce n'est qu'a partir de là qu'on peut trouver une config.

Je prends un exemple :

300Mo arrivent dans une RAM (donc 13 images)

Étape 1 Supprimer tous les pixels inutiles et d'après ce que j'ai compris, il y en a beaucoup + Stocker les données restantes.

Combien de temps pour faire ça ? Ça aidera a déterminer la taille de la mémoire tampon.
Après ce traitement il reste combien de données sur les 300Mo ? Ça aidera a déterminer la taille du HDD pour stockage.

Étape 2 Traitement de l'image avec un programme informatique pour être beaucoup plus rapide que Matlab + Stocker les données résultantes.

Combien de temps pour faire ça ?

Étape 3 L'interface utilisateur pour l'affichage (bien sur a mettre complètement a côté du temps réel, à la limite voir même dédier cette tâche a un autre µPC) .

Combien de temps pour faire ça ?

A mon sens pour déterminer une config, il faut impérativement la réponse à toutes ces questions. Peut être que tu t'apercevra que le fait d'avoir un OS multitâches (donc qui attribut un temps pour chaque tâche) est bloquant voir complétement incompatible avec ton application. Peut être que tu t'apercevras qu'en dégageant la partie graphique de l'OS donc en gardant que le noyau, que les timings peuvent être tenus ! Sans savoir tout ça, je ne vois pas comment choisir une configuration ?




ps : Sur un Raspberry-Like, déterminer le temps de calcul est simple avec un oscilloscope.
Dans ton programme, tu allumes une LED en premier, tu fais ton traitement informatique puis tu éteins la LED. En mettant l'oscillo sur le LED tu mesures le temps durant le quel la LED était allumée, qui sera l'image du temps de traitement.
En faisant ceci, je ne serai pas surpris que tu vois une grande variation du temps de traitement si par exemple tu lances un application a côté (genre le moniteur) etc...

[xe4b4ct]

Re bonjour Vincent,

Si on reprend la camera 9 MPix.

Etape1: traiter une image prends environ 0.1 à 0.15 s. On arrive à leur faire proprement (pour les deux caméras concernées - 9 et 3 MPix et en temps réel), avec Matlab, qu'avec l'utilisation des 12 coeurs en parallèle et les 128 Go de RAM pour temporiser. Si besoin, je peux faire des essais avec 1, 2 puis 3 cameras, faire tourner le code d'acquisition et vous envoyer les impressions d'écrans de l'utilisation des ressources du mac.

Etape2: Je me suis mis à python et C++ pour d'autres projets. Je n'ai pas essayer de le faire pour celui-ci car j'aimerais vraiment rester sous Matlab. Tout le code d'acquisition de données marche sous Matlab et je ne me sens pas de le refaire dans un autre code. Idem, même si cela nous concerne pas ici, pour le traitement des données.
Je ne veux pas être non plus trop fermé, mais le but de ce projet est de fournir un drone montrable en kit (avec les capteurs à la carte), le logiciel d'acquisition et de gestion du drone qui va avec, ainsi que le logiciel de traitement de données. J'aimerai un truc qui tourne bien, facile d'utilisation et peu susceptible de crasher à cause de l'utilisation de différents languages. C'est peut être des a priori de ma part.
Pour le temps nécessaire pour traiter les images avec un autre algo, il faut voir. Mais je n'en ai aucune idée, à part que cela plus rapide que sous Matlab. Par contre, le temps pour moi de le faire, de la coder, de le tester - plusieurs semaines voire mois, sans compter le risque que cela ne marche pas.

Etape3: les interfaces utilisateurs sont faites sous Matlab (une pour l'acquisition, une pour le traitement) et seront compiler en .exe voire en .dmg pour le traitement. L'interface acquisition gère tout: paramètrage de l'acquisition, communication avec les capteurs, enregistrement des données. Il faut pour l'instant plusieurs secondes pour lancer tous les capteurs et commencer l'enregistrement - certains capteurs, non détaillés ici (car non significatifs pour la masse de données) sont un peu lents à la configuration.

Pour la configuration à retenir, à ce jour et en tenant compte des délais et du fait que je ne puisse pas vraiment valoriser (professionnellement) un autre programme avec un autre language, je serai plus partant d'avoir une configuration (pour l'Opt1 ou l'Opt2) qui tourne avec l'interface graphique et les codes que l'on a déjà.

Cela ne sera clairement pas optimiser d'un point de vue software et hardware, mais cela fera le job. Ce n'est certainement pas la philosophie de ce forum, mais c'est, je pense, la méthode la plus rapide pour arriver à mes fins et faire un peu de recherche avec ce prototype.

Cordialement

[xe4b4ct]

Re,

Un premier essai sur MacPro:

Opt1:
- Matlab et le moniteur d'activité en marche
- camera 9 MPix en acquisition, 12 images/s, pas de prétraitement:
- 1 min d'enregistrement
- le fichier .avi fait 18.12 GB
- utilisation de la mémoire: 10-12 GB
- utilisation du proc: 400 % (je pense que c'est du à l'utilisation de 4 des coeurs du proc)
- données reçues sur le réseau: 9.38 G en 1 minute

Opt2
- même conditions
- les fichiers .mat font 61 MB pour une minute
- utilisation de la mémoire 8-10 GB
- utilisation du proc: à fond, les 12 coeurs sont à 90-95% d'utilisation
- meme quantité sur le réseau

Voulez-vous que je fasse des tests avec les autres caméras?

Cordialement

[Vincent PETIT]

Cela ne sera clairement pas optimiser d'un point de vue software et hardware, mais cela fera le job. Ce n'est certainement pas la philosophie de ce forum, mais c'est, je pense, la méthode la plus rapide pour arriver à mes fins et faire un peu de recherche avec ce prototype.

D'accord,
Je comprends, le but n'est pas d'industrialiser le proto mais de l'utiliser.

Dans ce cas, je ne pense pas que des tests soient nécessaires. L'option 1 fonctionne et elle sollicite moins le hard.

[CTJayce]

Salut,

Sur le site de la caméra, ils disent qu'il faut un MTU minimum de 8228, est-ce que c'était le cas sur la odroid ?

https://www.alliedvision.com/fileadm...ion_Manual.pdf

[xe4b4ct]

Re bonjour:

@Vincent: la nouvelle option 1 (i5) ou la première?
@CTJayce: bien vu. Sur Windows, j'ai pu monté le Jumbo packet à 8048 et sur le mac à 9000. C'est peut être pour cela que je ne peux atteindre le 12 fps sur Windows mais que cela la fait sur mac.

Je vais tester la config 1 (nouvelle ou ancienne) et je vais voir ce que cela donne.
Dans un second temps, si on voit que cela chauffe trop ou consomme trop, on passera surement à une solution optimisée.

A plus