Version actuelle datée du 17 juin 2019 à 21:22

Kit Robot

Lien de téléchargement de l'application

Robot final fait à partir du Kit

Document utile

Catalogue_des_pièces_du_Kit.pdf

Liens utiles:

• Librairie Arduino du kit
• Librairie pour l'ATtiny en esclave I2C
• Tuto d'installation du type de Board Attiny85 pour ArduinoIDE
• Interface de programmation par blocs
• Github de l'interface de programmation

Informations utiles:

• Nom du module Bluetooth: KitRobotP46
• Mdp du module Bluetooth: 0000

Informations d'utilisation

• Installation des librairies: télécharger les librairies sur github puis Croquis>Inclure un bibliothèque>Ajouter la bibliothèque .ZIP
• Téléversez un programme sur la carte: Utilisez l'ISCP

Sur un Arduino UNO téléversez l'exemple ArduinoISP. Reliez les ICSP de l'Arduino avec la Carte. Attention le fil Reset ne doit pas être branché sur celui du UNO mais sur le pin 10. Pour téléverser sélectionnez la carte ArduinoMega2560, sélectionnez le programmateur Arduino as ISP puis téléversez avec Ctrl+Shift+U ou en cliquant sur "Téléverser avec un programmateur".

• Pour installer l'application flashez le QRcode
• Pour utiliser le site de programmation, assemblez vos blocs, cliquez sur "View code source" et copiez/collez le code dans l'IDE Arduino pour le téléverser.
• L'encodeur moteur utilise le portB du contrôleur, le portA reste donc disponible pour un moteur DC

Bug observé: Si le moteur s’emballe lors du contrôle en position, nous avons observé un faux contact au niveau de l'encodeur, appuyez sur le connecteur pour corriger le problème.

Présentation générale

Description

Il existe de nos jours de nombreux kits d'assemblage de robots programmables.

Ils permettent aux utilisateurs de créer leurs propres robots à l'aide de pièces, de moteurs et de capteurs. Il existe des kits pour tous les niveaux, du débutant à l'expert en robotique ; les robots sont programmables via une application mobile en Bluetooth ou via des langages de programmations (Scratch, C++, Python ...)

Le problème de ces kits est qu'ils sont souvent assez chers et surtout propriétaires. C'est à dire qu'ils ne sont pas Open-Source et que la perspective d'évolution du kit est limitée à la même marque.

Durant notre cursus, nous avons eu l'occasion de tester par exemple les kits MindStorm NXT, Bioloid et MakeBlock.

L'objectif de ce projet est d'y proposer une alternative, en concevant un kit Open-Source (open source en logiciel comme en matériel) permettant l’assemblage d’un robot et une programmation aisée et facilement modifiable à sa convenance.

Objectifs

Pour la réalisation de ce projet nous allons tout d'abord réaliser notre propre carte programmable qui sera le cerveau du robot. Elle permettra de connecter (principalement via RJ25 avec un protocole SPI ou I2C pour faciliter le câblage) les capteurs, les actionneurs, les moteurs, les modules de communication et de les contrôler facilement.

Nous trouverons un système d’alimentation du robot, proposant une autonomie correcte (par exemple batterie lithium). Nous ajouterons également un système de recharge simple et un régulateur de tension adapté aux besoins des composants du robot.

Puis nous allons réaliser ou adapter différents modules électroniques permettant d’aider à la conception des différents modèles (capteurs, actionneurs, modules de communication).

Ensuite nous réaliserons, à l'aide de la Découpeuse Laser et des imprimantes 3D du Fabricarium de l'école, les différentes pièces du Kit qui peuvent être facilement assemblées pour former plusieurs modèles de robots.

Enfin nous réaliserons différentes bibliothèques proposant un outil de programmation et d'utilisation simplifié du modèle et de ses modules.

Le Kit créé pourra être utilisé au club Robotech de Polytech Lille. Il permettra aux nouveaux membres de se familiariser avec la robotique, d'utiliser les machines du Fabricarium et de créer un robot. Il pourra également être utilisé pour la coupe de France à laquelle Robotech participe chaque année. Il constituera une base solide pour la fabrication et la programmation des deux robots (primaire et secondaire)

Analyse du projet

Positionnement par rapport à l'existant

Tous les kits disponibles de nos jours possèdent des points positifs et des points négatifs (autonomie, prix, facilité de programmation, facilité d'assemblage, diversité des modèles disponibles, possibilité d'additionner plusieurs kit...)

Notre kit sera, à l'inverse de la plupart des kits existants, Open Source en matériel et en logiciel.

Les utilisateurs pourront eux-mêmes imprimer les pièces du kit grâce à des fichiers stl (imprimante 3D) et svg (Découpeuse Laser). Ils pourront également reproduire la carte et les différents capteurs, actionneurs, modules de communication grâce aux fichiers partagés et à la liste des composants nécessaires. Cela permettra une économie d'argent considérable et également à l'utilisateur de comprendre en détails avec quels composants sont réalisés tous les éléments du kit et comment ceux-ci fonctionnent. De plus si un élément du Kit ne fonctionne plus ou est défectueux, il suffit de le réimprimer. Ce n'est pas le cas des Kit déjà existants qui ne sont pas Open Sources.

Notre Kit sera simple d'utilisation avec des codes couleurs pour faciliter les branchements et la programmation.

Analyse du premier concurrent

Notre premier concurrent est la marque Makeblock. Cette marque propose différents Kits pour construire des robots.

Nous étudierons ici deux de leurs kits :

Makeblock (mBot V1.1)

Makeblock (Ultimate 2.0)

Robot mBot V1.1 et Ultimate 2.0

Voici les différentes caractéristiques de ces kits:

Connectivité

• Type d'interface: Wi-Fi ou Bluetooth
• Port de chargement USB
• Applications: Arduino IDE
• Câbles inclus: LAN (RJ-45), USB

Puissance

• Batteries requises
• Type de source d'alimentation: Non-rechargeable battery
• Tension des piles: 1,5 V
• Type de batterie: AA
• Nombre de batteries prises en charge: 4 pour le mBot et 6 pour l'Ultimate

Robot mBot V1.1

Caractéristiques

• Nombre de moteurs: 4
• Nombre de capteurs: 3
• Ligne suivante: Oui
• Support smartphone à distance: Oui
• Support d'application: Oui
• Applications: Graphical, Arduino , Python, Node JS, Mblock, Scratch
• Chargeur: Oui
• Guide de démarrage rapide: Oui
• Piles fournies: Non

Ultimate 2.0

Caractéristiques

• Nombre de pièces: 40 pièces
• Nombre de robots programmables: 1
• Chargeur: Oui
• Guide de démarrage rapide: Oui
• Piles fournies: Non
• Nombre de moteurs: 2
• Nombre de capteurs: 3
• Ligne suivante: Oui
• Nombre de haut-parleurs: 1
• Compatible avec les effets de lumière: Oui
• Couleur de la lumière: Multi
• Nombre de DEL d'éclairage: 2
• Support smartphone à distance: Oui
• Support d'application: Oui

Robot mBot V1.1: Ce Kit est l'un des moins cher du marché (100 euros), il est néanmoins moins complet que certain autres Kit. La marque revendique ce Kit comme étant spécialement conçu pour les enfants. Il permet d'apprendre facilement les bases de la programmation.

Avertissement de sécurité pour le mBot

• Pas pour les enfants âgés entre 0 et 3 ans
• À utiliser sous la surveillance directe d'un adulte

Ultimate 2.0: Ce Kit propose un ensemble de 10 configurations programmables. Ce Kit n'est pas destiné aux jeunes enfants car il contient de nombreux petits éléments et le montage se fait à l'aide de vis. Ce Kit est au prix de 400 euros.

Avantages des 2 Kits:

• Pièces très résistantes et assemblage robuste grâce aux vis
• Compatible avec plusieurs moyens et langages de programmation
• Compatibles avec des capteurs de marque autre que Mblock
• Facile d'utilisation
• Prix abordable pour le Robot mBot V1.1

Inconvénients des 2 Kits:

• Autonomie limitée
• Prix assez élevé pour l’Ultimate 2.0
• Nombre et types de pièces très limités et non remplaçables pour le Robot mBot V1.1
• Non évolutif

Analyse du second concurrent

Notre second concurrent est la marque LEGO. Elle propose des Kits de programmation de robots qui sont plus accessibles aux enfants. Le construction de ce kit est simplifiée: il n'y a pas besoin de vis.

Ces deux kits sont très utilisés pour l'enseignement et l'éducation des sciences et techniques.

Les prix de ces Kits sont autour de 300 euros.

LEGO (Mindstorm EV3)

LEGO (Mindstorm NXT 2.0)

Voici les différentes caractéristiques de ce kit:

• Brique intelligente programmable NXT 4 ports d'entrée et 3 ports de sortie de forme proche du standard RJ12
• Connexions USB et Bluetooth
• Trois servomoteurs interactifs
• Quatre capteurs : sonore, photosensible, ultrason, tactile (possibilité d'utiliser d'autres capteurs qui ne sont pas dans le Kit :couleur, autodirecteur infrarouge, gyroscopique, infrarouge, accéléromètre, boussole...)
• NXT-G, le logiciel de programmation graphique, basé sur Labview compatible avec Windows et Mac
• Alimentation : six piles AA (1,5 V) ; une batterie 9 V est commercialisée par Lego.

Il est possible d'utiliser des accessoires supplémentaires (non fournis dans la boite principale) comme une clé Bluetooth USB, une batterie rechargeable, des moyens de communication Wi-Fi, XBee (modules radio compatibles), des multiplexeurs, des panneaux solaires, des pilotes de relais, des roues holonomiques...

Avantages

• Logiciel de programmation simplifié
• Facile à assembler

Inconvénients

• Capteurs et moteurs propriétaires cher à l'achat
• Puissance des actionneurs limitée
• Possibilité limitée du nombre de capteurs (4) et d'actionneurs (4) sur un même robot à cause du nombre de ports disponibles

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

Scénario:

