La SunFounder Fusion HAT+ ressemble à un simple HAT pour Raspberry Pi… jusqu’au moment où vous réalisez que c’est plutôt un couteau suisse pour robot “assisté par IA”. Elle ne “fait” pas l’IA toute seule : les neurones restent sur le Raspberry Pi (un Pi 5 dans mon cas), mais la carte apporte le muscle et l’intendance. Gestion d’alimentation avec pack 2×18650, microcontrôleur embarqué, drivers pour 4 moteurs CC et sorties PWM pour servos : de quoi piloter un engin qui bouge vraiment. Bonus sympa : micro + haut-parleur pour imaginer des commandes vocales, des retours audio, et des interactions plus naturelles.
Dans cet article, je vous propose de la décortiquer, de la tester sur le terrain, et de voir ce qu’elle vaut quand on lui confie un vrai projet.

Au sommaire :

1 Test de la SunFounder Fusion HAT+ sur Raspberry Pi 5 : une carte “IA-ready” qui pilote moteurs, servos et alimentation

Test de la SunFounder Fusion HAT+ sur Raspberry Pi 5 : une carte “IA-ready” qui pilote moteurs, servos et alimentation

Déballage – une boîte simple, mais sérieuse

La Fusion HAT+ arrive dans une boîte en carton rigide qui inspire confiance (les cartes sont protégées par des sachets antistatiques dans la boîte). Sur le dessus, SunFounder résume clairement les fonctions :
batterie rechargeable, arrêt propre (safe shutdown), 12 sorties PWM,
4 drivers moteurs CC, haut-parleur + micro, I2C/SPI/UART,
4 entrées ADC 12 bits, et la compatibilité
Raspberry Pi 5 / 4 / 3B+ / Zero 2 W.
Légende photo : « Boîte de la SunFounder Fusion HAT+ : les fonctions principales sont annoncées noir sur blanc. »

La carte – vue de dessus

Une fois sortie de sa boîte, la carte annonce la couleur : c’est un HAT orienté “robotique” avec de l’audio intégré. On retrouve le connecteur GPIO 40 broches en haut, et surtout, à droite, les rangées de connecteurs dédiés aux servos (PWM) : c’est très lisible, avec le repérage des canaux, et les colonnes SIG / 5V / GND (pratique pour éviter les erreurs de branchement).
À droite également, le haut-parleur est déjà monté, et on voit les connecteurs moteurs
M1 à M4 (JST) pour piloter des moteurs CC. En bas à gauche, un port USB-C “CHARGE” sert à la charge de la batterie.

La carte – vue de dessous

Dessous, SunFounder a eu la bonne idée d’imprimer un pense-bête directement sur le PCB : “SPECIFICATION” avec la batterie 7,4 V Li-ion, la charge, et les rails d’alimentation (dont le 5 V et le 3,3 V). On trouve aussi un tableau qui rappelle le mapping des canaux moteurs vers des broches (Pxx), et plusieurs pastilles / points de test utiles pour le debug. Bref : ce n’est pas juste “le côté moche avec les soudures” : c’est aussi une mini fiche technique intégrée.N’oubliez pas que ces infos seront « sous » la carte une fois qu’elle sera fixée sur le Raspberry Pi 😀
Le petit bloc métallique au dessus de l’inscription « FUSION »‘ est le microphone, je vais y revenir.

Alimentation – prise de charge USB-C et pack batterie 2×18650

La prise USB-C « CHARGE »

Sur le bord de la carte, SunFounder a prévu un connecteur USB-C dédié à la charge, clairement sérigraphié CHARGE. C’est un point pratique : on recharge directement le pack sans devoir passer par une alim externe ou un chargeur « au hasard ». La présence de cette prise confirme que la Fusion HAT+ n’est pas qu’une carte d’E/S : elle intègre une vraie gestion d’énergie pour un usage nomade/robotique.

Le pack batterie fourni : Li-ion 7,4 V – 2000 mAh

La carte est livrée avec un pack Li-ion 7,4 V – 2000 mAh, basé sur 2 accus 18650 montés en série (2S). Le marquage sur la gaine est explicite : « Li-ion Battery 7.4V 2000mAh ».

Équilibrage (3 fils) : ce n’est pas un simple +/−

Détail important : le pack utilise un faisceau à 3 fils. Ce troisième fil correspond au point milieu entre les deux cellules, ce qui permet l’équilibrage lors de la charge (chaque élément peut être surveillé/ajusté). On est donc sur une approche « propre » pour un pack 2S, ce qui est rassurant côté sécurité et longévité.

Connecteur batterie « BATTERY »

Le pack se branche sur un connecteur dédié, sérigraphié BATTERY, placé sur le bord de la carte.
Là encore, c’est du pratique : le branchement est détrompé (impossible de l’enficher à l’envers), et le connecteur est dimensionné pour un pack 2S avec 3 conducteurs (plus, moins et point milieu pour l’équilibrage). Juste à côté, SunFounder positionne aussi les LEDs Power et utilisateur (LED).

Circuit de charge – repérage et rôle des composants

Sur cette zone de la carte (photo ci-dessus), le circuit de charge est identifiable assez facilement : c’est le composant marqué IP2326 (en bas à gauche). Il gère la charge du pack Li-ion 2S (7,4 V nominal)selon un profil de charge adapté (courant constant puis tension constante). Juste à proximité, la grosse self marquée 2R2 indique que la charge se fait via une alimentation à découpage (conversion DC/DC), ce qui est logique pour charger un pack 2S à partir du 5 V USB :
il faut élever la tension pour atteindre la tension de fin de charge du pack.
Les composants RT6206AH et AMS1117-3.3 visibles sur l’image sont des régulateurs d’alimentation (distribution des rails de la carte, notamment le 3,3 V pour la logique). Le « cerveau » de la charge reste bien l’IP2326, associé à la self 2R2.

Le microcontrôleur (MCU) – le “chef d’orchestre” de la Fusion HAT+

Au centre de cette zone, on distingue clairement le microcontrôleur marqué GigaDevice,
avec la référence de la famille GD32E230 (architecture ARM). C’est lui qui sert de cerveau embarqué à la carte : il assure la coordination des fonctions “temps réel” (gestion d’alimentation/états, pilotage des sorties, lecture des entrées, etc.) pendant que le Raspberry Pi s’occupe de la partie “couche haute” (Python, IA, vision, logique applicative).
Dit autrement : l’IA et les programmes tournent sur le Pi, mais tout ce qui doit rester fiable, réactif et autonome (même quand Linux tousse) est typiquement délégué à ce MCU.

À côté du MCU, en haut à droite de cette photo, le composant marqué NS4168 n’est pas un simple ampli “analogique” : c’est un amplificateur audio mono Class D 2,5 W à entrée numérique, avec anti-aliasing et une interface I2S.
Détail intéressant sur cette image : l’entrée acoustique du microphone se fait via un trou traversant dans le PCB, sérigraphié « MIC ». Concrètement, le son entre par ce “port” (bottom-port) et arrive directement sur le micro situé de l’autre côté de la carte, juste dessous.
Sur le composant microphone, le marquage relevé est « 484 XLKTS » (probablement un code lot/production plutôt qu’une référence commerciale exploitable telle quelle). Ce type d’implantation est typique d’un micro MEMS bottom-port et permet d’intégrer proprement le micro sur un HAT sans exposer directement la capsule sur la face composants.

Zone GPIO + bus de communication (I²C / SPI / UART)

Sur cette partie de la carte, on est au plus près du connecteur GPIO 40 broches du Raspberry Pi (en haut de l’image). SunFounder a sérigraphié des repères très explicites pour retrouver rapidement les bus principaux : I²C (SDA/SCL), SPI (MOSI/MISO/SCLK/CS) et UART (TX/RX), avec un rappel du niveau logique 3V3.
Le petit connecteur blanc au centre (juste au-dessus du logo Fusion HAT+) est prévu pour relier un ruban de LEDs RGB 5 volts.

Sorties moteurs CC : 4 canaux M1 à M4

La Fusion HAT+ intègre quatre sorties dédiées aux moteurs à courant continu, repérées M1, M2, M3 et M4. Chaque moteur se branche sur un connecteur 2 broches (type JST), placé sur le pourtour de la carte pour garder un câblage propre, sans venir encombrer la zone GPIO ou les connecteurs servos.
Sur cette zone, on identifie clairement les circuits de pilotage : chaque sortie moteur est associée à un circuit intégré TC618CS, placé à proximité du connecteur. Ce sont eux qui assurent la partie “puissance” de la commande des moteurs courant continu.

Le TC618CS (ChipSourceTek) est un driver moteur mono-canal avec pont en H intégré (MOSFETs N + P) destiné aux applis sur batterie : jouets, petits systèmes de mouvement, etc.
Il accepte une alim large 2 à 9,6 V et annonce 2,1 A en continu (jusqu’à 3,5 A en pointe), avec fonctions avant / arrière / stop / freinage. Le fabricant met en avant une faible résistance “on” (~0,26 Ω) et une protection thermique : coupure vers 150 °C typ. avec hystérésis pour éviter la surchauffe.

Le placement autour du haut-parleur est plutôt bien pensé : les connecteurs restent accessibles, la sérigraphie M1…M4 est lisible, et le câblage des moteurs ne vient pas gêner les autres connecteurs.

Pour aller plus loin (et éviter les erreurs de câblage), SunFounder met à disposition une page de documentation très claire qui regroupe le pinout complet de la Fusion HAT+ ainsi que les informations de connexion (GPIO, I²C/SPI/UART, audio I²S, etc.). Elle sert de référence officielle pour vérifier rapidement quelles broches sont utilisées et comment raccorder proprement les différents modules.

Visuels SunFounder : repères, promesses et exemple d’usage

Schéma annoté : tous les connecteurs d’un coup d’œil

Ce visuel est très pratique pour se repérer rapidement : SunFounder y indique clairement les principaux ports (moteurs, servos PWM, ADC, GPIO, I²C/SPI/UART, WS2812…), mais aussi les éléments “système” liés à l’alimentation (port batterie, indicateurs, bouton utilisateur, charge USB-C, etc.). C’est le genre d’image que l’on garde sous la main pendant le câblage, surtout lors des premiers essais. Vous trouverez plus d’informations sur la page « HARDWARE » de la documentation en ligne.

Et le détail des connexions sur cette page.

Montage sur Raspberry Pi : batterie, entrée 5V/3A, sortie 5V/5A et arrêt propre

Ici, le constructeur met en avant la vocation “nomade” de la Fusion HAT+ : un pack batterie rechargeable (2000 mAh), une charge via USB, et surtout la promesse d’une alimentation pensée pour les projets mobiles. Les encadrés rappellent les points clés côté énergie (entrée, sortie et gestion d’extinction propre), ce qui résume bien le positionnement de la carte : une base d’alimentation + pilotage pour monter un robot sans empiler les modules.

Exemple d’application : irrigation assistée par IA

Ce troisième visuel illustre une idée de projet typique “Fusion HAT+” : capteurs (humidité, température, lumière…), commande d’actionneurs (pompe/électrovanne via moteur/driver), et interaction vocale grâce au micro et au haut-parleur. L’angle “IA” est clairement mis en scène : la carte ne fait pas l’IA elle-même, mais elle fournit l’interface matérielle (alimentation, E/S, audio) pour que le Raspberry Pi serve de cerveau et prenne des décisions plus “intelligentes”.

Premiers tests “concrets” de la Fusion HAT+ sur Raspberry Pi 5

La documentation SunFounder est assez généreuse : elle propose une partie “prise en main”, une série d’exemples Python (électronique / moteurs / servos / audio), et même une section dédiée à des projets “GPT/voix” (chat vocal, speech-to-text, etc.). L’idée ici est de dérouler une check-list simple, reproductible, et surtout de valider le matériel étape par étape avant d’empiler de l’IA par-dessus.

Check rapide avant de coder

Batterie insérée : la carte s’appuie sur sa gestion d’alimentation, donc on évite de “tester sans batterie”.
Audio I2S : le micro + l’ampli (HP) utilisent des broches I2S du Raspberry Pi. Tant que l’audio est actif, évitez de réutiliser ces GPIO.
RGB (WS2812) : la prise “RGB” est faite pour un ruban WS2812 (type NeoPixel). Pensez à activer SPI si nécessaire.

1) Vérif EEPROM HAT (la carte “s’annonce” au Pi)

La documentation précise que la Fusion HAT+ utilise les broches ID_SD / ID_SC (GPIO0 / GPIO1) pour son EEPROM HAT. Si tout va bien, le Raspberry Pi doit donc exposer les informations d’identification de la carte dans
/proc/device-tree/hat/.

Lancez ces commandes sur le Raspberry Pi :

ls -l /proc/device-tree/hat || echo "Pas de dossier /proc/device-tree/hat"

for f in product vendor product_id product_ver; do
  if [ -f "/proc/device-tree/hat/$f" ]; then
    echo -n "$f: "
    tr -d '\0' &lt; "/proc/device-tree/hat/$f"
    echo
  fi
done

ls -l /proc/device-tree/hat || echo "Pas de dossier /proc/device-tree/hat"

for f in product vendor product_id product_ver; do

if [ -f "/proc/device-tree/hat/$f" ]; then

echo -n "$f: "

tr -d '\0' < "/proc/device-tree/hat/$f"

echo

done

La carte est vue et correctement identifiée par l’EEPROM HAT.

Installer les dépendances (bibliothèque Fusion HAT+ + support audio)

Avant de lancer les exemples (servo, moteurs, WS2812, micro/HP…), il faut installer la couche logicielle SunFounder qui ajoute la bibliothèque Python fusion_hat et les scripts système associés (notamment pour l’audio I²S). L’installation se fait via un script officiel qui configure automatiquement ce qu’il faut. Suivez scrupuleusement les instructions de la page de démarrage. L’installation est également décrite ici.

Mettre le système à jour (recommandé) :

sudo apt update sudo apt -y full-upgrade

1
2

sudo apt update
sudo apt -y full-upgrade

Charger les exemples et lancer l’installateur Fusion HAT+ :

cd ~/
git clone https://github.com/sunfounder/ai-lab-kit.git --depth 1
curl -sSL https://raw.githubusercontent.com/sunfounder/sunfounder-installer-scripts/main/install-fusion-hat.sh | sudo bash

cd ~/

git clone https://github.com/sunfounder/ai-lab-kit.git --depth 1

curl -sSL https://raw.githubusercontent.com/sunfounder/sunfounder-installer-scripts/main/install-fusion-hat.sh | sudo bash

Pendant l’installation, le script télécharge les composants nécessaires, installe la bibliothèque et pose les fichiers de configuration/scripts au bon endroit.

Redémarrer le Raspberry Pi (important pour prendre en compte les réglages) :

sudo reboot

1

sudo reboot

Vérifier que tout est en place :

# Le script audio doit exister après installation
ls -l /opt/setup_fusion_hat_audio.sh || echo "Script audio absent"

# La bibliothèque Python doit s'importer
python3 -c "import fusion_hat; print('fusion_hat OK')"

# Le script audio doit exister après installation

ls -l /opt/setup_fusion_hat_audio.sh || echo "Script audio absent"

# La bibliothèque Python doit s'importer

python3 -c "import fusion_hat; print('fusion_hat OK')"

Allez c’est tout bon, on peut continuer.

Activer et tester l’audio (haut-parleur + micro)

Activer l’audio Fusion HAT+ (après le reboot) :

sudo /opt/setup_fusion_hat_audio.sh sudo reboot

1
2

sudo /opt/setup_fusion_hat_audio.sh
sudo reboot
Vérifier les périphériques audio détectés (sortie + entrée) :

aplay -l arecord -l

1
2

aplay -l
arecord -l
Tester la sortie (haut-parleur) : générer un son de test :

speaker-test -D plughw:2,0 -t sine -c 2

1

speaker-test -D plughw:2,0 -t sine -c 2

Arrêter avec Ctrl+C.
Enregistrer 5 secondes avec le micro (format WAV 16 kHz, mono) :

arecord -D plughw:2,0 -d 5 -f S16_LE -r 16000 -c 1 mic_test.wav

1

arecord -D plughw:2,0 -d 5 -f S16_LE -r 16000 -c 1 mic_test.wav
Réécouter l’enregistrement :

aplay -D plughw:2,0 mic_test.wav</code></pre>

1

aplay -D plughw:2,0 mic_test.wav</code></pre>

Si tout est correctement configuré, vous devez entendre le son de test sur le haut-parleur, puis retrouver votre voix (ou au minimum un signal) lors de la réécoute du fichier WAV.

Test du servo (exemple SunFounder)

Pour valider rapidement la partie PWM/servos de la Fusion HAT+, la documentation SunFounder propose un script prêt à l’emploi. Branchez votre servo sur le connecteur Servo/PWM canal 0 (servo déclaré en 0 dans l’exemple), puis exécutez le script depuis le dossier des exemples Python du dépôt ai-lab-kit. Le servo doit alors se déplacer selon la séquence prévue par le programme, ce qui confirme que la génération PWM et l’alimentation servo fonctionnent correctement.

cd ~/ai-lab-kit/python/
sudo python3 1.7_Servo.py

1 2	cd ~/ai-lab-kit/python/ sudo python3 1.7_Servo.py

# Exemple : lancer un script servo (après installation des dépendances de la carte)
python3 demo_servo_fusion_hat.py

# Exemple : lancer un script servo (après installation des dépendances de la carte)

python3 demo_servo_fusion_hat.py

from fusion_hat.servo import Servo   # Import the Servo class for controlling servos
from time import sleep               # Import sleep for timing delays

servo = Servo(0)                     # Create a Servo object on channel 0

while True:                          # Loop forever
   # Sweep from -90° to +90° in steps of 10°
   for i in range(-90, 91, 10):
      servo.angle(i)               # Set servo to angle i
      sleep(0.1)                   # Small delay for smooth movement

   # Sweep back from +90° to -90° in steps of -10°
   for i in range(90, -91, -10):
      servo.angle(i)               # Set servo to angle i
      sleep(0.1)                   # Small delay for smooth movement

from fusion_hat.servo import Servo # Import the Servo class for controlling servos

from time import sleep # Import sleep for timing delays

servo = Servo(0) # Create a Servo object on channel 0

while True: # Loop forever

# Sweep from -90° to +90° in steps of 10°

for i in range(-90, 91, 10):

servo.angle(i) # Set servo to angle i

sleep(0.1) # Small delay for smooth movement

# Sweep back from +90° to -90° in steps of -10°

for i in range(90, -91, -10):

servo.angle(i) # Set servo to angle i

sleep(0.1) # Small delay for smooth movement

Commande vocale : allumer/éteindre la LED USER (STT Vosk)

La Fusion HAT+ possède une LED USER (et un bouton) pilotés via la puce I²C de la carte.
Une fois l’audio (micro + haut-parleur) validé, j’ai mis en place un petit test de commande vocale en local : le micro capture la voix, Vosk transcrit la phrase (STT), puis un script Python déclenche l’action en appelant device.set_led(1) (ON) ou device.set_led(0) (OFF).
En pratique, les commandes “light on” et “light off” fonctionnent immédiatement ; j’ai simplement ajouté la variante “light of” (reconnaissance parfois tronquée) pour fiabiliser l’extinction.

cd ~/ai-lab-kit/llm
sudo ./voice_userled_stt.py

1 2	cd ~/ai-lab-kit/llm sudo ./voice_userled_stt.py

Le programme de test voice_userled_stt.py :

#!/usr/bin/env python3
import json
import sounddevice as sd
from vosk import Model, KaldiRecognizer
from fusion_hat import device

def traiter_commande(texte: str) -&gt; None:
    t = texte.strip().lower()
    if "light on" in t:
        device.set_led(1)
        print("ACTION: USER LED ON")
    elif ("light off" in t) or ("light of" in t):
        device.set_led(0)
        print("ACTION: USER LED OFF")
    else:
        print("ACTION: (aucune)")

def main():
    device.set_led(0)
    model = Model(lang="en-us")
    rec = KaldiRecognizer(model, 16000)

    print("Say: 'light on' / 'light off' (Ctrl+C to stop)")

    def callback(indata, frames, time_info, status):
        if status:
            print(status)
        if rec.AcceptWaveform(bytes(indata)):
            res = json.loads(rec.Result())
            texte = res.get("text", "")
            if texte:
                print(f"final: {texte}")
                traiter_commande(texte)

    with sd.RawInputStream(samplerate=16000, blocksize=8000, dtype="int16",
                           channels=1, callback=callback):
        while True:
            sd.sleep(200)

if __name__ == "__main__":
    try:
        main()
    except KeyboardInterrupt:
        pass

#!/usr/bin/env python3

import json

import sounddevice as sd

from vosk import Model, KaldiRecognizer

from fusion_hat import device

def traiter_commande(texte: str) -> None:

t = texte.strip().lower()

if "light on" in t:

device.set_led(1)

print("ACTION: USER LED ON")

elif ("light off" in t) or ("light of" in t):

device.set_led(0)

print("ACTION: USER LED OFF")

else:

print("ACTION: (aucune)")

def main():

device.set_led(0)

model = Model(lang="en-us")

rec = KaldiRecognizer(model, 16000)

print("Say: 'light on' / 'light off' (Ctrl+C to stop)")

def callback(indata, frames, time_info, status):

if status:

print(status)

if rec.AcceptWaveform(bytes(indata)):

res = json.loads(rec.Result())

texte = res.get("text", "")

if texte:

print(f"final: {texte}")

traiter_commande(texte)

