Concevoir un robot de service. Énoncé du problème, architecture de la solution

Nous, avec une équipe (à laquelle vous pouvez vous joindre ) de personnes partageant les mêmes idées de Habr, développons un robot pour ramasser des balles de golf sur le practice .



Vladimir Goncharov Shadow_ru parle de la collecte des exigences, de la formulation des tâches pour le travail, du développement d'une architecture et de la création d'un prototype pour l'exécution de logiciels.



Le projet a commencé pour moi, avec la collecte des exigences, la généralisation et la décomposition ultérieure des sous-tâches. La tâche du robot à première vue est simple, mais les erreurs au stade de la planification gâchent considérablement le résultat du travail et ne sont pas toujours visibles immédiatement, donc sauter cette étape est le chemin vers nulle part.

Résumer les exigences simplifie la communication avec les autres membres de l'équipe - une compréhension commune du problème est développée, la situation où chaque robot dans sa tête ne se pose plus. De plus, lorsqu'un nouveau membre entre dans l'équipe, il suffit de lire un document similaire, ce qui réduit le temps de la phase d'entrée.

Il y a toujours un équilibre entre la collecte des exigences et les généralisations - je veux décrire plus en détail, mais si vous n'êtes pas un avocat habitué à travailler avec des centaines de paragraphes connexes - cela ne résoudra pas le problème général de la vision. Il y a bien sûr la bonne approche lorsque plusieurs tranches d'exigences sont faites pour différents membres de l'équipe et des clients et entrepreneurs externes. Mais pour l'instant, c'est clairement inutile, car Chaque modification des exigences entraînera un sérieux investissement de temps pour la mise à jour de ces tranches, ce qui n'affecte pas trop la productivité au démarrage.

Pour ma part, j'ai décidé de décomposer en exigences fonctionnelles et non fonctionnelles et de mettre le tout dans une seule page A4. La première version est sortie comme ceci:

Phase 1. Énoncé du problème

Défi: Un détour maximal continu d'un parcours de golf d'entraînement est requis dans des conditions climatiques difficiles pour ramasser des balles.

Problème: Un véhicule terrestre sans pilote ( UGV ) est nécessaire pour effectuer des missions cycliques pour contourner l'espace défini par le périmètre avec les coordonnées des points dans la notation WGS-84.

Les missions devraient comprendre les opérations suivantes:

1. Démarrage normal à partir d'une position d'origine connue
2. Démarrage d'urgence à partir d'une position inconnue à l'avance (démarrage après le fonctionnement du WD, protection de l'alimentation, etc.)
3. Éviter une zone avec une couverture d'au moins 98% de l'espace pour 1 ou plusieurs courses (recommencer à contourner le champ après avoir rempli la trémie après 15 minutes n'est pas nécessaire)
4. Revenez à sa position initiale pour remplir la trémie, vidanger la batterie, terminer le détour
5. Course sur la plateforme de lancement pour réinitialiser les balles, recharger les batteries

Version simplifiée de l'algorithme



De plus, l'UGV doit remplir les conditions suivantes:

1. Ne laissez pas le périmètre spécifié lorsque vous conduisez autour du périmètre spécifié
2. La position d'origine peut être en dehors du périmètre spécifié.
3. Surveillez la consommation de la batterie et prévoyez un retour en fonction de la puissance consommée. Le déplacement d'une trémie remplie nécessite plus de batterie qu'un vide.
4. Conservez les journaux de télémétrie, y compris, mais sans s'y limiter, les coordonnées sur le plan, les valeurs de 6 axes de rotation, le niveau de signal de la télémétrie et les capteurs externes.
5. Avoir trois systèmes de positionnement - GPS pour obtenir des coordonnées grossières, IMU pour vérifier et corriger les coordonnées sur le plan, optique pour un positionnement précis par des marqueurs.
6. Avoir deux systèmes Watch Dog - logiciel et matériel. Le logiciel vérifie l'état
7. Avoir un canal de communication d'urgence à longue portée avec alimentation séparée, qui est utilisé lorsque les paramètres de mission dépassent les paramètres spécifiés (coordonnées, accident, panne de courant, panne d'équipement)
8. Possibilité de modifier les paramètres de mission à la maison
9. Avoir deux canaux de communication - télémétrique basse vitesse et haute vitesse pour la transmission d'informations audiovisuelles. La haute vitesse devrait pouvoir activer / désactiver la commande de télémétrie.