Hervé est en Peip à Lille et il s'est découvert une nouvelle passion pour la Robotique. Il a vu plusieurs reportages et vidéos sur le sujet. Il veut travailler plus tard dans ce domaine. Il décide alors qu'il ira en IMA . En attendant, il décide d'apprendre toutes les facettes de cette discipline. Mais il ne sait pas par quoi commencer. Il veut apprendre étape par étape et se renseigne alors sur des moyens d'apprendre la robotique facilement. Sur internet il découvre l'existence de Kit de robotique programmable qui constitue une excellente base de Robotique et qui sont accessibles aux débutants. Mais ils sont assez chers et il n'a pas les moyens (il est étudiant).

Il découvre alors l'existence du Club "Robotech". Quelle chance ! Les membres du club l'informent de l'existence d'un tout nouveau Kit crée par des étudiants pour leur projet de 4ème année. Hervé se renseigne alors : ce kit est Open Source et il pourra grâce à l'imprimante 3D et la découpeuse Laser du Fab fabriquer les pièces de son Kit. Cela lui permettra également de faire des économies d'argent. Pour ce qui est des capteurs et de la carte, les membres de Robotech (qui sont curieusement principalement des IMA) lui fournissent de l'aide et il pourra tout réaliser à Polytech.

Quelques semaines plus tard, Hervé réalise son premier robot qui est commandable en Bluetooth et possède toute une panoplie de capteurs lui proposant un champs d'application très varié. Il est également très content de la batterie en Lithium du Kit qui assure une bonne autonomie à son robot et qui se recharge très facilement.

Malheureusement il a fait tomber son robot (il est maladroit) et le capteur infrarouge ne fonctionne plus du tout. Pas de soucis ! Grâce au fichier opensource il peut en fabriquer un nouveau facilement.

Au fur et à mesure, Hervé créé les capteurs dont il a besoin et fabrique de nouvelles pièces pour améliorer son robot. Grâce à ce Kit il a pu apprendre à programmer son propre robot et à comprendre comment sont fabriqués les différents capteurs et comment ils fonctionnent.

Un an plus tard, le voilà nommé Secrétaire et Responsable de la communication de Robotech. La date de la compétition phare du club, la Coupe de France de Robotique, approche. Surchargés de travail entre les cours de réseau et d'électronique, les membres du club n'ont pas eu le temps de fabriquer le robot secondaire et il ne leur reste qu'un mois. Hervé décide alors, sur un éclair de génie, d’utiliser de nouveau le Kit : celui-ci est robuste et permettra de confectionner n'importe quel type de robot. L'avantage est qu'il est facilement programmable via l'IDE Arduino pour les jeunes IMA3, et on pourra y brancher énormément de capteurs sans un nombre incalculable de fils qui se prendront dans les roues !

Réponse à la question difficile

Qu'est-ce que notre Kit apportera de nouveau par rapport aux autres?

Notre Kit sera Open Source en logiciel et en matériel. Des bibliothèques seront conçues et des codes déjà implémentés. De plus les fichiers pour créer les pièces et les capteurs seront accessibles. Il sera donc facile pour un étudiant, grâce à tous les moyens mis à disposition à Polytech, de fabriquer tout ce dont il a besoin

Ce kit sera conçu par des étudiants pour des étudiants (Robotech). Nous allons faire notre possible pour pouvoir proposer un Kit contenant les principales pièces et capteurs à un prix abordable.

Pour ce qui est des possibilités d'extension du Kit, nous proposerons plusieurs capteurs et pièces pour ajouter au robot.

Nous allons faciliter la programmation et l'assemblage en utilisant des connectiques adéquates et des codes couleur.

En d'autres termes, nous voulons combiner les avantages de tous ces kits en 1 seul (prix, pièces, Open Source, facilité de programmation...) et les améliorer en proposant la possibilité de produire des pièces de rechange soi même.

Préparation du projet

Cahier des charges

• Concevoir des bibliothèques pour faciliter la programmation sur l'IDE Arduino

• Proposer des modèles et une programmation simplifiée par blocks

• Concevoir les pièces 2D du robot dans un matériel résistant, peu cher et facile à usiner : plexiglass

• Concevoir les pièces 3D du robot grâce aux imprimantes 3D

• Créer et/ou modifier des capteurs pour le robot pour être adapté à l'I2C

• Créer une carte programmable optimisée permettant le branchement facile des capteurs et actionneurs sur un ATMega2560

• Concevoir une application Bluetooth pour contrôler le Robot

• Faciliter la construction (code couleur, câbles simples à brancher)

Choix techniques : matériel et logiciel

Matériaux

• Plaque de plexiglas 1m2, 3mm d'épaisseur pour des fines pièces
• Plaque de plexiglas 1m2, 6mm d'épaisseur pour des pièces plus grosses et résistantes

Actionneurs

• Moteur CC + Encodeur + contrôleur moteur
• Motoréducteur + encodeur FIT0520: [1]

Capteurs

• 1 Capteur de distance par Ultrasons HCSR04: [2]
• 2 Capteurs de distance par Infrarouges de type SHARP: [3]
• 1 Gyroscope: [4]
• 2 Capteurs de lignes: [5]
• 2 Fin de courses: [6]

Autre

• Vis M4 12mm,16mm et écrous M4: [7] + [8] + [9]
• câbles RJ25
• RJ25 femelle
• Batterie Lithium-ion + chargeur
• Arduino Mega: [10]

Carte électronique Principale

• Micro contrôleurs:
  
  • 1x ATMEGA2560-AU[11]
    
  • 1x ATMEGA8u2[12]
    
• Alimentation:
  
  • 2x Diode suppresseur ESD PGB1010603MR[13]
    
  • 1x Perle de ferrite BLM21[14]
    
  • 1x FDN340P MOSFET [15]
    
  • 2x SS34 Diode/Redresseur [16]
    
  • 1x Fusible réarmable 500mA [17]
    
  • 1x Fusible réarmable 1,5A [18]
    
• Résistances CMS 0603:
  
  • 1x Réseau de résistances 1K CAY16 [19]
    
  • 7x Résistance 10K [20]
    
  • 2x Résistance 1M
    
  • 1x Résistance 1,91k
    
  • 1x Résistance 29,4K [21]
    
  • 2x Résistance 22r [22]
    
  • 3x Résistance 220r [23]
    
• Condensateurs:
  
  • 1x Condensateurs électrolytiques en aluminium - CMS 470UF[24]
    
  • 1x Condensateurs électrolytiques en aluminium - CMS 330uF [25]
    
  • 4x Condensateurs électrolytiques en aluminium - CMS 100uF[26]
    
  • 13x Condensateur céramique 100nF [27]
    
  • 1x Condensateur céramique 0603 1uF [28]
    
  • 2x Condensateur céramique 0603 10uF [29]
    
  • 4x Condensateur céramique 0603 22pF [30]
    
  • 1x Condensateur céramique 0603 120pF [31]
    
  • 1x Condensateur céramique 0603 68pF [32]
    
• Connectique:
  
  • 1x Régulateur de tension TPS54331D [33]
    
  • 1x Connecteur USB-B [34]
    
  • 1x Interrupteur Reset [35]
    
  • 1x Commutateur à glissière [36]
    
  • 1x Power jack 3,5A minimum
• Leds:
  
  • 2x led jaune CMS [37]
    
  • 1x led rouge CMS [38]
    
  • 1x led verte CMS [39]
    
• Autre:
  
  • 2x Quatrz 16MHz[40]
    
  • 1x Inductance 6.8uH [41]
    

Contrôleurs moteurs Pour 1 contrôleur moteur: (pour le projet on en aura besoin de 4):

• Résistances CMS 0603:
  
  • 1x Résistance 220r [42]
    
  • 1x Résistance 10K [43]
    
• Condensateurs:
  
  • 3x Condensateur céramique 0603 10uF [44]
    
  • 3x Condensateur céramique 0603 100nF [45]
    
• Autre:
  
  • 1x Contrôleur de moteurs TB6612 [46]
    
  • 1x led verte CMS [47]
    
  • 1x Transistor DMG3415U-7

Carte électronique capteurs Pour 5 cartes controllées par ATtiny85 et 2 cartes utilisant un ADC

• Composants électroniques:
  
  • 5 ATTiny85 CMS: [48]
    
  • 2 ADS1015 : [49]
    
• Condensateurs:
  
  • 21x Capacité CMS 1206 100nF : [50]
    
• Résistance CMS:
  
  • 29x Résistances CMS 1206 10KΩ
    
• Autre:
  
  • RJ25 femelle
    
  • Pin mâles
    

Liste des tâches à effectuer

Les différentes tâches à effectuer :

Tâche 1 :Création de la carte principale Après en avoir parlé avec nos enseignants, nous utiliserons comme base de notre carte programmable, un Arduino Mega.

Tâche 2 :Création des pièces Nous avons défini les différents capteurs et actionneurs de notre Kit. Il s'agit maintenant de créer les pièces du Kit pour pouvoir créer son robot selon différents modèles disponibles.

Tâche 3 :Création cartes moteurs et capteurs Pour pouvoir contrôler le robot, on peut utiliser différents capteurs et des moteurs pour la pince et pour le faire avancer.

Tâche 4 :Programmation Nous allons créer des bibliothèques pour faciliter la programmation des différents modèles. La programmation se fera avec l'IDE Arduino (langage C) ou en blocs (ArduBlock, Blockly Arduino..)

Calendrier prévisionnel

Septembre à Décembre

• Présentation du projet(description et objectif)
• Analyse du projet
• Préparation du projet (cahier des charges, matériel)
• Discussion avec les encadrants pour valider les différents choix proposés

Janvier

• Analyse et répartition des différentes tâches à effectuer
• Début de la création de la carte principale
• Recherche sur le logiciel Ardublock
• Recherche sur le protocole I2C

Février

• Fin création de la carte principale et ajout du matériel à commander dans la liste
• Création des pièces du Kit (en imprimante 3D et découpeuse laser sur du plexiglas)
• Début programmation via IDE Arduino

Mars

• Soudure de la carte principale
• Création des différentes librairies Arduino
• Création ou modification des pièces du Kit (capteurs)

Avril

• Création application Bluetooth
• (Programmation en blocs)
• Conception de modèles de Robot de base

Mai

• Rapport pdf et création d'un manuel d'utilisation pour le Kit
• Soutenance

Réalisation du Projet

Feuille d'heures

Les heures indiquées dans ce tableau sont approximatives.

