Contents — find the section you need
Change parameters and verify
Open the panel, then press Run to load Python. You can stop execution and reset parameters. Results are computed on this device. No Python installation is required.
Local execution steps below are optional for reproducing the source results; they are not required for the browser experiment.
The experiment controls are in English.
Explore timing, mounting position and axes in your browser
Use the panel above to compare ideal examples without ROS or local Python. These calculations explain different sources of disagreement; they do not run a fusion filter, estimate calibration or diagnose a robot. The original diagnostic procedure remains below.
Time offset: Δt is the time of the compared value minus the reference time. The displayed differences are x(t+Δt)−x(t)=vx Δt and heading(t+Δt)−heading(t)=yaw_rate Δt. Positive Δt compares a later value; negative compares an earlier value. At 1 m/s, 90 deg/s and +50 ms, the differences are +0.05 m and +4.5°. These are separate constant-axis translation and constant-angular-rate examples, not an integrated turning trajectory or a prediction of filter error. Time offset is not automatically transport latency or a timestamp-sign convention for a particular driver. Zero motion can hide timing disagreement. No tolerance is recommended.
Mounting position: the lower diagrams describe velocities at one instant. Body axes use x forward, y left, z up; positive yaw is counterclockwise viewed from +z. The supplied base-point velocity is v_base=(vx,0) in body axes. The lever arm r=(rx,ry) points from that base origin to the sensor origin, also in body axes. With ω=yaw_rate × π/180, the mounting-point velocity difference is ω×r=(-ω ry, ω rx) m/s. Thus v_sensor_body=v_base+ω×r. The position plot uses metres; the velocity plot uses m/s with separate scales. Sensor-axis arrows have a display length of 0.15 m. The velocity plot places vectors at a common origin to compare their components, not to depict where the robot travels.
Mounting orientation: R_bs rotates sensor components into body components. The model constructs hypothetical sensor-point linear velocity as v_sensor_components=R_bsᵀ v_sensor_body. Rotating it back gives the velocity of the sensor point, still not the base point. Only after subtracting the known ω×r term does this ideal algebra recover the supplied base velocity. Reuse of the known exact geometry is not a calibration estimate. This is a hypothetical velocity measurement, not raw IMU acceleration or gyro output; acceleration lever-arm effects are not modeled.
The “raw component mismatch” deliberately subtracts sensor-axis numbers from base-axis numbers at another point. It is an example of an invalid comparison, not a filter innovation. Its norm may even cancel to zero for some wrong comparisons. The algebraic recovery residual measures floating-point roundoff after using the same exact model; it is not localization accuracy or evidence that real calibration is correct. The table labels every vector by its point and axes.
Try in-place rotation, zero lever arm, a sensor on the left, reversed rotation and a 90° sensor mounting. Changing mounting yaw changes sensor components but leaves physical body-frame velocity unchanged. Changing Δt affects only the timing exercise. By default the lever arm is 0.2 m and the rate is 90 deg/s, so the lever-arm speed is about 0.314 m/s; the article's separate 1 rad/s example gives 0.2 m/s. Do not confuse degrees/s with radians/s.
All inputs are synthetic and exact. No covariance, noise, observability test, slip, bias, interpolation, TF lookup, clock synchronization, ROS execution or fusion estimator is included. A/B uses matching position and velocity scales; slider limits are teaching choices. For point transforms, use the separate coordinate-transform Lab; for replay conditions, use the replay Lab.
References reviewed 2026-09-20: REP-103 coordinate conventions and Modern Robotics: rigid-body point velocity. The browser uses the site's existing planar rotation helper and the planar form of the rigid-body velocity relation.
Quando l'aggiunta di sensori peggiora la localizzazione, il filtro non è l'unico sospettato. Le misurazioni non possono essere confrontate direttamente se i loro tempi, frame o unità di misura differiscono. Controlla ogni input, quindi i punti in cui entra nella fusione.
Correggi l'ordine di diagnosi
Riutilizza un log breve e ispeziona le ruote singolarmente, l'IMU singolarmente, poi entrambi. Cambiare il pavimento o la velocità di guida contemporaneamente maschera la causa. Rivedi i principi in fondamenti della fusione dei sensori.
L'errore di temporizzazione diventa errore di movimento
A una velocità costante di 1 m/s, un errore di timestamp di 50 ms crea uno spostamento apparente di 1\times0.05=0.05 m. A 90 gradi/s, lo stesso errore crea una discrepanza di rotazione di 4,5 gradi. Questi sono calcoli a movimento costante, non tolleranze raccomandate.
Determinare se un timestamp di messaggio indica l'acquisizione del sensore o la ricezione da parte del driver. Un ritardo di trasmissione fisso può essere gestibile con timestamp di acquisizione corretti; orologi non sincronizzati tra host rappresentano un problema diverso. Una coda più lunga non corregge lo scostamento dell'orologio. Durante la riproduzione, assicurarsi che tutti i nodi rilevanti utilizzino la stessa configurazione di tempo di simulazione.
Verifica assi e origini
I frame ROS del corpo utilizzano normalmente x avanti, y sinistra e z su; i frame ottici della telecamera utilizzano z avanti, x destra e y giù. Verificare le convenzioni in REP-103. Rinominare un frame non ne ruota i valori.
Trasformare un punto del sensore utilizzando p_b=R_{bs}p_s+t_{bs} . Sia la rotazione che la traslazione sono importanti. La traslazione inversa è -R^Tt , non semplicemente -t . Registrare se la calibrazione mappa il sensore sul corpo o il corpo sul sensore.
Anche gli offset di montaggio influenzano il movimento
Per un corpo rigido, la velocità al sensore è v_s=v_b+\omega\times r. Con un offset perpendicolare di 0,2 m e una velocità angolare di 1 rad/s, la differenza di velocità è di 0,2 m/s. Un sensore lontano dal centro di rotazione si muove anche durante una svolta sul posto.
Includere le svolte oltre alla traslazione nella diagnostica. Una calibrazione estrinseca completa richiede un movimento sufficientemente informativo; la sola guida in linea retta potrebbe non identificare tutti i gradi di libertà. Confrontare le responsabilità del telaio con REP-105.
Esaminare i residui e la covarianza per ultimi
| Sintomo | Ipotesi | Confronta successivo |
|---|---|---|
| L'errore aumenta con la velocità | Disallineamento temporale | Stesso percorso a velocità diverse |
| L'errore aumenta durante le svolte | Assi, offset o temporizzazione | Fermo, rettilineo e svolte a sinistra/destra |
| Stima dei salti durante l'aggiunta di un input | Frame, unità o eccessiva sicurezza | Input grezzo e residuo di predizione |
Deriva lenta | Bias o slittamento | Medie grezze e direzioni osservabili |
Il residuo è la differenza tra osservazione e predizione. Una covarianza minore aumenta l'affidabilità; non corregge assi o timestamp errati. Trattare posizione e velocità derivate dallo stesso encoder come osservazioni fortemente indipendenti può anche sovrastimare le informazioni. Esaminare la selezione dell'input e la gestione del frame nell'implementazione ufficiale di robot_localization.
Confermare una causa alla volta
Modificare un'impostazione, confrontare lo stesso log, quindi confermare con una nuova esecuzione. Valori plausibili stazionari non escludono errori di sincronizzazione dipendenti dal movimento o errori di montaggio. Prima della valutazione SLAM, registrare insieme la semantica del timestamp, le unità, i publisher TF e la direzione di calibrazione.
Commenti
Accedi per continuare.
Nessun dato disponibile.