Marouan Hamza

Vue d’ensemble

ROBOT-AI est un chef d’orchestre intelligent : il perçoit (voix, clavier, vision), raisonne (architecture multi-agents), retient (mémoire long terme), et agit sur des systèmes externes (APIs, outils logiciels). Je conserve le rôle de CEO et administrateur principal, avec validation finale des décisions sensibles.

• Analyser les besoins du marché local (notamment en France)
• Évaluer la faisabilité technique et économique d’un projet
• Définir les ressources nécessaires et produire une vision industrielle complète de bout en bout
• Servir d’outil d’aide à la décision pour des projets réels

Architecture multi-agents

Chaque agent occupe un rôle métier précis : direction, coordination, ingénierie, développement logiciel, analyse marché, finance, qualité et industrialisation. La valeur du projet réside dans l’orchestration de ces agents, la mémoire persistante et la sécurité des actions sensibles.

Technologies

Stratégie d’adaptation par modèle : certains agents utilisent Groq pour la rapidité, l’agent logiciel utilise Claude pour le raisonnement avancé, le directeur peut s’appuyer sur OpenRouter pour accéder à plusieurs modèles selon le contexte. Cette approche optimise qualité, vitesse et coût simultanément.

Sécurité (biométrie vocale) : j’ai intégré un algorithme de reconnaissance vocale par empreinte vocale afin d’authentifier l’administrateur  ; lors des actions sensibles (exécution, accès cloud, modifications), le robot exige une validation par signature vocale en plus des confirmations classiques.

Résilience & Sécurité

Le robot est conçu pour rester opérationnel en toute circonstance :

• Coupure Internet → basculement automatique sur LLM locale (Llama 3.2 via Ollama)
• Expiration de tokens API → fallback automatique vers une autre API cloud disponible
• Actions sensibles → validation multi-niveaux : reconnaissance faciale + commande valide + confirmation écran + bouton physique

Problèmes rencontrés & Solutions

1. Gestion de la mémoire contextuelle : les LLM n’ont pas de mémoire native. Solution : système de mémoire externe gérant mémoire entreprise, mémoire projet, historiques de décisions, résumés automatiques et contexte long terme — persistant et transférable entre machines.
2. Disponibilité du service : dépendance aux APIs cloud (latences, pannes, limites de tokens). Solution : architecture de fallback à deux niveaux (cloud → local → autre cloud) avec basculement transparent.
3. Sécurité des actions critiques : un agent IA ne doit pas exécuter des actions irréversibles sans contrôle humain. Solution : pipeline de validation multi-facteurs avec bouton physique comme dernier verrou.
4. Performance embarquée : les LLM sont gourmands en ressources. Solution : modèles optimisés edge (3B–11B paramètres), avec migration planifiée vers NVIDIA Jetson pour l’inférence locale haute performance.

Résultats / Apprentissages

Matériel cible

Vue d’ensemble

Smart Viewer est un système d’inspection industrielle temps réel destiné à détecter et corriger les défauts couleur sur des pièces imprimées en sortie de ligne de production. L’architecture distribuée RPi5 + Pico W communique via RS485 pour piloter 4 moteurs NEMA23 (drivers TB6600) responsables de la correction physique des défauts. Une interface PyQt5 multithreading garantit la stabilité de l’UI même sous forte charge.

• Inspection couleur temps réel par vision par ordinateur (OpenCV)
• Pilotage de 4 moteurs NEMA23 via drivers TB6600 et protocole RS485
• Interface opérateur PyQt5 réactive et intuitive
• Architecture distribuée RPi5 (traitement) + Pico W (actionneurs)

Technologies

Problèmes rencontrés & Solutions

1. Synchronisation vision / actionneurs : latence entre la détection d’un défaut et la correction physique. Solution : architecture multithreading avec bus de messages interne séparant le pipeline de traitement image du pipeline de commande moteur.
2. Stabilité de l’interface sous charge : le traitement OpenCV en temps réel saturait l’UI thread. Solution : isolation stricte des threads UI et traitement, avec queue thread-safe pour la communication inter-threads.
3. Fiabilité du lien RS485 : pertes de trames lors de rafales de commandes. Solution : protocole de communication avec acquittement et retry automatique implémenté côté MicroPython sur le Pico W.
4. Calibration couleur : variabilité des conditions lumineuses affectant la détection. Solution : algorithme de calibration automatique au démarrage avec profil de référence réglable par l’opérateur.

Résultats / Apprentissages

Vue d’ensemble

OptiQt est un framework modulaire structuré en quatre couches indépendantes : Core (moteur applicatif), Vision (traitement OpenCV), CNC (génération G-code et communication série) et UI (interface PyQt5). Cette architecture facilite la maintenance, les tests unitaires et l’extension vers de nouveaux types de machines ou d’algorithmes de vision.

• Traitement d’image OpenCV : extraction de contours, analyse optique, segmentation
• Génération automatique de G-code à partir des résultats de vision
• Pilotage machine via communication série (PySerial)
• Tests unitaires Pytest avec environnement virtualisé
• Interface HMI PyQt5 pour supervision temps réel

Technologies

Problèmes rencontrés & Solutions

1. Couplage fort entre vision et CNC : les premières versions mélangeaient traitement image et génération G-code, rendant les tests difficiles. Solution : introduction de l’architecture en 4 couches avec interfaces bien définies entre chaque module.
2. Précision de la génération G-code : les contours extraits par OpenCV contenaient du bruit entraînant des trajectoires imprécises. Solution : pipeline de post-traitement (lissage de courbe, simplification de polygone, filtrage adaptatif).
3. Testabilité du code de pilotage machine : impossible de tester sans une machine physique connectée. Solution : couche d’abstraction de la communication série avec mock injectable pour les tests unitaires Pytest.

Résultats / Apprentissages