[Résolu] Pas d'affichage HDMi au démarrage de la raspberry pi
[Résolu] Pas d'affichage HDMi au démarrage de la raspberry pi
Date
07.05.2021
Qui a rencontré le problème
Guillaume
Description du problème
Au démarrage de la raspberry, l'écran affiche "no signal"
Description de la solution
2 solutions
1/ Timing
Dans le cas où un écran est nécéssaire, la raspberry doit toujours être mise en tention après avoir relié l'écran à la raspberry pi .
2/ Programme
On peut aussi forcer le démarrage de la connexion HDMi :
Brancher la carte SD contenant l'OS sur l'ordinateur. Se rendre dans la partition boot, puis chercher le fichier texte nommé "config.txt", l'ouvrir avec un editeur de texte.
Retirer le "#" devant le seconde ligne des parties suivantes
# uncomment if hdmi display is not detected and composite is being output #hdmi_force_hotplug=1
# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1
Enregistrer le fichier
Réinsérer la carte SD dans le raspberry Pi 4 et la démarrer.
[Résolu] Le capteur ILS du stop d'arrêt ne fonctionne pas
[Résolu] Le capteur ILS du stop d'arrêt ne fonctionne pas
Date
19.07.2022
Qui a rencontré le problème
Jean-Louis Poupin, Justin Rouxel, Guillaume Leguen & Maël Boussange
Description du problème
Le KOSMOS a besoin de se stopper dans sa rotation afin de marquer des pauses par angles de 60°.
Ces pauses sont contrôlées par un ILS qui doit stopper la rotation du KOSMOS après avoir détecté un aimant.
Or la détection de cet aimant par l’ILS n’est pas systématique voir absente.
Cette fiche retrace donc l’ensemble des démarches qui ont été mises en place afin de résoudre ce problème de mauvais fonctionnement du capteur.
[Solution] : L’ILS doit recevoir une impulsion électronique de 3.3V afin de fonctionner proprement, ce qui n’était pas le cas dans notre configuration. La carte électronique sera changée en conséquence afin de délivrer du 3.3V à l’ILS.
A l’aide d’un voltmètre, des tests de continuités sont effectués de manière à vérifier la bonne réception du signal à travers différentes sections du circuit électronique.
Constat : lorsque l’ILS est dans son berceau en dessous de l’aimant et que l’on fait tourner le moteur, il y a 3 bips (anormal)... + le moteur ne s’arrête pas (système K2 + ILS K2)
Lorsque l’on éloigne un peu l’ILS de l’aimant, on observe que les 3 bips disparaissent et un long bip est entendu avec le voltmètre. En revanche, le moteur ne s’arrête pas pour autant.
Test système K2 sur ILS K2 (ILS + loin de l’aimant) >> tout est OK, on a un bip au niveau du voltmètre lorsque l’on passe l’aimant devant l’ILS K2 + vérification OK de toute la chaîne entre l’ILS jusqu’au connecteur de la raspberry MAIS lorsque l’on utilise le réducteur K2 avec le système K2, nous n’avons pas d’arrêt du moteur
Test système K1 sur ILS K2 >> Le KOSMOS K1 tourne parfaitement avec l’ILS K2 et le système se stoppe lorsque l’aimant passe devant l’ILS K2 et quelle que soit la distance entre l’aimant et l’ILS K2 MAIS le moteur fait tourner le système K1 dans le sens inverse par rapport à système K2 + ILS K2
Test système K2 sur ILS K2 (avec code su système K1) >> nous avons mis la clé USB contenant le .ini et la carte SD du K1 dans le système K2. Puis nous avons connecté le système K2 sur l’ILS K2. le moteur va plein balle… Le moteur ne s'arrête pas lorsque l’aimant passe devant l’ILS. Pour la vitesse du moteur, le .ini n’est pas adapté pour l’ESC du K2
Pistes :
Problème électronique : vérifier la carte du K2 par rapport au câblage du K1 (mêmes résistances ? mêmes composants ?)
Problème de GPIO dans la Rabspberry Pi ?
Endommagement de la carte lorsque la Raspberry Pi a grillé ?
Mercredi 20 juillet 2022 - Maël
Reprise des tests de détection de l’ils
Test système K2 sur ILS K2 (avec un écran branché sur la raspberry et affichage d’une réponse de l’ils dans le code)
4.1 Premier test dans la configuration de la veille : (non branché à l’écran) aucune détection.
(fils et capteur non accessibles)
4.2 Second test en branchant le kosmos à l’écran : (sans pilotage automatique)
Nous avons bien une réponse machine de la détection de l’aimant par l’ils. Le moteur est en mesure de s’arrêter, de façon aléatoire et non récurrente. Quelque soit l’aimant (roue ou manuel)
(les fils non accessibles mais capteur manipulé)
4.3 Troisième test : inclusion du message “moteeuuuur” lors de la détection de l’aimant.
→ Le message est visible et prouve bien la réaction du système face à la détection de l’aimant.
Le moteur est en mesure de s’arrêter, toujours de façon aléatoire et non récurrente.
4.4 Quatrième test : le kosmos est débranché de l’ordinateur. Celui-ci marque un arrêt (non systématique) avec l’aimant manuel ou celui de la roue.
→ Difficile de déterminer la raison de la détection soudaine de l’aimant par l’ils
Suspicion que la manipulation du capteur ai un impact
>> ACTION : changer l’ILS et le mettre plus loin sur le support du réducteur
Test système K2 sur ILS K2 : tests de positionnement
Le bon fonctionnement de la détection de l’ils en fonction de sa position est très aléatoire.
Pour une même position, il est possible d’avoir une détection tout comme une absence de détection. Il ne semble pas y avoir une position privilégiée du moment que l’aimant est dans le champ de détection du capteur.
Différentes positions du capteur ont été testé : position extérieure (mode K1) , mi-enfoncé dans l’encoche, complètement enfoncé dans l’encoche (position K2).
Sur la tranche ou sur l’extrémité.
→ les résultats de réponses sont trop aléatoires pour obtenir une quelconque corrélation.
Test système K2 sur ILS K2 : présence d’un faux-contact/vibrations ?
Lorsque l’on maintient les fils du capteur ou la capsule avec les doigts on pourrait corréler une meilleur probabilité de détection que lorsque le capteur est scotché à la parois (dans une position quelconque.)
Peut-être que le maintien des fils/du capteur limiterait les (fortes) vibrations émises par le réducteur ou limiterait un faux contact.
Test du capteur dans sa position classique K2 (dans l’encoche) maintenue par un scotch.
On observe la réactivité du capteur face à la détection de l'aimant dans 2 configurations :
fils libres
fils maintenues avec les doigts
Test sur 20 séries dans chaques configurations
Observations : Lorsque que les fils sont libres, il y a beaucoup plus d'échecs de détection mais non systématiques.
Lorsque les fils sont maintenus avec les doigts il y a beaucoup plus de réussite mais également quelques échecs de détection.
Ainsi il n’y a pas de corrélation parfaite, seulement une piste de réflexion.
Cette sensibilité dans la réussite/échec de détection n’est par ailleurs pas cohérente avec le test 2. (K1 sur ILS K2). En effet le K1 tourne parfaitement et sans erreurs de détection sur la base du K2.
→ Cela écarte la piste du faux contact dans la base K2 et l’effet des vibrations.
Hypothèse :Dès lors que l'on vient créer un contact entre nos doigts et les fils de l’ils, le contact avec la terre est probablement rendu possible ou est du moins favorisé. Il faut revoir les connexions entre l’ils et la masse.
Pistes :
Pourquoi y aurait-il un faux contact du K2 sur base K2 et non K1 sur base K2 ?
La longueur du fil peut-il avoir un impact ? (déjà trop long dans le K2 ?)
Y a-t-il un problème de liaison entre l’ils et la terre ? → revoir la connexion entre l’ils et la terre.
Vendredi 22 Juillet 2022 - Jean Louis, Guillaume & Maël
Le problème a été résolu !
Il s'agissait d’un problème de conception électronique au niveau du PCB.
En effet, l’ILS devait être alimenté par un courant de 3.3V pour pouvoir être en mesure de détecter l’aimant proprement.
Or, l’ILS était branché entre une masse (fil rouge), et son port GPIO21 (fil noir). Le port GPIO21 étant la connectique de sortie connecté à la résistance R6 de 1K.
L’ILS était donc connecté entre deux masses et n’avait pas l’alimentation requise.
Test d’une nouvelle connectique pour l’ILS avec un apport de 3.3V
L’ILS est désormais branché au port GPIO21 (fil noir) ainsi qu’à une alimentation 3.3V (fil rouge). Le 3.3V est pris temporairement en amont des résistances R7 et R8 à l’aide d’une pince crocodile.
Avec l’apport du 3.3V, le stop d’arrêt du kosmos marche parfaitement.
Un nouvel agencement de la carte électronique sera vu prochainement afin d'apporter proprement du 3.3V à l’ILS
Mais pourquoi avions-nous parfois un signal de l’ILS alors que le circuit électronique n’était pas bon ?
L’ILS possède une petite bobine et le passage de l’aimant en mouvement à proximité de celle-ci peut créer une induction électromagnétique suffisante pour renvoyer un signal au programme. Seulement, cela est très sensiblement dépendant de la vitesse de passage de l’aimant ou de l’orientation du capteur. Cela explique donc pourquoi nous avions une détection possible aléatoire.
Notice de calibration du KOSMOS - Paramétrer la pause d'observation 30 secondes.
Notice de calibration du KOSMOS - Paramétrer la pause d'observation 30 secondes.
Date
25.08.2022
Qui a rencontré le problème
Maël Boussange
Description du problème
Cette notice permet de résumer la calibration du KOSMOS de manière à paramétrer la pause d’observation de 30 secondes par secteurs.
Description de la solution
La réalisation de la calibration du KOSMOS doit être effectuée dans l’air, puis dans l’eau.
La première calibration dans l’air permet de vérifier la cohérence du protocole d’observation :
Démarrage du moteur, passage d’un cran dans la croix de Malte, arrêt du moteur par l’ILS, et durée de la pause d’observation.
La seconde calibration dans l’eau permet d’obtenir une durée précise de la pause d’observation. En effet, dû à une importante différence de densité entre l’air et l’eau, le système de réduction ne se comportera pas de la même façon et le temps de calibration sera différent.
Note : Influence de l’eau sur le temps de rotation du kosmos
La présence de l’eau va considérablement contribuer à la perte de puissance du système de réduction. Cette résistance entre un fluide qui s’oppose au corps de l’engrenage s’appelle une perte par ventilation. L’expression du coefficient de perte par ventilation est ainsi directement fonction de la densité du fluide (rhô).
Par exemple la densité de l’air à Concarneau est d’environ rhô=1, 195 kg/m3 (à 20° et 90% d’humidité). Tandis que la densité de l’eau à 10m est d’environ rhô=1 025,556 kg/m3 (avec 17.2°C, 35.2 psu et 2 bar). Nous avons donc un facteur 10 puissance 3.
Expression du coefficient de perte de puissance par ventilation
avec S une aire de référence, oméga la vitesse de rotation de l’engrenage, R le rayon de l'engrenage et C l’expression du coefficient de couple adimensionné déduit de l’équation de quantité de mouvement de Navier-Stokes.
Paramétrage de la pause
La pause d’observation dépend de trois paramètres.
Ces paramètres sont modifiables par le réglage de trois variables présentes dans le code :
La durée de la pause
La variable paramétrant la durée de la pause est présente dans le fichier kosmos_config.ini présent dans la clé de sauvegarde vidéo.
Modifier la valeur SETT_MOTOR_STOP_TIME (ligne 12) pour changer le temps de pause, en secondes.
Il ne suffit pas de renseigner 30 secondes pour avoir un arrêt sur secteur de 30 secondes. Il faudra également déduire le temps nécessaire pour entraîner mécaniquement la caméra sur le secteur suivant. Ce temps à déduire est d’autant plus long que la vitesse de rotation du moteur est petite.
La variable SETT_MOTOR_STOP_TIME désigne donc le temps entre deux ordre de démarrage du moteur.
La durée de fonctionnement du moteur
La variable paramétrant la durée de fonctionnement du moteur est également présente dans le fichier kosmos_config.ini présent dans la clé de sauvegarde vidéo.
Modifier la valeur SETT_MOTOR_RUN_TIME (ligne 60) pour changer le temps de rotation du moteur.
Cette valeur désigne donc le temps nécessaire pour entraîner le kosmos sur son prochain cran de la croix de malte. Il peut varier de 6 à 20 secondes suivant la vitesse de rotation du moteur.
Cette valeur peut être surévaluée car le stop d’arrêt viendra empêcher le système de tourner de plus d’un cran.
L’arrêt de la rotation (Top d’arrêt ILS)
La variable paramétrant l’arrêt de la rotation est présente dans le fichier kosmos_main.py
L’arrêt de la rotation se fera par le passage régulier d’un aimant dans le champ de détection du capteur ILS top d’arrêt.
Seulement, le champ de détection de l’aimant peut être plus ou moins important suivant les composants, il est donc important de paramétrer la durée de détection de l’aimant par l’ILS. Si cette durée est trop longue, l’aimant risque d’être détecté deux fois, et le système marquera deux pauses sur le même secteur.
Dans la procédure working() (ligne 103)
Une fonction time.sleep() est renseignée trois fois.
Dans les parenthèses du second appel de la fonction (ligne 141), renseigner le temps pendant lequel l’ILS ne devra pas être détecté. Plus le temps renseigné est long, plus l’aimant aura une chance de sortir du champ de détection sans être détecté une nouvelle fois. Une durée de 4 secondes semble raisonnable. Renseigner alors time.sleep(4).
Attention à ne pas mettre un temps trop élevé de manière à éviter que le kosmos ne tourne de plusieurs crans.
Procédure :
Dans un premier temps, calibrer la durée de fonctionnement du moteur et l’arrêt de la rotation de manière à ce que le KOSMOS tourne et s’arrête secteurs par secteurs. (faire varier SETT_MOTOR_RUN_TIME et time.sleep).
Faire ensuite varier la durée de la pause de manière à obtenir 30 secondes de plan fixe par secteurs. (faire varier SETT_MOTOR_STOP_TIME). Il faudra prendre en compte le temps pris par le système de réduction entre le démarrage du moteur et l'entraînement du KOSMOS sur le prochain cran.
Ajuster les paramètres de manière à obtenir un système respectant les pauses de 30 secondes dans l'air. Faire ensuite le test dans l'eau et observer la différence de temps d'observation sur la vidéo enregistrée. Réduire le temps exédant en diminuant la variable SETT_MOTOR_STOP_TIME.
J'ai donné les droits au script install.sh.
L'install fonctionne mais renvoi quelques erreurs :
Failed to set wall message, ignoring: Interactive authentication required.
Failed to reboot system via logind: Interactive authentication required.
Failed to open initctl fifo: Permission denied
Failed to talk to init daemon
Je pense qu'il lui manque des droits qu'en dis-tu ?
Je te propose l'ajout de
sudo
dans install.sh devant
reboot
. (proposition faite sur ta branche).
Lancement
Puis j'ai tenté de lancer lancement.sh
Un premier refus.
J'ai donc changé les droits avec
sudo chmod u+x lancement.sh
J'ai aussi changé les chemins pour trouver la clé USB dans lancement.sh
la clé est sur
/media/kosmos2/00clef
Le programme est sur
/home/kosmos2/kosmos_software/kosmosV3-env
J'ai modifié aussi kosmos_find_usb.sh avec le bon chemin.
J'ai relancé le lancement.sh et j'obtiens :
./lancement.sh: line 9: /sys/class/i2c-adapter/i2c-1/new_device: No such file or directory
Try sudo apt-get install python-smbus
DEBUG:root:DEBUT INIT config
DEBUG:root:Recherche clef usb lancement script : ./kosmos_find_usb.sh /media/kosmos2
Traceback (most recent call last):
File "/home/kosmos2/kosmos_software/kosmosV3-env/kosmos_main.py", line 293, in
myMain = kosmos_main()
File "/home/kosmos2/kosmos_software/kosmosV3-env/kosmos_main.py", line 40, in __init__
self._conf = KConf.KosmosConfig()
File "/home/kosmos2/kosmos_software/kosmosV3-env/kosmos_config.py", line 46, in __init__
self._usb_path = self.find_usb_path()
File "/home/kosmos2/kosmos_software/kosmosV3-env/kosmos_config.py", line 25, in find_usb_path
result = subprocess.run(["./kosmos_find_usb.sh",
File "/usr/lib/python3.9/subprocess.py", line 505, in run
with Popen(*popenargs, **kwargs) as process:
File "/usr/lib/python3.9/subprocess.py", line 951, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
File "/usr/lib/python3.9/subprocess.py", line 1823, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: './kosmos_find_usb.sh'
Là j'avoue que je ne comprend pas. Il semblerait qu'il y ai un problème avec l'I2C. A voir si il n'y avait pas un truc à installer pour l'horloge. Hwclock ? Je regarde...
Hwclock est bien là mais il ne peut accéder à une horloge hardaware il me dit. Il doit y a voir don un PB de chargement de l'I2C.
Pour la suite, cela m'échappe. il semble chercher kosmos_find_usb.sh...
On peut répéter cette oppération avec et sans la connexion au capteur de pression. Ainsi on s'assure d'avoir le bon port. Ici j'obtien le canal 68 pour l'horloge et 76 pour le capteur de pression.
Notifier le nouveau composant installé au système :
echo ds3231 0x68 | sudo tee /sys/class/i2c-adapter/i2c-1/new_device
Lire l'heure du RTC :
sudo hwclock
Configuration depuis le internet: (choisir le bon fuseau horraire):
Problème : Le réducteur du KOSMOS 2 est trop bruyant.
De manière à garantir une observation discrète des écosystèmes marins, le système kosmos doit être le moins bruyant possible. Due à sa plus grande densité, on estime que le son se propage 4 fois plus vite dans l’eau que dans l’air. Il est ainsi primordial de garantir une réduction drastique du bruit généré par les engrenages.
Pour différentes raisons qui seront développés ci-dessous, la première reproduction (réducteur k2) est beaucoup trop bruyante et risque de perturber la cohérence des relevés vidéos. Nous allons ainsi tenter de déterminer les sources de ces nuisances sonores puis allons proposer des améliorations ou des pistes de recherches afin de pallier à ce problème.
Plan d’action :
1 - Étude technologique : Déterminer les avantages et inconvéniants du système de réduction
2 - Analyse du problème : Déterminer les sources potentielles de bruit sur le réducteur K2.
3 - Réétude du montage et de la fabrication : Corriger les problèmes détectés dans la reproduction du réducteur, sans modifications technologiques.
4 - Étude de conception 1 : Proposer des améliorations techniques mineures en conservant le même mode de réduction si le bruit persiste.
5 - Étude de conception 2 : Proposer des améliorations techniques majeures si le mode de réduction actuel s’avère être encore trop bruyant.
Description de la solution
Étude technologique
Comparaison de la version actuelle avec le système staviro : avantages et inconvénients
Cette première partie permet de faire une comparaison effective entre le système STAVIRO et le KOSMOS. Le STAVIRO étant le système de déploiement initial développé par l’IFREMER depuis 2007 dont lequel le KOSMOS est inspiré.
Le but de cette partie est de rappeler les différences majeures de conception et de propositions technologique entre ces deux systèmes afin d’en observer les conséquences sur le bruit émis par le système de réduction.
Elle pourra notamment faciliter le regard porté sur la réalisation des études de conception (parties 4 et 5 du plan d’action) et aider à comprendre les enjeux de réalisation du système KOSMOS.
Avantages :
Le système STAVIRO n’est muni que de deux engrenages, il y a donc qu’un seul contact de transmission.
Cela facilite grandement sa fabrication, sa reproduction, son montage et limite ainsi les erreurs de jeu ainsi de le bruit de contact (dents contre dents)
Inconvénients :
Les engrenages utilisés sont en métal usiné ce qui les rend certes plus performant mais plus lourd et difficilement reproductibles, du moins ils ne sont pas usinables au fab lab.
Concernant le moteur :
Avantages :
Le moteur est un pas à pas ce qui le rend relativement précis et facile à programmer. Il est lent en rotation contrairement au moteur brushless dont le KOSMOS est équipé.
Inconvénients :
Le moteur pas à pas est bruyant lorsqu’il tourne, contrairement au brushless.
Il n’est pas étanche ce qui le contraint à être isolé dans un caisson étanche
Avantage :
Le système KOSMOS est muni d’une croix de malte ce qui permet de répartir mécaniquement les angles de rotation de la caméra de façon très précise.
Malgré la complexité du système de réduction, la reproductibilité est facile.
Nous utilisons du polyoxyméthylène (POM) pour fabriquer nos pièces ce qui les rends usinables sur des fraiseuses numériques courantes.
Le montage des engrenages est intuitif et se fait sans trop de difficultés.
Inconvénients :
Les engrenages sont au nombre de 8, soit 4 contacts dents à dents interposés qui viennent s’ajouter au mécanisme de la croix de malte.
Plus il y a de contacts, plus il y aura de bruits de contact dents à dents si le profil de denture n’est pas parfaitement usiné. Le système est donc plus difficile à dimensionner et les erreurs de jeu entre les dents sont beaucoup plus nombreuses.
Les deux axes de rotations doivent donc être parfaitement parallèles.
Il suffit d’une erreur de dimensionnement sur un pignon pour dérégler les autres contacts dents à dents
Le système est encombrant.
Concernant le moteur :
Avantage :
Le réducteur KOSMOS est équipé d’un moteur Brushless ce qui le rend silencieux et étanche.
Inconvénients :
Le moteur brushless tourne à très haute vitesse de rotation ce qui impose un système de réduction important.
Conclusion :
Le système STAVIRO est bruyant au niveau du moteur mais est bien plus facile à monter et à reproduire par la simplicité de sa mécanique.
Le système KOSMOS est équipé d’un moteur brushless pouvant être silencieux et étanche.
En revanche sa grande vitesse de rotation requiert une réduction importante.
Le système de réduction est donc plus complexe et les erreurs de précisions peuvent être importantes. Notamment le contact entre les dents des engrenages et le jeu entre les pièces sur l’arbre de rotation.
Analyse du problème
Test comparatif de comportement et de niveau sonore
Dans un premier temps nous allons réaliser une série de tests de manière à pouvoir comparer quantitativement le son émis par chacun des dispositifs de réduction.
Le test est réalisé dans une pièce pouvant maximiser l’isolation phonique. Il s’agit ici de la salle de bain de la “Tiny House” du Low tech lab que l’on peut modéliser par un caisson de bois de dimensions h=190cm l=200cm et L=70cm.
On placera chaque dispositif à 1m de la prise de son.
La prise de son est réalisée par l'application “Decibel X”.
Un calibrage du sonomètre est réalisé de manière à considérer le niveau sonore de la pièce à 0 dB.
Les valeurs de niveaux qui vont être relevés par la suite sont donc relatives à la calibration qui a été effectuée dans des mêmes conditions d’expérience (même capteur, même distance émission-réception, et niveau zéro identique). Nous pouvons donc comparer les résultats obtenus uns à uns mais il ne sera pas cohérent de comparer ces valeurs à d’autres niveaux sonores (transposition sur échelle décibels)
Le test est réalisé sur le Staviro, puis le KOSMOS 1 et enfin le KOSMOS 2
Pour chaque expérience un niveau sonore moyen et maximal sera relevé.
Un enregistrement sonore ainsi qu’une courbe de niveau est disponible pour chaque enregistrement.
Important :
Lorsqu’il effectue ses rotations, le K2 présente des angles pour lesquels la rotation s’effectue “normalement” (C'est-à-dire que seul un choc entre les dents serait principalement responsable du bruit) ainsi que d’autre angles pour lequel une sur-contrainte et des accouts apparaissent, générant donc un bruit plus important.
Nous distinguerons donc le cas dit “normal” et le cas “contraint” lors de l’expérience.
Cette génération plus importante de bruit pour certains angles du kosmos 2 met déjà en relief des erreurs de fabrication et ou de dimensionnement.
Comment comparer des niveaux sonores ?? :
Ajouter 3 dB correspond à multiplier l’énergie acoustique (l’intensité des vibrations) par deux.
Exemple : 26 dB est donc deux puissant que 23 dB et 23 dB est lui-même deux fois plus puissant que 20 dB.
🎧 Voici les enregistrements mp3 pour chaque essais :
Cette première expérience nous permet de comparer concrètement les différences de niveaux sonores entre nos systèmes et nous aide également à évaluer leurs comportements auditifs de manière à repérer d’éventuelles anomalies.
L’enregistrement du STAVIRO nous sert ici de témoin en comparaison aux différents systèmes KOSMOS. En sachant que le STAVIRO a déjà été opérationnel nous devons réussir à obtenir un bruit au moins égal ou inférieur à celui émis par le STAVIRO.
Sachant que la principale source de bruit sur le STAVIRO vient du moteur et que le KOSMOS est équipé d’un moteur silencieux, nous pouvons réussir à atteindre cet objectif en minimisant les nuisances provenant du réducteur.
KOSMOS 1 :
On observe que le K1 possède un niveau sonore moyen 4 fois supérieur à celui du STAVIRO.
Le niveau sonore est constant ce qui ne laisse pas entrevoir d’anomalies particulières.
En revanche, nous pouvons distinguer un grésillement métallique irrégulier provenant d’une rondelle qui n’est pas suffisamment maintenue (trop de jeu, et grosse différence entre le diamètre extérieur de l’arbre et le diamètre intérieur de la rondelle.)
Il est donc possible de réduire davantage le niveau sonore du K1 en ajustant ces rondelles.
KOSMOS 2:
On observe que le K2 possède un niveau sonore moyen entre 64 et 1024 fois supérieur à celui du STAVIRO, et 16 à 128 fois supérieur à celui du K1.
La nuisance sonore est ici concrètement quantifiable.
Le niveau sonore est constant dans le cas “normal” mais n’est pas constant dans le cas “contraint” ce qui laisse entrevoir des anomalies de reproduction.
Nous distinguons bien la vitesse plus élevée du moteur, il faudra donc essayer de la réduire au maximum.
Pistes de recherche :
→ Etude approfondie du réducteur K2 pour observer toutes les anomalies de conception et de fabrication.
→ Réduire la vitesse du moteur K2.
→ Changer les rondelles métalliques en un autre matériau moins bruyant.
Etude mécanique approfondie du réducteur KOSMOS 2
Le réducteur K2 a été démonté et méticuleusement observé de manière à relever toutes les anomalies de reproduction ou les causes de potentielles sources de bruit.
Dans un premier temps, nous énumérerons toutes les observations faites et leur impact sur le système, puis nous déterminerons dans un second temps des pistes d’amélioration.
Pour faciliter l'explication des problèmes mécaniques et la désignation des composants voici une vue de coupe du réducteur avec le nom de chaque pièces :
Lorsque l’on fait tourner manuellement les engrenages il est possible d’entendre une sorte de “ronronnement” au niveau des dentures. Ce bruit est causé par un choc régulier entre les dents des engrenages qu’il est possible de minimiser, voir supprimer si le profil de denture est parfaitement calculé et usiné. Cela dépendra des moyens dont dispose le fab lab sur la précision d’usinage.
Lorsque le réducteur tourne à haute vitesse (en particulier sur le K2), ce ronronnement devient bien plus fort et génère un bruit de fond important qui a été mesuré à au moins 32 fois supérieur au STAVIRO.
Ainsi la révision du profil de dentures et de l’usinage sur la minimisation des micro-chocs pourrait grandement réduire les nuisances sonores du réducteur KOSMOS.
Rondelles mobiles de mauvaises dimensions (différent des rondelles bloquant l’entretoise métalique)
Un jeu important entre le diamètre intérieur des rondelles mobiles et le diamètre extérieur de l’entretoise métallique vient causer des chocs. (rondelles RM.1, RM.2, RM.3, et RM.4).
Ces chocs entre pièces métalliques sont l’une des principales causes des nuisances sonores observées.
Un ajustage de ce jeu ou un changement de matériau doit être effectué.
De nouvelles rondelles inox aux bonnes dimensions peuvent être utilisées.
Un matériau “glissant” est préférable de manière à limiter les frottements.
Des rondelles imprimées en 3D sont envisageables de manière à pouvoir ajuster à notre guise le jeu intérieur ainsi que l’épaisseur. Elles peuvent être revêtues grâce à un traitement aux vapeurs d’acétone de manière à limiter les frottements.
Traces de chocs
Présence de traces, d’éraflures et de copeaux sur les dents des engrenages. Cela est probablement dû à des collisions, notamment entre l 'engrenage P2.1 de l’arbre primaire et la rondelle RM.3 de l’arbre secondaire. Cela peut également provenir de la fabrication des pièces.
Défaut de parallélisme des engrenages
Les engrenages ne sont pas parallèles les uns par rapport aux autres lorsqu’ils sont en rotation. Cela génère un oscillement des engrenages, augmente les chocs entre les dents et génère du bruit. Il y a un jeu trop important entre l'alésage de l'engrenage et le tube de rotation. Il faut réétudier le compromis serrage/jeu pour garder les engrenages bien droit sans pour autant freiner leurs rotations.
Mauvaise rotation des engrenages autour des leurs arbres
Lorsque l’on fait tourner manuellement un engrenage autour de son entretoise métallique il est possible de sentir un freinage important selon certains angles, en particulier l’entretoise métallique de l’arbre secondaire. Soit l'alésage de l’engrenage est mal usiné, soit le tube n’est pas parfaitement rond. Il semblerait que ce soit le tube, issu de récupération.
Ce freinage important entre les engrenages et l’arbre ne permet pas de leur conférer une rotation optimale. Le tube doit être changé.
Déformation de pièces imprimées en 3D
L’entretoise 3D supérieur de l’arbre primaire subit des déformations importantes lors du serrage de l’arbre (pièce R5). L'écrou s’enfonce petit à petit dans la pièce, cette dernière perd en hauteur et gagne en épaisseur au point de bloquer l'emboîtement de l’arbre primaire dans la partie haute du carter (R5 dans F2). La pièce a dû être réimprimée. Une nouvelle rondelle pourrait-être ajoutée entre l’écrou et la pièce R5 de manière à répartir les contraintes de serrage et minimiser les déformations.
Déformations importantes au niveau du bras de Malte
Le creux de tête de vis étant trop petit, la vis M5 jouant le rôle de bras d'engrènement de la croix de Malte a largement contraint puis déformé la base inférieure du bras lorsqu’elle a été vissé (la pièce P5.2 est voilée vers le haut). Les frottements entre la croix et le bras sont donc très importants, pouvant freiner le mécanisme. Ce défaut est probablement responsable des pics sonores due à la sur-contrainte (la pièce P4 rentre dans la pièce P5.2).
Il faut également vérifier le rayon d'engrènement entre le bras et la croix de malte de manière à ce que ces derniers glissent sans frotter et sans collisions.
Jeu important au niveau de l’arbre primaire
Jeu mesuré à ~0.60/0.70mm sur l’arbre ce qui est beaucoup. Il est dimensionné à 0.40mm sur le plan. Ce jeu doit être réduit de manière à limiter la translation des engrenages sur l’axe. La translation des engrenages de haut en bas favorise les chocs entre les engrenages, défavorise la transmission mécanique et peut être en partie responsable du bruit.
Un très léger jeu doit cependant être préservé de manière à permettre la rotation des engrenages.
Jeu important au niveau de l’arbre secondaire
L’arbre secondaire possède un défaut entre le plan de conception et la fabrication.
Sur le plan, l’entretoise métallique est épaulée sur le carter alors qu'à la fabrication cette dernière a été épaulée sur des rondelles.
La bonne solution technique est d’épauler l’entretoise sur des rondelles comme cela a été fait lors de la fabrication, seulement cela a engendré un important décalage de jeu sur l’arbre.
Ce jeu excessif apparaît donc au niveau de l’entretoise de l’arbre secondaire (pièce R6) et a été relevé lors de la fabrication. Une seconde pièce plus longue a été imprimée pour compenser ce jeu.
Lorsque la pièce R6 est d’origine (même dimensions que sur le plan et le K1), le jeu est donc maximal (>1.20mm au lieu de 0.8mm sur le plan). Une collision entre la rondelle de l’arbre secondaire et un engrenage de l’arbre primaire apparaît, causant un fort bruit de claquement métallique ainsi que des éraflures au niveau de la roue crantée.
Lorsque la pièce R6 a été agrandie (9mm) le jeu disparaît et le choc entre la rondelle et la roue est supprimé. Seulement la pièce a été trop agrandie et l’entretoise métallique ne se retrouve plus appuyé entre les deux rondelles de serrage. Le bras de malte se retrouve donc plaqué contre la rondelle de serrage pouvant causer des sur-contraintes et gêner la rotation de la croix de malte.
La rondelle venant s’entrechoquer contre la roue de l’arbre primaire n’est pas indispensable et devrait être retirée. Son enlèvement doit alors être compensé par un allongement de l’entretoise R6.
Il y a un léger décalage de mesures entre l’entretoise métallique du plan et celle montée sur le réducteur (longueur originale de 49.2 contre 49.30)
Pistes d’améliorations :
Étude métrologique
Révisons et comparaisons du dimensionnement entre le plan et le réducteur réel.
Réalisation d’un plan côté mis à jour. Prise de mesure de toutes les pièces fabriquées et comparaison avec les modèles 3D. Détermination précise des problèmes de jeu sur les arbres et détermination du jeu nécessaire.
Modification des rondelles mobiles
Étude d’un meilleur matériau pour remplacer le bruit généré par les rondelles métalliques mobiles.
Tester les joints o-ring, et les rondelles imprimées en 3D de manière à maîtriser leur taille et une reproductibilité identique.
Réétude des engrenages
Vérifier le profil des engrenages, et le protocole de fabrication.
Il faut enlever les trous dans les engrenages de manière à rendre la découpe plus économique et surtout à minimiser les erreurs de découpe.
Revoir la méthode de fraisage et la ligne de coupe par rapport au diamètre de la fraise et la ligne d’engrènement. Pourquoi pas réaliser un banc d’essai de manière à tester différents modes de fraisages
Remplacement des pièces défectueuses
Réusiner la pièce P5.2 qui est voilée
Changement des entretoises métalliques
Réduction de la vitesse du moteur
Trouver un moyen de réduire au maximum la vitesse de rotation du moteur de façon à limiter le bruit généré par les chocs dents contre dents (analogie avec une marche arrière de voiture, plus l'on vas vite, plus le bruit est important).
Description du problème
- Faciliter la mise à l'eau
- Protéger la caméra en mode participatif
Description de la solution
- Bibliographie à Réaliser avec Dominique sur les gréements rigides
- Cahier des charges à proposer au KAL
- Dessin avec des métrés et des soudures
Au lancement du script les GPIO ne se connectent pas
Au lancement du script les GPIO ne se connectent pas
Date
19.10.2022
Qui a rencontré le problème
Guillaume
Description du problème
Au lancement du script .lancement.sh
J'obtiens une erreur de connexion au GPIO :
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Can't connect to pigpio at localhost(8888)
Did you start the pigpio daemon? E.g. sudo pigpiod
Did you specify the correct Pi host/port in the environment
variables PIGPIO_ADDR/PIGPIO_PORT?
E.g. export PIGPIO_ADDR=soft, export PIGPIO_PORT=8888
Did you specify the correct Pi host/port in the
pigpio.pi() function? E.g. pigpio.pi('soft', 8888)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Description de la solution
Il fallait installer pigpiod en utilisant la commande :