Avancement des objectifs

• Carte électronique principale:
  • Schématic: Terminé
  • Routage: Terminé
  • Soudure: Terminée
  • Tests: En cours, Fonctionnelle à 50%

• Cartes électroniques secondaires:
  • Schématic: Terminé
  • Routage: Terminé
  • Soudure: Terminée
  • Tests: ADS1015 Terminé, ATtiny85 Terminée

• Librairies:
  • Arduino: Terminé 100%
  • Programmation en Blocks: Terminé 100%

• Pièces du kit: Terminées 100%

• Application bluetooth: Terminée

Début des Séances de Projet

Semaine 1

Carte principale

Nous avons commencé par créer la carte. La première question est de savoir avec quel logiciel nous allions router notre carte(Fritzing ou Eagle). Nous avons décidé de prendre Eagle qui, même si il nous ne l'avons jamais utilisé contrairement à Fritzing, est plus performant pour notre application et est utilisé dans les entreprises de nos jours.

Nous avons effectué des recherches pour pouvoir créer notre carte et nous voulions nous inspirer des cartes Arduino crées dans les BE PEIP. Néanmoins nous voulons comme base un Arduino MEGA, donc nous nous sommes inspirés de schémas sur internet: Schematic Arduino Mega (open source). Le choix d'un ATMEGA2560 plutôt qu'un 328p s'est fait sur le nombre de pins,et d’interruptions que nous voulons utiliser pour notre kit. De plus nous voulons que notre kit soit évolutif, c'est à dire qu'il soit accessible aux débutant mais qu'une personne à l'aise avec un arduino puisse y ajouter des éléments plus évolués. D'où l’intérêt de laisser quelques pins à disposition sur la carte.

Protocole I2C

Ce protocole est très utilisé en Robotique. Il permettra de simplifier le montage du Robot. En effet il y aura moins de fil à connecter!

Le Kit mBot de Makeblock utilise ce protocole par exemple pour un de ses capteur de couleurs. De plus, toutes les communications entre la brique intelligente Lego Mindstorms NXT et les capteurs s’effectuent grâce au protocole I2C.

C'est quoi l'I2C?

Il s'agit d'un bus permettant d'échanger des données entre plusieurs systèmes numériques. Généralement, ce type de bus sert à connecter un micro-contrôleur (dans notre carte principale) à plusieurs périphériques tel que des afficheurs, des capteurs ou des actionneurs.

Ce bus se compose de 2 fils :

• SDA : qui sert à transmettre les données, c’est par cette ligne que transitent les informations échangée entre les deux systèmes.
• SCL : qui sert à transmettre une horloge permettant la synchronisation entre les 2 systèmes échangeant des données.

Les systèmes étant numérique, ces fils ne transmettent que des niveaux logiques binaire :

• pour transmettre un '0', le périphérique connecte le fil à la ligne de masse Gnd. C’est la référence des potentiels.
• pour transmettre un '1', le périphérique ne fait rien et une résistance dite de pull-up se charge d'élever la tension de la ligne au niveau de la tension d'alimentation Vcc. Il permet d’alimenter le capteur.

Principe de fonctionnement

Par défaut, les 2 fils sont au niveau logique '1' grâce à la résistance de pull-up. Pour commencer à transmettre des données, un périphérique met la ligne SDA à l'état '0'. En détectant ce passage à '0', les autres périphériques savent qu'ils vont alors recevoir des données. Après avoir passé la ligne SDA à l'état '0', le périphérique émetteur génère un signal d'horloge sur la ligne SCL en passant alternativement la ligne de '0' à '1' et vice versa. Grace à cette alternance, les autres périphériques peuvent se synchroniser à la même vitesse que le périphérique émetteur. Il ne reste alors plus qu'au périphérique émetteur d'envoyer les bits qu'il souhaite transmettre un à un sur la ligne SDA.

Autre

Nous avons discuté au sujet des différents modèles de Robot que nous pourrions réaliser pour le Kit. Ces modèles seront expliqué dans le manuel et permettront à l'utilisateur d'avoir des modèles de base pour commencer à utiliser notre Kit. Nous allons faire en priorité:

• Robot voiture
• Robot voiture + pince (le plus utile pour la Coupe de France)

Nous avions également pensé à réaliser d'autres modèles de Robot si nous avons le temps:

• Robot qui danse
• Robot détecteur (style Robotino mais attention au budget)
• Robot 2 roue (nécessite un PID)
• Robot sans roues (araignée,tortue...)
• Robot caméra (attention au budget)

Semaine 2

Nous nous sommes répartis les tâches. L'un s'occupe de continuer l'élaboration de la carte électronique. Pendant ce temps, l'autre s'est informé sur le logiciel Ardublock afin de créer des blocks de programmation dédiés à notre Kit de robots.

Carte Principale

Nous commençons a dessiner et router la partie communication série de la carte électronique. Pour cela nous nous basons sur les plans officiels de l'arduino mega en prenant soin de la comprendre parfaitement puisque nous n'avons pas besoin d'y apporter d'améliorations.

Logiciel Ardublock

Logiciel Ardublock

Le logiciel ArduBlock est un plugin qui s’ajoute à l’IDE d'Arduino et qui vous permet de programmer en blocs de fonctions.

Il se code en langage JAVA, nous avons donc commencé à regarder des cours de Java sur Internet.

Nous avons installé l'IDE Eclipse, un environnement de développement destiné au langage Java. Il contient déjà tout le nécessaire pour le développement et la compilation. Nous avons également besoin du JRE (Java Runtime Environment) qui peut traduire le byte code généré lors de la compilation. En effet, lors de la phase de compilation de notre code source, celui-ci prend une forme intermédiaire appelée byte code : c'est un code inintelligible pour notre machine, mais interprétable par la machine virtuelle Java (JRE).

Semaine 3

Nous avons continué de travailler sur la création de la carte principale (début du routage) et nous avons continué les recherches sur la création de blocs sous ArduBlock.

Carte principale

Étude des différentes entrées et sorties de la carte qui seront nécessaires et disposition des pins avant de commencer routage. La partie la plus importante à prévoir est l'emplacement des pins des contrôleurs moteurs, il a donc fallu effectuer des recherches dessus pour commencer le schématic. Nous listons alors les différents pin dont nous aurons besoin pour notre contrôleur moteur afin de les disposer sur notre carte principale. Nous avons alors besoin pour les contrôleurs de:

• 8 entrées:
  • 2 pins PWM: réguler la vitesse des 2 moteurs
  • 1 pin d'interruption: pour l'encodeur du moteur
  • 4 sorties digitales: pour contrôler le sens de rotation de chacun des 2 moteurs
  • 1 pin en plus pour brancher un contrôleur de moteur pas à pas dans le futur (évolutivité du kit)
• 8 sorties:
  • +5V : alimentation de l'encodeur
  • +Vcc: pour l'alimentation des moteurs
  • 2 GND
  • les 4 sorties des moteurs

Nous disposerons ces pins de manière logique par rapport à l'ordre de entrées et sorties sur le composant électronique du contrôleur moteurs.

Les pins doivent être également judicieusement choisis par rapport à l'emplacement des pin sur le microcontrôleur ATMega2560.

Logiciel Ardublock

D'autres recherches sur la création de blocs sous Ardublock nous ont amené à découvrir un nouveau moyen de réaliser ses blocs sans utiliser Eclipse.

Lors du téléchargement de Ardublock nous obtenons une archive. Dans Arduino\tools\ArdublockTool\tool\ardublock-all-20130712\com\adublock\Block nous pouvons créer nos différents blocs en modifiant à 3 fichiers:

• ardublock.xml décrire tous les blocs boutons, connexion, choix multiples et autres.

• ardublock.properties faire la déclaration pour les noms.

• bloc-mapping.properties connecter les « noms » avec des fichiers de classe.

Semaine 4

Carte Principale

Nous avons continué le schématic de la partie ATMega2560, nous avons rajouté les différentes capacités de découplage, le bouton reset, les leds témoins, et la partie Quartz.

Avant l'étape de routage, nous avons besoin de l'empreinte de chaque composant. Il nous faut alors rechercher et/ou créer des librairies pour les composants à utiliser. Cette étape a été bien plus fastidieuse et longue que prévu. Nous pouvons récupérer certaines empreintes sur les sites des fournisseurs de composants électroniques (Mouser, RS, etc...). Pour les autres nous nous basons sur les schémas et les cotations fournies par leur datasheet.

Pièces du kit

Nous avons comme objectif de modéliser une vingtaine de pièces avec l'outil de modélisation en ligne TinkerCad. Nous pouvons extraire nos fichiers en .stl pour les pièces en 3D et ainsi les imprimer grâce à l'imprimante 3D du Fabricarium. Enfin, nous pouvons extraire les en .csv pour les fichiers 2D et ainsi pouvoir imprimer nos pièces avec du plexiglas grâce à la découpeuse laser.

Semaine 5

Protocole I2C

Nous avons choisi d'utiliser des ATtiny 85 pour la partie I2C. L'ATtiny 85 est un microcontrôleur d'Atmel (même famille que l'ATmega des Arduino). Nous nous sommes intéressé à ce composant que nous l'avions déjà plusieurs fois utilisé dans des petits projets personnels. Ce petit composant est plutôt facile à inclure dans un projet, il est compacte et peu cher.

Les ATTiny ne disposent pas à proprement parler d'une stack I2C ou TWI, mais intègrent un USI (Universal Serial Interface) qui peut se programmer pour communiquer en I2C.

L'avantage d'utiliser un microcontrôleur plutôt qu'un composant dédié purement à l'I2C avec des entrées digitales, est de pouvoir utiliser des capteurs avec un fonctionnement un peu plus complexe qu'un fin de course. Par exemple, pour un capteur Ultrasons nous avons besoins d'émettre une onde sonore, de mesurer le temps que met l'onde pour atteindre un objet puis de rebondir sur lui et de revenir. Avec un ATtiny85 nous pouvons alors inclure les étapes de calcul dans le contrôleur et directement communiquer la distance mesurée en I2C.

Nous utiliserons de ATtiny 85 en CMS par soucis d'encombrement (pour prendre moins de place).

Partie Électronique

Choix de la partie alimentation de la carte:

