-
Notifications
You must be signed in to change notification settings - Fork 18
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
ROS tf frame confusion #3
Comments
Hey there, The current base_link pose (name in cfg: corrected_baselink_frame) wrt the first base_link pose (name in cfg: map_frame) is only published hereas a nav_msgs::Odometry message and not send as a transform to tf. In our system, we have an EKF subscribed to IMU and these odom msgs which then sends a filtered transform to tf. So to make it work for you, I think you have to first add sending the odom transform also to tf e.g. after here adding something like the following lines:
From what I saw wrt rtabmap on here at paragraph 4.3.6, the odometry system should provide the transform odom -> baselink. For that I think the following settings should work: Also: |
Hi Jan
even though the rtabmap/icp_odometry node isn't running. I suppose this is a specialty of rtabmap. Hence, reaching out to @matlabbe who wrote the code:
to make it work. When using Jan's lidar_mars_registration instead, rtabmap always seems to publish map-->odom, even though rtabmap/icp_odometry isn't running (see roswtf error above). Following Jan's advice, I am using these settings with lidar_mars_registration:
I feel like I am very close, registration works beautifully, I just cannot get tf tree to behave. It should be: |
Can you show your current tf tree? with
If you start only
This should indeed do that. Based on @JanQuenzel last comment, you would normally end up with cheers, |
Hello @matlabbe and @JanQuenzel
and this has fixed the tf issues I was having. I have had not time to properly evaluate lidar_mars_registration yet, but just wanted to share this progress with you guys. I will report back later next week on my findings. Have a great weekend, cheers :-) |
Hi Jan, I tested lidar_mars_registration with my existing Ouster OS0-64 datasets, with mixed results. The generated odom for the indoor datasets (factory type building) has a lot of jitter, with the position jumping around quite a bit. When playing around with the parameters in the config file I noticed that the jitter is reduced when setting I realize that there are many parameters that could be tuned, do you have any tutorials or documentation written up for this yet? I'd be happy to collaborate with you and share my bag and config, but maybe this issue thread is not the right place for discussion? Please consider the original issue ("tf frame confusion") as closed. |
Hey @masterhui , good to hear that at least the original problem is fixed. :) Can you be more specific in what situation it failed? Distance to surroundings, what happened in the situation etc? What kind of jitter do you mean? Time-wise or pose-wise? In our indoor situations (e.g. factory or storage type) we typically have some safety margin (> 1 m) around the drone. As such I used, as a compromise for indoor and outdoor, cell side lengths of 4/2/1m for grids and similar values for the Lattice. If I remember correctly, in the DRZ hall 4m ones are used very very rarely during registration. For narrow passages 4/2/1m is too large. You can reduce it by adapting the MAP_SIDE, NUM_CELLS and NUM_LEVELS from include/MarsMapParameters.h L47-L50. MAP_SIDE determines the side length of the local map on the coarsest scale. The coarsest cell side in meter is simply MAP_SIDE / NUM_CELLS. Finer cell sides are then subdivided by 2 per level. Setting MAP_SIDE to 128 would thus give you 2/1/0.5m. I recently found a bug within the Lattice code that the directly corresponding cell was not included when looking up correspondences. I'll push the fix for that within the next days. |
Hey @JanQuenzel,
Let me describe the test setup in more detail: The OS0-64 is mounted to a tracked robot (footprint 1.0x0.4m), which is remote piloted around a large indoor warehouse type facility. The whole course is a loop, it is first driven clockwise, then counter-clockwise, then clockwise again. During each lap, the robot also enters an office, which is pretty tight, and also performs numerous rotations in there on carpet, which causes a lot of vibrations. It also climbs over a pyramid shaped obstacle which is approx. 1m tall and has 45° sloped ramps. In addition, it performs 360° rotations every 20m.
Yes I am talking about pose jitter. Looking at the output of rostopic hz, the odom rate is pretty solid at 10Hz (same as Ouster). I have been playing with the parameters you sent, and things have improved a great deal compared to the default settings. The best setup I found uses MAP_SIDE=64, NUM_CELLS=32, NUM_LEVELS=2 in MarsMapParameters.h and max_iterations: 6 in mars.cfg/registration_adaptor section. The issue is that this works great in the large warehouse setting, with CPU load still not saturating one of the 6 NUC cores. However, when the robot enters the office, the pose litter gets very large: During lap 3, the localization finally completely fails in the office: I know this is a very challenging torture course, but it's the benchmark I am using to compare it to F-LOAM performance, which deals with it pretty well overall. Looking forward to the fix you mentioned, I will give it a try once you push the commit. I could also try to extract the Ouster data from my rosbag if you would like to give it a go yourself, I just first have to strip some of the other topics (like uncompressed RGB, blowing up the size to 600GB). One last question: Where can I disable or tune down the log output? I tried various places reduce verbosity, but did not succeed so far. Cheers! |
That really sounds like a torture circuit :D You could also try to compensate orientation distortion within scans with the IMU.
For planar sensor motion it shouldn't be necessary, but in case of tilting, it may bring some benefit to enable:
Then a keyframe will also be created if roll/pitch wrt to last keyframe changes above One thing that surprises me are the parameters you chose. I also added an option to send the tf transform between map and base_link via the config option Most output should now be reduced, since I changed most Furthermore, I added the soft-constraint on acceleration, which can be adjusted via:
I'd be careful with the factor, since for very rapid movement it could actually reduce accuracy as it constrains high acceleration on both rotation and translation. So far, I haven't quantified the influence by rerunning some of the experiments, but in general it appeared more consistent. |
Now I am really curious what the reason is. If the offer still stands, you can also send me part of the ouster data in question and I'll take a deeper look into why it looses track. Another quick thing: Regarding orientation compensation: Best, Jan |
Hi Jan, I have sent you a download link for the bag file via Email :-) |
As you suggested, I tried to start bag playback at 470s ( |
Hello Jan
First of all, great work on your paper, I really appreciate you published your code. Currently, I am using F-LOAM for LIDAR odomery on a UGV equipped with Ouster OS0-64. I discovered your fork recently (https://github.com/JanQuenzel/floam), which solved the increasing latency problem I was having with the original code. However, I really would like to evaluate lidar_mars_registration, as it promises even better results. I successfully compiled your package in my ROS workspace and was able to confirm your results from the paper using the public data sets.
Now, I would like to replace my LIDAR odometry solution (/rtabmap/icp_odometry using your F-LOAM fork) with lidar_mars_registration. Here is my current tf-tree:
As you can see, the map-->odom transform comes from rtabmap, taking care of loop closures. Then odom-->base_footprint should be supplied by the LIDAR odometry. I tried the following settings in the "tfs" section of the lidar_mars_registration .cfg file:
However, this doesn't work. Even though lidar_mars_registration is subscribed to the correct pointcloud topic and it also correctly processes the scans, the published tfs are wrong. Running roswtf to debug, I get the following errors:
Any idea where I'm going wrong? Your help is greatly appreciated!
The text was updated successfully, but these errors were encountered: