IMA3/IMA4 2018/2020 P13 : Différence entre versions

De Wiki de Projets IMA
(→‎Semaine2 (20/01-26/01))
(→‎Documents Rendus)
 
(146 révisions intermédiaires par 2 utilisateurs non affichées)
Ligne 256 : Ligne 256 :
 
==Calendrier prévisionnel==
 
==Calendrier prévisionnel==
  
−
{| style="float: center; height: 300px; margin-left:0.2em; border: 0px solid #bbb;"
+
{| style="float: center; height: 200px; margin-left:0.2em; border: 0px solid #bbb;"
−
| style="border: 1px solid #bbb;" valign="top" |[[Fichier:planningp13.png|500px]]
+
| style="border: 1px solid #bbb;" valign="top" |[[Fichier:planningp13.png|300px]]
 
|}
 
|}
  
Ligne 477 : Ligne 477 :
 
{| style="float: center; height: 150px; margin-left:0.2em; border: 0px solid #bbb;"
 
{| style="float: center; height: 150px; margin-left:0.2em; border: 0px solid #bbb;"
 
| style="border: 1px solid #bbb;" valign="top" |[[Fichier:shield1.png|250px]]
 
| style="border: 1px solid #bbb;" valign="top" |[[Fichier:shield1.png|250px]]
−
| style="border: 1px solid #bbb;" valign="top" |[[Fichier:shield2.jpg|250px]]
+
| style="border: 1px solid #bbb;" valign="top" |[[Fichier:shield2.png|290px]]
 
|}
 
|}
  
 
* Design du nouveau chassis (Plexiglas), en attente de la découpe laser.
 
* Design du nouveau chassis (Plexiglas), en attente de la découpe laser.
−
 
−
* Construction image 3D
 
−
** https://docs.opencv.org/3.4.8/d4/d18/tutorial_sfm_scene_reconstruction.html
 
−
** https://becominghuman.ai/stereo-3d-reconstruction-with-opencv-using-an-iphone-camera-part-i-c013907d1ab5
 
  
 
* Configuration des webcams
 
* Configuration des webcams
Ligne 490 : Ligne 486 :
 
**Nous avons utilisé le code fourni par Omar Padierna que nous avons récupéré sur https://github.com/OmarPadierna/3DReconstruction et effectué les premier test de configuration pour la construction d'une image 3D à partir d'OpenCV.
 
**Nous avons utilisé le code fourni par Omar Padierna que nous avons récupéré sur https://github.com/OmarPadierna/3DReconstruction et effectué les premier test de configuration pour la construction d'une image 3D à partir d'OpenCV.
 
**Nous avons sélectionné 2 webcam ayant une basse qualité d'image pour que les calculs soient plus rapide. Le problème c'est que les images sont de trop mauvaise qualité ce qui ne permet pas pour le moment de faire la configuration des webcams avec OpenCV.
 
**Nous avons sélectionné 2 webcam ayant une basse qualité d'image pour que les calculs soient plus rapide. Le problème c'est que les images sont de trop mauvaise qualité ce qui ne permet pas pour le moment de faire la configuration des webcams avec OpenCV.
 +
 +
* Construction image 3D (OpenCV)
 +
** https://docs.opencv.org/3.4.8/d4/d18/tutorial_sfm_scene_reconstruction.html
 +
** https://becominghuman.ai/stereo-3d-reconstruction-with-opencv-using-an-iphone-camera-part-i-c013907d1ab5
  
 
===Semaine3 (27/01-02/02)===
 
===Semaine3 (27/01-02/02)===
 +
 +
* Construction du nuage de point (stéréo vision)
 +
** Principe de fonctionnement
 +
On utilise deux cameras séparées d'une certaine distance (comme deux yeux) pour mesurer la distance d'un objet dans l’environnement extérieur.
 +
Les deux cameras sont sur le même plan et on la même inclinaison verticale/horizontale. On connais la distance qui les sépare (l). Si on connais les angles A et B alors on peut utiliser le principe de triangulation pour connaître la distance de l'objet (d):
 +
{| style="float: center; height: 200px; margin-left:0.2em; border: 0px solid #bbb;"
 +
| style="border: 1px solid #bbb;" valign="top" |[[Fichier:StereoVision1.jpg|400px]]
 +
|}
 +
Pour calculer les angles A et B: On connais l'ouverture du champ de vision de la camera (angle C) et on connais la largeur de l'image (L en pixel). On peut donc calculer la distance D et en déduire l'angle alpha:
 +
{| style="float: center; height: 200px; margin-left:0.2em; border: 0px solid #bbb;"
 +
| style="border: 1px solid #bbb;" valign="top" |[[Fichier:StereoVision2.jpg|400px]]
 +
|}
 +
 +
Il suffit désormais de trouver un point similaire dans chacune des images pour calculer sa distance par triangulation. A chaque point de l'image on peut désormais associer une une notion de profondeur et donc on peut reconstituer une nuage de point 3D représentant l’environnement extérieur.
 +
 +
On utilise la librairie OpenCV qui contient déjà toutes les fonctions nécessaires au traitement de l'image et a la reconstruction de la vue en 3D.
 +
 +
** Calibration des cameras
 +
Pour pouvoir calculer la distance d'un point de l'image, il faut connaître les caractéristiques intrinsèques de la camera tel que la distance focal:
 +
{| style="float: center; height: 150px; margin-left:0.2em; border: 0px solid #bbb;"
 +
| style="border: 1px solid #bbb;" valign="top" |[[Fichier:FocalLength.jpg|300px]]
 +
|}
 +
 +
De plus, avant de construire le nuage de points 3D, les image sont traitées pour compenser la distorsion (radiale et tangentielle) introduite par la camera (notamment a cause du positionnement de la lentille). Cette distorsion modifie les formes reeles des objets et donc influe sur le résultat de la triangulation. La méthode cv2.undistort d'OpenCV permet de rectifier l'image. Elle prend en paramètre les coefficient de distorsion (k1 k2 p1 p2 k3) qu'il nous faut connaître.
 +
Pour cela, on prend une série de photo d'un damier avec différentes inclinaisons et on lance le programme calibrate.py. Ce dernier détecte les coins des carres du damier et mesure les distances (en pixel) entre chacun. Ces dimensions sont comparées aux dimensions reeles (mesurées a la main) et permette de calculer les coefficients de distorsion (matrice dist.npy).
 +
Bien mieux expliqué ici: https://opencv-python-tutroals.readthedocs.io/en/latest/py_tutorials/py_calib3d/py_calibration/py_calibration.html#calibration
 +
 +
Le programme récupère également les paramètres intrinsèques/extrinsèques de la camera (distance focale et foyer optique) présent dans l’entête de chaque image.
 +
 +
Nous rencontrons ici un problème pour recuperer la distance focal de webcam. Cela marche tres bien avec la camera d'un téléphone portable car la valeur est directement écrite dans les caractéristique de la photo. Ce n'est pas le cas pour la webcam. On rentre la valeur de la focal a la main dans le programme de reconstruction, focal_length = 4.2 (trouvée dans sur internet d'une source moyennement fiable).
 +
 +
* Réunion avec étudiant de Mr. Dequidt pour pilotage automatique
 +
** Première solution (la simple): détecter l'objet par sa couleur
 +
** Pythonrobotics pour planifier le parcours du robot
 +
** SLAM pour localisation et mapping de l'environnement
 +
** fast.ai / pytorch
 +
 +
* liste de courses
 +
** https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1822096/
 +
** https://fr.rs-online.com/web/p/webcams/1254274/
 +
 
===Semaine4 (03/02-09/02)===
 
===Semaine4 (03/02-09/02)===
 +
====Damien====
 +
* développement du code pour récupération des données du Lidar en 2D: premier code en python pour vois si tout fonctionnait bien rapidement mais les données n'étaient pas précises, donc utilisation du code fourni par le fournisseur en C++, la récupération des données semblent plus rapides en C++ et plus précises.
 +
http://www.slamtec.com/en/support#rplidar-a-series
 +
 +
====Vincent====
 +
* Decoupe (au fab) du châssis et du support pour les webcam (pour avoir un écartement fixe entre les deux et la même inclinaison verticale/horizontale)
 +
[[Fichier:DecoupeLaser.zip]]
 +
* Script python pour sauvegarder une image a partir d'un webcam (Vincent): save_snapshot.py permet d'enregistrer une série de photo du damier qui seront ensuite analysées.
 +
* Script python pour récupérer les paramètres des camera: calib.py détecte les coins des carres noirs du damier et détermine la distorsion des cameras ainsi que ses caractéristiques intrinsèques (fichers K.npy et dist.npy)
 +
 +
{| style="float: center; height: 200px; margin-left:0.2em; border: 0px solid #bbb;"
 +
| style="border: 1px solid #bbb;" valign="top" |[[Fichier:calib.png|400px]]
 +
|}
 +
 +
* Reconstruction du nuage de points 3D a partir de 2 images (Reconstruction.py). Il faut cependant trouver les bon paramètres pour la reconstruction (lors de l'appel a "cv2.StereoSGBM_create") car ceux de base peu efficaces. Pour cela, j'ai créé une fenêtre avec des curseurs amovibles pour trouver visuellement les meilleurs paramètres (c'est Damien qui se charge de trouver les bon params la semaine d’après).
 +
Fortement inspiré par : https://martinperis.blogspot.com/2011/08/opencv-stereo-matching.html (code en c++ réécrit en python).
 +
 +
{| style="float: center; height: 200px; margin-left:0.2em; border: 0px solid #bbb;"
 +
| style="border: 1px solid #bbb;" valign="top" |[[Fichier:tuneParameters.png|400px]]
 +
|}
 +
 
===Semaine5 (10/02-16/02)===
 
===Semaine5 (10/02-16/02)===
 +
====Damien====
 +
* Départition des pins de servo-moteur sur le shield
 +
[[Fichier:Map_servo.jpg|300px]]
 +
* Découpe des pales en caoutchouc
 +
* Trouver les bons paramètres acceptables pour la reconstruction
 +
[[Fichier:Param1 p13.jpg|700px]]
 +
 +
====Vincent====
 +
* Design des bielles pour la pale en caoutchouc
 +
* Code pour récupérer les images des deux camera en parallèle (multithread)
 +
 
===Semaine6 (17/02-23/02)===
 
===Semaine6 (17/02-23/02)===
−
===Vacances Hiver (24/02-01/03)===
+
 
 +
* Impression de 6 bielles
 +
* Premier test de fonctionnement avec un découpage de pâle en caoutchouc. Problèmes rencontrés:
 +
** Nous avons essayé de faire des bielles plus longues avec une fixation à la pâle à l'extrémité et au centre de la pâle pour la mieux maintenir mais ce n'était pas une bonne idée car cela laisse moins de jeu pour la pâle et demande plus de force au servo-moteur. Nous essayons alors avec seulement une fixation à l'extrémité de la pâle pour le moment.
 +
** Le caoutchouc étant épais, la force demandée au servo-moteur semble trop importante pour réaliser des amplitudes d'ondulation importante.
 +
 
 
===Semaine7 (02/03-08/03)===
 
===Semaine7 (02/03-08/03)===
 +
====Vincent====
 +
* Finir StereoVision:
 +
** Trouver la matrice Q avec une fonction dédiée -> ça marche pas la fonction plante -> Rentrer la matrice a la main (trouver la bonne?)
 +
** Recalibration des cameras -> il y a une camera plus lumineuse que d'autres, est-ce un problème??
 +
** Prendre images dans un cadre moins luminuex pour limiter la reflexion des object
 +
** Retrouver les bon parametres pour la fonction (Winsize,...)
 +
 +
* Recherche de solution pour le pilotage automatique (calcule de trajectoire): Une fois que l’environnement est appréhendé (StereoVision) il faut trouver la cible souhaiter et décider de la trajectoire a suivre pour s'y rendre. Solution envisagée:
 +
** Reconnaissance du milieu et construction d'une cartographie : algorithm FastSlam https://atsushisakai.github.io/PythonRobotics/#slam
 +
** Reconnaissance de la cible
 +
*** Par la couleur dans un premier temps (comme pour le tp d'IHM): On choisira un objet d'une couleur caracteristique (ex: vert). On calcule la moyenne de points qui ont une couleur comprise dans l'intervalle prédéfini pour isoler le centre de l'objet.
 +
*** Avec un algorithme de reconnaissance d'objet type machine learning (neuronal network/ Kmeans/ Support vector machines SVM) a definir plus precisement.
 +
** Calcule de trajectoire (https://atsushisakai.github.io/PythonRobotics/#path-planning)
 +
 +
====Damien====
 +
La semaine dernière j'ai remarqué que coller les bielles au support des servo-moteurs n'était pas très efficace car le caoutchouc applique une trop grand force lors des ondulations. Pour remédier à cela je suis partie dans l'après midi chercher du polyépoxyde pouvant subir une force de 130 kg/cm2 donc largement suffisant fixer les bielles aux servo-moteurs. Les bielles seront collées aujourd'hui et la semaine prochaine.
 +
=====Problématique=====
 +
Pour parer à la trop grand résistance des pâles en caoutchouc, 2 solutions étaient envisageable:
 +
* Changer de servo-moteur pour de plus puissant.
 +
* Réaliser des découpes dans les pâles pour les rendre plus souple. (Découpage intelligent ou mésostructure)
 +
Le problème de la première solution est qu'après avoir vu les servo-moteurs développant plus de couple, leur dimension étant plus grande nous aurions dû refaire tout le chassie avant de pouvoir tester cette solution. Donc une perte de temps, car la 2ème solution était directement faisable.
 +
=====Solution=====
 +
Dans un premier temps, j'ai envisagé plusieurs forme manière simple d'entailler le caoutchouc pour le rendre plus souple:
 +
* L'entailler sur la largeur: ceci permettrai de rendre la pâle plus souple sur la déformation des ondulations sans perdre la rigidité sur l'axe des appuis véhicule/sol.
 +
* L'entailler sur la longueur: non envisageable car l’opposé de la précédente donc inutile dans notre utilisation
 +
* L'entailler en diagonale: cela peut être combiné à la première proposition pour amélioré encore plus la souplesse du caoutchouc sur des ondulations si celle ci n'est pas suffisante avec seulement les entailles sur la largeur. Mais attention les entailles en diagonale vont aussi faire perdre de la rigidité au caoutchouc sur l'axe des appuis véhicule/sol.
 +
 +
J'ai alors réalisé 2 prototypes de pâles: une avec seulement des entailles sur la largeur et une avec des entailles sur la largeur et en diagonale.
 +
 +
[[Fichier:Modele pale 1.png|600px]]
 +
 
===Semaine8 (09/03-15/03)===
 
===Semaine8 (09/03-15/03)===
 +
====Vincent====
 +
* Définition de la structure général du programme pour une meilleur vue d'ensemble du projet:
 +
{| style="float: center; height: 200px; margin-left:0.2em; border: 0px solid #bbb;"
 +
| style="border: 1px solid #bbb;" valign="top" |[[Fichier:Trame_algo.jpg|400px]]
 +
|}
 +
 +
Au démarrage, l'utilisateur a le choix entre commande manuelle et automatique. Dans le cas d'une commande manuel, le programme lis en boucle les instruction de la télécommande sur le serveur web de la Raspberry et les envoie par liaison serie a la carte Arduino pour effectuer le déplacement(travail réalisé au S7). Pour le déplacement autonome, le robot va d'abord scanner son environnement en effectuant une acquisition avec le LIDAR et des cameras. Les données du LIDAR vont permettre de construire un cartographie de l’environnement qui permet au robot de savoir ou il se situe dans son environnement (travail a réaliser pendant les prochaines séances). L'image issue d'un camera va permettre de déterminer si la cible se situe dans l’environnement (visible par le robot) soit avec un simple filtre de couleur, soit avec un algorithme de reconnaissance d'objet (Machine learning). Si la cible n'est pas détectée, le robot se déplace et recommence l'acquisition. Si la cible est détectée, on utilise ici l’algorithme de Stereovision pour recuperer la distance a laquelle se trouve l'objet. On peut ensuite déterminer la trajectoire a suivre pour atteindre l'objet (algorithme a* ou autre) puis le robot se déplace jusqu’à atteindre sa cible.
 +
 +
* Recherches sur l'algorithme SLAM pour Générer une cartographie de l’environnement.
 +
 +
====Damien====
 +
Après réalisation des découpes des 2 pâles prototypes envisagés la semaine dernière, j'ai pu réaliser les testes d'ondulation sur le robot avec les nouvelles bielles imprimées il y a 2 semaines. Plusieurs remarques sont à dire de ce test:
 +
* La pâle avec les entailles sur la largeur et en diagonale possède une meilleur "ondulation".
 +
* Premier test avec les 12 servo-moteurs en action. Même avec les tous les servo-moteurs en position basse, le véhicule ne se soulève pas.
 +
* Les ondulations sont très approximatives car la déformation du caoutchouc au milieux de la pâle demande trop de force aux servo-moteurs en position 3 et 4 qui n'arrivent pas à réaliser une ondulation maximal contrairement aux servo-moteurs 1 et 6.
 +
 +
Solutions envisagées:
 +
* Au niveau du problème le plus contraignant, le fait que même tout les servo-moteurs n'arrivent pas à soulever le robot. Nous avons vu avec monsieur Dequidt, que pour nous n'avions pas le temps de changer les servo-moteurs, et que pour les tests nous allions porter le véhicule avec une structure ou avec un câble pour appliquer moins de force sur les servo-moteurs.
 +
* Pour les ondulations pour le moment approximatives, nous avons discuté de possible forme qui permettrons un meilleur mouvement entre chaque servo-moteur en retirant de la matière entre chaque servo ou en coupant carrément le lien entre chaque servo-moteur et partir sur un modèle de pagaie d'aviron. Un premier test avec de la matière retiré montre déjà un meilleur mouvement mais des tests supplémentaire doivent être effectués.
 +
 +
[[Fichier:Modele pale 2.jpg|600px]]
 +
 +
[[Fichier:Ondulation caoutchouc.gif]]
 +
 
===Semaine9 (16/03-22/03)===
 
===Semaine9 (16/03-22/03)===
 +
====Vincent====
 +
=====Fonctionnement du SLAM=====
 +
Si on connaît la position du robot, on peut calculer la carte a partir des donnée d’observation.
 +
Si on connaît la carte, on peut calculer la position du robot.
 +
Si on connaît ni l’un ni l’autre, on utilise SLAM (= Simultanous Localization And Mapping).
 +
 +
Approche probabiliste : permet de calculer : P(xt, m | zt-1, ut-1), cad la fonction de distribution de la position x et la map ma l’instant t sachant l’observation z et la commande u a l’intant t-1.
 +
{| style="float: center; height: 200px; margin-left:0.2em; border: 0px solid #bbb;"
 +
| style="border: 1px solid #bbb;" valign="top" |[[Fichier:explicationSLAM.png|600px]]
 +
|}
 +
 +
Pour calculer cette fonction de probabilité, on utilise un filtre de Bayes et plus précieusement un EKF (Extended Kalman Filter) qui permet d’obtenir un résultat même pour des distribution non linéaires.
 +
Fonctionnement  EKF SLAM : 2 étapes → Prediction et Correction
 +
Source:https://www.youtube.com/watch?v=U6vr3iNrwRA&list=PLgnQpQtFTOGQrZ4O5QzbIHgl3b1JHimN_
 +
 +
=====Travail effectue=====
 +
* J'ai fixé le LIDAR sur le robot réalisé lors du BE PEIP pour pouvoir tester le programme sur quelque chose de mobile.
 +
{| style="float: center; height: 200px; margin-left:0.2em; border: 0px solid #bbb;"
 +
| style="border: 1px solid #bbb;" valign="top" |[[Fichier:robotPEIP.jpg|300px]]
 +
|}
 +
PythonRobotics propose un code tout fait du SLAM basé sur un "Motion modèle" de type "Velocity". Un problème se pose: sur le robot, il n'y a aucun moyen de mesurer le déplacement réel car pas d'accelerometre ni de capteur optique sur les roues. En attendant de pouvoir commander un accelerometre (confinement), il faut donc adapter le code récupéré pour pouvoir rentrer a la main le déplacement effectué par le robot et ainsi tester le bon fonctionnement du programme (suite la semaine prochaine)
 +
* Il y a apparemment un moyen de faire tourner le SLAM sans odométrie : Google cartographer: https://google-cartographer-ros.readthedocs.io/en/latest/
 +
Je n'arrive pas a installer ROS (supporte jusqu’à Ubuntu 16) sur ma machine (Ubuntu 18...). Je n'ai pas penser a prendre ma Raspberry pour essayer dessus. Suite la semaine prochaine.
 +
 +
====Damien====
 +
Les résultats obtenus lors de cette semaine ont déjà été décrits sur la semaine précédente pour avoir une rédaction unique.
 +
 
===Semaine10 (23/03-29/03)===
 
===Semaine10 (23/03-29/03)===
 +
====Vincent====
 +
* Installation ROS pour tester Google Cartographer: il suffisait de suivre https://www.theconstructsim.com/how-to-install-ros-on-ubuntu/
 +
* Compiler ROS Cartographer https://google-cartographer-ros.readthedocs.io/en/latest/compilation.html
 +
* Essaie avec des donnée trouvées sur internet: https://google-cartographer-ros.readthedocs.io/en/latest/demos.html OK çà fonctionne
 +
* Essaie avec le rpLIDAR en direct: https://www.youtube.com/watch?v=qNdcXUEF7KU
 +
Pour cela, on installe les packets RPLIDAR_ROS : https://github.com/Slamtec/rplidar_ros
 +
Ça ne marche pas: le LIDAR se lance bien mais le Cartographer n'a pas l'air d'avoir accès aux données. Pourtant le LIDAR fonctionne bien:
 +
{| style="float: center; height: 100px; margin-left:0.2em; border: 0px solid #bbb;"
 +
| style="border: 1px solid #bbb;" valign="top" |[[Fichier:EssaiLIDAR.png|300px]]
 +
|}
 +
* https://github.com/NickL77/RPLidar_Hector_SLAM ne marche pas nous plus
 +
Manque de tuto sur le sujet...
 +
* Autre approche: On enregistre au préalable les donnes du LIDAR dans un fichier.bag puis on lance le Cartographer avec ces données.
 +
Pour enregistrer: http://wiki.ros.org/rosbag/Tutorials/Recording%20and%20playing%20back%20data
 +
Pas plus de succes...
 +
 +
* Changement de tactique: on oublie ROS(qui a l'air de bien faire rire Mr Boe) et on se base sur le code de PythonRobotics:https://github.com/AtsushiSakai/PythonRobotics/tree/master/SLAM
 +
On intègre le code du LIDAR pour recuperer les points et on rentre la position du robot a la main.
 +
 
===Semaine11 (30/03-05/04)===
 
===Semaine11 (30/03-05/04)===
 +
====Vincent, toujours sur le SLAM====
 +
* Les données du LIDAR sont stockées sous forme d'un vecteur (360*1). L'indice i correspond a l'angle de la mesure du lidar (dans son repère, cf schéma ci-dessous). A chaque angle, on associe une distance mesurée. L'acquisition d'un scan se fait sur une dizaine de tour du moteur pour être sur d'avoir une bonne valeur par angle. Toutes les fonctions nécessaire pour faire fonctionner le LIDAR sont dans le fichier /Mapping/lidar.py.
 +
* J'ai repris le code du FastSlam2 proposé par pythonRobotics (https://github.com/AtsushiSakai/PythonRobotics/tree/master/SLAM/FastSLAM2):
 +
** Adaptation de la fonction observation() pour recuperer les données du LIDAR.
 +
** Comme on a aucun système d’odométrie, on test sur une ligne droite en prenant des mesure toute les 0,5m (cad a chaque repère au sol)
 +
{| style="float: center; height: 100px; margin-left:0.2em; border: 0px solid #bbb;"
 +
| style="border: 1px solid #bbb;" valign="top" |[[Fichier:EssaiSLAM.jpg|300px]]
 +
|}
 +
** Problèmes rencontres dans la fonction update_with_observation(): Le code fournie est en réalité une simulation qui tourne avec une liste prédéfinie de Landmarks (repérés par un lm_id). Or dans notre cas, on ne sais pas quel mesure correspond a quel Landmark lorsqu'on scan l’environnement. Il faudrait associer chaque mesure du LIDAR a un Landmark par calcul trigonométrique.
 +
* Il s’avère qu'il y a un moyen de se baser que sur les données du LIDAR sans associer un Landmark particulier: https://github.com/simondlevy/BreezySLAM.
 +
Ce gentil monsieur propose même un programme compatible avec notre LIDAR (rplidar A1) et en plus sans odométrie. C'est un miracle...
 +
Comme en témoigne ces images de mon espace de confinement, ca marche!
 +
{| style="float: center; height: 100px; margin-left:0.2em; border: 0px solid #bbb;"
 +
| style="border: 1px solid #bbb;" valign="top" |[[Fichier:EssaiSLAM2.png|500px]]
 +
|}
 +
====Damien====
 +
Après 2 semaines d'acharnement sur la conception des pâles. J'ai réalisé un nouvelle algorithme pour essayer de faire avancer le robot différemment. Le code réalisé lors du S6 et S7 faisait que les servo-moteurs tournés indépendamment des autres. Les servos étaient conditionnés a une initialisation en position puis un déplacement pas à pas de chaque servo dans un direction programmé. Le problème de cette méthode est que l'ondulation correspond au mouvement d'une onde stationnaire. Ceci est excrément compromettant car une onde stationnaire ne permettra jamais au robot de ce déplacement, il fera seulement du sur-place. J'ai alors réalisé une nouvelle fonction de mouvement des servo-moteur.
 +
=====Nouvelle Fonction=====
 +
Cette nouvelle fonction à pour premier principe de ne faire tourner qu'un seul servo-moteur par pâle via les paramètres globaux (inclinaison max, inclinaison initial, pas, sens de rotation). Maintenant, le reste des servos vont recopier le mouvement du servo le précédent. Avec cela nous avons alors bien un sens d'ondulation. Le problème c'est que nous ne voulons pas recopier la position du servo précédent mais une position plus ancienne pour avoir un retard plus important et donc en fonction du retard apporté nous allons obtenir des ondulations différentes.
 +
 +
[[Fichier:Ondulation retardee.gif]]
 +
 +
Maintenant avec ce mouvement nous allons essayer de faire déplacer le robot. Dans un premier temps pour avoir une meilleur impulsion sur le robot nous allons faire en sorte que l'ondulation ne soit pas continu et de marquer un temps d’arrêt faible après chaque ondulation. Après avoir trouver des premiers paramètre nous arrivons à avoir un léger déplacement du robot. Le déplacement est excrément lent et le robot nécessite une aide pour soulever son poids mais cela reste une grand avancée.
 +
 +
[[Fichier:Deplacement1.mp4|600px]]
 +
 
===Semaine12 (06/04-12/04)===
 
===Semaine12 (06/04-12/04)===
−
===Vacances Pâque (13/04-26/04)===
+
====Vincent====
−
===Semaine13 (27/04-03/05)===
+
* Stereo vision: nouvel essai avec une seul camera pour voir si le problème viens du matériel:
−
===Semaine14 (04/05-10/05)===
+
** Capture des images droites et gauches avec une seul camera (celle de droite) et espaçant les deux prises de 10cm et en essayant de garder la même inclinaison.
−
Soutenances
+
** Recalibration de la camera utilisée (pour être sure).
 +
** Calibration des paramètres de StereoSGBM: resultats toujours pas exploitables...
 +
* SLAM: Trouver comment combiner les données de la carte et la positon de l'objet pour planifier la trajectoire du robot.
 +
* Target detection: code détection de cible par la couleur:
 +
{| style="float: center; height: 100px; margin-left:0.2em; border: 0px solid #bbb;"
 +
| style="border: 1px solid #bbb;" valign="top" |[[Fichier:Target.png|500px]]
 +
|}
 +
Pas le temps pour faire algo machine Learning
 +
 
  
 
===Documents Rendus===
 
===Documents Rendus===
 +
 +
*Rapport: [[Fichier:P13_Rapport-S8.pdf]]
 +
*Support soutenance: [[Fichier:P13_Soutenance-S8.pdf]]
 +
*Codes: https://github.com/vincentduboisdlc/P13.git

Version actuelle datée du 1 mai 2020 à 16:39


Vidéo HD

Sommaire


Présentation générale

Description

Sur le marché actuel, on trouve très peu de robots amphibies. En effet, les systèmes de propulsion traditionnellement utilisés ne sont pas adaptés pour fonctionner dans différents environnements. Cependant, de nouvelles techniques voient le jour notamment grâce à l’émergence de la robotique molle (Soft Robotic). Ce nouveau domaine s'inspire fortement de la manière dont les organismes vivants se déplacent et s’adaptent à leur milieu. L'un des objectifs de la robotique déformable est notamment d’accroître la mobilité des systèmes en utilisant des matériaux hautement déformables.

Ce projet consiste donc en la réalisation d'un robot amphibie pouvant se déplacer aussi bien sur la terre ferme qu'en milieu aquatique. Pour ce faire, nous nous inspirons du déplacement de la raie et du serpents. Ces deux animaux se déplacent par ondulation (verticale pour la raie et horizontale pour le serpent). Le robot sera donc munie de deux nageoires ondulantes dont on peut changer l'inclinaison afin de s'adapter a son environnement.

Objectifs

L'objectif est dans un premier temps de concevoir le système de propulsion a l'aide de matériaux déformables. Le mouvement des nageoires sera sinusoïdale contrairement a la raie dont le mouvement serai trop complexe a reproduire étant donne le temps consacré au projet. Le contrôle du robot se fera en boucle fermé donc de manière autonome.

Dans sa globalité, le projet comprend:

-la conception du système de propulsion par ondulation

-la fabrication de l'enveloppe hermétique

-la conception de la carte électronique

-l’intégration des différents capteur nécessaires au fonctionnement autonome

-le développement du programme de navigation (avec reconnaissance du milieu?)

Analyse du projet

Positionnement par rapport à l'existant

Analyse du premier concurrent

Salamandra robotica II (École polytechnique fédérale de Lausanne)


Salamandra robotica II.jpg Salamandra robotica II2.jpg


Ses concepteurs se sont inspiré de la salamandre pour fabriquer un robot amphibie capable d’évoluer dans l'eau comme sur terre. Cet amphibien utilise deux modes de locomotion différents en fonction du milieu dans lequel il se trouve. Dans l'eau, son corps ondule: l'animal nage alors à la manière d'une anguille. En revanche, il utilise ses pattes pour se mouvoir sur la terre ferme.

Le robot se compose de dix modules articulés pouvant réaliser des mouvements latéraux. Les neuf premiers ont une forme rectangulaire et intègrent des circuits électriques et des microcontrôleurs. Quant au dernier, il ressemble à une palette natatoire. Les modules 3 et 6 sont en plus équipés d'une paire de pattes repliables.

Les mouvements sont donc coordonnés par un ordinateur principal faisant tourner la modélisation du réseau neuronal des salamandres. Une simple commande pouvant être émise à distance suffit pour changer le mode de locomotion du robot. La vitesse de nage comme sa direction sont également gérées par l'ordinateur central.

Analyse du second concurrent

Velox (PLIANT ENERGY SYSTEMS llC) https://www.pliantenergy.com/

Pliant energy robot.jpg Pliant energy robot2.jpg Pliant energy robot3.jpg

Le robot Velox cumule plusieurs modes de locomotion empruntés au monde du vivant. Équipé d’une seule paire d’ailettes latérales souples qui changent de position selon l’environnement, l’engin est capable « de nager comme une raie, de ramper comme un mille-pattes, de jaillir comme un calamar et de glisser comme un serpent ».

Le secret de ses déplacements réside dans ses appendices ondulatoires. Lorsqu’ils sont alignés à l’horizontale, la machine peut se déplacer sous l’eau. En mode tout-terrain, ses ailettes se positionnent perpendiculairement au sol pour ramper, par exemple, sur des sables mouvants. Ses pédicules caoutchouteux lui permettent également de patiner sur la glace et de slalomer entre les obstacles sur la neige.

Ce robot n’est pour l’instant qu’un prototype mais intéresserait cependant le bureau de la recherche navale américaine pour ravitailler en armes et en matériel des troupes lors d’un débarquement.

Scénario d'usage du produit ou du concept envisagé

Le robot est capable de détecter la nature de son milieu et d'adapter l'inclinaison de ses nageoires en fonction. Il peut donc évoluer dans des milieux complexes et variés tel que des zones sinistrées, inondées, marécageuses, sableuses, aquatiques,... L'avantage qu'il possède, comparé au véhicules traditionnels, est son changement de locomotion rapide en cours de déplacement. En fonction de l'objectif de sa mission, le robot se déplace de manière autonome jusqu’à atteindre sa cible ou peut être piloté manuellement par un utilisateur. Du fait de ses propriétés, il peut servir dans les scénario suivants:

  • Reconnaissance et recherche de survivants suite à un tremblement de terre.
  • Navigation dans des zones marécageuse/sable mouvants.
  • Reconnaissance dans conduite d'eau
  • Exploration de fonds marins (Résistant à l'enchevêtrement dans les plantes ou autres débris aquatiques).

Réponse à la question difficile

Bibliographie et webographie

  • Magazine Pour La Science n 402 p66 "Onduler pour avancer"

Préparation du projet

Cahier des charges du groupe

Cahier des charges des équipes

Equipe 1

Damien Tillaux & Vincent Dubois

  • Propulsion:

Le robot est doté de deux nageoires artificielles ondulantes de chaque côté de son châssis. On utilise des servomoteurs alignés pour donner le mouvement d’ondulation aux pales. Le nombre de servomoteurs est défini en fonction de la longueur de la pale, de l’amplitude des ondulations ainsi que du nombre de points d’appuis au sol souhaités. Concernant ce dernier points, nous avons fixé à 2 le nombre d’appuis au sol de chaque côté du robot afin que le dispositif soit stable. La jonction entre la nageoire et les servomoteurs se fait via une bielle. La nageoire doit être assez déformable pour pouvoir supporter l’ondulation imposée par les servomoteurs et doit être assez rigide pour supporter le points du bobot. De plus, le matériaux utilisé doit avoir une certaine rugosité pour pouvoir adhérer au sol et permettre au robot d’avancer correctement.

La solution moteur+arbre est d’emblée éliminé car trop compliquée a mettre en place étant donne nos faibles connaissances en mécanique. De plus, la consommation en énergie des servomoteurs est bien moindre comparée a un moteur(DC).

  • Chassie:

Le châssis du robot doit pouvoir accueillir les servomoteurs nécessaires à la propulsions ainsi que la carte électronique, le système d’alimentation (batterie) et les différents capteurs inhérents au fonctionnement autonome du robot. Les dimensions du châssis sont fixées notamment par le nombre de servomoteurs utilisés et par la taille des autres composants électronique. Afin de limiter le poids total de la structure nous utilisons l’impression 3D qui permet de fabriquer des objets à la fois creux et résistants. Enfin, l’appareil étant amené à se déplacer dans l'eau, le chassie doit donc être étanche. Étant donnée que le projet porte en premier lieu sur les compétences IMA, l’étanchéité du robot fera l'objet d'une étude secondaire avec l'aide d'étudiants en Conception Mécanique.

  • Contrôle:

Le dispositif a pour but final d'être complètement autonome. Pour cela nous implémentons un algorithme qui permet de reconnaître son milieu et d’adapter son déplacement en fonction. Pour ce faire, le robot doit intégrer des détecteurs d'obstacles ainsi qu’un système permettant la reconnaissance de milieu aquatique. L'appareil doit également être télécommandable pour que l'utilisateur puisse prendre la main sur son déplacement. Nous proposons pour cela d’intégrer une télécommande infrarouge au projet ainsi qu'une caméra.

Equipe 2

Eric Agbodjan

L'avantage de fabriquer sa propre carte électronique est de pouvoir utiliser uniquement les entrées/sorties du microprocesseur dont on a besoin et de ne pas surcharger la carte de fonctions inutiles au projet . De plus, cela nous permet d’adapter la disposition des pins de connexion des servomoteurs et des différents capteurs et donc de gagner énormément de place. La principale contrainte pour cette carte est que le microprocesseur utilisé doit pouvoir générer assez de signaux PWM pour accueillir au moins 10 servomoteurs. De plus, la carte doit pouvoir adapter la tension d’alimentation de la batterie aux différents besoins des composants.

Choix techniques : matériel et logiciel

Equipe 1

  • Servomoteurs:

Nous avons tout d’abord commencé par réfléchir au nombre optimal de servomoteurs pour avoir un appuis stable avec le sol lorsque la pale est à l'horizontale. Etant donné sa forme ondulée, il faut au moins deux points d’appuis de chaque côté pour assurer la stabilité. On en a donc conclu qu’il fallait au moins 5 servomoteurs de chaque côté:

Schema stabilite.png

Pour limiter la longueur du robot nous avons cherché des modèles de servomoteur de petites tailles toute en faisant un compromis sur le couple développé par ce dernier. Le SG90 est le modèle le plus facile à trouver et aussi celui que nous avions sous la main.

estimation de la masse total du robot ~ 0,5kg.

Tableau des masses
Masse (kg) Quantité Total
PCB 0,03 1 0,03
Batterie 0,2 1 0,2
SG90 0,009 10 0,09
Boitier 0,2 1 0,2
Pales 0,01 2 0,02
Capteurs 0,005 1 0,005
0,54


D’après sa datsheet, le SG90 peut développer un couple de 1800g/cm:

Sg90.jpg SG90specifications.png

Dans le cas le plus défavorable le poids est repartie sur 4 points d'appuie (125g chacun).

Schema couple.png

On a donc un couple appliqué sur chaque servomoteur C = 125xL g.cm On calcule une largeur de pale L = 1800/125 = 14,4 cm maximal pour ne pas dépasser le couple max développé par les SG90. Etant donné l'estimation de la taille du châssis (~300mm*200mm), la largeur max de nageoire calculée est largement supérieur a l'estimation faite en amont. Validation du choix du servomoteur.

Par la suite nous avons remarque que ce modèle n’était pas viable (voir semaine bonus dans la suite du wiki)

  • Nageoire:

Le caoutchouc est un matériaux déformable et rugueux et paraît être parfaitement adapté à notre problème. De plus, ce matériaux est facile a découper (manuellement/découpe laser). Le positionnement et les dimensions de la pale seront déterminé de manière expérimentale. Nous avons pensé a plusieurs solutions: la première consiste a placer la nageoire de manière longitudinale dans l'axe des bielles. De ce fait, le mouvement d'ondulation suit parfaitement le mouvement des servomoteurs. La deuxième solution est donner une forme ondulée aux nageoires; c'est a dire que lorsque les bielle sont toutes alignées sur le même plan, la nageoire est deja ondulée. Enfin on peut egalemment decouper les pales de maniere incurvee afin que la pale soit ondulee a l'exterieur et non au niveau de la fixation des bielles. Le dimensionnement des nageoires dépend donc de la configuration choisie. A l’issue des ses expérimentations, nous pourrons définitivement valider le choix du matériau et nous concentrer davantage sur le contrôle du robot. Le seul inconvénient que nous avons anticipé avec le caoutchouc est qu'il a une masse volumique importante et donc demande plus de puissance au servomoteurs lors du délassement. Pour palier à ce problème, nous avons pensé à l'impression 3D avec un matériau déformable tel que le TPU (polyuréthane thermoplastique). L’intérieur de la nageoire serait donc remplie sous forme de mésostructure a la fois rigide, déformable et de faible masse. (logiciel ICE SL)

  • Contrôle:
    • Détection d'obstacles:

Les capteurs ultrasons généralement vendus avec les cartes Arduino permettent de mesurer une distance et sont souvent utilisés pour la détection d'obstacle. Cependant, d’après notre expérience personnelle, leur fonctionnement ainsi que la précisions des mesures sont douteux. Les capteurs de distance infrarouges paressent être une alternative plus fiable(https://www.phidgets.com/?tier=3&catid=5&pcid=3&prodid=396). Deux capteurs seront disposés a l'avant du robot et seront inclines l'un par rapport a l'autre afin de couvrir un angle plus important. Meme si théoriquement le robot est capable d'effectue une marche arrière, nous n'avons pas juge nécessaire de positionner un autre capteur a l’arrière du châssis.

    • Détection milieux aquatique:

Nous avons d'abord pense a un capteur d’humidité. Cependant la mesure du taux d’humidité ne caractérisé pas si on est dans un milieu aquatique ou non: on peut par exemple avoir un taux de 100% dans l'air. Il a donc fallu trouver un système tout ou rien pour détecter la présence d'eau. Pour cela, on place deux électrode a l’extérieur du châssis et on applique une tension sur l'une des deux. Si le robot est bel et bien dans l'eau, on peut détecter une tension sur la deuxième électrode.

Test detection eau.jpg
    • Pilotage manuel ou autonome:

Afin de prendre le contrôle manuellement sur le robot nous avons décidé de fabriquer une télécommande infrarouge capable de communiquer avec la carte électronique. Pour cela nous souhaitons concevoir entièrement une carte électronique permettant à l’utilisateur de diriger le robot, d’adapter sa vitesse et de changer l’inclinaison des pales. Néanmoins, l’utilisateur doit pouvoir se rendre compte de l'environnement qui entoure l’appareil. C’est pourquoi nous avons décidé d'intégrer une caméra au robot. Du fait que récupération des images de la caméra à distance est impossible à mettre en oeuvre avec une simple carte basée sur l'ATmega, on utilise une carte Raspberry Pi capable d’interagir avec un ordinateur via le réseau wifi. L’objectif final du projet est que l’appareil soit totalement autonome et qu’il accomplisse seul la mission pour laquelle il est programmé. En fonction du cas d’utilisation, nous aimerions développer un algorithm de reconnaissance d’objet permettant au robot de détecter la cible qu’il doit atteindre sans intervention humaine.

Equipe 2

Réalisation du PCB:

matériel a intégrer : - 12 servomoteurs (type : SG90) - 2 TSOP - 2 capteurs de distance IR - Capteur d’humidité - Bouton reset - led de contrôle - Communication USB ( microprocesseur FT232R ) - programmateur ( prog spi avr)


Nous avons choisi de prendre un microcontroleur atmega2560 pour effectuer notre carte programmable. Ce microprocesseur possède 16 broches PWM ( 12 seront utilisés pour le servomoteurs). Ceci est un avanatge car le robot va devoir porter le chassis donc cela va permettre d'aléger de quelques grammes les palmes.

Le bouton va permettre de rénitialiser la carte s'il y a un problème dessus.

Les leds de controles vont être très utiles car avec ça, nous allons pouvoir repérer les éventuelles problèmes d'alimentation.

Le capteur infrarouge va nous permettre de télécommander le robot via une télécommande.

La carte raspberry pi zéro va servir pour la caméra car nous ne pouvons pas brancher directement la caméra à un arduino. Nous avons choisi cette car elle est petite, pas cher et assez puissante pour faire fonctionner une caméra.

Niveau logiciel, j'ai choisi d'utiliser Altium Designer car on va l'utiliser tout au long du cursus.

Liste des tâches à effectuer

Equipe 1

  • 1.1 Choix des capteurs/servomoteurs.
  • 1.2 Premier prototype de châssis (un seul cote = 5 servomoteurs).
  • 1.3 Algorithme de déplacement (avec 5 servomoteurs seulement).
  • 1.4 Design des nageoires.
  • 1.5 Tests et ajustements algorithme/pale avec 5 servomoteur.
  • 1.6 Conception et impression du châssis final.
  • 1.7 Algorithme de déplacement complet (10 servomoteurs).
  • 1.8 Télécommande IR.
  • 1.9 Camera + RaspberryPi.
  • 1.10 Algorithme de pilotage automatique avec intégration des capteurs.
  • 1.11 Châssis étanche.

Equipe 2

  • 2.1 Recherche sur les différents composants (descriptions des pins, alimentation,...)
  • 2.2 Conception du schéma électrique du circuit
  • 2.3 Routage du PCB
  • 2.4 Impression et implantation des composants
  • 2.5 Tests
  • 2.6 Choix de la batterie adaptée

Calendrier prévisionnel

Planningp13.png

Réalisation du Projet

Projet S6

Semaine 4

Lors de la séance du 12/02, nous avons défini un premier jet du cahier des charges. En fonction des éléments que nous voulons inclure sur le véhicule, nous avons mis en prévision un masse total des composants (environ 500 gramme).

Pour la méthode de déplacement, nous avons décidé d'utiliser des servomoteurs mais nous devons définir le nombre à inclure sur le robot. Le nombre de servomoteur sera défini à partir de la masse qu'ils devront soulevé en fonction de la longueur des pâles. Nous sommes allé voir M Astori pour savoir si l'idée de mettre 5 servomoteurs de chaque côté était envisageable. Après étude du caractéristique couple/distance de l'arbre des servomoteurs SG90, nous devrions pourvoir réussir à soulever cette masse sans problème. Théoriquement, avec un SG90 qui a un couple de 1.8kg.cm, quand nous sommes au point critique de, donc 4 appuis, chaque servomoteur devra soulever une masse de 125 gramme. Si nous considérons la masse réparti équitablement, avec cette configuration, les pales devrons, au maximum être d'une largeur de 14.4 cm. Toutes ses informations seront retranscrites dans les choix techniques.

Semaine 5

Cette séance était très fortement consacrée à un brainstrorming du groupe de projet pour savoir qu'elle serait les choix techniques au niveau matériel.

  • servomoteurs: nous partons sur un model de servomoteur FS90. Ce sont les sevomoteur plus basique que les SG90
  • chassi: nous partons dans un premier temps sur la conception d'une moitiée latérale du chassi pour les premiers test à effectuer
  • pale du véhicule imprimé par imprimante 3D, avec une structure souple permettant son ondulation.
  • capteurs utilisés: au niveaux des capteurs à utiliser nous sommes parti sur une liste simple qui pourra être modifié par la suite
    • tsop et led infra-rouge pour une communication infra-rouge
    • 3 sonnar à l'avant du véhicule pour repérer les obstacles en mode autonome
    • une rasberry Pi pour une communication direct avec l'utilisateur s'il veut passer en mode télécommandé

Semaine 6

La séance fut principalement réservée pour la remplissage du wiki: rédaction propre du cahier des charges et définitions des taches. Début de conceptions d'un premier prototype de chassie (finis a la maison)

Semaine 7

Equipe 1:

Durant cette séance, nous avons commencé à programmer les servomoteurs pour avoir une base pour les premiers tests lorsque le chassis sera imprimé.

Pour le chassis, un modèle 3D à été fait est devrait être imprimé pour la semaine prochaine.

Modification des choix techniques: nous avons décidé de changer les sonars par des détecteurs de distance infra-rouge. Ce changement est dû à la différence d'efficacité entre les 2 composants. Les détecteurs infra-rouge on une meilleure précision et un meilleur fonctionnement.

Equipe 2:

Pendant la séance j'ai effectué des recherches sur le branchement des différents composants ( capteurs de distances, servomoteurs ...) sur l'arduino afin de réaliser le schéma électrique.

Semaine 8

Equipe 1:

Impression du premier châssis et premiers test avec les servomoteur.

Test1 P13.gif

Equipe 2:

J'ai effectué la réalisation du PCB (schéma électrique) sur Altium. J'attends la validation de M.Boé pour passer au routage et voir les éventuelles modifications à effectuer.

Semaine 9

Equipe 1:

Adaptation du code pour faire des ondulations. Dimensionnent théoriques des nageoires et des bielles. Commande des feuilles de caoutchouc.

Equipe 2:

Modification du schéma électrique

Recherche pour créer un régulateur 6V pour les servomoteurs

Semaine 10

Equipe 1:

Nous avons finis le design des bielles en fonction de l’épaisseur du caoutchouc et de l'amplitude du mouvement. En attente des feuilles de caoutchouc pour découper les nageoires et effectuer les premiers tests.

Equipe 2:

En attente de validation du shematic. Recherche pour la batterie: nous partons sur une 'Powerbank' de 5V donc plus besoin de régulateur. Recherches sur consommation total du système.

Semaine 11

Equipe 1:

A Défaut d'avoir reçu le caoutchouc, nous commençons la modélisation d'un deuxième prototype de châssis permettant d’intégrer les 10 servomoteurs ainsi que les capteurs. Réflexion sur l'algorithme de déplacement: nous avons décidé de ne plus utiliser l’environnement Arduino IDE et de programmer directement en C d'utiliser le compilateur AVR prévu a cet effet.

Réflexion de groupe sur le dimensionnement du PCB et la dispositions de des différents éléments.

Equipe 2:

Semaine 12

Equipe 1:

Changement de stratégie concernant la détection du milieux aquatique: capteur d’humidité inappropriée. Nous partons sur une solution beaucoup plus simple: on détecte une tension si l'eau fait le lien entre deux électrodes. Conception et modélisation du châssis. Premiers tests d'ondulation avec du lino a la place du caoutchouc afin de mieux comprendre le comportement des nageoires.

Equipe 2:

Finition du shematic.

Commencement du routage.( ils manquent 2 capcacités de découplages)

Capture1.png C2.png

Semaine bonus

Equipe 1:

  • 1er test avec une seul nageoire: la pale est ondulée et décrit un arc de cercle parfait entre chaque servomoteur. Deux problèmes se posent lors de ce test. Le premier concerne la nageoire: la forme de la pale impose trop de contrainte au servomoteurs et le matériau (lino) est trop déformable donc on ne retrouve pas le mouvement d'ondulation commandé par les servomoteurs. Le deuxième problème provient de la bielle qui lie l'arbre des servomoteurs a la nageoire. Nous n'avons pas réussi a reproduire les stries permettant de maintenir la bien en phase avec la tete du servomoteur du coup cette dernière tourne parfois dans le vide. Nous avons donc conçue une nouvelle bielle qui vient se colle directement sur la bielle fournie avec le servomoteur.
Bielle1.png Bielle2.1.png Bielle2.2.jpg
  • 2e test avec une seul nageoire: cette fois si on redimensionne la pale avec une forme ondulée mois prononcée que précédemment. On se fixe une amplitude du mouvement des servomoteurs a 20deg et on calcule la longueur nécessaire de la pale entre chaque bielle.

Test2.1.gif

On se rend compte que l’algorithme d'ondulation comme nous l'avions implémenté ne permet pas de faire onduler la nageoire. En effet, l'algorithme était prévue pour alterner entre 2 et 3 points d'appuis au sol afin de garder une certaine stabilité. Ce modèle fonctionnerait potentiellement si on augmentait la distance entres les servomoteurs. Nous somme donc passé sur un deuxième modèle a 6 servomoteurs même si le châssis ne peut en accueillir que 5. Dans ce cas les servomoteur son deux a deux en phase se qui permet d'avoir 2 points d'appuis au sol en permanence.

Test2.2.gif

  • Impression du châssis final en deux parties pour pouvoir faire des test de déplacement avec les 2 nageoires.

Problèmes d'impressions de la partie avant mais pas dérangeant pour faire les tests.

  • Test avec les deux nageoires sur le châssis final:

Test.gif

En plaçant les nageoire a la verticale on constate que le robot n'avance toujours pas. Cela vient surement du fait que le lino est trop flexible pour supporter le poids total du robot et n’adhère pas assez au sol (ce qui aurait surement été différent avec du caoutchouc

Test vertical.gif

  • Test avec nageoire incurvée
Incurve.jpg

L'angle choisi est trop important donc l'ondulation impose trop de contraintes mécaniques aux servomoteurs. Test non concluant: réessayer avec un plus petit angle.

Equipe 2:

Documents Rendus

Projet S7

Redéfinition des objectifs

  • Finir la partie mécanique
    • Ajout d'un 6ème servomoteur par côté
    • Impression d'un châssis plus adapté aux tests
    • Test des pâles en caoutchouc
  • Réalisation de la commande du déplacement du robot
    • Commande manuelle/autonome: récupération des données des donné (caméra + LIDAR), traitement par un ordinateur de controle (algorithme de machine learning ou commande manuelle)et envoi des ordres de direction a la carte de commande du robot.
  • Rendre le robot indépendant énergiquement: batterie et commande sans fil (Semestre 8)

Nouveaux choix techniques

  • Servomoteurs : Le type de servomoteur reste le même (SG90) sauf dans le cas ou la nageoire en caoutchouc engendre trop de frottements avec le sol et donc demande plus de puissance. Cependant, comme expliqué dans le compte rendu du S6, l'algorithme de propulsion change: on passe à un modèle à 6 servomoteurs de chaque côté du robot.
  • Nageoires : L'idée des nageoires en caoutchouc reste valable. Il s'agit désormais de mettre en pratique cette idée en découpant les nageoires dans des feuilles de caoutchouc. Concernant la forme de ces dernières, les différentes géométries vue au S6 seront reproduite avec le nouveau matériaux pour en tirer la meilleur. Nous avons également pensé, dans le cas ou la rigidité du caoutchouc serait insuffisante, a utiliser des feuilles d'aluminium pour le design des pales.
  • Contrôle :
    • Contrôle de la propulsion : Une première carte électronique de contrôle type Arduino (avec shield ou non) permet de gérer les 12 servomoteurs et ainsi de contrôler le déplacement du robot.
    • Détection de milieux extérieurs : Pour la détection d'obstacle, on garde toujours les 2 sonars qui donnent une première idée de la distance aux obstacles de l’environnement extérieur. On utilise deux caméras (webcams) pour mieux rendre compte de l’environnement extérieur. La combinaison des deux images permettra de donner une notion de profondeur que l'on pourra étalonner avec un LIDAR 2D. L'acquisition des donnés sera géré par une deuxième carte électronique (type Raspberry Pi). Il reste a définir si les informations seront envoyé a un ordinateur de contrôle pour être traiter ou si la Raspberry est assez puissante pour traiter l'image par elle même.
    • Pilotage manuel : Il sera possible de piloter le robot grâce une télécommande (sur la Raspberry en point d'accès)
    • Pilotage autonome : Création d'un algorithme de machine learning permettant au poste de contrôle (ou Raspberry) de faire ses propres choix de déplacement pour trouver et suivre une cible.

Liste des tâches à effectuer

  • Impression/découpe d'un nouveau modèle de châssis.
  • Découpe des pales en caoutchouc.
  • Firmware de contrôle sur Arduino (avec réception des commandes via liaison série).
  • Conception d'un Shield Arduino pour faciliter la connectique
  • Configuration de la carte d'acquisition (configuration en point d'accès)
  • Création d'une télécommande sur la RaspberryPI et envoie des information à Arduino via liaison série
  • Choix du LIDAR et caméras.
  • Code d'acquisition des Images/données.
  • Algorithme de traitement des données et pilotage automatique (Machine Learning)

Semaine 1 (07/11/2019 - 14/11/2019)

  • Redéfinition du cahier des charges et des taches
  • Réunion de validation du projet avec les enseignants
  • début configuration Raspberry Pi
  • Réalisation des modèle 3D du châssis

Semaine 2 (14/11/2019 - 21/11/2019)

  • Configuration Raspberry Pi en point d’accès

Semaine 3 (21/11/2019 - 28/11/2019)

  • Choix camera/Lidar : Trouver un capteur permettant améliorer la vision du robot (en complément de la caméra). Solutions envisagées:
    • Caméra 3D : trop chère + trop d'information à traiter pour la Raspberry. Il aurait fallu réduire la résolution de l'image ou ne prendre que quelques images par secondes.
    • Lidar 3D + camera : Trop chère + Le temps de balayage du lidar est trop long. Le Lidar 3D utilise 2 moteur pour diriger le laser sur 2 axes. La fréquence de fonctionnement du Lidar est trop faible comparé a la caméra. On aurait donc eu un décalage entre l'information donné par le Lidar et celle donné par la Caméra.
    • Lidar 2D + 2 cameras : Les deux caméras espacées de quelques cm permettent d'avoir une vision en 3D. On choisi délibérément une faible résolution pour les camera de manière à réduire la quantité d'information à l'ordinateur de contrôle. Le LIDAR permet d’étalonner la profondeur (de l'image 3D reconstituée) sur un axe donné.
  • Impression parties châssis
  • Commencement de la migration des codes en .ino vers .c.

Semaine 4 (28/11/2019 - 05/12/2019)

  • Adaptation du code Arduino pour déplacement avec 6 servomoteurs (avec AVR, plus d'Arduino IDE). Meilleur contrôle des Timers utilisés.
  • Configuration RaspberryPI en point d’accès pour piloter faire une télécommande (172.26.145.42) -> A refaire (merci carte microSD made in China)

Semaine 5 (05/12/2019 - 06/01/2020)

  • Communication entre la RaspberryPi et l'Arduino

On envoie un message sur le port série d'une carte a l'autre. Le message a envoyé est choisie par l'utilisateur sur un téléphone connecté au point d’accès de la RaspberryPI sur robot.P13.org. Problème d’envoi sur la liaison série: On arrive bien a envoyer quelque chose de la RaspberryPI à l'Arduino mais on ne sait pas vraiment quoi.

Documents Rendus

Projet S8

Liste des taches https://trello.com/b/VHCWut1Y/p13

Semaine1 (13/01-19/01)

  • Shield pour l'arduino MEGA sur Fritzing (12 sorties servomoteur + 8 LED/resistances + entrée alimentation).
  • Essais résolution problèmes liaison série entre RaspberryPI et Arduino.

Semaine2 (20/01-26/01)

  • résolution du problème d'envoie de données entre la raspberry et l'ATmega: le problème venait de la fonction websocket.send() dans /var/www/html/index.php dans laquelle nous mettions en paramètre un caractère comme '1'. A l'envoie vers l'ATmega2560 le caractère était transformé par son code ASCII que nous n'arrivions pas à comprendre. Nous avons alors essayer de passer en paramètre un code en hexadécimal pour voir ce qui arriverez sur l'ATmega2560. En mettant bien websocket.send(0x01) l'ATmega a bien reçu via le port série le caractère 0x01 qui pourra alors être interprété plus tard pour la commande du véhicule.
  • Sheld ArduinoMEGA : impression/soudure/tests -> tout est OK

Fichier:P13shieldMEGA.zip

Shield1.png Shield2.png
  • Design du nouveau chassis (Plexiglas), en attente de la découpe laser.
  • Configuration des webcams
    • Récupération d'une commande permettant de prendre une capture d'image des webcam, nous l'utiliserons pour récupérer les données.
    • Nous avons utilisé le code fourni par Omar Padierna que nous avons récupéré sur https://github.com/OmarPadierna/3DReconstruction et effectué les premier test de configuration pour la construction d'une image 3D à partir d'OpenCV.
    • Nous avons sélectionné 2 webcam ayant une basse qualité d'image pour que les calculs soient plus rapide. Le problème c'est que les images sont de trop mauvaise qualité ce qui ne permet pas pour le moment de faire la configuration des webcams avec OpenCV.

Semaine3 (27/01-02/02)

  • Construction du nuage de point (stéréo vision)
    • Principe de fonctionnement

On utilise deux cameras séparées d'une certaine distance (comme deux yeux) pour mesurer la distance d'un objet dans l’environnement extérieur. Les deux cameras sont sur le même plan et on la même inclinaison verticale/horizontale. On connais la distance qui les sépare (l). Si on connais les angles A et B alors on peut utiliser le principe de triangulation pour connaître la distance de l'objet (d):

StereoVision1.jpg

Pour calculer les angles A et B: On connais l'ouverture du champ de vision de la camera (angle C) et on connais la largeur de l'image (L en pixel). On peut donc calculer la distance D et en déduire l'angle alpha:

StereoVision2.jpg

Il suffit désormais de trouver un point similaire dans chacune des images pour calculer sa distance par triangulation. A chaque point de l'image on peut désormais associer une une notion de profondeur et donc on peut reconstituer une nuage de point 3D représentant l’environnement extérieur.

On utilise la librairie OpenCV qui contient déjà toutes les fonctions nécessaires au traitement de l'image et a la reconstruction de la vue en 3D.

    • Calibration des cameras

Pour pouvoir calculer la distance d'un point de l'image, il faut connaître les caractéristiques intrinsèques de la camera tel que la distance focal:

FocalLength.jpg

De plus, avant de construire le nuage de points 3D, les image sont traitées pour compenser la distorsion (radiale et tangentielle) introduite par la camera (notamment a cause du positionnement de la lentille). Cette distorsion modifie les formes reeles des objets et donc influe sur le résultat de la triangulation. La méthode cv2.undistort d'OpenCV permet de rectifier l'image. Elle prend en paramètre les coefficient de distorsion (k1 k2 p1 p2 k3) qu'il nous faut connaître. Pour cela, on prend une série de photo d'un damier avec différentes inclinaisons et on lance le programme calibrate.py. Ce dernier détecte les coins des carres du damier et mesure les distances (en pixel) entre chacun. Ces dimensions sont comparées aux dimensions reeles (mesurées a la main) et permette de calculer les coefficients de distorsion (matrice dist.npy). Bien mieux expliqué ici: https://opencv-python-tutroals.readthedocs.io/en/latest/py_tutorials/py_calib3d/py_calibration/py_calibration.html#calibration

Le programme récupère également les paramètres intrinsèques/extrinsèques de la camera (distance focale et foyer optique) présent dans l’entête de chaque image.

Nous rencontrons ici un problème pour recuperer la distance focal de webcam. Cela marche tres bien avec la camera d'un téléphone portable car la valeur est directement écrite dans les caractéristique de la photo. Ce n'est pas le cas pour la webcam. On rentre la valeur de la focal a la main dans le programme de reconstruction, focal_length = 4.2 (trouvée dans sur internet d'une source moyennement fiable).

  • Réunion avec étudiant de Mr. Dequidt pour pilotage automatique
    • Première solution (la simple): détecter l'objet par sa couleur
    • Pythonrobotics pour planifier le parcours du robot
    • SLAM pour localisation et mapping de l'environnement
    • fast.ai / pytorch

Semaine4 (03/02-09/02)

Damien

  • développement du code pour récupération des données du Lidar en 2D: premier code en python pour vois si tout fonctionnait bien rapidement mais les données n'étaient pas précises, donc utilisation du code fourni par le fournisseur en C++, la récupération des données semblent plus rapides en C++ et plus précises.

http://www.slamtec.com/en/support#rplidar-a-series

Vincent

  • Decoupe (au fab) du châssis et du support pour les webcam (pour avoir un écartement fixe entre les deux et la même inclinaison verticale/horizontale)

Fichier:DecoupeLaser.zip

  • Script python pour sauvegarder une image a partir d'un webcam (Vincent): save_snapshot.py permet d'enregistrer une série de photo du damier qui seront ensuite analysées.
  • Script python pour récupérer les paramètres des camera: calib.py détecte les coins des carres noirs du damier et détermine la distorsion des cameras ainsi que ses caractéristiques intrinsèques (fichers K.npy et dist.npy)
Calib.png
  • Reconstruction du nuage de points 3D a partir de 2 images (Reconstruction.py). Il faut cependant trouver les bon paramètres pour la reconstruction (lors de l'appel a "cv2.StereoSGBM_create") car ceux de base peu efficaces. Pour cela, j'ai créé une fenêtre avec des curseurs amovibles pour trouver visuellement les meilleurs paramètres (c'est Damien qui se charge de trouver les bon params la semaine d’après).

Fortement inspiré par : https://martinperis.blogspot.com/2011/08/opencv-stereo-matching.html (code en c++ réécrit en python).

TuneParameters.png

Semaine5 (10/02-16/02)

Damien

  • Départition des pins de servo-moteur sur le shield

Map servo.jpg

  • Découpe des pales en caoutchouc
  • Trouver les bons paramètres acceptables pour la reconstruction

Param1 p13.jpg

Vincent

  • Design des bielles pour la pale en caoutchouc
  • Code pour récupérer les images des deux camera en parallèle (multithread)

Semaine6 (17/02-23/02)

  • Impression de 6 bielles
  • Premier test de fonctionnement avec un découpage de pâle en caoutchouc. Problèmes rencontrés:
    • Nous avons essayé de faire des bielles plus longues avec une fixation à la pâle à l'extrémité et au centre de la pâle pour la mieux maintenir mais ce n'était pas une bonne idée car cela laisse moins de jeu pour la pâle et demande plus de force au servo-moteur. Nous essayons alors avec seulement une fixation à l'extrémité de la pâle pour le moment.
    • Le caoutchouc étant épais, la force demandée au servo-moteur semble trop importante pour réaliser des amplitudes d'ondulation importante.

Semaine7 (02/03-08/03)

Vincent

  • Finir StereoVision:
    • Trouver la matrice Q avec une fonction dédiée -> ça marche pas la fonction plante -> Rentrer la matrice a la main (trouver la bonne?)
    • Recalibration des cameras -> il y a une camera plus lumineuse que d'autres, est-ce un problème??
    • Prendre images dans un cadre moins luminuex pour limiter la reflexion des object
    • Retrouver les bon parametres pour la fonction (Winsize,...)
  • Recherche de solution pour le pilotage automatique (calcule de trajectoire): Une fois que l’environnement est appréhendé (StereoVision) il faut trouver la cible souhaiter et décider de la trajectoire a suivre pour s'y rendre. Solution envisagée:
    • Reconnaissance du milieu et construction d'une cartographie : algorithm FastSlam https://atsushisakai.github.io/PythonRobotics/#slam
    • Reconnaissance de la cible
      • Par la couleur dans un premier temps (comme pour le tp d'IHM): On choisira un objet d'une couleur caracteristique (ex: vert). On calcule la moyenne de points qui ont une couleur comprise dans l'intervalle prédéfini pour isoler le centre de l'objet.
      • Avec un algorithme de reconnaissance d'objet type machine learning (neuronal network/ Kmeans/ Support vector machines SVM) a definir plus precisement.
    • Calcule de trajectoire (https://atsushisakai.github.io/PythonRobotics/#path-planning)

Damien

La semaine dernière j'ai remarqué que coller les bielles au support des servo-moteurs n'était pas très efficace car le caoutchouc applique une trop grand force lors des ondulations. Pour remédier à cela je suis partie dans l'après midi chercher du polyépoxyde pouvant subir une force de 130 kg/cm2 donc largement suffisant fixer les bielles aux servo-moteurs. Les bielles seront collées aujourd'hui et la semaine prochaine.

Problématique

Pour parer à la trop grand résistance des pâles en caoutchouc, 2 solutions étaient envisageable:

  • Changer de servo-moteur pour de plus puissant.
  • Réaliser des découpes dans les pâles pour les rendre plus souple. (Découpage intelligent ou mésostructure)

Le problème de la première solution est qu'après avoir vu les servo-moteurs développant plus de couple, leur dimension étant plus grande nous aurions dû refaire tout le chassie avant de pouvoir tester cette solution. Donc une perte de temps, car la 2ème solution était directement faisable.

Solution

Dans un premier temps, j'ai envisagé plusieurs forme manière simple d'entailler le caoutchouc pour le rendre plus souple:

  • L'entailler sur la largeur: ceci permettrai de rendre la pâle plus souple sur la déformation des ondulations sans perdre la rigidité sur l'axe des appuis véhicule/sol.
  • L'entailler sur la longueur: non envisageable car l’opposé de la précédente donc inutile dans notre utilisation
  • L'entailler en diagonale: cela peut être combiné à la première proposition pour amélioré encore plus la souplesse du caoutchouc sur des ondulations si celle ci n'est pas suffisante avec seulement les entailles sur la largeur. Mais attention les entailles en diagonale vont aussi faire perdre de la rigidité au caoutchouc sur l'axe des appuis véhicule/sol.

J'ai alors réalisé 2 prototypes de pâles: une avec seulement des entailles sur la largeur et une avec des entailles sur la largeur et en diagonale.

Modele pale 1.png

Semaine8 (09/03-15/03)

Vincent

  • Définition de la structure général du programme pour une meilleur vue d'ensemble du projet:
Trame algo.jpg

Au démarrage, l'utilisateur a le choix entre commande manuelle et automatique. Dans le cas d'une commande manuel, le programme lis en boucle les instruction de la télécommande sur le serveur web de la Raspberry et les envoie par liaison serie a la carte Arduino pour effectuer le déplacement(travail réalisé au S7). Pour le déplacement autonome, le robot va d'abord scanner son environnement en effectuant une acquisition avec le LIDAR et des cameras. Les données du LIDAR vont permettre de construire un cartographie de l’environnement qui permet au robot de savoir ou il se situe dans son environnement (travail a réaliser pendant les prochaines séances). L'image issue d'un camera va permettre de déterminer si la cible se situe dans l’environnement (visible par le robot) soit avec un simple filtre de couleur, soit avec un algorithme de reconnaissance d'objet (Machine learning). Si la cible n'est pas détectée, le robot se déplace et recommence l'acquisition. Si la cible est détectée, on utilise ici l’algorithme de Stereovision pour recuperer la distance a laquelle se trouve l'objet. On peut ensuite déterminer la trajectoire a suivre pour atteindre l'objet (algorithme a* ou autre) puis le robot se déplace jusqu’à atteindre sa cible.

  • Recherches sur l'algorithme SLAM pour Générer une cartographie de l’environnement.

Damien

Après réalisation des découpes des 2 pâles prototypes envisagés la semaine dernière, j'ai pu réaliser les testes d'ondulation sur le robot avec les nouvelles bielles imprimées il y a 2 semaines. Plusieurs remarques sont à dire de ce test:

  • La pâle avec les entailles sur la largeur et en diagonale possède une meilleur "ondulation".
  • Premier test avec les 12 servo-moteurs en action. Même avec les tous les servo-moteurs en position basse, le véhicule ne se soulève pas.
  • Les ondulations sont très approximatives car la déformation du caoutchouc au milieux de la pâle demande trop de force aux servo-moteurs en position 3 et 4 qui n'arrivent pas à réaliser une ondulation maximal contrairement aux servo-moteurs 1 et 6.

Solutions envisagées:

  • Au niveau du problème le plus contraignant, le fait que même tout les servo-moteurs n'arrivent pas à soulever le robot. Nous avons vu avec monsieur Dequidt, que pour nous n'avions pas le temps de changer les servo-moteurs, et que pour les tests nous allions porter le véhicule avec une structure ou avec un câble pour appliquer moins de force sur les servo-moteurs.
  • Pour les ondulations pour le moment approximatives, nous avons discuté de possible forme qui permettrons un meilleur mouvement entre chaque servo-moteur en retirant de la matière entre chaque servo ou en coupant carrément le lien entre chaque servo-moteur et partir sur un modèle de pagaie d'aviron. Un premier test avec de la matière retiré montre déjà un meilleur mouvement mais des tests supplémentaire doivent être effectués.

Modele pale 2.jpg

Ondulation caoutchouc.gif

Semaine9 (16/03-22/03)

Vincent

Fonctionnement du SLAM

Si on connaît la position du robot, on peut calculer la carte a partir des donnée d’observation. Si on connaît la carte, on peut calculer la position du robot. Si on connaît ni l’un ni l’autre, on utilise SLAM (= Simultanous Localization And Mapping).

Approche probabiliste : permet de calculer : P(xt, m | zt-1, ut-1), cad la fonction de distribution de la position x et la map ma l’instant t sachant l’observation z et la commande u a l’intant t-1.

ExplicationSLAM.png

Pour calculer cette fonction de probabilité, on utilise un filtre de Bayes et plus précieusement un EKF (Extended Kalman Filter) qui permet d’obtenir un résultat même pour des distribution non linéaires. Fonctionnement EKF SLAM : 2 étapes → Prediction et Correction Source:https://www.youtube.com/watch?v=U6vr3iNrwRA&list=PLgnQpQtFTOGQrZ4O5QzbIHgl3b1JHimN_

Travail effectue
  • J'ai fixé le LIDAR sur le robot réalisé lors du BE PEIP pour pouvoir tester le programme sur quelque chose de mobile.
RobotPEIP.jpg

PythonRobotics propose un code tout fait du SLAM basé sur un "Motion modèle" de type "Velocity". Un problème se pose: sur le robot, il n'y a aucun moyen de mesurer le déplacement réel car pas d'accelerometre ni de capteur optique sur les roues. En attendant de pouvoir commander un accelerometre (confinement), il faut donc adapter le code récupéré pour pouvoir rentrer a la main le déplacement effectué par le robot et ainsi tester le bon fonctionnement du programme (suite la semaine prochaine)

Je n'arrive pas a installer ROS (supporte jusqu’à Ubuntu 16) sur ma machine (Ubuntu 18...). Je n'ai pas penser a prendre ma Raspberry pour essayer dessus. Suite la semaine prochaine.

Damien

Les résultats obtenus lors de cette semaine ont déjà été décrits sur la semaine précédente pour avoir une rédaction unique.

Semaine10 (23/03-29/03)

Vincent

Pour cela, on installe les packets RPLIDAR_ROS : https://github.com/Slamtec/rplidar_ros Ça ne marche pas: le LIDAR se lance bien mais le Cartographer n'a pas l'air d'avoir accès aux données. Pourtant le LIDAR fonctionne bien:

EssaiLIDAR.png

Manque de tuto sur le sujet...

  • Autre approche: On enregistre au préalable les donnes du LIDAR dans un fichier.bag puis on lance le Cartographer avec ces données.

Pour enregistrer: http://wiki.ros.org/rosbag/Tutorials/Recording%20and%20playing%20back%20data Pas plus de succes...

On intègre le code du LIDAR pour recuperer les points et on rentre la position du robot a la main.

Semaine11 (30/03-05/04)

Vincent, toujours sur le SLAM

  • Les données du LIDAR sont stockées sous forme d'un vecteur (360*1). L'indice i correspond a l'angle de la mesure du lidar (dans son repère, cf schéma ci-dessous). A chaque angle, on associe une distance mesurée. L'acquisition d'un scan se fait sur une dizaine de tour du moteur pour être sur d'avoir une bonne valeur par angle. Toutes les fonctions nécessaire pour faire fonctionner le LIDAR sont dans le fichier /Mapping/lidar.py.
  • J'ai repris le code du FastSlam2 proposé par pythonRobotics (https://github.com/AtsushiSakai/PythonRobotics/tree/master/SLAM/FastSLAM2):
    • Adaptation de la fonction observation() pour recuperer les données du LIDAR.
    • Comme on a aucun système d’odométrie, on test sur une ligne droite en prenant des mesure toute les 0,5m (cad a chaque repère au sol)
EssaiSLAM.jpg
    • Problèmes rencontres dans la fonction update_with_observation(): Le code fournie est en réalité une simulation qui tourne avec une liste prédéfinie de Landmarks (repérés par un lm_id). Or dans notre cas, on ne sais pas quel mesure correspond a quel Landmark lorsqu'on scan l’environnement. Il faudrait associer chaque mesure du LIDAR a un Landmark par calcul trigonométrique.
  • Il s’avère qu'il y a un moyen de se baser que sur les données du LIDAR sans associer un Landmark particulier: https://github.com/simondlevy/BreezySLAM.

Ce gentil monsieur propose même un programme compatible avec notre LIDAR (rplidar A1) et en plus sans odométrie. C'est un miracle... Comme en témoigne ces images de mon espace de confinement, ca marche!

EssaiSLAM2.png

Damien

Après 2 semaines d'acharnement sur la conception des pâles. J'ai réalisé un nouvelle algorithme pour essayer de faire avancer le robot différemment. Le code réalisé lors du S6 et S7 faisait que les servo-moteurs tournés indépendamment des autres. Les servos étaient conditionnés a une initialisation en position puis un déplacement pas à pas de chaque servo dans un direction programmé. Le problème de cette méthode est que l'ondulation correspond au mouvement d'une onde stationnaire. Ceci est excrément compromettant car une onde stationnaire ne permettra jamais au robot de ce déplacement, il fera seulement du sur-place. J'ai alors réalisé une nouvelle fonction de mouvement des servo-moteur.

Nouvelle Fonction

Cette nouvelle fonction à pour premier principe de ne faire tourner qu'un seul servo-moteur par pâle via les paramètres globaux (inclinaison max, inclinaison initial, pas, sens de rotation). Maintenant, le reste des servos vont recopier le mouvement du servo le précédent. Avec cela nous avons alors bien un sens d'ondulation. Le problème c'est que nous ne voulons pas recopier la position du servo précédent mais une position plus ancienne pour avoir un retard plus important et donc en fonction du retard apporté nous allons obtenir des ondulations différentes.

Ondulation retardee.gif

Maintenant avec ce mouvement nous allons essayer de faire déplacer le robot. Dans un premier temps pour avoir une meilleur impulsion sur le robot nous allons faire en sorte que l'ondulation ne soit pas continu et de marquer un temps d’arrêt faible après chaque ondulation. Après avoir trouver des premiers paramètre nous arrivons à avoir un léger déplacement du robot. Le déplacement est excrément lent et le robot nécessite une aide pour soulever son poids mais cela reste une grand avancée.

Semaine12 (06/04-12/04)

Vincent

  • Stereo vision: nouvel essai avec une seul camera pour voir si le problème viens du matériel:
    • Capture des images droites et gauches avec une seul camera (celle de droite) et espaçant les deux prises de 10cm et en essayant de garder la même inclinaison.
    • Recalibration de la camera utilisée (pour être sure).
    • Calibration des paramètres de StereoSGBM: resultats toujours pas exploitables...
  • SLAM: Trouver comment combiner les données de la carte et la positon de l'objet pour planifier la trajectoire du robot.
  • Target detection: code détection de cible par la couleur:
Target.png

Pas le temps pour faire algo machine Learning


Documents Rendus

Récupérée de « https://projets-ima.plil.fr/mediawiki/index.php?title=IMA3/IMA4_2018/2020_P13&oldid=84206 »