Aller au contenu


Photo

FourBarQuad525 - Toujours plus rapide


  • Veuillez vous connecter pour répondre
182 réponses à ce sujet

#121 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 7 030 messages
  • Gender:Male

Posté 05 décembre 2020 - 07:17

Nouveau record !

 

 

                            430cm en 5s

 

 

 

Pour arriver à cela, j'ai augmenté la tension. Sur mon UBEC, j'ai un cavalier qui permet de choisir entre 5V, 6V et 7,4V. Ces derniers temps, j'utilisais le 6V. Aujourd'hui, j'ai testé les servos SG90, MG90S et MG92B en 7,4V pendant 1h chacun. Pas de problème, ça ne chauffe pas. En réalité, l'UBEC délivre 6,9V. Logique, on ne peut espérer avoir du 7,4V avec une batterie 2S en entrée. 

J'ai donc décidé de passer le Quad en 7,4V. Le Shield que j'utilise ne supporte pas les 8V de la 2S, l'Arduino boot en permanence.

Je vais essayé avec le Shield que j'utilisais précédemment. Si cela fonctionne, j'économiserai le poids de l'UBEC qui est de 16g, en alimentant directement le Shield.

Je suis en train de faire une version plus légère de mon Quad, en collant certaines pièces, mais ce n'est pas facile, j'arrive à la limite, là.

Vous l'aurez compris, mon objectif, c'est 5m en 5s. 



#122 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 796 messages
  • Gender:Male

Posté 05 décembre 2020 - 07:21

Merci pour le retour d'expérience sur la tension supportée par les microservo. Ca économise le poids du BEC et des problèmes d'alimentation !

 

Avec une tension supérieure, tu dois avoir plus de couple, tu tentes un allongement des pattes ?

 

Patrick.



#123 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 7 030 messages
  • Gender:Male

Posté 05 décembre 2020 - 07:32

Difficile d'allonger les pattes, car elles se touchent pratiquement au centre. Pour cela, il faudrait que j'allonge le corps, donc plus lourd.

 

Pas de souci, les garçons, je suis de très près ce que vous dites, même si parfois je suis un peu largué.

Vous me dites ce que je dois faire, et si je peu, je le ferai.

 

Dites donc, connaissez-vous la bibliothèque VarSpeedServo.h ? C'est la bibliothèque utilisée par Sebastian sur son GorillaBot.

Je pense qu'il connait Servo.h, alors s'il utilise cette bibli, il doit y avoir une bonne raison. D'ailleurs, son utilisation est différente de Servo.h.



#124 Sandro

Sandro

    Membre chevronné

  • Modérateur
  • PipPipPipPip
  • 1 321 messages
  • Gender:Male

Posté 05 décembre 2020 - 08:22

Je pensais que la bibliothèque servo.h générait les impulsions "en même temps", et les arrêtait au fur et à mesure, mais c'est pas ça. En lisant le code source, je pense que Ptarick a raison : c'est un pulse après l'autre.

Pour l'arduino Uno, c'est bien un seul timer (timer 0) qui sert.

Pour un arduino mega, il y a jusqu'à 4 timers qui servent : le premier sert pour les 12 premiers servos, le second pour les 12 suivants,... Du coup, à priori, on peut exécuter 4 impulsions en même temps, à condition de faire croire à la bibliothèque qu'il y a d'autres servos entre. Si on déclare ces servos suplémentaires avec writeMicroseconds(0), on peut à priori avoir seulement l'exécution de 2 servos par timer, soit 5ms.

Si tu veux un peu plus petit que la vrai Méga, il y a un clone plus petit sur la boutique : https://www.robot-ma...60-pro-312.html

 

Pour VarSpeedServo, à première vue, je dirais que ça n'apporte pas grand chose ici (on peut fixer la vitesse du servo, mais vu qu'il on essaye d'aller au plus vite, je ne suis pas sur que ce soit très pertinent).

 

 

Après dîner, je vais voir si j'arrives à faire un code qui se passe de la librarie servo et qui fait tous les pulses en simultané (au prix d'être bloquant pendant 2.5ms)


Aidez-nous à vous aider : partagez toutes les informations pertinentes : description précise du problème, contexte, schéma de câblage, liens vers la documentation des composants, votre code (ou encore mieux un code minimal reproduisant le bug), ...

Vous recevrez ainsi plus de réponses, et elles seront plus pertinentes.


#125 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 796 messages
  • Gender:Male

