Camera Preprocessing
camera_preprocessing.py
Overview
camera_preprocessing.py is a horizontal (domain-independent) data-filter component that improves raw RGB + depth imagery before any perception or fusion module touches it. Every robot sharing the same message contracts can reuse this node as-is, giving you a single place to tweak sensor quirks instead of a dozen ad-hoc patches spread across your stack.
Interfaces (strongly-typed, stateless)
Direction |
Topic |
Message type |
Notes |
|---|---|---|---|
Required |
|
|
BGR8 frames |
Required |
|
|
Any depth encoding |
Provided |
|
|
Same header; 5 × 5 Gaussian blur (σ ≈ 1) |
Provided |
|
|
Same header; values < 0.5 m set to 0 |
Contract
Pre-conditions
Incoming RGB must be 8-bit, 3-channel (BGR8).
Depth resolution not larger than 1920×1080 (soft real-time ceiling).
Post-conditions
Header stamp and frame_id are identical between input and output.
Latency from callback entry to publish is < 12 ms on a 4-core laptop.
Output resolution equals input (no accidental rescale).
Invariants
Peak RAM ≤ 5×(w×h×c) bytes (one temp copy plus output buffer).
Protocol
Subscribe to both raw topics.
Publish processed counterparts for every incoming frame.
No service calls or stateful dialogue; each message is handled independently.
Lifecycle
Node name: {robot}_camera_preprocessing_node.
Ready when its two publishers are advertised (no extra init service).
Clean shutdown on Ctrl-C or rosnode kill, handled by rospy.
Quality & Reusability Metrics
Latency < 12 ms → supports 30 Hz pipelines.
Throughput ≥ camera frame-rate (default 30 Hz).
Cyclomatic complexity < 15 → easy to maintain / extend.
Adding such a server is orthogonal to the current contract and does not break existing clients.
Implementation Notes
A single global CvBridge keeps conversion overhead low.
Processing occurs inside subscriber callbacks (no poll loop).
The duplicate publisher block at the end of __init__ preserves existing downstream contracts; remove it only after all consumers migrate to the namespaced topics.