• Nous souhaitons pouvoir alimenter la carte entre 6V et 12V afin d'alimenter directement les moteurs, sans sources extérieur.
• Les moteurs ayant une consommation sous 6 Vcc à vide de 0,1 A et bloqué de 2,7 A nous nous orientons sur une solution permettant de transmettre assez de courant.
• Cette alimentation doit pouvoir être transformer de manière dynamiquement en 5V pour l'alimentation des contrôleurs et des capteurs. En effet la tension des batteries lithium que nous utiliserons a tendance à varier avec son état de charge. Le composant doit donc être capable de transformer n'importe quelle tension en 5V constant.
• La partie 5V doit débiter assez de courant pour pouvoir alimenter tous les capteurs que nous brancherons dessus ainsi que potentiellement des servomoteurs si l'utilisateur final souhaite en rajouter.

La solution retenue est la suivante: Pour la partie alimentation des moteurs, celle ci sera reliée directement à l'alimentation générale. Nous n'oublions pas d'inclure un interrupteur permettant de couper facilement l'alimentation de la carte via les batteries lithium. Le port d'entrée se fera par un port Jack 5.5mm pour faciliter le branchement.

Pour la partie convertisseur vers 5V nous avons choisi le composant: TPS54331[51]
Ce dernier est un Step-Down DC/DC permettant sur une alimentation de 3.5V à 12V de ressortir une tension de 5V sous une limite de 3A suffisante pour notre application. En parcourant la data sheet du constructeur, il est alors facile de reconstituer le circuit grâce aux formules et exemples fournis. Nous y ajouterons un fusible réarmable adapté pour protéger le circuit et un transistor pour pouvoir basculer en priorité sur l'alimentation sur batterie quand le port USB est également branché.

Semaine 6

Carte Principale

La carte est pratiquement terminée. Le routage touche à sa fin et ne fut pas évident au vu du nombre de pistes et à la contrainte de l'emplacement des contrôleurs moteurs. L'autre contrainte est la taille des pistes, plus le courant qui doit passer dedans est élevé, plus les pistes doivent être larges. Il faut ensuite lui rajouter des trous pour pouvoir placer plus facilement la carte sur le robot. Pour finir, il faudra alors la faire vérifier par un enseignant et lancer sa production.

Pièces du Kit

Nous avons modélisé la plupart des pièces du Kit, nous en avons imprimé en 3D pour voir le rendu : il nous reste les donc les roues et les chaînes à modéliser.

Cf : voir tableau Résumé des éléments du Kit à la fin du Wiki pour avoir les fichiers SVG et STL

Protocole I2C

Nous allons, à l'aide d'un logiciel, créer des PCB pour mettre dessus les ATtiny85 et permettre la connexion I2C entre les différents capteurs. Deux choix s'offrent à nous: chaque PCB peut contrôler 1 ou plusieurs capteurs. L'avantage d'en contrôler 2 est évident mais nécessite des fils.

Nous allons créer 5 cartes différentes pour les 5 capteurs. Certaines cartes accueilleront 2 capteurs identiques et d'autres plusieurs

Chaque carte comprendra:

• une entrée et une sortie: la connexion entre les cartes se fera par des câbles RJ12 afin de disposer d'un système de branchement facile.
• l'ATtiny85 (pour les capteurs tout ou rien)ou ADS (pour les cateurs analogiques)
• un ensemble de 6 pins afin de pouvoir la connecter à la carte principale et pouvoir programmer l'Attiny en ICSP
• Des pins JST pour pouvoir connecter facilement un capteur

Semaine 7

Carte principale

Création des cartes des driver moteur à connecter à la carte principale. Nous avons choisi le contrôleur TB6612FNG[52] qui permet de contrôler 2 moteur DC et peut délivrer jusqu'à 1,2A en continu et 3,2A en impulsionnel pour une alimentation maximale de 15V. Ce composant est donc parfaitement adapté aux moteurs que nous avons sélectionnés. L'avantage est également d'avoir un composant CMS compacte afin de sauvegarder le maximum de place. A l'image du contrôleur délivré par Adafruit[53], nous assurons une protection contre le "Reverse-power" grâce à un transistor.

Protocole I2C

Nous continuons à créer les cartes I2C pour les capteurs (distance SHARP, gyroscope, lignes, fin de courses, ultrason). Nous utilisons le logiciel Eagle pour cela.

Pièces du KiT

Nous avons commencé à modéliser les dernières pièces : les roues, la pince et la chaîne.

Pince modélisée pour le kit

La modélisation de la chaîne a été particulièrement complexe. Cette chaîne sera composée de différents maillons que nous pourrons assembler pour modifier la longueur de celle ci. Nous avons opter pour un assemblage sans vis, uniquement grâce à l'impression 3D. Nous n'auront ainsi pas besoin d'acheter de pièces supplémentaires. Il suffira juste de glisser un morceau de filament de 1.75mm d'imprimante 3D dans les maillons pour les assembler entre eux.

L'idéal aurait été d'imprimer les maillons grâce à un filament flexible de type TPU qui aurait l'avantage d'améliorer l'adhérence de la chaîne. Cependant ce type de filament est très cher et difficile à imprimer. Nous resterons alors sur un filament en PLA classique. Pour l'adhérence, nous rajouterons une bande de colle chaude au pistolet à colle.

Semaine 8

I2C

ADC(ADS1015)

Le gyroscope n'a pas besoin d'ATtiny85 car il est déjà programmé pour l'I2C.

Voici les différentes cartes à base d'ATtiny85 (pour réaliser le protocole I2C) que nous voulons réaliser :

• fin de courses: 2 sur une même carte
• ultrason: 1 par carte
• suiveur de ligne: 2 par carte

Nous ne pourrons pas mettre plus de capteurs par carte en raison du nombre d'entrées/sorties limitée puisque les ports d'I2C en occupent déjà 2.

Le capteur SHARP nécessite un ADC (analogic to digital). Nous n'utilisons donc pas un ATtiny85 mais un ADS1015 qui contient une interface I2C.

L'ADS1015IDGST est un convertisseur de précision Analogique-Numérique (ADC) avec une résolution de 12 bits. Il a une faible consommation en courant. Il comporte une référence et un oscillateur intégrés. Les données sont transférées via une interface série compatible I2C, quatre adresses esclaves I2C peuvent être sélectionnées grâce au pin ADDR. Il fonctionne avec une alimentation unique allant de 2,0 à 5,5V.

Voici les différentes adresses que peut prendre l'ADS1015 en reliant le pin ADDR à un autre:

• ADDR to Gnd: address = 0b01001000 = 0x48 = 72
• ADDR to VDD: address = 0b01001001 = 0x49 = 73
• ADDR to SDA: address = 0b01001010 = 0x4A = 74
• ADDR to SCL: address = 0b01001011 = 0x4B = 75

Pièces du KiT

L'engrenage et la roue sont prêts. Nous les avons réalisés sous OnShape.

Engrenage : 56 dents, épaisseur 4mm, dents de 2mm, diamètre 58mm, module 1, diamètre primitif 56mm (58-2*(2/2))
Roue : 90 dents, épaisseur 8mm, dents de 1mm, diamètre 58mm, module 1, diamètre primitif 57mm (58-2*(1/2))

Carte principale et cartes moteurs

Nous avons fait vérifier les différentes cartes électroniques auprès de l'enseignant Alexandre Boé. En prenant en compte ses remarques nous avons amélioré les schématiques et le routage de la carte, notamment concernant le quartz de l'ATMEGA2560 qui n'était pas assez isolé des autres pistes de la carte. Cela aurait pu générer des interférence et perturber l'horloge du contrôleur. Il a également fallu rajouter des capacités de découplage à plusieurs endroits. Après cette correction nous pouvons enfin valider notre liste de matériel. Certains composants n’étant plus en stocks entre le début du routage de la carte et le moment d'envoyer la commande. Il a donc fallu en choisir d'autres et redessiner en urgence par nous même leur empreinte pour la carte, notamment pour les interrupteurs donc l'empreinte n'est pas standardisée. Pour cela nous avons créé notre propre librairie contenant les composants dessinés en se basant sur les Datasheets constructeur. La carte principale est terminée, nous allons la faire imprimer.

Carte + Fichier gerber + Fichier Eagle	Schematic	Board	Composants
Carte "Arduino" Média:Carte_principale_+_correctif.zip			Micro contrôleurs: 1x ATMEGA2560-AU[54] 1x ATMEGA8u2[55] Alimentation: 2x Diode suppresseur ESD PGB1010603MR [56] 1x Perle de ferrite BLM21 [57] 1x FDN340P MOSFET [58] 2x SS34 Diode/Redresseur [59] 1x Fusible réarmable 500mA [60] 1x Fusible réarmable 1,5A [61] Résistances CMS 0603: 1x Réseau de résistances 1K CAY16 [62] 7x Résistance 10K [63] 2x Résistance 1M 1x Résistance 1,91k 1x Résistance 29,4K [64] 2x Résistance 22r [65] 3x Résistance 220r [66] Condensateurs: 1x Condensateurs électrolytiques en aluminium - CMS 470UF [67] 1x Condensateurs électrolytiques en aluminium - CMS 330uF [68] 4x Condensateurs électrolytiques en aluminium - CMS 100uF [69] 13x Condensateur céramique 100nF [70] 1x Condensateur céramique 0603 1uF [71] 2x Condensateur céramique 0603 10uF [72] 4x Condensateur céramique 0603 22pF [73] 1x Condensateur céramique 0603 120pF [74] 1x Condensateur céramique 0603 68pF [75] Connectique: 1x Régulateur de tension TPS54331D [76] 1x Connecteur USB-B [77] 1x Interrupteur Reset [78] 1x Commutateur à glissière [79] 1x Power jack 3,5A minimum Leds: 2x led jaune CMS [80] 1x led rouge CMS [81] 1x led verte CMS [82] Autre: 2x Quatrz 16MHz[83] 1x Inductance 6.8uH [84]
Contrôleurs moteurs Média:Controleur_moteurs_P46_IMA4.zip			Pour 1 contrôleur moteur (pour le projet on en aura besoin de 4): Résistances CMS 0603: 1x Résistance 220r [85] 1x Résistance 10K [86] Condensateurs: 3x Condensateur céramique 0603 10uF [87] 3x Condensateur céramique 0603 100nF [88] Autre: 1x Contrôleur de moteurs TB6612 [89] 1x led verte CMS [90] 1x Transistor DMG3415U-7

