Bonjour

Je réalise un robot bimoteur qui est composé des éléments suivants : Carte Arduino Mega et Smartphone Android.

La carte Arduino collecte les données de 2 encodeurs (A), un Lidar, une camera AI ( . La carte envoie ces données au smartphone via une liaison Bluetooth. ©

Le smartphone envoie des commandes de guidage à la carte Arduino qui actionne 2 servos. (D)

L'ensemble fonctionne mais il y a clairement un problème de précision qui est dû à un décalage entre le moment où l'Arduino envoie les données et le moment où le smartphone les reçoit. Ce décalage est variable mais atteint parfois 4 secondes ce qui est énorme surtout quand le robot fait une manoeuvre  qui exige de la précision.

La transmission se fait à 9600 baud via un socket. La vitesse de transmission ne peut pas être augmentée étant donné que c'est du Bluetooth.

Mais même à 9600 baud la réception devrait se faire sans problème quasi instantanément. La chaîne de paramètres envoyée par l'Arduino fait +/- 80 digits.

Au niveau du code sur le téléphone (c'est du Windev) :

Il faut d'abord initialiser le socket

SocketEnCours	est une chaîne	= "so01"
MacDispositif	est une chaîne
RetourExiste	est une chaîne
MacDispositif	= "00:0E:EA:CF:71:40" 
e = SocketConnecteBluetooth(SocketEnCours,"SerialPortServiceClass_UUID",MacDispositif) 
SI e = Vrai ALORS
   RetourExiste	= SocketExiste(SocketEnCours)
   LIB_01 = "Connexion établie" 
   SI SocketChangeModeTransmission("so01", SocketSansMarqueurFin) = Vrai ALORS LIB_02 = "Mode de transmission modifié"
SINON
   LIB_01 ="Connexion en Bluetooth impossible " 
   Info(errInfo)
FIN

Ensuite une procédure est lancée toutes les 100 ms

buf = buf + SocketLit("so01",Faux,1000)
buf = Droite(buf,500)
bs = AnsiVersUnicode(buf)  
u2 = Position(bs,"#",0,DepuisFin)     // récupération de la fin de la chaîne
u1 = Position(bs,"@",u2,DepuisFin)    // récupération du début de la chaîne
bs = Milieu(bs,u1,u2-u1+1)
erg = Val(ExtraitChaîne(bs,2,";"))    // encodeur moteur gauche
erd = Val(ExtraitChaîne(bs,3,";"))    // encodeur moteur droit
px1 = Val(ExtraitChaîne(bs,9,";"))    // Coordonnées camera X
px2 = Val(ExtraitChaîne(bs,10,";"))   // Coordonnées camera Y
...

Le problème vient peut-être de cette communication par socket. Mais Windev Mobile ne prend pas en charge une communication série.

Si je connecte l'Arduino sur le port usb d'un pc, la réception des données à 9600 baud est quasiment immédiate.

Il va falloir remplacer le smartphone par un pc

Merci Sandro,

Je viens de recevoir https://www.ardusimp...te-bt-case-kit/

J'ai opté pour l'appli SW Maps pour Android et Lefebure NTRIP client.

La réception des satellites dans SW Maps fonctionne. (12 satellites à l'intérieur)

Par contre la connection au réseau Walcors (Belgique) n'est pas encore opérationnelle.

Ce ne serait pas normal que cela fonctionne du premier coup ...

Bonjour

Merci Oracid, mais s'il te plaît ne sois pas désolé

J'hésite entre la solution GPS qui communique avec un Arduino ou le GPS qui communique avec le smartphone.

Je pense que je vais me diriger vers la seconde afin de soulager l'Arduino qui fait déjà beaucoup de choses (LIDAR, camera Jevois, encodeurs, communication bidirectionnelle avec le téléphone en Bluetooth)

En tout cas c'est génial de pouvoir obtenir une précision centimétrique.

Pouvoir planifier un trajet sur Google Earth comme on le fait avec les drones...

Cela ouvre un paquet de perspectives

Bonjour,

J'avance bien sur ce projet de robot.

Je souhaiterais faire l'acquisition d'un GPS RTK.

Quelqu'un a-t-il déjà testé récemment un dispositif Ardusimple ?

https://www.ardusimple.com/store/

Merci

Bonjour,

Voilà où j'en suis avec ce châssis

Ce serait évidemment mieux de remplacer le joystick par une commande électronique mais cela dépasse mes compétences. Ce ne sont pas des simples potentiomètres.

Bonjour,

J'ai continué les essais avec la camera Jevois Pro

Le robot fait un va et vient entre 2 cibles ArUco qui se déplacent.

L'ArUco format A4 est détecté sans erreur à une distance de +/- 14 mètres. En plein soleil ou en faible luminosité.

Il n'y a aucun réglage à faire sur la camera. Juste démarrer Linux et choisir le bon module. Cette camera est géniale et les applications potentielles sont assez phénoménales. (merci à vous de m'avoir orienté vers ce matériel)

Le flux de données entre l'Arduino Mega est maintenant plus ou moins bien géré (selon mon niveau de compétence) 

1) Rplidar 2) Encodeurs 3) Camera Jevois Pro 4) module Bluetooth qui reçoit et envoie données vers un smartphone qui est sur le robot. Le smartphone peut être lui-même contrôlé par un pc via Wifi.

Robot de guidage

Etape suivante est de transposer le système sur un châssis plus costaud.

Apparemment cela fonctionne mais il y a sûrement un code plus simple et efficace.

La fonction strtok mérite d'être connue

String cm1;
String cm2;

void setup() {
   Serial.begin(9600); 
   cm1 = "N2 U6 N2 A3 2 N2 U6 89 67 77"; // string reçue sur le port série
   int cp = cm1.lastIndexOf('N2'); // position de N2 dans la chaîne en commençant par la fin
   cp = cp - 1;
   Serial.print("cp:");Serial.println(cp);
   cm2 = cm1.substring(cp); // extraction de la chaîne retenue
   int str_len = cm2.length() + 1; 
   char cm3[str_len];
   cm2.toCharArray(cm3, str_len); // conversion du string vers CharArray
   Serial.print("cm3:");Serial.println(cm3);
   const char *delimiter =" "; // séparateur espace
   char *token = strtok(cm3, delimiter); 
   while (token != NULL)
   {
      Serial.print("token:");Serial.println(token);
      token=strtok(NULL, delimiter);
   }
}

Ca donne dans le serial monitor :

N2 U6 N2 A3 2 N2 U6 89 67 77
cp:14
cm3:N2 U6 89 67 77
token:N2
token:U6
token:89
token:67
token:77


 

Bonjour,

La camera Jevois fonctionne très bien. Un ArUco au format A4 est détecté à une distance de 14 mètres.

Cependant je cale sur la réception des données envoyées par la camera Jevois.

La chaîne qu'elle envoie est : N2 U6 289 22 131 131

Je dois récupérer la valeur 289 qui est la valeur en x de l'ArUco et 131 qui est sa largeur. (qui permet de déterminer la distance de la cible).

Evidemment la longueur de la chaîne varie  (Exemple : N2 U6 1 230 450 450)

Voici le code que j'ai adapté :

void jevois() {
 if (millis() - t4 > 250)
  {
   t4 = millis();
   byte len = Serial2.readBytesUntil('\n', instr, INLEN);
   instr[len] = 0;
   char *tok = strtok(instr, " \r\n");
   state = 0;cy = 0;
   //===========================================================
   while (tok)
   {
    state ++;
    switch (state)
     { case 1: if (strcmp(tok, "N2") != 0){break;}
       case 3: cx = atoi(tok); {cy=1;break;}
       case 5: width = atoi(tok); break;
       default: break; // Skip any additional tokens
     }
     tok = strtok(0, " \r\n");
   } // while (tok)
   //===========================================================
   Serial.print(" cx:");Serial.print(cx);
   Serial.print(" width:");Serial.println(width);
  }// if
}

Parfois la chaîne reçue est correcte mais parfois l'Arduino reçoit :

N2 U9 21 131 130
N2 U6 289 2N2 U6 289 21 131 130
N2 UN2 U6 289 21 131 130
N2 U6 289 2N2 U6 289 21 131 1N2 U6 289 21 131 130

