-
Notifications
You must be signed in to change notification settings - Fork 197
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2D positioning error occurred, the positioning program selected the wrong pointcloud2 topic #36
Comments
Hello, This is the expected behavior of drl. The pose published in topic Check in rviz with the global frame set to Have a nice day, |
Thank you for your reply. I have tried adjustments, I changed base_link_frame_id to base_link. The laserscan and ambient_pointcloud fit together, and the localization_pose also coincides with the laser's TF, which is equivalent to saying that the localization_pose is based on the ambient_pointcloud instead of the aligned_pointcloud. And only after I publish an initial value, the positioning data becomes correct. I guess this may be related to TF, I am trying to solve it, wish you have a good day. |
Hello, It seems you have changed the By default it has a negative value to indicate that the If you specify a positive value, the This functionality was added to allow other nodes to have available the tf This might be useful if you have a motion controller running and constantly looking at the latest tf The drawback of this approach is that all the other nodes (including rviz), that look at tf to transform data to the map frame (which includes the laser scans), will have the error associated with odometry between scan alignment corrections. Without this feature, the motion controller would block when calling the lookup transform api and would only be able to run at 10 Hz. Alternatively, the motion controller could internally use the last That is why drl has by default the If you do not want this odometry error between scan alignment corrections, then you need to set the Also, the drl_configs.yaml is only for documentation. The yamls loaded to the parameter server and used by drl are the ones specified in the dynamic_robot_localization_system.launch along with the other roslaunch parameters inside the node xml tag. Have a nice day, |
Hello, By default the But this feature will only work reliably if you have good odometry. In the readme below you have more documentation and examples about the impact of the spherical linear interpolation correction in the final point cloud (generated from the laser scan). In the examples you can see that without the correction the first and last laser measurements do not overlap on the same wall line and on the left of the map the measurements do not overlap with the walls. If you compare these images with the ones with the correction, you can see that these scan deformation issues are corrected. Have a nice day, |
Hello, I found what was the problem. This commit added the stop of the point cloud subscribers at the end of the drl pipeline when it exceeded the By default, I fixed this issue in last commit: Without this check for ensuring That was why you were seeing the drift over time, because drl would process the first scan after you set the initial pose in rviz and then would stop the point cloud subscribers, which would result in drl stopping estimating the robot pose. I apologize for the inconvenience and thank you very much for alerting me of this problem. Please do Have a nice day :) |
Hello! I have tested DRL for a long time. It seems to be suitable for scenes with many moving obstacles. The effect is much better than most 2D positioning algorithms. But the drift of tf does not seem to trigger the correction program. Is the method of initial registration of point clouds the same as the registration method during operation? And is there any way for DRL to register two point clouds without sending initial values? |
Dear Carlos,
I tried using your outstanding work and its positioning effect was very excellent. But I have encountered a problem now, and I have tried to modify the code or configuration file, but none of them can solve it. I sincerely hope that you can point out the mistakes I have made.
The problem I encountered is that /ambient_pointcloud is getting farther and farther away from the wall. Then the positioning data also showed a few centimeters of error compared to the actual data. /ambient_pointcloud becomes less attached to the wall as it runs, and then /aligned_pointcloud remains attached to the wall. I believe that the positioning data should be output by /aligned_pointcloud instead of /ambient_pointcloud , but the actual situation is that /ambient_pointcloud and radar /scan are attached, and the positioning data is also published based on /ambient_pointcloud.
What is in red in the picture is /aligned_pointcloud ,and what is in white in the picture is /ambient_pointcloud ,It can be seen that /aligned_pointcloud is in contact with the wall. And /ambient_pointcloud has error. And this error will gradually increase as the car runs, I guess it's due to compensation for the odometer. By the way, I confirmed that the odometer data is accurate.
/ambient_pointcloud and /scan are matched:
Only when I give it another initial position value will everything match and become normal.
This is my TF data, one radar, one Odom:
Here is my configuration file:
drl_configs.txt
launch file:
launch.txt
What can I do to make the location data based on /aligned_pointcloud ?
Wishing you a wonderful day!
The text was updated successfully, but these errors were encountered: