To make a 3D-perception-based obstacle-avoidance workflow suitable for safety-critical robots, treat the SDK as just one component in a safety case—not as the thing that “makes it safe.” Compliance usually depends on your system design, process, validation, and runtime safety architecture, not only on the SDK itself.

Here’s a practical checklist.

1) Identify the safety standard(s) that apply

Choose based on the robot type and environment:

• Industrial robots / mobile robots: ISO 10218, ISO 13849-1/-2, IEC 62061
• AMRs/AGVs: ISO 3691-4
• Collaborative robots: ISO/TS 15066
• Functional safety process: IEC 61508
• Autonomous systems / general robotics: often a mix of the above plus company-specific safety requirements

Define:

• Hazards
• Safety goals
• Required Performance Level / SIL
• Operating envelopes and assumptions

2) Don’t rely on perception alone for safety

A 3D perception SDK can be non-safety-rated unless explicitly certified. Use it for:

• Situational awareness
• Advisory obstacle detection
• Path planning input

But for safety-critical stopping/avoidance, use independent safety functions, such as:

• Safety laser scanners
• Safety-rated depth sensors or safety PLC inputs
• Redundant sensors with diverse modalities
• Hardware E-stops and safe torque off (STO)

A good rule:
Perception can inform motion; safety functions must be able to stop motion independently.

3) Build a layered safety architecture

Use a layered design:

• Layer 1: Perception — SDK outputs obstacles/occupancy
• Layer 2: Planning — computes safe trajectories with conservative margins
• Layer 3: Safety monitor — checks speed, distance, braking distance, sensor health
• Layer 4: Safety controller — can override and bring robot to a safe state
• Layer 5: Actuator safety — STO, brake control, safe stop, emergency stop

Key idea: the perception stack should fail “benignly,” and the safety layer should remain effective even if perception is wrong.

4) Define the safety assumptions explicitly

Write down:

• Minimum detectable obstacle size
• Required detection range
• Maximum robot speed
• Reaction time budget
• Braking distance
• Environmental limits:
  • lighting
  • dust/fog/smoke
  • reflective surfaces
  • occlusions
  • sensor vibration
• Sensor placement constraints
• Calibration and alignment requirements

If the SDK performance depends on assumptions, those assumptions must become enforced operational limits.

5) Treat false negatives as the critical risk

For obstacle avoidance, the most dangerous failure is:

• obstacle not detected
• obstacle detected too late
• obstacle position estimated too optimistically

Mitigations:

• Add conservative safety margins
• Inflate obstacles in planning
• Use worst-case latency for braking calculations
• Cap speed based on sensor confidence and range
• Fail safe on degraded confidence or invalid data

6) Validate timing end-to-end

Safety-critical robotics is often about latency + distance.

Measure:

• sensor frame time
• SDK processing latency
• message transport latency
• planner update rate
• controller response time
• actuator deceleration behavior

Then prove:

• The robot can stop before entering the hazard zone
• Worst-case latency is within the safety budget
• The system still meets requirements under load

7) Establish sensor health monitoring

Your workflow should detect:

• dropped frames
• calibration drift
• timestamp errors
• point cloud corruption
• out-of-range values
• temperature/overheating
• hardware disconnection

On fault:

• degrade to slower mode, or
• stop motion, or
• hand over to a safer fallback sensor

8) Verify and validate with safety cases

You need documented evidence:

• requirements traceability
• hazard analysis
• FMEA/FMEDA or similar
• simulation testing
• hardware-in-the-loop testing
• field testing in representative conditions
• regression tests for perception edge cases

Include adversarial scenarios:

• low reflectivity
• glass/transparency
• narrow poles/wires
• partial occlusion
• crowded scenes
• rapid obstacle emergence

9) Manage software integrity and configuration

Safety compliance usually requires controlled changes:

• version pinning for SDK and model files
• checksum/signature verification
• reproducible builds
• change impact analysis
• calibration file management
• logging and audit trails

If ML is used, document:

• training data scope
• known failure modes
• out-of-distribution behavior
• retraining governance

10) Use a fail-safe operating mode

Define what happens if perception is uncertain:

• slow down
• widen safety buffer
• stop and request intervention
• switch to a simpler certified sensor
• limit mission autonomy

A compliant system is usually one that degrades safely, not one that keeps operating at full speed.

A simple compliance mindset

Ask these three questions:

1. Can the robot detect obstacles reliably enough for nominal operation?
2. Can a separate safety layer stop the robot if perception fails?
3. Do you have test evidence that both work under worst-case conditions?

If the answer to any is “no,” the system is not ready for safety-critical use.

Recommended implementation pattern

For safety-critical deployment, a common pattern is:

• Use the 3D perception SDK for navigation and avoidance hints
• Use a safety-rated stop mechanism for emergency intervention
• Compute speed limits from distance-to-obstacle
• Add confidence and health gates
• Force safe stop on uncertain or invalid perception
• Maintain formal documentation and test evidence

Important caveat

If you need actual compliance for a regulated product, you should involve:

• a functional safety engineer
• a certification body / notified body
• your robot OEM / integrator
• legal/regulatory experts for your market

A software SDK alone generally cannot be assumed safety-compliant unless the vendor explicitly provides safety certification artifacts.

If you want, I can help you turn this into a safety compliance checklist, a hazard analysis template, or a reference architecture for obstacle avoidance with safety fallback.