Skip to content
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

[Bug] Some scans have weird timetstamp #7

Open
LimHyungTae opened this issue Sep 3, 2024 · 4 comments
Open

[Bug] Some scans have weird timetstamp #7

LimHyungTae opened this issue Sep 3, 2024 · 4 comments
Assignees
Labels
bug Something isn't working

Comments

@LimHyungTae
Copy link

As far as I know, point['t'] should be 0.0. - near 0.1, yet I observed that some point clouds have erroneous values: for instance, in the campus_train1 sequence, the time values of some points are 3.604361924.

Thus, these values sometimes make the deskewing imprecise. By any chance, do you happen to know why these situations occur when you guys gather data? Take your time, and feel free to let me know :)

@EmanueleGiacomini EmanueleGiacomini self-assigned this Sep 3, 2024
@EmanueleGiacomini EmanueleGiacomini added the bug Something isn't working label Sep 3, 2024
@EmanueleGiacomini
Copy link
Contributor

Thanks for spotting this bug 🤓!
Based on an initial investigation, the issue is located on the first cloud of the sequence.
This issue might be caused by recording data in raw format (UDP packets) and reconstructing the clouds using the Ouster library. Given that the record can start at any point during the acquisition of a scan, it might be possible that the first scan is broken.

If you could share the timestamp or the ID of the clouds that appear broken, we can further investigate the issue

@LimHyungTae
Copy link
Author

LimHyungTae commented Sep 3, 2024

Wow, thanks for your swift reply, bro!

In fact, there are a few ts over the expected boundaries, and most bag files have the issues.

Originally, I wanted to deskew the point cloud. And here is my code snippet to detect the abnormal situation in_save_cloud function:

timestamp_in_sec = timestamp / 1e9
time_diff_for_each_point = data.points["t"] / 1e9
time_for_each_point = timestamp_in_sec + time_diff_for_each_point

min_value = np.min(time_diff_for_each_point)
max_value = np.max(time_diff_for_each_point)
# 0.15s are heuristic values, but times should be within the 0.15 sec since the Hz of point clouds are 10-20Hz!
are_normal_values = min_value >= -0.15 and max_value <= 0.15 

if not are_normal_values:
    print(f"Unexpected 't' values have come. Skip {timestamp_in_sec} frame")
    deskewed_points = np.stack([data.points["x"], data.points["y"], data.points["z"]], axis=1)

And once I printed them, their values are 3.xx, which is quite larger than we expected.

@LimHyungTae
Copy link
Author

LimHyungTae commented Sep 3, 2024

For instance in coloseeo_train0 (please ignore the GTData timestamp out of range message),

image
image

@LimHyungTae
Copy link
Author

In spagna_train0,

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants