Aller au contenu


Photo
- - - - -

BurnBot - Self Balancing Robot

balancing equilibre pas à pas

154 réponses à ce sujet

#21 Budet

Budet

    Membre passionné

  • Membres
  • PipPipPip
  • 355 messages
  • Gender:Male
  • Location:69

Posté 16 septembre 2017 - 06:05

J'ai acheté des roues de skateboard ! Je vais enlever les roulements et les coupler directement

#22 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 4 664 messages
  • Gender:Male

Posté 16 septembre 2017 - 06:11

J'ai acheté des roues de skateboard ! Je vais enlever les roulements et les coupler directement

Ben, non ! Tu vas avoir un gros trou !
Tu as la chance d'avoir un Nema17 avec un axe de 5mm.
Je pense qu'il faut en profiter et prendre des roues avec des axes de 5mm. Non ?

#23 Budet

Budet

    Membre passionné

  • Membres
  • PipPipPip
  • 355 messages
  • Gender:Male
  • Location:69

Posté 16 septembre 2017 - 06:19

Ne t'en fais pas, j'ai des moyeux qui me permettent de coupler l'axe de mes nema à mes roues



#24 Budet

Budet

    Membre passionné

  • Membres
  • PipPipPip
  • 355 messages
  • Gender:Male
  • Location:69

Posté 17 septembre 2017 - 10:35

Bonjour à tous,

Ma première pièce est enfin fini et je dois dire que l'impression s'est bien passé ! J'ai fais un premier montage rapidement pour voir si je n'avais pas loupé une côte mais aucun problème à l'horizon, tout es en ordre :)

Je vous laisse apprécier le résultat, n'hésitez pas à me dire ce que vous en pensé, l'autre pièce devrait être finis dans la soirée.

@Oracid : tu peux voir les moyeux sur la photo, il se connectent sur l'arbre grâce à une vis de pression et ils font parfaitement le même diamètre que les roulements qui etaient dedans du coup je peux les monter serrer (j'ai eu beaucoup de chance la dessus)

IMG_4664.JPG



IMG_4663.JPG

IMG_4662.JPG

#25 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 4 664 messages
  • Gender:Male

Posté 17 septembre 2017 - 01:19

Beau boulot ! Super l'impression.

#26 Budet

Budet

    Membre passionné

  • Membres
  • PipPipPip
  • 355 messages
  • Gender:Male
  • Location:69

Posté 19 septembre 2017 - 03:52

Salut à tous,

 

Juste un petit message pour vous faire par de l'avancée ! Le robot est complètement assemblé et il fonctionne (voir photo). 

 

J'ai un doute sur le couple des moteurs, le robot est plus lourd que ce que j'imaginais, lorsqu'ils sont à l'arrêt, roues bloquées et à 50% de leur couple maximal le couple ne suffit plus passé 15° d'inclinaison !

 

Je pense qu'à 100% du couple ça devrait suffire mais je sais dors et déjà que mon robot aura une vitesse limite ou le couple ne suffira plus, à espérer qu'elle soit la plus élevée possible.

 

Maintenant, la partie ou je suis le moins doué et ou j'aurais besoin de votre aide : le code.

 

IMG_4677.JPG

 

IMG_4674.JPG

 

IMG_4676.JPG

 

Je suis désolé, j'ai beau tourner mes photos dans tous les sens elles ne restent jamais droites quand je les upload ici



#27 Oliver17

Oliver17

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 2 732 messages
  • Gender:Male
  • Interests:Glenn

Posté 19 septembre 2017 - 04:44

Trop classe,  :thank_you:

 

Pour faire de petite retouche photo rapidement sans se prendre la tête, j'utilise FastStone image viewer, c'est gratuit et super utile.

 

http://www.faststone.org/FSViewerDetail.htm

 

Pour le code, désolé :'(


signature_01.png -->

 

Mon Tipeee
 


#28 arobasseb

arobasseb

    Membre chevronné

  • Modérateur
  • PipPipPipPip
  • 715 messages
  • Gender:Male
  • Location:BORDEAUX (33)
  • Interests:Informatique, robotique et sciences technique en générale.

Posté 19 septembre 2017 - 08:18

Pour le code, il faudrait que tu nous dises ce que tu as fait et où tu bloques.



#29 Budet

Budet

    Membre passionné

  • Membres
  • PipPipPip
  • 355 messages
  • Gender:Male
  • Location:69

Posté 19 septembre 2017 - 09:04

Je ne me suis pas beaucoup penché dessus mais je n'arrivais même pas à inverser le sens de rotation d'un des moteurs ! ^^

Je regarde bien et je vous dis ou je pèche

#30 Budet

Budet

    Membre passionné

  • Membres
  • PipPipPip
  • 355 messages
  • Gender:Male
  • Location:69

Posté 25 septembre 2017 - 07:38

Bon je galère sévère, j'ai besoin de votre aide !

 

J'ai écris un semblant de code histoire de tester certaines idées basiques et voilà ou j'en suis :

 

J'arrive à afficher l'angle d'inclinaison du robot en degrés en mettant le 0 à la verticale. Déjà la j'ai un problème de type "hardware", la lecture de mes valeurs ce stop des fois, surtout quand je touche le robot. J'en déduit que mes soudures ne sont vraiment pas bien faite et que certaines pistes perde le contact mettant ainsi fin à la liaison... Je verrais surement pour racheter un capteur déjà soudé parce que ce pas avec mon vieux fer que j'arriverais à faire mieux !

 

Ensuite comme vous pouvez le voir j'ai mis une simple boucle pour faire tourner mes moteurs dans un sens si l'angle est négatif et dans l'autre si il est positif tout ça a une vitesse constante, rien de bien compliqué mais forcément ça ne marche pas (les roues ne tournent pas), la dessus j'ai une petite idée du pourquoi mais je ne sais pas comment le régler...

 

j'imagine que mon roue1.runspeed() doit être répété plein de fois, un appel = 1 set ? mais du coup je trouve ça trop nul comme fonction vu que la vitesse du moteur dépend du nombre d'appel et pas de la valeur à l'intérieur...

 

Je suis un peu perdu, en terme de programmation ce projet est largement au dessus de mes compétences, pour le moment ;)

// I2Cdev and MPU6050 must be installed as libraries, or else the .cpp/.h files
// for both classes must be in the include path of your project
#include "I2Cdev.h"

#include <AccelStepper.h>         //Bibliothèque pour moteur pas à pas
AccelStepper roue1(1, 9, 6);      //Définition des moteurs 9 = step pin; 6 = pin direction
AccelStepper roue2(1, 8, 5); 

#include "MPU6050_6Axis_MotionApps20.h"
//#include "MPU6050.h" // not necessary if using MotionApps include file

// Arduino Wire library is required if I2Cdev I2CDEV_ARDUINO_WIRE implementation
// is used in I2Cdev.h
#if I2CDEV_IMPLEMENTATION == I2CDEV_ARDUINO_WIRE
    #include "Wire.h"
#endif

// class default I2C address is 0x68
// specific I2C addresses may be passed as a parameter here
// AD0 low = 0x68 (default for SparkFun breakout and InvenSense evaluation board)
// AD0 high = 0x69
MPU6050 mpu;
//MPU6050 mpu(0x69); // <-- use for AD0 high


// uncomment "OUTPUT_READABLE_YAWPITCHROLL" if you want to see the yaw/
// pitch/roll angles (in degrees) calculated from the quaternions coming
// from the FIFO. Note this also requires gravity vector calculations.
// Also note that yaw/pitch/roll angles suffer from gimbal lock (for
// more info, see: http://en.wikipedia.org/wiki/Gimbal_lock)
#define OUTPUT_READABLE_YAWPITCHROLL


#define LED_PIN 13 // (Arduino is 13, Teensy is 11, Teensy++ is 6)
bool blinkState = false;

// MPU control/status vars
bool dmpReady = false;  // set true if DMP init was successful
uint8_t mpuIntStatus;   // holds actual interrupt status byte from MPU
uint8_t devStatus;      // return status after each device operation (0 = success, !0 = error)
uint16_t packetSize;    // expected DMP packet size (default is 42 bytes)
uint16_t fifoCount;     // count of all bytes currently in FIFO
uint8_t fifoBuffer[64]; // FIFO storage buffer

// orientation/motion vars
Quaternion q;           // [w, x, y, z]         quaternion container
VectorInt16 aa;         // [x, y, z]            accel sensor measurements
VectorInt16 aaReal;     // [x, y, z]            gravity-free accel sensor measurements
VectorInt16 aaWorld;    // [x, y, z]            world-frame accel sensor measurements
VectorFloat gravity;    // [x, y, z]            gravity vector
float euler[3];         // [psi, theta, phi]    Euler angle container
float ypr[3];           // [yaw, pitch, roll]   yaw/pitch/roll container and gravity vector

// packet structure for InvenSense teapot demo
uint8_t teapotPacket[14] = { '$', 0x02, 0,0, 0,0, 0,0, 0,0, 0x00, 0x00, '\r', '\n' };

//Mes variables
int axeyoffsetto0 = 1.61;
int vitesse = 700;

// ================================================================
// ===               INTERRUPT DETECTION ROUTINE                ===
// ================================================================

volatile bool mpuInterrupt = false;     // indicates whether MPU interrupt pin has gone high
void dmpDataReady() {
    mpuInterrupt = true;
}



// ================================================================
// ===                      INITIAL SETUP                       ===
// ================================================================

void setup() {

    // join I2C bus (I2Cdev library doesn't do this automatically)
    #if I2CDEV_IMPLEMENTATION == I2CDEV_ARDUINO_WIRE
        Wire.begin();
        TWBR = 24; // 400kHz I2C clock (200kHz if CPU is 8MHz)
    #elif I2CDEV_IMPLEMENTATION == I2CDEV_BUILTIN_FASTWIRE
        Fastwire::setup(400, true);
    #endif

    // initialize serial communication
    // (115200 chosen because it is required for Teapot Demo output, but it's
    // really up to you depending on your project)
    Serial.begin(9600);
    while (!Serial); // wait for Leonardo enumeration, others continue immediately

    // NOTE: 8MHz or slower host processors, like the Teensy @ 3.3v or Ardunio
    // Pro Mini running at 3.3v, cannot handle this baud rate reliably due to
    // the baud timing being too misaligned with processor ticks. You must use
    // 38400 or slower in these cases, or use some kind of external separate
    // crystal solution for the UART timer.

    // initialize device
    Serial.println(F("Initializing I2C devices..."));
    mpu.initialize();

    // verify connection
    Serial.println(F("Testing device connections..."));
    Serial.println(mpu.testConnection() ? F("MPU6050 connection successful") : F("MPU6050 connection failed"));

    // wait for ready
    Serial.println(F("\nSend any character to begin DMP programming and demo: "));
    while (Serial.available() && Serial.read()); // empty buffer
    while (!Serial.available());                 // wait for data
    while (Serial.available() && Serial.read()); // empty buffer again

    // load and configure the DMP
    Serial.println(F("Initializing DMP..."));
    devStatus = mpu.dmpInitialize();

    // supply your own gyro offsets here, scaled for min sensitivity
    mpu.setXGyroOffset(220);
    mpu.setYGyroOffset(76);
    mpu.setZGyroOffset(-85);
    mpu.setZAccelOffset(1788); // 1688 factory default for my test chip

    // make sure it worked (returns 0 if so)
    if (devStatus == 0) {
        // turn on the DMP, now that it's ready
        Serial.println(F("Enabling DMP..."));
        mpu.setDMPEnabled(true);

        // enable Arduino interrupt detection
        Serial.println(F("Enabling interrupt detection (Arduino external interrupt 0)..."));
        attachInterrupt(0, dmpDataReady, RISING);
        mpuIntStatus = mpu.getIntStatus();

        // set our DMP Ready flag so the main loop() function knows it's okay to use it
        Serial.println(F("DMP ready! Waiting for first interrupt..."));
        dmpReady = true;

        // get expected DMP packet size for later comparison
        packetSize = mpu.dmpGetFIFOPacketSize();
    } else {
        // ERROR!
        // 1 = initial memory load failed
        // 2 = DMP configuration updates failed
        // (if it's going to break, usually the code will be 1)
        Serial.print(F("DMP Initialization failed (code "));
        Serial.print(devStatus);
        Serial.println(F(")"));
    }

    // configure LED for output
    pinMode(LED_PIN, OUTPUT);
}



