search

robotology / peripersonal-space

This repository deals with the implementation of peripersonal space representations on the iCub humanoid robot.
GNU General Public License v2.0
1 stars 4 forks source link

check sending of activations to skinGuis #31

Closed matejhof closed 8 years ago

matejhof commented 8 years ago

The virtual/PPS activations (green) sent to skinGuis have weird behavior sometimes. They either flicker or do not light up at all - it seems to be dependent on the rate of the vtRFThread - even changing the verbosity level may change behavior. Check here: https://github.com/robotology/peripersonal-space/blob/pps-with-modulations-devMultiEvent/modules/visuoTactileRF/vtRFThread.cpp#L542 and compare to how real skin activations are being sent by skinManager.

alecive commented 8 years ago

Makes sense. Their activations are read from the vtRF and if that module for some reason is slowed down, the activations are slowed down/flickering/having some problem accordingly. This is not an issue to me.

matejhof commented 8 years ago

Hmm, don't know. @pattacini was also unhappy with this. Is there another way?

The way skinManager is sending the real skin "red" activations to the same GUIs is here: https://github.com/robotology/icub-main/blob/master/src/modules/skinManager/src/compensator.cpp#L340 There, I have never seen it flickering, but I did not try slowing the skinManager down...

alecive commented 8 years ago

That module is doing very little tasks. It makes sense that it can keep 30fps or higher.

Whereas we already know that in multiple cases the vtRF module cannot keep up with its 20fps rate because it is too computationally expensive. Especially if you print a lot of stuff on the terminal (which is known to slow down considerably the execution of a module).

alecive commented 8 years ago

The only way to workaround that is to: 1) reduce verbosity 2) optimize the module 3) change the skinGUI to keep information for more than 1 frame (which I don't like honestly).

pattacini commented 8 years ago

@matejhof I would then remove lots of verbosity first.

Flickering is always a bad effect we shouldn't have.

matejhof commented 8 years ago

Ok, I thought @pattacini was suggesting that by looking into the writing and reading on the two ends, there might be some options. If that is not the case and we simply need to ensure that the sender is running fast enough, then we can close this (and keep an eye on optimizing vtRF thread).