Joueur de football Robo de débutants. Concours au MIPT. Android et Arduino et Bluetooth

Cet article est une semi-suite du travail de Love, Death and Robots, «La machine basée sur Arduino contrôlée par l'appareil Android via Bluetooth est un cycle complet» composé de deux parties ( une , deux ). Les choses qui y sont décrites ont été légèrement modifiées, refaites et le robot lui-même d'une machine itinérante s'est transformé en joueur de football. En général, il existe des informations intéressantes sur la façon de procéder.

L'instruction précédente était divisée en deux parties: logiciel et physique. Il n'y a pas eu beaucoup de changements dans les deux sens, cette fois, tout est en un seul exemplaire. Je vous rappellerai brièvement pourquoi la partie décrite est nécessaire, mais pour une compréhension complète, il est préférable de passer en revue les deux premières parties.

Partie physique


Basé sur tous les mêmes principes décrits dans le premier article:

  • sandwich d'Arduino Uno et Motor Shield.
  • deux moteurs connectés au bouclier moteur.

Et voici les changements:

  • la partie de choc est apparue, curieusement, responsable de frapper la balle.
  • le boîtier est maintenant complètement à moi, imprimé sur une imprimante 3D.

Logement


Une forme est un cercle dans lequel s'inscrivent à la fois une planche et deux roues. Extension pour la partie où la force d'impact se maintiendra.



Lors de la conception, faites attention à:

  • Hauts côtés. Les robots entrent en collision pendant le jeu, les côtés protègent non seulement vos fils, mais aussi vos rivaux de vos fils.
  • Centre de gravité et stabilité. Le centre de gravité est bien sûr là où se trouve la planche. Les roues sont situées à proximité, de sorte qu'elles ne glissent pas. De plus, une batterie est placée sur le dessus de la carte.
  • Pour empêcher le robot de picorer son nez ou son dos, nous mettons des boules allant dans le kit des ampères ici et là (si elles ne sont pas là, vous pouvez le remplacer par n'importe quel autre design coulissant).
  • Rigidité d'un dessin. La plate-forme ne doit pas s'affaisser sous le poids des circuits imprimés et des moteurs. Ne lésinez pas, utilisez des matériaux durs (contreplaqué) ou renforcez la structure en plastique avec des supports



Et maintenant le non-sens principal


Les billes ajoutées par manque de "picage" ont soulevé la plate-forme afin que les roues n'atteignent pas le sol. Pour éviter cela, nous utilisons des roues de plus grand diamètre ou raccourcissons les structures de support. En général, nous calculons cela à l'avance!

Partie de choc. Elle ne frappe pas. Beats, mais pas assez cool. Dans notre premier modèle, il y avait une servo-machine à laquelle une pièce similaire à un godet de chasse-neige était connectée. En changeant la position du servo (de 0 à 30 degrés), vous pouvez simuler un coup. Mais les servos se sont révélés lents, donc le coup est allé au diable.

Il y a deux façons de sortir: ajouter une secousse à l'impact ou remplacer les servos par des solénoïdes. La première option consiste à augmenter l'élan en fournissant de la vitesse aux roues pendant un coup. En pratique, ceci est le suivant: l'utilisateur appuie sur le bouton de coup, le robot part de l'endroit (légèrement) et en même temps fait une grève.

La deuxième option - les solénoïdes poussent la partie de choc, et ici tout dépend de la puissance (vitesse) du choc, qui à son tour dépend des caractéristiques du solénoïde.



Partie logiciel


Par une bonne tradition, qui est déjà un article, nous diviserons cette section en deux parties. D'abord une application Android, puis un croquis Arduino.

Android


Permettez-moi de vous rappeler que la demande a été rédigée par mes soins à partir de zéro. Au cours des six derniers mois, j'ai un peu mieux compris ce sujet, je vais donc décrire ce à quoi pensait Doper .

Passons d'abord à la simplification. Maintenant, le protocole de communication est le suivant: "caractère d'ouverture" + "valeur" + "caractère de fermeture" (Pour comprendre comment j'obtiens ces valeurs et de quoi il s'agit, voir l'analyse complète de l'application ici ). Cela fonctionne à la fois pour la vitesse et l'angle. Puisqu'il n'y a qu'un seul type de frappe, il n'a pas besoin d'une telle sagesse, donc l'équipe se compose d'un caractère «/» (à propos de l'équipe touchée à travers le paragraphe).

private void sendCommand(String speed, String angle) { String speedCommand = "#" + speed + "#"; //     String angleCommand = "@" + angle + "@"; try { outputStream.write(speedCommand.getBytes()); //   outputStream.write(angleCommand.getBytes()); } catch(Exception e) { e.printStackTrace(); } } 

Une commande typique ressemblerait à ceci: # 125 # @ 180 @, où 125 est la vitesse et 180 est l'angle. Bien sûr, cela peut encore être simplifié, mais l'une des tâches consistait à maintenir la légèreté et la lisibilité, afin de pouvoir l'expliquer plus tard, y compris aux enfants.

Une nouvelle commande sendHit () est apparue, qui est déclenchée lorsque le bouton "Hit" est enfoncé. Elle envoie un seul "/". Étant donné que le bluetooth 2.0+ ordinaire ne souffre pas des données reçues en même temps, c'est-à-dire qu'il sait les mettre dans la file d'attente et ne pas les perdre, nous n'avons pas besoin de contrôler cela. Si vous allez travailler avec Bluetooth Low Energy 4.0+ (enfin, tout d'un coup), la file d'attente devra déjà être organisée manuellement, sinon les données seront perdues.

 ... bHit = findViewById(R.id.b_high_hit); //   bHit.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View view) { threadCommand.sendHit(); //     "" } }); ... private void sendHit() { try { outputStream.write("/".getBytes()); //   }catch (Exception e) { e.printStackTrace(); } } } 

Arduino


Le protocole d'envoi des commandes a donc changé, l'algorithme de réception a également changé. Il a simplifié. Un si le coup de pied de suivi a également été ajouté. Une analyse complète du croquis est ici .

bt.read () lit un caractère. Si c'est "#", alors les symboles de vitesse commencent. Nous les lisons jusqu'à ce que le caractère de fermeture "#" apparaisse. La boucle for ne peut pas être utilisée ici, car la longueur de la vitesse n'est pas connue à l'avance (il peut s'agir d'un nombre à un, deux ou trois chiffres). La valeur résultante est écrite dans la variable.

La même chose se produit avec un virage. Après avoir lu la vitesse et l'angle, nous passons tout au tour de fonction (vitesse int, angle int).

 void loop() { if(BTSerial.available() > 0) {//    char a = BTSerial.read(); //   if(a == '#') { //  sp=""; char b = BTSerial.read(); while( b != '#') { //   ,     sp+=b; b = BTSerial.read(); } } else if (a == '@') {//  val = ""; char b = BTSerial.read(); while(b != '@') { //    val+=b; //    b = BTSerial.read(); } turn(val.toInt(), sp.toInt()); //   ,   } else if (a == '/') { //,    Serial.println(a); servo.write(30); //  delay(150); servo.write(0); //    } lastTakeInformation = millis(); } else { if(millis() - lastTakeInformation > 150) { //     150 //  lastTakeInformation = 0; analogWrite(speedRight, 0); analogWrite(speedLeft, 0); } } delay(5); } 

La fonction turn () détermine la direction à suivre (avant, arrière) et où tourner (droite, gauche, droite). La restriction if (vitesse> 0 && vitesse <70) est nécessaire pour que le robot ne ralentisse pas en cas de perte d'octets. Face à cela lorsque j'ai augmenté la vitesse de transmission (joué avec des retards de 100 à 300 ms entre les équipes) - parfois la valeur de la vitesse n'atteignait pas et se transformait en 0, 40 (bien que, par exemple, 240 aient été réellement envoyés). Béquille, mais ça marche.
On peut l'appeler «protection contre des facteurs incontrôlables».

 void turn(int angle, int speed) { if(speed >= 0 && speed < 70) return; if(speed > 0) { digitalWrite(dirLeft, HIGH); digitalWrite(dirRight, HIGH); } else if (sp < 0) { digitalWrite(dirLeft, LOW); digitalWrite(dirRight, LOW); } if(angle > 149) { analogWrite(speedLeft, speed); analogWrite(speedRight, speed - 65); //  } else if (angle < 31) { analogWrite(speedLeft, speed - 65); //  analogWrite(speedRight, speed); } else { analogWrite(speedLeft, speed); analogWrite(speedRight, speed); } } 

Compétitions au MIPT au lieu d'un total


Avec notre robot, nous sommes allés à la compétition de football robotique, qui a été organisée et organisée à l'Institut de physique et de technologie de Moscou, Dolgoprudny, le 14/04/2019. Nous avons réussi à atteindre les finales 1 \ 4, mais n'avons pas avancé plus loin.



Le processus lui-même était intéressant pour nous, mais ici je vais décrire les conclusions que nous avons réussi à tirer en regardant le robot sur le terrain:

  • besoin de plus puissant. Quatre roues ou des moteurs plus puissants et d'autres roues sont souhaitables. Bien que, bien sûr, ce soient les modèles à quatre roues qui semblaient plus avantageux
  • la gestion n'est pas élevée. Il est nécessaire de transférer le robot dans un virage de réservoir (virage à un moment donné en raison de la rotation des roues dans des directions opposées), sinon le rayon de virage est trop grand. Et en général, l'option avec quatre flèches, plutôt qu'un cercle avec une vitesse proportionnelle, est préférable pour le football . L'option décrite est mieux adaptée aux courses où vous conduisez en continu, et ici vous avez besoin de clarté (j'ai tourné de 10 degrés autour de mon axe, dirigé vers le ballon et appuyé sur le bouton vers l'avant. Mais ensuite, quand j'ai déjà attrapé le ballon, je voudrais manœuvrer avec souplesse, mais ici, vous avez besoin de proportionnelle vitesse ... vous devez en quelque sorte combiner cette chose).

Les commentaires et suggestions seront très heureux. Sous les articles précédents, les commentaires sont parfois plus intéressants que l'article lui-même. Merci, Sasha et Dana pour le travail .

Source: https://habr.com/ru/post/fr448080/


All Articles