Trolley Robot 2.0. Partie 1. Navigation autonome d'un robot domestique basé sur ROS

Le projet a été construit sur la base d'un autre projet bien connu dans ses cercles - linorobot (linorobot.org), en utilisant des composants disponibles pour un simple profane. Les objectifs qui ont été fixés: réaliser un mouvement autonome du robot à la maison en utilisant des composants à faible coût, évaluer les performances des mini-PC aux fins indiquées, configurer la pile de navigation pour se déplacer dans les espaces étroits du Khrouchtchev.



Le fer


La liste des composants dans les solides est la suivante:

  • framboise pi 3b - 2800 r .;
  • lidar rplidar a1 - 7500 p .;
  • ponts électriques l298n -2pcs - 400 rub.;
  • paire de roues avec encodeurs de type A et B - 2000 r. (210 tr / min - lien )
  • Teenzy 3.2 - 2100 r.;
  • imu 9250 (9150 ou 6050) - 240 p .;
  • banque de puissance à 10000mH - 1500 r.
  • 3 piles 18650 et support -600 p.
  • convertisseur abaisseur dc-dc c 5V à 3,3V - 20p.
  • un morceau de contreplaqué, parquet -? frotter.

Total: 17160 p.

* Le coût peut être réduit en remplaçant teenzy par arduino mega 2560 (600 p.), Et lidar en remplaçant kinect v.1 (1000 p.):



Cependant, il convient de noter que le premier kinect a une visibilité minimale (zone aveugle) de 0,5 m, ce qui peut nuire à la navigation dans des conditions exiguës et il est plutôt encombrant. Le lidar a une zone aveugle de moins de 0,2 m. Kinect v.2 ne conviendra pas à la framboise 3b (il n'a pas d'usb 3.0). Arduino mega est inférieur à teenzy en taille (et certaines caractéristiques), en plus, vous devrez retravailler légèrement le code.

En général, le «design» ressemble à ceci:





Il n'y a pas de beauté ici, bien sûr, mais ce n'est pas tout.

En plus du robot lui-même, il est hautement souhaitable d'avoir un PC externe sur lequel seront lancés des coques graphiques pour visualiser les actions du robot (rviz, gazebo).

Assemblage de robot


Il est peint en détail sur le site Web du projet - un lien , alors insistons sur les points qui causent des difficultés. Vous devez d'abord considérer que les encodeurs de la paire de roues sont alimentés en 3,3 V et, lorsque 5 V sont appliqués, échouent parfaitement.

Le script d'installation de linorobot est correctement installé sur ubuntu 16.04, ubuntu 18.04. Versions ROS: ROS cinétique ou ROS mélodique. Sur framboise 3b, vous devez d'abord créer un fichier d'échange.

Le principal code teenzy est en cours de route:

roscd linorobot/teensy/firmware/lib/config
nano lino_base_config.h

Et versé dedans avec la commande:

roscd linorobot/teensy/firmware
platformio run --target upload

Les ensembles de commandes ci-dessus seront utilisés assez souvent, il est donc logique de les ajouter aux alias.

En raison des difficultés d'assemblage du robot, la corrélation correcte des contacts connectés allant de l298n à teenzy peut être gênante. Malgré le schéma de connexion extrêmement clair, les roues peuvent se comporter différemment et doivent expérimenter, en choisissant l'affectation des broches correcte dans le code.

Dans mon cas, cela s'est avéré comme ceci:

/// ENCODER PINS
#define MOTOR1_ENCODER_A 14
#define MOTOR1_ENCODER_B 15 

#define MOTOR2_ENCODER_A 11
#define MOTOR2_ENCODER_B 12 
//MOTOR PINS
#ifdef USE_L298_DRIVER
  #define MOTOR_DRIVER L298

  #define MOTOR1_PWM 21
  #define MOTOR1_IN_A 1
  #define MOTOR1_IN_B 20

  #define MOTOR2_PWM 5
  #define MOTOR2_IN_A 8
  #define MOTOR2_IN_B 6

Le deuxième point est de prescrire la spécification des roues du robot:

