Dans un monde où les appariels portables intelligents sont omniprésents, les attentes des utilisateurs en matière d'expérience utilisateur dépassent largement la simple fonctionnalité pour tendre vers la fluidité et l'intuitivité. Pour un appareil comme le traducteur IA d'Inno, qui excelle dans la communication multilingue en temps réel, la qualité de l'interaction tactile est aussi cruciale que la précision de la reconnaissance vocale et des moteurs de traduction. Des sauts ou des tremblements mineurs lors du changement de langue, du défilement de l'historique ou de la sélection de texte peuvent perturber le flux d'une conversation immersive.

La réalité de l'entrée tactile est loin d'être idéale. Les coordonnées brutes fournies par l'écran capacitif sont souvent sujettes à des variations brusques, des interruptions et des micro-vibrations en raison de la fréquence d'échantillonnage limitée du matériel (typiquement 60-120 Hz), de la latence de communication et des interférences ambiantes. Ces imperfections, même minimes, peuvent se traduire par des animations d'interface saccadées, une mauvaise interprétation des gestes ou un curseur tremblant. Ces problèmes sont exacerbés dans des conditions difficiles, comme le port de gants ou des doigts humides.

Pour relever ce défi, l'équipe d'Inno a implémenté une technologie de reconstruction de trajectoire tactile au niveau du système embarqué. Celle-ci utilise des algorithmes pour débruiter, interpoler et prédire les données brutes, recréant ainsi un chemin de mouvement plus proche de l'intention réelle de l'utilisateur. L'objectif n'est pas seulement d' "adoucir les lignes", mais d'atteindre un équilibre délicat entre précision, réactivité et consommation de ressources, le tout avec une latence extrêmement faible.

Prenons l'exemple d'un simple glissement de page. Le contrôleur tactile peut signaler une nouvelle coordonnée toutes les 8 ms (125 Hz). Cependant, des fluctuations dans l'ordonnancement du MCU ou la communication I²C peuvent rendre l'intervalle d'échantillonnage irrégulier. Si ces points discrets sont directement transmis au framework d'interface graphique (comme LVGL ou TouchGFX), l'animation de défilement peut apparaître "en escalier", perdant la sensation d'inertie. Pire encore, de légers tremblements des doigts pourraient être interprétés comme des changements de direction, provoquant des mouvements de page erratiques.

La solution d'Inno consiste à créer une couche de traitement intermédiaire légère mais intelligente : un moteur de reconstruction de trajectoire, situé entre le pilote et l'interface graphique. Sa fonction n'est pas de simplement relayer les données, mais de "comprendre" activement l'intention de l'utilisateur et de générer un flux de trajectoire virtuel à haute fréquence et à faible jitter. Ce processus peut être décomposé en quatre étapes clés :

1. Collecte de données brutes : Les triplets (x, y, t) du contrôleur tactile (par exemple, Goodix GT911 ou FT6X36) sont reçus par le système.
2. Prétraitement et débruitage : Les points aberrants évidents (par exemple, une distance excessivement grande entre deux points consécutifs) sont éliminés pour éviter de perturber les analyses ultérieures.
3. Alignement temporel et interpolation : L'interpolation linéaire ou par spline est utilisée pour générer des états intermédiaires entre les points valides, augmentant la fréquence de sortie à 240 Hz ou plus.
4. Prédiction dynamique et sortie lissée : La vitesse est utilisée pour prédire la position suivante, et des algorithmes de filtrage adaptatif produisent les coordonnées finales.

Le principal défi ici est de terminer le traitement de bout en bout en moins de 8 ms pour éviter toute latence perceptible par l'utilisateur. Par conséquent, les modèles mathématiques complexes doivent être optimisés pour s'adapter aux ressources limitées des MCU de type ARM Cortex-M7/M4F.

Une méthode de lissage simple et efficace est la Moyenne Mobile Pondérée Exponentiellement (EWMA). Elle ne nécessite pas le stockage d'un historique complet, calculant le résultat actuel en se basant uniquement sur la valeur lissée précédente. Voici un exemple d'implémentation :

#define SMOOTH_ALPHA 0.3f

typedef struct {
    float x;
    float y;
} Point_t;

Point_t smooth_touch(Point_t raw, Point_t prev_smooth) {
    Point_t smoothed;

    smoothed.x = SMOOTH_ALPHA * raw.x + (1.0f - SMOOTH_ALPHA) * prev_smooth.x;
    smoothed.y = SMOOTH_ALPHA * raw.y + (1.0f - SMOOTH_ALPHA) * prev_smooth.y;

    return smoothed;
}

Dans cet exemple, SMOOTH_ALPHA contrôle le poids accordé aux nouvelles données par rapport aux anciennes. Une valeur plus faible entraîne un lissage plus important, mais augmente également la latence de réponse. En pratique, un paramètre fixe peine à couvrir tous les scénarios : un lissage plus fort est nécessaire pour les ajustements fins et lents afin de supprimer le jitter, tandis qu'un défilement rapide exige une latence plus faible pour préserver la fidélité du mouvement.

Pour pallier cela, l'équipe a introduit une stratégie de filtrage adaptatif : le coefficient alpha (α) est ajusté dynamiquement en fonction de la vitesse de glissement estimée en temps réel.

if (speed < 5 px/ms)     -> α = 0.2 (lissage élevé)
else if (speed < 20)     -> α = 0.4 (moyen)
else                     -> α = 0.7 (faible filtrage, réponse rapide)

Ce contrôle à plusieurs niveaux améliore considérablement la cohérence de l'expérience utilisateur. Cependant, pour des besoins plus avancés, notamment lorsque des changements d'accélération ou des trajectoires de gestes complexes sont impliqués, l'EWMA simple devient insuffisante.

Dans de tels cas, le filtre de Kalman représente une soultion plus robuste. Cet algorithme d'estimation récursif d'état permet d'inférer l'état latent d'un système (comme la vitesse et l'accélération) de manière optimale, même en présence de bruit de mesure. Dans le contexte tactile, le point de contact est modélisé comme un système de mouvement bidimensionnel :

Vecteur d'état X = [x, vx, y, vy]^T
Entrée d'observation Z = [x_mesuré, y_mesuré]

Grâce à une boucle de prédiction-mise à jour, le filtre de Kalman non seulement fournit la meilleure estimation de la position actuelle, mais suit également en continu la tendance du mouvement, permettant une prédiction raisonnable des positions futures. Comparé aux filtres statiques, il offre une meilleure capacité à capturer les tendances tout en maintenant une faible latence, ce qui le rend particulièrement adapté aux opérations non uniformes comme le défilement rapide ou le glissement de courbes.

Voici une structure d'implémentation simplifiée adaptée aux plateformes embarquées :

typedef struct {
    float x, vx, y, vy;
} StateVector;

typedef struct {
    StateVector X;
    float P[4][4];  // Matrice de covariance
    float Q[4];     // Bruit de processus (perturbation position/vitesse)
    float R;        // Bruit de mesure (erreur capteur)
} KalmanFilter;

void kalman_predict(KalmanFilter *kf, float dt) {
    // Mise à jour de la position basée sur la vitesse actuelle
    kf->X.x += kf->X.vx * dt;
    kf->X.y += kf->X.vy * dt;

    // Propagation simplifiée de la covariance
    for (int i = 0; i < 4; ++i)
        kf->P[i][i] += kf->Q[i];
}

float kalman_update(KalmanFilter *kf, float mx, float my) {
    // Calcul du gain de Kalman et mise à jour de l'état
    float S = kf->P[0][0] + kf->R; // Simplification pour le terme S
    float Kx = kf->P[0][0] / S;
    float Ky = kf->P[2][2] / S; // Utilisation P[2][2] pour y

    float dx = mx - kf->X.x;
    float dy = my - kf->X.y;

    kf->X.x += Kx * dx;
    kf->X.y += Ky * dy;

    // Correction simplifiée de la vitesse
    // La dérivée de la position donne une estimation de la vitesse
    kf->X.vx += 0.1f * dx / dt; // Coefficient arbitraire 0.1
    kf->X.vy += 0.1f * dy / dt;

    return kf->X.x, kf->X.y; // Retourne la position estimée
}

