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 a adição de sensores piora a localização, o filtro não é o único suspeito. As medições não podem ser comparadas diretamente se seus tempos, quadros ou unidades forem diferentes. Verifique cada entrada e, em seguida, os limites onde ela entra na fusão.
Corrija a ordem de diagnóstico
Reutilize um log curto e inspecione as rodas individualmente, a IMU individualmente e, em seguida, ambas. Alterar o piso ou a velocidade de deslocamento ao mesmo tempo obscurece a causa. Revise os princípios em fundamentos da fusão de sensores.
Erro de temporização se torna erro de movimento
A uma velocidade constante de 1 m/s, um erro de timestamp de 50 ms cria um deslocamento aparente de 1\times0.05=0.05 m. A 90 graus/s, o mesmo erro cria uma discrepância de rotação de 4,5 graus. Esses são cálculos de movimento constante, não tolerâncias recomendadas.
Determine se um carimbo de data/hora de mensagem indica aquisição do sensor ou recepção do driver. Um atraso de transmissão fixo pode ser gerenciável com carimbos de data/hora de aquisição corretos; relógios que divergem entre os hosts representam um problema diferente. Uma fila mais longa não corrige o desvio do relógio. Durante a reprodução, certifique-se de que todos os nós relevantes usem a mesma configuração de tempo de simulação.
Verificar eixos e origens
Os sistemas de coordenadas do corpo no ROS normalmente usam x para frente, y para a esquerda e z para cima; os sistemas de coordenadas ópticas da câmera usam z para frente, x para a direita e y para baixo. Verifique as convenções em REP-103. Renomear um sistema de coordenadas não rotaciona seus valores.
Transforme um ponto do sensor usando p_b=R_{bs}p_s+t_{bs} . Tanto a rotação quanto a translação são importantes. A translação inversa é -R^Tt , e não simplesmente -t . Registre se a calibração mapeia o sensor para o corpo ou o corpo para o sensor.
Deslocamentos de montagem também alteram o movimento
Para um corpo rígido, a velocidade no sensor é v_s=v_b+\omega\times r. Com um deslocamento perpendicular de 0,2 m e velocidade angular de 1 rad/s, a diferença de velocidade é de 0,2 m/s. Um sensor afastado do centro de rotação se move mesmo durante uma curva no mesmo lugar.
Inclua curvas, bem como translação, nos diagnósticos. A calibração extrínseca completa requer movimento suficientemente informativo; apenas dirigir em linha reta pode não identificar todos os graus de liberdade. Compare as responsabilidades do quadro com REP-105.
Inspecione os resíduos e a covariância por último
| Sintoma | Hipótese | Compare a seguir |
|---|---|---|
| O erro aumenta com a velocidade | Descompasso de tempo | Mesma rota em velocidades diferentes |
| O erro aumenta durante as curvas | Eixos, deslocamento ou tempo | Parado, em linha reta e curvas à esquerda/direita |
| Estime os saltos ao adicionar uma entrada | Quadro, unidades ou excesso de confiança | Entrada bruta e resíduo de previsão |
| Deriva lenta | Viés ou deslizamento | Médias brutas e direções observáveis |
Um resíduo é a diferença entre a observação e a previsão. Uma covariância menor aumenta a confiança; ela não corrige eixos ou timestamps incorretos. Tratar a posição e a velocidade derivadas do mesmo codificador como observações fortemente independentes também pode superestimar a quantidade de informações. Inspecione a seleção de entrada e o tratamento de quadros na implementação oficial de localização de robôs.
Confirme uma causa por vez
Altere uma configuração, compare o mesmo registro e confirme com uma nova execução. Valores estacionários plausíveis não descartam erros de sincronização ou montagem dependentes do movimento. Antes da avaliação SLAM, registre a semântica do timestamp, as unidades, os publicadores TF e a direção de calibração em conjunto.
Comentários
Entre na sua conta para continuar.
Ainda não há dados.