//define your robot' specs here
#define MAX_RPM 210               // motor's maximum RPM
#define COUNTS_PER_REV 1365       // wheel encoder's no of ticks per rev
#define WHEEL_DIAMETER 0.065       // wheel's diameter in meters
#define PWM_BITS 8                // PWM Resolution of the microcontroller
#define LR_WHEELS_DISTANCE 0.235  // distance between left and right wheels
#define FR_WHEELS_DISTANCE 0.30   // distance between front and rear wheels. Ignore this if you're on 2WD/ACKERMANN
#define MAX_STEERING_ANGLE 0.415  // max steering angle. This only applies to Ackermann st

RPM peut être trouvé dans la spécification de roue, mais CPR (COUNTS_PER_REV) est la valeur calculée.
CPR = PPR x 4. PPR de nos roues 341.

* PPR peut être visualisé dans les spécifications ou exécuter le code sur le robot roslaunch linorobot minimal.launch et tourner la roue à 360 degrés. PPR sera égal à la valeur numérique qui sera affichée à l'écran après la rotation de la roue:



* PPR = abs (RECENT_COUNT - INITIAL_COUNT).

Donc CPR = 1364. Vous devez également définir WHEEL_DIAMETER et LR_WHEELS_DISTANCE en mètres. De plus, LR_WHEELS_DISTANCE est la distance entre les axes centraux des roues, et non pas de bord à bord. D'autres indicateurs peuvent être ignorés si le robot est à deux roues, différentiel (pas omni).

Le troisième point qui peut poser des problèmes - l' étalonnage imu. Pour ce faire, en suivant les instructions, il est nécessaire de fixer le robot dans certaines positions. Les conseils seront dans le code lors de l'exécution du script rosrun imu_calib do_calib : une



fois terminé, imu_calib.yaml avec les paramètres sera généré.

Il est préférable d'effectuer l'étalonnage, malgré le fait qu'il existe un fichier par défaut avec les paramètres imu.
* De plus, il s'est avéré que l'étalonnage imu peut affecter la direction du mouvement du robot par téléopération (gauche au lieu de droite et vice versa, alors que le mouvement de va-et-vient était correct). La situation n'a pas été résolue par le réarrangement des broches dans le code. Imu lui-même a été fixé et calibré avec des supports inversés, comme fixé à l'arrière de la base du robot. Son (imu) flip supplémentaire sans recalibrage a résolu le problème.

Quatrième point - étalonnage pid.

Sur le site Web du projet, la procédure de mise en œuvre de l'ajustement est décrite en détail - lien .

Cependant, il sera difficile pour un débutant de comprendre ce que c'est et comment travailler avec. En général, une régulation pid est nécessaire pour garantir que le robot se déplace uniformément, sans secousses / freinage brusque. Trois paramètres en sont responsables: p, i, d. Leurs valeurs sont contenues dans le code principal téléchargé sur teenzy:

#define K_P 2.0 // P constant angle
#define K_I 0.3 // I constant
#define K_D 0.1 // D constant

Vous pouvez les expérimenter en exécutant sur le robot:

roslaunch linorobot minimal.launch

Plus loin sur le PC externe dans trois terminaux différents:

rosrun lino_pid pid_configure
rosrun teleop_twist_keyboard teleop_twist_keyboard.py
rqt

En déplaçant les curseurs p, d, i dans le terminal rqt, puis en contrôlant le robot dans le terminal teleop_twist_keyboard, vous pouvez obtenir les résultats nécessaires sans avoir à télécharger le code avec les nouveaux paramètres pid à chaque fois dans teenzy:



c'est-à-dire que tout se passe à la volée et à ce moment-là dans le firmware teenzy peut avoir des significations complètement différentes. * Vous ne pouvez pas vous concentrer sur les graphiques, car visuellement, et ainsi on comprendra COMMENT le robot se déplace.

Ils recommandent de commencer par définir les valeurs p = 1,0, d = 0,1, i = 0,1. Dans notre cas, les valeurs sont les suivantes (obtenues expérimentalement) p = 2,0, i = 0,3, d = 0,1.

Ensuite, ces valeurs doivent être définies dans le code et remplies dans teenzy.

N'oubliez pas non plus de définir le code (DEBUG 0 au lieu de DEBUG 1):

#define DEBUG 0

Odométrie