N2 UN2 U6 289 21 132 130

Dans un langage plus convivial (Windev ) je chercherais la première occurrence de N2 à partir de la droite.

Pour n'avoir que ceci : N2 U6 289 21 131 130

Puis boucle avec strtok pour avoir chaque valeur.

Je vérifie que valeur 1 = N2, valeur 2 U6
 

Mais bon en C++ c'est moins évident pour moi.

Je vais tester avec lastindexof() mais il a sûrement une méthode plus simple pour une communication série classique.

Si quelqu'un y voit plus clair ... merci pour votre aide.

Oui le code pourrait être plus optimal.

Je vais tester le robot avec ce code et voir s'il y a beaucoup de données à filtrer.

Pour info voici le code d'un exemple d'une came Jevois pour guider des servos.

Mais je ne comprends pas bien le code au niveau de la réception série. Donc je préfère utiliser un code que je comprends mieux

// JeVois control steering or a pan/tilt head from the output of JeVois modules
//
// We handle messages "T2 <targetx> <targety>", "T1 <targetx>", "PANGAIN <gain>", and "TILTGAIN <gain>".
// targetx and targety are assumed to be in the -1000 ... 1000 range as output by the JeVois Kalman filters.
// Here we only do simple PD control under the assumption that target coordinates have already been filtered upstream.
 
#include <Servo.h>
 
// Pin for LED, blinks as we receive serial commands:
#define LEDPIN 13
 
// Serial port to use: on chips with USB (e.g., 32u4), that usually is Serial1. On chips without USB, use Serial:
#define SERIAL Serial1
 
// Pins for up to two servos:
Servo panservo;
#define PANPIN 3
Servo tiltservo;
#define TILTPIN 5
 
// Initial servo values in degrees:
#define PANZERO 90
#define TILTZERO 90
 
// With updates typically coming in at 60Hz or up to 120Hz, we will often need to move by a fraction of a
// degree. Hence we keep track of the pan and tilt values multiplied by SCALE. For the gains, a gain of 100
// means we will update servo angle by the 0.1*(target value/SCALE) degrees on each update. Higher gains mean
// larger angular updates.
#define SCALE 100
long pangain = 100;
long tiltgain = 100;
long panval = PANZERO * SCALE;
long tiltval = TILTZERO * SCALE;
 
// Buffer for received serial port bytes:
#define INLEN 128
char instr[INLEN + 1];
 
void setup()
{
  SERIAL.begin(115200);
  SERIAL.setTimeout(1000000);
 
  pinMode(LEDPIN, OUTPUT);
  digitalWrite(LEDPIN, LOW);
  
  panservo.attach(PANPIN);
  panservo.write(panval / SCALE);
 
  tiltservo.attach(TILTPIN);
  tiltservo.write(tiltval / SCALE);
 
  // We are ready to rock, disable logs and turn on serial outputs on JeVois platform:
  SERIAL.println("setpar serlog None");
  SERIAL.println("setpar serout Hard");
}
 
