Service Robot Risk Assessment: What to Verify in Supplier Documentation
A supplier’s risk assessment is not a compliance certificate—it is a living document describing how hazards were identified, mitigated and verified for a specific hardware revision. For service robots, this includes physical interaction points such as bumpers, cliff sensors and emergency stop logic. Buyers must read these assessments not as endorsements, but as engineering narratives: do they name test methods, define failure modes, and reference actual measurements taken on production-representative units? The how we build and test page outlines our internal validation gates, but your due diligence begins where those gates end.
Cliff Sensor Validation Is Not Just About Detection
Cliff sensors must respond reliably across surface reflectivity, ambient light and tilt angle—not just on black carpet or in lab lighting. A compliant assessment documents test surfaces (e.g., matte black tile, polished granite), minimum detection distance at 5° and 10° incline, and whether firmware applies hysteresis to prevent false triggering. It should also state whether the sensor output feeds directly into motion control or requires software interpretation—a latency gap here can compromise pedestrian safety. For models like the U1 humanoid robot platform, multi-sensor fusion (LiDAR + time-of-flight + edge detection) is documented per revision, not assumed.
Bumper Stops Must Prevent Contact, Not Just Respond to It
A functional bumper is not defined by its presence, but by its integration into the robot’s reactive behaviour tree. The assessment must specify the maximum allowable contact force (in newtons), the time-to-halt from nominal speed, and whether mechanical deformation is part of the safety path. If the bumper signal only interrupts motor power without initiating reverse motion or audible alert, it fails basic pedestrian safety expectations. This applies equally to the K1 AI companion robot and industrial-grade service units—age grading on packaging determines toy scope, not operational context.
Emergency Behaviour Requires Explicit State Mapping
“Emergency stop” is meaningless without defined states: what constitutes an emergency (e.g., sustained bumper pressure >2 seconds, loss of cliff sensor feedback for >150 ms, thermal shutdown), what action follows (immediate brake, safe hold, audible cue, wireless alert), and how recovery is initiated (manual reset only, or auto-resume after timeout). The assessment must map each trigger to a state transition diagram—not just list features. This is covered in our CE RED document checklist, adapted for service robot scope.
Documentation Must Match Hardware Revision—Not Just Model Name
A risk assessment dated before final PCB layout or motor driver firmware is obsolete. Look for references to board version (e.g., “Main PCB Rev C2”), firmware hash, and LiDAR module part number. If the document cites EN 62368-1 but omits class 1 laser statement for the embedded LiDAR, it is incomplete. Likewise, battery UN38.3 testing must match the exact cell batch and pack configuration shipped—not a generic summary. All documentation is supplied per model and hardware revision, as detailed in our factory process overview.
| Checklist Item | What Evidence to Request | Where It Should Appear |
|---|---|---|
| Cliff sensor response curve | Test report showing detection distance vs. surface albedo (0.05–0.9) | Risk assessment appendix or EMC test summary |
| Bumper force threshold | Calibrated load-cell measurement at full speed, with deceleration graph | Hardware safety section of risk assessment |
| Emergency state transitions | State machine diagram with timing annotations and recovery conditions | Firmware architecture annex |
| LiDAR laser classification | Class 1 statement signed by accredited lab, referencing module datasheet | Safety compliance summary |
| Firmware version traceability | Hash or build ID matching test unit, not “latest stable” | Test report header and risk assessment revision log |
| Battery UN38.3 scope | Test summary naming exact cell model, pack voltage, watt-hour rating | UN38.3 report and SDS, shipped with order |
- Verify the risk assessment references a specific hardware revision—not just “v2.0” or “current model”
- Confirm cliff sensor tests were performed on low-reflectivity surfaces under variable lighting
- Check that bumper force thresholds are measured dynamically, not estimated from spring constants
- Ensure emergency stop logic is mapped to discrete states—not described as “automatic safety response”
- Validate that LiDAR classification matches the exact module used, not a generic datasheet
- Compare firmware version in test report against the one quoted in your MOQ, sampling and lead times schedule
A robust risk assessment reflects engineering discipline—not marketing convenience. When reviewing submissions for service robots, treat every claim as provisional until backed by revision-specific test evidence. WingPhoenix supplies documentation per hardware revision, including CE RED (EN 300 328, EN 301 489, EN 62368-1), FCC Part 15 B/C, RoHS 3 and REACH SVHC screening—all available for review before order placement. To begin verification, request the latest risk assessment package for your target model from the AI robots line, cross-reference it against the OEM/ODM services scope, and schedule a joint review with our compliance team using the product catalogue as your baseline.
Questions buyers ask
Why can’t I rely on a supplier’s claim that their robot “meets safety standards”?
Claims without test reports tied to a specific hardware revision are unverifiable. For service robots, EN 62368-1 and EMC scope must cover the full operating configuration—not just static components—and cliff sensor response must be validated under real lighting and surface conditions.
How do I know if the bumper stop is properly integrated into the control logic?
Check whether the risk assessment documents the force threshold, deceleration time and mechanical redundancy. A bumper that triggers only after impact does not meet pedestrian safety expectations—it must initiate avoidance before contact.
Related: more on ai robots · buyer guides · customisation tiers