Claude Code per i droni

Claude Code per i droni

Claude Code, l’ambiente di sviluppo agentico di Anthropic, si sta diffondendo anche nell’ingegneria dei sistemi aerei a pilotaggio remoto (UAS/UAV). Questo articolo mostra come utilizzarlo concretamente nello sviluppo di sistemi SLAM, nella regolazione dei flight controller, nella computer vision di bordo e nella scrittura di firmware di volo, per poi affrontare il tema, spesso sottovalutato, dei limiti etici e contrattuali legati agli usi militari dell’intelligenza artificiale e delle alternative rappresentate dai modelli locali.

Indice dei contenuti

1. Cos’è Claude Code e perché interessa a chi sviluppa software per droni

2. Architettura di un progetto drone-oriented con Claude Code

3. Sviluppo di sistemi SLAM con il supporto di Claude Code

4. Regolazione dei flight controller (PX4/ArduPilot) con Claude Code

5. Computer vision e riconoscimento visivo a bordo

6. Esempio pratico: pipeline di offboard control PX4 + ROS 2 assistita da Claude Code

7. Sviluppare firmware di volo e software di visione con Claude Code

8. Droni in ambito militare: la posizione etica e contrattuale di Anthropic

9. Modelli AI locali: sviluppo senza i vincoli di una policy d’uso centralizzata

10. Best practice e errori classici da evitare

11. Conclusioni: la corsa all’aggiornamento professionale

1. Cos’è Claude Code e perché interessa a chi sviluppa software per droni

Claude Code è lo strumento di coding agentico di Anthropic: opera da terminale, da IDE o da app desktop ed esegue un ciclo agentico completo. Legge file del repository, propone modifiche, esegue comandi di build e test, richiama strumenti esterni tramite il Model Context Protocol (MCP) e mantiene coerenza di contesto anche su codebase di grandi dimensioni. Attorno a questo ciclo, Anthropic ha costruito un piccolo insieme di primitive: il file CLAUDE.md per la configurazione di progetto, le skill riutilizzabili per compiti ricorrenti, i subagent per lavori isolati e paralleli, gli hook per far rispettare regole tramite codice e i comandi slash per template ripetibili.

Per chi sviluppa software per droni questa combinazione è particolarmente utile: un progetto UAS reale non è mai un singolo linguaggio o un singolo dominio. Si passa da firmware C/C++ in tempo reale, a nodi ROS 2 in Python o C++, a script di analisi telemetria, a pipeline di visione basate su modelli di deep learning, fino ai file di parametri del flight controller. Claude Code può muoversi trasversalmente su tutti questi livelli nello stesso flusso di lavoro, mantenendo coerenza tra le convenzioni del progetto, ad esempio il sistema di riferimento NED usato internamente da PX4 rispetto a quello ENU nativo di ROS 2, un dettaglio che nella pratica genera bug sottili se gestito a mano da team diversi.

2. Architettura di un progetto drone-oriented con Claude Code

Prima di chiedere a Claude Code di scrivere codice, conviene descrivergli il progetto. Il file CLAUDE.md, posizionato nella root del repository, viene letto automaticamente a ogni sessione e funziona come una sorta di briefing tecnico permanente: convenzioni di frame, versione del firmware target, distribuzione ROS 2 in uso, comandi di build e di test, vincoli di sicurezza da non violare mai (ad esempio limiti di velocità massima in simulazione). Un repository tipico per un progetto drone-oriented è organizzato con una cartella firmware (fork PX4 o ArduPilot con moduli custom), una cartella ros2_ws con i pacchetti per SLAM, visione e mission control, e una cartella tools con script di analisi log e tuning.

# CLAUDE.md — esempio minimale per un progetto drone
## Contesto
- Flight controller: PX4 v1.15, SITL Gazebo per i test
- Frame convention firmware: NED. Frame convention ROS 2: ENU
- ROS 2 distro: Jazzy, build con colcon
- Companion computer: Jetson Orin NX, inferenza con TensorRT
 
