Ce serait dommage d'avoir la précision d'un moteur pas à pas avec une calibration à main levé!
Pour ton bras, en faisant une étape initiale appropriée tu évites les collisions

Ce serait dommage d'avoir la précision d'un moteur pas à pas avec une calibration à main levé!
Pour ton bras, en faisant une étape initiale appropriée tu évites les collisions

Oui c'est vrai. J'ai des marquages spéciaux (d'origine) sur le bras pour tout aligner.

Je fais ce petit compte-rendu du live de ce soir sur discord, qui était illustré par mon expérience de Hector. 

 

Je place Hector devant une surface plane et un profilé debout entre la surface et la tourelle.

 

 

J'obtiens ces mesures. Elles sont brut. Chaque point est une mesure.

 

 

On retrouve la surface plane entre le noir et le bleu. La pointe du V représente le profilé. Les jambes du V sont constituées de points fictifs dus au capteur. Celui-ci ne mesure pas un point précis comme le ferait un laser simple. La mesure est formée d'un cône qui explique les points intermédiaires entre le profilé et la surface placée derrière.

 

Je suis bien embêté avec ces points fictifs pour faire la cartographie ... Cela risque d'être bien complexe à éliminer.

 

Comme c'est un cône, je vais faire moins de mesures, cela ira plus rapidement à chaque passage. (Il faut voir les choses du bon coté.)

Je vais me concentrer sur la liaison de ces points et sur le tangent bug pour le faire avancer.

 

Merci Pascal !!

Comme ton robot se déplace, l'angle de vue change, les points liés au profilé resteront, et ceux du V pourront être supprimé, non ?

Suggestion bête en repensant à ce que disait ServeurPerso: tu as essayé de faire une unique mesure à un angle donné pour voir la réception du signal dans le temps ? Une mesure analogue serait d'avoir une barre linéaire de récepteur, d'envoyer un pulse avec un seul émetteur et d'observer le signal reçu en fonction de la position du récepteur.
La raison est la suivante: si ce qu'envoie l'émetteur n'est pas ponctuel devant la résolution de ton capteur mais plutôt un cercle (ou une gaussienne d'intensité), ce genre de mesure te permet de déterminer la largeur d'émission de chaque capteur, et donc d'avoir une stratégie de correction basée sur ton matériel réel.

En bougeant, les points disparaissent mais dautres tangents aparaissent J ai bien imaginé des algos pour éliminer les points fictifs. Avec des poids sur chacun cela implique de les mettre en cluster, de deviner que le point est fictif parce qu il n est pas detecter. Cela réduit le champ de vision car quid d un point bien réel qui sort du champ de vision ? Aussi avec la detection dun mouvevement des lignes ... Jai du mal à imaginer des algo viables pour mapper lenvironnement. Pour se déplacer en évitant les obstacles, ça doit convenir.

Je suis pas sur d'avoir compris ton problème.

 

  

 

 

En gros tu veux un algo pour passer de l'image de gauche à l'image de droite ?

Oui tout à fait. Et avoir des angles droits quand c est le cas. En bleu en haut à gauche et en noir en haut aussi. En fait naïvelent, je m attendais pas à ce type de résultat.

Quelque nouvelles de ma tourelle. Ashira a bien résumé le problème des points fictifs que j'avais avec les VL53L0X montés sur un axe rotatif. A cela, il faut ajouter les angles formés par les murs étaient vus arrondis. Ce phénomène est causé par la forme conique du capteur. Ce capteur est pourtant très précis quand il est utilisé de manière statique.

 

Il me fallait une autre solution qui ne génère pas ces points fictifs. Je n'envisageais pas un algo pour les éliminer et retrouver les angles de mes murs.

 

J'ai commencé à dompter le rp lidar A2 du shop. Mes premiers essais avec les outils fournis montrent que je n'aurai plus les problèmes dénoncés plus haut.

 

J'ai branché le lidar directement sur la pi3 sans passer par le convertisseur usb. J'utilise le port série gpio et un des 2 pwm hardware de la pi.

 

Pour retrouver un port série performant sur la pi3, j'ai suivi les infos lus ici : http://www.framboise314.fr/le-port-serie-du-raspberry-pi-3-pas-simple/

 

Utiliser l’UART (le vrai !) en perdant la fonction Bluetooth. Il faut permuter les E/S des deux UART. Pour cela, ajoutez à /boot/config.txt : dtoverlay = pi3-disable-bt

Puis supprimer :
console=serial0,115200  dans cmdline.txt

 

J'obtiens bien ce changement :

 

 

Pour tester l'uart, comme indiqué dans l'article, j'ai relié le TX sur le RX de la pi avec une résistance.

 

 

Contrairement à l'article, j'ai testé en JS. J'utilise le module serialport https://www.npmjs.co...kage/serialport

