1 Product Overview
This chapter mainly introduces the working principle, specifications, structural description, equipment coordinates and field of view distribution of the AD2-S-X3 LiDAR.
1.1 Product introduction
Bennewake AD2-S-X3 is a high-performance automotive-grade LiDAR product with excellent 3D perception capabilities and can accurately perceive various targets.
The two-dimensional scanning system and array transceiver design adopted by AD2-S-X3 support the continuous upgrade and iteration of product performance, and also meet the needs of intelligent driving systems for continuous optimization and upgrade of perception capabilities. The ultra-high resolution of AD2-S-X3 allows it to achieve high-definition detection capabilities within the entire field of view, leaving sufficient time for the intelligent driving system to make decisions, planning and control, thereby reducing the incidence of traffic accidents and assisting intelligent driving. It assists vehicles in making them safer and smarter.
1.2 Working principle
- The ranging principle is Time of Flight (ToF):
❖The laser transmitter emits an ultrashort laser pulse;
❖The laser is projected onto the object, diffuse reflection occurs, and the laser receiver receives the diffuse reflected light;
❖By measuring the flight time of the laser beam through space, the distance from the target object to the device can be accurately calculated.
d：distance c：speed of light t：flight time of laser beam.
- The principle of angular direction measurement is to use the internal scanning device of the device to deflect the emitted laser beam, trigger the measurement with a regular angular amplitude to scan the surrounding environment, and realize the perception of the three-dimensional environment.
Figure. 1: Schematic diagram of scanning
1.3 Specifications
| Performance parameters | |
| Detection range① | 200m@10% reflectivity |
| Blind zone | ≤1.2m |
| Field of view (H x V) | 120° x 25.6° |
| Angular resolution (H x V) | 0.2° x 0.1° |
| ROI field of view (H x V) | 120 ° x 8° |
| ROI angular resolution (H x V) | 0.1° x 0.1° |
| Ranging precision② | 5cm @1σ |
| Frame rate | 10Hz |
| Point cloud data-rate | 1.536M pts/s (without ROI) 2.016M pts/s (with ROI) |
| Echo mode | Single echo & double echos |
| Equivalent lines | 256 |
| Laser performance | |
| Laser wavelength | 905nm |
| Laser safety level | Class 1 Eye-safe [IEC60825-1：2014] |
| Data transmission | |
| Data interface | 1000Base-T1 automotive grade Ethernet |
| Data transmission protocol | UDP/TCP |
| Time synchronization | gPTP, PTP, NTP |
| Work platform | Windows, Linux (Ubuntu) & ROS drivers |
| Mechanical/Electrical | |
| Power consumption | ≤15W |
| Operating Voltage | 9~32V |
| Operating temperature | -40℃ ~ +85℃ |
| Storage temperature | -40℃ ~ +105℃ |
| Device Dimensions (H x W x D) | 49 x 160 x 144mm |
| Weight | ≤1.2Kg |
| Device interface | TE 2446023-1 |
| Protection level | IP67&IP6K9K |
- The detection range is based on outdoor 100Klux ambient light condition, and any changes in environmental conditions may cause changes in the measurement results.
- The measurement precision is based on the ambient temperature of 25°C and may change due to various factors such as ranging, reflectivity, and environmental conditions.
1.4 Structural Appearance
AD2-S-X3 uses aluminum alloy enclosure and a curved glass window at the front. The overall appearance of the LiDAR is as shown in the figure below:
Figure. 2: AD2-S-X3 Appearance
Figure. 3: AD2-S-X3 view
1.5 Coordinates System and Field of View Distribution
1. Device coordinate system
The coordinate system of AD2-S-X3 is shown in the figure below. The positive direction of the X-axis is the direction of the LiDAR window glass, the positive direction of the Z-axis is perpendicular to the bottom surface and upward, and the positive direction of the Y-axis is parallel to the direction of the rear housing of the device; the XYZ axis constitutes a right-handed coordinate system, and the origin of the LiDAR coordinates is located at the center of the LiDAR window glass. The output point cloud data is based on the LiDAR coordinate origin.
Figure. 4: Schematic diagram of AD2-S-X3 LiDAR coordinate system
2. Horizontal field of view distribution
The horizontal field of view of AD2-S-X3 is 120°, with the positive X-axis direction as the center line, and the left and right sides are 60°. The horizontal field of view angle distribution is shown in the figure below:
Figure. 5: AD2-S-X3 horizontal field of view angle distribution
3. Vertical field of view distribution
The vertical field of view is 25.6°, equivalent to 256 lines, evenly distributed. The specific vertical field of view angle distribution is shown in the figure below:
Figure. 6: Schematic diagram of vertical field of view angle distribution of AD2-S-X3
2 Device Installation
This section introduces the device size, mechanical installation, converter box (optional), connection and other information of AD2-S-X3 LiDAR.
2.1 Equipment size
Figure. 7: Top view (left) & bottom view (right) of the device(unit: mm)
Figure. 8: Front view (left) & side view (right) of the device(unit: mm)
2.2 Mechanical installation
AD2-S-X3 has three M6 installation holes reserved, as shown in the red circle of the following figure. You can fix the device on the working platform through the reserved holes.
Figure. 9: Diagram of AD2-S-X3 installation hole locations
Precautions:
❖Make sure the device is leveled during installation.
❖Confirm whether the device is installed securely and check whether there is any obstruction in front of the window glass.
❖During installation, if any parts are damaged or missing, please contact Benewake technical support team.
2.3 Converter box (optional)
When testing the device, a converter box needs to be used to connect the computer and equipment to complete power supply and data transmission. The converter box is equipped with a standard industrial Ethernet interface and a power interface, and supports 9~32V DC power supply.
Figure. 10: AD2-S-X3 adapter box
Table. 1: Adapter box interface description table
| Interface name | Specification | Definition |
| Power supply interface | DC Jack 2.5mm | 12V power supply |
| Gigabit Ethernet network interface | RJ45 | Device data transfer |
| Vehicle Ethernet data interface | Board connector: 2304372-1 | Device data transfer |
| LiDAR power and signal | Board connector: 2311621-1 | Connect LiDAR |
2.4 Connector
2.4.1 LiDAR terminal connector
Figure. 11: LiDAR connector appearance & interface size
Table. 2: Interface connector pin definitions
| Pin number | Non-vehicle customer | level |
| 1 | VCC12V | 9~32V |
| 2 | NC | — |
| 3 | NC | — |
| 4 | GND | OV |
| 5 | NC | — |
| 6 | NC | — |
| D1 | ETH_MDI-N | — |
| D2 | ETH_MDI-P | — |
2.4.2 Connector plugging and unplugging
❖Plugging: After powering off, insert the red pin on the cable end into the connector lock on the LiDAR end. When you hear a click, the connection is successful.
❖Unplugging: After powering off, slightly pull up the red safety pin, and then press the black bayonet to pull out the wire end connector.
Figure. 12: Connector plugging & unplugging
Precautions:
❖Do not pull out the cable connector with strong force or twist the connector to avoid damage to the connector pins.
❖It is not advised to assemble cable connector shells and cable clamps by the customer.
❖It is prohibited to connect cable connectors without shells to avoid damaging the internal circuit of the LiDAR.
2.4.3 LiDAR connection
An additional Ethernet hybrid harness is required between the LiDAR and the junction box. As shown in the picture below: the left side is the LiDAR end, and the right side is the converter box end.
Figure. 13: Schematic diagram of supporting Ethernet hybrid wiring harness
The connection method between LiDAR, computer and junction box is as shown in the figure below:
Figure. 14: LiDAR connection diagram
3 Device Usage
This chapter mainly introduces the GUI software point cloud viewing and communication protocols of the AD2-S-X3 LiDAR.
3.1 Point cloud viewing
The device does not contain any power switch. Data can be transmitted after the power adapter is connected and connected to the computer via a network cable.
Before receiving data, please check whether the IP address of the computer you are using is in the same network segment as the device; if not, the computer IP needs to be configured. Users can use the Benewake LiDAR Viewer debugging software to record and play back point cloud data. This debugging software has a total of two methods for device connection:
1. If the device IP and port number are known, you can click the Add button to connect to the device.
2. If the device IP and port number are not clear, click the icon to automatically search for the device. Wait for about 5 seconds, and the information of the connected device will be displayed on the device management panel.
Click start button in the device management panel and wait a moment to obtain the point cloud data; click the stop button to stop the LiDAR from working, and the point cloud data will stop updating.
Figure. 15: Connecting device to GUI software
If you want to know more about how to use the Benewake LiDAR Viewer debugging software, you can contact Benewake technical team to obtain the usage instructions of the software.
3.2 Parsing protocol
The LiDAR device and the debugging computer communicate through Ethernet. The interface protocol type is: UDP Server. The communication content is divided into three types: MDOP, DCSP and DSOP. The default factory setting is fixed IP and port number mode. The protocols list is as follows:
Table. 3: Communication protocol table
| Protocol name | Protocol Type | Default IP address | Broadcast type | Description |
| MDOP | UDP | 192.168.0.2 | Unicast | Main Data Communication Protocol |
| DCSP | UDP | 192.168.0.2 | Unicast | Device Command Sets Protocol |
| DSOP | UDP | 192.168.0.2 | Broadcast | Device Status Protocol |
3.2.1 Master Data Communication Protocol (MDOP)
Description:
- Main data communication protocol: MDOP stands for Main Data Output Protocol.
- Mainly responsible for outputting three-dimensional measurement related data: laser ranging values, reflectivity, horizontal azimuth angle, vertical azimuth angle, and timestamp offset relative to the frame header.
- The output data is of I/O type and is transmitted to the debugging computer for analysis and point cloud data is formed.
- In single echo mode, the MAC frame size is 954 Bytes: MAC frame header 42 Bytes, protocol header 42 Bytes, data block 864 Bytes, and frame tail is 6 Bytes. The theoretical data transfer rate is approximately 68.688 Mbps;
- In dual echo mode, the MAC frame size is 906Bytes: MAC frame header 42 Bytes, protocol header 42 Bytes, data block 816 Bytes, and frame tail is 6 Bytes. The theoretical data transfer rate is approximately 130.464 Mbps.
The basic structure of the main data communication protocol is as follows:
Table. 4: Basic structure of master data communication protocol
| Field | Header | Payload | Tail |
| Number of bytes (Bytes) | 42 | N (variable) | 6 |
| Description | Frame header | Load | End of frame |
| Remarks: Ÿ All Reserve bytes are padded with 0x00 Ÿ All multi-byte combination values are transmitted in little-endian mode (that is, the low bit is transmitted first, then the high bit) | |||
a) MDOP header
A total of 42 Bytes, mainly used to identify the data starting position, product version, protocol type, packet count, frame number, etc.; the detailed structure is shown in the table below:
| Field | Offset (Bytes) | Number of bytes (Bytes) | Value | Description |
| SOF | 0 | 2 | “BW”” | Start tag, fixed value |
| Product Identifier | 2 | 1 | 0x01: AD2-S-X3 | Product version |
| Protocol Identifier | 3 | 1 | 0x00: Data transfer protocol MDOP | Protocol type |
| Protocol Version | 4 | 2 | 0x0001 | Protocol version |
| Count | 6 | 4 | 0x0000 | ⚫ Packet count value ⚫ Unsigned integer ⚫ Sequential count value ⚫ Add 1 each time, and start counting from 0 again when overflow occurs |
| nFrame | 10 | 2 | / | ⚫ Frame number ⚫ Unsigned integer ⚫ Sequential count value ⚫ Add 1 each time, and start counting from 0 again when overflow occurs. |
| nLine | 12 | 2 | / | ⚫ Line number (one glow) ⚫ The number of rows of the data block in the payload [one row actually contains 16 channels, nLine starts from 0] |
| Points | 14 | 2 | / | Points in the packet |
| Timestamp_s | 16 | 8 | / | Timestamp – whole second |
| imestamp_ns | 24 | 4 | / | Timestamp – nanoseconds |
| Return mode | 28 | 1 | 0x00: First echo 0x01: Strongest echo 0x02: Last echo 0x03: Double Echo: Strongest + Last 0x04: Double echo: First + Last 0x05: Double Echo: First + Strongest | Echo mode |
| Center Coordinate of ROI-X Direction | 29 | 2 | Non-0xFFFF: Horizontal direction (X direction) ROI area center point coordinates 0xFFFF: ROI function is turned off | The effective center point angle coordinate of the ROI area in the horizontal direction (X direction). It is the integer ten times of actual angle coordinate. E.g. Hex (30 00) = Dec(48), means 4.8° |
| Center Coordinate of ROI-Y Direction | 31 | 2 | Non-0xFFFF: Vertical direction (Y direction) ROI area center point coordinates 0xFFFF: ROI function is turned off | The effective center point angle coordinate of the ROI area in the vertical direction (Y direction). It is the integer ten times of actual angle coordinate. |
| Width of ROI-Region | 33 | 2 | Non-0xFFFF: Valid angle range of horizontal ROI area 0xFFFF: ROI function is turned off | The effective angle range of the horizontal ROI area. It is the integer ten times of actual angle range. |
| Height of ROI-Region | 35 | 2 | Non-0xFFFF: Valid angle range of vertical ROI area 0xFFFF: ROI function is turned off | The effective angle range of the ROI area in the vertical direction. It is the integer ten times of actual angle range. |
| Reserve | 37 | 5 | / | reserve |
Note:
◆Protocol version: Use CRC verification.
◆The number of points in the Points packet: the payload contains data generated by how many times the light is emitted.
◆Description of the data contained in point and payload:
❖A UDP transmission contains a fixed number of data blocks, 4 data blocks for Cartesian coordinates and 12 data blocks for spherical coordinates (the specific format of the data block is described later).
❖For single echo, one light emission produces 1 data block; for double echo, one light emission produces 2 data blocks.
❖For one UDP transmission, for Cartesian coordinates, a single echo can transmit data generated by up to 4 luminescences (points <= 4) each time; Dual echo can transmit data generated by a maximum of 2 luminescences (points <= 2) each time.
❖For one UDP transmission, for spherical coordinates, a single echo can transmit up to 12 luminous data (points <= 12) each time; a double echo can transmit up to 6 luminous data (points <= 6) each time.
❖If the points are less than the maximum number of times of light emission that can be transmitted, the remaining payload is filled with 0.
❖If it is encoder data, it represents the number of data transmission points in this frame. Each point contains 12 bytes, not exceeding 76.
b)MDOP payload
It is the measurement data part in the protocol package. In the single echo mode, there are 864 Bytes in total, which are composed of single-echo data generated by 12 luminescences. The data block size generated by each light emission is 72 Bytes. In dual-echo mode, there are 816 Bytes in total, which are composed of dual-echo data generated by 6 luminescences. The data block size generated by each light emission is 136 Bytes. See the table below for detailed structure:
| Single Luminescence Data | Segmentation | Field | Offset (Bytes) | Number of bytes (Bytes) | Description |
| Share Field | h_azimuth | 0 | 2 | Horizontal azimuth angle: -60° ~ +60°; resolution: 0.2° | |
| v_azimuth | 2 | 2 | Vertical azimuth angle: -12.8° ~ +12.8°; resolution: 0.1° | ||
| time_offset | 4 | 4 | Timestamp offset relative to frame header | ||
| Echo 1 | ch1_distance | 8 | 2 | Channel 1 distance; accuracy: 1cm | |
| ch1_Intensity | 10 | 1 | Channel 1 reflectivity | ||
| ch1_reserved | 11 | 1 | reserved | ||
| ch2_distance | 12 | 2 | Channel 2 distance; accuracy: 1cm | ||
| ch2_Intensity | 14 | 1 | Channel 2 reflectivity | ||
| ch2_reserved | 15 | 1 | reserved | ||
| … | |||||
| ch16_distance | 68 | 2 | Channel 16 distance; accuracy: 1cm | ||
| ch16_Intensity | 70 | 1 | Channel 16 reflectivity | ||
| ch16_reserved | 71 | 1 | reserved | ||
| Echo 2 (Dual echo only) | ch1_distance | 72 | 2 | Channel 1 distance; accuracy: 1cm | |
| ch1_Intensity | 74 | 1 | Channel 1 reflectivity | ||
| ch1_reserved | 75 | 1 | reserved | ||
| ch2_distance | 76 | 2 | Channel 2 distance; accuracy: 1cm | ||
| ch2_Intensity | 78 | 1 | Channel 2 reflectivity | ||
| ch2_reserved | 79 | 1 | reserved | ||
| … | |||||
| ch16_distance | 1332 | 2 | Channel 16 distance; accuracy: 1cm | ||
| ch16_Intensity | 134 | 1 | Channel 16 reflectivity | ||
| ch16_reserved | 135 | 1 | reserved |
c) MDOP frame tail
Frame-tail contains 6 Bytes in total, see the table below for details:
| Field | Offset (Bytes) | Number of bytes (Bytes) | Value | Description |
| Checksum | 0 | 4 | / | HEADER + PAYLOAD verification |
| End Flag | 4 | 2 | 0x00 0xFF | End tag, fixed value |
d) Packaging method
•Single Echo Mode
There are 12 emissions for one UDP packet.
•Dual Echo Mode
There are 6 emissions for one UDP packet.
3.2.2 Device Command Protocol (DCSP)
Description:
•Device Command Protocol: DCSP stands for Device Command Set Protocol.
•Mainly responsible for transmitting different functional instructions (commands) to the LiDAR and enabling it to execute the response protocol. The length of the whole frame is variable, the frame header is fixed to 10 Bytes, the payload length is variable, and the frame tail is fixed to 6 Bytes.
•The output data is of I/O type, and the LiDAR analyzes the command and responds.
The basic structure of the device command protocol is as follows:
| Field | Header | Payload | Tail |
| Number of bytes (Bytes) | 1 0 | N (variable) | 6 |
| Description | Frame header | Load | End of frame |
Remarks:
| |||
A total of 10 Bytes, mainly used to identify the data starting position, product version, DCSP protocol type, etc.; the detailed structure is shown in the following table:
| Field | Offset [Bytes] | Length [Bytes] | Value | Description |
| SOF | 0 | 2 | “BW”” | Start tag, fixed value |
| Product Identifier | 2 | 1 | 0x01: AD2-S-X3 | Product version |
| Protocol Identifier | 3 | 1 | 0x02: DCSP request 0x03: DCSP response | DCSP protocol type |
| Protocol Version | 4 | 2 | 0x0000 | DCSP protocol version |
| Count | 6 | 4 | 0x0000 | Packet count value ⚫ DCSP request: a. Each time a DCSP request is sent, the sequence is incremented by 1, and counting starts from 0 again when overflow occurs. It is an unsigned integer. b. The Count value of the retransmitted packet remains unchanged. ⚫ DCSP response: a. Return the count value in the request package |
b) DCSP payload
It is the command part in the protocol packet, with variable length. It is divided into two types: DCSP request payload and DCSP response payload.
❖DCSP request payload
Mainly responsible for sending specific instructions to LiDAR. The detailed structure is shown in the table below:
| Field | Offset (Bytes) | Number of bytes (Bytes) | Description |
| Request command ID | 0 | 1 | Request opcode |
| Request command data length | 1 | 2 | Requested command length |
| Request command data | 3 | Request command data length | Requested command data |
❖ DCSP response payload
Mainly responsible for transmitting information that the device responds to instructions sent by the computer. There are two types of responses. See the table below for details:
| Response payload—positive response | |||
| Field | Offset (Bytes) | Bytes | Description |
| Response command ID | 2 | 1 | Response opcode: corresponds to the response request |
| Response command data length | 1 | 2 | Response Status length + Response data length |
| Response status | 3 | 2 | 0x00: Will respond, no error |
| Response data | 3 | / | Response data: If the command has response data, return the response data |
| Response payload—negative response | ||||
| Field | Offset (Bytes) | Bytes | value | Description |
| Response command ID | 0 | 1 | Response opcode: corresponds to the response request | |
| Response command data length | 1 | 2 | 2 | Response status length |
| Response status | 3 | 2 | Non-0x00: negative response; its value indicates the error code. For detailed definition, see DCSP error summary | |
❖ DCSP command summary:
| Serial number | Command ID | Command name | Whether to support LiDAR runtime execution | Command description |
| 1 | 0x00 | Get Device Information | yes | Get device information |
| 2 | 0x02 | START/STOP Sampling | yes | Start/stop sampling |
| 3 | 0x07 | Set IP and Port | no | Set IP and service port number |
| 4 | 0x0A | Get Timestamp Format | yes | Get timestamp format |
| 5 | 0x0B | Set Timestamp Format | yes | Set timestamp format |
| 6 | 0x0C | Get LiDAR Mode | yes | Get LiDAR mode |
| 7 | 0x0D | Set LiDAR Mode | yes | Set LiDAR mode |
| 8 | 0x18 | Get MDOP port | yes | Get MDOP port number |
| 9 | 0x20 | Download Firmware | no | Download firmware |
| 10 | 0x73 | Restart | no | Restart |
- DCSP command definition:
- Get Device Information:
| Field | Offset (Bytes) | Length (Bytes) | Value | Description |
| Command ID | 0 | 1 | 0x00 | Get Device information request |
| Data length | 1 | 2 | 0x0000 | Get Device information request data length |
- START/STOP Sampling:
| Field | Offset (Bytes) | Length (Bytes) | Value | Description |
| Command ID | 0 | 1 | 0x02 | START/STOP sampling request |
| Data length | 1 | 2 | 0x0001 | START/STOP sampling request data length |
| Parameter | 3 | 1 | 0x00: Stop 0x01: Start |
- Set IP and Port:
| Field | Offset (Bytes) | Length (Bytes) | Value | Description |
| Command ID | 0 | 1 | 0x07 | Set IP and Port request |
| Data length | 1 | 2 | 0x0018 | Set IP and Port request data length |
| IP | 3 | 4 | ||
| MDOP Port | 7 | 4 | ||
| DSOP Port | 11 | 4 | ||
| DCSP Port | 15 | 4 | ||
| Mask | 19 | 4 | ||
| Gateway | 23 | 4 |
- Get timestamp format:
| Field | Offset (Bytes) | Length (Bytes) | Value | Description |
| Command ID | 0 | 1 | 0x0a | Get timestamp request |
| Data length | 1 | 2 | 0x0000 | Get timestamp request data length |
- Set timestamp format:
| Field | Offset (Bytes) | Length (Bytes) | Value | Description |
| Command ID | 0 | 1 | 0x0b | Set timestamp request |
| Data length | 1 | 2 | 0x0001 | Set timestamp request data length |
| Timestamp format | 3 | 1 | 0x00: No sync source 0x01: PTP (1588V2) 0x02: NTP 0x03: GPS+PPS 0x04: PPS 0x05: gPTP |
- Get LiDAR Mode:
| Field | Offset (Bytes) | Length (Bytes) | Value | Description |
| Command ID | 0 | 1 | 0x0c | Get LiDAR mode request |
| Data length | 1 | 2 | 0x0000 | Get LiDAR mode request data length |
- Set LiDAR Mode:
| Field | Offset (Bytes) | Length (Bytes) | Value | Description |
| Command ID | 0 | 1 | 0x0D | Get LiDAR mode request |
| Data length | 1 | 2 | 0x0001 | Get LiDAR mode request data length |
| Mode | 3 | 1 | 0x00: mode 0 0x01: mode 1 |
- Get MDOP port:
| Field | Offset (Bytes) | Length (Bytes) | Value | Description |
| Command ID | 0 | 1 | 0x18 | get MDOP port request ID |
| Data length | 1 | 2 | 0x0000 | get MDOP port request data length |
- Download firmware:
| Field | Offset (Bytes) | Length (Bytes) | Value | Description |
| Command ID | 0 | 1 | 0x20 | Download firmware request ID |
| Data length | 1 | 2 | 1+4+4+Firmware data length | Download firmware request data length |
| Transfer flag | 3 | 1 | Bit0-First package Bit1-last package Remarks: bit1: When bit0 is 01, it is the first package bit1: When bit0 is 10, it is the last package | Transfer mark |
| Sum bytes of firmware | 4 | 4 | The total length of the Bin file | |
| Package count | 8 | 4 | Send download packet count, starting from 0 | |
| Firmware data | 12 | N | The length n cannot exceed the limit length of a single UDP packet. (Default 1024) | |
| Remarks: 1. In cyclic packet sending, each request corresponds to a response, the transfer flag bit0 of the first request is 1, and the transfer flag bit1 of the last request is 1; 2. Firmware and FPGA files are temporarily downloaded uniformly through this command; 3. If the Host Computer GUI does not receive the response from the firmware within 500ms, the Host Computer GUI needs to resend the request, in which all data in the request will not be modified. A total of 3 attempts. If all three communication attempts fail, it will fail. | ||||
- Restart:
| Field | Offset (Bytes) | Length (Bytes) | Value | Description |
| Command ID | 0 | 1 | 0x73 | Restart request |
| Data length | 1 | 2 | 0x0000 | Restart request data length |
c) DCSP frame tail: 6 Bytes in total
| Field | Offset (Bytes) | Length (Bytes) | Value | Description |
| Command ID | 0 | 4 | / | HEADER + PAYLOAD verification |
| Data length | 4 | 2 | 0x00 0xFF | End tag, fixed value |
3.2.3 Device Status Protocol (DSOP)
Description:
- This protocol is used to transmit the status of the device.
- The length is 90 Bytes, the frame header is fixed at 52 Bytes, the payload is at a fixed length of 32 Bytes, and the frame tail is at a fixed length of 6 Bytes.
- The output data type is I/O type, and the debugging computer analyzes it.
The basic structure of the device status protocol is as follows:
| Field | Header | Payload | Tail |
| Length (Bytes) | 52 | 32 | 6 |
| Description | Frame header | Load | End of frame |
Remarks: All reserve bytes are padded with 0x00 | |||
a) DSOP header
A total of 52 Bytes, mainly used to identify product version, DSOP protocol type, protocol version, LiDAR SN number, protocol port number and other information; the detailed structure is shown in the table below:
| Field | Offset (Bytes) | Length (Bytes) | Value | Description |
| SOF | 0 | 2 | “BW” | Start mark, fixed value, ‘B’ is sent first, then ‘W’ |
| Product Identifier | 2 | 1 | 0x01: AD2-S-X3 | Product version |
| Protocol Identifier | 3 | 1 | 0x01: DSOP | Protocol type |
| Protocol Version | 4 | 2 | 0x0000 | Protocol version |
| SN | 6 | 32 | / | Device SN number |
| DCSP_port | 38 | 2 | / | Protocol port number |
| Timestamp | 40 | 8 | / | Time-stamp |
| Count | 48 | 4 | / | The count value is incremented by 1 at a time, and counting starts again from 0 when overflow occurs. |
b) DSOP payload
A total of 32 Bytes, which is the device status data part in the DSOP protocol package. The detailed structure is shown in the following table:
| Field | Offset (Bytes) | Length (Bytes) | Description |
| DSOP_content_type | 0 | 1 | 0: Universal heartbeat frame interval 1s |
| monitor_status_info | 1 | 12 | Monitor status information |
| sys_status_info | 13 | 4 | System status information |
| eth_status_info | 17 | 1+n*port | Ethernet status information |
| DTC_info | 17+1+n*port | / | DTC information |
| DID_info | 20+X | max 369 | Version information |
| DSOP_content_type | 0 | 1 | 1: Functional safety frame interval 100ms |
| functional_safety_info | 1 | 14 | Functional safety information |
c) DSOP frame tail
There are 6 Bytes in total, see the table below for details:
| Field | Offset (Bytes) | Length (Bytes) | Description | Field |
| Checksum | 0 | 4 | / | HEADER + PAYLOAD verification |
| End flag | 4 | 2 | 0x00 0xFF | End tag, fixed value |
4 Device Maintenance
This section introduces the device storage, transportation, cleaning and other information of AD2-S-X3.
4.1 Device storage
- It is recommended to use the original packaging provided by Benewake for storage.
- Please store the device in an environment of -40℃ ~ +105℃, relative humidity ≤ 60%, ensure the ventilation and no corrosive gases, and avoid exposure to direct sunlight.
- When storing, please avoid contact with corrosive substances, such as acids, alkalis, oils and other solutions, and keep away from all heat sources.
- If the storage time exceeds three months, please perform a working test on the device before use to ensure that the it can be used under normal conditions.
- Please regularly check the status of all components and packaging of the device.
4.2 Device transportation
- During transportation, loading and unloading, please handle it with care and avoid collisions and severe mechanical impacts to avoid damage or direction deviation of the optical components inside the device.
- Please follow the instructions on the packaging during device transportation and loading, and pay attention to moisture.
- During transportation, do not place the device in an unstable place and avoid incorrect handling to prevent the damage and personal injury.
- During transportation, please avoid contact with corrosive substances, such as acids, alkalis, oils and other solutions.
Leave a comment
You must be logged in to post a comment.