Posté 05 décembre 2020 - 08:28

Elle est bien cette carte MEGA au format compact !

 

Elle dispose de 15 PWM. Avec une telle carte, Oracid peut utilisedr analogWrite() pour générer les PWM. Plus besoin de <Servo>.

 

Bon courage Sandro, je suis curieux de voir le résultat. Ca pourrait bien marcher. 

 

Patrick.



#126 Sandro

Sandro

    Membre chevronné

  • Modérateur
  • PipPipPipPip
  • 1 321 messages
  • Gender:Male

Posté 05 décembre 2020 - 08:46

 

Elle dispose de 15 PWM. Avec une telle carte, Oracid peut utilisedr analogWrite() pour générer les PWM. Plus besoin de <Servo>.

Euh ... non

Les servo moteurs de modélismes n'utilisent pas un PWM "normal" (ie rapport cyclique de 0 à 100%).

Hors, la fonction analogWrite(n) génère un PWM "normal" avec un rapport cyclique de n/255. Sans compter que (par défaut) la fréquence est beaucoup plus élevée (de l'ordre de 500Hz pour la plupart des pins (timer 0 et 2), le double pour timer1 (qui est 6bits); pour les timers propres à la méga, je sais pas).

 

Par contre, sur la méga, avec les 4 timers 16 bits (1, 4, 5, 6), ayant chacun deux sorties, il est à priori possible de gérer les 8 servos rien qu'avec les timers (par contre c'est à coder à la main)


Aidez-nous à vous aider : partagez toutes les informations pertinentes : description précise du problème, contexte, schéma de câblage, liens vers la documentation des composants, votre code (ou encore mieux un code minimal reproduisant le bug), ...

Vous recevrez ainsi plus de réponses, et elles seront plus pertinentes.


#127 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 796 messages
  • Gender:Male

Posté 05 décembre 2020 - 08:48

https://www.arduino....o-hardware-pwm/



#128 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 796 messages
  • Gender:Male

Posté 05 décembre 2020 - 09:51

Petite digression au sujet du pilotage de servo.

 

Il existe une bibliothèque logicielle sur Raspberry Pi qui permet de faire du PWM sur toutes les GPIO, comme la bibliothèque <Servo> de Arduino.  Elle s'appelle PIGPIO.

Ainsi, pas besoin de shield et de carte d'extension (ex. : Servo HAT à base de PCA9685). Non seulement, cette bibliothèque fonctionne bien et elle est simple à utiliser en C ou en Python sous Linux/RPi.

Mais en plus elle est assez performante.

 

Standard : 8 servos au rythme de 50Hz (Période = 20ms)

 

CapturePIGPIO.PNG

 

Maximum : 8 servos au rythme de 400Hz (Période = 2.5ms)

A cette vitesse on peut utiliser les servo les plus rapide (333Hz).

CapturePIGPIO400Hz.PNG
 
Profitant de la puissance du CPU disponible, toutes les impulsions sont générées en même temps. Je ne sais pas comment ils ont réussi à coder cette bibliothèque, avec une telle contrainte temps-réel sous Linux.... Un Tick à 5us.
 
Enfin, une petite carte RPi n'est pas beaucoup plus lourde d'une Arduino, et on peut la programmer à distance (Wifi) dans un environnement riche en possibilité.
 
Patrick.


#129 Sandro

Sandro

    Membre chevronné

  • Modérateur
  • PipPipPipPip
  • 1 321 messages
  • Gender:Male

Posté 05 décembre 2020 - 10:01

@Patrick : pour la librarie dont tu donnes le lien, elle permet en effet d'utiliser les timers hardware pour commander directement les servos sur l'arduino mega (du coup, pas besoin de re-écrire ce code nous même si on passe à une méga miniature)

 

 

Sinon, voici un premier jet de code pour contrôler 8 servos avec les pulses en simultanés, et garantir qu'une nouvelle consigne sera toujours prise en compte en même temps sur tous les servos :

#define PERIODE_US 20000

uint16_t duree_pulse_us[8]={1700, 1700, 1700, 1700, 1700, 1700, 1700, 1800};
byte servo_pins[8]={2, 3, 4, 5, 6, 7, 8, 9};
bool servo_etat[8]={0, 0, 0, 0, 0, 0, 0, 0};  //état du pin (0 ou 1)

