-
Notifications
You must be signed in to change notification settings - Fork 40
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
Running Kimera-Multi on EuRoC MH: issues with results #9
Comments
Hi, To answer your two points:
Things to try: |
Hello, Thank you for your quick response.
I did try launching the What happened was that the system was running, but due to an error of there being no I'm currently home and won't be back at my school computer where I do experiments until Monday, so I could try running a full run on single robot VIO, evaluate the trajectory, and provide more details when I get back. Thank you. |
Hi @TakShimoda sorry I forgot to respond. Any updates? |
Hello @yunzc, I haven't been working on it, but I ran a single robot VIO and I got the same issues I mentioned above (no output as well, so I can't assess trajectory) I tried running Kimera-Multi again on MH and what I noticed is that either the loop closure or dpgo seems to get stuck on optimization. After a few minutes after all the rosbags finished playing, the trajectory looks something like this: Even among the 4 trajectories that seem to have approximately correct, you can see they don't have many keyframes. For example, for robot 1, there's only 118 poses compared to 29993 for ground truth. Here's what the trajectory and xyz for it looks like: For additional info, dpgo shows that a lot of potential loop closures are not being accepted: Considering robot 0's failed trajectory and robot 2-5 having few poses, I'm assuming the issue is still kimera-vio for individual robots. I also noticed dpgo takes a long time, but I think this is due to the faulty individual trajectories and tmux (which I noticed was slow for other multi-robot algorithms as well) as I don't think this was an issue with D-GNC taking more RBCD iterations due to converging to approximate solutions as mentioned in the paper as MH isn't a perceptually aliased or challenging scene. |
I had another question which isn't related to the current issue but is related to the output of Kimera-Multi, so I'll ask here in this thread if you don't mind. I was wondering about RPY values not being aligned, which I also asked here. The answer I got was to multiply the rotation by the SO(3) I got from Umeyama's Alignment from the evo library. But I thought this was already corrected when applying the SIM(3) or SE(3) trajectory alignment between estimate and ground-truth? This was the case for other SLAM algorithms where the RPY values were off initially, but corrected after applying the trajectory alignment with the evo library. Here's an example using acl_jackal's trajectory from the 1208 dataset: As you can see, even after applying the alignment which aligns the xy clearly, the roll angle is still off by about 90 degrees. This has a significant effect when I calculate ATE/RPE with evo, which according to the library, first computes an error matrix as below: Then, giving these error matrices, they have multiple ways to calculate ATE/RPE. I used 2 of these: For example, here are the ATE statistics by calculating only wrt translation:
And here are the ATE statistics by calculating wrt full transformation:
Where there's quite a large difference. In section 7B of the Kimera-Multi paper, with the results in Table I, are the ATE values calculated only wrt translation or wrt full transformation? When I compare the two methods with other algorithms, there's almost no difference since the RPY values are fairly close to ground-truth after applying trajectory alignment, but it doesn't happen with the Kimera-Multi output. |
Hi! |
Hi @yunzc thanks, I did the SE(3) transform then rotated 90 degrees ccw about the Z-axis and it mostly aligned the angles correctly. I still am encountering the issues with kimera-VIO on the MH dataset |
I have the same problem. Is there any solution? Or can you provide a readme.md about how to run it on Euroc? @yunzc The picture is the trajectory results I ran on MH_01-MH_05. I don't think it's running correctly. Thanks a lot anyway |
Hello, I'm raising a new issue, as directed by @yunzc from this thread. Thank you for helping me to get it running on campus_outdoor_1014. I'm now trying to run it on EuRoC Machine Hall dataset with 5 robots.
I worked from 1014-example.yaml and took a look at kimera_vios_ros_euroc.launch as suggested by yunzc. Here's what I changed:
use_external_odom:=false
, and added the arguments for the topics for the EuRoC bag file:left_cam_topic:=/$ROBOT0/cam0/image_raw right_cam_topic:=/$ROBOT0/cam1/image_raw imu_topic:=/$ROBOT0/imu0
kimera_vio_jackal.launch
tokimera_vio_jackal_MH.launch
in the vio window, andmit_rosbag.launch
toMH_rosbag.launch
in the data window which I'll explain the changes in 2. and 3.<arg name="params_folder" value="$(find kimera_vio)/params/Euroc" />
<include file="$(find kimera_vio_ros)/launch/kimera_vio_ros_euroc.launch" pass_all_args="true"/>
kimera_vios_ros.launch
./$(arg input_ns)/forward/imu, /$(arg input_ns)/forward/infra1/image_rect_raw/compressed, /$(arg input_ns)/forward/infra2/image_rect_raw/compressed
) to (/imu0, /cam0/image_raw, /cam1/image_raw
)ExternalOdometryParams.yaml
file in kimera_vio/params/EuRoC folder. The contents of this folder are the exact same as from the D455 folder used for the 1014 example. The reason I did this is that the vio node crashed due to an error of not finding theExternalOdometryParams.yaml
file, even though I set use_external_odom:=false as explained in step 1.RESULTS
I get proper output for all the windows: frontend receives candidate loop closures and performed robust initialization of robots in the global frame, dpgo performed optimization of the poses, and the vio was properly running for each robot.
The output in rviz, however gives a poor trajectory:
when I evaluated one of the trajectories (e.g. robot 1: jackal) with the latest
kimera_distributed_poses_xxx.csv
file in the output log, it seems there are only a few trajectories given in a short span.What I think are causing the issue:
use_external_odom
parameter. It's set to false in thekimera_vio_ros.launch
andkimera_vio_ros_euroc.launch
files, but is set to true inkimera_vio_jackal.launch
. I had to set it to false, because if I set it to true, the frontend wouldn't detect any loop closure. I'm thinking this parameter is true if the system has an IMU external to the camera, but I'm not sure.Any help would be appreciated. Thank you.
The text was updated successfully, but these errors were encountered: