Enfin, nous avons pu publier le SDK promis pour le projet OMower (une plate-forme matérielle et logicielle ouverte pour les robots à roues basée sur le contrôleur ATSAM3X8E 32 bits avec prise en charge du développement dans Arduino IDE). Le niveau d'achèvement du logiciel n'est pas très bon (par exemple, il n'y a pas de classes pour les capteurs de pare-chocs, de pluie et d'herbe, certaines fonctions ne sont pas entièrement déboguées), mais même dans sa forme actuelle, le robot peut conduire avec une grande précision via RTK GPS, il prend en charge presque tout ce qui est nécessaire pour tondeuses - sonars, périmètre câblé, boussole et navigation GPS, charge à partir d'une station de charge ou d'un panneau solaire.
Mon précédent article sur le projet OMowerLe code SDK et les fichiers Kicad avec le circuit et le câblage de la carte
se trouvent sur le github .
Seules deux plates-formes sont actuellement prises en charge - la carte OMower v3 avec les pilotes de moteur double Polulu MC33926 et un tas de pilotes de moteur Arduino Due + IHM12A1 (machine de test sur un petit châssis à quatre roues). Le support Ardumower basé sur Arduino Due peut être ajouté. Il est hautement souhaitable d'avoir une carte IMU GY-80, sans elle, la navigation ne fonctionne pas simplement (bien que vous puissiez faire un simple homme de tondeuse qui conduit accidentellement à l'intérieur du périmètre du fil).
Dans la nouvelle quatrième version de la carte, il est prévu de mettre une IMU MPU9250 dessus et d'ajouter une puce FRAM pour enregistrer les paramètres utilisateur non dans le flash interne du contrôleur (qui est réinitialisé lorsque le firmware est rechargé), eh bien, toutes sortes de cartes peuvent y être stockées. De plus, j'augmenterai probablement les tailles des ensembles résistance et condensateur, souder le 0402 «sur le genou» avec un sèche-cheveux était un plaisir en dessous de la moyenne, et augmenter l'espace pour les connecteurs afin que vous puissiez les mettre avec des pinces, pas seulement des broches collantes.
Le code API est écrit sous la forme d'une poignée de classes (fichiers omower - *. H) que vous devez inclure en tant qu'objets dans votre logiciel (et, facultativement, les inclure tous, vous ne pouvez prendre que ceux qui sont nécessaires, à l'exception des bases). Pour simplifier la compréhension et les tests, OMower_Simple a été
écrit , qui exécute un ensemble assez important de commandes émises via pfodApp à partir de n'importe quel smartphone.
Le SDK prend le contrôle de toutes les fonctions de bas niveau et fonctionne principalement sur les interruptions, ce qui donne au programmeur logiciel final la possibilité d'écrire un logiciel indépendamment des détails spécifiques d'un robot particulier, et de manière très libre (vous pouvez écrire une machine d'état, ou vous pouvez simplement appeler la fonction de démarrage du lecteur et attendez que le robot atteigne le point souhaité). Seules les procédures d'appel aux fonctions d'initialisation et de contrôle de la conduite du robot tombent sur les épaules du programmeur (instructions sur où aller, en fait, et traiter les opérations des sonars et autres capteurs).
Pour connecter des périphériques externes supplémentaires sur la carte (et la prise en charge dans le SDK, bien sûr) - il existe de nombreux connecteurs externes. Par exemple, les servo variateurs standard avec une entrée PPM peuvent connecter jusqu'à quatre pièces (voire six si vous refusez deux moteurs). Il y a beaucoup de capteurs «standard» pour la tondeuse, il y a jusqu'à six de ces sonars et quatre des capteurs de périmètre. Bien sûr, dans la plupart des cas, cela n'est pas nécessaire et une partie de leurs connecteurs peut être utilisée pour connecter d'autres appareils (presque toutes les sorties du microcontrôleur sont sorties). La partie intellectuelle (traitement RTK GPS, connectivité avec wifi) est réalisée par Orange PI Zero, qui est installé dans un connecteur spécial.
Je m'excuse d'avance pour la courbe et le code inachevé à certains endroits, j'ai dû creuser dans d'autres projets, et beaucoup de difficultés de toutes sortes se sont révélées auxquelles je pouvais à peine faire face. Mais j'ai appris beaucoup de nouvelles choses, par exemple, que la courbure de l'ellipse de la Terre à nos endroits est de près de 40 mètres, et que les pôles magnétiques de la Terre parcourent des dizaines de kilomètres d'année en année (sans en tenir compte, le robot a voyagé de point en point avec des lignes très courbes). Parfois, il semblait que je lançais une fusée spatiale et non une tonte de pelouse. :)
Eh bien, en bonus, j'ai également exposé les sources de mon firmware pour l'arduino avec Decawave DW1000, qui organise un mini-réseau de ces appareils et permet au robot de déterminer son emplacement à l'intérieur ou où le GPS RTK ne peut tout simplement pas déterminer ses coordonnées (avec un support pour une quantité presque infinie étiquettes et division en pièces). Ce
firmware est encore très, très brut, mais il peut être utile pour quelqu'un.
Mise à jour, j'ai décidé de compléter l'article avec une histoire sur la façon dont il est organisé à l'intérieur:
L'utilisateur du SDK doit déterminer tous les objets dont il a besoin, appeler la fonction begin () pour tout le monde (initialisation matérielle, une seule fois), puis définir les valeurs de leurs paramètres (après les avoir lues dans le flash ou juste les valeurs par défaut), appeler init () pour tout le monde (la fonction peut utilisé pour réinitialiser l'appareil dont l'objet est responsable), définissez les fonctions de crochet pour poll10 / poll20 / poll50 (10, 20 et 50 fois par seconde) à partir desquelles il doit appeler les fonctions poll * () correspondantes de tous les objets utilisés. Théoriquement, il était possible d'automatiser tout cela dans le code du SDK lui-même, mais j'ai décidé de ne pas le faire en raison de la consommation supplémentaire de ressources du contrôleur. Un exemple de l'utilisation dont vous avez besoin pour regarder OMower_Simple.ino
L'une des classes principales est l'objet moteurs (omower-motors.h), qui contrôle les pilotes de moteur à partir de sa fonction poll10 (). L'utilisateur appelle simplement le roll / move (tourner et rouler sans navigation) ou rollCourse / moveCourse (rouler avec navigation / correction basé sur les données d'un objet enfant de la classe navThing qui, via les fonctions readCourseError (), donne la valeur de l'écart par rapport à la direction de conduite souhaitée )
Les dérivés de navThing sont des objets des classes imu et gps (omower-imu.h et omower-gps.h), le premier est chargé de lire et de convertir les données de la boussole / accéléromètre / gyroscope sous une forme pratique (il donne les valeurs de la boussole et de l'inclinaison en degrés sur deux axes ) La seconde - traite les données GPS et oriente l'objet moteurs dans la bonne direction si vous avez besoin d'un trajet en coordonnées GPS ou RTK GPS (pour ce dernier, la correction est calculée lorsque l'antenne n'est pas placée au centre du corps du robot et correction à court terme par des capteurs de l'odomètre). Le programme utilisateur est responsable de la communication avec le récepteur GPS lui-même et transmet les chaînes NMEA ou les coordonnées prêtes à l'objet gps.
L'objet de tonte (omower-mow.h) est responsable du moteur de cisaillement et de son palan actionneur avec un moteur pas à pas (le cas échéant). L'utilisateur indique à quelle vitesse tourner et quelle hauteur de coupe régler.
L'objet pwmServo (omower-pwmservo.h) contrôle les sorties PWM-A / B / C / D / E / F / G / H (cela ne peut pas être fait via d'autres bibliothèques en raison de conflits possibles avec les temporisateurs).
L'objet de puissance (omower-power.h) est chargé de contrôler les régulateurs de charge et de convertir les valeurs ADC en volts et ampères que tout le monde comprend. Le programme utilisateur doit détecter l'apparition de tension sur les électrodes de charge et appeler la fonction d'activation de la charge, puis il récupérera les cycles PWM des régulateurs pour correspondre au courant de charge.
Étant donné que l'utilisation d'objets Arduin Serial * standard peut interrompre le traitement des interruptions (voir ci-dessous), il existe un objet série (omower-serial.h) pour lire et transmettre les ports série. Malheureusement, le même problème existe avec les bus I2C, ils doivent être utilisés en utilisant les fonctions définies dans due-i2c-blocking.h.
Les fonctions des autres objets sont claires par leur nom, vous pouvez simplement regarder les commentaires dans les fichiers d'en-tête (omower-sonars.h, omower-rtc.h, omower-current * .h, omower-odometry.h, etc.).
Maintenant sur les interruptions au niveau le plus bas. L'objet châssis (omower-chassis.h) configure TIM7 à 100 interruptions par seconde. À chaque interruption, 12 canaux de la puce ADC MAX11617 sont lus (entrés dans un tableau spécial, d'où les objets SDK OMower lisent leurs valeurs - max11617-adc-scan.h). À chaque seconde - une interruption logicielle est générée pour le crochet de fonction poll50 (), à chaque cinquième - poll20 (), à chaque dixième - poll10 (). Ils fonctionnent tous de manière asynchrone (ce qui est pratique, mais impose des restrictions sur l'utilisation du bus I2C, plus tard, je prévois d'y ajouter des transactions / sémaphores).
Le temporisateur TIM5 est également configuré pour générer des interruptions avec une fréquence de 38462 hertz. À partir de cette interruption, tous les canaux du contrôleur ADC interne sont lus et entrés dans un tableau spécial (il prend également en charge la saisie de chaque valeur reçue pour le tampon sélectionné dans le tampon en anneau, ce qui est fait, par exemple, par la classe de périmètre, en filtrant ces échantillons plus tard en utilisant la transformée de Fourier).
Pour générer des informations de débogage, il existe une fonction debug () avec une priorité minimale pour l'affichage des messages (c'est-à-dire que le débogage n'est pas effectué, rien ne sera émis vers la console, mais à tout moment vous pouvez activer au moins le niveau maximum, il sera spammé). Dans les formats de valeurs de débogage (* format printf), les nombres à virgule flottante sont pris en charge (contrairement aux fonctions Arduin standard).
Mise à jour: La nouvelle quatrième version de la carte OMower, jusqu'à présent uniquement un circuit (en attente de la fabrication du PCB). Comprend en outre une boussole / accéléromètre MPU9250, 128 kilo-octets de F-RAM pour enregistrer les paramètres, les cartes, les waypoints et autres choses, tous les connecteurs avec verrous (Molex 22-11-20x3 / 10-11-20x3, compatible avec l'ancienne version à partir d'un 2.54- broches), convertisseurs de niveau logique 74HC4050 pour sonars et odomètres, convertisseurs de puissance 3,3 / 5 volts plus puissants (jusqu'à trois ampères), deux sorties PWM / PPM supplémentaires sur les connecteurs, lignes séparées pour un contrôle indépendant du deuxième pilote de moteur pas à pas, plus de condensateurs tampons pour la stabilité Grands éléments CMS pour un assemblage facile des modifications mineures.
