Oui merci  pour cette info ^^ Là avec le pilotage du pas à pas, j'ai bien envie de mettre 2 arduino. Pas obligé, ça passerait au niveau du câblage. Je gagne une broche en retirant le servo et je doit en ajouter 2 pour le stepper + une pour la fin de course soit + 2 broches utilisées. Ce serait pour être tranquille avec mes interruptions et pouvoir compter mes roues codeurs en même temps que je fais fais mes relevés de distance. En tout cas pour gagner de la vitesse.

Ce WE, j'ai mis ensemble (en mode développement) les 4 capteur TOF VL53L0X, le arduino nano, le driver et un stepper.

Pour piloter le driver du stepper : 2 pin, le pas et la direction. La lib qu'Ashira a mis dans son test est top !!

Pour les capteurs, c'est plus compliqué. J'ai posté des infos par le passé là : http://www.robot-maker.com/forum/topic/10721-capteur-de-distance-laser-vl53l0x/?p=76048

J'ai configuré le driver à 1/16 pas. Comme dit plus haut, c'est vraiment trop long. Je fais une une mesure tous les 10 pas.

Ça me donne au bout des 2 mètres de la mesure une erreur de ~4cm. Je m'en contenterai.

Donc, avec le stepper, j'ai une vision à 360° avec 320 échantillons (tous les 1,1°) et une envergure de 4m autour. 

Qui dit stepper, dit butée. Problème rencontré, quand la tourelle quitte la butée, elle oscille ... C'est à cause du couplage mécanique entre la tourelle et l'arbre du moteur. Pour ne pas avoir ce pb à chaque aller-retour, j'éloigne le point de départ de la butée. Ça donne les 3 états du programme plus bas : 1) recherche de la butée et avance de 500. 2) forward 90°, 3) backward de 90°, puis 2) puis 3) ...

Sur la sortie USB, j'obtiens des séries de 5 chiffres. Le 1er est la position du stepper. Les 4 suivant est la distance mesurée.

(...)
30, 78, 34, 22, 17
20, 78, 39, 21, 17
10, 79, 34, 21, 14
0, 78, 34, 20, 16
10, 80, 37, 21, 16
20, 76, 32, 21, 18
30, 82, 36, 20, 16
(...)

La forme triangulaire est la première colonne.

Code arduino qui m'a servi pour le test :

#include <AccelStepper.h>
// https://www.pjrc.com/teensy/td_libs_AccelStepper.html
// Merci Ashira

#include <Wire.h>
#include <VL53L0X.h>

VL53L0X sensorA;
VL53L0X sensorB;
VL53L0X sensorC;
VL53L0X sensorD;

#define PIN_XSHUT_A 7
#define PIN_XSHUT_B 8
#define PIN_XSHUT_C 9
#define PIN_XSHUT_D 10

#define ADR_SENSOR_A 51
#define ADR_SENSOR_B 52
#define ADR_SENSOR_C 53
#define ADR_SENSOR_D 54
// https://github.com/pololu/vl53l0x-arduino/blob/master/examples/Single/Single.ino

#define PIN_STEPPER_STEP 6
#define PIN_STEPPER_DIR 2
AccelStepper stepper(1, PIN_STEPPER_STEP, PIN_STEPPER_DIR);
long steps;
#define STEP_SIZE 10

#define PIN_COURSE_END 3

int state;
#define STATE_FORWARD 1
#define STATE_BACKWARD 2
#define STATE_FIND_STOP 3

void scanI2CAdresses() {
  Serial.println ("I2C scanner. Scanning ...");
  byte count = 0;

  for (byte i = 1; i < 120; i++)
  {

    Wire.beginTransmission (i);
    if (Wire.endTransmission () == 0)
    {
      Serial.print ("Found address: ");
      Serial.print (i, DEC);
      Serial.print (" (0x");
      Serial.print (i, HEX);
      Serial.println (")");
      count++;
      delay (1);  // maybe unneeded?
    } // end of good response
  } // end of for loop
  Serial.print ("Done. Found ");
  Serial.print (count, DEC);
  Serial.println (" device(s).");
}

/* Set XSHUT to LOW */
void prepareSensor(byte pinXshut) {
  pinMode(pinXshut, OUTPUT);
  digitalWrite(pinXshut, LOW);
}


// Uncomment this line to use long range mode. This
// increases the sensitivity of the sensor and extends its
// potential range, but increases the likelihood of getting
// an inaccurate reading because of reflections from objects
// other than the intended target. It works best in dark
// conditions.

//#define LONG_RANGE


// Uncomment ONE of these two lines to get
// - higher speed at the cost of lower accuracy OR
// - higher accuracy at the cost of lower speed

//#define HIGH_SPEED
//#define HIGH_ACCURACY

