You set the camera's output flags to false, save the JSON, and the read-back confirms it: every unwanted output is off. Then you launch the ROS driver, and half of those flags read true again, with each disabled topic still publishing on the bus. Nothing is wrong with your edit. The driver's launch file passes a stream schema mask — the PCIC schema — and that mask, not your saved configuration, decides which layers the camera transmits. Here is how to prove the override in five minutes, compute the mask with the schema helper, put it in the launch file, and keep the trimmed topic set after every relaunch.
The persistent config and the session schema
A 3D camera that streams over the PCIC protocol separates output control into two layers. The persistent configuration is what the dump and config commands read and write: network settings, operating modes, filter parameters and the output flags — keys such as OutputAmplitudeImage — that you set to false. It survives power cycles, and your edit landed there; the second dump proved it.
The session schema is different. It is a bitmask the client hands the camera when it opens the data stream, and each bit enables one image layer — typically distance, amplitude, confidence and a Cartesian point cloud, plus auxiliary outputs. The camera transmits exactly the requested layers and nothing more, and the driver publishes a ROS topic for each layer it receives. The launch file ships with a default mask, so every roslaunch re-decides the stream set before your node sees a single message.
That is the whole mechanism. Your flags describe the persistent store; the mask describes the session. When the two disagree, the mask wins, and the next dump shows the flags back at their defaults because the driver re-applied them at start-up.
Likely causes, most probable first
1 — The launch file's schema default overrides you (most likely). The driver applies its own mask each time it opens the stream, so your stored flags stop describing reality the moment the session starts. Test: set the flags false, confirm with a dump, then run any non-ROS client — the vendor's viewer or a short SDK script. If the trimmed layer set streams outside ROS, the camera is fine and the launch file is the writer you are fighting.
2 — A second writer re-applies settings after you. Another node, a start-up script or a reconnecting viewer can write configuration too. Test: dump one minute after launch with nothing else running, and search the workspace for every launch file that mentions the driver or a schema parameter.
3 — You configured a different camera than the driver opens. On a multi-camera bench it is easy to edit the unit at 192.168.0.69, the tool's default address, while the launch file drives a neighbor at .70. Test: read the IP argument in the launch file and run dump against exactly that address.
Prove the override in five minutes
-
dumpthe camera, set the output flags false, load the file back withconfig, and dump again. The store must read false — your original flow, kept unchanged. - Open a plain session without launching the driver: viewer or SDK script, same camera IP. Check which layers arrive. A trimmed set here means the camera obeys its persistent config.
- Launch only the driver, wait for the first frames, and dump once more. Flags back at true prove the launch is rewriting them — the override is confirmed and located.
- Search your launch files for the schema parameter. It is an integer mask passed to the node that opens the PCIC stream; exact names differ between driver releases, so search for 'schema' and for any bare hexadecimal argument.
The fix: set the mask in the launch file
- Run the schema helper. It lives in the same command-line suite as
dumpandconfig: theschemasubcommand.schema --helplists the global options —--ipamong them, defaulting to 192.168.0.69 — and the tool prints the mask for the layer set you pick. - Paste that value into your launch file as the driver node's schema parameter: an
argfeeding aparamin roslaunch XML, or a node parameter in a ROS 2 launch script. Name the argument yourself so it is easy to find later. - Relaunch and count topics with
rostopic list. The list must match your enabled layers and nothing more. - Dump once more after a session. If a stored flag now disagrees with the stream you deliberately set, trust the mask — with the parameter under your control, the stored flags are no longer the operating truth.
Worked example, with illustrative numbers: assume each enabled layer publishes one image topic plus one CameraInfo topic. The default mask enables six layers, so the bus carries 6 × 2 = 12 topics. Your node reads distance, confidence and the point cloud; the helper returns a three-layer mask, and after the relaunch rostopic list shows 3 × 2 = 6 topics. Twelve versus six is also your acceptance check: if the list still shows 12, the file you edited is not the file being loaded — check which launch file your start-up command actually includes.
What trimming buys you on the wire
Every enabled layer is roughly one full frame per shot, so the saving scales with the layer count: three layers instead of six halves the pixels shipped per frame and about halves the messages the driver publishes. Size the absolute rate as pixels × bytes per pixel × frame rate. At 640 × 480 pixels, 2 bytes per pixel and 30 fps, one 16-bit layer moves 640 × 480 × 2 B × 30 = 18.4 MB/s; a six-layer default runs past 110 MB/s before protocol overhead, and the three-layer mask cuts that to about 55 MB/s. The 640 × 480 and 30 fps figures are a scale example — put in your camera's pixel count and frame rate and the same multiplication holds.
On a bench with several depth cameras, this is usually the cheapest fix for sagging frame rates, because cameras that stream every layer fight each other for the link. Why three depth cameras drop to low FPS walks that failure, and if you keep the confidence layer, decode its flags instead of thresholding blindly — confidence image values: decode bitflags and mask bad pixels explains the bit layout.
Make the setting stick
- The mask lives in exactly one file: your top-level launch, which cell and robot launches include. Never edit the driver's example launch in place.
- Comment the value with the layer names it enables, so the next engineer does not have to re-derive it.
- Re-run the five-minute proof after every driver or firmware update; defaults move between releases.
- Any client that opens a stream imposes its own session schema. A viewer left connected changes what the camera transmits — close it before you judge the topic list.
- Adding cameras to the same launch anyway? Multiple cameras in a ROS launch: plan acquisition and synchronization covers the acquisition and trigger side.
When the schema is not your problem
Four look-alikes fail differently:
- Flags flip back even though the driver never launched: the write itself failed. Re-run
configagainst the exact IP the driver uses. If a key refuses to store at all, that camera family keeps it read-only, and the route back is the vendor's documented reset or import procedure — not a hand-edited dump file. - Topics publish but carry the wrong image — grey depth where color should be. That is stream selection inside the camera, not the mask; depth camera RGB shows black and white: you are on the IR stream is that exact failure.
- You only wanted different topic names. Renaming is remapping, and the camera keeps shipping every enabled layer either way; remap depth camera topics for a ROS people detection node shows the remap side.
- The driver exposes no schema parameter at all: some releases fix the mask in code. Set the schema from your own node through the SDK's session API, or move to a driver release that exposes the parameter.
Before the next launch
- Dump, edit,
config, dump: the store holds your values before anything launches. - A non-ROS session streams the trimmed set: the camera obeys its config.
- A driver-only launch flips the flags: the override is proven and located.
- The schema helper's value sits in your launch file, commented with the layer names.
-
rostopic listmatches the expected topic count after the relaunch. - The proof is repeated after each driver or firmware update.
More depth-camera integration fixes sit on the 3D vision topic page. If you are standardizing the depth hardware in the cell too, the 3D sensors category groups cameras by type — laser profiler, stereo and structured light, ToF depth, logistics volume — so you can match the output set to the task instead of trimming layers afterwards. The MV-DT01WMU is a ToF sensing camera, and the MV-DPS200P-02 is a projected structured-light 3D camera; the 3D camera finder filters the rest by type and series. Every order includes free expert support, so a schema question can travel with the hardware.
- Type
- Depth / ToF camera
- Type
- Stereo / structured light
Laser profilers and stereo 3D cameras
170 models · from $699.00Questions
Where does the schema mask go in the launch file?
It is a parameter of the driver node, not a camera setting. In a roslaunch XML file it appears as a rosparam integer inside the node that opens the PCIC stream, usually fed from an arg you can override per machine. If the driver's example launch file does not expose one, add the parameter yourself and set it to the mask value the schema helper printed. A ROS 2 launch script takes the same value as a node parameter.
Does the camera remember the schema mask after a power cycle?
No. The mask is session state: the client sends it when the stream opens and it governs that stream only. What persists is the configuration you wrote with dump and config, minus any keys the driver rewrites at launch, which is why the output flags read true again after a session. Judge the effective stream set by the topics on the bus and by a dump taken with the driver stopped, never by the flags alone.
Which layers are safe to disable first?
Start with layers no node subscribes to: auxiliary images such as amplitude or confidence when your pipeline reads distance only, debug outputs, and any RGB or IR layer nobody uses. Keep every layer a downstream node reads, even if you use it only occasionally — a disabled layer comes back as an empty topic or a no-messages error at runtime, not as a launch failure. Trim one layer at a time and re-run your pipeline checks.
Should I trim layers or throttle the publish rate instead?
Trim layers. A publish-rate throttle leaves the camera capturing and shipping frames your node discards, so the link and the driver CPU stay loaded; the schema mask removes the work at the source, before the bytes leave the camera. Rate changes also interact with exposure on time-of-flight imagers, while a disabled layer simply never exists. Do both only after trimming: set the mask first, then tune rates for the layers that remain.
Can several cameras with different masks share one launch setup?
Yes, if the mask is an arg with a default rather than a hard-coded value. Include the same launch snippet once per camera and pass each unit's IP and mask as arguments; the schema helper runs against one IP at a time, so print a mask per camera model and layer list. Keep the values in one versioned file so a change to one camera's layer set does not silently move the others.