// ================================================================
// ===                    MAIN PROGRAM LOOP                     ===
// ================================================================

void loop() {
    // if programming failed, don't try to do anything
    if (!dmpReady) return;

    // wait for MPU interrupt or extra packet(s) available
    while (!mpuInterrupt && fifoCount < packetSize) {
        // other program behavior stuff here
        // .
        // .
        // .
        // if you are really paranoid you can frequently test in between other
        // stuff to see if mpuInterrupt is true, and if so, "break;" from the
        // while() loop to immediately process the MPU data
        // .
        // .
        // .
    }

    // reset interrupt flag and get INT_STATUS byte
    mpuInterrupt = false;
    mpuIntStatus = mpu.getIntStatus();

    // get current FIFO count
    fifoCount = mpu.getFIFOCount();

    // check for overflow (this should never happen unless our code is too inefficient)
    if ((mpuIntStatus & 0x10) || fifoCount == 1024) {
        // reset so we can continue cleanly
        mpu.resetFIFO();
        Serial.println(F("FIFO overflow!"));

    // otherwise, check for DMP data ready interrupt (this should happen frequently)
    } else if (mpuIntStatus & 0x02) {
        // wait for correct available data length, should be a VERY short wait
        while (fifoCount < packetSize) fifoCount = mpu.getFIFOCount();

        // read a packet from FIFO
        mpu.getFIFOBytes(fifoBuffer, packetSize);
        
        // track FIFO count here in case there is > 1 packet available
        // (this lets us immediately read more without waiting for an interrupt)
        fifoCount -= packetSize;


        #ifdef OUTPUT_READABLE_YAWPITCHROLL
            // display Euler angles in degrees
            mpu.dmpGetQuaternion(&q, fifoBuffer);
            mpu.dmpGetGravity(&gravity, &q);
            mpu.dmpGetYawPitchRoll(ypr, &q, &gravity);
            
            ypr[1] = (ypr[1] * 180/M_PI)-axeyoffsetto0;
            Serial.println(ypr[1]);
            
        #endif


        // blink LED to indicate activity
        blinkState = !blinkState;
        digitalWrite(LED_PIN, blinkState);
    }

    if (ypr[1] <= -0.5)
    {
      Serial.println ("1");
      roue1.setSpeed(vitesse);
      roue2.setSpeed(-vitesse);

      roue1.runSpeed();
      roue2.runSpeed();
    }

    if (ypr[1] >= 0.5)
    {
      Serial.println("2");
      roue1.setSpeed(-vitesse);
      roue2.setSpeed(vitesse);

      roue1.runSpeed();
      roue2.runSpeed();
    }
    
}


#31 Path

Path

    Made By Humans

  • Modérateur
  • PipPipPipPipPip
  • 2 461 messages
  • Gender:Male
  • Location:Paris

Posté 25 septembre 2017 - 08:11

Sur AccelStepper, il faut donner une valeur à setMaxSpeed.

https://www.pjrc.com...celStepper.html

 

Sets the maximum speed. The default is very slow, so this must be configured. When controlled by setting position, the stepper will accelerate to move at this maximum speed, and decelerate as it reaches the destination.

