search

thp / psmoveapi

Cross-platform library for 6DoF tracking of the PS Move Motion Controller. Sensor fusion, computer vision, ambient display (LED orb).
https://thp.io/2010/psmove/
Other
466 stars 160 forks source link

Update frequency for IMU #443

Open gb2111 opened 3 years ago

gb2111 commented 3 years ago

Hello. I was testing examples and they seem to use a high CPU. My idea is that if there is no data they create "empty" iterations. After adding some code seems like I can get 300 FPS which of course is not easy to schedule on Windows. I wonder if number 300 is something you can confirm or it might be something specific to my PC? Thanks.

nitsch commented 3 years ago

I wonder if number 300 is something you can confirm or it might be something specific to my PC?

The controller's internal update frequency (for both ZCM1 and ZCM2) is roughly 180 Hz, I believe. Polling it faster than that would not yield any new values, i.e. psmove_poll() returns 0.

gb2111 commented 3 years ago

Thanks for reply @nitsch . I am testing example.c file. Added some code to check FPS separately when I have returned zero or non-zero. I am using timeGetTime function and count how many I can get in one second. When I have one device I have about 580FPS. When I have 2 devices I have about half of that, which is in practice 280FPS. Those numbers are not fixed and can vary even by 10-20. So can vary even 40 between min and max. No info about dropping frames what seem to be good indicator.

Then I see also about 5000000 fps for non-pooled values that is causing quite a overhead for CPU. The fans go loud immediately.

I changed code to disable noblocking and got only 'proper' values with same FPS. But there was no 'zero' calls from psmove_pool(). My CPU was almost idle and fans quiet.

@thp I wonder if you would see it useful to have some flag to allow 'blocking' code or better just some timeout to give CPU idle time before waiting for new data. That seem relatively simple and I could do that part if you agree. If I missed anything where this is already in place then sorry for that :)

nitsch commented 3 years ago

I don't think there is an option yet for blocking vs. non-blocking (or even ansync) reads. But it may be useful. If you want to add that to the library, just go ahead. Contributions are always welcome.

thp commented 2 years ago

Feel free to make a pull request. The example code, however, usually has the right way to do it -- for integrating sensor readings over time, you want to poll until it returns zero, and process every event, if you just care about the "latest" values, just poll until it returns zero, and then process only the last event (throwing away all in-between values, as they are "old data" anyway).