void loop()
{
  digitalWrite(LEDPIN, LOW);
  byte len = SERIAL.readBytesUntil('\n', instr, INLEN);
  instr[len] = 0;
  digitalWrite(LEDPIN, HIGH);
 
  char * tok = strtok(instr, " \r\n");
  int state = 0; int targx = 0, targy = 0;
  while (tok)
  {
    // State machine:
    // 0: start parsing
    // 1: T2 command, parse targx
    // 2: T2 command, parse targy
    // 3: T2 command complete
    // 4: T1 command, parse targx
    // 5: T1 command complete
    // 6: PANGAIN command, parse pangain
    // 7: PANGAIN command complete
    // 8: TILTGAIN command, parse tiltgain
    // 9: TILTGAIN command complete
    // 1000: unknown command
    switch (state)
    {
      case 0:
        if (strcmp(tok, "T2") == 0) state = 1;
        else if (strcmp(tok, "T1") == 0) state = 4;
        else if (strcmp(tok, "PANGAIN") == 0) state = 6;
        else if (strcmp(tok, "TILTGAIN") == 0) state = 8;
        else state = 1000;
        break;
        
      case 1: targx = atoi(tok); state = 2; break;
      case 2: targy = atoi(tok); state = 3; break;
      case 4: targx = atoi(tok); state = 5; break;
      case 6: pangain = atoi(tok); state = 7; break;
      case 8: tiltgain = atoi(tok); state = 9; break;
 
      default: break; // Skip any additional tokens
    }
    tok = strtok(0, " \r\n");
  }
 
  // Target coordinates are in range -1000 ... 1000. Servos want 0 ... 180.
  // We also need to negate as needed so that the servo turns to cancel any offset from center:
  if (state == 3 || state == 5)
  {
    panval -= (targx * pangain) / 1000;
    if (panval < 5 * SCALE) panval = 5 * SCALE; else if (panval > 175 * SCALE) panval = 175 * SCALE;
    panservo.write(panval / SCALE);
  }
  
  if (state == 3)
  {
    tiltval += (targy * tiltgain) / 1000;
    if (tiltval < 5 * SCALE) tiltval = 5 * SCALE; else if (tiltval > 175 * SCALE) tiltval = 175 * SCALE;
    tiltservo.write(tiltval / SCALE);
  }
}

Contexte : j'utilise une camera AI pour guider un robot bimoteur.

Celui-ci se dirige vers une cible qui est posée sur un second petit mobile qui se déplace.

J'ai auparavant utilisé une camera Husky Lens. J'ai d'abord essayé avec des codes barres puis une mire en forme de croix et la fonction object tracking de la camera Husky Lens. Cela fonctionne pour des petites distances de +/- 4m mais la camera est très sensible aux variations de lumière et donc la solution n'est pas convaincante pour des plus grandes distances et surtout pour travailler à l'extérieur.

Je suis donc passé sur la camera Jevois Pro. Celle-ci permet de travailler avec des ArUco markers. Ce sont des codes barres simplifiés plus adaptés à la robotique. C'est un appareil tout à fait différent de l'Husky Lens : c'est un petit ordinateur sous Linux sur lequel on branche un écran HDMI, clavier et souris.

On choisit l'application qui nous intéresse : reconnaissance d'objets, de mains, de visages, .... et d'ArUco. La vitesse de détection des ArUco est impressionnante et sans apprentissage.

Après quelques essais à l'extérieur, la camera détecte sans problème un ArUco à 8 mètres sous différentes luminosités.

La connexion avec l'Arduino Mega (port série 2) est très simple VIN GRD RX TX. Voici le code utilisé qui peut à mon avis être optimisé.

La camera envoie la chaîne "T2 cx cy" à 115200 bauds

x = coordonnées en x du centre de l'ArUco marker. -1000 à fond à gauche et 1000 à fond à droite.

Parfois il y a des valeurs tout à fait différentes Exemple 20 fois les valeurs 800 100 puis 0 0. Cela vient sûrement du code.

void jevois() {
  if (millis() - t4 > 500)
  {
    t4 = millis();
    if (inData == "") {cx = 9999;cy = 0;}
     
    while (Serial2.available() > 0)
    {
      char rx = Serial2.read();
      inData += rx; 
      if (rx == '\n')
        {readString = inData; 
         inData = "";
         cm1 = readString.substring(3,7); 
         char carray[cm1.length() + 1]; 
         cm1.toCharArray(carray, sizeof(carray)); 
         cx = atoi(carray); // coordonnées en x 
          
        }
    }
  }
}

A première vue les possibilités sont assez vastes.

Bonjour

Pour l'instant les contrôleurs ZS-X11H conviennent pour le job. Merci pour ton aide Oracid.

Je viens d'acquérir une camera Jevois Pro.

L'objectif est de l'utiliser avec des ArUcode pour guider le robot et surtout d'augmenter la portée par rapport à l'Huskylens.

C'est un appareil nettement plus complet : Linux Ubuntu avec un paquet de modules. Faut apprendre à maîtriser la bête.

Si qq l'a déjà utilisé avec un Arduino ...

Ok l'intérêt des contrôleurs e-bike est donc la puissance...

