-
Notifications
You must be signed in to change notification settings - Fork 82
Livox SDK Communication Protocol HAP(English)
Release History | ||
---|---|---|
Date | Version | Description |
20220519 | v1.0 | 1. Initialized version |
20220530 | v1.1 | 1. Merge status and parameter key_value information fields2. The information push command supports pushing LiDAR parameter information and status information |
20220602 | v1.2 | 1. Add log related commands |
20220622 | v1.3 | 1. Port 56000 only supports discovery command by broadcasting. Discovery command by broadcasting ack adds the control command port field of the current LiDAR |
20220628 | v1.4 | 1. Update working status description |
20220629 | v1.4.1 | 1. Add firmware type to key value list
|
20220914 | v1.4.2 | 1. Add the status_code |
20230113 | v1.4.3 | 1. Update 0x0300 command data info |
20230310 | v1.4.4 | update the parameters saving setting to flash clearly |
20230331 | v1.4.5 | 1.Modify the key value supported by the radar push message 0x0102 2.Add glass heating key value 3.Add log conifg key value |
20230803 | v1.4.6 | 1.Modify the key 0x800D value introduction: Lidar Error Status Code Description. For Firmware version V15.05.01.15 and V15.05.01.08, the Lidar Error Status Code Description changed and show in different link page. 2. Add the relation description of glass_heat_support and Lidar Dirty/Blocked Fault Detection Function. Lidar Dirty/Blocked Fault Detection Function need to switch on the configuration of key 0x001B(glass_heat_support) |
20231214 | v1.4.7 | 1. Update Chapter 3.1 Frame Format of "seq_num" attribute's description. |
20240218 | v1.4.8 | 1. Add the new key-value-list item: 0x0020. This setting used to control lidar to automatically display point cloud after power-on/reboot. |
[TOC]
There are two types of data protocols between the user and the LiDAR, see as below:
Point cloud data protocol:
-
Point cloud data;
-
IMU data.
For details, see 2.3 Data Types.
Control command protocol:
-
Configure and query LiDAR parameters;
-
LiDAR reset;
-
Push and query LiDAR status;
-
Upgrade LiDAR;
For details, see 4 CMD Detials
Both protocols are encapsulated using UDP data segments, and the protocol data is Little-endian.
state machine
- For SELFCHECK, it takes at most 5s ; For MOTORSTARUP, it takes at most 10s;
- The dotted line state(SELFCHECK, MOTORSTARUP, MOTORSTOP, ERROR) is the target state that the user cannot actively set;
- The dotted arrow is the logic automatically convert by the LiDAR according to the external control conditions, external environment and internal actual working conditions;
- In any state except ERROR state, if an error is detected, LiDAR will automatically switch to the ERROR state;
- In any state except SLEEP state, if user request to enter the SLEEP state is received and the sleep conditions are met, the SLEEP state is entered;
- After the user sends an upgrade request, the LiDAR automatically jumps to the UPGRADE state (not shown in the figure);
- The LiDAR state is specifically defined as follows:
LiDAR Status | Enumeration Value | Description |
---|---|---|
SAMPLING | 0x01 | The LiDAR sends point cloud & IMU data in this state(if it support the IMU function then IMU data could be sent out) |
IDLE | 0x02 | LiDAR is idle, waiting for user action |
SLEEP | 0x03 | HAP(TX) type does not support this state, only HAP(T1) type supports this state; After the user requests the LiDAR to enter the SLEEP state, the LiDAR detects whether the network is disconnected or not. If disconnected, the LiDAR cuts off the main power supply of LiDAR and enters to the SLEEP state ( Only keep the LiDAR Ethernet PHY active to detect Ethernet wake-up signals) |
ERROR | 0x04 | If LiDAR detects error, then automatically switch to this state |
SELFCHECK | 0x05 | When powered on, the LiDAR automatically enters this state to perform self-test activity. If there is any error detected, LiDAR will automatically switch to ERROR state, otherwise it will switch to IDLE state |
MOTORSTARUP | 0x06 | When the LiDAR is in IDLE state, if the user requests SAMPLING state, the LiDAR will first enter this state to start the motor. When the motor speed is stable, the LiDAR automatically switches to SAMPLING state |
MOTORSTOP | 0x07 | When the LiDAR is in SAMPLING state, if the user requests IDLE state, the LiDAR will first enter this state to stop the motor. When the motor stops running, the LiDAR automatically switches to IDLE state |
UPGRADE | 0x08 | When the user requests an upgrade, the LiDAR state automatically switches to this state |
The source port and destination port are explained as follows according to the different data types:
Data Type | Transmission Direction | LiDAR Port | Host Computer Port | Transmission Type | Transmission Protocol |
---|---|---|---|---|---|
Device Type Query | LiDAR <---> Host Computer | 56000 | Any | Broadcast | UDP |
LiDAR Information Control Command |
LiDAR <---> Host Computer | 56000 | any | Unicast | UDP |
Point Cloud Data | LiDAR ---> Host Computer | 57000 | 57000(setting enable with 0x0100 command) | Default is unicast and support multicast setting | UDP |
IMU Data | LiDAR ---> Host Computer | 58000 | 58000(setting enable with 0x0100 command) | Default is unicast and support multicast setting | UDP |
LOG Data | LiDAR <---> Host Computer | 59000 | 59000(#0x0100-Parameter-Configuration) | Unicast | UDP |
Note:
- 56000 is used as the fixed listening port of Livox LiDAR, mainly used for the host computer to query the device through broadcast. Only the device type query command (cmd_id: 0x0000) is supported. The host computer obtains the specific device type of the LiDAR through this port. This command response is replied by broadcast, so that when the host computer and the LiDAR IP are not in the same net, the host computer can still identify the LiDAR
- For Command Data , if no destination IP address and port setting, LiDAR will use the source IP address inside the command request message from host computer as the destination IP address and port and use for futher message sending. For these Point Cloud & IMU Data and Log Data, the Command data destination IP address will be used and the default destination port will be used as info in above table.
Point cloud data format:
Fields | Offset (bytes) | Size (bytes) | Description |
---|---|---|---|
version | 0 | 1 | Package protocol version: currently 0. |
length | 1 | 2 | The length of the entire UDP data segment starting from version . |
time_interval | 3 | 2 | Intra-frame point cloud sampling time (Unit: 0.1us); In this frame of point cloud data, the time of the last point minus the time of the first point. Note: for IMU data, this field is 0 |
dot_num | 5 | 2 | The current UDP packet data field contains the number of points. |
udp_cnt | 7 | 2 | Point cloud UDP packet count, each UDP packet is incremented by 1 in turn, and cleared to 0 at the beginning of the point cloud frame. |
frame_cnt | 9 | 1 | Note: HAP LiDAR keeps 0 for this field |
data_type | 10 | 1 | Data type. For details, see 2.3 Data Types. |
time_type | 11 | 1 | Timestamp type. For details, see 2.2 Timestamp. |
pack_info | 12 | 1 | Bit0-1: safety_info. 0: the whole package is trusted; 1: the whole package is not trusted; 2: the non-zero point is trusted; Bit2-3: tag type. Point cloud tag type.for HAP this field is 0 Bit4-7: reserved. |
reserved | 13 | 11 | Reserved. |
crc32 | 24 | 4 | Timestamp + data segment check code, using CRC-32 algorithm. For details, see CRC Algorithm. |
timestamp | 28 | 8 | Point cloud timestamp. For details, see 2.2 Timestamp. |
data | 36 | -- | Data information. For details, see 2.3 Data Types. |
Note:
The HAP T1 type does not support IMU function, and HAP Tx type supports IMU function.
The LiDAR system supports gPTP network protocol synchronization.
The timestamp in each packet represents the time of the first point cloud, and there are "dot_num" point clouds in each packet. The time of these "dot_num" point clouds is equally spaced, and the total time interval is the value of time_interval
.
Timestamp type:
Timestamp Type | Sync Source Type | Data Format | Description |
---|---|---|---|
0 | No synchronization source, the timestamp is based on the time of the LiDAR is power on | uint64_t | Unit: ns |
1 | gPTP synchronization, the time of master clock source as a timestamp | uint64_t | Unit: ns |
Data Type | Value | Echo Mode | Coordinate Mode | N | Data Frequency |
---|---|---|---|---|---|
IMU Data | 0 | 1 | 200kHz | ||
Point Cloud Data1 | 1 | Single Return Mode | Cartesian Coordinate(32bit) | 96 | 452kHz |
Point Cloud Data2 | 2 | Single Return Mode | Cartesian Coordinate(16bit) | 96 | 452kHz |
IMU Data (each imu data with 24bytes):
Field | Offset (bytes) | Data Type | Description |
---|---|---|---|
gyro_x | 0 | float | Unit: rad/s |
gyro_y | 4 | float | Unit: rad/s |
gyro_z | 8 | float | Unit: rad/s |
acc_x | 12 | float | Unit: g |
acc_y | 16 | float | Unit: g |
acc_z | 20 | float | Unit: g |
Point Cloud Data1(each point data with 14bytes):
Field | Offset (bytes) | Data Type | Description |
---|---|---|---|
x | 0 | int32_t | X axis, unit: mm |
y | 4 | int32_t | X axis, unit: mm |
z | 8 | int32_t | Z axis, unit: mm |
Reflectivity | 12 | uint8_t | Reflectivity |
Tag Information | 13 | uint8_t | According to the point cloud frame header pack_info.tag_type field, match the specific tag type. For details, see 2.4 Tag Information. |
Point Cloud Data2(each point data with 8bytes):
Field | Offset (bytes) | Data Type | Description |
---|---|---|---|
x | 0 | int16_t | X axis, unit: 10mm |
y | 2 | int16_t | Y axis, unit: 10mm |
z | 4 | int16_t | Z axis, unit: 10mm |
Reflectivity | 6 | uint8_t | Reflectivity |
Tag Information | 7 | uint8_t | According to the point cloud frame header pack_info.tag_type field, match the specific tag type. For details, see 2.4 Tag Information. |
Note:
- There are "dot_num" samples in each data package.
- The default data type of Point Cloud Data is Point Cloud Data1.
tag_type | Description |
---|---|
0 | bit 6-7: reserved bit 4-5: Point attributes based on other categories: (not used in HAP LiDAR) 00: High confidence (normal point) 01: Medium confidence 10: Low confidence 11: Very low confidence bit 2-3: Point attribute based on energy intensity: 00: High confidence (normal point) 01: Medium confidence 10: Low confidence 11: Very low confidence bit 0-1: Point attributes based on spatial location: 00: High confidence (normal point) 01: Medium confidence 10: Low confidence 11: Very low confidence |
Field | Offset(byte) | Size (byte) | Description |
---|---|---|---|
sof | 0 | 1 | Starting byte, fixed to be 0xAA. |
version | 1 | 1 | Protocol version, 0 for current version. |
length | 2 | 2 | Length of frame; The number of bytes from beginning of sof to end of entire data segment. Max value: 1400. |
seq_num | 4 | 4 | This field is incremented by 1 in LiDAR side for each new REQ request message; This field range is 0~65535; This field of ACK message is the same as REQ and can be used for message matching. |
cmd_id | 8 | 2 | Different types of messages are distinguished by this field, For details, see 3.2 CMD ID |
cmd_type | 10 | 1 | Command Type: 0x00: REQ, actively send data request; 0x01: ACK, response to REQ data. |
sender_type | 11 | 1 | The sender's device type: 0x00: Host computer, 0x01: LiDAR. |
resv | 12 | 6 | Reserved. |
crc16 | 18 | 2 | Frame header checksum, check data starts from sof to crc16 (not included), 18 bytes in total. For details, see CRC Algorithm |
crc32 | 20 | 4 | Frame data checksum. For details, see CRC Algorithm |
data | 24 | n | see 4 CMD Detials. |
Function Type | CMD ID | Function |
---|---|---|
Device Type Query | 0x0000 | LiDAR Discovery by broadcasting message from Host Computer |
LiDAR Information | 0x0100 | Parameter Configuration Setting from Host Computer |
0x0101 | Parameter Information Query from Host Computer | |
0x0102 | LiDAR Information Push to Host Computer | |
Control CMD | 0x0200 | Request reboot LiDAR from Host Computer |
Log CMD | 0x0300 | Log file Push to Host Computer |
Log CMD | 0x0301 | Start/Stop Log file Push to Host Computer |
General Upgrade CMD | 0x0400 | Request to start upgrade |
0x0401 | Firmware data transfer | |
0x0402 | Firmware transfer complete | |
0x0403 | Get firmware upgrade status | |
Request
CMD | Name | Offset(byte) | Data Type | Description |
---|---|---|---|---|
data | NULL |
ACK
ACK | Name | Offset(byte) | Data Type | Description |
---|---|---|---|---|
data | ret_code | 0 | uint8_t | Return code (For details, see Return Code |
dev_type | 1 | uint8_t | LiDAR type | |
serial_number | 2 | uint8_t[16] | LiDAR SN | |
lidar_ip | 18 | uint8_t[4] | LiDAR IP address E.g: AA.BB.CC.DD lidar_ip[0] = AA lidar_ip[1] = BB lidar_ip[2] = CC lidar_ip[3] = DD |
|
cmd_port | 22 | uint16_t | LiDAR command port HAP is 56000(fixed port) |
Request
CMD | Name | Offset(byte) | Data Type | Description |
---|---|---|---|---|
data | key_num | 0 | uint16_t | Number of key in key_value_list
|
rsvd | 2 | uint16_t | Reserved | |
key_value_list | 4 | key_value_list[N] | see key value list format |
ACK
ACK | Name | Offset(byte) | Data Type | Description |
---|---|---|---|---|
data | ret_code | 0 | uint8_t | Return code (For details, see Return Code ) |
error_key | 1 | uint16_t | If the ret_code is not LVX_RET_SUCCESS , the error_key shows the first error Key label |
Request
CMD | Name | Offset(byte) | Data Type | Description |
---|---|---|---|---|
data | key_num | 0 | uint16_t | Number of key label values in key_list
|
rsvd | 2 | uint16_t | ||
key_list | 4 | -- | Key label value list |
The key type in the key_list
:
Data | Name | Offset(byte) | Data Type |
---|---|---|---|
key | 0 | uint16_t | Key label value |
ACK
ACK | Name | Offset(byte) | Data Type | Description |
---|---|---|---|---|
data | ret_code | 0 | uint8_t | Return Code (For details, see Return Code ) |
key_num | 1 | uint16_t | Number of key in key_value_list
|
|
key_value_list | 3 | -- | see [key_value_list] (#key-value-list) |
LiDAR push Actively
CMD | Name | Offset(byte) | Data Type | Description |
---|---|---|---|---|
data | key_num | 0 | uint16_t | Number of key in key_value_list
|
rsvd | 2 | uint16_t | ||
key_value_list | 4 | -- | see [key_value_list] (#key-value-list) |
The HAP pushes the following information every second:
-
0x0000
-
0x0001
-
0x0003
-
0x0004
-
0x0006
-
0x0007
-
0x0012
-
0x0013
-
0x001A
-
0x001B
-
0x001C
-
0x001D
-
0x001E
-
0x0020
-
0x8000
-
0x8001
-
0x8002
-
0x8003
-
0x8004
-
0x8005
-
0x8006
-
0x800D
-
0x800E
-
0x800F
-
0x8010
-
0x8012
Format of each parameter in key_value_list
is as follows:
Data Field | Offset(byte) | Data Type | Description |
---|---|---|---|
key | 0 | uint16_t | Key label value |
length | 2 | uint16_t | Length of Key data value |
value | 4 | -- | Key data value |
Specific meanings to key_value_list
are as follows:
Label(key) | Name | Length | Type | Content | Whether the following commands are supported |
---|---|---|---|---|---|
0x0000 | pcl_data_type | 1 | uint8_t | Type of point cloud data, For details, see2.3 Data Types: 0x01: Cartesian coordinate(32bits) 0x02: Cartesian coordinate(16bits) Note: This value is not allowed to be set during sampling. Parameters will not be saved to LiDAR flash, immediately active after setting. The default value 0x01 |
0x100: Y 0x101: Y 0x102: N |
0x0001 | pattern_mode | 1 | uint8_t | Pattern mode: 0x00: Non-repetitive scan 0x01: Repetitive scan Note: Parameters will be saved to LiDAR flash, active after LiDAR reboot. the default value is 0x00 |
0x100: Y 0x101: Y 0x102: N |
0x0003 | point_send_en | 1 | uint8_t | Point cloud send enable 0x00:Send point cloud in working mode; 0x01:Do not send point cloud in working mode Note: Parameters will not be saved to LiDAR flash, immediately active after setting. The default value 0x00 |
0x100: Y 0x101: Y 0x102: N |
0x0004 | lidar_ipcfg | 12 | uint8_t[12] | LiDAR IP address configuration LiDAR IP address: AA.BB.CC.DD data[0]: AA data[1]: BB data[2]: CC data[3]: DD IPV4 subnet mask data[4-7] IPV4 gateway data[8-11] Note: 1.Parameters will be saved to LiDAR flash, active after LiDAR reboot. the default IP value is 192.168.1.100 2. IP address and net mask and gateway setting should follow IPv4 protocol. |
0x100: Y 0x101: Y 0x102: N |
0x0006 | pointcloud_host_ipcfg | 8 | uint8_t[8] | Setting lidar point clouds message sending out destination IP address and destination port. data[0-3]Destination IP address: AA.BB.CC.DD data[4-5]Destination port data[6-7]Source port Note: 1. The setting destination IP address and ports parameters will not be saved to LiDAR flash, immediately active after setting. 2. Point clouds data and Imu data use the same destination IP address, so after this IP address setting, IMU data will also be sent to this IP address. 3. Destiny port setting is supported set and query. Source Port setting is supported query function. The HAP point cloud data source port is fixed at 57000 4.If the destination IP address is not set, the LiDar will default to using the IP address of the upper computer that controls command interaction as the destination IP address for point cloud push, see Destination IP address automatically setting algorithm. 5. IP address should be follow the IPv4 protocol,IP cannot be set to 0.0.0.0 or 255.255.255.255. |
0x100: Y 0x101: Y 0x102: N |
0x0007 | imu_host_ipcfg | 8 | . uint8_t[8] | Configure the remote IP address for pushing LiDAR IMU data. The same configuration constraints as "pointcloud_host_ipcfg". data[0-3] point cloud data destination IP address: AA.BB.CC.DD data[4-5] push message destination port data[6-7] push message source port Note: 1. The set IP will not be saved in flash. If you need to specify an IP address, you need to configure it every time you power on. 2. The IP address for point cloud data push is also It will be updated to this address 3.Destiny port setting is supported set and query. Source Port setting is supported query function. the IMU port is fixed at 58000 4. If the destination IP address is not set, the radar will default to using the IP address of the upper computer that controls command interaction as the destination IP address for point cloud push. 5. IP cannot be set to 0.0 .0.0 or 255.255.255.255 |
0x100: Y 0x101: Y 0x102: N |
0x0009 | log_host_ipcfg | 8 | uint8_t[8] | IP address configuration for LiDar push log data data[0-3]Log data destination IP address:AA.BB.CC.DD data[4-5]Log data destination port data[6-7]Log data source port Note: 1. The set IP will not be saved to flash. If you need to specify an IP address, it needs to be configured every time you power on 2. The destination IP and destination port can be set. After setting, the LiDar will prioritize pushing 0x0300 logs to this port, and the data source port setting will not take effect. The default log source port for HAP LiDar is 59000. |
0x100: Y 0x101: Y 0x102: N |
0x0012 | install_attitude | 24 | Installation location of LiDAR on the user's system(extrinsic parameters calibration). Lidar just save this parameters inside flash and not use them. This paramete will be saved to LiDAR flash and read out by Host Computer to use. Format: { float roll_deg; float pitch_deg; float yaw_deg; int x_mm; int y_mm; int z_mm; } |
0x100: Y 0x101: Y 0x102: N |
|
0x0013 | blind_spot_set | 4 | uint32_t | Blind spot set(uint: cm) Note: 1. The range is 50-200cm, default is 50cm. 2. This paramete will be saved to LiDAR flash, immediately active after setting. 3. It is not recommended to set this value in SAMPLING state. |
0x100: Y 0x101: Y 0x102: N |
0x001A | work_tgt_mode | 1 | uint8_t | setting the LiDAR's target working mode, For details, see1.2 LiDAR Working Status | 0x100: Y 0x101: Y 0x102: N |
0x001B | glass_heat_support | 1 | uint8_t | Glass heating enable option: 0: Disable glass heating function 1: Enable glass heating function Note: The switch will be stored in Flash Note: 1. This configuration is the global configuration used to control the window glass heating function. After this configuration enable, lidar will response to force_heat_en function to heat the window. 2. Lidar window dirty/blocked fault detection function depend on this glass_heat_support configuration. Lidar window dirty/blocked fault detection function work only after this configuration set to 1. |
0x100: Y 0x101: Y 0x102: N |
0x001C | imu_data_en | 1 | uint8_t | 0x00: Disable IMU data push 0x01: Enable IMU data push Note: For HAP Tx type, the default value is 0x01. For HAP T1 type, the parameter is invalid . This paramete will not be saved to LiDAR flash, immediately active after setting. |
0x100: Y 0x101: Y 0x102: N |
0X001D | fusa_en | 1 | uint8_t | 0x00: Disable fusa diagnostic function0x01: Enable fusa diagnostic functionNote: This parameter will be saved to LiDAR flash, active after LiDAR reboot. The default value is 0x00. |
0x100: Y 0x101: Y 0x102: N |
0X001E | force_heat_en | 1 | uint8_t | 0: Turn off forced heating 1: Turn on forced heating Note:1.The window heating function needs to be turned on first 2.Currently powered on and valid 3.The maximum duration of a single heating can only be 3 minutes, otherwise the window heating mode will automatically exit 4.Heating will not occur in an error state |
0x100: Y 0x101: Y 0x102: N |
0X0020 | workmode_after_boot | 1 | uint8_t | This setting used to control lidar to automatically display point cloud after power-on/reboot. value refer to see1.2 LiDAR Working Status. 0: default value, IDLE 1: SAMPLING 2: IDLE Note: This parameter will be saved to LiDAR flash, active after LiDAR reboot. The default value is 0x00. |
0x100: Y 0x101: Y 0x102: N |
0x8000 | sn | 16 | uint8_t[16] | String type(Use '\0' padding for less than 16 bytes) LiDAR SN(Use '\0' padding for less than 16 bits) |
0x100: Y 0x101: Y 0x102: N |
0x8001 | product_info | 64 | char[64] | String type(Use '\0' padding for less than 64 bytes) LiDAR type + LiDAR production date E.g: "HAP 1990/01/25" |
0x100: N 0x101: Y 0x102: N |
0x8002 | version_app | 4 | uint8_t[4] | App firmware version number: aa.bb.cc.dd version_info[0]: aa version_info[1]: bb version_info[2]: cc version_info[3]: dd |
0x100: N 0x101: Y 0x102: N |
0x8003 | version_loader | 4 | uint8_t[4] | Loader firmware version number: aa.bb.cc.dd version_info[0]: aa version_info[1]: bb version_info[2]: cc version_info[3]: dd |
0x100: N 0x101: Y 0x102: N |
0x8004 | version_hardware | 4 | uint8_t[4] | Hardware version number: aa.bb.cc.dd version_info[0]: aa version_info[1]: bb version_info[2]: cc version_info[3]: dd |
0x100: N 0x101: Y 0x102: N |
0x8005 | mac | 6 | uint8_t[6] | LiDAR MAC address: aa:bb:cc:dd:ee:ff data[0]: aa data[1]: bb data[2]: cc data[3]: dd data[4]: ee data[5]: ff |
0x100: N 0x101: Y 0x102: N |
0x8006 | cur_work_state | 1 | uint8_t | Current working state of LiDAR, For details, see1.2 LiDAR Working Status | 0x100: N 0x101: Y 0x102: Y |
0x800D | status_code | 32 | uint8_t[32] | Each of the bit corresponds an abnormal: 0= no error 1= error For detail information, please see Firmware V15.05.01.15 HAP LiDAR status code description Firmware V15.05.01.08 HAP LiDAR status code description |
|
0x800E | lidar_diag_status | 2 | uint16_t | LiDAR diag status code: bit[0-3]: system module bit[4-7]: Scan module bit8-11: Ranging module bit12-15: Communication module The status of xx module is defined as below: 0: normal 1: warning 2: error 3: safety_err 4-7: resv |
0x100: N 0x101: Y 0x102: Y |
0x800F | lidar_flash_status | 1 | uint8_t | Flash status: 0: idle 1: busy Note: Before requesting reboot or power off the LiDAR, please make sure that the FLASH is not in the busy state, otherwise it may cause data loss. |
0x100: N 0x101: Y 0x102: Y |
0x8010 | fw_tpye | 1 | uint8_t | Firmware type: 0= loader 1= app1 2= app2 |
0x100: N 0x101: Y 0x102: N |
0x8012 | cur_glass_heat_state | 1 | uint8_t | current glass heating state 0:unheated 1:heating |
0x100: N 0x101: Y 0x102: N |
Request
CMD | Name | Offset (byte) | Data Type | Description |
---|---|---|---|---|
data | time_delay | 0 | uint16_t | reboot time delay, the uint is ms the range is 100ms~2000ms |
ACK
ACK | Name | Offset (byte) | Data Type | Description |
---|---|---|---|---|
data | ret_code | 0 | uint8_t | return code: (For details, see Return Code ) |
Request: Lidar
CMD | Name | Offset (byte) | Data Type | Description |
---|---|---|---|---|
data | log_type | 0 | uint8_t | Log type: 0 : real-time log 1 : exception log |
file_index | 1 | uint8_t | File index | |
rsvd | 2 | uint8_t | ||
flag | 3 | uint8_t | bit 0: 1: need to return an ACK message bit 1: 1: create a new log file bit 2: 1: end file flag for current log file Note: The ack bit will be set when the LiDAR sends the create file message, log configuration header information message, and end file flag message and the host computer should send the ACK message to LiDAR. |
|
timestamp | 4 | uint32_t | Unix timestamp representing the number of seconds elapsed since January 1, 1970 00:00:00. When the host computer creates a log file, the log file is named by the following format. log\_<log_type_name>\_<file_index>\_<system_time>.dat E.g: log_fully_log_1_20220613203140.dat <system_time> is the system time after timestamp conversion. If the timestamp returned by the LiDAR is 0, the host computer does not convert the timestamp , and directly uses the host computer system time. |
|
rsvd | 8 | uint16_t | ||
trans_index | 10 | uint32_t | Transfer index number | |
log_data_len | 14 | uint16_t | Log data length | |
log_data | 16 | -- | Log data: need to append to the end of the log file sequencely |
ACK: HOST
ACK | Name | Offset (byte) | Data Type | Description |
---|---|---|---|---|
data | ret_code | 0 | uint8_t | return code: (For details, see Return Code ) |
log_type | 1 | uint8_t | ||
file_index | 2 | uint8_t | ||
trans_index | 3 | uint32_t |
CMD | Name | Offset (byte) | Data Type | Description |
---|---|---|---|---|
data | log_type | 0 | uint8_t | Log type: 0 : real time log |
enable | 1 | uint8_t | 0:close log 1:open log |
ACK
ACK | Name | Offset (byte) | Data Type | Description |
---|---|---|---|---|
data | ret_code | 0 | uint8_t | return code: (For details, see Return Code ) |
Request
CMD | Name | Offset (byte) | Data Type | Description |
---|---|---|---|---|
data | firmware_type | 0 | uint8_t | Firmware type: 0: Package firmware 1: LiDAR firmware 2: Other firmware Note: For HAP, this field is reserved. |
encrypt_type | 1 | uint8_t | Encrypt type: 0: None encrypt 1: AES128 2: AES256 3: DES 4: 3DES |
|
firmware_length | 2 | uint32_t | Firmware length | |
dev_type | 6 | uint8_t | Device type 10: HAP |
ACK
ACK | Name | Offset (byte) | Data Type | Description |
---|---|---|---|---|
data | ret_code | 0 | uint8_t | return code: (For details, see Return Code ) |
Request
CMD | Name | Offset (byte) | Data Type | Description |
---|---|---|---|---|
data | firmware_offset | 0 | uint32_t | |
current_length | 4 | uint32_t | ||
encrypt_type | 8 | uint8_t | ||
rsvd | 9 | uint8_t[3] | ||
data | 12 | uint8_t[n] | firmware data |
ACK
ACK | Name | Offset (byte) | Data Type | Description |
---|---|---|---|---|
data | ret_code | 0 | uint8_t | return code: (For details, see Return Code ) |
current_offset | 1 | uint32_t | ||
received_length | 5 | uint32_t |
Request
CMD | Name | Offset (byte) | Data Type | Description |
---|---|---|---|---|
data | checksum_type | 0 | uint8_t | |
checksum_length | 1 | uint8_t | ||
checksum_data | 2 | uint8_t[n] |
ACK
ACK | Name | Offset (byte) | Data Type | Description |
---|---|---|---|---|
data | ret_code | 0 | uint8_t | return code: (For details, see Return Code ) |
Request
CMD | Name | Offset (byte) | Data Type | Description |
---|---|---|---|---|
data | NULL | |||
ACK
ACK | Name | Offset (byte) | Data Type | Description |
---|---|---|---|---|
data | ret_code | 0 | uint8_t | return code: (For details, see Return Code ) |
upgrade_progress | 1 | uint8_t | upgrade progress: 0 ~ 100% |
- Check whether the LiDAR network cable is connected and the supply power (12V DC) to the LiDAR is ok;
- The host computer sends a discovery command message by broadcasting to obtain the LiDAR IP address and control command port number and other information. It is used for the following message communication;
- The parameters configuration to the LiDAR must be set before the LiDAR enters the SAMPLING state. If the configuaration parameters saved to the flash of the Lidar and active after LiDAR reboot(such as LiDAR IP /scanning mode configuration), reboot the LiDAR after configuration, and then query whether the relevant parameters have taken effect after reboot;
- The host computer configures the
work_tgt_mode
to 0x01 (SAMPLING state) through the 0x0100 command to enable the LiDAR sampling; - The host computer obtains point cloud data & IMU data;
- The host computer configures the
work_tgt_mode
to 0x02 (IDLE state) through the 0x0100 command to stop the LiDAR sampling; - Before reboot or powering off the LiDAR, you need to query the LiDAR
lidar_flash_status
. If the LiDAR 'lidar_flash_status' is in busy state, you need to wait until thelidar_flash_status
is in idle state to avoid the flash corrupted.
Name | Return Code | Description |
---|---|---|
LVX_RET_SUCCESS | 0x00 | Execution succeed |
LVX_RET_FAILURE | 0x01 | Execution failed |
LVX_RET_NOT_PERMIT_NOW | 0x02 | Current state does not support |
LVX_RET_OUT_OF_RANGE | 0x03 | Setting value out of range |
LVX_RET_PARAM_NOTSUPPORT | 0x20 | The parameter is not supported |
LVX_RET_PARAM_REBOOT_EFFECT | 0x21 | Parameters need to reboot to take effect |
LVX_RET_PARAM_RD_ONLY | 0x22 | The parameter is read-only and cannot be written |
LVX_RET_PARAM_INVALID_LEN | 0x23 | The request parameter length is wrong, or the ack packet exceeds the maximum length |
LVX_RET_PARAM_KEY_NUM_ERR | 0x24 | Parameter key_ num and key_ list mismatch |
LVX_RET_UPGRADE_PUB_KEY_ERROR | 0x30 | Public key signature verification error |
LVX_RET_UPGRADE_DIGEST_ERROR | 0x31 | Digest check error |
LVX_RET_UPGRADE_FW_TYPE_ERROR | 0x32 | Firmware type mismatch |
LVX_RET_UPGRADE_FW_OUT_OF_RANGE | 0x33 | Firmware length out of range |
CRC Name | Polynomial Formula | Width | Polynomial | Initial Value | Result XOR value | Input Reverse | Output Reverse |
---|---|---|---|---|---|---|---|
CRC-16/CCITT-FALSE | x^16^ + x^12^ + x^5^ + 1 | 16 | 0x1021 | 0xFFFF | 0x0000 | false | false |
CRC-32 | x^32^ + x^26^ + x^23^ + x^22^ + x^16^ + x^12^ + x^11^ + x^10^ + x^8^ + x^7^ + x^5^ + x^4^ + x^2^ + x + 1 | 32 | 0x04C11DB7 | 0xFFFFFFFF | 0xFFFFFFFF | true | true |