Competenza · Sistemi per robot

Software per robot: lo strato che decide il movimento, il modulo di visione e quello di udito. Oggi abbiamo verifica offline e simulazione — non abbiamo nulla che comandi un motore reale.

Scriviamo cinematica, verifica della traiettoria e simulazione fisica riproducibile, con gate che bloccano quando manca la prova. Per la visione abbiamo un prototipo su camera fissa, non su robot. Per l’audio su robot non abbiamo nulla costruito, e la pagina lo dice invece di prendere in prestito prove dalla telefonia. Non lavoriamo con ROS.

Parliamo di un progetto

Offerta, con condizioniHo eseguito oggi tutto ciò che si può eseguire. Lo strato di controllo esiste ed è serio, ma è offline: un modulo proprio di cinematica per un braccio a sei assi, che ha risolto 8.400 punti di traiettoria su 8.400, e un validatore di fisica su MuJoCo 3.10.0 con 34 test superati, più 14 test sulla parte di visualizzazione. Entrambi dichiarano nel proprio sorgente che non hanno trasporto verso l’hardware e non possono comandare un robot reale. In vista abbiamo un prototipo proprio — rilevamento e tracking di persone su telecamera IP fissa — con un solo commit e con la directory dei test vuota. Per l’audio sul robot abbiamo zero: tutto ciò che è su disco è voce da call center o libreria terza di telefonia, e l’unico lavoro acustico proprio si è concluso con un risultato negativo, scritto nell’applicazione. ROS: zero installato, zero scritto. La regola richiede almeno due implementazioni proprie per dire «abbiamo fatto»; sul controllo le ho, ma nessuna tocca l’hardware, e gli altri due strati del servizio sono sotto soglia. Quindi: offerta con condizioni, con i confini tracciati.

Il software di un robot ha tre strati che si rompono in modo diverso: ciò che vede e ascolta, ciò che decide, e ciò che invia ai motori. Sui primi due abbiamo lavori propri con test che vengono eseguiti. Sul terzo — il ponte verso l’hardware — non abbiamo nulla, e questo è il confine del servizio, non un dettaglio di implementazione. Due dei nostri codici lo dicono nel proprio header, in inglese, proprio per non poter essere letti male: il modulo di cinematica non ha trasporto verso l’hardware e non può comandare un robot reale.

Ciò che esiste sul lato del movimento è una verifica prima del movimento. Un modulo proprietario calcola cinematica diretta, jacobiano e cinematica inversa per un braccio a sei assi, con un margine imposto rispetto ai limiti di ciascun asse, ed è stato usato per verificare un’intera traiettoria: 8.400 punti richiesti, 8.400 risolti, con la velocità massima per asse rimasta sotto l’8% del limite di catalogo. Separatamente, un validatore fisico gira su MuJoCo 3.10.0 su processore, con passo di calcolo di un millisecondo, in sei scenari, ciascuno due volte, con lo stesso seme — e le due esecuzioni danno impronte identiche. Il determinismo non è un’affermazione, è un confronto di checksum.

Ciò che esiste sul lato della visione è meno, ed è onesto dirne quanto. Un prototipo proprio rileva e segue persone su flussi di telecamera IP, con un piccolo rilevatore della famiglia YOLO, un tracker multi-oggetto, stima della postura per cinque stati e controllo pan-tilt-zoom della telecamera. Ha un solo commit e la directory dei test vuota. E la differenza tra questo e la visione di un robot è reale, non formale: la telecamera su un robot si muove con esso, la scena è vicina, l’esposizione cambia a ogni passo, e il budget di latenza è diverso, perché l’immagine deve arrivare a una decisione di movimento, non a uno schermo. Non abbiamo telecamera di profondità, non abbiamo calibrazione della telecamera, non abbiamo odometria visiva.

Sul lato audio per robot non abbiamo nulla di costruito, e non prenderemo in prestito prove da altrove. Abbiamo lavori reali di voce per telefonia e per assistenti conversazionali, ma un microfono su un robot ha altri problemi: il rumore proprio della macchina, ventole e servomotori che partono esattamente quando il robot si muove, la direzione da cui arriva la voce, l’eco nella stanza e la distanza variabile. L’unico lavoro acustico proprio che abbiamo si è concluso con un risultato negativo, scritto nell’applicazione, e lo pubblichiamo come tale — perché un risultato negativo misurato è più utile di una promessa.

Cosa comprende

Il lavoro, per componenti

Verifichiamo la cinematica prima di muovere qualcosa

