Topic smear: duplicate sensors of the same type share one topic

Story: as a dev, if I connect multiple of the same sensor I can pass all that data to a module without recompiling/building the module so that I can conveniently enhance the robot with better data.

Ex:

• Two lidars into the raytracer
• Multiple cameras/imus to the cuVSLAM/dimSLAM module

Core change, exploratory task, 2.5 directions (no perfect solution):

1. Overloaded topic: current approach. Keep dumping instances on one topic, disambiguate
downstream by frame.

2. Topic-Funnel: For a particular input, a module gets its list of topics + protocols at startup and subscribes to exactly those. On the Rust side this already comes through the stdin
config and enforces a bijection between the config topics and the Rust ports, so there
can be no unused topics. Python equivalent would be subclassing a native module to
declare its subscriptions:

class slam(nativemodule):
    ...

class 5CameraSLAM(slam):
    camera1: topic1
    camera2: topic2
    ...

Argument for 2: something.subscribe() is normally expected to have a single semantic
source. We don't put every path or every cmd_vel on one topic and rebuild the pubsub in
post-processing.

Undecided which of the two we want.

Next steps

• Meeting with Paul — multi-lidar, and likely more cases shaped like this
• Talk to Sam
• Next sensor-fusion PR (all Rust) will try a way to list topics in Rust; check
  whether the Python subclassing form can work too

Source

#navigation-private, 2026-08-28 — Jeff / lesh / andrew.

Synced from DIM-1539 by jeff

Start with the Rust sensor-fusion path and its stdin configuration, then examine whether the proposed Python native-module subclassing form can express multiple subscriptions. Use the multi-lidar and camera/IMU examples to compare the overloaded-topic and topic-funnel approaches. Done means the team has selected and validated an approach for these cases.