If a ROS 2 LiDAR camera synchronizer never calls back while both topics appear active, inspect the inputs to the actual message-filter chain before changing calibration or replacing hardware. A topic visible in another terminal does not prove that the subscriptions inside your node receive it. Once both inputs are confirmed, compare their header timestamps, matching policy and retained history.
This diagnostic targets a silent paired callback. It does not establish whether two sensors captured the same physical instant. The capture-alignment qualification guide addresses hardware triggering and clock relationships. Here the immediate decision is which software gate prevents two received messages from reaching the registered callback.
Pin the deployed ROS distribution, message_filters version, language implementation and node revision before testing. The official Jazzy message-filter reference distinguishes source filters, caches and synchronizers. Use its concepts with the installed implementation; a parameter copied from a different release or language can describe a different policy.
Prove receipt inside the node that is failing
Add a lightweight observation at each input boundary before synchronization. Record the resolved topic, message type, number of messages received, header stamp and local observation time. Keep these observations separate from the paired callback counter. Avoid expensive point-cloud processing or image copying in the diagnostic path, because the instrumentation itself can delay other work.
A separate command-line subscriber is useful evidence that a publisher exists and can communicate with that subscriber. It is not evidence about every subscriber configuration. Inspect resolved names and namespaces in the actual node, and verify that the filter wraps the intended topic rather than a similarly named raw, rectified or compressed stream. Match the message type to that endpoint.
The ROS 2 QoS documentation explains that incompatible publisher and subscription policies can prevent delivery. Compare the actual endpoints. Do not assume that increasing depth repairs a reliability or durability incompatibility. If one filter input has no received messages, repair that delivery boundary before investigating timestamp matching.
Give every recorded time a meaning
For a short representative interval, preserve the complete header stamps from both streams, their order of receipt and their clock provenance. State whether the observer uses system, steady or ROS time. Do not subtract two values merely because both are expressed in seconds. A timestamp copied from a device clock may have a different origin from a timestamp assigned by a host driver.
The Image message definition says its header timestamp should represent acquisition. The PointCloud2 definition also associates the header with sensor acquisition. Those definitions do not prove how a particular driver implements the timestamp or whether a cloud spans a longer acquisition interval.
Write down any conversion between device time and the clock used in the messages. Preserve missing information as unknown. If timestamps reset, repeat or jump backwards, retain the original evidence and the restart sequence. The sensor-recording checklist helps preserve original timing fields rather than relying solely on the final fusion output.
Test the policy the application actually constructed
Read the synchronizer construction and callback registration in the deployed code. An exact-time policy needs matching header timestamps, not messages arriving during the same wall-clock interval. Independent camera and LiDAR streams can both be healthy while never producing an identical stamp. Confirm the policy before interpreting an empty paired-output counter.
Approximate matching permits a different relationship, but the implementation still decides which retained messages can form a candidate. Inspect the Jazzy Python implementation when diagnosing that implementation. Its matching window and queue handling are software rules, not a measurement that the underlying sensors captured simultaneously.
Do not transfer Python tuning names directly into C++ examples. The C++ approximate-time policy source is a separate implementation reference. Record the API and settings your executable actually uses. Increasing a permitted interval until output appears may hide a clock offset or create pairs too far apart for the application.
Separate the queues before changing their sizes
A middleware subscription history and a synchronizer’s retained candidates are different buffers. The first affects messages available to the subscription; the second affects messages still available for pairing after the filter receives them. Preserve both settings in the diagnostic record. One number labelled queue size in a launch file does not establish which layer it controls.
Use observed rates and delay variation to understand retention. As an explicitly illustrative example, a camera producing several messages while waiting for one LiDAR message may require more camera candidates than a one-to-one toy example. This is not a recommended universal queue depth. Determine what arrives, what remains eligible and what the application can afford in memory and latency.
| Observation | Boundary to investigate | Next evidence |
|---|---|---|
| No input observations on one side | Topic, type and endpoint delivery | Resolved names and QoS compatibility |
| Both inputs arrive but no equal stamps | Exact-time matching | Original stamp sequences and selected policy |
| Pairs appear only with a very large interval | Clock relationship or application tolerance | Stamp origin, offset and accepted physical skew |
| Output stops under workload | Executor progress and retention | Input counters, callback duration and drops |
Check lifetime and execution without obscuring the symptom
Keep the subscriber filters and synchronizer alive for the intended node lifetime. Review ownership in the actual program, especially when construction occurs inside a helper or short-lived scope. Confirm callback registration and its expected signature. A correct policy cannot invoke application code that was never connected to the chain being exercised.
Then examine whether the executor continues servicing the subscriptions. A long-running callback or a blocked dependency can make the node appear to have a synchronization problem. Compare input counters during the stall with earlier activity. Keep the publish-rate diagnostic available to separate upstream publication changes from processing delays inside the receiving node.
Replay a fixed interval and close the decision
Preserve a representative recording, configuration and executable identity before changing settings. Change one layer at a time and compare input counts, output counts and the timestamp difference of every accepted pair. Keep startup and restart cases separate from steady operation. A successful callback counter alone is an incomplete acceptance test.
If downstream transformation fails after pairing is restored, use the TF timing diagnostic. If a paired projection is rotated or mirrored, consult the optical-frame guide. Those failures need their own evidence; loosening the synchronizer should not become a general substitute for correcting timestamps or geometry.
Define acceptable pairing behavior from the consumer’s requirements. Retain the input interval, installed versions, selected policy, effective queue settings, timing observations and outcome. State which boundary changed and why the resulting pairs are useful. A reproducible decision record is more valuable than a setting that makes a demonstration appear busy.
Frequently asked questions
Does approximate matching synchronize the sensor clocks?
No. It selects messages using timestamps already attached to them. Establish the underlying clock relationship and acquisition meaning separately before treating a pair as physically aligned.
Should every silent callback be fixed by increasing the queue?
No. First prove receipt in both filter inputs, then check policy, stamp relationship, object lifetime and executor progress. A larger history cannot make incompatible endpoints communicate or make unrelated timestamps equal.
What should a support request include?
Provide a minimal reproducible interval, topic and type identities, endpoint policies, stamp samples, input and paired-output counters, construction code and exact versions. Describe observed facts separately from suspected causes. For a ROS 2 LiDAR camera synchronizer with no callback, these artifacts let another engineer test the failing gate rather than guess from a screenshot.
