--- title: "Sensor Fusion Annotation: LiDAR + Camera + Radar | YPAI" url: https://ypai.ai/annotation/sensor-fusion-annotation-services/ description: "Multi-modal annotation across LiDAR, camera, radar, IMU and thermal. Calibration-verified cross-modal consistency, PTP-synced delivery, EEA processing." source: "src/copy/routes (route /annotation/sensor-fusion-annotation-services/)" --- # Sensor fusion annotation, time-synced across modalities. > Multi-modal annotation across LiDAR, camera, radar, IMU and thermal. Calibration-verified cross-modal consistency, PTP-synced delivery, EEA processing. Multi-modal annotation with calibration-verified cross-modality consistency. Single 3D label projects to every camera, every radar return, every thermal frame. ## A 3D label is only useful if it lands on every sensor. - Separate per-sensor jobs can look complete and still disagree in the fused frame. - YPAI draws one object in the primary sensor and projects it through verified extrinsics onto every secondary stream. The annotator confirms the landing before the label is closed. Twenty objects across seven classes, with occlusion and truncation recorded. Extent, class and identity are all a single camera can give. Depth comes from the sensors below. ### Camera - The cuboid lands on the pixels that actually belong to the object, including truncated and night frames. ### Radar - The same identity carries Doppler velocity where radar is in the stack. ### Thermal - The silhouette holds when RGB fails. Heat-only classes stay available when the taxonomy needs them. PTP time base across the recording ### LiDAR ### Camera ### Radar Illustrative readout. The engagement sets the primary sensor, the projection policy and the drift threshold the delivery must report. ## The stack you buy is the stack you can train. Paying for isolated LiDAR boxes and isolated camera boxes is the expensive way to discover they do not occupy the same object. ### LiDAR ### Camera ### Radar ### IMU + GPS ### Thermal ### LiDAR + camera - Geometry from LiDAR, class and attributes from camera. One 3D box is projected into every camera view through verified extrinsics. - LiDAR cuboid, camera as semantic corrector - Projection error when extrinsics drift, truncation, and night RGB - 3D boxes with camera-view projections, class, and occlusion state - ADAS perception baselines, robotics scene understanding ### LiDAR + camera + radar - The same identity also carries Doppler velocity. Radar keeps the object when rain, spray or darkness take the camera down. - LiDAR geometry, radar velocity, camera class - Associating sparse radar returns to the cuboid without splitting identity - Fused cuboid, velocity, and per-sensor visibility flags - Production AD perception beyond a camera-only stack ### LiDAR + IMU + GPS - Point clouds are labelled in a trajectory that stays georeferenced. The map and the object share one coordinate frame. - LiDAR in a SLAM or GNSS-stabilised world frame - Keeping landmarks and dynamic objects distinct as the trajectory drifts - Georeferenced clouds, trajectory, landmarks, LAS / LAZ where required ### Camera + thermal - RGB and long-wave thermal share one identity. When the camera goes dark, the thermal silhouette is still a labelled object. - Thermal silhouette with RGB class when light allows - Calibration across very different resolutions and the hot-spot taxonomy - Paired boxes or masks, thermal-only classes where the schema needs them - Night automotive, search and rescue, perimeter perception ### Multi-camera array - Identity continues as the object leaves one camera and enters the next. The handoff is a labelled event, not a new object. - Shared identity across a time-synced camera ring - Handoff at overlapping FOV edges and appearance change between cameras - Per-camera boxes plus a cross-camera identity manifest - Surround perception, multi-camera surveillance, sports capture ## The same fused scene answers four different questions. Per-sensor annotation cannot settle a disagreement between streams. Fusion-aligned labels can. ### Automotive AD / ADAS ### Robotics and AMR ### Surveillance ### Surveying and mapping ### Perception that must survive weather and night. - Vehicle, pedestrian, cyclist and lane labels share one identity across LiDAR, camera and radar. Taxonomy can follow nuScenes or Waymo schemas when the engagement asks for that alignment. ### A robot needs the obstacle and the grasp in the same frame. - LiDAR + camera + IMU for indoor and outdoor SLAM. Dynamic people, navigable floor and graspable objects are labelled against one trajectory. ### Identity has to survive a camera handoff at night. - Multi-camera plus thermal. Cross-camera re-identification is a labelled event. Day and night coverage share the same person ID. - The same calibrated multi-sensor stack extends to ### The map is only useful if the cloud is georeferenced. - LiDAR + IMU + GPS + camera. Delivery can include LAS / LAZ and a georeferencing check. BIM-ready when the engagement specifies it. ## Production starts after calibration holds. Schema, projection policy and a shared subset all serve one decision: is the multi-sensor contract stable enough to scale? ### Schema and multi-sensor calibration - Class taxonomy is locked. Per-sensor intrinsics, pairwise extrinsics and PTP timestamps are verified before anyone draws a production label. ### Guideline and projection policy - Visibility rules per sensor. Which stream is primary for each class, and which stream is allowed to correct it. ### Calibration round - A shared subset is labelled in the fused viewer. Cross-modal agreement and projection error are measured. The guideline is revised on what the round actually found. - Cross-modal agreement record and revision decisions. ### The gate - Production starts when the calibration round clears the task-specific projection and agreement thresholds in the acceptance plan. - The gate is a recorded decision. Drift after this point is reported. - Signed record that the gate was cleared. ### Production in the fused viewer - One 3D label in the primary sensor, projected to every secondary. The annotator validates the landing. Work runs in the proprietary fused viewer; tenant isolation is specified per project in the security annex. ### QA, cross-modal audit and delivery - Per-class scores per modality, projection-error report, time-sync drift audit, Article 30 records and a signed DPA. ## The evidence package is defined before production. These records travel with the labels. They are specified in the statement of work, not assembled afterwards. ### Multi-sensor calibration verification - Intrinsic and extrinsic checks per sensor, plus a PTP drift report across the recording. ### Cross-modal projection consistency - The 3D box projected to every camera, radar return and thermal frame. Per-class projection error. Velocity delta where radar is present. ### Per-modality and cross-modality metrics - Per-class scores on each stream, identity preservation across sensor handoff, and a distance breakdown when the task needs it. ### Time-sync drift audit - Frame-pair correspondence, interpolation policy for mismatched rates, and threshold flags. ### Processing and delivery record - Article 30 records, signed DPA, lawful-basis documentation, 30-day erasure terms, and the sub-processor list. ### EU AI Act Article 10 - Annotation provenance per sensor, sampling notes, and known limitations for high-risk perception systems. ### GDPR Articles 7, 9 and 28 - Per-contributor consent. Biometric category handling where camera data identifies persons. Processor agreement. ### EEA processing - Norwegian company, EEA processing by default, EEA-only sourcing on request. Norwegian jurisdiction. Transfer controls defined per project. ## Bring the sensor mix, the calibration state and the acceptance problem. - A short brief is enough to start. - YPAI will identify the projection policy, the open ontology decisions and the first calibration step. The reply lists the questions to resolve before a pilot or production scope. We reply inside one EU business day with the questions that must be resolved before a pilot or production scope. - evidence-package proposal, schedule and price basis ## What calibration data do you need across the sensors? Per-sensor intrinsics, pairwise extrinsics, and PTP-synchronised timestamps with sub-millisecond skew. Calibration is verified before annotation. Drift is checked across the recording and reported at delivery. ## How do you handle disagreement between sensors? A documented projection policy decides which sensor is primary for each class. Annotators validate the projection before the label is finalised. Remaining disagreement is recorded in the delivery report. ## Do you handle thermal and multi-spectral? Yes. Long-wave thermal, near-infrared and multi-spectral bands from drone or satellite capture. Calibration is verified across those modalities. The taxonomy can include thermal-only classes such as hot-spot. ## Where is the data processed? Norwegian company, EEA processing by default, EEA-only sourcing on request. 30-day GDPR Article 17 erasure SLA. Norwegian jurisdiction. Transfer controls defined per project. ## What output formats do you deliver? nuScenes JSON, KITTI-360, AV2 SDK, and custom Protocol Buffers when the engagement specifies them. Per-modality files plus a cross-modal manifest. Time-aligned multi-sensor packages. ## Can public corpora be used as taxonomy references? Yes, when the engagement asks for alignment with corpora such as nuScenes, Waymo Open, Argoverse 2, A2D2 or KITTI-360. Production work runs against your own streams under the engagement DPA. Public corpus licences are checked per project. Brief the sensor mix. The reply names the projection policy and the first gate. ## Answers that belong in the first conversation.