Il tuo robot non può essere intelligente, veloce e libero. L'evoluzione ha già risolto questo problema.

      Ecco un vincolo che quasi nessuno che costruisce AI fisica dice ad alta voce, anche se ognuno di loro lo sta combattendo silenziosamente.

      L'intelligenza di un robot desidera tre cose contemporaneamente. Vuole essere intelligente, il che significa che può ragionare a livello di un modello di frontiera su una scena sconosciuta. Vuole essere veloce, il che significa che risponde all'interno dei tempi ristretti e deterministici richiesti da un loop di controllo fisico. E vuole essere libero, il che significa che continua a funzionare quando la rete cade, il Wi-Fi del magazzino muore o la macchina va in un luogo dove non arriva alcun segnale.

      Non puoi avere tutte e tre le cose su un singolo pezzo di calcolo. Scegli due qualsiasi.

      Per essere precisi, l'autonomia limitata funziona già. Bracci industriali, droni e stack di autonomia limitata possono essere veloci e offline perché i loro compiti sono ristretti. Il trilemma morde alla frontiera: non puoi mettere il ragionamento generale su scala di frontiera, la risposta deterministica in tempo reale e la piena autonomia offline nello stesso substrato limitato in potenza, non per lo stesso loop di controllo.

      Un modello su scala di frontiera è intelligente, e se trasmetti i suoi sensori a un datacenter può persino essere veloce, ma ora è legato a una rete e non è più libero. Riduci quel modello fino a farlo stare su un modulo embedded da 15 watt e diventa veloce e libero, ma non è più intelligente come un modello di frontiera. Esegui il grande modello nel cloud e interrogarlo solo occasionalmente, e ottieni intelligenza e libertà, ma mai velocità. Tre angoli, due disponibili alla volta. Ho cominciato a pensare a questo come al trilemma incarnato, ed è la vera ragione per cui la questione edge/cloud è la decisione architettonica più difficile nella robotica. La maggior parte dei team la tratta come un dettaglio di distribuzione. È più vicina a una legge.

      Perché non puoi barare con il triangolo

      Il trilemma non è una moda o una limitazione hardware temporanea che puoi aspettare. Deriva direttamente dalla fisica e dai budget energetici.

      La qualità del ragionamento di frontiera vive attualmente in modelli che richiedono decine di gigabyte di memoria e acceleratori di classe datacenter. Quell'hardware non funziona con una batteria che un robot mobile può trasportare. Quindi "intelligente" impone una scelta: portare il datacenter al robot attraverso un collegamento di rete, il che sacrifica la libertà, oppure accettare un modello onboard più piccolo, il che sacrifica l'intelligenza.

      Il controllo in tempo reale è ancora meno negoziabile. Un viaggio di andata e ritorno su una rete a larga area aggiunge 30 a 100 millisecondi di latenza, e la varianza conta più della media. Un loop di controllo che di solito è veloce ma occasionalmente si ferma è peggiore di uno che è affidabilmente mediocre, perché i controllori sono sintonizzati per un timing deterministico. Nel momento in cui "veloce" dipende da una rete, hai rinunciato a "libero", perché la rete è ora all'interno del tuo loop di controllo che tu lo volessi o meno.

      Quindi il triangolo tiene. La quantizzazione, la distillazione e migliori acceleratori spostano gli angoli, ma non li fanno collassare. Chiunque affermi il contrario di solito sta nascondendo quale angolo ha rinunciato.

      Mettere numeri sul triangolo

      È utile rendere il vincolo quantitativo, perché nel momento in cui scrivi il timing, gli angoli smettono di essere astratti.

      Inizia con la latenza. Il ritardo end-to-end di una decisione di percezione-azione presa nel cloud è una somma di termini:

      Lcloud = tcapture + tencode + tuplink + tinference + tdownlink + tdecode

      Esegui la stessa decisione a bordo e la maggior parte di quella somma scompare:

      Ledge = tcapture + tinference,local

      La differenza tra i due non è il tempo di inferenza, che può effettivamente essere inferiore nel cloud su hardware migliore. La differenza è la rete, tuplink + tdownlink, e più importante la sua varianza. Un setup di robotica cloud misurato su un collegamento cablato veloce ha visto viaggi di andata e ritorno di circa 30 millisecondi, mentre le distribuzioni nel mondo reale si trovano comunemente nell'intervallo di 100 a 300 millisecondi, e i collegamenti wireless oscillano molto più in alto. L'elaborazione edge, al contrario, riduce i viaggi di andata e ritorno a 1-5 millisecondi perché nulla lascia la macchina.

      Ora dichiara la regola che decide dove può vivere un loop. Un loop di controllo con budget di timing Lbudget può funzionare su un dato percorso di calcolo solo se

      Lpath + k·σjitter ≤ Lbudget

      dove σjitter è la deviazione standard della latenza del percorso e k è il fattore di sicurezza necessario per il determinismo. Quel termine k·σjitter è il killer silenzioso. Gli studi di teleoperazione sono chiari al riguardo: un collegamento che mantiene una latenza costante di 100 millisecondi è praticabile, ma uno che oscilla tra 30 e 200 millisecondi produce movimenti irregolari e imprevedibili, perché il controllore non può pianificare attorno a un ritardo che non può prevedere. Il budget del loop riflesso è di 1-10 millisecondi. Nessun percorso a larga area soddisfa l'ineguaglianza. La matematica, non l'architetto, lo vieta.

      Loop di controllo

      Budget di timing

      Percorso onboard (~1-5 ms)

      Percorso a larga area (~30-300 ms)

      Riflesso (controllo motore, e-stop)

      1-10 ms

      Fattibile

      Impossibile

      Percezione (rilevamento, tracciamento, SLAM)

      30-100 ms

      Fattibile

      Marginale, fallisce su jitter

      Deliberazione (pianificazione, linguaggio)

      1-10 s

      Fattibile

      Fattibile (async)

      La tabella è l'argomento in una vista. Il riflesso non supera mai un viaggio di andata e ritorno in rete. La percezione lo supera solo su collegamenti insolitamente buoni. La deliberazione ha un budget da risparmiare, motivo per cui può vivere nel cloud in modo asincrono.

      La larghezza di banda chiude il caso per la percezione. Una singola telecamera 1080p a 30 fotogrammi al secondo produce video grezzo a 1920 × 1080 × 3 byte × 30, che è circa 1,5 gigabit al secondo. Un modesto rig con quattro telecamere più profondità supera i 6 gigabit al secondo di dati grezzi dei sensori. Puoi comprimerlo, ma la compressione costa latenza e il collegamento deve comunque trasportarlo in modo affidabile, ovunque vada il robot. La percezione edge è la versione robotica di quel movimento. Comprimi a una rappresentazione semantica sul posto; non spedire mai il flusso grezzo.

      Infine, l'economia, che è solo il trilemma con un simbolo di dollaro. Il calcolo onboard è un costo di capitale una tantum. Il ragionamento nel cloud è un costo operativo che si accumula con ogni query:

      Ccloud(t) = r·ctoken·t

      dove r è il tasso di query e ctoken il prezzo per token, contro un Cedge piatto = Ccapex. Le due linee si incrociano a t* = Ccapex / (r·ctoken). Spingi trenta fotogrammi al secondo a un modello cloud e t* arriva quasi immediatamente, quindi il costo del cloud domina la vita della flotta. Inoltra solo alcune query di classe deliberativa al minuto a monte e t* si ritira all'orizzonte.

      Strategia

      Cosa va a monte

      Forma dei costi

      Break-even t*

      Trasmetti tutto

      ~30 fotogrammi/sec a un modello cloud

      Opex lineare ripida

      Quasi immediato

      Inoltra solo deliberazione

      Poche query/min

      Opex lineare poco ripida

      Oltre la vita utile della flotta

      Completamente onboard

      Niente

      Capex una tantum, piatto

      Mai incrociato

      Stesso hardware, stessi modelli, economia opposta, decisa interamente da quale loop hai posizionato in quale angolo. Il divario non è sottile: una singola telecamera trasmessa a un modello di visione cloud