Je sais pas si ça peut aider.


Podcast Made By Humans

Je cherche des volontaires de tous niveaux pour nos petites conversations entre hobbyistes.

Accès aux salles secrètes

 


#32 Budet

Budet

    Membre passionné

  • Membres
  • PipPipPip
  • 355 messages
  • Gender:Male
  • Location:69

Posté 25 septembre 2017 - 08:35

Raaah merci !! Je le savais en plus, dans tous mes essaies j'ai toujours mis le setMaxSpeed mais la j'avais oublié :D

Et bien mine de rien ça marche pas trop mal ! J'ai réussis à le faire tenir en équilibre pendant 2 secooondes !! 

 

Bon y'a deux problèmes, le premier est que je n'arrive pas à lui faire aller à sa vitesse max, j'ai beau changé ma vitesse il va lentement alors que je sais qu'il est peu aller 2 a 3 fois plus vite.

 

Ensuite la fréquence du changement de rotation du robot n'est pas du tout assez rapide.

 

Suite au prochain numéro :)



#33 Path

Path

    Made By Humans

  • Modérateur
  • PipPipPipPipPip
  • 2 461 messages
  • Gender:Male
  • Location:Paris

Posté 25 septembre 2017 - 08:40

Tu as setAcceleration() aussi. Tu peux lui donner une valeur super haute si tu veux (dois) gérer toi même l'accélération ... avec un PID ;)


Podcast Made By Humans

Je cherche des volontaires de tous niveaux pour nos petites conversations entre hobbyistes.

Accès aux salles secrètes

 


#34 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 4 664 messages
  • Gender:Male

Posté 26 septembre 2017 - 07:25

Tu as setAcceleration() aussi. Tu peux lui donner une valeur super haute si tu veux (dois) gérer toi même l'accélération ... avec un PID ;)

Ce problème de PID, n'est-il pas déjà inclus dans les fonctions des bibliothèques ?
Par exemple, j'ai cru comprendre que c'était codé dans le Firmware des imprimantes 3D.

En tout cas, Budet, 2 secondes en équilibre, c'est déjà pas mal ! Bravo !

#35 Amhnemus

Amhnemus

    Membre passionné

  • Membres
  • PipPipPip
  • 593 messages
  • Gender:Male
  • Location:Montigny-le-bretonneux

Posté 26 septembre 2017 - 06:07

Pour le code je suis une quiche donc je ne pourrai t'aider je peux juste te féliciter de l'avancement de ton projet et tres belle réalisation des pièces imprimer c'est classe.
1ère place Robot Warrior 2019 humanoïdes autonome

#36 Budet

Budet

    Membre passionné

  • Membres
  • PipPipPip
  • 355 messages
  • Gender:Male
  • Location:69

Posté 26 septembre 2017 - 07:29

Merci pour vos réponses ça me motive à fond !

Le problème du setAcceleration() c'est que le robot accélère pour atteindre une consigne puis décélère avant de l'atteindre...

J'ai regarder le code d'autre personne qui ont fait quelque chose de similaire a moi et j'avoue que ça a mis un coup à mon morale de ne même pas comprendre ce qu'ils ont fait....

L'objectif à atteindre et sacrément chaud...

J'ai lu plein de truc sur le PID, je comprend la logique derrière mais la façon de mettre ça en marche m'échappe !

Je travaille cette semaine dessus et je vous reposerais des questions ce week end :) merci merci

#37 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 4 664 messages
  • Gender:Male

Posté 26 septembre 2017 - 08:35

Même en ayant le code, je n'y suis pas parvenu et c'était plus simple qu'un SegWay.

#38 Budet

Budet

    Membre passionné

  • Membres
  • PipPipPip
  • 355 messages
  • Gender:Male
  • Location:69

Posté 01 octobre 2017 - 05:18

Bonjour à tous,

 

J'ai un nouveau problème et cette fois ci un peu plus important...

 

