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

drv_hrt: allow time differences across timestamp wrap again #23380

Closed
wants to merge 1 commit into from

Conversation

MaEtUgR
Copy link
Member

@MaEtUgR MaEtUgR commented Jul 9, 2024

Solved Problem

Fixes #23378

Solution

reverting a small part of 4a55393

Changelog Entry

Bugfix: allow time differences across timestamp wrap again

Alternatives

We could check why these occur in the first place.

Test coverage

The SITL test procedure I used to reproduce the original issue passes again.

Context

#22881

@DronecodeBot
Copy link

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-sync-q-a-july-10-2024/39614/1

Copy link
Contributor

@katzfey katzfey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will break VOXL 2

@MaEtUgR
Copy link
Member Author

MaEtUgR commented Jul 11, 2024

@katzfey I'm aware and I really do not want to break the board support you contributed! That's also why this pr is a draft. Like I wrote here: #23378 (comment) it would be nice to avoid the additional overhead with this much used time critical inline function and behavioral side effects on all setups just because the microcontroller timestamps jump back on VOXL even though that's not supported by other components. All I'm saying is another solution to the time synchronization would be desired.

#23384 at least fixed the blocking problem that broke the PX4 main branch.

@MaEtUgR MaEtUgR closed this Jul 11, 2024
@MaEtUgR MaEtUgR deleted the maetugr/fix-uorb-timestamps branch July 11, 2024 08:16
@katzfey
Copy link
Contributor

katzfey commented Jul 11, 2024

Is the extra CPU load for this extra check quantified? If it is large we could just ifdef the code so that only VOXL 2 boards suffer the extra overhead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug] Modules do not react on parameter updates anymore
3 participants