The Autoware Foundation
Replies: 5 comments 10 replies
-
|
Hi, I suggest adding 'clock source' into UTC format. A complex system may have several clock sources and will fuse the data from multiple sensors, which use different clock sources. For example, the bus may have one GPS clock for the computer and another GPS clock for each LIDAR. The drift among clock sources may lead to wrong results if the system is NOT aware of the difference in clock sources. Clock drift within 100ms will prolong the length of the detected objects. The clock source can be represented by the UUID of the device, for example, or URL to the NNTP server.. Daniel |
Beta Was this translation helpful? Give feedback.
-
|
Hello, |
Beta Was this translation helpful? Give feedback.
-
|
Hi @ralwing,
I'm assuming you are talking about the ray_ground_classifier. And its design doc. This filter divides the point cloud into regions (rays), filtered by the local heights, sorted by x-y euclidean distance, and classifies the points as ground or not if difference is too high. It doesn't do ray casting to my knowledge. Lidars are ray casting sensors themselves. I'd say that with egomotion correction done, the full point cloud will make more sense and the ray_ground_classifier will work better.
A ray is basically a top down pie section of the point cloud. You can divide the point cloud into "rays" in any angle size you want. And that angle size is a parameter. The red part would represent a ray in the filter. (normally it'd be of 0.01rad or 0.57deg) |
Beta Was this translation helpful? Give feedback.
-
|
Ray Ground Classifier (RGC) works by getting a point cloud, dividing it into rays, and then analyzing the divided points to classify them as points on the ground or above the ground. The division into rays should reflect the operation of lidar - the RGC should see the world in the same way as lidar to work optimally. Currently, the RGC gets points in the base_link frame and creates rays from that point. So the rays created this way do not correspond to the rays from lidar because they are created from a different location. This can cause misclassification of the outermost points, as you can see in the attached image (the problem becomes apparent when standing in front of a hill). Her lidar is about 2 meters in from of base_link:
The green points are on the ground, the blue points are above. The points on the left have been misclassified as blue, because for the radius so created (relative to base_link) the initial points are missing and the first points in that radius are already on the hill. Once we set base_link into the same location, all points are correctly classified. |
Beta Was this translation helpful? Give feedback.
-
|
@ralwing Of course the origin of the lidar should be known for RGC to work correctly. I agree with that. But ego-motion distortion correction doesn't translate the point cloud so this shouldn't be an issue. |
Beta Was this translation helpful? Give feedback.
-
|
I believe, it is rather important to limit the data size of a point cloud. In our experience, big messages are not well supported in DDS/RMW implementations. Considering a format like this:
It has 25 bytes per point. In the case of Velodyne VLS 128 set for 600RPM, it produces over 230k points each revolution. A single message has around 5.5MB of data, which is quite a lot for DDS/RMW implementation to handle with 10Hz frequency. Size reduction would be very desireable, I think. IntensityIs there a reason for intensity to be as high resolution as FLOAT32? Wouldn't the resolution provided with UINT16 or even UINT8 be sufficient for Autoware applications? Laser channelWhat would be the data type of the Time representationI think a better approach would be to use a full timestamp in the header and offsets in the points since it reduces the overall message size. To further reduce the point cloud size, offsets could be set for a ranges of points rather than to each point. Such metadata might be sent on the dedicated topic and nodes interested could use it. However, the question is whether such an approach would be accurate enough to be used for distortion reduction or other required applications. X,Y, Z position informationFLOAT32 seems fine to represent points. However, depending on the expected resolution data size might be reduced by half when representing the position in INT16. With 1cm level accuracy, it can represent a range <-327,68; 327,67>m which seems enough for most Lidars. Or with 0.5cm level accuracy with range reduced by half. Of course, the drawback here would be greatly limited distance resolution. And it is not the standard approach to point representation. |
Beta Was this translation helpful? Give feedback.
-
|
I can create a sample nodes to investigate iceoryx zero-copy feature against a very large pointcloud message. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
I looked over the description of this solution and I have one concern. From iceoryx page:
So it would be great in case of publisher and subscriber are on the same machine, but it won't work via the network I suppose. Can it be expected that no big point cloud will be sent over the network? @mitsudome-r I did not perform the iceoryx performance tests yet. I will take care of them soon however |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
I did some tests of iceoryx I used I created an artificial point cloud formatted as x,y,z floats I planned to test point clouds from 100'000 to 15'000'000 points which was feasible for Apparently, it would not fit a single point cloud of mentioned Velodyne VLS 128 (with format as stated before) that has over 5,5MB of data. I do not know if the implementation could be change to fit more data but I would conclude that usage of iceoryx might be more cumbersome than anticipated. |
Beta Was this translation helpful? Give feedback.
-
|
@xmfcx (@badai-nguyen @drwnz @miursh) We currently use a pointcloud_ex topic that also includes distance, azimuth, and return type for some sensing modules (the data size is large, so we use a container as shown in velodyne_node_container.launch.py). Currently, the azimuth output from sensor drivers is a lidar-dependent value, and the type is not fixed. |
Beta Was this translation helpful? Give feedback.
-
Main Sensing/Perception Discussion: #2456
This discussion is for deciding the point types accross the new autoware.
I think everybody agrees that we will use the http://docs.ros.org/en/lunar/api/sensor_msgs/html/msg/PointCloud2.html for point clouds.
Here is the link for PointFields to choose from.
My initial proposal is to go with PointXYZI for most of the stack.
A
FLOAT32is 32 bits = 4 bytes. And each point is 16 Bytes, which is a tightly packed structure size, avoiding padding.Time Field Management for the Motion Distortion Correction
This information is costly and there are multiple ways of adding this information.
Each point contains a UTC time with nanosecond precision
This is the cleanest way to implement and requires adding
fields to each point.
Pros:
Cons:
The message header contains the UTC time information, point times offset from there
This method attempts to reduce the repeated information since the points from the cloud will belong to a small time window.
Header contains the old ros::Time message which contains the time that belongs to the first point in the cloud.
And rest of the points only contain the following field:
And it denotes the nanoseconds passed from the first point in the cloud.
Note that a
UINT32can represent 2^32 numbers (including 0 :p)And it can represent 2^32 * 10^-9 = 4.294967295 seconds of time. So if a scan is longer than this, it will overflow.
Pros:
Cons:
laser_channelField for the Laser Channel based processing #This is for denoting the
laser_channelfield forchannelsin rotating lidar scanners. And representslinesfor solid state lidars.graph TD A(Lidar Driver) -->|PointXYZI+LaserChannel+Time| X1(Sensing Modules) subgraph sensing X1(Ego Motion Distortion Corrector) -->|PointXYZI+LaserChannel| X2(Laser Channel Outiler Remover) end X2 -->|PointXYZI| D(Rest of the Modules)Beta Was this translation helpful? Give feedback.
All reactions