with sd.RawInputStream(samplerate=16000, blocksize=8000, dtype="int16",

channels=1, callback=callback):

while True:

sd.sleep(200)

if __name__ == "__main__":

try:

main()

except KeyboardInterrupt:

pass

Une fois Vosk basculé sur un modèle français, la démo devient tout de suite plus naturelle : il suffit de dire « allume » ou « éteint » et la LED USER de la Fusion HAT+ réagit instantanément. On garde le même principe (STT → action), mais cette fois avec des commandes vocales en français, ce qui rend l’exemple bien plus parlant en conditions réelles.

Conclusion

Au final, la Fusion HAT+ tient exactement la promesse que laisse entendre son nom : elle “fusionne” sur une seule carte tout ce qu’on empile d’habitude en couches (alimentation sur batterie, drivers moteurs, PWM servos, entrées analogiques, audio, petite logique temps réel). Et c’est là sa vraie valeur : vous gardez le Raspberry Pi comme cerveau (Python, vision, IA, logique), pendant que la carte s’occupe du terrain : bouger des trucs, alimenter proprement, et rester stable même quand Linux décide de prendre son temps.

Les premiers tests sont franchement rassurants : EEPROM HAT bien reconnue, installation logicielle plutôt fluide, audio I²S opérationnel (HP + micro), servo OK, et la petite démo commande vocale => action (Vosk) montre que l’intégration “interaction” n’est pas un gadget marketing. Ce n’est pas une carte “IA” au sens où elle exécuterait un modèle, mais c’est clairement une carte IA-ready : tout ce qu’il faut pour que l’IA serve à quelque chose dans le monde réel.

Points forts : gestion d’alimentation pensée robot (batterie + charge + arrêt propre), 4 moteurs CC, 12 PWM servos, audio intégré (et exploitable), sérigraphies lisibles et doc plutôt généreuse.
À garder en tête : l’audio mobilise l’I²S du Pi (donc ces GPIO ne sont plus “libres”), le pack 2×18650 fourni (2000 mAh) donne une autonomie correcte pour des démos mais pourra être un peu juste sur un robot gourmand, et les drivers moteurs restent dimensionnés pour de la “petite” motorisation (ce n’est pas un contrôleur pour moteurs de trottinette, hein).

Bref : si vous cherchez une base propre pour monter un robot Raspberry Pi qui ne ressemble pas à un millefeuille de modules (et que vous voulez ajouter de la voix, des capteurs, un peu d’“intelligence”) la Fusion HAT+ est une très bonne candidate. Dans la suite, l’intérêt sera de la mettre face à un vrai projet (robot mobile, mécanisme, pompe/irrigation, assistant vocal “atelier”…), histoire de voir comment elle se comporte sur la durée, avec de la charge sur les moteurs, des servos qui bougent pour de bon, et un Pi qui fait tourner autre chose qu’un simple script de démo.

Et puis soyons honnêtes : une carte qui gère l’alim, fait bouger des moteurs et répond à “allume / éteint”… c’est déjà un début d’obéissance. Reste à lui apprendre à ranger l’atelier. 😄

Sources

SunFounder Fusion HAT+ Expansion Board for Raspberry Pi 5/4/3B+/Zero 2W, Rechargeable Battery, 4 DC Motor Drivers, 12 PWM Servo, ADC, Speaker & Mic, Works with AI LLMs（ChatGPT-4o/Gemini）

https://docs.sunfounder.com/projects/ai-lab-kit/en/latest/_shared/component/cpn_fusion_hat.html

https://docs.sunfounder.com/projects/ai-lab-kit/en/latest/quick_start/run_installer.html

https://docs.sunfounder.com/projects/fusion-hat/en/latest/hardware/hardware.html

https://github.com/sunfounder/fusion-hat

https://docs.sunfounder.com/projects/ai-lab-kit/en/latest/index.html

https://www.programmez.com/actualites/fusion-hat-sunfounder-propose-une-carte-dextension-ultra-complete-38801

https://www.raspberryme.com/sunfounder-fusion-hat-carte-de-controle-moteur-avancee-pour-raspberry-pi-et-llm/

Framboise 314, le Raspberry Pi à la sauce française….

La référence du Raspberry Pi en France – Par l'auteur du livre "Raspberry Pi 4" paru aux Edts. ENI

SunFounder Fusion HAT+ : alimentation 2×18650, moteurs et contrôle “IA-ready” pour Raspberry Pi