[BUG] Missed rewarded trials due to speed smoothing

[teristam]

Describe the bug Some rewarded trials are omitted

Running environment

• Data in datastore: Teris\FragileX\data\VR\M2_D28_2021-02-17_15-53-49
• Branch: master
• Platform: all

To Reproduce

1. Run pipeline in specified data folder

Expected behavior Number of trials obtained by the pipeline should be the same as indicated in the blender log

Additional context I found that in the above recording, the pipeline only reported having 11 rewarded trials, but in fact the animal received 27 trials as reported in the blender output file Teris2021_20210217_1554.log in the same folder.

Further investigation revealed that it is probably the speed smoothing causing the problem. Red is blender data. Blue is Open ephys data.

The following shows the location of the stop within the reward zone:

Zoomed in view:

In the zoomed in view, we can see that around x point 4150, the animal paused mometarily. This stop was registered by blender and reward is delivered but due to speed smoothing, the speed of the animal doesn't reach the stop threshold in our pipeline.

Currently the speed is smoothed by two ways, 1. 200ms for calculation, 2. using a binned speed at a location to calculate the stop, both will smooth out momentary stops that may have beeen registered by blender.

Possible solution I think the short term solution is to stop the smoothing. The long term solution is really to use the blender output file to determine the rewarded trials directly. Replicating the stop analysis for reward in the pipeline is very error-prone due to the different way the analysis pipeline and blender considered as stop.

Report this bug here so that ppl are aware of it @JunjiHua @HDClark94

[HDClark94]

Hi Teris,

I've noticed this before. I'm reworking on the stop calculation now. On the set up on the 6th floor I've made the speed calculation take an average of speed over the last 100ms rather than 200ms or so that it is on the 5th floor. This helps the mice score when they are running faster so they don't need to stop. Once I've implemented the stops calculated based on the last 100ms I think this might be fixed, as there won't be any smoothening before its calculated.

[teristam]

Hi Teris,

I've noticed this before. I'm reworking on the stop calculation now. On the set up on the 6th floor I've made the speed calculation take an average of speed over the last 100ms rather than 200ms or so that it is on the 5th floor. This helps the mice score when they are running faster so they don't need to stop. Once I've implemented the stops calculated based on the last 100ms I think this might be fixed, as there won't be any smoothening before its calculated.

Thank you! I also see that changing the smooth window to 100ms helps. I think the most important part is to make sure the rewarded trials coming out from the pipeline really match with what the animal actually received in experiment.