Initialement, OMower a été conçu pour les interfaces de contrôle pfodApp et Modbus simples. Le premier est un protocole de texte de haut niveau dans lequel les menus et les commandes de contrôle sont transmis, et le second est une chose bien connue, mais pas très pratique dans cette application, car il nécessite que le programme de contrôle interroge constamment l'état de tous les capteurs utilisés «manuellement». Par conséquent, il a été décidé de passer progressivement à ROS (Robot OS), un framework largement utilisé pour contrôler divers robots.
À l'heure actuelle, le support ROS est à un stade initial, comprenant uniquement la transmission d'informations à partir de capteurs sous la forme de tableaux simples (sans utiliser les formats de message spécialisés offerts par de nombreuses bibliothèques ROS), les journaux de débogage et le flux de contrôle des commandes au format pfodApp / Modbus, sans possibilité vraiment contrôler le robot avec des outils ROS standard. Autrement dit, afin de déplacer le robot de sa place ou de modifier n'importe quel paramètre interne du robot, vous devrez lui envoyer une commande de texte au format pfodApp. Mais même sous une forme aussi tronquée - vous pouvez facilement diffuser et enregistrer ce qui se passe avec le robot, en visualisant ses mouvements dans les outils ROS (rviz) standard, ainsi qu'en ajoutant des services pour des fonctions supplémentaires. C'est, par exemple, l'occasion de rouler en direction du gabarit visuel (damier) fourni par omower_seeker.py, pour une arrivée précise au parking.
L'image montre des flux de données dans le robot. Les principaux services ROS sont exécutés sur Orange PI Zero, coincé dans un emplacement spécial sur la carte du robot (sur une machine de test, Raspberry PI3 est utilisé pour cela, connecté de manière similaire - via le port série). Via l'interface rosserial, le robot transmet des messages de capteurs (tels que / imu / orientation ou / motors / PWM), son journal de débogage au format texte et la sortie des menus / messages au format pfodApp ou Modbus vers le noyau ROS, recevant un flux de commandes texte ou Modbus -quies. Deux Raspberry PI Zero supplémentaires sont livrés avec des flux d'images provenant de caméras, mais comme la pratique l'a montré, il est impossible d'obtenir une synchronisation normale pour le traitement des images stéréo avec ce schéma (la qualité est visible dans l'image ci-dessous), donc une caméra stéréo normale sera bientôt remplacée.
Le degré d'intégration de ROS dans OMower augmentera progressivement, jusqu'à fournir un accès complet à toutes les variables internes du robot et la capacité de le gérer via des outils ROS standard (tels que les messages cmd_vel qui spécifient la vitesse requise).
Je vais vous en dire un peu plus sur le module omower_seeker.py, comme exemple d'utilisation de ROS pour ajouter des fonctions à OMower. Son but est assez simple - aller dans la direction de l'échiquier, en ajustant votre itinéraire en temps réel. Cette fonction sera utilisée pour conduire la tondeuse jusqu'à la station de stationnement, où elle pourra rapidement charger ses batteries. En analysant l'image de l'une des caméras, le module calcule deux angles (l'angle de déviation de la carte par rapport au centre de la caméra et l'angle de rotation de la carte elle-même par rapport à la perpendiculaire) et les transmet sous forme de commande de texte au module de recherche interne (omower-seeker.h / cpp dans le SDK OMower).
Extérieurement, cela semble être une tâche assez simple, mais dans la vraie vie, il y a un problème grave - la vitesse de traitement de l'image sur un micro-ordinateur intégré au robot. Comme le montre la pratique, la vitesse de recherche de motifs en ouverture dans l'image lors de l'utilisation d'Orange PI et de Raspberry Pi relativement faible puissance est très faible et instable, prenant de quelques dizaines à centaines de millisecondes à une résolution de 640x480, ce qui pendant la conduite se transforme en déviations de l'itinéraire nécessaire, car le robot , même avec sa faible vitesse, parvient à tourner un angle important ou à parcourir une distance relativement importante pendant ce temps. En fait, c'est pourquoi un échiquier avec un minimum de cellules a été choisi, car les autres modèles prennent encore plus de temps.
Pour compenser le long temps de recherche du modèle visuel, un schéma de boussole est utilisé - le microcontrôleur robot stocke ses valeurs toutes les 100 millisecondes, stockant cinq échantillons dans la dernière demi-seconde (les analyses plus longues sont simplement ignorées, car elles sont peu utiles pour une navigation précise). Les angles calculés à partir d'omower_seeker.py (qui transmet également le temps de recherche du modèle au microcontrôleur) sont recalculés à l'angle de rotation réel en utilisant la valeur de la boussole enregistrée, qui ne dépasse pas 100 millisecondes à partir du temps de recherche, et le robot se déplace le long de cet angle. Cela vous permet d'aller plus ou moins précisément en direction de l'échiquier en ligne droite. Ou, s'il est légèrement tourné par rapport à la perpendiculaire - le long d'un arc corrigeant l'angle d'approche afin qu'il soit aussi proche que possible de l'axe du gabarit, car nous devons non seulement conduire jusqu'à la planche, mais aussi entrer dans les rails de guidage et se connecter aux contacts de charge.
L'algorithme complet d'arrivée à la gare est mis en œuvre en trois étapes. Deux points sont définis sur le champ GPS - le point de départ (quelque part au milieu de la zone de travail) et le point devant la station, ainsi que l'angle de rotation par rapport à la station. Une fois que le robot est arrivé du point de départ au second et s'est tourné vers l'angle souhaité vers le damier de la station, le module de recherche entre en action, ajustant la vitesse des moteurs via le contrôleur PID. Si l'une des étapes a échoué ou si les angles de déviation dépassent les valeurs définies, le robot annule la course et revient à nouveau au point de départ.
Liens et vidéo:
→
OMower SDK, bibliothèque pour Arduino IDE et disposition des circuits imprimés→
Micrologiciel prêt à l'emploi utilisant le SDK qui implémente à la fois pfodApp / Modbus et la connexion à ROS→
package omower_gateway pour ROS