Pour ma part je continue mon robot de nettoyage avec des moteurs DC car avec les moteurs d'hoverboard je n'arrive pas à stabiliser les trajectoires quand le terrain est en pente....

Mais le problème se pose quand même avec les moteurs DC : quand le robot est bien chargé avec un pulvérisateur plein et qu'il doit faire un demi-tour dans une pente, c'est pas évident. Il est quand même entraîné par son poids. Donc même dans ce cas il faut pouvoir maîtriser l'asservissement en vitesse. Ce qui n'est pas encore évident pour moi.

(J'utilise un smartphone Android et un Arduino Mega)

.

Le but du bras est de manipuler une charge de quel poids ?

C'est super de pouvoir utiliser l'hoverboard tel quel avec carte et batterie. Je vais m'intéresser au firmware hoverboard hack FOC.

Ca va sûrement intéresser Oracid.

Et ton bras manipulateur tu vas l'interfacer comment avec le NUC ?

Merci pour la liste de matériel.

Je ne comprends pas comment tu fais l'interface entre le petit pc et la  carte de l'hoverboard.... c'est une connexion série ?

L'IMU a l'air bien. 

J'en ai essayé quelques uns pour guider le robot selon un cap déterminé. Mais la précision n'était pas au rendez-vous. Le cap variait de plusieurs degrés alors que le robot ne changeait pas de direction.

Tu es satisfait de cet IMU ?

Merci en tout cas pour les infos.

Bonjour

@Pat92fr : super le robot. Il a l'air de bien se comporter dans la pente.

Tu utilises du matos plus spécifique (ROS2 SLAM, ...) qui a l'air nettement plus performant que la solution Arduino Mega /  contrôleur ZS-X11H

En termes de coût tu te situes à quel niveau ?

Bonjour,

J'ai avancé sur ce projet.

2 robots mires qui se déplacent. Et le robot principal avec le nettoyeur haute pression qui fait des va et vient entre les 2 robots.

Quand le "gros" robot arrive près d'un robot de guidage, celui-ci reçoit une commande en 433 Mhz qui lui demande de se déplacer de 40 cm.

En intérieur sur des petites distances de 5/6m cela fonctionne.

A l'extérieur c'est moins évident surtout quand la luminosité est forte ...

Je vais tenter d'améliorer le système :

- en utilisant plutôt un point lumineux circulaire. Je ne suis pas convaincu que la croix en led soit plus visible de loin.

- peut-être qu'un seul robot de guidage serait suffisant. Le robot principal ferait marche arrière plutôt que de faire demi tour avec tout ce que cela comporte comme imprécision.

- en utilisant une camera Jevois Pro et AruCo tag (Sandro)

- comme proposé par Mike118 l'idéal serait d'utiliser un système de balises ultrasons / Balise UWB ...

Bref il y a encore du taf

Super ! beau travail.

Je ne comprends pas tout ce que tu as fait ... mais apparemment c'est bien fait.

Tu as un asservissement en vitesse ? Si tu mets le robot sur un plan incliné il va freiner les roues pour garder sa trajectoire ?µ

Pour ma part c'est ce qui me paraît le plus difficile à faire...

@Oracid : pas trop dur de ne pas être dans ton atelier ?

Bonjour, j'ai fait de nombreux essais avec cet engin.

Ma conclusion actuelle est que cet engin est très difficile à guider en charge et sur terrain en pente.

C'est dû au fait que ce sont des roues qui tournent librement quand il n'y a pas de tension.

Bien sûr il faut un asservissement en vitesse et donc freiner les roues qui s'emballent mais cela devient fort compliqué à mon niveau.

Je vais laisser au frigo pour un moment et revenir vers des motoréducteurs. Cela me paraît nettement plus facile à guider avec précision.

Merci Mike118 !

Je n'avais pas vu ta réponse.

Très utile. Je vais l'appliquer de ce pas car je ne suis toujours pas satisfait du suivi de la référence par le robot.

La trajectoire est trop sinueuse.

Encore merci.

Bonjour

J'ai proposé à mon robot de passer de la propulsion à la traction. Cela ne s'est pas fait sans douleur.

Le pauvre ne savait plus où étaient sa tête et son cul....

Je lui ai ajouté des spots leds pour ne laisser aucun doute... et du coup éclairer sa zone de travail.

Au niveau de la motricité, cela paraît meilleur.

Au niveau guidage c'est quand même fort différent et en tout cas plus sensible et à mon sens plus difficile à régler.

C'est plus facile de diriger un caddie bien chargé avec des roues fixes à l'avant et folles à l'arrière qu'un caddie avec les roues folles à l'avant et fixes à l'arrière. Mais dans le premier cas la trajectoire est plus imprécise.

Je vous laisse méditer là-dessus

Bonjour, je suis sur un projet similaire à celui de bubu17

J'utilise les mêmes controleurs avec des moteurs d'hoverboard de 10 pouces.

Pour le moment ils font le job, mais il faudra voir quand le robot sera plus lourd.

Le freinage n'est pas très efficace mais on fait avec.

Au départ les moteurs étaient à l'arrière du robot. J'ai finalement opté pour la traction : moteurs à l'avant, roues folles à l'arrière.

Avec Rplidar, camera Huskylens et encodeurs.

Bonjour,

Je suis sur un projet de robot 2 roues motrices destiné dans un premier temps à rouler sur du béton, pavés, ... avec des charges.

Au départ du projet je me suis inspiré des robots tondeuse : 1 ou 2 roues folles devant et 2 roues motrices à l'arrière

Et je suis parti sur cette configuration me disant que ces gens avaient sûrement de bonnes raisons de faire comme ça.

Mais dans le cas des tondeuses, c'est peut-être plus facile de mettre les grandes roues derrière pour pouvoir tondre plus près de la bordure.

Dans mon cas, les 2 roues frontales font un diamètre de 80 mm. Les roues arrière motrices un diamètre de 280 mm.

Est-ce vraiment la bonne solution ?

En cas de franchissement de petit obstacle, bosse, pierre, ... n'est - il pas préférable d'avoir les grandes roues motrices à l'avant qui vont plus facilement le surmonter ?

Au niveau du guidage : est-il différent pour une traction ou une propulsion ?

Qu'en pensez-vous ?

Les robot-mire peuvent être "très" simples. (oui je sais que ce genre de chose est rarement simple)

Ils ne peuvent se déplacer que tout droit.

Un moto-réducteur sur une roue de traction. 2 roues arrière non pivotantes. Un Arduino, un driver. un capteur à ultrasons, une batterie 12V

Ou je récupère 2 voitures à téléguider que j'adapte.

Merci Mike118 : je vais regarder du côté des balises ultrasons, ... mais il faut que ça reste un truc que je suis capable de faire ...

De mon côté je suis en train de mettre en place un asservissement en vitesse. Je crois qu'on y échappera pas.

J'ai choisi de monter les encodeurs sur des petites roues indépendantes. C'est plus précis. 1000 tours de la petite roue = 100 cm.

Pour avancer à la vitesse d'une tondeuse robot, la valeur de pwm est 45. Donc il y a encore de la réserve.

Et le robot pèse à vide 9kg

J'ai continué à améliorer le guidage avec la camera Huskylens, j'ai réalisé des mires lumineuses :

des simples croix réalisées avec des rubans led et un petit dimmer.

La camera en mode reconnaissance d'objet les reconnaît à +/- 8 mètres voire plus. (mon living est trop court).

De plus la reconnaissance peut se faire dans une ambiance lumineuse faible.

Je souhaiterais que le robot balaye une surface de +/- 10m x 10m. Le guidage par mire lumineuse ma paraît tellement efficace que je me demande s'il serait pertinent d'utiliser 2 mires mobiles motorisées :

L'axe de déplacement serait défini par 2 mires.

Pour le premier axe le robot est guidé sur la première mire.

Lorsque le robot arrive au bout de l'axe, il fait demi-tour et vise la seconde mire pour revenir au point de départ.

Ensuite la première mire se déplace de 30 cm et ainsi de suite.

Bien sûr il faut fabriquer 2 mires mobiles qui se déplacent quand le robot s'en approche. (détection par ultrasons).

Mais cela me semble en valoir la peine.