void envoyer_pulse()
{
  uint8_t nbr_servos_restant=8;
  
  for(int i=0;i<8;i++)
  {
    servo_etat[i]=1;  //on s'aprète à mettre à 1 les pins
  }
  
  unsigned long start_time=micros();
  for(int i=0;i<8;i++)
  {
    digitalWrite(servo_pins[i],1);  //on active tous les pins : on commence le pulse
  }
  unsigned long test_time1=micros();
  while(nbr_servos_restant)
  {
    unsigned long duree_actuelle_du_pulse=micros()-start_time;  //durée écoulée depuis le début du pulse
    for(int i=0;i<8;i++)
    {
      if(duree_actuelle_du_pulse>=duree_pulse_us[i] && servo_etat[i]) //si la durée du pulse est écoulée, mais que le pin est encore actif) : il faut le mettre à 0  
      {
        digitalWrite(servo_pins[i],0);
        servo_etat[i]=0;
        nbr_servos_restant--;
      }
    }
  }
}

void setup() {
  Serial.begin(115200);
  for(int i=0;i<8;i++)
  {
    pinMode(servo_pins[i],OUTPUT);
  }
  Serial.println("Hello");
}

int c=0;

void loop() {
  c++;
  unsigned long start_time=micros();
  envoyer_pulse();
  unsigned long duration=micros()-start_time;
  Serial.println(duration);

  //faire ici les calculs pour la nouvelle position des servos (position en µs de pulse, pas en degrés)
  duree_pulse_us[0]=1500+((c/100)%2)*300;
  duree_pulse_us[1]=1500+((c/100)%2)*300;
  duree_pulse_us[2]=1500+((c/100)%2)*300;
  duree_pulse_us[3]=1500+((c/100)%2)*300;
  duree_pulse_us[4]=1500+((c/100)%2)*300;
  duree_pulse_us[5]=1500+((c/100)%2)*300;
  duree_pulse_us[6]=1500+((c/100)%2)*300;
  duree_pulse_us[7]=1500;

  //attendre la fin de la période
  while(micros()-start_time<PERIODE_US)
  {
    //ne rien faire
  }
}

A noter que ce code à pour l'instant plusieurs inconvénients :

- on utilise directement les durées en micro-secondes des pulses et pas les positions angulaires plus pratiques (en gros, on n'utilise que writeMicroseconds de la librairie servo et pas write). C'est pas dur a ajouter, mais c'est pas encore fait

- bien plus gros : par l'algo même, si plusieurs servos on des durées de pulses très proches (voir identiques), il y a aura une erreur sur les "derniers" servos à demander cette durée de pulse (c'est bien visible avec le choix des calculs dans le loop du programme de test). Actuellement, dans le pire des cas (tous les servos à la même position), j'obtiens une erreur max de 52µs, soit environ 9.3°. Ce problème ne pourra jamais être totalement éliminé, mais peut être fortement réduit en écrivant un code plus optimisé (ce que j'ai volontiers pas fait dans la première version pour tester le principe rapidement et pour avoir un code facile à comprendre)

 

NB : dans ce code, la fonction envoyer_pulse est bloquante, mais elle dure moins de 0.1ms de plus que le pulse le plus long

 

 

Du coup, j’attaque une V2, en optimisant le code pour améliorer la précision


Aidez-nous à vous aider : partagez toutes les informations pertinentes : description précise du problème, contexte, schéma de câblage, liens vers la documentation des composants, votre code (ou encore mieux un code minimal reproduisant le bug), ...

Vous recevrez ainsi plus de réponses, et elles seront plus pertinentes.


#130 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 796 messages
  • Gender:Male

Posté 05 décembre 2020 - 10:17

Je me suis demandé si ca valait le coup d'ordonner la liste des servos en fonction de la largeur d'impulsion à générer, pour limiter les tests dans la boucle. Ca permettrait aussi de gérer plus facilement le cas de deux servos ayant la même largeur d'impulsion. Qu'en penses-tu ? Le tri cout eun peu de CPU au début, mais ensuite ca va plus vite.



#131 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 796 messages
  • Gender:Male

Posté 05 décembre 2020 - 10:19

Sinon tu peux faire comme dans PIGPIO, tu prends un Timer à 5 / 10 ou 15us par exemple, et sur It. tu rafraichis les sorties en fonction de la largeur d'impulsion des servos.



#132 Sandro

Sandro

    Membre chevronné

  • Modérateur
  • PipPipPipPip
  • 1 321 messages
  • Gender:Male

Posté 06 décembre 2020 - 12:07