Cinematica diretta, Jacobiano analitico costruito da prodotti vettoriali, cinematica inversa numerica con quattro posizioni di avvio e una riserva imposta di 10° rispetto al limite di ciascun asse, con convergenza a 0,05 mm sulla posizione. Con essa abbiamo verificato una disposizione in 1.331 posizioni di griglia e un percorso completo di 8.400 punti, tutti risolti. I risultati: velocità massima per asse al 7,86% del limite di catalogo e margine minimo rispetto ai limiti di 19,9°. Il rapporto scrive da sé la propria natura: screening discreto offline, senza uscita verso l’hardware.

Eseguiamo la fisica separatamente dall’immagine, e in modo riproducibile

Il validatore di fisica è un programma separato dalla parte visiva, su MuJoCo 3.10.0, su processore, con passo di un millisecondo e campionamento a 20 millisecondi. Sei scenari, ciascuno eseguito due volte con la stessa semenza, con impronte identiche tra le esecuzioni. Le tolleranze sono dichiarate nel codice, non sottintese: deriva energetica sotto l’1% relativo, penetrazione nel suolo sotto 3 cm, violazione del limite articolare sotto 0,03 radianti. Ciò che si misura in caduta libera è l’accelerazione del centro di massa, confrontata con la gravità configurata — 9,80665, 1,62 e 3,72076 metri al secondo quadrato.

Mettiamo un gate che blocca, non uno che etichetta soltanto

Il registro delle azioni chiede a ogni movimento di dichiarare la propria provenienza, e tutte le 15 azioni registrate sono marcate cinematiche, zero validate — perché nessuno dei controller in esse è guidato da un simulatore di corpi rigidi con limiti degli attuatori e validazione dei contatti. Sopra di esso, un gate di rilascio legge il file di prova e cade se una costante chiave non è calibrata sull’hardware. Oggi cade: una sola costante di arresto articolare, di 5 millisecondi, è dichiarata nel codice come parametro provvisorio, non valore misurato — e basta questo perché la verifica completa vada in errore. È una regola scritta da noi contro di noi.

Leggiamo la descrizione del robot con un parser proprio, e diciamo ciò che lascia fuori

Per la visualizzazione e l’ispezione dei modelli abbiamo scritto un nostro analizzatore del formato MJCF: corpi, articolazioni di tipo cerniera, libera, scorrevole e sferica, geometrie, materiali e caricamento delle mesh, con cache delle geometrie. Lascia intenzionalmente fuori le geometrie di collisione, perché è un analizzatore visivo, non uno di contatto — scritto nel codice, non scoperto in seguito. I modelli utilizzati sono quelli ufficiali, con 29 gradi di libertà per l’umanoide e 12 per il quadrupede.

Non confondiamo i valori comandati con quelli misurati

Gli angoli che compaiono sullo schermo sono quelli comandati dal controller, pubblicati in un’unica direzione verso l’interfaccia. Non contengono rumore dell’encoder, stato misurato, coppia, velocità o temperatura — scritto esplicitamente nell’audit tecnico del progetto. Questa distinzione sembra piccola finché qualcuno prende un grafico bello per telemetria di robot; per questo lo scriviamo nel codice, nell’audit e qui.

Visione: rilevamento e tracciamento di persone, con telecamera fissa

Un prototipo proprio che prende flussi di telecamera IP, rileva persone con un piccolo modello della famiglia YOLO, le segue tra i frame con un tracker multi-oggetto a una soglia di confidenza di 0,5, stima la postura in cinque stati — sconosciuto, seduto, in piedi, camminando, piegato — e può ruotare la telecamera tramite il protocollo standard di controllo. Funziona forzatamente su processore, a causa di un’incompatibilità annotata nel codice. Il suo stato reale: un solo commit e la directory dei test vuota. È un prototipo, non un modulo di produzione, e non è mai stato su un robot.

Audio sul robot: diciamo ciò che manca, invece di prendere in prestito dalla telefonia

Non abbiamo rilevatore di parola di attivazione, non abbiamo rilevatore di voce eseguito localmente, non abbiamo beamforming, non abbiamo stima della direzione e non abbiamo codice di cancellazione dell’eco scritto da noi. Ciò che abbiamo nell’area voce è per le chiamate telefoniche e per assistenti conversazionali: l’interruzione dell’oratore avviene sia tramite il rilevatore del servizio del fornitore, sia premendo un tasto nel menu telefonico, e la cancellazione dell’eco arriva dalle librerie del browser o da uno stack terzo di telefonia. Sono cose reali, ma risolvono un altro problema rispetto a un microfono montato su una macchina che si muove e fa rumore da sola.

ROS: non lo abbiamo, e non facciamo finta di averlo