Sur la base de ces exigences, l'architecture de solution suivante a été choisie:

La structure du complexe robotique comprend: un centre de contrôle (Ground Station Control) - ci-après GSC .

Permet à l'utilisateur d'effectuer les opérations suivantes:

• Définir le périmètre
• Planifier les missions en fonction de l'heure de la journée et de la charge de travail
• Être capable de surveiller des robots de golf avec des lectures discrètes d'au moins 1 minute
• Avoir la capacité d'interrompre une mission

Le logiciel GSC devrait planifier les actions des robots de golf, tandis que les robots eux-mêmes devraient être assez simples. La solution n'est pas très flexible, bien sûr, mais les solutions auto-cohérentes et les réseaux maillés ne sont pas quelque chose qui peut être résolu en peu de temps, et même pas cher. Le plus - c'est une approche typique, et donc des problèmes bien connus. Un ou plusieurs robots de golf (Golf rover) - ci-après dénommés GR .

Effectue les actions typiques suivantes:

• Obtient une mission à moins de 10 mètres d'une station au sol
• Remplit une mission
• Dans le cas d'une mission type, rapports sur un canal de télémétrie avec une fréquence d'au moins 1 fois par minute
• Retourne à la station au sol
• En attente d'une nouvelle mission
• Chaque mission doit être interrompue par les événements suivants:
  
  
  • Remplissage de la trémie à billes
  • Accident de nutrition
  • Impossibilité de mouvement (coup d'État, obstacle soudain)
  • Redémarrage d'urgence
  • Interruption de mission manuelle
• Chaque interruption de mission doit être transmise via la télémétrie conventionnelle et le canal de secours
• Après interruption - GR retourne à la station sol, si son état le permet

Parce que il peut y avoir 1 stations au sol, mais il existe de nombreux GR - remplir la trémie à billes est une urgence. Cela résout deux problèmes à la fois - le GSC sait avec une grande certitude que le robot est allé à la station et a souvent testé le canal de secours. Il est également supposé que le remplissage des balles devrait avoir lieu pendant la mission, et si ce n'est pas le cas, le SGC a quelque part fait une erreur dans la planification et cela devrait être corrigé. Intuitivement, je veux libérer le robot dans un champ propre, et quand il récupérera les balles, il reviendra. Mais ici, l'économie entre en jeu, si 1-2 personnes sont engagées, il est préférable que le robot se tienne à la station et commence à bouger lorsque les balles se sont déjà accumulées. Moins de ressources et de consommation d'énergie.

Une ou plusieurs stations au sol (station au sol) - ci-après GS.

• Charge
• Trémie à billes
• Communication avec GR

Le schéma de l'ensemble du complexe est le suivant:

La deuxième phase est une évaluation des risques et des problèmes possibles de l'ensemble de ce complexe

Pour de bon, vous devez donner un tableau des risques et leurs évaluations, mais je crains que trois feuilles A4 ne provoquent que des bâillements. Je ne donnerai qu'une compression intéressante:

Le problème principal de tous les rovers rampants autonomes est la tâche d'obtenir leur position exacte. De plus, la position doit être très précise - de préférence dans les 10 à 15 cm précisément parce que ce problème ne peut pas être vraiment résolu sur une petite plate-forme mobile, il n'y a pas de drones agricoles / transports / militaires bon marché et massifs.

Bien qu'il semblerait qu'il existe des solutions pour les drones volants, réutilisez tout sur le terrain. Mais cela dans les airs à 10-15 mètres à gauche ou à droite sur un demi-tour ne résout presque rien, mais au sol, cela entraînera des accidents et des catastrophes. De plus, les pierres ne changent pas de place dans l'air, les animaux ne traversent pas la route. Des oiseaux, oui, mais il y a beaucoup plus d'espace dans l'air.

Le positionnement est effectué par le module GPS / GLONASS, ce qui entraîne immédiatement deux conséquences: la précision de positionnement n'est pas trop grande et la vitesse d'obtention des coordonnées. Coordonnées du module uBlox M8N pour les tests stationnaires: 2-3 mètres dans de bonnes conditions de réception, 7-10 dans de mauvaises conditions météorologiques et de visibilité. En général, de telles erreurs pour la collecte des balles sont même bonnes - un rover pour plusieurs missions capturera les balles plus que la conduite sur rails. Cependant, dans ce cas, il s'avère qu'il est impossible de le conduire près d'obstacles tels que des murs ou de grosses pierres et dans ces zones les balles s'accumuleront. Les systèmes de navigation optiques et ultrasoniques ont été analysés, mais il s'est avéré qu'un grand nombre de balises / caméras étaient nécessaires avec une géométrie de champ complexe, il y avait des problèmes avec les zones de visibilité (le champ n'est pas toujours aussi plat que le sol dans le hangar) et la stabilité de ces systèmes dans des conditions météorologiques difficiles ( pluie, brouillard). Donc pour l'instant, notre GPS est tout, mais avec des réservations. De plus, vous pouvez augmenter la précision du GPS à peu de frais - RTK, mais cela ne résoudra pas le problème des murs.

Il est devenu clair que l'approche choisie, lorsque le rover rampe le long des points chargés avec une précision de 5 à 10 mètres de gauche à droite, doit être vérifiée. Monter dans un train appelé SLAM avec les jambes pour une tâche simple semble inutile. Si entrer dans la station par des objets optiquement brillants (Code Aruco) est clair, et combien cela nécessite également des ressources, alors résoudre le problème de la classification de tous les objets possibles sur le terrain ou de la recherche des limites est une tâche complètement différente.

Il est temps pour la phase 3 - Proof of Concept

Il faut faire une maquette du système, le tester en action sur le terrain et évaluer son applicabilité. Selon les exigences développées, les choses sont devenues beaucoup plus amusantes:

En tant que rover logiciel, Ardurover a été choisi - un logiciel en développement actif qui démarre en tant que firmware pour les quadcoptères sur Arduino. Cependant, à ce jour, il prend en charge les cartes Linux avec un noyau RTL et il est ouvert à des améliorations. À l'avenir, je devais le terminer, soit dit en passant, mais plutôt pour accélérer le travail que si nécessaire.

En tant que cerveau du rover, BeagleBone Blue a été choisi - un système hautement intégré pour la robotique.


Une caractéristique distinctive est l'utilisation de puces TI Sitara / Octavo, par rapport à la même Raspberry, il existe une unité programmable en temps réel - PRU. Ce sont deux cœurs séparés de 200 MHz qui peuvent contrôler le fer en temps réel sans distraire le noyau principal avec des interruptions, des threads et d'autres techno-magie.

De plus, la plate-forme dispose immédiatement du WiFi, du Bluetooth, d'un connecteur soudé pour un câble d'équilibrage, d'un contrôleur pour charger les batteries Li-Po, de connecteurs USB pour connecter la télémétrie et un ordinateur, de connecteurs pour servomoteurs, de stabilisateurs de puissance de 5 et 3,3 volts, l'ADC s'est immédiatement retrouvé avec un canal par batterie, plusieurs UART. En général, prenez et fabriquez un robot.

Ardurover n'y est pas allé sans problème - l'utilisation de PRU à partir du logiciel pour le moment n'est possible qu'avec le noyau 4.4 LTS. Dans les noyaux plus récents, la programmation des PRU à partir du logiciel utilisateur entraîne une erreur SIGBUS, après avoir parlé avec les développeurs de la branche ardublue, j'ai commandé un adaptateur JTAG, je vais voir quelle est la raison. Ce rover n'interfère pas du tout avec la vie, mais je veux comprendre clairement quel est le problème.

Le logiciel vous permet de faire presque toutes les exigences, sauf pour le positionnement à l'arrivée à la base, ici j'utilise la caméra JeVois-A33. Il n'enverra pas de signal d'alarme concernant les événements, mais il s'agit d'une tâche pour un module séparé avec une alimentation séparée, comme Le module d'alimentation peut ne pas survivre à une panne de courant ou à un bon coup d'État.

Reste à acheter un récepteur GPS, un émetteur radio télémétrique, un capteur de distance à ultrasons et à connecter une caméra de vision industrielle. Après la soudure, la connexion des connecteurs et un test, cela s'est avéré comme ceci:


En tant que centre de contrôle, Mission Planner est utilisé .


Le logiciel n'est pas incontestable, une interface Web décente au lieu d'un couteau suisse avec 100500+ boutons pour les fans de copters devrait être faite, mais à des fins de débogage, il est plus que approprié. Pour communiquer avec le mobile, le protocole MAVLINK des adaptateurs et des logiciels d'application pour Java / JS est utilisé, beaucoup a été écrit. Bien sûr, j'aimerais avoir des paquets plus petits dans le protocole et maintenir une référence de paramètre standard, mais ce serait trop bien.

Comme base du rover, une machine modèle à l'échelle 1/18 a été utilisée avec un récepteur et un contrôleur de moteur séparés.

Le récepteur a été jeté, les connecteurs du servomoteur et du contrôleur de moteur ont été câblés directement à BeagleBone Blue, tout comme la batterie.

De la chose drôle - je me suis souvenu que, enfant, je ne pouvais pas du tout souder, de la morve en étain pendait tout le temps sur les sites de soudure et j'ai pris le fer à souder non sans inquiétude intérieure. Cependant, dès que le couteau, le fil et le fer à souder sont tombés dans mes mains, j'ai bien cousu la piqûre, coupé l'isolant sans toucher le noyau interne, mes mains ont tordu les extrémités du câble, les ont irradiées et scellé la connexion. Et puis je me suis souvenu que j'avais commencé à travailler en tant que développeur embarqué et pendant quelques mois, je suis entré en communication avec un fer à souder. Une belle illustration du dicton "vous ne boirez pas l'expérience", à mon avis.

Pour le moment, le stand ressemble à ceci:


Comme vous pouvez le voir - le contrôleur sans boîtier et attaches. Malheureusement, j'ai commandé une pseudohermobox à imprimer avec du nylon sur une imprimante SLS 3D, et ils n'ont pas encore réussi à le faire. Faire ressortir le rover dans un champ pur sans coque - un tel Viking peut marcher une demi-heure au grand air. Ensuite, soit la corrosion électrochimique se terminera, soit après un coup-coup, elle sera complètement émise. Nous attendons donc le boîtier, les joints d'étanchéité et les fixations conformément à toutes les règles d'amortissement des chocs et des vibrations.

Vidéo de détection Aruco Code Rover



En conséquence, j'ai passé le test pokatushki à la maison sur le contrôle manuel. Il s'est avéré que la base a été choisie pas tout à fait à droite - elle accélère trop vite, j'ai dû apprendre la programmation du contrôleur de moteur chinois. Le deuxième - marche arrière sur ce miracle de la pensée chinoise est activé par deux signaux «arrière» - le premier allume le freinage, le second allume déjà la marche arrière. Et il peut être ignoré si le signal est trop rapide - il économise la ressource des engrenages et du moteur. J'ai dû finir ardurover, tk. ces astuces n'y étaient pas prises en compte.

Les actions suivantes - annulez l'itinéraire 5-7 fois, supprimez les journaux de télémétrie et les traces GPS des itinéraires. J'ai trouvé un stade de football avec un terrain chauffé, donc s'il neige, ça va. De toute évidence, Rover ne forera pas de congères, sinon Faina Ranevskaya aurait ajouté le golf le long des congères à la liste des perversions en plus du hockey sur gazon et du ballet sur glace. Pas le divertissement le moins cher, bien sûr, mais où ailleurs en Russie, et en novembre, vous pouvez trouver de l'herbe verte. Les travaux ont également commencé sur la mise en œuvre de châssis chenillés, où les vitesses sont beaucoup plus faibles (le modèle actuel accélère à 20 km / h en 15 secondes) et il y a un demi-tour en place, plutôt que des triangles sur un patch. Très probablement, dans quelques semaines, les deux châssis seront rodés en même temps, pour tester le fonctionnement du détecteur d'obstacles et les algorithmes de détour.

En fin de compte, je tiens à noter que la vérification des solutions sur les modèles grandeur nature est très rapide et bon marché. De nombreux problèmes ont été détectés beaucoup plus tôt et, en outre, il est temps d'apporter des modifications à la conception d'un grand robot alors qu'il est encore au stade de la conception ou du prototype. Ensuite, cela coûtera plus cher, plus longtemps et quelque chose cassera quelque chose dans les nœuds de liaison. De plus, sur de tels modèles, presque tous les logiciels nécessaires aux tâches sont facilement développés et vérifiés. Idéalement, tout ce dont vous avez besoin pour passer à un autre modèle est de remplacer le protocole du contrôleur de moteur par un nouveau. Eh bien, il est possible de changer le modèle dynamique.

De plus, l'utilisation de solutions spécialisées et éprouvées économise considérablement du temps et de l'énergie. Inventer sa propre carte de circuit imprimé haute densité, son propre protocole de communication, ses logiciels au sol et son logiciel mobile, déboguer des algorithmes d'évitement d'obstacles et communiquer avec des contrôleurs de moteur chinois est certainement très excitant, mais dans ce cas, vous pouvez immédiatement ajouter une demi-année à un chemin long et cahoteux. Déjà passé par quelqu'un.

J'ai besoin de votre aide:

• Si vous êtes prêt à travailler sur la version ROS.
• Nécessite la préparation de la carte de connexion du module pour les versions Raspberry Pi et Orange Pi
• Aide aux tests de practice, surtout si vous vivez dans un pays où vous jouez activement au golf;
• Questions juridiques, exportation du robot du pays, droit des brevets, exigences législatives en matière de conception;
• Besoin d'aide avec le packaging de démarrage, la recherche d'investissement. Nous évoluons bien et sans investissement, nous avons un plan d'action, une équipe se forme. Plutôt que de l'argent des investisseurs, nous avons besoin de plus d'expérience et de compétences pour développer un projet commercialement réussi.

État actuel du projet

Nous préparons la deuxième version du corps. Dans une semaine, le boîtier sera prêt par moulage sous vide, à ce sujet nous écrirons un article séparé.



La partie inférieure du corps est réalisée par fraisage d'un matériau composite.



Le corps et la mécanique sont conçus par NikitaKhvoryk . Nous attendons depuis longtemps de payer les modules de connexion pour les versions raspberry pi et orange pi de n12eq3 . Version avec Ardupilot Vladimir Goncharov Shadow_ru

Nous remercions Process0169 , Trif , tersuren , vasimv , vovaekb90 , Vyacheslav Soldatov, Levon Zakaryan, Sergey Pomazkin, Vladi Kuban, Karen Musaelyan, Alexey Platonov pour l'aide et les conseils offerts. Si vous voulez aider - veuillez m'écrire dans le LAN ou VK , FB .

Plans:

Nous avons des accords préliminaires sur le placement d'un robot pour les tests dans les clubs de golf en Russie, en Allemagne, en Amérique latine et en Nouvelle-Zélande. Dans un avenir proche, nous allons finaliser les algorithmes et la conception, effectuer des tests à Moscou et apporter des améliorations. Créez 5 robots et placez-les gratuitement dans des clubs de golf pour de longs tests pour la nouvelle saison.



Merci d'avoir lu, demandez-nous et critiquez-nous complètement.