Semaine 9

Cartes I2C

Nous continuons le routage des cartes I2C pour les 5 différents capteurs. Nous allons les faire vérifier par un enseignant et allons lancer leur production à Polytech à partir de la semaine prochaine. Nous avons déjà les composants pour souder.

Châssis

Pièces du Kit

Avec la plupart des pièces que nous avons découpé à la découpeuse laser ou imprimé en 3D nous avons construit un chassis pour un exemple de Robot. Les moteurs des roues sont en place. Nous avons défini un espace pour placer la carte principale. Nous réfléchissons à l'endroit où sera placé la pince ainsi que les cartes I2C des capteurs. Nous essayons de faire un modèle de Robot optimal qui serait facile à mettre en œuvre et utiliserait tous les capteurs.

Programmation

Nous avons commencé à réaliser des tests sur un ATtiny85 (celui-ci traversant) pour la programmation des capteurs. L'objectif de test est de récupérer la valeur d'un bouton connecté sur l'Attiny et d'envoyer sa valeur sur requête de l'arduino en I2C. L'arduino est connecté en tant que Master et l'Attiny en tant que Slave.

Plusieurs librairies Opensource existent sur Internet pour faciliter cette démarche. Mais beaucoup ne sont plus à jour où fonctionnent avec un retard important. Après plusieurs test nous avons trouvé la librairie suivante[91] qui a l'avantage de pouvoir fonctionner par interruption.

Dans un premier temps, l'ATtiny85 n'est pas directement programmable via un port USB. Pour cela de nombreux tutoriels existent proposant de le programmer grâce à un arduino, comme celui-ci[92]. Nous réalisons donc, en s'inspirant de ce tutoriel, un shield pour Arduino UNO permettant facilement de programmer l'ATtiny traversant avec des Leds permettant de visualiser lorsque le téléversement du programme est en cours où qu'une erreur est survenue. Coté arduino, il suffira de lui téléverser l'exemple "ArduinoISP". Puis pour téléverser le programme il suffit alors de connecter l'ATtiny sur le shield, et de sélectionner le profil ATtiny85 et le profil de téléversement "Arduino as ISP" sur l'IDE.

Tout est maintenant réunit pour effectuer les tests. Voici le code adapté pour l'esclave:

#include <TinyWireS.h> 
#define I2C_SLAVE_ADDRESS 0x34 // Address of the slave 
#define LED PB3
#define Bouton PB4

uint8_t capteur;
void setup()
{
    TinyWireS.begin(I2C_SLAVE_ADDRESS); // join i2c network
    //TinyWireS.onReceive(receiveEvent); // not using this
    TinyWireS.onRequest(requestEvent);
 
    // Turn on LED when program starts
    pinMode(LED, OUTPUT);
    pinMode(Bouton, INPUT);
    digitalWrite(LED, HIGH);
}
 
void loop()
{
    // This needs to be here
    TinyWireS_stop_check();
}
 
// Gets called when the ATtiny receives an i2c request
void requestEvent()
{
    capteur = digitalRead(Bouton);
    TinyWireS.send(capteur);
}

Et maintenant le code du maître:

#include <Wire.h>
#define I2C_SLAVE 0x34
void setup()
{
 Wire.begin(); // join i2c bus (address optional for master)
 Serial.begin(9600); // start serial
}
 
void loop()
{
 Wire.requestFrom(I2C_SLAVE, 1); // request 1 byte from slave device address 0x34 
 while(Wire.available()) // slave may send less than requested
 {
  int i = Wire.read(); // receive a byte
  Serial.println(i); // print the byte
 } 
delay(50);
}

Semaine 10

Carte Principale et cartes moteurs

La carte principale et les cartes moteurs sont arrivées. Nous avons commencé la soudure cette semaine.

Pour la connexion des contrôleurs moteurs nous avons imaginé une astuce pour éviter que l'utilisateur ne le branche à l'envers. Pour cela sur la carte nous soudons à la place de la rangée gauche de pins des pin mâle et à droite des pin femelles. Ainsi le contrôleur ne peut pas être branché à l'envers.

Lors de la soudure des composants nous nous sommes rendus compte que la librairie du contrôleur de puissance récupérée sur le site du fournisseur était erronée. Des pins étaient inversés. Pour palier à ce problème nous ferons imprimer à Polytech juste la partie servant à transformer la tension batterie en 5V. Cette partie viendra se souder sur les pins de la carte par dessus l'ancienne partie. La carte correctrice et la correction de la carte sont présente dans le .zip de la carte principale du tableau précédent

Batteries

Concernant l'alimentation , nous avons besoin de batteries débitant assez de courant et ayant une tension assez élevé pour les moteurs. Plusieurs choix s'offrent à nous:

• Alimentation par pile de 1,5V: Nécessite de brancher 6 piles en séries pour obtenir un tension correcte de 9V, de plus elles se déchargent assez vite. Donc à éviter
• Pile 9V: Tension correcte mais courant insuffisant
• Batterie Li-Po: Très bonne autonomie et bonne tension mais encombrante et dangereuse
• Batterie Lithium 18650, 3.7V: Nécessite 2 batteries en série pour une tension correcte, courant de de sortie suffisant et excellente autonomie.

Ce sont les batteries 18650 qui nous offre un meilleur rapport vis à vis des performance, de l'encombrement et de la facilité d'utilisations. Par chance il nous restait chez nous 2 batteries 18650 que nous utilisions pour des projets personnels, nous n'aurons donc pas besoin d'en racheter.

Carte I2C

Nous avons fait vérifier les cartes des 5 capteurs par un enseignant. Nous avons rencontré un problème : elles ne sont réalisables à Polytech. Nous allons donc les refaire d'une autre manière: nous n'allons plus faire une carte pour chaque capteur mais une carte pour les capteurs avec ATtiny, une avec l'ADS et une pour le gyroscope qui ne nécessite pas de micro-contrôleur. Nous n'aurons donc pas les cartes pour les vacances. Nous allons les souder à la rentrée et allons tout de même continuer à faire la programmation du Kit pendant les vacances car nous possédons un ATtiny non CMS que nous pouvons utiliser grâce à une BreadBoard.

Semaine 11

Carte Principale et cartes moteurs

Les contrôleurs moteurs et la carte principale sont soudés et testés au multimètre. Nous terminons de souder la nouvelle carte de puissance.

Nous commençons à tester les cartes.

• Carte principale: Nous avons réussis à installer le bootloader sur l'Atmega8u2. Cependant l'ATMega2560 ne répond pas.
• Contrôleur Moteur: nous n'avons soudé que 2 contrôleurs pour nos tests, il fonctionnent parfaitement, nous pourrons en souder d'autres au besoin.

Carte I2C

Finalement nous ne faisons pas de carte pour le Gyroscope. Nous avons donc 2 modèles de cartes : 1 carte pour les 2 capteurs Sharp, 1 carte ATtiny pouvant être adaptée pour les capteurs ultrasons, fin de lignes et fin de course. Nous les avons envoyé pour être imprimées.

Carte + Fichier gerber + Fichier Eagle	Schematic	Board	Composants
Carte Sharp Média:Carte_Sharp_P46_IMA4_2018_2019.zip			1x ADS Résistances et Capacités CMS 1206: 2x Résistance 10K 3x Capacité 100nF 2x Prise RJ25
Carte ATtiny85 (capteur de ligne, ultrasons, fin de course) Média:Carte_ATtiny_85_P46_IMA4_2018_2019.zip			Pour 1 ou 2 capteurs du même type (pour le projet on aura besoin de 5 cartes): 1x ATtiny85 Résistances et Capacités CMS 1206: 5x Résistance 10K 3x Capacité 100nF 2x Prise RJ25

Pièces du Kit

Nous avons à ce jour modélisé 2 types de roue pour le Kit :

• des roues adaptées pour la chenille
• des roues sans chenille

Nous cherchons maintenant à créer un système de bras pour le robot permettant de lever et baisser la pince pour saisir un objet. Nous imaginons alors un système relié à un engrenage qui, entraîné par un moteur à courant continu, permettra de faire monter et descendre le bras. Cependant la plupart des petits moteurs que nous avons à disposition chez nous ou à Robotech ne possèdent pas assez de couple à l’arrêt pour maintenir le bras en position haute. Lors de nos tests nous avons par exemple testé les moto-réducteurs jaunes que nous pouvons trouver un peu partout dans les kits de robotique débutants. Le réducteur possède assez de couple à l'arrêt pour maintenir le bras en position haute mais pas en position moyenne. De plus à pleine puissance il avait du mal à faire monter ce bras. Nous sommes finalement parvenu à trouver à Robotech un moteur avec un couple à l’arrêt et en fonctionnement suffisamment conséquent. Le moteur est cependant bien plus encombrant que les autres. En effet le couple d'un moteur DC est directement lié à ses dimensions, typiquement plus un moteur est large, plus il possède un couple important, de même, plus un moteur est long, plus il pourra/aura une vitesse de rotation maximale élevée.

Nous modélisons alors la pièce qui servira à fixer le moteur ainsi que l'engrenage qui sera disposé sur son arbre. Nous dimensionnons l'engrenage de façon à avoir un coefficient de réduction correct sur la vitesse de rotation pour ne pas relever ou baisser trop rapidement le bras. Sur la pièce moteur, au lieu de mettre de simples trous pour fixer le moteur sur le bras, nous optons pour des "slots" (mix entre cercles et rectangles) pour pouvoir ajuster le moteur correctement. Nous appliquerons cette technique aux supports des moteurs afin de pouvoir régler la tension de la chenille.

Tous les fichiers sont disponibles dans le tableau récapitulatif des pièces du Kit.

Semaine 12 & 13

Librairie Arduino

La création de la librairie Arduino a pour but de simplifier la programmation de notre kit. Elle est codée en C++ et est constituée d'un ou plusieurs fichiers .h où seront déclarés les classes ainsi que le fichier .cpp où seront explicitées les fonctions des classes. De nombreux exemples doivent également être inclus pour guider les utilisateurs dans le maniement de la librairie.