Non è installato su nessuna nostra macchina e non abbiamo mai scritto un nodo, un file di lancio o un pacchetto nostro. L’unico pacchetto con sistema di costruzione specifico ROS sul disco è la descrizione pubblica di un robot industriale, scaricata come file di modello e usata esattamente così, non compilata. Se il tuo progetto presuppone ROS 2 come dato di fatto, è un’informazione che devi avere prima della prima riunione, non dopo.

Cosa accetteremmo e cosa no

Accetteremmo: verifica cinematica e di traiettoria prima di un acquisto, simulazione con tolleranze dichiarate, un modulo di percezione misurato sui tuoi dati, e un ponte verso l’hardware realizzato insieme all’integratore che risponde della sicurezza. Non accetteremmo: scrivere da soli lo strato che arresta un robot in caso di emergenza, promettere un modulo audio sul robot senza una misurazione preventiva del rumore proprio della tua macchina, e neppure dire che la nostra esperienza di voce al telefono copre l’udito di un robot.

Come si presenta

Il percorso, passo dopo passo.

Definiamo il compito e i limiti fisici, poi verifichiamo se ci stanno

Che cosa deve raggiungere il robot, in quale volume, con quale velocità e quale carico. Poi la verifica: copertura del volume, margine rispetto ai limiti di ciascun asse, velocità e accelerazione sul percorso, collisioni sulla geometria reale come screening. Consegniamo il rapporto con i suoi limiti scritti. Questa fase ha un buon rapporto tra costo e danno evitato, perché si fa prima di un acquisto.

Simuliamo con tolleranze dichiarate e con determinismo verificato

Scenari, seme fisso, esecuzioni ripetute, confronto delle impronte, tolleranze scritte nel codice. Consegniamo anche l’elenco delle cose che la simulazione NON dimostra — da noi, per esempio, un validatore che conferma la caduta libera e il mantenimento della posizione su un piano di test non conferma il cammino, il contatto complesso o la dinamica dell’attuatore, e lo scrive da sé.

Costruiamo la percezione sui tuoi dati, non su un set pubblico

Un rilevatore che funziona su immagini da internet non dice nulla sul tuo capannone. La fase significa acquisizione dall’ambiente reale, un set di valutazione proprio, una misura di riferimento e solo poi la scelta del modello e del punto in cui gira. Consegniamo i numeri di riferimento e il metodo con cui puoi riprodurli, anche quando sono deboli.

Il ponte verso l’hardware — la fase che non abbiamo mai fatto

La scriviamo per ultima e la scriviamo con condizioni, perché è l’unica della lista in cui non abbiamo esperienza propria. Si fa insieme all’integratore o al produttore del robot, e le funzioni di arresto d’emergenza, di limitazione e di sicurezza restano sotto la responsabilità di chi risponde della macchina. Quello che possiamo portare noi fino lì è lo strato decisionale, verificato, con la sua interfaccia documentata.

La catena di un robot, da sinistra a destra, con lo stato reale di ogni anello. Visione: prototipo su telecamera fissa, un solo commit, senza test. Udito: vuoto — nulla di costruito per un microfono su una macchina che si muove. Decisione e cinematica: verificato, con 8.400 punti risolti e con un gate che blocca quando una costante non è calibrata. L'ultima freccia, quella verso i motori, è interrotta: nessun nostro codice ha trasporto verso l'hardware. Il disegno è fatto per mostrare dove si ferma il servizio, non per sembrare completo.

I dati

Cosa tocchiamo, dove risiedono e quanto rimangono

Le domande che pone chiunque abbia un responsabile della protezione dei dati — poste qui prima che le ponga lui.