Je vous met une photo de comment est câblé la partie motorisation de mon robot. (Je suis désolé c'est pas hyper lisible, je ne maîtrise pas très bien Fritzing, de plus le dessin des contrôleur de moteur pas à pas n'est pas le bon mais c'est pour vous illustrer mes propos).

 

Capture.PNG

 

En gros, j'ai une batterie qui alimente mes deux moteurs, j'ai bricolé une petite carte sur une breadboard avec des vieille soudure toutes moches qui me permet de partager l’énergie à mes deux contrôleurs de moteurs. 

 

J'ai décidé de raccorder toutes les masses au même endroit, il y'a a 5 fils qui partent de cet endroit là, deux qui vont avec le VCC de mes controlleurs, deux autres qui vont de l'autre côté des controlleur pour mettre certaines entrés à la masse (suivant un état bas) sinon ils ne fonctionnent pas, et un dernier qui va à la masse de l'arduino.

 

Tout marcher très bien comme ça lorsque je faisais des essais seulement sur les moteurs pour prendre en main la bibliothèque AccelStepper.

 

Récemment j'ai fais des bonnes avancé sur le code, et j'arrivais à obtenir un relatif contrôle de l'inclinaison du robot sauf qu'il y a très vite eu un problème. Au départ j'allumais ma batterie, mes moteurs stabilisait le robot quelques que secondes puis ils se coupaient nette comme si plus de courant ne les traversaient. 

 

Plus je réitérais l'opération et plus le temps avant qu'ils ne s'arrêtent devenait court jusqu'à ce qu'ils ne marchent plus du tout.

 

N'importe quelle personne saine d'esprit aurait déjà arrêté le massacre dès le premier problème mais moi j'ai décidé de persisté dans ma connerie jusqu'à ce que je casse tout.

 

Après analyse visuelle rapide je me suis rendu compte que le fil rouge de ma batterie s'était déconnecté de ma jolie soudure sur la breadboard, super ! tout est logique, si le câble est déconnecté ça ne risque plus de marcher.

 

Du coup je me suis empressé de le ressouder, j'ai retransferé mon code et miracle ça a marché mais pas plus de 10 secondes, ensuite rebollote, aucun courant dans mes moteurs.

 

J'ai d'abord pensé qu'un composant ne fonctionnait plus du coup j'ai supprimer la breadboard et j'ai connecté la batterie directement à chaque controlleur afin de vérifier, un à un, leur bon fonctionnement et la conclusion est que tout fonctionne !

 

Du coup, mon diagnostique est que mon robot ne doit vraiment pas supporter tous les acoups en courant/tension qui sont générés lorsque le robot essaye de se stabiliser et que d'un point de vue électronique mon système n'est pas bon du tout...

 

J'imagine qu'il faut que je rajoute des diodes/resistances afin d'empêcher les pics/retours de courant/tension qui doivent endommager mon circuit mais j'avoue que j'aimerais bien connaitre votre avis la dessus. :)

 

Merci à tous !



#39 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 4 664 messages
  • Gender:Male

Posté 01 octobre 2017 - 06:27

J'ai déjà fait ça, ici http://www.robot-maker.com/forum/topic/11322-test-du-gros-servo-asme-mxa-260kgcm-012s60-3600/?p=82674
C'est une bonne pratique. Déjà, ça fait un problème de moins à régler.
C'est vrai qu'avec les bobines des moteurs, c'est plus prudent.
J'ignorais complètement ce problème avant mon test.

#40 Budet

Budet

    Membre passionné

  • Membres
  • PipPipPip
  • 355 messages
  • Gender:Male
  • Location:69

Posté 01 octobre 2017 - 06:49

Ah merci ! Donc une simple diode suffirait ?

Vu que ma batterie c'est une 12V 3A il faudrait que je le surdimensionne un peu... Une idée d'ou je pourrait en trouver rapidement ?



Répondre à ce sujet



  



0 utilisateur(s) li(sen)t ce sujet

0 members, 0 guests, 0 anonymous users