Aller au contenu


Bacab

Inscrit(e) (le) 20 mai 2018
Déconnecté Dernière activité sept. 25 2022 09:57
-----

Sujets que j'ai initiés

Moteur pas à pas pour simulateur de cockpit d'avion

12 septembre 2021 - 10:44

Bonjour,

 

Je suis passionné d'aviation et je passe beaucoup de temps sur des simulateurs de vol. L'année dernière j'ai entamé la réalisation d'un cockpit de poche et en 2021 je finis tous les projets que j'ai commencé (le sous-marin arrive en dernier, et ce projet-ci est l'avant dernier).

 

N'étant pas le premier, j'ai suivi les conseils avisés de mes prédécesseurs et j'ai utilisé des moteurs pas à pas x27.168 pour réaliser les instruments. Voici le résultat, branché et fonctionnel avec le simulateur que j'utilise le plus:

Fichier joint  mini_cockpit.jpg   77,6 Ko   70 téléchargement(s)

 

Ce n'est pas très parlant pour le moment car il manque les cadrans des instruments avec les graduations : il faudra donc me croire sur parole lorsque je vous dit que mon avion vole à 500 kts indiqués (haut gauche), 15000 pieds (bas gauche) et vers le sud (haut droite). Le quatrième instrument est un variomètre qui n'est pas (encore) fonctionnel.

 

Je n'ai pas beaucoup apprécié de travailler avec les moteurs x27.168 : je les ai trouvés fragiles et très susceptibles aux perturbations extérieurs (un simple boulon en M2 en acier à proximité du boitier et le moteur ne tourne plus). En plus les connexions ne sont pas évidentes (les moteurs sont prévus pour être monté sur PCB) et leur schéma d'alimentation n'a pas l'air standard (en gros ça marche avec la librairie stepper d'arduino mais pas avec librairie accelstepper, c'est chiant). Coté positif ils permettent effectivement d'aller à 60 RPM ce qui est bien pour mes instruments. La question est la suivante : connaitriez vous des moteurs pas à pas au couple réduit (le moteur n'entraine qu'une aiguille, pas besoin de couple pour cela), avec une vitesse aussi élevé, alimentable en 5V pour moins de 100 mA mais qui serait plus facile à piloter, connecter et installer ?

Aux environs de 15€ pièce.

 

J'ai essayé les 28BYJ-48  mais la vitesse de rotation culmine à 11 RPM pilotés avec mon Arduino.

 

Je vous remercie par avance pour vos idées.


Problème d'impression avec une Prusa i3 Mk2S

24 avril 2021 - 12:26

Bonjour,

 

J'ai acheté il y a 3 ans une imprimante 3D de marque Prusa, une i3 Mk2S. Jusqu'à présent je n'avais jamais eu de problème sérieux avec (rien que quelques petits ajustements ne pouvaient régler) mais ce matin c'est la Bérézina : j'ai foiré toutes mes impressions sauf une qui est en cours et qui se passe bien (elle a passé la première couche donc ça devrait bien se passer pour la suite).

 

En cause : la première couche qui semble avoir du mal à adhérer au lit d'impression. En particulier c'est le filament qui sert à délimiter les contours de la forme à imprimer qui n'adhère pas ou très mal au plateau, le remplissage qui a lieu après semble mieux se passer. J'ai aussi les extrémités des pièces que j'essaye d'imprimer qui se décollent pendant l'impression : généralement c'est ce qui fait que l'impression foire complètement car inévitablement la buse finit par arracher la partie qui rebique.

 

Voici ce que j'ai fait pour essayer de résoudre le problème:

- nettoyer le plateau. Maintenant il est propre mais ça ne fonctionne pas mieux.

- diminuer de 20% la vitesse d'impression ==> en effet l'imprimante semble aller beaucoup plus vite lorsqu'elle trace les contours que lorsqu'elle passe au remplissage. Je pense jouer encore plus avec ce paramètre pour voir si cela aide mais 20% n'ont pas suffit.

- J'ai refait ma calibration en Z (sait-on jamais ?) et j'ai remarqué que le réglage précis du Z avait besoin d'être modifié (je suis passé de -0.57 à -0.6)*. Malheureusement cela ne règle pas mes problèmes.

 

