Unstable Timestamp Synchronization Between Stereo Cameras in ROS
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Ambito
- audio-video-rtc, robotics
Direzione di ricerca
Start by identifying the ROS1 camera nodes and Python API paths used to acquire stereo images, then inspect how each source assigns timestamps. The issue reports variable left/right offsets but names no files or tests; determine whether the discrepancy is in capture, timestamping, or synchronization before proposing a change. Done means stereo pairs have stable timestamp alignment and the behavior is verified across both acquisition paths.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Hello maintainers,
One:
I'm using this project for stereo SLAM development and encountered an issue with timestamp synchronization between left/right camera images. When acquiring images via ROS1 nodes, the timestamp difference between stereo pairs varies significantly (4–20ms) and fluctuates unpredictably.
Two:
"When acquiring images directly through the Python API, I've encountered two scenarios across multiple script executions:
Perfect sync: Timestamps from both cameras are identical
Significant drift: Timestamps show ~50ms discrepancy
This inconsistency persists even when restarting the Python script."
Could you suggest any methods to:
1/Implement software-based synchronization with stable timestamp alignment
2/Recommend best practices for configuring the nodes to minimize this discrepancy
or alternative solutions？
Thank you for your time and expertise!
What feature are you suggesting?
Overview:
Smaller Details:
Nature of Request:
- Addition
- Change
- Removal
Why would this feature be useful?
- Lingua principale
- C++
- Stelle
- 890
- Fork
- 170
- Merge medio
- 17h 15m
- PR unite (30g)
- 8
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di iamaisim/ProjectAirSim
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
iamaisim/ProjectAirSim#241 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
iamaisim/ProjectAirSim#239 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
iamaisim/ProjectAirSim#240 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 50/100
iamaisim/ProjectAirSim#236 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
iamaisim/ProjectAirSim#169 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di iamaisim/ProjectAirSim
Issue simili
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
objectionary/game-of-life#74 ·
-
bug fmt low priority
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
qbittorrent/qBittorrent#25176 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
lxqt/lxqt-powermanagement#500 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
scp-fs2open/fs2open.github.com#7965 ·
I maintainer di solito rispondono entro 1 giorno