Custom lidar sensor vendor searches often begin with a feature list: smaller, wider view, a different cable, or a preferred host interface. That is not yet a buildable request. A vendor can only evaluate it responsibly when the buyer also states the real scene, the mechanical boundary, the data handoff, and the evidence that will decide whether a sample fits.
This guide is for UAV and robotics teams that need to turn a sensing use case into a reviewable customization brief before they request an evaluation sample. It does not promise that every request is feasible or that a listed product has an unlisted option. It gives the buyer a better way to ask, compare, and test.
| Quick answer | Send a custom LiDAR vendor an application envelope—not only desired specifications. Define the scene, mounting boundary, data contract, test targets, and acceptance record before asking for a sample or modification. |
|---|---|
| Best fit | Technical buyers evaluating a compact dToF module for a UAV payload, robot, or embedded perception prototype. |
| Decision rule | If the request cannot identify the required view, target, host, and measurable pass/fail evidence, keep it as a discovery task rather than calling it a custom specification. |
A custom LiDAR request begins with a configuration boundary
“Custom” can describe very different work: an evaluation around existing published hardware, a mechanical fit question, a cable or host-side requirement, or a larger engineering change. Treating all of those as the same request creates a predictable problem: a supplier receives a wish list while the systems team has not agreed what must be physically seen, how the output will be consumed, or what evidence would prove success.
Start by separating four boundaries. The scene boundary describes targets, distances, angles, light, motion, and occlusion. The mechanical boundary states the available volume, optical window, mount datum, cable route, thermal context, vibration context, and service access. The data boundary names the host, interface, units, frame, timestamps, invalid-data behaviour, and logging need. The evidence boundary says which representative tests must pass before the project uses the configuration.
This matters because direct time-of-flight behaviour is not reduced to one headline number. A 2025 primary SPAD dToF performance study analyzes how optical flux, pulse width, timing quantization, and detector dead-time effects influence ranging precision. That paper is not a result for Purpleriver hardware. It is a useful reason to document the application conditions rather than infer installed performance from a single range field.
Custom LiDAR sensor vendor decision chart
| Question to settle | Evidence to send | What a vendor can evaluate | Do not assume |
|---|---|---|---|
| What must the sensor observe? | Annotated view sketch, target dimensions, distance band, angles, occluders, lighting, and motion envelope | Whether the proposed view and test plan are meaningful | That a maximum range proves target visibility or control margin |
| Where can it fit? | Optical-center datum, volume envelope, bracket drawing, window stack, cable path, and service clearances | Mechanical integration questions and sample-fixture needs | That a compact module automatically fits after the connector and cable are included |
| What output is usable? | Host OS/hardware, transport preference, depth/point-cloud/event need, rate target, and recording requirement | Which documented interface path should be evaluated | That an interface name proves a native driver, message mapping, or controller compatibility |
| How will the team decide? | Target matrix, raw-data capture plan, acceptance criteria, test owner, and change log | Whether the sample test answers the business question | That a single demo image is an acceptance result |
| What is fixed versus exploratory? | A list tagged “published baseline,” “required,” “preferred,” or “open question” | Where a configuration discussion can begin without silently changing requirements | That an unlisted feature, certification, delivery date, or custom parameter exists |
Published MRP-LD1 parameters: use them as the baseline, not an inference
Purpleriver’s current WooCommerce Featured product is the MRP-LD1 Drone LiDAR Sensor. For a team considering it during a customization discussion, the exported product fields below are the factual starting point. They are not a promise of unlisted configuration options, installed performance, protocol implementation, or suitability for a particular system.
| Published parameter | MRP-LD1 value | Question for the configuration brief |
|---|---|---|
| Ranging/scanning principle | dToF with SPAD | Which target conditions and response evidence matter in the intended scene? |
| Emitter | 940 nm VCSEL | What window, mount, and optical-path assumptions need review? |
| Listed range | Indoor 0.5–25 m; outdoor 0.2–8 m | What part of this envelope is actually required for the defined targets? |
| Field of view | 60° horizontal × 45° vertical | Does the installed geometry leave a blind wedge or self-occlusion? |
| Output / rate | 40 × 30 at 10 fps | Which downstream output is needed, and what target persistence is acceptable? |
| Interfaces | UART, UVC, UDP | Which path will be tested with the actual host and recorded data? |
| Software support | Windows, ARM, Linux, Android | What exact host version, API, data format, and integration responsibility are required? |
| Electrical / mass | 5 V, 1.2 W, 8 g | Do power quality, connector, cable, bracket, and complete payload mass fit the design? |
| Operating temperature | −20°C to 60°C | Which complete-assembly environmental conditions must be tested? |
The listing also describes laser safety as Class 1. A buyer should still keep the device-level listing distinct from the risk assessment, safety architecture, and compliance evidence required for the complete UAV, robot, or workcell.
Six steps to build a customization brief engineering can test
1. Describe one real scene before proposing a product change
Choose a representative job, not a generic market. For example: a low-mounted forward payload must observe pallet edges in a loading lane, or a compact UAV must measure terrain beneath a protected payload bay. State the target material, minimum dimensions, relative approach, usable distance band, lighting transitions, and motion. Include the failure that matters: missed target, unstable depth, nuisance event, late data, or an unusable log.
2. Draw the mechanical boundary from the optical datum outward
Give the vendor a reference point for the proposed optical center, then show the allowed volume and the parts around it: bracket, enclosure lip, window, harness bend, cooling path, landing gear, robot body, or service tool. A body outline is more helpful than “space is tight.” It lets both sides identify self-occlusion and cable conflicts before a sample arrives.
3. Convert requirements into four evidence labels
Mark every line in the brief as one of these: published baseline (a documented product field), required (the project cannot proceed without it), preferred (a tradeoff is possible), or open question (it needs confirmation or a trial). This small distinction prevents a preference from being silently treated as a capability, and prevents a missing fact from becoming a purchase commitment.
Use the existing LiDAR module sample checklist as a companion when the team is ready to turn the boundary into an evaluation request.
4. Specify the application data contract
State whether the host needs a depth image, point cloud, derived event, or recorded raw stream. Then record the sensor frame, host frame, units, timestamp origin, target ordering, confidence or invalid-value treatment, and the owner of each transform. The official ROS REP-103 standard documents shared units and coordinate conventions; those concepts are useful even where a project does not use ROS. The request should name its convention rather than make the integration team guess it.
5. Name the transport proof, not just the transport
MRP-LD1 lists UART, UVC, and UDP. Select the path that the project can actually bring up, record, recover, and support. For UVC, request the negotiated format, payload definition, valid data region, host-side test conditions, and stream-recovery behaviour. The official USB-IF Video Class v1.5 document set describes a class transport; it does not by itself define a project’s depth interpretation, point layout, or application behaviour. For wider transport tradeoffs, see Purpleriver’s UART, UVC, or UDP interface guide.
6. Freeze acceptance evidence before the sample is judged
Create a small test matrix using the final target types, distances, angles, mount position, lighting cases, host version, and data path. Save raw observations before filters or downstream logic make them look cleaner. Each row needs an owner, a pass rule, a result, and the hardware/firmware/software versions used. This is what turns a promising demonstration into a result that can be rerun after a bracket, host, or firmware change.
Interface, data, and integration questions a vendor brief must not hide
Integration ambiguity is often more expensive than the sensor choice. A package can list a physical interface yet leave open who converts its output, which data fields are valid, whether a timestamp represents acquisition or host receipt, and what happens if a stream is late or interrupted. Keep those questions visible.
| Handoff item | Question to record | Evidence to request or create |
|---|---|---|
| Host boundary | Which exact computer, operating system, and application receives data? | Versioned host description and a reproducible bring-up record |
| Frame and units | Where is the optical frame, how is it related to the vehicle/robot frame, and what units apply? | Mount datum, transform ownership, and a simple annotated sketch |
| Payload meaning | What values are depth, point coordinates, confidence, invalid samples, or metadata? | Current protocol documentation plus one labeled capture |
| Time | Which clock creates a timestamp, and when is the measurement considered current? | Timestamp definition and a controlled delay/dropout test |
| Recovery | How is loss detected, who restarts it, and what should the host do with stale data? | Recorded interruption/recovery procedure and project-owned response rule |
| Change control | Which hardware, firmware, calibration, driver, and configuration versions were tested? | A test record that can be compared after a change |
If the team is deciding which representation it can process, the depth map versus point cloud guide can help frame the choice. It does not remove the need to verify the actual data contract for the selected evaluation setup.
Illustrative case: a protected UAV payload bay
Illustrative engineering scenario, not a customer result: a systems team is considering a compact dToF module for a small inspection UAV that must observe a defined near-field corridor while its payload sits inside a protected bay. The first email asks for “a wider view, custom cable, and Linux support.”
The team rewrites the request. It adds a side and underside drawing with the proposed optical-center datum, a window outline, landing-gear occlusion, cable bend space, a distance band, representative target panels, and the intended host. It labels MRP-LD1’s 60° × 45° field of view and UART/UVC/UDP as published baselines, while calling wider coverage, cable arrangement, and host data mapping open questions.
For the sample plan, the team records raw data at the defined target positions, with the final window and bracket installed. It tests its selected host path, writes down the timestamp interpretation, and repeats the same cases after a bracket adjustment. If the data is insufficient, the result is an evidence-backed mismatch—not a claim that an unlisted capability should exist. That outcome still saves the project from integrating around an assumption.
Common mistakes when contacting a custom LiDAR sensor vendor
- Sending only a desired range and field of view. Target angle, material, occlusion, lighting, motion, and host-side use still determine whether the result is useful.
- Calling every preference “required.” Separate published baseline, required, preferred, and open questions so tradeoffs are visible.
- Measuring enclosure dimensions but not the optical datum. The useful view is determined by the installed optical geometry, not by a sketch of the housing alone.
- Using an interface label as a data contract. UART, UVC, or UDP does not answer payload meaning, version, timestamps, invalid data, recovery, or host ownership.
- Assuming a platform name proves a driver. Ask for the actual documentation, data format, and integration responsibility; do not infer native ROS or controller support.
- Testing only one clean reference target. Use representative target sizes, materials, angles, lighting, window, mount, and motion states.
- Tuning filters before storing raw evidence. Otherwise the team cannot tell whether a target was not measured or was removed downstream.
- Requesting a safety conclusion from a component demo. Keep listed device facts separate from the complete system’s risk assessment and safety design.
- Skipping version control. A bracket, firmware, calibration, host, or parameter update can invalidate an earlier sample result.
RFQ checklist: make the request answerable
Before asking a vendor to quote, modify, or sample a LiDAR configuration, attach these items:
- one-sentence application decision and the failure that matters;
- target matrix: size, material, reflectivity where relevant, distance, angle, speed, lighting, and occlusion;
- mounting drawings with optical datum, allowed volume, bracket, window, cable route, service access, and complete payload constraints;
- published baseline fields kept separate from required, preferred, and open questions;
- host computer, operating system, selected UART/UVC/UDP path, power context, data representation, recording requirement, and recovery need;
- units, frame convention, timestamp semantics, payload interpretation, invalid-data treatment, and transform ownership;
- sample-data, firmware, protocol, API, and version documentation requested through the available documentation resources;
- acceptance matrix with raw-capture requirement, pass rule, owner, evidence storage location, and change-control trigger; and
- a clear list of questions the supplier must confirm rather than assumptions the buyer has made.
Bring a Testable Application Brief to Your LiDAR Discussion
Share the target scene, mounting boundary, host path, required output, and acceptance evidence with your inquiry. Purpleriver can help compare those questions against the MRP-LD1’s published parameters and identify what should be confirmed during an evaluation.