Ici nous n'expliciterons pas les classes dans leur entièreté pour ne pas que cela soit indigeste.

Nous ferons le choix de diviser notre librairie en 4 fichiers .ccp et .h :

• Driver_moteur : cette partie déclare la classe représentant les moteurs encodeurs. Ses attributs sont entre autre les pins sur lesquels il est connecté, les paramètres mécaniques du moteur et les différentes valeurs déduites des encodeurs: vitesse réelle/voulue, nombre de pulsations, etc...

Parmi les fonctions, on y trouvera trois modes de mouvements différents:

• • Contrôle du moteur par PWM
  • Contrôle du la vitesse en rpm du moteur. Ici on implémentera un régulateur fonctionnant grâce aux valeurs reçues de l'encodeur. Un simple régulateur P suffira, nous n'avons pas besoin d'être particulièrement précis sur la vitesse du moteur.
  • Contrôle du moteur en position. On y trouve là l’intérêt principal de l'encodeur sur un moteur à courant continu. On peut ainsi contrôler l'angle de l'arbre moteur (et des roue) avec un moteur bien plus léger et moins volumineux qu'un moteur pas à pas. Ici on implémente non pas un simple régulateur P mais un régulateur PD qui permettra d'atteindre un angle donnée de la manière la plus optimisée possible.

Nous avons dû effectuer de nombreux tests pour trouver les paramètres des régulateurs.

• MotorDC: cette partie est dédiée au contrôle des moteurs à courant continu simples grâce aux contrôleurs moteurs. On y déclarera la classe MotorDC mais aussi deux classes héritières pour la pince et le bras. Pour ces dernières on aura alors des fonctions plus parlantes comme "open()" et "close()" ou encore "up()" et "down()". Elles auront comme attributs les pins sur lesquels le moteur est branché.

• Sensors_kit: On définit ici les classes pour chaque type de capteur et les fonctions permettant de recueillir leurs valeurs.

• MyRobot: la classe présente dans cette librairie représente le robot où on lui attribuera un moteur gauche, un moteur droite, des capteurs, etc... On y renseignera également la largeur entre les roues du robot ainsi que leur diamètre. Ces valeurs permettent alors de créer des fonctions d'odométrie comme "avancer de 10cm" ou encore "tourner à droite de 90 degrés". On y trouvera également une fonctionnalité pour être contrôlé en Bluetooth.

On y voit là tout l’intérêt des moteur encodeurs pour réaliser ces fonctions d'odométrie. Vous trouverez les fonctions d'odométries dans les diapositives suivantes issues d'une compétition réalisé par l'un des membre de notre binôme.

A chaque classe ainsi créée on écrira un programme d'exemple pour montrer l'utilisation de chaque fonction.

Le développement de la librairie a pris énormément de temps: 4h par jour de travail pendant 2 semaines. Le plus long a été la partie sur l'encodeur qui possède un fonctionnement bien particulier. En effet outre la programmation et quelques 1300 lignes de code plus tard, il a fallu tester les programmes et les corriger en conséquence.

Vous retrouverez le GitHub de la librairie ci-dessous. Il ne faudra également pas oublier d'installer la librairie correctement comme décrit sur le GitHub.

• Lien du repository GitHub de la librairie

Application Bluetooth

Pour la création de l'application bluetooth sur Android destinée à contrôler le robot nous nous sommes orienté vers Appinventor. N'ayant pas de connaissances préalables sur le développement d'applications mobiles et surtout de communication en bluetooth, Appinventor est un outil parfait pour les débutants et permet d'économiser du temps. De plus, il propose des outils simplifiés pour la communication en bluetooth.

Visuel de l'application

Après s'être familiarisé avec le logiciel, nous avons programmé une application de base permettant de transmettre un octet à un module bluetooth HC-05. Il faut maintenant choisir les fonctionnalités de l'application vis à vis du robot. Nous avons décidé d'implémenter les fonctionnalités de base du robot, à savoir avancer, reculer, tourner à gauche, tourner à droite, monter le bras, descendre le bras, ouvrir la pince et fermer la pince. Un "slider" permet de régler la vitesse du robot.

Pour l'envoi des données nous nous sommes accordé sur l'envoi des données sous 1 seul octet. Ce format a pour avantage de limiter les erreurs causées par l'envoi de plusieurs octets et améliorer le temps de réponse du robot. Nous disposons de 9 boutons, nous avons donc besoin de 4 bits pour coder le bouton appuyé. Ils se trouveront sur les bits de poids faible. Il reste donc les 4 bits de poids fort pour encoder la vitesse soit 15 valeurs possibles. Il faut donc limiter la plage de vitesse autorisées. Nous avons choisi une sélection de la vitesse par pas de 10% (min=10%, max=100%) donc 9 valeurs différentes.

Par exemple: 0xA2 = 0b1010 0010 demande au robot d'avancer à la vitesse 100%

En parallèle nous passons notre module bluetooth en mode AT pour lui changer son nom et son mot de passe. Il s'appelle maintenant "ArduinoKitP46" et a pour mot de passe 0000. Pour se connecter au module via l'application il faudra qu'il soit précédemment connu en l'enregistrant dans les paramètres bluetooth du téléphone.

Apk de l'application mobile Androïd: Fichier:ApkRobotKit.zip

Code de l'application

Programmation Blockly Arduino

Après les différents renseignements collectés, nous en avons déduit que la création d'une nouvelle librairie sur Ardublock est un travail extrêmement long et trop complexe pour un rendu final peu attractif. Après de quelques recherches nous sommes tombés sur Blockly, un outil de programmation en blocs sur navigateur créé par un enseignant français. Il a la particularité d'être plus récent qu'Ardublock, d'avoir une interface de travail plus accueillante et surtout d'être ouvert à l'ajout de nouvelles librairies de blocs. Cette dernière fonctionnalités est très bien documentée sur le site suivant, ce qui rend notre tâche plus facile.

Pour ajouter des blocs à Blockly nous "forkons" le code source de la page disponible sur le GitHub de Blockly. La programmation se fait en Javascript et en HTML. Dans le dossier "Blockly-at-rduino/blocks/", nous venons créer un dossier où 2 fichiers seront présents. Le premier permet de définir les visuels du bloc, ses entrées, sorties, type, etc... Le deuxième fichier permet de faire le lien entre les blocs créés et les fonctions Arduino associées qui se trouvent elles dans un nouveau fichier dans le dossier "Blockly-at-rduino/generators/arduino/". Dedans, nous récupérons les entrées du bloc et nous notons le code Arduino correspondant.

Ainsi nous traduisons chaque fonction de la librairie Arduino dans un bloc correspondant. Nous nous permettons d'y ajouter les couleurs afin de différentier les différentes sortes (fonctions liées aux encodeurs, fonctions liées au capteur, etc). Chaque bloc quand il est utilisé peut effectuer 4 sortes d'actions différentes sur le code .ino. Il peut écrire dans la loop, écrire dans le setup, définir des fonctions ou des variables globales et inclure des librairies. Lorsque le bloc n'a pas encore l'objet ou les fonctions qu'il utilise il vient les créer une fois pour toute et ils ne seront pas recréés par la suite. Ainsi pas de code inutile est créé et aucune déclaration de variable n'est nécessaire à l’exception de ce qui va suivre.

Nous avons tout de même créé 2 blocs spéciaux. L'un s'appelant "Générer le code pour le kit" permettra de déclarer des éléments et des fonctions de base du Kit. Une partie des éléments ainsi créés auraient pu être fait directement de la manière explicitée plus haut. Mais comme une autre partie ne peut être créée au fur et à mesure, nous avons fait le choix de le faire d'un seul coup via ce bloc de départ. Le deuxième bloc spécial est celui qui permet de définir en autre un modèle de robot en choisissant un moteur gauche et droit et qui nous renseigne des dimensions du robot pour l'odométrie. Étant donné qu'il est trop lourd de redemander ces informations dans chaque block lié à cette structure, ce dernier permet de la déclarer une fois pour toute.

Blockly Arduino avec notre librairie

Nous testons ainsi les éléments au fur et à mesure de leur programmation et nous observons leur comportement dans le code .ino qui est généré par Blocky. Les tests se font localement dans le répertoire en ouvrant le fichier index.html sur un navigateur web. Attention il se trouve que Chrome 64bits ne soit pas pleinement compatible avec l'application, il faudra donc passer par Mozilla ou Chrome 32bit.

Pour finir il faudra rajouter les différents blocs créés dans une librairie, pour cela il faudra remplir l'un des fichiers présents dans le dossier "Blockly-at-rduino/toolbox/" en y renseignant le nom de notre nouvelle librairie et le nom de chaque fonction. En fonction du fichier rempli, la librairie s'ajoute dans des catégories différentes: "niveau 1", "niveau 2" ... "all" qui permettent de classer toutes les librairies présentes par difficulté. Comme notre kit n'est pas destiné à être commercialisé il ne sera pas utile de publier nos modifications sur le répertoire git du créateur de l'application. Nous resterons alors sur un répertoire annexe et nous pouvons alors nous permettre de placer notre librairie comme librairie par défaut dans toutes les catégories pour la trouver facilement.

Pour résumé, nous sommes maintenant capable de programmer notre kit en blocs. Pour cela il suffit soit de télécharger le zip du projet sur github et de lancer index.html. Soit directement de lancer notre version du logiciel via github.

• Lien du repository github
• Repository Github avec uniquement les fichiers changés
• Lien de notre page web de programmation:

Une fois le logiciel lancé vous cliquerez sur "Configuring Blocks" pour venir importer notre librairie via l'une des catégories ("all" par exemple). En cliquant sur "view Source Code" vous aurez accès au code Arduino généré. Vous pourrez alors le coller dans l'IDE Arduino pour le téléverser dans l'Arduino. En effet le seul défaut de Blockly Arduino est que le téléversement vers une carte Arduino est possible directement depuis l'interface web, mais pas lorsque nous utilisons des librairies C++ externes comme celles que nous avons créé.

L'ensemble de la programmation ne fût non pas extrêmement complexe mais a nécessité un bon temps d'adaptation avant de connaître les différents paramètres de création de blocs. Ce fût également fastidieux de créer les blocs pour chaque fonction puis de les tester et de corriger les oublis de ";" ou de parenthèses qui se glissaient rapidement. L'ensemble nous a pris 20h de travail étalées sur une semaine.

