Réinvestir un capital est un réflexe « capitaliste » pour ne pas qu’il perde de sa valeur. Ce propos pour le moins « financier » n’est pas forcément hors sujet dans un petit projet comme le nôtre. Dans cette manipulation nous allons réinvestir les 356 octets économisés par les mesures drastiques entreprises dans le chapitre précédent. Autant faire afficher des octets sur l’écran était un luxe dont on peut royalement se passer, autant utiliser la belle Fiche n°26 n’a rien de convivial. Si l’on désire orienter la sonde à un CAP magnétique particulier, il faudra constamment interpréter les données de correction. Aussi, envisager une correction automatique par le calculateur de bord est séduisant. La courbe de correction affichée en rouge sur la Fig.150 du TOME 3 fait un peu peur, car pour la reproduire avec des équations trigonométriques on devine confusément qu’il va falloir introduire des harmoniques et de la développée de Fourrier. BEURRRRKKKKK !
Retrouver le Nord.
Outre le fait que ce ne sera pas facile de trouver les équations qui seront capables de traduire la courbe diabolique, leur traduction en langage C++ va engloutir tout le capital restant pour le code objet. Ce n’est évidemment pas acceptable. Toutefois, si l’on regarde un peu mieux le graphe de la Fig.150 et si l’on accepte une correction avec une imprécision pouvant aller jusqu’à ±5°, la situation n’est pas aussi dramatique qu’il n’y parait. Sur la Fig.214 on a superposé des droites à la
courbe rouge, et l’on peut vérifier que ces dernières masquent relativement bien l’ancienne trace. On peut alors considérer que la réalité sera proche des quatre cas 1, 2, 3 et 4. Pour traiter les cas 2 et 4 la solution est immédiate, il suffit de retrancher 40° ou d’ajouter 29° au cap mesuré pour avoir l’orientation réelle. Pour les cas 1 et 3 il faut établir une correction linéaire.
• 1 : De 0 à 85° : Interpoler soit 0/+30 à 85/-40.
• 2 : De 86° à 143° : Enlever 40°.
• 3 : De 144° à 307° : Interpoler soit 144/-40 à 307/+28.
• 4 : De 308 à 359° : Ajouter 29°. (Corriger si valeur >359)
Il se trouve que linéariser une valeur entre deux limites est très facile avec le langage C++ de l’IDE, l’instruction map() est conçue dans ce but. Elle peut manipuler librement pour les limites des valeurs positives ou négatives et dans un ordre quelconque.
La procédure Mesure_orientation_magnetique() se terminera maintenant par la séquence de correction du compas de route. Pour ne pas augmenter la place consommée pour les variables du programme, elle réutilise localement Numerisation, CAN et LSB.
Considérons le listage de la séquence qui traite la correction magnétique :
L’instruction (1) effectue une lecture du capteur puis divise la valeur par dix pour l’avoir en degrés. Pour faciliter l’aiguillage, car il faut distinguer les quatre cas, on transforme le float en int dans la variable Numerisation. Les quatre lignes qui suivent à partir de (2) ont pour but de sélectionner le cas dans l’identificateur CAN par les représentations numériques 1, 2, 3 et 4. La ligne (3) peut alors aiguiller le traitement en fonction de la valeur de Numerisation. S’il faut réaliser une transposition linéaire comme pour le cas 1 par exemple, on commence en (4) à calculer la valeur de la correction à appliquer dans la variable CAN. Puis en ligne (5) on ajoute cette correction linéaire algébrique à la valeur mesurée Numerisation. L’instruction break fait sauter les aiguillages qui
suivent car il est inutile de les tester. La ligne (6) traite le cas 2 et la ligne (7) l’intervalle 4. Cette ligne (7) peut engendrer un petit aléa. Supposons que la valeur mesurée CAP_construit conduise à une valeur de Numerisation égale à 345° par exemple. En ajoutant 29° on obtient 374° et l’on déborde des 359° correspondants à la rose des CAP. La ligne ˆ corrige ce petit écart de conduite. En retranchant 360 on obtient 14° qui correspond bien au CAP indiqué sur une plage de 0 à 359°.
L’ensemble de ces instructions ajoutées consomme 310 octets. On a dilapidé dans cette séquence tout le bénéfice des économies passée. Peu importe, dans l’état actuel du développement il reste encore 1974 octets de disponibles, largement de quoi parer bien des problèmes.
Pour conclure, ce qui semble le plus intéressant à souligner, c’est la façon dont on a traité par approximation un problème qui mathématiquement s’avérait assez indigeste. Aussi, bien plus souvent qu’on n’y pense, ce type de transposition par linéarisation peut nous sortir élégamment de sévères impasses, et ce d’autant plus que les précisions que l’on programme dans nos applications sont souvent exagérées. Un programmeur averti en vaut deux …
La suite est ici.