const SerialPort = require('serialport');

const port = new SerialPort('/dev/ttyAMA0', {
	autoOpen: false,
	baudRate: 115200
});

const send = () => {
	port.write('Je teste le port série 1 2 3 4 5', () => {
		port.drain((err) => {
			if (err) {
				console.log(err);
				return;
			}
		});
	});
	setTimeout(send, 1000);
}

port.on('open', () => {
	console.log('Opened');
	send();
});

port.on('data', (chunk) => {
	console.log(chunk);
	console.log(chunk.toString());
});

port.open((err) => {
	if (err) {
		console.log(err);
		return;
	}
});

Concernant l'utilisation du PWM pour piloter le moteur, j'ai utilisé le module pigpio https://www.npmjs.com/package/pigpio

C'est un wrapper du pilote gpio en C qui permet d'utiliser le PWM hardware.

const modulePigpio = require('pigpio');

const Gpio = modulePigpio.Gpio;

const motorPWM = new Gpio(18);
motorPWM.mode(Gpio.OUTPUT);

// duty = 1 000 000*60/100; -> 600 000
motorPWM.hardwarePwmWrite(25000, 600000);

Pour le challenge et voir jusqu'où on peut aller en NodeJS sur un raspberry PI3, j'ai décidé de refaire le driver 'from scratch' en javascript. Je vise les 4K mesures par seconde.

 

 LR001_SLAMTEC_rplidar_protocol_v1.0_en.pdf   1,46 Mo   409 téléchargement(s)

 

Dans le protocole, on ne trouve rien pour piloter le moteur. C'est "neuneu". Sans le convertisseur USB, pour gérér le moteur, il suffit d'utiliser la commande MOTOCTL en PWM à 25kHz.

 

Pour le moment, j'ai codé les commandes, les réponses et leur analyse GET_HEALTH, GET_INFO. Salut, comment tu t'appel, comment tu vas ? Pas de problèmes particuliers. J'ai la commande EXPRESS_SCAN et la confirmation de son descripteur en réponse. Je lis les paquets 4K brut, il me reste à les analyser. 

 

 

 

Génial j'ai hâte de voir les premiers tests : suivre une autre implémentation surtout full NodeJS me passionne aussi:)

J'utilise aussi le module SerialPort de Node, (quasi) obligatoire pour ce qu'on fait:)

J'avais envoyé ma logique de décodage du 2K et du 4K en C, mais ma 4K comporte un dernier bug d'angle courant/futur à corriger - bug qui fait deux "marches d'escalier" à un endroit dans la lecture qui semble fonctionner correctement hormis ça, faudra que je m'y re penche donc curieux de suivre ton avancement.

J'ai posté mon code ici, si ça te dit. https://github.com/P...ourelle-rplidar

C'est brut et en cours de dev. C'est pas fini.

Hop stared merci:D

Bon !! Le code est posé. Il doit rester des pétouilles à corriger dans les calculs.

Toute la complexité est là. Le raspberry avale les trames 4K/s sans problème et en javascript.

 

Ne me demandez pas de compiler le cpp pour comparer, c'est certain que ça prend moins de cpu ^^

 

Héhé !!

 

 

Ça c'était le bon coté. J'ai quand même eu un pb qui m'a embêté toute l'aprem. : le calcul de la somme de contrôle. Dans la doc :

ChkSum
Obtained by calculating the
response data packet using XOR
operation to each packet data byte
and accumulating them together.

Je mets tout le packet, que les cabins, que les cabins et des packets du header ... rien à faire.

 

@Serveurperso, tu le fais ce calcul ?

Euh moi ça fonctionne le checksum...

 

checksum = premier & 0xF;

checksum |= second << 4;

 

sum ^= cabines;

if(sum != checksum) {
 TXDEBUG.print(sum);
 TXDEBUG.print(" != ");
 TXDEBUG.println(checksum);
}

 

T'oublie pas un RAS de ton tmp (sum) ?

C'est forcément une connerie. Voici mon code qui fonctionne (ou il reste le fameux petit bug de old/courant/future angle)

bool readLidar() {
 uint8_t current;
 static uint8_t n = 0;
 static uint8_t checksum;
 static uint8_t sum = 0;
 static uint16_t oldStartAngleq6;
 static uint16_t startAngleq6 = 0;
 static bool start;
 static uint16_t diffAngleq6;
 static uint8_t m = 0;
 static uint8_t s = 0;
 static int8_t derivAnglesq5[RPLIDARNBSAMPLES];
 static uint16_t distances[RPLIDARNBSAMPLES];
 float distance;
 float angle;
 static uint16_t j = 0;
 float lidarx;
 float lidary;

 while(RXLIDAR.available()) {
  current = RXLIDAR.read();

  switch(n) {

   case 0:
    if(current >> 4 == 0xA) {
     checksum = current & 0xF;
     n = 1;
    }
    break;

   case 1:
    if(current >> 4 == 0x5) {
     checksum |= current << 4;
     n = 2;
    } else
     n = 0;
    break;

   case 2:
    sum ^= current;
    oldStartAngleq6 = startAngleq6;
    startAngleq6 = current;
    n++;
    break;

   case 3:
    sum ^= current;
    startAngleq6 |= (current & 0x7F) << 8;
    start = current >> 7;
    if(start)
     TXDEBUG.println("start");








    if(oldStartAngleq6 > startAngleq6)
     diffAngleq6 = (360 << 6) + startAngleq6 - oldStartAngleq6;
    else
     diffAngleq6 = startAngleq6 - oldStartAngleq6;

    for(uint8_t i = 0; i < RPLIDARNBSAMPLES; i++) {
     distance = distances[i];
     if(distance) {                                                    // Si la lecture est valide


      //lidarReady = true; // Debug
      angle = (float(oldStartAngleq6) + float(diffAngleq6) * float(i) / float(RPLIDARNBSAMPLES) - float(derivAnglesq5[i] << 1)) / 64.0 * PI / 180.0;;


      lidarx = POSITIONLIDARX + distance * sin(angle);
      lidary = POSITIONLIDARY + distance * -cos(angle);
      if(lidarx > POSITIONSROBOTXMAX || lidarx < POSITIONSROBOTXMIN ||
         lidary > POSITIONSROBOTYMAX || lidary < POSITIONSROBOTYMIN) { // Si la lecture est hors du robot
       lidarsx[j] = int(lidarx);
       lidarsy[j] = int(lidary);
       lidarsCartex[j] = int(lidarx * cos(theta) + lidary * -sin(theta) + odometriex * 1000.0);
       lidarsCartey[j] = int(lidarx * sin(theta) + lidary * cos(theta) - odometriey * 1000.0);
       j++;
       if(j == NBMESURESMAX)
        j = 0;
      }
     }
    }






    n++;
    break;

   default:
    sum ^= current;
    n++;
    switch(m) {
     case 0:
      derivAnglesq5[s] = (current & 3) << 6;
      distances[s] = current >> 2;
      m++;
      break;
     case 1:
      distances[s] |= current << 6;
      m++;
      break;
     case 2:
      derivAnglesq5[s + 1] = (current & 3) << 6;
      distances[s + 1] = current >> 2;
      m++;
      break;
     case 3:
      distances[s + 1] |= current << 6;
      m++;
      break;
     case 4:
      derivAnglesq5[s] |= (current & 0x0F) << 2;
      derivAnglesq5[s + 1] |= (current & 0xF0) >> 2;
      m = 0;
      s += 2;
      if(s == RPLIDARNBSAMPLES) {
       if(sum != checksum) {
        TXDEBUG.print(sum);
        TXDEBUG.print(" != ");
        TXDEBUG.println(checksum);
       }
       n = 0;
       s = 0;
       sum = 0;
      }
      break;
    }
    break;

  }
 }

}

Merci. Si j'ai compris ton code, tu prends tous les octets du packet sauf les 2 premiers.

 

Je vais tester ça. Je crois pas l'avoir fait. C'est pourtant évident de pas prendre en compte les 2 qui contiennent le checkSum ...

Merci. Si j'ai compris ton code, tu prends tous les octets du packet sauf les 2 premiers.

 

Je vais tester ça. Je crois pas l'avoir fait. C'est pourtant évident de pas prendre en compte les 2 qui contiennent le checkSum ...

 

LOL imagine le checksum qui s'auto prend en compte lui même le brainfuck de l'algo checksum côté lidar !!! tu le prends en compte donc il change donc il faut le reprendre en compte donc il rechange etc...

hop mon robot à une roue asservie qui tourne c'est l’accouchement ! DODO

Ouais lol comme tu dis. merci bn

Le checkSum passe nickel Je suis con des fois ^^

Donc avec le checksum, activé, le process nodeJS prend 15% du CPU.

Je continue.

Top !

Moi j'suis arrivé sur un grave problème de moteurs inutilisable pour mon type de projet sur le petit robot (ou la précision et la vitesse doivent aller de paire), j'ai du fedexer aux US pour ne pas être bloqué et dégouté pendant mes 2 semaines de congé.

J'ai mis un post plus complet ici http://www.robot-maker.com/forum/topic/11316-robot-pilotable-a-distance-via-internet-de-maniere-securise/page-3#entry91032

en résumé il faut un moteur qui tourne très vite avec une boite de réduction qui démultiplie fort - je suis passé de 34 à 100 mais je garde 150RPM sur l'arbre de sortie sans survolter le moteur!.