Robot

Même si la carte principale ne fonctionne pas encore, nous faisons avancer notre robot en utilisant un ArduinoMega qui possède les mêmes caractéristiques que notre carte pour la programmation. Nous pouvons piloter le robot via une Application Bluetooth grâce à un module Bluetooth. Le robot adhère bien au sol grâce à la colle que nous avons mise sur chaque maillons de la chaîne. La pince est entièrement commandée et permet d'attraper des objets. Nous modélisons une pièce supplémentaire pour maintenir les moteurs encodeur puisqu'ils avaient tendance à pencher sous le poids du robot.

Semaine 14

Carte principale

Nous continuons les tests de la carte principale. Nous re-testons les connections des pins 1 à 1 au multimètre mais nous n'arrivons pas à la faire fonctionner. En observant le schématic nous avons décelé une seconde erreur sur la carte qui pourra perturber la communication entre le 8u2 et l'AtMega2560: Lors du tracé du schématic nous avons utilisé des noms qui permettent de relier des fils ensemble sans avoir à tracer le fil sur la feuille et ainsi créer des croisements et des nœuds de fils incompréhensibles. Mais pour le Rx0 du 2560 qui permet de communiquer en Série avec le 8u2, une erreur de frappe s'est glissée. Sur le routage les pistes n'ont alors pas été routés. Mais nous pouvons facilement contourner ce problème en soudant un strap sur la carte puisque nous avons eu la précaution de créé des via sur un maximum de pins non utilisé/relié de l'ATMega2560 lors de la conception de la carte. Nous restons cependant sur une programmation via le port ICSP pour ne pas être impacté par les potentiels problèmes existant sur le 8u2. Faisons un rappel sur le principe de la programmation par ICSP. Cette technique permet de téléverser un programme sur un arduino via un autre arduino. Pour cela nous avons besoin d'un Arduino UNO et de lui téléverser l'exemple "ArduinoISP". UN fois cela fait vous pouvez connecter les pin ICSP de cet Arduino (Mapping des pin à cette adresse) sauf le reset qui doit etre sur le pin 10, au port ICSP de l'Arduino que vous voulez programmer. Choississez maintenant votre programme, sélectionner votre Board, le port série de l'Arduino en ISP et choisissez le programmateur "Arduino as ISP". Pour téléverser le programme il faut cliquer sur "Téléverser en utilisant un programmateur" (Ctrl+Shift+U).

Nous avons également testé notre circuit de puissance. Bien que nous ayons scrupuleusement suivit la datasheet le contrôleur de puissance ne sort aucune tension. Nous vérifions chaque piste au multimètre, rien n'est court-circuité. Nous reviendrons aux test de cette partie plus tard, nous préférons donner priorité à la partie Atmega2560 qui est plus essentielle.

Cartes Capteurs I2C

Nous avons soudé les cartes I2C. Nous en avons 5 pour les capteurs utilisant un ATtiny85 et 2 pour les capteurs SHARP utilisant un convertisseur analogique-numérique. Les cartes seront chaînées à la suite les unes des autres grâce aux Câbles RJ25. Si nous le voulions, nous pourrions chaîner 128 cartes!

Cartes ATtiny85 en vert et ADC en bleu

Nous aurons besoin de:

• 1 carte pour chaque capteur ultrason (nous en avons 2)
• 1 carte pour les 2 suiveurs de ligne
• 1 carte pour les 2 fins de course
• 1 carte pour les deux capteurs SHARP

Pour le gyroscope nous n'avons pas créé de carte sous Eagle.

En ayant imprimé les cartes nous avons remarqué 2 erreurs:

• des pins sont un peu trop près d'un trou dans la carte
• un via pour faire le plan de masse a été ajouté afin d'avoir un plan de masse complétement réparti

Les modifications ont été effectuées et les fichiers sont corrigés en conséquence dans le Wiki.

Test des cartes I2C

Nous devons maintenant tester les cartes I2C. Pour cela nous reprenons le programme Arduino que nous avons testé précédemment sur bread board. L'objectif est de recevoir une donnée de l'Arduino pour savoir quel capteur il faut activer, puis quand l'Arduino le demande, lui envoyer la valeur de ce capteur.

Par exemple les requêtes:

• REQUEST_FINDECOURSE1 = 0x01 renvoie l’état du fin de course branché sur le port 1
• REQUEST_FINDECOURSE2 = 0x02 renvoie l'état du fin de course branché sur le port 2
• REQUEST_ULTRASONIC_MM = 0x03 renvoie la distance détectée par le capteur ultrason en millimètres jusqu'à 254 millimètres (pour être transmis sur 1 seul octet)
• REQUEST_ULTRASONIC_CM = 0x04 renvoie la distance détectée par le capteur ultrason en centimètres jusqu'à 254 centimètres (pour être transmis sur 1 seul octet)
• REQUEST_LINESENSOR = 0x05 renvoie l’état du capteur de ligne

L'avantage pour l'Ultrason par exemple est de recevoir directement la distance du capteur sur l'Arduino, aucune connaissance sur son fonctionnement est alors nécessaire. En effet, normalement, pour un capteur Ultrason, il faut émettre une impulsion sur le pin Trig du capteur pour émettre une impulsion sonore. Puis le son se propage, se répercute sur une surface et revient vers le capteur. Un signal est alors renvoyé sur le pin Echo du capteur. La différence de temps entre ces 2 signaux correspond au temps mis par l'onde pour effectuer un aller-retour. Avec la vitesse du son, soit 340 m/s, il est aisé de mesurer la distance entre l'obstacle et le capteur. Nous pouvons utiliser la formule suivante:

distance_mm = duree_microsecondes / 2.0 * (340.0/1000);

Avec 340.0/1000 étant la vitesse du son en mm/μs.

Le capteur de ligne est en réalité composé de 2 capteurs de ligne pour un bon fonctionnement d'un suiveur de ligne. Chaque capteur renvoie 1 (5V) lorsque du noir est détecté et 0 sinon. L'information du capteur de ligne envoyée est alors représentée sous la forme d'un octet où le (premier) bit de poids faible correspond à l'état du capteur droit et le 2eme bit au capteur gauche. Ainsi en un seul octet nous obtenons l'information des 2 capteurs. On a donc les résultats suivants:

• 0b0000 0000 = 0: Gauche=Blanc & Droite=Blanc
• 0b0000 0001 = 1: Gauche=Blanc & Droite=Noir
• 0b0000 0010 = 2: Gauche=Noir & Droite=Blanc
• 0b0000 0011 = 3: Gauche=Noir & Droite=Noir

Les codes sont disponibles dans les exemples de la librairie qui est disponible sur notre repository github: Lien des exemples

Semaine 15

Carte Principale

Le débogage de la carte Principale avance. En observant la sortie du Quartz de l'ATMEGA2560 nous nous sommes rendu compte que celui ci n'oscillait pas. Nous l'avons donc changé avec un nouveau. Lors de la soudure du nouveau Quartz, la pastille de soudure inférieure de la carte a sauté, il a donc été soudé par dessus, d'où le rendu étranger que vous pourrez observer. Malgré cet imprévu le Quartz oscille bien à 16MHz à l'oscilloscope. 1 Problème de réglé! Mais la carte ne fonctionne toujours pas et avec nos encadrants nous ne comprenons pas le problème. Mr Redon propose alors 2 solutions:

• soit le contrôleur n'a pas résisté à la soudure au four
• soit certaines soudures sur l'ATMega ne seraient pas assez prononcées.

Après avoir renforcé les soudures le contrôleur répond enfin! Nous pouvons téléverser le bootloader de la carte et téléverser un premier programme Blink sur la Led13 pour vérifier son bon fonctionnement.

Une étape de franchie, mais les problèmes s’enchaînent. Nous ne parvenons pas à téléverser nous même en ICSP un programme sur la carte. Après des recherches avec nos encadrants, nous avons découvert l'article suivant: "ArduinoasISP" upload fail Pour résumer cet article, il existe un conflit dans le code source du logiciel Arduino sur Linux qui empêche d'utiliser l'Arduino as ISP. En effet pour le fonctionnement sur Windows une structure récursive a été utilisée, mais qui ne fonctionne pas sur Linux. Il faudra donc trouver le fichier "programmers.txt" et modifier les lignes suivantes:

Carte Principale

• Remplacer "arduinoasisp.protocol=arduino" par "arduinoasisp.protocol=stk500v1"
• Remplacer "arduinoasisp.program.protocol=arduino" par "arduinoasisp.program.protocol=stk500v1"

stk500v1 étant le programmeur par ICSP.

Nous pouvons enfin téléverser par nous même des programmes sur la carte. Nous remercions particulièrement Mr Redon et Mr Boé pour nous avoir beaucoup aidé et pour le temps qu'ils nous ont consacré pour la faire fonctionner.

Cependant malgré le strap nous ne pouvons toujours pas téléverser de programmes via la liaison série entre le 8u2 et le 2560. Nous essayons de dessouder le réseau de résistance de cette liaison série qui semble défectueux et d'y souder à la place de nouvelles résistance disposées sur la tranche pour entrer dans l'empreinte du réseau. Mais le problème n'est toujours pas résolu, de plus l'une des led témoins de transfert à été endommagé lors du dessoudage du réseau avec le pistolet à air chaud qui était indispensable pour retirer ce composant. Nous vérifions une fois de plus au multimètre les soudures, tout semble normal.

Malheureusement nous avons encore beaucoup à faire et nous avons déjà perdu énormément de temps sur cette carte. Nous n'avons donc pas assez de temps supplémentaire à accorder à cette carte malgré notre souhait profond de la terminer complètement. Les derniers tests sur la partie convertisseur de puissance ne sont pas concluants non plus. Nous devrons alors utiliser 2 alimentations en attendant et téléverser les programmes en ICSP. La batterie Lithium servira à alimenter les moteurs alors que l'alimentation du 5V se fera via un câble USB sur Ordinateur ou via une batterie portable externe (celles qui permettent de recharger nos téléphones portable).

