Nothing Special   »   [go: up one dir, main page]

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

IMU observation in pi3hat interface is not thread-safe #413

Open
stephane-caron opened this issue Aug 15, 2024 · 1 comment
Open

IMU observation in pi3hat interface is not thread-safe #413

stephane-caron opened this issue Aug 15, 2024 · 1 comment
Assignees
Labels
bug Something isn't working

Comments

@stephane-caron
Copy link
Member

Bug description

IMU measurements from attitude_ are read in Pi3HatInterface::observe, which is called in step 1 actuation cycles, before step 3 where we wait for a reply. This means the following undesirable execution sequence may happen:

  • Spine thread: Spine::cycle`` calls Pi3HatInterface::observe`
  • CAN thread: Pi3HatInterface::pi3hat_->Cycle(input)`` updates attitude_`
  • Spine thread: reads Pi3HatInterface::attitude_ at the same time: inconsistent reading 💥

Expected property

The data read during observed should not be writable by the CAN thread, as is already the case with servo commands.

Reproduction steps

As far as I know the undesirable execution sequence above has never been observed in practice.

System

  • OS: Ubuntu 22.04
  • Upkie version: 5.1.0
@stephane-caron stephane-caron added the bug Something isn't working label Aug 15, 2024
@stephane-caron stephane-caron changed the title IMU measurements in pi3hat interface may not wait for reply IMU observation in pi3hat interface may not wait for reply Aug 15, 2024
@stephane-caron stephane-caron changed the title IMU observation in pi3hat interface may not wait for reply IMU observation in pi3hat interface is not thread-safe Aug 15, 2024
@stephane-caron
Copy link
Member Author

One reason thread safety between the CAN and spine threads is not a pressing issue is that spine cycles spend more than 90% of their duration waiting:

image

At this rate, we could switch to blocking cycles. 🤔

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

No branches or pull requests

1 participant