La pièce que j'essaye d'imprimer a été imprimée avec succès il y a deux jours (gcode identique), je n'avais alors eu aucun problème. Entre temps j'ai changé ma bobine de filament (même filament qu'avant, j'ai juste remplacé la bobine vide par une pleine : j'utilise du Colorfab PLA eco silver).

 

Si vous avez des idées pour m'aider je vous en remercie par avance.

* : est-ce qu'il est possible que cette différence puisse venir de l'usure de la buse. Auquel cas est-ce que mon problème pourrait venir de la ?

 

 


Se débarasser d'un "HUM" sur un projet audio

24 avril 2020 - 06:49

Bonjour,

 

Je prépare pour faire une surprise à un ami une boîte à musique sur la base d'une Arduino Uno, d'un Shield Wave d'Adafruit (https://www.adafruit.com/product/94), d'un amplificateur (https://www.velleman...ts/view?id=9181) et d'un haut-parleur. Le tout est alimenté par une pile 9V.

 

Le principe est que lorsque mon ami appuiera sur un bouton, la boite jouera un morceau de musique ou un son qui a une signification particulière pour lui.

 

J'ai reçu, assemblé et testé le montage aujourd'hui et ça marche parfaitement à l'exception d'un "hum" audible même lorsque le shield n'envoie plus de musique à l'amplificateur. J'ai analysé le spectre du "hum" en question et voila ces caractéristiques :

Fichier joint  spectro.png   13,09 Ko   122 téléchargement(s)

On a donc des raies à :

- 172.5 Hz (3x57.5 Hz)

- 345 Hz (6x57.5 Hz)

- 517.5 Hz (9x57.5 Hz)

- 690 Hz (12x57.5 Hz)

je pense que vous voyez la logique.

 

Je suppose que le 57.5 Hz provient du réseau électrique : ais-je raison ou tord ?

Si oui comment puis-je protéger mon circuit (mes premiers essais avec de l'alu semblent améliorer la situation mais c'est pas Byzance) ?

 

Je vous remercie par avance pour vos réponses, conseils...


Problème avec un multiplexeur analogique et l'ADC de l'Arduino

25 janvier 2020 - 12:54

Bonjour,

 

Il y a quelques temps j'ai finis de fabriquer une "boîte à boutons" que je souhaiterais utiliser avec mes simulateurs d'avions sur mon ordinateur. La boîte comporte 16 boutons et 6 axes. Grâce au projet Unojoy j'ai pu reprogrammer mon Arduino pour la faire reconnaître comme un joystick par mon ordinateur et cela fonctionne très bien.

 

Fichier joint  DSC_0032.JPG   95,42 Ko   151 téléchargement(s)

 

Pour avoir 16 entrées numériques et 6 entrées analogiques j'ai utilisé un shield DFRobot qui utilise un multiplexeur géré par I2C. Par conséquent 2 entrées analogiques (A4 et A5 si je ne dis pas de bêtise) ne sont pas accessible et j'ai ajouté un multiplexeur analogique CD4051B pour quand même avoir mes six axes. L'entrée A1 de l'Arduino est donc toujours celle qui est lue. Comme les potentiomètres sont des 100k linéaires (erreur de ma part à la commande) j'ai mis 2 lectures consécutives de l'ADC et je ne garde que la seconde pour laisser le temps au condensateur de l'ADC de se charger (à ma connaissance il n'est pas possible de ralentir l'ADC de l'Arduino au delà de la valeur par défaut puisque le prescaler a 128 pour valeurs max.).

 

Je rencontre néanmoins un problème lorsque certains axes sont dans certaines positions. J'ai remarqué que si je mets un des axes à sa position maximum (1023 sur l'ADC) un autre axe se met à contrôler tous les axes en même temps. Autre bizarrerie : si je mets tous les axes à ~50% les lectures deviennent complètement erratiques (variation des valeurs lues très rapide entre 0 et 1023).

 

J'ai, en premier lieu, suspecté un court-circuit mais je ne le trouve pas. Est-ce qu'il y a une autre piste à explorer ?

 

Je vous remercie par avance pour votre aide.

 

Le code :

#include <clsPCA9555.h>
#include "UnoJoy.h"

int time_delay = 10;
int i = 0;
int prev_value[6] = {128,128,128,128,128,128};
PCA9555 ioport(0x20);

void setup()
{
  setupPins();
  setupUnoJoy();
}

void loop()
{
  delay(time_delay);
  // Always be getting fresh data
  dataForController_t controllerData = getControllerData(i, prev_value);
  prev_value[0] = controllerData.x_axis;
  prev_value[1] = controllerData.y_axis;
  prev_value[2] = controllerData.z_axis;
  prev_value[3] = controllerData.r_x_axis;
  prev_value[4] = controllerData.r_y_axis;
  prev_value[5] = controllerData.r_z_axis;
  setControllerData(controllerData);
  
  i++;
  if(i==6)
  {
    i=0;
  }
}

void setupPins(void)
{
  ioport.begin();
  ioport.pinMode(ED0, INPUT);
  ioport.pinMode(ED1, INPUT);
  ioport.pinMode(ED2, INPUT);
  ioport.pinMode(ED3, INPUT);
  ioport.pinMode(ED4, INPUT);
  ioport.pinMode(ED5, INPUT);
  ioport.pinMode(ED6, INPUT);
  ioport.pinMode(ED7, INPUT);
  ioport.pinMode(ED8, INPUT);
  ioport.pinMode(ED9, INPUT);
  ioport.pinMode(ED10, INPUT);
  ioport.pinMode(ED11, INPUT);
  ioport.pinMode(ED12, INPUT);
  ioport.pinMode(ED13, INPUT);
  ioport.pinMode(ED14, INPUT);
  ioport.pinMode(ED15, INPUT);
  pinMode(A0, OUTPUT);
  pinMode(A1, INPUT);
  pinMode(A2, OUTPUT);
  pinMode(A3, OUTPUT);
}