Pour l'orientation du robot et la navigation ultérieure, les données lidar, imu et encodeur de roue sont utilisées. Si l'étalonnage imu est effectué correctement, que le lidar est correctement installé et que les valeurs de l'encodeur sont correctes, il ne devrait y avoir aucun problème d'odométrie.

Pour vérifier que l'odométrie est correcte, vous devez rouler un peu sur le robot via teleop et voir les valeurs dans la rubrique odom, cela est écrit sur la page du projet - lien .

Et regardez également dans la coque visuelle de rviz:



une cellule de rviz mesure 1 m, il est donc conseillé au robot de passer ce compteur à la fois dans l'éditeur visuel et en nature.

De plus, la distance parcourue est affichée dans l'indicateur w:



Elle doit également tendre à 1 m.

Il en va de même pour les angles de rotation du robot:



* En rviz et en direct, le robot doit tourner selon les mêmes angles.

L'odométrie d'un lidar est définie de la même manière - un lien: la distance entre le lidar et le mur le plus proche, en direct et en direct, doit correspondre.

TF


Dans ROS, une attention particulière est accordée aux transformations - tf. D'une manière générale, ce concept décrit la corrélation des objets les uns par rapport aux autres dans l'espace. Pour que les objets ne pendent pas en l'air et que le programme comprenne comment ils sont présentés les uns par rapport aux autres, il est nécessaire de faire attention au réglage tf.

Dans le projet, toutes les connexions tf sont déjà configurées les unes par rapport aux autres et il vous suffit d'ajuster les indicateurs, par exemple, d'indiquer comment se trouve le lidar. Cela est nécessaire pour que le robot comprenne que l'obstacle ne s'est pas posé directement devant lui, mais devant le lidar, qui est séparé du centre du robot à une certaine distance.

Allons dans le répertoire approprié:

roscd linorobot/launch
nano bringup.launch

La base elle-même est située à une distance de 0,065 m du sol:

<node pkg="tf_ros" type="static_transform_publisher" name="base_footprint_to_base_link" args="0 0 0.065 0 0 0  /base_footprint /base_link "/>

Dans laser.launch, vous devez définir l'emplacement du lidar par rapport au centre de la base du robot:

roscd linorobot/launch/include
nano laser.launch

Dans mon cas, le lidar est décalé le long de l'axe x: -0,08, y: 0,04 et "monte" au-dessus de la base (axe z): 0,08m:

<node pkg="tf2_ros" type="static_transform_publisher" name="base_link_to_laser"
args="-0.08 0.04 0.08 0 0 0  /base_link /laser "/>

En rviz, cet emplacement peut être observé visuellement: bien



que non loin du lidar, nous ajusterons sa fréquence pour qu'il donne plus de points (par défaut, il donne 4k), cela aidera à construire la carte:

cd linorobot/launch/include/lidar
nano rplidar.launch

Ajouter un paramètre:

<param name="scan_mode"  type="string" value="Boost"/>

et changer

<param name="angle_compensate"    type="bool"   value="false"/>

Maintenant 8k est à notre disposition: L'



emplacement physique du lidar sur le robot est également important:



Construire un plan de salle 2D


Sur le site du projet, il est proposé de construire un plan de salle en lançant dans deux terminaux:

roslaunch linorobot bringup.launch
roslaunch linorobot slam.launch

Cependant, la pratique a montré que le slam, qui accompagne le projet par défaut, refuse de fonctionner lorsque le mode lidar est à 8k:



alors qu'en mode 4k, les cartes ne sont pas très réussies, elles sont très bruyantes.

Par conséquent, il est préférable d'utiliser un autre slam - hector-slam.

Comment l'installer est indiqué ici .

Après l'installation, la procédure de création d'une carte sera la même, mais au lieu de roslaunch linorobot slam.launch, exécutez roslaunch my_hector_mapping my_launch.launch Les

cartes sont plus propres, mais il est préférable de les modifier dans un éditeur graphique, supprimant celles inutiles, surtout si le lidar est entré en collision avec des miroirs lors de la construction de la carte :



N'oubliez pas de sauvegarder le plan des chambres:

rosrun map_server map_saver -f my-map

* Les cartes sont mieux obtenues dans un crépuscule agréable, ce qui tirera le meilleur parti du lidar budgétaire.

À suivre.

All Articles