@Patrick : pour le trie, sur la version "naive", ça vaut le coup. Pour la V2, je suis pas sur si c'est encore le cas.

@Patrick : ton second message, j'ai pas compris, en particulier "et sur It."

 

 

Sinon, voici la V2, qui devrait être utilisable :


//équivalences pin/port
//  2   PD2
//  3   PD3
//  4   PD4
//  5   PD5
//  6   PD6
//  7   PD7
//  8   PB0
//  9   PB1

//octets avec un 0 à l'endroit correspondant à un pin dans les registres et 1 ailleurs
#define ZERO_DU_PIN_2 B11111011
#define ZERO_DU_PIN_3 B11110111
#define ZERO_DU_PIN_4 B11101111
#define ZERO_DU_PIN_5 B11011111
#define ZERO_DU_PIN_6 B10111111
#define ZERO_DU_PIN_7 B01111111
#define ZERO_DU_PIN_8 B11111110
#define ZERO_DU_PIN_9 B11111101

//nom du pot correspondant à chaque pin
#define PORT_DE_PIN_2 PORTD
#define PORT_DE_PIN_3 PORTD
#define PORT_DE_PIN_4 PORTD
#define PORT_DE_PIN_5 PORTD
#define PORT_DE_PIN_6 PORTD
#define PORT_DE_PIN_7 PORTD
#define PORT_DE_PIN_8 PORTB
#define PORT_DE_PIN_9 PORTB


#define PERIODE_US 20000  //période

uint16_t duree_pulse_us[10]={0,0,1700, 1700, 1700, 1700, 1700, 1700, 1700, 1700};   //position initiale

uint16_t duree_pulse_us_min[10]={0,0,1000, 1000, 1000, 1000, 1000, 1000, 1000, 1000};
uint16_t duree_pulse_us_max[10]={0,0,2000, 2000, 2000, 2000, 2000, 2000, 2000, 2000};
int angle_min[10]={0,0,0, 0, 0, 0, 0, 0, 0, 0};
int angle_max[10]={0,0,180, 180, 180, 180, 180, 180, 180, 180};

void envoyer_pulse()
{
  unsigned long start_time=micros();
  //mise à 1 de tous les pins
  PORTD |= B11111100; //mise à 1 des pins 2 à 7 du port D (ie pins 2 à 7 de l'arduino)
  PORTB |= B00000011; //mise à 1 des pins 0à 1 du port B (ie pins 8 et 9 de l'arduino)
  
  while( (PORTD & 0B11111100) | (PORTB & 0B00000011) )  //tant qu'au moins un des pins est à 1
  {
    unsigned long duree_actuelle_du_pulse=micros()-start_time;  //durée écoulée depuis le début du pulse
    if(duree_actuelle_du_pulse>=duree_pulse_us[2])
      PORT_DE_PIN_2 &= ZERO_DU_PIN_2;

    if(duree_actuelle_du_pulse>=duree_pulse_us[3])
      PORT_DE_PIN_3 &= ZERO_DU_PIN_3;
      
    if(duree_actuelle_du_pulse>=duree_pulse_us[4])
      PORT_DE_PIN_4 &= ZERO_DU_PIN_4;

    if(duree_actuelle_du_pulse>=duree_pulse_us[5])
      PORT_DE_PIN_5 &= ZERO_DU_PIN_5;

    if(duree_actuelle_du_pulse>=duree_pulse_us[6])
      PORT_DE_PIN_6 &= ZERO_DU_PIN_6;

    if(duree_actuelle_du_pulse>=duree_pulse_us[7])
      PORT_DE_PIN_7 &= ZERO_DU_PIN_7;

    if(duree_actuelle_du_pulse>=duree_pulse_us[8])
      PORT_DE_PIN_8 &= ZERO_DU_PIN_8;

    if(duree_actuelle_du_pulse>=duree_pulse_us[9])
      PORT_DE_PIN_8 &= ZERO_DU_PIN_9;
  }
}

void set_position_degrees(byte pin, int angle_deg)
{
  uint16_t duree_us=map(angle_deg, angle_min[pin], angle_max[pin], duree_pulse_us_min[pin], duree_pulse_us_max[pin]);
  duree_pulse_us[pin]=duree_us;
}

void setup() {
  Serial.begin(115200);
  for(int i=2;i<=9;i++)
  {
    pinMode(i,OUTPUT);
  }
  Serial.println("Hello");
}

int c=0;

