Come impara a camminare

L’idea in quattro passi

1. Un gemello virtualeMasse, misure e servo del robot descritti in MuJoCo.
2. Tentativi e premiOgni tentativo riceve un punteggio: avanzare dritto senza cadere.
3. Un mondo un po’ diverso ogni voltaCosì la rete non si abitua a un robot “perfetto”.
4. Dal computer al robotI pesi diventano policy.h e si compilano nel firmware.

Il gemello in simulazione

In training/pulcino.xml c’è il modello MuJoCo del robot, con le stesse misure della specifica: torso di 230 g, gambe da 68 mm, piedi 76 × 44 mm, circa 326 g in tutto. Ogni servo MG90S è simulato in modo realistico e un po’ pessimista:

• controllo di posizione, velocità massima 8 rad/s, coppia massima 0,2 N·m;
• banda morta di circa 1° (0,017 rad);
• ritardo di comando tra 10 e 30 ms, diverso a ogni episodio;
• nessun feedback di posizione: i servo economici non dicono dove sono davvero, quindi la rete non vede gli angoli reali, solo le proprie azioni precedenti e l’IMU.

Quest’ultimo punto è la chiave del trasferimento: se in simulazione la rete potesse “sbirciare” informazioni che il robot vero non ha, sul robot fallirebbe.

Augmented Random Search (ARS)

Per l’addestramento usiamo ARS, un metodo di ricerca casuale sorprendentemente efficace per reti piccole, scritto in puro numpy in training/train_ars.py. Funziona così:

1. parti da una rete con pesi quasi nulli;
2. genera N piccole perturbazioni casuali dei pesi, e prova ciascuna in + e in −;
3. guarda quali direzioni hanno dato più premio e sposta i pesi un po’ da quella parte;
4. ripeti per qualche centinaio di iterazioni (su un portatile: da qualche decina di minuti a un paio d’ore).

Il premio incoraggia ad avanzare alla velocità richiesta, restare dritto e vivo, e penalizza movimenti bruschi e consumo. Rispetto a PPO e simili è meno potente, ma non richiede GPU né librerie pesanti ed è facile da capire riga per riga.

Cosa vede e cosa decide la rete

q = POSE_STAND + a · ACTION_SCALE
ACTION_SCALE = {0.3, 0.6, 0.6}

Domain randomization

Il robot vero non sarà mai identico al modello: il PLA pesa un po’ di più, un servo è più lento, il pavimento scivola. Per questo a ogni episodio la simulazione cambia a caso:

• masse delle parti (±15 %);
• attrito dei piedi (da 0,5 a 1,2: dal parquet al tappeto);
• coppia massima (±10 %, come una batteria mezza scarica), guadagno dei servo (±20 %) e ritardo di comando (10–30 ms);
• errori di calibrazione dei servo (±3°);
• rumore, bias e piccolo disallineamento di montaggio dell’IMU;
• spinte casuali sul torso.

L’elenco esatto è nel commento iniziale di training/env.py.

Una rete che cammina in tutti questi mondi un po’ sbagliati ha buone probabilità di camminare anche in quello vero.

Il piano B: la camminata a oscillatori

Prima della rete (e quando policy.h è ancora il segnaposto) Pulcino cammina con un CPG: tre sinusoidi per gamba, descritte in un piccolo gait.json. I parametri si possono cercare automaticamente in simulazione (training/cpg.py) sul server, seguendo i progressi nella Palestra.

{
  "version": 1, "type": "cpg", "freq": 1.6,
  "joints": {
    "hip_roll":    { "amp": 0.18, "phase": 0.0,  "offset": 0.02 },
    "hip_pitch":   { "amp": 0.30, "phase": 1.57, "offset": 0.0 },
    "ankle_pitch": { "amp": 0.20, "phase": 1.57, "offset": 0.0 }
  },
  "feedback": { "roll_gain": 0.0, "pitch_gain": 0.0 }
}

Dal computer al robot

cd training
python3 -m venv venv && source venv/bin/activate
pip install mujoco numpy
python train_ars.py --iters 200 --workers 6     # allena la rete MLP
python train_ars.py --cpg --iters 60 --workers 6 # oppure: cerca un gait.json
# poi esporta i pesi in firmware/pulcino/policy.h (vedi README di training)

Ricompila il firmware, poi dalla web app scegli la modalità policy. Se la rete non è valida il robot torna da solo al CPG. I comandi esatti sono nel README di training.

• repo/training/README.md
• repo/training/pulcino.xml — modello MuJoCo
• repo/training/env.py — ambiente di simulazione
• repo/training/train_ars.py — addestramento ARS