dataForController_t getControllerData(int axis_to_read, int* data_to_save)
{
  dataForController_t controllerData = getBlankDataForController();
  controllerData.x_axis   = data_to_save[0];
  controllerData.y_axis   = data_to_save[1];
  controllerData.z_axis   = data_to_save[2];
  controllerData.r_x_axis = data_to_save[3];
  controllerData.r_y_axis = data_to_save[4];
  controllerData.r_z_axis = data_to_save[5];
  switch(axis_to_read)
  {
    case(0):
      // cas 0 = 000
      digitalWrite(A0, LOW);
      digitalWrite(A2, LOW);
      digitalWrite(A3, LOW);
      analogRead(A1);
      controllerData.x_axis = analogRead(A1)>>2;
      break;
    case(1):  
      // cas 1 = 001
      digitalWrite(A0, HIGH);
      digitalWrite(A2, LOW);
      digitalWrite(A3, LOW);
      analogRead(A1);
      controllerData.y_axis = analogRead(A1)>>2;
      break;
    case(2):
      // cas 2 = 010
      digitalWrite(A0, LOW);
      digitalWrite(A2, HIGH);
      digitalWrite(A3, LOW);
      analogRead(A1);
      controllerData.z_axis = analogRead(A1)>>2;
      break;
    case(3):
    // cas 4 = 100
      digitalWrite(A0, LOW);
      digitalWrite(A2, LOW);
      digitalWrite(A3, HIGH);
      analogRead(A1);
      controllerData.r_x_axis = analogRead(A1)>>2;
      break;
    case(4):
      // cas 5 = 101
      digitalWrite(A0, HIGH);
      digitalWrite(A2, LOW);
      digitalWrite(A3, HIGH);
      analogRead(A1);
      controllerData.r_y_axis = analogRead(A1)>>2;
      break;
    case(5):
      // cas 7 = 111
      digitalWrite(A0, HIGH);
      digitalWrite(A2, HIGH);
      digitalWrite(A3, HIGH);
      analogRead(A1);
      controllerData.r_z_axis = analogRead(A1)>>2;
      break;
  }
  
  controllerData.btn_01 = !ioport.digitalRead(ED0);
  controllerData.btn_02 = !ioport.digitalRead(ED1);
  controllerData.btn_03 = !ioport.digitalRead(ED2);
  controllerData.btn_04 = !ioport.digitalRead(ED3);
  controllerData.btn_05 = !ioport.digitalRead(ED4);
  controllerData.btn_06 = !ioport.digitalRead(ED5);
  controllerData.btn_07 = !ioport.digitalRead(ED6);
  controllerData.btn_08 = !ioport.digitalRead(ED7);
  controllerData.btn_09 = !ioport.digitalRead(ED8);
  controllerData.btn_10 = !ioport.digitalRead(ED9);
  controllerData.btn_11 = !ioport.digitalRead(ED10);
  controllerData.btn_12 = !ioport.digitalRead(ED11);
  controllerData.btn_13 = !ioport.digitalRead(ED12);
  controllerData.btn_14 = !ioport.digitalRead(ED13);
  controllerData.btn_15 = !ioport.digitalRead(ED14);
  controllerData.btn_16 = !ioport.digitalRead(ED15);
  
  return controllerData;
}

Le schéma du montage (je n'ai mis que la partie analogique) :

Fichier joint  schema_electrique.JPG   87,65 Ko   117 téléchargement(s)

 

Contrairement à ce qui est affiché sur le schéma c'est bien un CD4051 que j'utilise (pas trouvé de schéma pour Spice donc j'ai mis un circuit équivalent). Le voltmètre avec la résistance d'un Meg en parallèle représente l'ADC de l'Arduino Uno.


Comment utiliser une pince à sertir

25 août 2019 - 04:00

Tout est dans le titre j'en ai peur : j'ai acheté une pince à sertir pour réaliser mes propres câbles et je n'arrive pas à m'en servir. Mes connecteurs sont de ce type :

Fichier joint  DSC_0105.JPG   46,24 Ko   166 téléchargement(s)

Et j'essaye de les attacher à un fil avec ça :

Fichier joint  DSC_0107.JPG   39,46 Ko   162 téléchargement(s)

Comment suis-je censé faire ? J'ai essayé de juste positionner le fil dans le connecteur et de serrer mais la pince ne replie pas les espèces d'ailes qui se trouvent au bout du connecteur (qui tombe donc).