Haply Pen Slowdown

HelpDesk
1

When following the C++ example provided in 0.0.5 release I found that when the Haply pen was used, the update rates significantly slowed down. Enough to make haptics un-useable.

I could try putting it on its own thread, but this doesn’t seem like a practical/long-term solution.

I have yet to measure this difference.

I use virtual coupling so I can drop stiffness to account for it. But I have to drop it pretty significantly.

2

Hi,

Yes, this is the expected behavior. The current firmware of the handle is sending continuous updates at 50 Hz and if the calls are made in the same threads as for the Inverse3, this slows the simulation to that rate.

In simulation, we typically use a separate thread to keep the same rates. This is the current prefered solution.

We experimented with a API that would manage the threads, but in C++ this ended up creating dependencies conflicts. We are currently looking at ways to speed up the “Receive()” call or make it non blocking to reduce the impact on the simulation.

Best,

Antoine

3

Does it:

  • Send a request to get the data, then receive the data. Such that when Receive is called it takes 20ms from the start of the call.
  • The handle is constantly emitting a orientation, you just have to receive it and can get it whenever you want but it will not be any finer than 50hz?

If the latter is the case it seems like it would just be a matter of better coinciding when you ask for it, with when it has it. In which case I could half the amount of calls done to it and get better rates. And start to schedule when I make recieve calls (ie: every 20ms). I have yet to try this.

4

Currently, the handle is constantly emitting the orientation at 50Hz (the update rate of the inertial unit) and the “Receive” is blocking.
Doing it every 20ms should work, but you would probably have to do it faster at the beginning of the simulation to consume the buffer.