Continuing from the previous article, this part mainly introduces lidar data and other content. This can be said to be the most important thing to understand the lidar manual, which is the key to key issues (skin~). Also because the velodyne manual is difficult to read but the content is complete and rich, we will continue to explain the velodyne 128 (alpha prime) in this issue, and the second part will explain the contents of other lidar manuals.
Students who have not seen the first issue can click:
Contents of this article
4.1 packet type and definition
4.3 Calculation of precise time
4.4 Convert PCAP file to point cloud file
7. Configuration of multi-tooth lidar access
8. Comparison with other lidars
Appendix: LiDAR physical photos:
4. Lidar data (data)
The sensor has its own frame in its own coordinate system. The origin (0,0,0) of the lidar is 66.11mm on its base. The establishment and calculation of the coordinate system is as shown in the figure below (it should be noted that the xyz axis may be in different Different sensors have different definitions of forward direction, some are positive x and some are positive z)
4.1 packet type and definition
Next is the most important packet analysis : There are two types of packets: data packets and position packets. Position packets are sometimes called telemetry packets, or GPS packets. The former contains the three-dimensional data measured by the sensor and the calibrated reflectivity of the surface on which the light pulse is returned. The former also contains of azimuths and a 4-byte timestamp , as well as two factory bytes (Factory Byte) that identify the sensor model and laser return mode . If you have configured the sensor to synchronize with a GPS time source, the position packet will provide a copy of the last NMEA message (GPRMC or GPGGA) received . The location packet also provides a byte to identify the status of the PPS status signal and the time source synchronization (such as locked, abent, etc.) .
Specifically including:
1. Laser firing sequence
A firing sequence occurs when all lasers in the sensor are fired. They are launched in sequences specific to a given product line or model. Includes laser recharge time. A point emission sequence is not allowed to span multiple packets . On average, it takes 55.275µs to fire and charge all 128 lasers. The lidar is divided into eight groups to emit laser light (that is, each group has 16).
2. Laser channel (laser channel)
One laser channel is a 905 nm laser transmitter and receiver. Each channel has a specific installation elevation angle ( so the elevation angle of each point is fixed, only the corresponding horizontal angle is given in the packet, and there is no elevation angle data ). Usually we say how many lines , that is, how many channels there are, and each channel has an ID. The laser pattern is like this:
From the above figure, we can also see that 0~7, etc., with 8 as the unit, are not in one column, and are divided into 8 groups, so that each point has an offset (relative) .
3. Point data (Data Point)
We all know that the principle of lidar is TOF, and the returned data has distance and reflection intensity. In the packet, a point is represented by three bytes , two of which represent the distance ( unsigned integer, the interval size is 4mm, so 25154 in the message represents 25154*4=100616mm ), and one represents the calibration reflection Rate ( normalized to 0~255 ). The pitch angle (ω) is inferred from the position of the data point in the data block. A distance of 0 means no measurement (e.g. firing a laser into the air). The laser was either off, or the measurable reflection didn't return in time.
4. Azimuth
After the flag byte at the beginning of each data block , a two-byte azimuth value (α) will appear . Azimuth is an unsigned integer. It represents an angle expressed in hundredths of a degree. Therefore, the original value of 27742 should be interpreted as 277.42°. The effective range of azimuth angle is 0 to 35999 (calculation 360*100=36000) . Only one azimuth value is reported per data block (from which the rest can be calculated).
5. Data Block (Data Block)
Note that this part is the most important and the most difficult. The 128-line echo information contains 4 blocks in the single echo mode . In double echo mode there are 8 consecutive blocks . Each packet has at most 3 sequences of laser shots . Only one azimuth is returned per block.
Contents in each block:
A two-byte flag and azimuth, and 32 points of data ( 3 bytes for each point mentioned above, two for distance, one for reflectivity ), so the final is 100 bytes .
6. frame
The data frame contains all data points in a single rotation, or the part from the beginning FOV to the end (only points for a specific angular range are recorded if FOV is set). It may contain some additional data if included in a firing sequence when it crosses a rotation boundary.
7. Time stamp
The timestamp consists of 4 bytes, 32-bit unsigned integer. The mark is the time of the third transmission group in the first transmission sequence of the data packet (that is, the position in the figure below, the third group of the first sequence) . Timestamp is the offset value of TOH (top of hour), marking an hour in microseconds: the value range is 0~3599999999 (60*60*1000*1000=3600000000);
The time stamp is critical because it is used by georeferencing software to match each laser shot with corresponding data from the inertial navigation system. An inertial navigation system provides a series of time-stamped values for pitch, roll, yaw, yaw, latitude, longitude, and elevation. By matching the time of the data points to the time-stamped data from the INS, user software can convert the data from the sensor's coordinate system to the ground reference system. Timestamps match Coordinated Universal Time (UTC) as provided by GPS/INS. When the sensor is powered on , it starts counting microseconds using an internal time reference. ( This refers to the fact that the lidar itself can also record time, and machine time is used when it is not connected ) However, the sensor can synchronize its data with UTC time so that it can determine the time of each laser in any particular data packet. exact launch time. UTC synchronization requires a user-supplied GPS/INS receiver to generate a sync pulse per second (1PPS) signal and a NMEA GPRMC message (MSG) . GPRMC messages provide minutes and seconds in UTC. After syncing, the sensor reads the minutes and seconds from the GPRMC message and uses this information to set the sensor's timestamp to the number of microseconds per UTC past that hour. ( The principle here is the same as the timing principle of computers and other equipment )
8. Factory location
Not too much to introduce here, that is, the echo form and product code
4.2packet structure
The structure of the packet :
The packets are 1248 bytes long and are sent over UDP packets on port 2368 . The packet consists of a 42-byte protocol header (Header), 12 data blocks (block, a block has 100 bytes as mentioned above), a 4-byte timestamp (timestamp) and 2 factory bytes ( factory bytes) . You can calculate by yourself whether the number is correct. Packets come in three formats:
Structure of a single echo:
Let's use the previous knowledge to analyze what this table means: First of all, from the beginning, a packet is 1248 bits, as mentioned above, there is also a header and timestamp, remove these, a total of 1200bytes, divided into 12 columns (here The column is the block), and each block mentioned above is 100 bytes, which contains point information (a total of three bytes of distance and reflection intensity correspond to the channel number 3bytes per channel outside), flag and azimuth. Look at the serial number again, 0~127, 128 in total, each firing sequence consists of 4 blocks in single echo mode, and there can be 3 sequences in a packet (in single echo mode).
Dual echo mode:
Because of the double echo, the amount of data is doubled, so a packet can only hold one firing sequence, so I won’t explain it in detail. In addition, there is also a double echo + confidence data structure ( Confidence Data Structure ) which will not be expanded here.
After talking about data packet, let's talk about position packet t:
The role of the position information package (commonly referred to as the telemetry package) is to provide a copy (copy) of the most recent, supported NMEA information, from an external GPS/INS/IMU source and pulse-per-second status, plus the time when the position package was assembled stamp, and possibly other relevant information. If no GPS/INS/IMU is attached or it is disabled, the NMEA sentence, PPS status and related fields in the position packet will be empty (i.e. all zeros).
The location packet is a 554 byte UDP packet received on port 8308 (by default). The protocol header (Header) occupies the first 42 bytes . The payload length is 512 bytes . The structure of the location packet (minus the 42-byte protocol header) is:
GPRMC sentences are terminated with CR/LF and padded with null bytes to the end of the payload.
NOTE: Timestamps in location packets are occasionally misaligned with the packets. This is normal as the delivery of data packets is the sensor's highest priority, while position packets may be temporarily delayed in favor of the data packets being transmitted. ( That is, when instability occurs, the data packet will be guaranteed first )
There are 4 states of PPS mentioned above, which are represented and described as follows:
Let's look at an actual particle to understand:
in:
The blue part: represents the Ethernet+IP+UDP header (42 bytes, mentioned above)
Orange part: timestamp (4 bytes) Note that 5D8E5FFD = 1569611773 (Little-endian) is required for conversion
Red: PPS status (1 byte) is locked at this time
Green: GPRMC statement
4.3 Calculation of precise time
If you want to calculate the precise time of each point, you can calculate each offset according to the law of emission. Each sequence (remember what a sequence means? It is a sequence of 128 lasers) takes 53.333μs to fire all 128 lasers and charge for the next shot (RP0 and RP1) . The last period (RP2) may range from 0 μs to 3.882 μs. The average length of RP2 is about 1.941μs . (Before that, the firmware would execute the trigger sequence every 53.3µs like clockwork). The purpose of this difference (the charging time of each RP2 is different) is to reduce the interference between different lidars .
A packet's timestamp is determined TOH 7μs from the first firing sequence in a packet . The time offset is negative for transmit groups before that and positive for the after (until the next packet). TOH is synchronized on the same marker. For each emission sequence, the azimuths appearing in the data blocks of the sequence are fixed at (i.e. around) similar points in the sequence for 7 μs.
These are three situations, one average, one maximum and one minimum. Where is the time stamp? At TOH7 microseconds of each packet, it can be seen from the above figure that the third group of the only first sequence at 7 microseconds is consistent with the above description .
So according to the rules, you can get the compensation (offset) table (only shows the single echo mode):
The 12 columns (block) are easy to understand. There are a total of three firing sequences, so why does the figure show 32 packets ? Some students will suddenly not be able to reflect - the line means order in packet (32*4=128), and you may suddenly realize it. That is, an offset of 128 laser is given .
Maybe you still remember the pattern of the laser above, then you can get the precise value of the offset of each angle according to this:
It is worth noting that it is consistent with the above - the azimuth and timestamp will be generated in the third group of the first firing sequence, and the azimuth will be generated in the third group of each sequence (while the timestamp is only in the third group generated) .
Pseudocode to achieve this:
// Do this for every packet
// packet_m represents an index to a packet
// datablock_n represents an index to a data block, valid range is 0 to 11
// point_k represents an index to a data point in the nth data block, valid range is 0 to
31
// Adjust for an azimuth rollover from 359.99° to 0°
// Note that a firing sequence spans four data blocks
If (Azimuth[packet_m+1][datablock_0] < Azimuth[packet_m][datablock_0])
Then
Azimuth[packet_m+1][datablock_0] := Azimuth[packet_m+1][datablock_0] + 360;
Endif
// Adjust for a timestamp rollover from 3,599,999,999 μs to 0 μs
If (Timestamp[packet_m+1] < Timestamp[packet_m])
Then
Timestamp[packet_m+1] := Timestamp[packet_m+1] + 3600000000;
Endif
// Determine the azimuth rate
Azimuth_Gap := Azimuth[packet_m+1][datablock_0] - Azimuth[packet_m][datablock_0];
Time_Gap := Timestamp[packet_m+1] - Timestamp[packet_m]
Azimuth_Rate := Azimuth_Gap / Time_Gap;
// Loop over data blocks
For (datablock_n = 0 to 11)
// Loop over data points
For (point_k = 0 to 31)
// Determine laser number
Laser_Number := (datablock_n MOD 4) * 32 + point_k;
// Lasers are fired in groups of 8
Firing_Group := Laser_Number DIV 8;
// Interpolate
Precision_Azimuth[point_k] := Azimuth[packet_m][datablock_n] + Azimuth_Rate *
(2.665 μs * Firing_Group - 7 μs);
// Add rotation during RP0
If (Firing_Group > 7)
Then
Precision_Azimuth[point_k] := Precision_Azimuth[point_k] + Azimuth_Rate *
5.33 μs;
Endif
// Apply the azimuth offset
Precision_Azimuth[point_k] := Precision_Azimuth[point_k] + azimuth_offset[Laser_
Number];
// Adjust for any rollover
72 Alpha Prime User Manual
If (Precision_Azimuth[point_k] >= 360)
Then
Precision_Azimuth[point_k] := Precision_Azimuth[point_k] – 360;
Endif
End For
End For4.4 Convert PCAP file to point cloud file
PCAP is a binary file. Whether you record in Velo View or capture in WireShark, the obtained file is (can) be in PCAP format, which has the advantage of small size, and the unpacked point cloud file (such as pcd) will be much larger. Therefore, when recording on a large scale, we save it as PCAP so that the data flow is small, and when it is visualized, we need to convert it into a point cloud for processing.
Closer to home, how to convert it?
Converting packet capture (pcap) files of veladar data to LAS, LAZ, XYZ, PLY, or other point cloud file formats can be a simple process. The data provided by a sensor in a pcap file is measured relative to the sensor's reference frame - the internal 3D coordinate system in which the sensor moves with the sensor . This is distinctly different from point cloud files where data points are referenced to a single coordinate system. This coordinate system may be an earth coordinate system (latitude, longitude, elevation) or another convenient reference frame. Processing raw lidar data into a point cloud is known as georeferencing. In georeferencing, the user considers the sensor position (X/Y/Z) and orientation (pitch/roll/yaw) for each measurement. Knowing these six values, the user can perform the appropriate mathematical thermal rotation and translation to reference the lidar data to a single coordinate system. Two popular technologies used by lidar customers for georeferencing are inertial referencing and simultaneous localization and mapping (SLAM). Through inertial reference, the position and direction of the sensor at any time are recorded by the inertial navigation system (INS). INS combines a Global Positioning System (GPS) receiver with an Inertial Measurement Unit (IMU). Data from the INS and LiDAR sensors are time-synchronized to the reference clock of the GPS satellites, enabling users to match each LiDAR data point with the corresponding position and orientation in the INS. After matching the lidar data to the INS data, each measurement was mathematically transformed into a single coordinate system. SLAM is a technique used by robots to analyze and navigate their environment. SLAM software can automatically identify stationary objects in lidar data. The algorithm then uses the positions of stationary objects to mathematically back out the lidar's motion and transform the data into a single coordinate system.
All in all, we know that the code can be decoded according to the rules. In contrast, the sensor center is written at the top. Of course, some users will write their own conversion tools (you can find Github, etc., and many domestically produced lidars already support changes . The output format makes recording and decoding more convenient ).
5. LiDAR communication
Before, this interface was simply explained, and now I will explain in detail the configuration interface after connection.
What is simple or explained is not repeated here.
Here are a few selections:
PPS Qualifier : As it says, it is a parameter to adjust how to coordinate to UTC time. We said before that the time has the time of the machine itself and the UTC time of GNSS access, set whether PPS access is required, whether PPS needs to be locked, PPS delay (acceptable verification time, in seconds), click SET to activate these configuration .
GPS Qualifier : Similarly, setting verification, whether GPS information is required;
Phase Lock: Phase lock, the phase at which the PPS rises. Can be used to synchronize the emission of two or more sensors. (and can control the position of the starting record)
The configuration of Velo View and so on will not be explained here, in addition, it can also be controlled by the curl command of the browser. Let me mention the contents of the appendix:
6. Notes in the appendix
6.1 Lasers
The source of each laser pulse in lidar is a semiconductor laser diode. A laser diode is a series of stacked pn junctions, similar in concept to the one shown in the diagram below. When current passes through the junction, photons are generated and pass through one end to form a tightly focused laser beam.
The laser emission produced by the sensor can be viewed with an infrared camera or a smartphone camera without an infrared filter (which emits infrared light). This part of the picture was taken with an infrared camera. While laser "spots" and "dots" are often used to describe when a laser pulse hits a target, the sensor's laser "dot" is actually a small rectangle made up of three smaller rods or bands of light area, as shown in the figure below. The major axis of the rectangle coincides with the path of the laser scan.
6.2 Time Synchronization
Above we also detailed the setting of PPS and GPS information in the configuration interface. Look back at the following picture:
These two new options control how the sensor utilizes the GPS information provided to the sensor. The first control option determines how the sensor utilizes the PPS signal (PPS Qualifer). The second control option determines how the sensor utilizes the timestamp provided in the National Marine Electronics Association (NMEA) sentence (GPS Qualifier).
The lidar maintains a counter representing the number of microseconds since the top of hour (TOH) . The TOH count is incremented according to the internal oscillator . When the sensor shows a valid PPS signal, the TOH count is adjusted on each rising edge of PPS to align TOH with UTC time . TOH is sent as a four-byte timestamp in data and position (telemetry) packets . We also mentioned this point before, TOH is the internal time of the lidar device, controlled by the crystal oscillator, and the crystal oscillator will drift with time and temperature , which is why we need to complete time synchronization. The function of each PPS is to reset the function.
Maybe we still don't quite understand TOH: TOH consists of two independent counters. One counter keeps minutes and seconds since the top of the hour , while the other keeps sub-second counts .
The combined value of the two represents the number of microseconds since the top of the hour . It ranges from 0 to 3599999999 μs - there are 3.6 x 109 μs in an hour. The subsecond counter has a range of 0 to 999,999µs . (That is , it is divided into two parts, one part is seconds, and the other part is values below seconds (sub-seconds), and the final result is the sum of the two )
This sensor continuously monitors the PPS input to assess the timing characteristics of any pulses presented. This process is shown in the web interface and location packets. When the sensor detects a valid and stable PPS signal, the web interface displays "PPS: Locked" (Locked) , and the PPS status field in the offset (offset) 0xF4 location packet is set to 0x02 .
The minute and second counters (that is, the first timer responsible for recording seconds) can be adjusted to the time values provided in the NMEA sequence . If no NMEA sentences are provided, the minutes and seconds counters are incremented every second. (It means that if you do not access NMEA data such as GPRMC, it is also possible to only access PPS. At this time, the second timer increments every second, and if GPRMC is connected, the time information will be extracted to replace the device's self-timer. time).
Using the PPS signal to adjust the subsecond counter keeps the sensor synchronized to the PPS source even if the source drifts slightly . This happens when the GPS receiver indicates that it is invalid, and starts to use its own internal time to drive the PPS reference ( referring to such as entering a tunnel, etc. GPS has no signal, there is no GPRMC, and it will switch for a period of time at this time It is the sensor's own time, but the PPS is still maintained, so that it can be corrected to prevent drift )
About Delay: This parameter indicates that the user is allowed to extend the time required for the sensor to verify PPS , and the unit is an integer second . Acceptable values range from 0 to 65535. The default is 5 seconds. The sensor continuously recognizes the PPS signal through a rolling n-second window defined by the delay parameter. In the first case, the PPS signal is considered unstable and the sensor enters a free-running mode where the sub-second counter is driven by an internal oscillator. In free-running mode, the sub-second counter is no longer adjusted on the rising edge of the PPS signal. Additionally, the minutes and seconds components of TOH increment based on the rolling start of the free-running sub-seconds counter . ( How to understand this paragraph, why should this Delay be set? Because the PPS signal may not always be stable, as we mentioned earlier, when something happens, the recording method of the timestamp will change. The default value is 5, which means If the PPS cannot be recognized, it will switch within 5 seconds )
The timing can be seen in the table below:
6.3 Phase lock
When using multiple sensors close to each other (for example, mounted on the roof of a vehicle), interference patterns may occasionally appear in the sensor data. Minimize this disruption by controlling where data is collected.
We have talked a lot about this before: just set the offset in the configuration interface.
After setting, you can see the state of the phase and the value you set have been jumping along with the PPS.
Apps to avoid distractions:
When installing left and right: the two offsets are shown in the figure
When installing front and rear:
7. Configuration of multi-tooth lidar access
As shown below:
So far, the Velodyne lidar has been introduced. The following will make an analogy to several other common radars.
(Concept self-test)
After reading the above sections, I have a few questions I want to ask:
1. There are many noun concepts in Velodyne LiDAR. What do the meanings of packet, group, firing sequence, data point, and data block mean? Is there any relationship in structure? ( important )
2. What are the characteristics and application occasions of single echo and dual echo? Is there any difference in packet performance?
3. What does RPM mean and what is its use? Does the greater the RPM, the greater the angle accuracy?
4. What is the principle of Phase Lock and what is its use?
5. How is the timestamp defined in this version of the firmware?
6. How is the elevation angle of the mechanical lidar obtained?
7. What method can you think of to calculate the ideal number of points per second?
8. What is the timing mechanism of lidar? What is the use of PPS and NMEA (such as GPRMC), and what role do they play in timing?
9. Is the charging time of the firing sequence of each group the same, and how many times are there?
10. Will you calculate a timestamp for you, how is the timestamp calculated, and is it related to UTC time? Does it have anything to do with linux time?
( Welcome to answer in the comment area~ )
--------------------------------------------------------------------------------------------
8. Comparison with other lidars
At present, domestic radars already have many star products, and their market share is also very good. Some products even have better performance than Velodyne, and the supported protocols and built-in algorithms are better. Some have already realized the loading of mass-produced vehicles. This section will briefly analyze the manuals of these radars, and introduce two domestically produced lidars, Sagitar and Hesai. You can also try to analyze other lidars with the knowledge you learned earlier. At present, many 4D radar and other Ethernet data formats are very similar to this data format, which has a strong reference value.
8.1 Sagitar lidar
Sagitar has launched many lidars. This article will give a brief description of its Ruby (128 lines) and M1 semi-solid-state lidar mounted on MEMES .
8.1.1 RS-Ruby
Why should we talk about the ruby lidar first, because it is also a high-end product with 128 lines.
The first step is to look at the characteristics of the product (datasheet):
The main features of the product are in the picture above, I circled three places, the frame rate is 10Hz or 20Hz ; the output point per second is 2.3 million (single echo mode) and Velodyne is similar, and supports many synchronization methods in terms of time synchronization: Classic 1PPS+GPRMC and PTP (IEEE 1588) , gPTP (IEEE 802.1) .
Next we say a few points in the manual:
1. Reflectance information : We know that in the Velodyne manual, the reflectance is represented by one byte and standardized to 0~255. It is defined in RS-RUBY as follows:
The intensity of diffuse reflection objects ranges from 0 to 100; the reflectivity intensity of total reflection objects ranges from 101 to 255. 255 is ideal total reflection.
2. The use of GPS : Here is just one point, which may not have been mentioned before, the GPRMC connected to the lidar needs to set the baud rate to 9600.
3. Packet structure : This part is its most important content. rs-rub sends a UDP protocol 1248bytes payload (are you familiar with 1248?) It is divided into mainstream data (MSOP) and device information (DIFOP) . Data structure diagram:
The structural arrangement is still different from Velodyne, the main part is similar to the structure composed of three blocks ( Velodyne is divided into 12 blocks, but in essence every four blocks represent a firing sequence, here a block represents a firing sequence ) Let's see how the block here is defined:
Among them, the channel data is the same as Velodyne, which are represented by 3 bytes, two represent the distance and one represents the standardized reflectance (0~255) ; the unit of the distance given here is centimeter (cm).
4. Vertical angle (elevation) :
You may remember the pattern of Velodyne's laser, ruby's relationship with India is as follows:
The ruby timestamp gives the laser point time of the first channel, so the offset can be calculated based on this.
5. Other features
In the configuration interface, there are some new features that have not been mentioned before:
This lidar can control three groups separately ( the group definition here is not given, the group here is different from Velodyne 8 as a group concept, according to the characteristics, I speculate that there are three blocks in one package and each The block contains a complete 128channel, which corresponds to a different firing sequence in a packet (MSOP), because it is a 128channel that can also be understood as a firing, so here you can control the attributes of different laser sequences in the packet, such as different triggers and FOV etc. make echo data with different properties in one MSOP )
The function of RS View can record and play (decompose PCAP package), and can export CSV format files and other features.
In addition, the configuration of ROS is omitted here;
8.1.2 RS-M1
The M1 lidar can be said to be a star product. It is a car-level radar that is officially installed and mass-produced. Its principle is different from that of the rotary type. The interior of a certain MEMS lidar is shown in the figure:
The principle of imaging is to scatter the laser light through the Diffuser, and then receive the reflected information through the receiver lens.
Same as above, first look at the features:
First of all, the horizontal FOV of this lidar is 120 degrees, mainly focusing on the forward direction. The number of output points is 750,000 (single echo mode), the time synchronization method is only gPTP, and the weight is only 730g.
For M1 I will simply mention a few unique points:
1. MSOP packet structure
It can be seen that it is divided into 25 blocks, and there are 5 channels in each data block. Here, there are actually five laser heads in the M1, and finally the images are spliced.
2. Use the software little robo to configure the lidar
3. The ROS package is given, and the parameter description is given in config.yaml to adjust your recording strategy.
8.2 Hesai LiDAR
Hesai LiDAR is also very powerful. If the M1 was the previous star product, then this year’s vcsel LiDAR AT128 is definitely the star product. Loaded with a number of models, such as the recently released ideal L9 and so on. Since I don't have the AT128 radar and manual, let's just take a look at its key parameters, and then talk about its excellent product panda 128.
8.2.1 AT128
The output volume is 1.53 million dots per second, which is very powerful, and the horizontal field of view is 120 degrees. The picture below even writes "no stitching" 120-degree ultra-wide field of view" This is not directly referring to the M1. Here its wavelength is 1550nm, which is farther away from visible light and less harmful to the human eye. You can increase the power to detect The distance is farther.
8.2.2 pandas 128E3x
parameter:
The number of output points is 3.45 million (much larger than the general 2.4 million points), so better resolution can be obtained. Time sources can be traditional GPS as well as PTP.
Data Format:
whose data subject:
Analysis of point cloud:
What I said here is relatively concise. Interested students can go to the application manual to have a look~
9. Summary
The upper and lower issues of this article can be said to be one of the few details that can be found for lidar. By reading the manual and understanding the principle of the device, we can better help us develop related algorithm design related solutions.
In addition to the lidar mentioned in the article, there are many other types of lidar that are very promising, such as Aeva's FMCW lidar (Lidar on chip), etc. are hot topics of discussion
Aeva structure diagram
Aeva renderings
-------------------------------------------------------------------------
Thanks for reading, I hope it helps you all! In addition, thanks to the various manufacturers in the article, I have learned a lot from their products!
Appendix: LiDAR physical photos:
Finally, put some beautiful photos of lidar:
Velodyne's VLS128 (Alpha Prime) carries weight
禾赛 Pandar 128
Sagitar M1