La camera di un robot riprende persone, e questo cambia tutto: Un modulo di visione che rileva e traccia persone produce dati personali nel senso proprio della parola, anche se nessuno è identificato per nome. Le domande si pongono prima della prima riga di codice: si conserva l’immagine o solo il risultato, dove si elabora, chi ha accesso alle registrazioni, per quanto tempo si tengono, cosa viene mostrato a chi viene ripreso. Il nostro prototipo è stato costruito come esperimento tecnico, non come sistema messo in funzione, e non lo proponiamo come tale.
Sul dispositivo o sul server — una decisione di latenza, non di preferenza: Se l’immagine deve arrivare a una decisione di movimento, il percorso fino a un server e ritorno entra direttamente nel budget di reazione. Se il risultato è solo visualizzato o registrato, il server è accettabile. La decisione si prende in base al budget di latenza misurato sul tuo caso, e si scrive. Il nostro prototipo gira forzatamente sul processore, il che è un vero limite di velocità, annotato nel codice.
Le simulazioni si conservano con seme e impronta: Un risultato di simulazione senza il seed del generatore e senza la checksum degli input non è una prova, è una storia. I nostri rapporti di fisica riportano il seed, il numero di run per scenario, la versione del motore e lo stato di determinismo; i rapporti di cinematica riportano l’impronta dei file di input. In questo modo si può verificare, mesi dopo, se una cifra citata è ancora valida.
Audio significa registrare una stanza: Un microfono su un robot sente tutto ciò che accade intorno, non solo il comando che gli viene dato. La regola che applichiamo sarebbe che la registrazione continua non esista in modo implicito, ma solo la finestra necessaria alla decisione, e che ciò che si conserva per il miglioramento sia una scelta esplicita, con termine. Non abbiamo ancora costruito un tale sistema, quindi è una posizione dichiarata, non una pratica dimostrata.
I modelli e le descrizioni dei robot hanno le loro licenze: I modelli di robot che usiamo in simulazione provengono da collezioni pubbliche, sotto licenze permissive, e le descrizioni dei robot industriali sono file pubblici dei produttori. Non sono nostri e non li rivendichiamo; in un vostro progetto, la licenza di ogni fonte esterna viene verificata prima di entrare nel deliverable.

Un caso

Una misurazione acustica interna che si è conclusa con «no», e perché la pubblichiamo

La situazione

In un’applicazione propria per macOS volevamo capire se l’altoparlante e il microfono di un dispositivo di consumo potessero essere usati come un semplice sonar — un segnale emesso, il suo eco misurato, una distanza dedotta. La domanda è esattamente quella che appare anche in un robot: quanto si può sapere dello spazio circostante usando hardware audio che si ha già, senza sensori aggiuntivi.

Cosa abbiamo costruito

Abbiamo costruito l’intera catena, non uno schizzo: un segnale sweep di 12 millisecondi che sale da 2 a 8 kilohertz, finestrato, emesso a bassa ampiezza; correlazione incrociata tra il segnale emesso e quello registrato; rilevazione dell’arrivo diretto con una finestra di guardia di 1,5 millisecondi, affinché i lobi laterali dell’autocorrelazione non vengano scambiati per eco; ricerca dell’eco in una finestra fino a 60 millisecondi, con soglie separate di correlazione e di guadagno relativo; velocità del suono corretta con la temperatura dell’aria. Quasi 800 righe di Swift, con rilevazione del percorso audio — se trasmettitore e ricevitore sono su dispositivi diversi, la geometria è bistatica e un singolo tempo di ritardo definisce un’ellisse, non un punto.

Cosa è emerso

La conclusione è scritta nell’app, nella schermata che dice cosa può e cosa non può misurare: sull’altoparlante e sul microfono dello stesso computer si possono rilevare cambiamenti grossolani delle riflessioni dopo la calibrazione, perché la latenza è relativamente stabile. Con cuffie wireless però, la cancellazione attiva del rumore, la beamforming, il codec e la latenza variabile distruggono la misurazione metrica precisa — quindi possono essere usate per l’orientamento della testa, non come sonar preciso. L’ho scritto nel prodotto, non in una nota interna.

Cosa non dice il caso

Il risultato riguarda hardware di consumo su un collegamento wireless, non un robot con microfoni montati e cablati. Ciò che si trasferisce non è la conclusione, ma il metodo: si misura il canale prima di promettere la funzione. Per un robot, la stessa indagine partirebbe dal rumore proprio della macchina in movimento — e solo il risultato di quella misurazione direbbe cosa è possibile.

Domande

Cosa ci chiedono le persone prima di chiamare

Avete mai messo il vostro software su un robot fisico?

No. Nessun nostro codice ha mai comandato un motore reale, e due delle nostre codebase lo dichiarano persino nell’header del file, affinché non possano essere lette in modo errato. Ciò che abbiamo eseguito è simulazione e verifica offline. Se questo è un problema per il Suo progetto, è meglio saperlo dalla prima frase che scoprirlo alla terza riunione.

Allora cosa avete, concretamente?

Tre cose, tutte eseguibili davanti a Lei. Un modulo di cinematica per un braccio a sei assi, che ha verificato un percorso di 8.400 punti senza alcun fallimento, con margine minimo di 19,9° rispetto ai limiti degli assi. Un validatore di fisica su MuJoCo 3.10.0, con 34 test superati e determinismo dimostrato tramite fingerprint identici su esecuzioni ripetute. E un dimostratore nel browser con 14 test, il cui gate di qualificazione oggi cade deliberatamente. Più un prototipo di visione, di cui diciamo apertamente che ha un solo commit e nessun test.

Lavorate con ROS?

No. Non è installato da noi, non abbiamo scritto alcun nodo, alcun file di lancio e alcun pacchetto. L’unico pacchetto di tipo ROS sui nostri dischi è la descrizione pubblica di un robot industriale, scaricata come file di modello per i calcoli di cinematica — usata come dati, non costruita. Se il vostro team lavora già in ROS 2 e questa è una richiesta, noi partiamo da zero lì, e va messo in conto.

Potete fare il modulo di visione per il nostro robot?

Con una fase di misurazione prima, non sulla base del prototipo che abbiamo. Ciò che si trasferisce da esso è il modo di lavorare — detector, tracker tra i frame, soglia di confidenza, dove gira il calcolo. Ciò che non si trasferisce è la situazione: la camera su un robot si muove, il soggetto è vicino, la luce cambia a ogni passo, e il risultato deve arrivare a una decisione di movimento, non a uno schermo. Inoltre, non abbiamo camera di profondità, calibrazione della camera o odometria visiva in nessun progetto proprio. La prima fase sarebbe una cattura dal vostro ambiente e una misurazione di riferimento.

Avete agenti vocali. Non è la stessa cosa che sentire un robot?

No, e non vogliamo che sembri così. Al telefono, il canale è noto e stretto, chi parla è attaccato al microfono, e l’interruzione di chi parla la gestisce o il servizio del fornitore, o un tasto premuto. Su un robot, il microfono sta su una macchina che fa rumore da sola proprio mentre si muove, la voce arriva da una direzione che cambia, l’ambiente produce eco e la distanza varia. Sono problemi di acustica, non di conversazione. Potremmo partire da una misurazione del rumore proprio del vostro robot — ma sarebbe un lavoro nuovo, non un’estensione di quello telefonico.

Perché pubblicate una qualification gate che fallisce?

Perché l’alternativa è che passi senza significare nulla. La nostra gate legge un file di prova e verifica se una costante critica — il tempo di arresto al finecorsa dell’articolazione — è stata calibrata sull’hardware. Non lo è: è un valore provvisorio di 5 millisecondi, impostato perché esista una simulazione stabile. Finché è provvisorio, il controllo completo va in errore, e tutte le azioni restano marcate cinematiche. Il giorno in cui passerà significherà qualcosa proprio perché oggi non passa.

Cosa non dimostrano le vostre simulazioni?

Più di quanto dimostrano, ed è scritto nei report. Il validator fisico conferma la caduta libera e il mantenimento della posizione su un piano di prova — non la camminata, non il contatto complesso, non la dinamica dell’attuatore, non i sensori sintetici. Lo screening di traiettoria conferma la cinematica e la geometria — non il materiale, non i tubi flessibili, non i ritardi di processo, non le rampe di avvio-arresto del controller. E il movimento nel browser è un’anteprima, non un risultato di simulazione.

Abbiamo bisogno di una certificazione di sicurezza. La fate?

No. L’architettura di sicurezza la possiamo progettare — circuito separato dal controllo del movimento, controller di sicurezza indipendente, arresto sicuro della coppia, freni con feedback, stati di guasto che vanno in sicurezza; questo lo abbiamo fatto anche in un progetto proprio di macchina. Ma la valutazione di conformità e la responsabilità per la macchina immessa sul mercato restano al produttore o all’integratore. Non ci assumiamo quel ruolo e non firmiamo al posto di nessuno.

Perché c’è scritto «offerta» su questa pagina?

Perché il servizio ha tre strati e nessuno supera completamente la soglia che ci siamo posti. Sul controllo abbiamo due lavori propri con test che passano, ma nessuno tocca l’hardware. Sulla visione abbiamo un prototipo con un commit e senza test. Sull’audio per robot abbiamo zero. Avremmo potuto scrivere una pagina che suona come esperienza, usando parole come «percezione» e «controllo» senza cifre. Avrebbe retto fino alla prima domanda di un ingegnere.

Su cosa si basano le affermazioni sopra (17 fonti)

`vision.megapromoting.com` non è un sistema di visionehttps://vision.megapromoting.com · 2026-09-06

16 di esse sono codice e file dei nostri repository. Non ne pubblichiamo il nome né la riga: insieme, in un'unica pagina, descriverebbero con troppa precisione come sono costruiti sistemi che non sono solo nostri. Le esaminiamo con te, nel repository, su richiesta — la verifica resta possibile, solo che avviene in una discussione.

Come lavoriamo Tutti i servizi

Cosa vorresti che funzionasse meglio?

Raccontaci il tuo processo. Insieme stabiliamo cosa vale la pena costruire, cosa possiamo collegare e come verifichiamo il risultato.

Parliamone