uzh-rpg/rpg_trajectory_evaluation

IndexError: too many indices for array

Opened this issue · 5 comments

Im currently running SVO on a subset of the Euroc datasets by ignoring the first 10 timesteps to avoid initialization errors i.e. rosbag play <file.bag> -s 10.
I record the estimated trajectory and extract to a text file.
For the ground truth I use the supplied ground truth in ASL format and parse it using the supplied matlab code.
As a result, there is a mismatch in the number of steps in estimate vs ground truth.

I assume that for the trajectory evaluation to work, there must be equal number of steps in both?
Can anyone confirm whether this is the case?

I met the same question,
****Traceback (most recent call last):
File "./analyze_trajectory_single.py", line 53, in
traj = Trajectory(args.result_dir)
File "/home/ rpg_trajectory_evaluation/scripts/../src/rpg_trajectory_evaluation/trajectory.py", line 68, in init
self.load_data()
File "/home/rpg_trajectory_evaluation/scripts/../src/rpg_trajectory_evaluation/trajectory.py", line 87, in load_data
self.accum_distances = traj_utils.get_distance_from_start(self.p_gt)
File "/home/rpg_trajectory_evaluation/scripts/../src/rpg_trajectory_evaluation/trajectory_utils.py", line 18, in get_distance_from_start
distances = np.diff(gt_translation[:, 0:3], axis=0)
IndexError: too many indices for array


I found that the timestamp of groundtruth and the timestamp of trajectory estimated are totally different.

Hello, I solved the issue by reformatting my stamped_traj estiamte.txt file. First, the groundtruth and estimated file do not have to have the same length (the examples provided in the "laptop" folder have different length for the groundtruth and estimated files.). I believe the code provided does some pre-processing of the data such that even if they aren't the same length, the tool still works.

I tried to make sure that the file format are excatly the same as provided in the example. Specifically, I changed my file to space separated and convert my float to have scientific representation of the same scale.

To debug, you can print out the shape of the array (using .shape) in File "/home/rpg_trajectory_evaluation/scripts/../src/rpg_trajectory_evaluation/trajectory.py", line 87, in load_data

good luck

Hello, I solved the issue by reformatting my stamped_traj estiamte.txt file. First, the groundtruth and estimated file do not have to have the same length (the examples provided in the "laptop" folder have different length for the groundtruth and estimated files.). I believe the code provided does some pre-processing of the data such that even if they aren't the same length, the tool still works.
I tried to make sure that the file format are excatly the same as provided in the example. Specifically, I changed my file to space separated and convert my float to have scientific representation of the same scale.
To debug, you can print out the shape of the array (using .shape) in File "/home/rpg_trajectory_evaluation/scripts/../src/rpg_trajectory_evaluation/trajectory.py", line 87, in load_data
good luck

Thanks for your answer, it's very helpful. It's the problem of timestamps .I think it's necessary to study the paper of this tool to understand how this tool works.

also, make sure the first line of the estimated file is "# time x y z qx qy qz qw".

Hello, I solved the issue by reformatting my stamped_traj estiamte.txt file. First, the groundtruth and estimated file do not have to have the same length (the examples provided in the "laptop" folder have different length for the groundtruth and estimated files.). I believe the code provided does some pre-processing of the data such that even if they aren't the same length, the tool still works.
I tried to make sure that the file format are excatly the same as provided in the example. Specifically, I changed my file to space separated and convert my float to have scientific representation of the same scale.
To debug, you can print out the shape of the array (using .shape) in File "/home/rpg_trajectory_evaluation/scripts/../src/rpg_trajectory_evaluation/trajectory.py", line 87, in load_data
good luck

Thanks for your answer, it's very helpful. It's the problem of timestamps .I think it's necessary to study the paper of this tool to understand how this tool works.

You're welcome. I got this tool to work with the ASL format EuroC dataset. Could you specify more on the timestamps issue? I had an issue that my timesteps are not of the same scale with the groundtruth data. I just convert them to the same scientific notation format and it seems to work fine for me.