Frame di coordinate ROS 2 TF2 per robot mobili

Una scansione laser viene misurata rispetto al laser, una posa di odometria delle ruote è relativa al frame iniziale e un obiettivo di navigazione è solitamente espresso in una mappa. Per confrontarli, il robot deve conoscere la relazione geometrica tra i frame di coordinate al momento corretto. Il sistema TF2 di ROS 2 archivia e interroga quell’albero di trasformazioni variabili nel tempo.

La maggior parte dei guasti TF2 non riguarda matematica avanzata. Si tratta di un genitore mancante, di una trasformazione invertita, di una marca temporale errata o di due nodi che rivendicano la proprietà della stessa relazione tra frame.

Pensa in trasformazioni, non in pose copiate

Una trasformazione descrive la traslazione e la rotazione da un frame padre a un frame figlio. Se base_link → laser indica che il laser si trova 0.20 m avanti e 0.10 m sopra la base del robot, TF2 può trasformare le misurazioni del laser nel frame base. Combinando ciò con odom → base_link, le esprimi nelle coordinate locali di odometria.

I frame formano un albero: ogni figlio ha esattamente un genitore per volta. Un collegamento può muoversi, ma la relazione con il genitore non può essere ambigua. Cicli come A → B → C → A non sono validi.

I frame ID sono nomi semantici, non unità né dati. Un punto marcato laser richiede ancora una trasformazione corrispondente alla marca temporale della misurazione.

Usa la catena standard per robot mobili

Un albero di navigazione comune è:

map → odom → base_link → laser
                       → camera_link
                       → imu_link

Ogni collegamento ha un ruolo distinto:

• map → odom: correzione della localizzazione globale. Può cambiare quando la localizzazione corregge la deriva accumulata.
• odom → base_link: movimento locale uniforme derivato dall’odometria basata su ruote, visiva o inerziale. Deve restare continuo, ma può derivare.
• base_link → sensor: geometria fissa di montaggio, normalmente una trasformazione statica.

Separare map e odom permette correzioni globali senza far saltare il frame di controllo locale. I nomi seguono le convenzioni ROS, ma il tuo robot può aggiungere base_footprint, frame per cardani o link articolati.

Decidi chi pubblica ogni collegamento

Scrivi una tabella di proprietà prima di avviare i nodi:

Esattamente un componente autoritativo deve pubblicare ogni collegamento. Due pubblicatori producono trasformazioni alternate o in conflitto, che possono sembrare salti casuali della posa.

Le trasformazioni statiche descrivono la geometria di montaggio misurata. Colloca origine e orientamento degli assi nella posizione in cui li aspetta il modello del sensore. Un frame ottico di una telecamera usa convenzioni degli assi diverse rispetto a un tipico frame base del robot, quindi segui la convenzione ROS pertinente anziché indovinare dal disegno.

Ispeziona l’albero attivo

Inizia con prove dalla riga di comando:

ros2 run tf2_tools view_frames
ros2 run tf2_ros tf2_echo odom base_link
ros2 run tf2_ros tf2_echo base_link laser

view_frames genera un grafico che mostra connettività, pubblicatori, frequenza di aggiornamento e informazioni temporali. tf2_echo target source riporta la trasformazione che converte i dati dal frame sorgente in quello di destinazione. Invertire gli argomenti mostra la trasformazione inversa, una comune fonte di confusione.

In RViz imposta intenzionalmente il frame fisso. Se il frame fisso è map ma map → odom manca, non puoi collocare le visualizzazioni che dipendono dall’odometria e dai sensori, anche se i loro messaggi arrivano regolarmente.

Rispetta le marche temporali delle misurazioni

TF2 archivia una cronologia delle trasformazioni dinamiche. Un messaggio di sensore marcato al tempo t deve essere trasformato usando l’albero al tempo t, non semplicemente l’ultima trasformazione. È importante mentre il robot si muove: usare una posa successiva sposta l’osservazione.

Usa la stessa sorgente oraria in tutti i nodi. In simulazione, tutti i partecipanti devono concordare il tempo simulato. Su più computer, gli orologi devono essere sincronizzati in modo adeguato alla precisione temporale richiesta dal sensore.

Un errore di «estrapolazione nel futuro» significa spesso che la marca temporale richiesta è più recente della trasformazione disponibile. «Estrapolazione nel passato» significa che i dati richiesti sono più vecchi del buffer TF2. Aumentare il buffer può aiutare con dati realmente ritardati, ma non risolve orologi discordi né marche temporali create nella fase sbagliata.

Verifica la geometria con semplici test fisici

I numeri possono sembrare plausibili mentre gli assi sono errati. Testa una relazione alla volta:

1. Mantieni fermo il robot e visualizza i punti del sensore in base_link.
2. Colloca un bersaglio direttamente davanti. La posizione trasformata deve trovarsi sull’asse di marcia previsto.
3. Ruota il robot sul posto. Un bersaglio fisso nel mondo deve restare fisso in odom, salvo errori di odometria.
4. Sposta il robot in avanti. Le osservazioni del sensore devono muoversi in modo coerente con la posa della base.

Misura le traslazioni statiche dalle origini scelte, non dai bordi arbitrari della struttura. Per un robot planare, un segno errato dello yaw può rispecchiare le scansioni e far sembrare che i muri ruotino con il veicolo.

Trasforma i dati al confine del consumatore

Un consumatore deve dichiarare il frame di destinazione necessario e chiedere a TF2 di trasformare i dati marcati. Evita di copiare manualmente valori di traslazione e rotazione nelle formule applicative: così salti la sincronizzazione temporale, l’incatenamento dei frame e la gestione consolidata dei quaternioni.

Se una trasformazione può arrivare poco dopo il messaggio, usa un filtro messaggi compatibile con TF2 o un’attesa limitata adatta al nodo. Non bloccare indefinitamente un loop di controllo in tempo reale in attesa della geometria.

Mantieni i frame ID privi di slash iniziali e coerenti per ortografia e maiuscole/minuscole. Pianifica i namespace per sistemi multirobot, così robot_1/base_link e robot_2/base_link non possono entrare in collisione.

Diagnostica i guasti dalla forma dell’errore

• Nessuna connessione tra i frame: manca un collegamento oppure il nome del frame differisce tra pubblicatore e messaggio.
• L’albero alterna tra due pose: due nodi pubblicano la stessa trasformazione del figlio.
• I dati del sensore sono ruotati di 90° o rispecchiati: l’orientamento statico o la convenzione del frame ottico è errata.
• I dati restano indietro rispetto al movimento: le marche temporali sono errate, le trasformazioni arrivano in ritardo oppure il consumatore usa l’ultima trasformazione.
• Il robot salta globalmente ma il controllo locale è uniforme: potrebbe essere una correzione di localizzazione valida map → odom.
• Il controllo locale salta quando la localizzazione si aggiorna: una posa globale viene pubblicata erroneamente come odom → base_link.
• RViz mostra i messaggi ma non riesce a collocarli: il frame fisso o la connettività dell’albero è errata.

La posa integrata nell’odometria a trazione differenziale fornisce naturalmente odom → base_link. Il tutorial sui fondamenti dello SLAM spiega quale stimatore globale fornisce map → odom e perché la separazione è importante.