## Regole vincolanti
- Non modificare mai i parametri di failsafe (COM_*, NAV_*) senza
  segnalarlo esplicitamente nel riepilogo della modifica
- Ogni modifica al controllo di volo va prima testata in SITL
- I limiti di velocità in simulazione non superano 5 m/s
 
## Comandi utili
- Build ROS 2: colcon build --symlink-install
- Avvio SITL: make px4_sitl gz_x500

3. Sviluppo di sistemi SLAM con il supporto di Claude Code

Il SLAM (Simultaneous Localization and Mapping) risolve un problema che si può descrivere con un’analogia semplice: è come esplorare una casa buia con una torcia, disegnando la mappa delle stanze mentre, allo stesso tempo, si tiene traccia di dove ci si trova rispetto a quella mappa. Un drone che vola in ambienti senza GPS (indoor, sotto ponti, in gallerie) deve risolvere questo problema in tempo reale, fondendo dati di camere, IMU e, spesso, lidar.

Claude Code non sostituisce le librerie SLAM consolidate (ORB-SLAM3, VINS-Fusion, RTAB-Map), ma accelera in modo concreto il lavoro di integrazione: genera lo scheletro del nodo ROS 2 che fa da ponte tra l’output del sistema di visual-inertial odometry (VIO) e il topic che il flight controller si aspetta di ricevere, scrive i launch file, individua incongruenze nell’albero delle trasformazioni (TF) e converte le convenzioni di frame quando la libreria di terze parti lavora in ENU e PX4 richiede NED. È un lavoro meccanico ma soggetto a errori sottili, ed è proprio lì che un agente capace di leggere l’intero grafo dei nodi dà un vantaggio misurabile.

# Prompt tipico da dare a Claude Code
"Crea un nodo ROS 2 in Python che sottoscrive /vio/odometry
(frame ENU, nav_msgs/Odometry) e pubblica su
/fmu/in/vehicle_visual_odometry nel formato atteso da PX4,
convertendo posizione e orientamento da ENU a NED."
 
# scheletro generato (estratto)
class VioToPx4Bridge(Node):
    def __init__(self):
        super().__init__('vio_to_px4_bridge')
        self.sub = self.create_subscription(
            Odometry, '/vio/odometry', self.on_odom, 10)
        self.pub = self.create_publisher(
            VehicleOdometry, '/fmu/in/vehicle_visual_odometry', 10)
 
    def on_odom(self, msg):
        ned_pose = enu_to_ned(msg.pose.pose)  # da frame_transforms
        out = VehicleOdometry()
        out.position = ned_pose.position
        out.q = ned_pose.orientation
        self.pub.publish(out)

4. Regolazione dei flight controller (PX4/ArduPilot) con Claude Code

La regolazione di un flight controller consiste nel trovare i guadagni dei loop di controllo (posizione, velocità, assetto) che rendono il drone stabile senza oscillazioni né risposte troppo lente. È un processo iterativo: si modifica un parametro, si vola (o si simula), si analizza il log, si corregge di nuovo. Claude Code è utile soprattutto nella parte di automazione e analisi: può scrivere script basati su pymavlink o MAVSDK che impostano un parametro, lanciano un volo automatico in SITL e salvano il log ulog per il confronto, oppure può analizzare un log esistente ed evidenziare pattern di oscillazione nella risposta in velocità.

# Esempio: impostare un guadagno PID via pymavlink
from pymavlink import mavutil
 
master = mavutil.mavlink_connection('udp:127.0.0.1:14540')
master.wait_heartbeat()
 
master.mav.param_set_send(
    master.target_system, master.target_component,
    b'MPC_XY_P', 0.95, mavutil.mavlink.MAV_PARAM_TYPE_REAL32)