void loop() {
  c++;
  unsigned long start_time=micros();
  envoyer_pulse();
  unsigned long duration=micros()-start_time;
  Serial.println(duration);

  /*//faire ici les calculs pour la nouvelle position des servos (position en µs de pulse, pas en degrés)
  duree_pulse_us[2]=1500+((c/100)%2)*300;
  duree_pulse_us[3]=1500+((c/100)%2)*300;
  duree_pulse_us[4]=1500+((c/100)%2)*300;
  duree_pulse_us[5]=1500+((c/100)%2)*300;
  duree_pulse_us[6]=1500+((c/100)%2)*300;
  duree_pulse_us[7]=1500+((c/100)%2)*300;
  duree_pulse_us[8]=1500+((c/100)%2)*300;
  duree_pulse_us[9]=1500;*/

  //variante
  set_position_degrees(2,0);
  set_position_degrees(3,20);
  set_position_degrees(4,40);
  set_position_degrees(5,60);
  set_position_degrees(6,90);
  set_position_degrees(7,120);
  set_position_degrees(8,160);
  set_position_degrees(9,180);

  //attendre la fin de la période
  while(micros()-start_time<PERIODE_US)
  {
    //ne rien faire
  }
}

Nouvautés :

1) le code est beaucoup plus optimisé : l'écart entre le traitement du premier et du dernier servo est de 7*11 cycles d'horloges (11 cycles par servo), soit 4.8µs, ce qui correspond à 0.8°. La fluctuation est encore bien plus faible (1 cycle d'horloge par servo ayant fini son pulse), soit au maximum 7 cycles d'horloges de fluctuation, soit 0.43ms, soit 0.08°

La plus forte cause de fluctuation est donc la fonction micros, qui a une résolution de 4µs, soit 0.7° de fluctuation sur les angles des servos.

En pratique, on ne remarque pas les fluctuations à l'oeil nu
2) renumérotation des servos : maintenant chaque servo correspon au pin (il y a donc 2 emplacements "vides" dans les tableaux, correspondant aux pins 0 et 1 qui ne sont pas utilisés)

