Sous-système matériel

Le sous-système matériel de ZeroClaw permet à l’agent de contrôler directement les microcontrôleurs, les SBC et les périphériques. Activez-le avec --features hardware.

Qu’est-ce qui est pris en charge ?

Le sous-système matériel identifie les cartes par leur VID/PID USB. Les cartes du registre canonique :

Transports pris en charge par le sous-système :

Consultez Conception des périphériques pour l’architecture et les guides de configuration propres à chaque carte (Nucleo, Arduino Uno Q, Raspberry Pi, Android) pour le câblage de chacune.

Activation

Au moment de la compilation :

cargo build --release --features hardware

Les fonctionnalités matérielles sont hardware (sous-système principal), peripheral-rpi (GPIO natif du Raspberry Pi) et probe (introspection SWD via probe-rs). Consultez la Référence de configuration pour les champs de configuration propres à chaque carte.

Outils d’exécution

Avec la fonctionnalité hardware, l’agent dispose de ces outils intégrés :

• gpio_read
• gpio_write
• pico_flash
• device_read_code
• device_write_code
• device_exec

Toutes les invocations d’outils passent par la même politique de sécurité que n’importe quel autre outil. Les outils matériels n’accèdent qu’aux chemins de périphériques explicitement listés dans les entrées [[peripherals.boards]] :

Exécution sur un Raspberry Pi

La cible matérielle la plus courante. Une configuration minimale :

curl -fsSL https://raw.githubusercontent.com/zeroclaw-labs/zeroclaw/master/install.sh | sh

# ajoutez-vous aux groupes matériels (déconnectez-vous et reconnectez-vous après)
sudo usermod -aG gpio,spi,i2c $USER

# installer en tant que service utilisateur (garantit l'héritage de l'appartenance au groupe matériel)
zeroclaw service install

L’unité systemd par défaut définit SupplementaryGroups=gpio spi i2c.

Sécurité

Les outils matériels peuvent rendre inutilisables des objets réels et coûteux.

• pico_flash écrit le firmware ; une image défectueuse peut rendre la carte inutilisable. L’outil exige l’approbation d’un opérateur au niveau d’autonomie Supervised quel que soit le niveau d’autonomie ; il n’existe aucun moyen de l’approuver automatiquement.
• Les écritures GPIO qui entrent en conflit avec des pilotes externes (combats de tension) endommagent les broches.

Pour les déploiements en production avec des canaux non fiables exposés, gardez les outils matériels hors des canaux non-CLI via la liste globale autonomy.non_cli_excluded_tools (le schéma ne comporte pas de champ tools_deny par canal). Les outils qui y sont listés sont omis des spécifications d’outils envoyées au modèle sur chaque canal non-CLI (Discord, Telegram, Bluesky, etc.). La CLI locale les voit toujours.

Fiches

Cartes des broches par carte et caractéristiques électriques :

• STM32 Nucleo-F401RE: https://www.st.com/en/evaluation-tools/nucleo-f401re.html
• Arduino Uno Q : https://docs.arduino.cc/hardware/uno-q
• GPIO du Raspberry Pi : https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#gpio
• ESP32 : https://www.espressif.com/sites/default/files/documentation/esp32_datasheet_en.pdf