Un punto da tenere sempre presente: qualunque parametro proposto da Claude Code va validato prima in SITL e poi, se necessario, in hardware-in-the-loop (HITL), mai direttamente in volo reale. I flight controller espongono parametri di sicurezza (failsafe, geofence, limiti di velocità) che non devono mai essere modificati automaticamente senza revisione umana esplicita: è una delle regole da inserire, come visto sopra, direttamente nel file CLAUDE.md.

5. Computer vision e riconoscimento visivo a bordo

La computer vision a bordo copre casi d’uso molto diversi tra loro: evitamento ostacoli, riconoscimento di marker per l’atterraggio di precisione, monitoraggio di colture in agricoltura, ispezione di infrastrutture, individuazione di persone in scenari di ricerca e soccorso. L’architettura tipica prevede un companion computer (ad esempio una scheda Jetson) che riceve il flusso video, esegue un modello di object detection (spesso una variante della famiglia YOLO) e invia i risultati sia al modulo di missione sia, se serve, direttamente al nodo di offboard control per reagire in tempo reale.

In questo ambito Claude Code aiuta soprattutto su tre fronti: scrittura della pipeline di inferenza e della sua integrazione con ROS 2, ottimizzazione del modello per l’hardware embedded (conversione e quantizzazione con TensorRT, gestione della memoria GPU limitata), e scrittura dei test che verificano il comportamento del sistema quando la detection è assente o rumorosa, condizione tutt’altro che rara in volo reale, dove vibrazioni e illuminazione variabile degradano facilmente la qualità dell’inferenza.

# Estratto di loop di inferenza su companion computer (pseudocodice)
for frame in camera.stream():
    detections = model.infer(frame)          # TensorRT engine
    obstacle = filter_by_confidence(detections, thr=0.6)
    if obstacle and obstacle.distance_m < SAFE_DISTANCE:
        mission_node.publish_stop_command()
    else:
        mission_node.publish_detections(detections)

6. Esempio pratico: pipeline di offboard control PX4 + ROS 2 assistita da Claude Code

Scenario: l’azienda fittizia SkyMapper Robotics sviluppa un drone per l’ispezione di tralicci elettrici e vuole aggiungere una manovra automatica di arresto quando la computer vision rileva un ostacolo lungo la traiettoria. Il team conosce PX4 e ROS 2 ma non ha mai usato Claude Code in modo strutturato. Ecco i passaggi tipici.

• Passo 1: Si descrive lo scenario a Claude Code in linguaggio naturale, indicando i topic ROS 2 già esistenti (/detections, /fmu/out/vehicle_local_position) e il comportamento atteso.
• Passo 2: Claude Code genera lo scheletro del nodo di offboard control, rispettando il requisito PX4 di pubblicare OffboardControlMode e TrajectorySetpoint in modo continuativo prima dell’armo.
• Passo 3: Il team chiede a Claude Code di aggiungere la logica di arresto in sicurezza quando arriva una detection sotto la soglia di distanza minima.
• Passo 4: Si esegue il test in simulazione Gazebo (make px4_sitl gz_x500) prima di qualunque volo reale, confrontando il log di missione con quello atteso.

// Estratto C++ semplificato del nodo di offboard control
void OffboardControlNode::on_timer() {
  publish_offboard_control_mode();  // richiesto da PX4 a ogni ciclo
 
  if (last_obstacle_distance_m_ < SAFE_DISTANCE_M) {
    publish_hold_setpoint(current_position_);  // arresto in sicurezza
  } else {
    publish_trajectory_setpoint(mission_waypoint_);
  }
}

7. Sviluppare firmware di volo e software di visione con Claude Code

Sul lato firmware, lavorare con Claude Code significa soprattutto usarlo come supporto alla scrittura e alla revisione di moduli C/C++ per PX4 o librerie ArduPilot: comprendere una codebase esistente prima di modificarla, generare la toolchain di cross-compilazione per target ARM, scrivere test unitari da eseguire nell’harness SITL, ed eseguire analisi statica (ad esempio con cppcheck) sui loop di controllo, dove un errore banale può tradursi in un comportamento pericoloso in volo. È buona norma chiedere a Claude Code di spiegare, prima di modificarlo, il comportamento del modulo esistente: la comprensione precede sempre la modifica, specialmente su codice che gira in un loop di controllo a frequenza fissa.

Sul lato software di visione a bordo, il lavoro tipico riguarda la scrittura degli script di conversione e ottimizzazione dei modelli (da PyTorch a ONNX a TensorRT), la gestione dei vincoli termici e di consumo energetico del companion computer, e l’integrazione con il resto dello stack tramite MCP quando serve, ad esempio, interrogare un sistema esterno di gestione missione o un database di log di volo. In entrambi i casi, firmware e visione, vale la stessa regola: Claude Code produce una prima versione solida e ben commentata, ma la validazione in simulazione e poi in hardware-in-the-loop resta un passaggio che nessun agente automatizza.

8. Droni in ambito militare: la posizione etica e contrattuale di Anthropic

Il tema dell’uso militare dei droni è oggi al centro di un confronto diretto tra Anthropic e il Dipartimento della Difesa statunitense, ed è utile per un team di sviluppo capire dove passa il confine. La Usage Policy di Anthropic vieta, in generale, di utilizzare i propri modelli per progettare, sviluppare o acquisire armi, e questo divieto resta in vigore anche nei contratti con enti governativi: la pagina ufficiale del centro assistenza chiarisce che, pur potendo Anthropic concedere eccezioni mirate ad alcune agenzie (ad esempio per analisi di intelligence estera), i divieti relativi a disinformazione, progettazione o uso di armi, censura, sorveglianza interna e operazioni informatiche malevole restano comunque validi.

Questo principio è stato messo alla prova concretamente all’inizio del 2026. Il Pentagono aveva un contratto con Anthropic, firmato a luglio 2025, che vincolava l’uso di Claude su reti classificate al rispetto della Usage Policy, con due clausole esplicite: divieto di sorveglianza di massa sui cittadini americani e divieto di impiego in sistemi d’arma completamente autonomi in grado di selezionare e colpire bersagli senza intervento umano. A febbraio 2026 il Dipartimento della Difesa ha chiesto di rimuovere queste due clausole per ottenere un uso illimitato “per qualsiasi scopo legale”; Anthropic ha rifiutato, e l’amministrazione ha reagito ordinando alle agenzie federali di cessare l’uso della tecnologia Anthropic e classificando l’azienda come rischio per la catena di approvvigionamento, una designazione storicamente riservata a fornitori considerati ostili. La disputa è oggi anche oggetto di un contenzioso legale.

Per chi sviluppa software per droni, la conseguenza pratica è chiara: Claude e Claude Code possono legittimamente supportare applicazioni difensive, di ricognizione, logistica, ispezione o mappatura, mantenendo un essere umano nel loop decisionale, ma non possono essere utilizzati per progettare o migliorare sistemi d’arma pienamente autonomi, indipendentemente dal fatto che il caso d’uso venga presentato come civile, duale o militare. Si tratta di un tema politicamente controverso, con posizioni legittime su entrambi i fronti, chi sostiene che un fornitore privato non debba dettare l’uso operativo di una tecnologia già acquisita dal governo, e chi ritiene che alcune soglie etiche debbano restare non negoziabili, ed è opportuno che ogni team ne sia consapevole prima di avviare un progetto in questo ambito.

9. Modelli AI locali: sviluppo senza i vincoli di una policy d’uso centralizzata

Accanto ai modelli offerti in cloud da fornitori come Anthropic, nel 2026 l’ecosistema dei modelli open-weight eseguibili in locale (Llama, Qwen, Gemma, DeepSeek, gpt-oss) ha raggiunto una qualità sufficiente per molti compiti di sviluppo, ed è distribuito con licenze permissive come Apache 2.0. Strumenti come Ollama, llama.cpp o vLLM permettono di scaricare i pesi del modello ed eseguire l’inferenza interamente sull’hardware del team, senza che alcuna richiesta lasci la rete locale. In questo scenario non esiste un fornitore terzo che applichi in tempo reale una propria Usage Policy alle singole richieste, perché l’inferenza non transita su un servizio cloud gestito centralmente.

È importante essere precisi su cosa cambia e cosa no. L’assenza di un enforcement automatico da parte di un fornitore cloud non elimina gli obblighi legali e normativi che si applicano comunque a chi sviluppa tecnologia a duplice uso: normative sul controllo delle esportazioni, autorizzazioni richieste per applicazioni a fini di difesa, e il diritto internazionale umanitario restano validi indipendentemente dallo strumento usato per scrivere il codice, cloud o locale che sia. La responsabilità legale ed etica di ciò che viene costruito resta sempre in capo a chi lo sviluppa e a chi lo dispiega, non allo strumento di sviluppo utilizzato.

10. Best practice e errori classici da evitare

Alcune pratiche che riducono in modo concreto il rischio quando si usa Claude Code su un progetto drone:

• Mantenere sempre una revisione umana esplicita su qualunque modifica al loop di controllo di volo o ai parametri di failsafe, geofence e limiti di velocità.
• Validare ogni modifica prima in SITL, poi in hardware-in-the-loop, e solo alla fine in volo reale, indipendentemente da quanto il codice generato sembri corretto.
• Codificare le convenzioni di progetto (frame NED/ENU, versione firmware, distribuzione ROS 2) nel file CLAUDE.md, così da ridurre errori di conversione ricorrenti.
• Tenere sotto controllo di versione anche i file di parametri del flight controller, non solo il codice sorgente.
• Rivedere sempre i log di volo (ulog) dopo ogni test, anche quando il comportamento osservato sembra corretto a occhio.
• Fissare le versioni di firmware, distribuzione ROS 2 e librerie di terze parti nel repository, perché un agente può generare codice coerente con una versione diversa da quella realmente in uso.

Tra gli errori più comuni osservati nei team che iniziano a usare Claude Code su questo tipo di progetti:

• Incollare codice generato per un loop real-time senza verificare la presenza di chiamate bloccanti o condizioni di race tra thread.
• Non controllare l’unità di misura dei parametri (ad esempio confondere m/s con cm/s in un campo di velocità).
• Disattivare temporaneamente failsafe o geofence per testare una nuova funzione, dimenticando di riattivarli prima del volo successivo.
• Passare direttamente all’hardware saltando la fase di simulazione, anche per modifiche apparentemente minori.

11. Conclusioni: la corsa all’aggiornamento professionale

L’intelligenza artificiale applicata allo sviluppo software, con Claude Code come esempio più maturo di questa generazione di strumenti, sta cambiando velocemente il modo di lavorare in ogni settore industriale, e il settore dei droni non fa eccezione: dallo scaffolding di sistemi SLAM alla regolazione dei flight controller, dalla computer vision al firmware di volo, i tempi di sviluppo si stanno comprimendo in modo che solo pochi anni fa sarebbe sembrato irrealistico. Le aziende e gli sviluppatori che non investono ora nell’aggiornamento delle proprie competenze rischiano concretamente di essere superati da chi lo fa, con una velocità di cambiamento del mercato che non lascia molto margine per rincorrere dopo.

Per preparare il proprio team a queste sfide, Innovaformazione propone il Corso Claude Code per sviluppatori, attivabile su richiesta per le aziende con calendario da concordare, in modalità online in aula virtuale live. Le aziende aderenti a Fondimpresa possono inoltre essere seguite nell’intero iter di gestione del piano formativo finanziato.

Contatti

Per informazioni e un preventivo personalizzato: info@innovaformazione.net — tel. 347 1012275 — Dario Carrassi.

(fonte) (fonte) (fonte) (fonte)