/* Set sensor adress and parameters */
void initSensor(byte pinXshut, VL53L0X *sensor, uint8_t adr) {
  pinMode(pinXshut, INPUT);
  delay(200);
  sensor->init(true);
  delay(100);
  sensor->setAddress(adr);
  sensor->setTimeout((uint16_t)500);
  
#if defined LONG_RANGE
  // lower the return signal rate limit (default is 0.25 MCPS)
  sensor->setSignalRateLimit(0.1);
  // increase laser pulse periods (defaults are 14 and 10 PCLKs)
  sensor->setVcselPulsePeriod(VL53L0X::VcselPeriodPreRange, 18);
  sensor->setVcselPulsePeriod(VL53L0X::VcselPeriodFinalRange, 14);
#endif

#if defined HIGH_SPEED
  // reduce timing budget to 20 ms (default is about 33 ms)
  sensor->setMeasurementTimingBudget(20000);
#elif defined HIGH_ACCURACY
  // increase timing budget to 200 ms
  sensor->setMeasurementTimingBudget(200000);
#endif
}

uint16_t readSensor(VL53L0X *sensor) {
  uint16_t distance = sensor->readRangeSingleMillimeters();
  if (sensor->timeoutOccurred() || distance > 8000) {
    return 0;
  }
  return distance;
}

void readRanges(unsigned long currentPosition) {
  Serial.print(currentPosition, DEC);
  Serial.print(", ");
  Serial.print(readSensor(&sensorA), DEC);
  Serial.print(", ");
  Serial.print(readSensor(&sensorB), DEC);
  Serial.print(", ");
  Serial.print(readSensor(&sensorC), DEC);
  Serial.print(", ");
  Serial.print(readSensor(&sensorD), DEC);
  Serial.println();
}

/*
   SETUP
*/
void setup() {
  prepareSensor(PIN_XSHUT_A);
  prepareSensor(PIN_XSHUT_B);
  prepareSensor(PIN_XSHUT_C);
  prepareSensor(PIN_XSHUT_D);
  delay(500);
  Wire.begin();
  Serial.begin (115200);
  initSensor(PIN_XSHUT_A, &sensorA, (uint8_t)ADR_SENSOR_A);
  initSensor(PIN_XSHUT_B, &sensorB, (uint8_t)ADR_SENSOR_B);
  initSensor(PIN_XSHUT_C, &sensorC, (uint8_t)ADR_SENSOR_C);
  initSensor(PIN_XSHUT_D, &sensorD, (uint8_t)ADR_SENSOR_D);

  //scanI2CAdresses();

  pinMode(PIN_COURSE_END, INPUT_PULLUP);

  stepper.setMaxSpeed(5000);
  stepper.setAcceleration(5000);
  state = STATE_FIND_STOP;
}

/*
   LOOP
*/
void loop() {

  switch (state) {

    case STATE_FIND_STOP : // recule jusqu'à la butée.

      if (digitalRead(PIN_COURSE_END) == HIGH) { // En butée
        // On avance un peu pour dégager la butée
        //\\***** TODO ***** //\\ déterminer l'angle de démarrage
        stepper.move(500);
        stepper.runToPosition();
        steps = 0;
        state = STATE_FORWARD;
        break;
      }
      stepper.move(-10);
      stepper.runToPosition();
      break;

    case STATE_FORWARD : // On avance de 90° (ou 800 pas)

      if (steps < 800) {
        readRanges(steps);
        stepper.move(STEP_SIZE);
        stepper.runToPosition();
        steps += STEP_SIZE;
        break;
      }
      state = STATE_BACKWARD;
      steps = 800;
      break;

    case STATE_BACKWARD : // On recule de 90° (ou 800 pas)

      if (steps > 0) {
        readRanges(steps);
        stepper.move(-1 * STEP_SIZE);
        stepper.runToPosition();
        steps -= STEP_SIZE;
        break;
      }
      state = STATE_FORWARD;
      steps = 0;
      break;
  }
}
 

 @Oracid 

Problème rencontré, quand la tourelle quitte la butée, elle oscille ... C'est à cause du couplage mécanique entre la tourelle et l'arbre du moteur.

Mon coupleur d'axe est celui qu'on a sur les axes Z de la disco de dagoma .

Genre ça :

Quand je quitte la butée qui (elle aussi) a du ressort, cela fait osciller ma tourelle. On le voit bien sur la video.

On le voit bien sur la video.

Salut,

A mon avis le problème ici est purement mécanique, si ton profilé n'est "tenu" que par le moteur, forcément il y aura beaucoup de jeu.

Il faudrait que la tourelle soit fixée par au moins deux paliers, comme pour un axe. Le plus d'espace entre ces deux paliers le moins ca bougera.

Comme l'a dit Cocothebo, le problème avec ton coupleur, c'est qu'il n'est fait que pour palier au défaut de parallélisme

entre l'axe de ton moteur et l'axe principal.

Et le roulement du moteur n'est pas fait pour supporter une charge longitudinale.

Ok, là c'est de la petite mécanique légère donc... c'est pas trop grave

mais normalement tu devrais avoir un système de palier pour tenir l'axe, ET un accouplement pour relier ton moteur dessus.

De sorte que tu puisses démonter ton moteur et faire tourner ta tourelle à la main.

 

