Bonjour,
Je travaille actuellement sur un projet pour récupérer plusieurs données, cela inclut 2 capteurs, 1 gps usb et une webcam usb. L’objectif étant lorsque j’appuis sur un bouton poussoir, le script de récupération de toutes ces données s’active, qu’il y a un affichage sur un écran LCD et cela dès le démarrage, de pouvoir récupérer les fichiers logs également. Pour l’instant j’ai fait un code pour les 2 capteurs qui sont le DHT22, capteur de température et d’humidité et le MPU6050 un capteur d’inclinaison en plus de cela j’ajoute dans le code le gps usb. J’ai réaliser cela avec des threads pour avoir les données sans problème d’occurrences. J’aimerais savoir dans un premier temps si mon code est bien optimisé, je rencontre des problèmes sur le script en arrière plan.
le code :
Désolé, je n’ai pas le temps de regarder ton code. Cependant, voici des astuces et choses à regarder.
- Assure toi que ton script marche sous le même utilisateur; par exemple, exécuter une commande cron ne donne pas le même résultat que de l’exécuter sous ton shell manuellement, même chose en service.
- Assure toi que si ton script démarre auto, c’est APRÈS que tout soit chargé
- Tente de travailler dans un seul dossier, comme dit, je n’ai pas vérifier ton code, mais la première ligne pour le CV2 m’inquiète… j’ai déjà eu a l’utiliser (et même sous Windows) et j’ai jamais eux à définir le chemin d’un module.
- Si ton script est « lent » ou « peux réactif », alors pense à regarder la commande «
nice », qui permet de changer/définir la priorité du processus
- Si tu es sous RPi0 v1, RPi1, la lenteur est normal et en background encore plus. Va sur le RPi2 et plus récent ou le RPi0 v2
- Un process en background est souvent plus lent, vu qu’il obtient une priorité base par défaut, sans changer le « nice », tu peux luis assigner plus d’activité pour que le système lui en donne plus, mais c’es « dur » à intégrer proprement.
- Évite le travail multiple. L’un affectera l’autre, c’est sur. Privilégie les appels a temps défini (cron) et de faire une suite d’action; soit attendre que le premier finisse pour lancer le second, et ainsi de suite…
Quoi que bien théoriquement, en pratique ça peut surcharger inutilement le script et tes demandes, surtout si un « thread » est créé plusieurs fois et non réutilisé. Isole plutôt en plusieurs scripts ou tente de regrouper. Soit plus « légé » dans les délais, je sais que le « Real ime » est « hot », mais très exigent. J’ai une sonde de température et la vérif prend ~1 secs, mais c’est mieux de « break » entre les demandes. Privilégie les données essentiels au Real Time, voir activer le « Real Time » si la donnée change de manière importante.
Alors pour résumer ce point, tes température et humidité, fait des attentes entre chaque sondage, et l’inclinaison donne lui la priorité.
Je code également Android (Java) et le conseil que plusieurs partage est de créer un Thread UNIQUEMENT SI REQUIS. Il est souvent associé à une priorité moindre que l’application principal. Le gérer peut être dur. Faut voir la priorité de l’app (parent) supérieur à un sous processus (enfant/child), et chaque sous processus ce verras associer un privilège plus faible que celui qui la créé. Je me bat moi-même avec ce problème pour mon lecteur de musique; le Thread créé pour le lecteur est souvent « kill » par le OS, mais pas l’interface (UI qui est le parent).
Bonjour la saturation du port USB. Sache que TOUT Webcam USB monopolise la bande passante, c’est un défaut que aucun fabriquant a réglé. Il est impossible de connecter un autre appareils exigent en donnée sur le même port. Si je ne me trompe pas, la majorité des RPi ont un port partagé. Alors soit trouver un GPS pour le GPIO ou une Camera Pi pour remplacer la version USB (de toute façon, de cette manière, tu gagne en qualité et rapidité du flux).