3) il y a maintenant une fonction pour donner la consigne en degrés (il y a des tableaux en début du programme pour ajuster les intervales d'angles et les durées en µs correspondantes : ça peut servir pour corriger les offsets des moteurs, ainsi que pour définir une plage angulaire de notre choix (par exemple -90° à +90°). NB : il n'y a aucune sécurité pour les valeurs hors intervalle.

 

@Oracid, je penses que tu peux commencer à intégrer ton code sur cette base si tu en as envie

 

 

EDIT : sur mon servo de test, je peux mettre PERIODE_US aussi petit que je veux, ça a l'air de toujours marcher correctement (nb : il faut quand même laisser PERIODE_US assez grand pour pouvoir réaliser la période souhaitée, sinon la période n'est plus respectée (mais mon servo conserve quand même la position)


Aidez-nous à vous aider : partagez toutes les informations pertinentes : description précise du problème, contexte, schéma de câblage, liens vers la documentation des composants, votre code (ou encore mieux un code minimal reproduisant le bug), ...

Vous recevrez ainsi plus de réponses, et elles seront plus pertinentes.


#133 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 7 030 messages
  • Gender:Male

Posté 06 décembre 2020 - 08:37

@Oracid, je penses que tu peux commencer à intégrer ton code sur cette base si tu en as envie

Je vais essayer, mais honnêtement, j'ai du mal à comprendre tout ça.

 

En résumé, je dois utiliser la fonction set_position_degrees() à la place d'un servo.write(). C'est ça ?



#134 Sandro

Sandro

    Membre chevronné

  • Modérateur
  • PipPipPipPip
  • 1 321 messages
  • Gender:Male

Posté 06 décembre 2020 - 12:56

Oui, c'est ça.

Et tous les calculs de position doivent se faire entre

  Serial.println(duration);

et

  //attendre la fin de la période
  while(micros()-start_time<PERIODE_US)
  {
    //ne rien faire
  }

A chaque tour du loop, exactement 1 nouvelle consigne sera envoyé a chaque moteur.

 

 

Une solution serait un code de la forme suivante:

void calculer_nouvelle_position(int index)
{
    int i=index % lgTab; //index croit indéfiniment, i correspond à l'index dans la période
    InverseKinematics(FRx[i],FRy[i],FRLS,FRRS);
    InverseKinematics(BLx[i],BLy[i],BLLS,BLRS);
    InverseKinematics(FLx[i],FLy[i],FLLS,FLRS);
    InverseKinematics(BRx[i],BRy[i],BRLS,BRRS);
}



int i=0;

void loop() {
  envoyer_pulse();
  calculer_nouvelle_position(i);
  i++

  //attendre la fin de la période
  while(micros()-start_time<PERIODE_US)
  {
    //ne rien faire
  }
}

Et dans InverseKinematics, remplacer servo.write par set_position_degrees(pin, angle), et suprimer le delay
 

 

EDIT : c'est quelle partie que tu as du mal à comprendre? (nb : je te conseilles de d'abord chercher à comprendre la V1, qui a été écrite pour être lisible, avant de chercher à comprendre la V2, qui est bien plus performante mais au prix d'un code bien moins facile à comprendre)


Aidez-nous à vous aider : partagez toutes les informations pertinentes : description précise du problème, contexte, schéma de câblage, liens vers la documentation des composants, votre code (ou encore mieux un code minimal reproduisant le bug), ...

Vous recevrez ainsi plus de réponses, et elles seront plus pertinentes.


#135 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 7 030 messages
  • Gender:Male

Posté 06 décembre 2020 - 02:03

C'est ce que j'avais compris. Je m'étonne moi-même.

Malheureusement, ce ne sera pas fait dans l'après-midi, mais je vais m'y atteler, promis.



#136 Sandro

Sandro

    Membre chevronné

  • Modérateur
  • PipPipPipPip
  • 1 321 messages
  • Gender:Male

Posté 06 décembre 2020 - 02:46

Aucun problème, rien ne presse (et rien ne t'oblige à partir sur cette piste si tu n'en as pas envie)


Aidez-nous à vous aider : partagez toutes les informations pertinentes : description précise du problème, contexte, schéma de câblage, liens vers la documentation des composants, votre code (ou encore mieux un code minimal reproduisant le bug), ...

Vous recevrez ainsi plus de réponses, et elles seront plus pertinentes.


#137 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 7 030 messages
  • Gender:Male

Posté 06 décembre 2020 - 07:52

Aucun problème, rien ne presse (et rien ne t'oblige à partir sur cette piste si tu n'en as pas envie)

Merci pour tout Sandro.

En fait, c'est pas l'envie, mais le temps qui me manque.



#138 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 7 030 messages
  • Gender:Male

Posté 07 décembre 2020 - 09:20

J'ai explosé mon dernier record de 430cm.

Aujourd'hui, mon record est de

 

                             450cm en 5s

 

Pour y parvenir, j'ai allongé les tibias de 112mm à 120mm, soit 8mm de plus (1L, unité Lego).

Mais bizarrement, c'est en mettant 104mm comme paramètres, soit 2L en moins de la réalité physique que je parviens à ce nouveau record.

Il faut que j'étudie cela, de près.



#139 pat92fr

pat92fr

    Membre passionné

  • Membres
  • PipPipPip
  • 796 messages
  • Gender:Male

Posté 07 décembre 2020 - 10:19

Ca progresse ! Tu dois avoir un cycle d'environ 360ms. Presque trois foulées par seconde. Ca fait 32cm par foulée. Pour un petit robot, c'est énorme ! Il te manque 10cm/s pour atteindre les 10s au 10m. Tu as une piste ?

 

Patrick.



#140 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 7 030 messages
  • Gender:Male

Posté 07 décembre 2020 - 10:36

Tu as une piste ?

Oui !

 

Hier j'ai testé les servos SG90, MG90S et MG92B en les alimentant directement avec une batteries 2S chargée à bloc, soit 8,3V.

Le test consistait à faire des aller/retour de 0° à 180° pendant une heure.

 

- le SG90, a rendu l'âme au bout de 1h. La tension a baissé de 8,3V à 7,9V.

- le MG90S a bien tenu 1h complète. La tension a baissé de 8,3V à 7,9V.

- le MG92B a bien tenu 1h complète. La tension a baissé de 8,3V à 8,0V. C'est pas mal, cela montre peut-être la bonne qualité du servo.

 

Pour mémoire, le test précédent était basé sur une alimention par une UBEC alimentée par une batterie 2S, mais avec une tension en sortie de l'UBEC de 6,9V.

Donc, là, en gros, on gagne un gros volt, pendant une heure. Avec 1 servo ! Avec 8 servos, les choses peuvent être différentes.

Mais j'ai bon espoir d'atteindre les 5m en 5s.






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

0 members, 1 guests, 0 anonymous users