Et le roulement du moteur n'est pas fait pour supporter une charge longitudinale.

Quand ce moteur était sur l'imprimante, il devait supporter le poids de l'axe vertical : une tige filetée et le poids de la moitié de la tête d'impression. Je veux bien entendre que sa conception soit légère (discovery 200). Là, je me dis que ça va aller, comme tu dis, c'est léger.

Alors je vais faire 2 choses pour améliorer la tourelle.

1. C'est sûr, je viens de tester. Je vais remplacer l'interrupteur de butée par le palpeur sans contact (toujours récupéré de l'imprimante). Ça fonctionne très bien sur la petite barre de métal qui venait toucher l'interrupteur. Plus de contact, plus d'oscillation au contact de la butée. On lit le capteur avec un simple analogRead

2. Je vais essayer de fixer la tourelle sur un 2e point. Comme dit Cocothebo, je vais essayer de cette manière là. Le jeu entre la vis et le trou dans le profilé est de 0,35mm. Je mettrai du papier autour de la vis pour limiter le bruit et diminuer le jeu.

Le palpeur est un NPN Inductive Proximity Sensor. Si quelqu'un peu m'expliquer la techno qui est en jeu. Ça m'ennuie de mettre ça sans savoir comment il fait pour détecter le métal ^^

J'ai trouvé ça chez mon ami google : https://automation-insights.blog/2014/03/05/basic-operating-principle-of-an-inductive-proximity-sensor/ 

J'avoue que je pourrai pas l'expliquer à quelqu'un d'autre

Pour la différence entre NPN et PNP : https://www.schneide.../faqs/FA142566/

oui, un capteur inductif c'est juste une bobine (parfois avec un aimant permanent)

dans laquelle on envoie un signal électrique oscillant

lorsqu'un objet métallique (ou organique) s'approche ou s'éloigne, ça créé un courant de Foucault.

(l'intensité du courant qui alimente la bobine change)

et suivant le seuil fixé, l'info de présence est renvoyée.

le composant qui permet de déterminer la sensibilité de détection est un transistor (on alimente sa Base en intensité)

Du coup tu peux avoir des capteurs PNP ou NPN. suivant si ton entrée est à l'état normalement haut ou bas.

petit schéma (ton entrée c'est le petit rond entre le transistor et load) :

Enfin quelques news à donner sur Hector : Fixation de la tourelle sur 2 points. Capteur de fin de course par induction, plus de contact, plus d'oscillation de la tourelle !

Schématiquement, il ressemble à ça :

Il y a 4 capteurs placés à 90°. La tourelle fait des aller-retours sur 90°. J'ai mis une couleur par capteur. C'est un nuage de points, pas d'interpolation, c'est brut. Je transforme juste les coordonnées polaires en cartésiennes.

Sur les parcours en bleu et noir, on voit la régularité des mesures, en angle et en distance. Le nuage rouge et vert en bas, c'est moi qui bouge pendant la mesure. Les tracés manquant montrent une distance trop grande pour le capteur.

Face à des murs à angle droit, les angles semblent arrondis. Un bel exemple d'arrondi sur le tracé noir en haut à droite. Idem pour l'arrondi bleu en haut à gauche.

Est-ce mon éclairage ? Est-ce un reflet ?

Je fait un test avec un couvercle devant les capteurs.

Ça donne ceci. Des genre de 'M' sur les angles de la boite.

Conclusion, c'est les profilés qui ajoute des interférences. Je refais le test avec les profilés à l'extérieur de la boite.

C'est mieux mais pas encore super.

On voit une différence de mesure entre le capteur en rouge et le capteur en vert ...

Je vois 2 types de déformations.

Celle en haut sur les capteurs noir et bleu. La mesure est pas linéaire.
Celle du vert plus bas et du nuage rouge, c'est certainement que la boite ne va pas assez bas.

Les points verts ne rejoignent pas bien les points bleus.

En tout cas, le vert et le rouge partent vers le bas avec le même angle. Ce qui semble confirmer le 1er pb. Je vais peut-être m'en sortir avec un coefficient pour remettre les murs droits. Et un autre pour le capteur vert qui semble avoir des distances plus longues.

Je vais aussi revérifier ma transformation polaire / cartésienne.

Reste à améliorer les échantillons de distance et finir la partie déplacement avec les roues codeuses.

Eclate totale !! Gros kif !! Je suis preneur des remarques !! Merci d'avance.

Code source : https://github.com/Path000/Hector

Modifié par Path, 29 octobre 2017 - 06:27 .
ajout du lien github

Merci C'est fort possible. Je vais refaire des tests face à un mur tout plat à une distance plus grande des capteurs.

en fait au début comme ça j'avais l'impression que certaines "erreurs " que tu vois dans les données recueillies traduisent en partie un défaut mécanique du style ' tourner pas bien rond" / capteurs pas monté à la même distance de l'axe de rotation / pas exactement des déphasage de 90° entre les capteurs " =)  

en tout cas les résultats sont prometteurs =)