Skip to content

RCP-Bench Cooperative Corruption Robustness

Last updated: 2026-05-09

RCP-Bench is a CVPR 2025 benchmark for robustness in collaborative perception under camera corruptions. It is useful because cooperative perception papers often report gains under ideal communication and sensor conditions, while deployed connected vehicles can face weather, camera faults, temporal misalignment, and corrupted collaborator inputs.

Related pages: sensor corruption robustness benchmarks, infrastructure cooperative perception, MultiCorrupt, MSC-Bench, RCooper, V2X-RealO


Scope

ItemDescription
Core taskRobustness evaluation for collaborative 3D object detection.
Base datasetsOPV2V, V2XSet, and DAIR-V2X.
Corrupted datasetsOPV2V-C, V2XSet-C, and DAIR-V2X-C generated from test splits.
Corruptions14 camera corruptions with five severity levels.
Interference scenariosGlobal, ego-only, and CAV-only interference, with six collaborative cases in the paper.
Models evaluated10 leading collaborative perception models according to the paper/repository.
Robustness strategiesRCP-Drop and RCP-Mix.

RCP-Bench focuses on camera corruptions for collaborative perception. It does not cover LiDAR corruptions, communication packet loss in full network detail, cybersecurity attacks, or airport-specific sensor artifacts.


Benchmark Design

RCP-Bench isolates where corruption enters a collaborative perception system:

ScenarioCorrupted sourceOperational meaning
Global interferenceEgo and collaborators are corruptedShared weather, lighting, or widespread camera degradation.
Ego interferenceOnly the ego vehicle is corruptedCollaboration may compensate for a degraded ego view.
CAV interferenceOne or more collaborating vehicles are corruptedCollaboration can become harmful if bad remote features are fused.
Single corruptionOne corruption type at a timeControlled diagnosis.
Multiple / heterogeneous corruptionDifferent corruptions occur together or across agentsCloser to messy real deployments.
New scenes with corruptionCorruption under scene variationTests whether robustness survives distribution shift.

This source isolation is the main value. A model that improves AP under ego-only corruption can still be unsafe if it degrades under corrupted collaborator features.


Sensors, Labels, And Corruptions

FieldDetails
ModalitiesCollaborative perception datasets with camera and 3D detection labels; RCP-Bench corrupts camera inputs.
LabelsOriginal 3D object detection labels from OPV2V, V2XSet, and DAIR-V2X.
External weather corruptionsRain, fog, snow, brightness/darkness, frost.
Camera interior corruptionsCamera crash, Gaussian noise, shot noise, impulse noise, zoom blur, motion blur, defocus blur, color quantization.
Temporal corruptionDesynchronized capture times.
SeverityFive levels per corruption type, yielding 70 corruption conditions per relevant setting.
Dataset creationCorrupted subsets are generated for evaluation from test splits, not used as training data in the repository workflow.

The benchmark uses the same task labels while perturbing inputs, enabling clean-to-corrupt degradation and collaborative compensation/harm to be measured directly.


Metrics

MetricUse
AP_corDetection AP under corrupted conditions.
RCERelative Corruption Error for robustness comparison.
PosCPositive Collaborative Coefficient, measuring beneficial collaboration under corruption.
NegCNegative Collaborative Coefficient, measuring harmful collaboration under corruption.
Clean APRequired reference point; robustness without clean accuracy is incomplete.
Per-corruption APDiagnoses specific failures hidden by aggregate metrics.
Per-scenario APSeparates global, ego, and CAV interference behavior.

For safety review, keep the full per-class, per-corruption, per-severity table. Aggregate robustness can hide a fatal case such as pedestrian recall collapse under CAV temporal misalignment.


Failure Modes Exposed

  • Collaboration can amplify corrupted remote features instead of compensating for them.
  • Global interference can remove the diversity benefit that cooperative perception relies on.
  • Ego-only corruption can make collaboration look strong, while CAV-only corruption reveals trust and gating weaknesses.
  • Attention-based or complex fusion modules may overfit clean collaborative patterns.
  • More cameras and more collaborators improve stability only up to a point and can add noisy inputs.
  • A model may remain strong under image noise but fail under temporal desynchronization.
  • Camera-only corruption does not exercise LiDAR faults, radar faults, pose errors, or network delay in a physically complete way.

AV, Indoor, Outdoor, And Airside Relevance

EnvironmentFitNotes
Public-road V2XStrongDirectly covers DAIR-V2X, OPV2V, and V2XSet-style collaborative perception.
Airport airsideStrong protocol proxyAirport cooperative perception has fixed infrastructure and vehicles, but needs airside sensors and classes.
Indoor multi-robotModerateSource-isolated corruption idea transfers, but camera/fusion setups differ.
Outdoor industrial sitesStrongSimilar fixed infrastructure plus mobile-agent collaboration patterns.
Runtime assuranceStrongUseful for trust gating, collaborator dropout, and degraded-mode policies.

Airports are a natural fit for the RCP-Bench style of evaluation because the operator can control infrastructure sensors and network topology. The missing pieces are airport classes, fixed-camera glare/night artifacts, jet-bridge occlusion, aircraft geometry, and ground-service vehicle behavior.


Validation And Data-Engine Use

  1. Run clean, global, ego-only, and CAV-only evaluations for every cooperative model candidate.
  2. Treat corrupted collaborator harm as a first-class metric; do not only report cases where collaboration helps.
  3. Add trust gating and collaborator health signals to the evaluation log: camera health, timestamp, pose quality, packet age, and confidence.
  4. For airside transfer, clone the scenario structure with stand cameras, apron poles, vehicle cameras, and mobile equipment.
  5. Add airport corruptions: floodlight glare, wet apron reflections, de-icing mist, jet exhaust shimmer, snow piles, dirt on fixed camera housings, and rolling-shutter flicker.
  6. Validate fallback policies: ego-only, infrastructure-only, no-remote-fusion, and stop/slow modes under each corruption.
  7. Keep corrupted data generation out of the final locked test holdout unless the safety case explicitly requires synthetic fault injection.

Sources

Public research notes collected from public sources.