Bien que les opérations complètes de matrices soient omises pour simplifier, cette version fonctionne de manière stable sur des plateformes comme le STM32H7. L'utilisation de la bibliothèque CMSIS-DSP peut améliorer davantage l'efficacité. Lors du débogage, les paramètres clés tels que le bruit de processus (Q) et le bruit de mesure (R) doivent être ajustés minutieusement en fonction des données mesurées. Typiquement, des valeurs de Q définies sur diag([0.1, 0.5, 0.1, 0.5]) et R autour de 2.0 donnent de bons résultats dans la plupart des scénarios.

Dans l'architecture globale du système, le module de reconstruction de trajectoire est planifié comme une tâche RTOS distincte, déclenchant son cycle de traitement toutes les 2 à 5 ms pour se synchroniser avec le taux de rafraîchissement de l'écran. Son comportement n'est pas fixe mais change intelligemment en fonction du contexte :

• Lors d'un glissement stable détecté, il passe en mode interpolation avancée + prédiction de Kalman pour une sortie virtuelle à 240 Hz.
• En cas d'inactivité ou de toucher léger, il bascule en mode direct pour minimiser la latence.
• Un mécanisme de "désébranlement" est activé pour les légers tremblements prolongés afin d'éviter de les interpréter comme un glissement continu.
• Il gère indépendamment plusieurs doigts pour les gestes composites comme le zoom ou la rotation.

De plus, des interfaces configurables sont disponibles pour différents cas d'utilisation. Par exemple, le niveau de lissage peut être augmenté pour la saisie manuscrite, tandis que la réactivité prime lors de la navigation dans les menus. Cette flexibilité permet à la même pile d'algorithmes de prendre en charge diverses formes d'interaction.

Du point de vue de l'expérience utilisateur, les améliorations apportées par cette technologie sont tangibles et significatives :

• Les glissements rapides sont fluides, sans saccades ni perte d'images, et les animations suivent le mouvement de manière plus fidèle.
• La sélection de texte est plus précise, avec une réduction notable du jitter sur les bords.
• Lors de l'utilisation de gants, la continuité de la trajectoire validée par le système évite les interruptions intempestives.
• Les erreurs de toucher entre de petits boutons sont réduites grâce à un mécanisme d'aide à la décision basé sur la reconnaissance de direction.

Plus important encore, tout cela est réalisé sans mise à niveau matérielle de l'écran tactile. Cela permet aux fabricants d'offirr une sensation d'utilisation proche de celle des smartphones haut de gamme, même avec des solutions tactiles plus économiques, démontrant ainsi l'ingéniosité de "combler les lacunes matérielles par le logiciel".

Bien entendu, toute optimisation a un coût. Sur une plateforme Cortex-M7 @ 480 MHz, la tâche de reconstruction de trajectoire consomme en moyenne environ 3 % du CPU. Bien que contrôlable, cela nécessite une attention particulière à la consommation d'énergie dans les appareils alimentés par batterie. Il est conseillé de désactiver l'unité de calcul en virgule flottante et d'utiliser des nombres en virgule fixe (Q15) pour les algorithmes clés lorsque la précision n'est pas primordiale, afin de réduire davantage la consommation d'énergie.

À l'avenir, avec l'amélioration des capacités de l'IA en périphérie, la reconstruction de trajectoire tactile pourrait évoluer de la "réparation passive" à la "prédiction active". Par exemple, en se basant sur les modèles de comportement historique de l'utilisateur, le système pourrait anticiper la fin d'un glissement et précharger le contenu ; ou utiliser des réseaux neuronaux pour reconnaître l'intention d'un geste avant même sa complétion, initiant une réponse précoce. De tels "systèmes d'entrée basés sur la compréhension de l'intention" pourraient redéfinir les frontières de l'interaction homme-machine.

La mise en œuvre actuelle sur le traducteur IA d'Inno prouve que même dans des environnements embarqués aux ressources limitées, une conception algorithmique judicieuse peut améliorer significativement la qualité de l'interaction. Il s'agit non seulement d'une amélioration de l'expérience utilisateur, mais aussi d'une étape cruciale vers des interactions plus réalistes et humanisées pour les terminaux intelligents.