Is there any reason changing the reference frame would change a scan's frame?
Hello, I currently have a system containing a velodyne VLP 16, and an intelrealsense L515. The velodyne's position is slightly above in Z of the base_link and is slightly turned (I didn't align it correctly so I corrected it in the tf publisher's yaw) while the intelrealsense is placed around ~70 cms forward.
<node pkg="tf" type="static_transform_publisher" name="base_to_laser_broadcaster" args="0.7 0.1 0 0 0 0 base_link lidarcamera_link 100" />
<node pkg="tf" type="static_transform_publisher" name="depth_to_lidar_broadcaster" args="0 -0.15 -0.05 0 0 0 lidarcamera_link camera_link 100" />
<node pkg="tf" type="static_transform_publisher" name="base_to_laser_broadcaster1" args="0 0 -0.10 0 0 0 base_link velodyne 100" />
Here's the problem: In rviz if I set the reference frame to be velodyne/lidarcamera_link/base_link, both velodyne's and l515 scans overlap perfectly throughout the whole course. However, I've created an odom frame twice: The first time i'm simply using laser_scan_matcher with the velodyne's scan and the second time i'm inputting it to robot_localization to fuse it with an odometry source. Whenever i set the reference frame to odom, the scans stop being overlapped. I don't see a reason why changing the static frame to odom would change the link between the velodyne's frame and the L515' frame. During curves it seems like the L515 scan (white one) moves first. Which led me to believe that for some reason the scans are desynchronised in time whenever the static frame is odom, so I checked the timestamp in both scans and they had a 3 second offset. The offset is however still there when my reference frame is not the odom, and the scans are perfectly overlapped. Later I realized it's not a problem of time sync since whenever a person was moving inside the L515 scans, the same person was doing the same in the velodyne's. So concluding: it's not a time sync problem.
Lastly, I noticed that whenever my static frame is set to either velodyne/lidarcamera_link/base_link, the L515 scans (white ones) start around 0.5 m in front of the lidarcamera_link frame(the L515 frame) which is the frame 70cm in front of base link/velodyne, this 0.5m value is expected since it's the minimum range of the L515. However, whenever I change the static frame to odom, the L515's scans seems to appear even behind the lidarcamera_link which should be impossible as the L515 only scans to the front. It's seems that the L515 scan's frame_id is changed somehow. I've echoed with |grep frame_id and it shows the same expected frame. This problem seems to create problems while running Gmapping. Since the scans aren't overlapped, the laser_scan_matcher odometry which uses the velodyne's scans doesn't fit with the L515's scans which are being the used for mapping.
Any suggestion as to why this is happening? A youtube link showing this is ...
Please provide some detail about the Intel L515: what sensors does it have? what is it's output? is it performing integration internally?
This seems to have been posted again in #q383680.
The Intel L515 has an IMU, a camera and a lidar (70x43 FOV). It outputs and dense pointcloud 640x480p and the scan (white) is given by the pointcloud to laserscan package. By performing integration internally do you mean if it performs an odometry process internally? No it just outputs the camera/depthimage/pointcloud/accelerometer/gyro.
The L515 white dot behavior as it approaches objects looks very odd to me. Do you know what algorithm it uses to estimate distance? What is its claimed max. range?
Odd in what way? Its claimed max range is 9m, and I have tested it and confirm. I'm not familiar with the algorithm the L515 might use to obtain the dense point cloud, but to get the scan I am using pointcloud_to_laserscan package. I forgot to mention that during the video there's some situations where the L515 showed a lot of noise where it may seem like it is seeing an object but actually isn't. Normally one can see it's noise since the robot passes through it. It usually has a V shape.
I still haven't found a reason why anytime I create a non static transform those 2 scans stop overlapping. Only the transforms between both lidars should matter, right?
Only the transforms between both lidars should matter, right?
No, it depends on how the L515 estimates distance. If its distance estimate is really poor at first, then it gradually "locks in" as it obtains different views, that would partially explain the behavior you are describing. In your video, to me it looks like the distance from the robot to the white dots is changing by a different amount than the robot itself has moved. The question is why?
I have noticed that if I select the /odom as fixed frame, it seems like the scan's position is delayed (the points in the scan appear before the frame of the scan itself) which fits with what you are saying. The weirdest part comes when during the curves, e.g. to the right, the scan rotates to the left even before the frame starts doing the curve, which would now indicate it's ahead in time. I still can't understand how changing the fixed frame which I thought it was merely for visualization purposes would mess with anything else. How would the L515's distance estimation affect this, though? I'm using the velodyne's scan (red one) to create the /odom->base_link topic, the L515's should be simply placed on top of the lidarcamera_link frame which has a static transform to base_link, right?
From your description, it sounds to me like the publishing of odom TF from velodyne scan data has a huge time delay. In my opinion, fixing that timestamp difference you noticed should be your highest priority. I would expect the updated
odom->base_linktransform to be published within 20 milliseconds of the velodyne scan data arriving atlaser_scan_matcher. If it takes 3000 milliseconds, something is very wrong.