Étape 1: La partie direction
Pour générer le script de 3 pièces principales sont à considérer : la partie « Directeur », qui peut être dérivée des caractéristiques matérielles, la partie « Contrôlées », les algorithmes traitant les différences (erreurs) entre les estimations et de réalité et de la partie « Réelle », comprenant les données des capteurs (actionneurs) utilisés, fournissant des informations sur la situation réelle de plus probable (!).
L’efficacité du script dépend fortement de l’exactitude des actionneurs utilisés. Par exemple : si les anciens marins auraient eu un système GPS, ils auraient des données plus précises sur leur position réelle.
En utilisant des actionneurs plus, différents, comme encodeurs, une boussole numérique, un retriever GPS (pour utilisation à l’extérieur) ou même un gyroscope, produirait plus de précision sur la situation réelle. Malheureusement, il rend la partie contrôlée un peu plus complexe, car il devait traiter l’influence pondérée des capteurs distincts afin de déterminer les données les plus précises sur la position réelle (« fusion capteur »).
Chaque actionneur utilisé, apportera au moins quelques particulière « bruit » dans les équations. Si un récepteur GPS aurait être récupération de données à une position stable, nous allons dire que 24 heures, le tracé de ces données serait éparpillé autour de la position réelle. À cet effet, la précision d’un système GPS est exprimée par 95 % des lectures relevant d’une certaine gamme (par exemple < 5 mètres). Pour faire face à filtrage de bruit du capteur et d’équilibrer le poids entre les cylindres séparés, il faut utiliser une boucle de régulation plus sophistiquée. Le filtre de Kalman est souvent utilisé pour cela.
Afin de garder les choses simples dans mes premières explorations, j’ai collé à un seul actionneur et utilisé uniquement les encodeurs. Ils génèrent des « tiques » par rotation des axes roue, fournissant ainsi des données sur le tournant réel des roues (ce qui en fait fournit des informations sur la vitesse ou distance).
Il y a beaucoup de différents encodeurs. Codeurs optiques utilisent souvent un disque segmenté pour mesurer les changements (de solide à non solides et vers l’arrière) avec un capteur infrarouge. La résolution (c'est-à-dire la quantité de tiques par révolution de l’axe de roue) de codeurs optiques est plutôt faible et limite ainsi la précision que l'on peut obtenir. Autres encodeurs rendent l’utilisation de disques magnétiques et ont une bien meilleure résolution. Codeurs optiques sont beaucoup moins cher et plus facile à tune/utilisation. Enfin les encodeurs peuvent être simple ou en quadrature. Ce dernier fournit aussi des informations sur le sens de la rotation de la roue.
RB2 a unique encodeurs optiques. Ils ne s’opposent à des restrictions ; surtout sur la précision (> = centimètres) et la fréquence de mesure (il faut au moins 1 tick d’entrer dans la partie contrôlée).
Maintenant nous allons plonger dans la partie « Directeur ». C’est la partie plus factuelle et toutes les variables nécessaires peut être calculés à l’avance et utilisés en tant que constantes dans le script. Si le script est destiné à être utilisé sur plusieurs robots différents, la partie « Directeur » doit être traitée dans la routine d’initialisation du script.
Quelques faits sur RB2 :
- Le châssis est un Baron de Robot DF (4 moteurs, connectés en tant que 2 moteurs différentiels) + étage de fixation supplémentaires
- Codeurs optiques sur les 2 roues avant, générant 20 tiques par révolution.
- La distance entre le Centre des roues = 0,147 m.
- Le diamètre de la roue = 0,065 m.
Ces faits peuvent servir à calculer certaines données importantes :
- Le périmètre de la roue = 0,20 m (c.-à-d. Pi * le diamètre de la roue)
- La quantité de tiques par mètre = 97,9 t/m (soit ticks_per_revolution / _perimeter de roue)
- La full_turn_perimeter = 0,46 m (c.-à-d. wheel_center_distance * Pi) lorsque vous utilisez les deux côtés de la contre-révolution!! Je viendrai à celui plus tard lors d’une plongée en passant par un certain nombre de degrés
- La quantité de ticks_per_full_turn = 45,2 t (c.-à-d. full_turn_perimeter * ticks_per_meter)
- La quantité de ticks_per_degree = 0,13 t (ticks_per_full_turn / 360)
Nous avons donc déjà un grand nombre de données utiles, mais nous devons également quelques chiffres selon la vitesse. Nous avons besoin de connaître la vitesse maximale, que le robot pourrait atteindre. Parfois le fournisseur fournit des données sur le kit et/ou des moteurs, mais qui s’est avéré pour être loin. J’ai fait quelques calculs sur la rotation maximale sur les moteurs, en prenant le taux de déduction de l’engrenage en compte, mais qui s’est également avéré pour être loin.
Pour beaucoup de raisons évidentes (et moins évidents): différences fabrication légère (même si les acquis de la même série), un engrenage de résistance (lubrification), minuscule différences de roue (position, centrale diamètre), l’emprise des pneus, du poids de la voiture et comment elle est distribuée et beaucoup d’influences de l’environnement comme : la surface (résistance, inégalité, planéité) et la même résistance à l’air. Tous les facteurs qui ne peuvent être traités dans le modèle de contrôle et pourquoi certaines données probables doit être acquis par des tests dès le départ (en gardant autant facteurs aussi constante que possible).
La vitesse maximale du robot trouvera mieux en l’exécutant dans le même environnement à PWM maximale pour un certain temps et mesure la distance du milieu de cette course. Je pense que cela pourrait être mieux mesuré en comptant les tiques encodeur et recalculer ces derniers en mètres (cette opération prendra au moins le bruit de l’encodeur en compte).
RB2 est sorti avec 0,31 m/s (le fournisseur fourni 0,68 m/s). Avec ce chiffre, nous pouvons calculer une autre variable nécessaire : le max_ticks_per_second = 30,4 t/s (c.-à-d. ticks_per_meter * max_speed)
Enfin, nous devons la vitesse de décrochage. Cela se retrouve en testant : commencez par PWM 0.0 et augmenter la PWM jusqu'à ce que le robot commence vraiment à bouger. Il est courant d’être 5 à 30 % de votre totale portée PWM. Pour RB2, je suis sorti avec : 0.124 m/s.
Maintenant, nous avons toutes les données pour estimer la vitesse et la distance effectuée par le robot de franchir une certaine distance à une certaine vitesse. La figure ci-dessous montre le schéma typique d’une telle exécution.