Nous positionnons alors la carte principale sur le robot et pouvons tester les moteurs directement dessus. Le contrôle se fait bien, la librairie arduino fonctionne bien dans l'ensemble. Il y a néanmoins la présence de quelques bugs que nous nous empressons de corriger. Nous arrivons enfin à piloter notre robot en Bluetooth avec notre propre carte électronique et non avec un arduino du commerce. Il nous faut alors passer à la mise en fonction des cartes I2C pour les capteurs.

Cartes Capteurs I2C

La carte I2C avec l'ATtiny fonctionnant correctement, il nous faut tester les cartes avec les ADS1015. En testant sur une carte, nous n'arrivions pas du tout à communiquer avec elle sur le bus i2C. Nous vérifions alors la carte au multimètre et nous observons alors un problème sur les résistance pull-up du bus. Au lieu d'avoir une valeur de 10kOhm comme l'indique l'écriture sur le boitier, celles ci ont une valeur de 5kOhm et ne peuvent alors pas fonctionner avec notre circuit. Par chance la seconde carte possède les bonnes valeurs de résistances alors que celles-ci possède le même code de valeur sur leur boitier. Nous poursuivons alors les tests sur cette seconde carte.

A l'aide de la datasheet de l'ADS1015 d'une librairie d'Adafruit[93] trouvée sur Gihub utilisant le même genre de composant, nous arrivons à comprendre et à instaurer la communication I2C. Les paramètres importants à régler sur le composant sont le gain du CAN (Convertisseur Analogique numérique) et sont le type de mesure (simple Pin, différentiel, etc...). Pour notre cas nous devrons régler notre ADS1015 en mesure "SingleEnded" puisque la lecture de la distance sur un Sharp se fait sur un seul pin.

Pour le choix du gain il existe ces diverses option:

 ads.setGain(GAIN_TWOTHIRDS);  // 2/3x gain +/- 6.141V  1 bit = 3mV      (default)
 ads.setGain(GAIN_ONE);        // 1x gain   +/- 4.094V  1 bit = 2mV      
 ads.setGain(GAIN_TWO);        // 2x gain   +/- 2.047V  1 bit = 1mV      
 ads.setGain(GAIN_FOUR);       // 4x gain   +/- 1.024V  1 bit = 0.5mV    
 ads.setGain(GAIN_EIGHT);      // 8x gain   +/- 0.512V  1 bit = 0.25mV   
 ads.setGain(GAIN_SIXTEEN);    // 16x gain  +/- 0.256V  1 bit = 0.125mV    

Pour comprendre ces valeurs il faut savoir que la donnée transmise par l'ADS1015 sur 12bits est sous la forme d'un entier signé allant de -2047 à +2047. Le gaine permet de régler la précisions du CAN. Pour le gain 2/3 par exemple, la précisions du convertisseur est de 3mV. Donc si le CAN nous renvoie la valeur 100, cela correspond alors à 100*3m=300mV. Nous pouvons alors croire que plus le gain est élevé, plus la précision est meilleure alors mieux c'est! Mais comme nous l'avons dit, la valeur maximale est 2047 donc pour un gain de 2/3 nous pouvons fonctionner jusqu'à 2047*3mV = 6,141V . Pour un gain de 1, la limite sera 2047*2mV=4,094V. Nos capteurs retournant une tension entre 0 et 5V, le gaine appropriée est le 2/3.

Nous nous inspirons alors de la librairie d'adafruit, pour créé la notre qui sera bien plus simple et adaptée à notre kit, en prenant soin de bien vérifier sur la datasheet les différents registres à utiliser. Les cartes I2C ADS1015 sont enfin opérationnelles. Nous recevons des données bruts, il nous reste à les traiter pour obtenir des valeurs exploitables.

Capteur Sharp

Principe de fonctionnement d'un capteur Sharp

Pour commencer il faut savoir qu'un capteur Sharp (nom de la marque) est un capteur de distance infrarouge. Ce dernier émet grâce à une led infrarouge un signal lumineux invisible de l'oeil humain. Ce dernier va être réfléchi par l'obstacle puis reviendra vers le capteur avec un angle d’incidence variant en fonction de la distance de l'obstacle. Avec une lentille, et une bande photoréceptrice, le capteur permet de détecter cet angle d'incidence avec lequel nous pourrons calculer la distance.

Pour pouvoir utiliser le capteur Sharp nous avons besoin de traduire ce que renvoie le capteur en centimètres. En effet la tension retranscrite par ce capteur n'est pas proportionnelle à la distance. Une courbe caractéristique (Tension en fonction de la distance) est fournie dans la datasheet mais l'équation n'est pas fournie et nous préférons la mesurer par nous même. De plus il existe de nombreux type de capteurs Sharp et même si la forme est semblable, chacun a une courbe caractéristique qui lui est propre. Pour cela nous avons effectué plusieurs mesures en mettant un objet à différentes distances du capteur (de 0cm à 50cm). Le but est d'obtenir une équation traduisant les cm en valeur Sharp et inversement.

Pour la courbe Valeur_sharp=f(Valeur_cm), nous savons qu'il sera difficile d'obtenir une équation exploitable. En effet, nous aurons premièrement un problème pour les valeurs de 0 à 3 cm car, au vu de la forme de pic de la courbe, les valeurs pour la capteur Sharp seront les mêmes entre 0 et 3cm que pour 3 et 8 cm. Nous ne pourrons donc pas être précis. Nous avons également un problème pour les valeurs du capteur Sharp après 33cm, elles sont quasiment toutes pareilles.

Cette courbe ne nous permet donc pas d'associer une valeur du capteur à une valeur en cm mis à part en optant pour une équation polynomiale d'ordre 5 minimum.

Nous avons donc fait un test avec la courbe 1/Valeur_sharp=f(Valeur_cm), nous observons qu'entre 3 et 33 cm la courbe est linéaire. Cela permet d'obtenir une équation pour traduire les valeurs en cm avec celles du capteur Sharp.

Nous avons donc refait les courbes en 1/Valeur Sharp entre 0 et 33cm pour obtenir l'équation de passage de cm à valeur Sharp et inversement.

Nous avons donc admis les équations suivantes :

1/Valeur_sharp = 0,0003*Valeur_cm + 0,0006

Valeur_cm = 2970,4*(1/Valeur_sharp) - 1,7651

Nous pouvons alors conclure que notre capteur n'est efficace qu'entre 3cm et 33cm. Au delà nous ne pourrons garantir à l'utilisateur la véracité de la mesure. C'est donc un capteur de proximité, là où le capteur ultrason servira à mesurer des valeurs au loin (jusqu'à 2 mètres minimum) pour par exemple détecter un obstacle éloigné, le Sharp servira plutôt à un algorithme de suivi de mur proche par exemple.

Semaine 16 / Dernière semaine

Nous terminons les tests des cartes I2C en les chaînant les unes à la suite des autres, nous parvenons à communiquer correctement avec elles et à traiter les données reçues par les capteurs branchées à elles.

Nous nous sommes rendu compte que nous ne disposions pas de solution de recharge pour les batterie 18650. Les chargeurs du commerce étant cher et n'ayant pas le temps de créer par nous même un contrôleur de charge, nous sortons de notre boite à électronique un composant bien pratique que nous pouvons acheter sur ce site[94] par exemple. Le TP4056 est un module de chargement pour les batteries 18650, il permet aussi de protéger la décharge de la batterie dans un circuit mais nous n'utiliserons pas cette dernière fonctionnalité. En effet nos batteries sont branchées en série sur notre robot et ce composant est prévu pour une seule cellule. Nous ne pouvons donc pas recharger et utiliser nos batteries sur le même "batterie holder". Nous récupérons ce modèle de "Battery charger 18650" directement sur Thingiverse pour gagner du temps du la conception. Nous imprimons le fichier puis nous soudons le composant sur notre chargeur de batterie. Nous testons avec précaution le système et tout fonctionne parfaitement. Voilà comment fabriquer un chargeur de batterie Li-ion 18650 pour moins d'1€.

Nous terminons de corriger les derniers bugs de la librairie et à peaufiner quelques détails.

Nous créons les câbles avec des pins JST pour avoir la longueur de notre choix et pouvoir brancher les capteurs sur la carte.

Nous avons tourné la vidéo de présentation de notre Projet.

Le Robot construit avec les éléments du Kit

La programmation des librairies est finie ainsi que l'interface de programmation par blocs.

Lien de téléchargement de l'application

L'application Bluetooth est prête à être utilisée : Fichier:ApkRobotKit.zip

Nous avons modélisé de nombreuses pièces pour le Kit. Elles sont toutes disponibles dans le résumé des éléments du Kit.

Les cartes capteurs contrôlés par ATtiny85 sont opérationnelles.

La carte pour le capteur Sharp fonctionne également. Nous avions décidé de contrôler nos deux capteurs Sharp sur la même carte. Nous avons finalement préféré avoir deux cartes différentes. Heureusement, nous avions soudé une carte supplémentaire (car nous avions assez de composants).

Nous n'utilisons pas finalement le gyroscope pour cause de manque de précision. Il aurait fallu le coupler avec accéléromètre et le faire fonctionner par interruption. Mais le timer2 d'interruption de l'arduino ne fonctionne pas avec la communication I2C car ils utilisent la même ressource. A cause de tous ces détails et par manque de temps nous ne permettons pas à notre Robot d'utiliser le gyroscope pour donner la position angulaire.

Néanmoins cette deuxième ne fonctionne pas alors que nous avons utilisé les mêmes composants que pour la première. Nous avons donc essayé de comprendre le problème de cette carte. Même si les résistances semblent être des résistances 10kΩ, nous avons découvert, au multimètre, que leur valeurs est de 5kΩ. Nous pensons donc à une erreur du constructeur. Cette erreur de valeur est fatale pour la carte car les résistances sont des résistances Pull Up.

Nous avons passé beaucoup de temps sur la carte principale et tout ne fonctionne pas comme nous le souhaitions. Nous ne pouvons plus nous permettre d’essayer de réparer les parties non fonctionnelles de la carte. Nous préférons nous concentrer sur les parties qui fonctionnent et utiliser la carte du mieux que l’on peut.

Résumé des éléments du Kit

Documents Rendus

Catalogue_des_pièces_du_Kit.pdf

Rapport_Projet_P46.pdf

Diaporama de Soutenance