OpenViBE forum

The OpenViBE community
It is currently Mon Dec 17, 2018 4:32 am

All times are UTC




Post new topic Reply to topic  [ 5 posts ] 
Author Message
PostPosted: Wed Oct 10, 2018 8:26 am 
Offline

Joined: Tue Mar 13, 2018 12:39 pm
Posts: 12
Dear all, recently I've tried to use the continuous wavelet analysis box as a feature generator for motor imagery BCI scenarios. My use case was similar to using FFT for that purposes, I did not really care about the timing of the features (relevant pieces of the EEG signal are selected using the 'Stimulation based epoching' box). For that purpose, I put together a simple python box that aims to re-arrange the CWT time-frequency output into chronologically sorted frequency bins (generated by the CWT).

You can find the box here: https://github.com/xskola/notes-on-openvibe. It requires one setting, 'Number of frequencies' (set it to correspond to your CWT setting) and can handle arbitrary number of channels. Nevertheless, the code is very simple and probably will require some adjustments for future utility.


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 19, 2018 8:49 am 
Offline

Joined: Tue Dec 04, 2012 3:53 pm
Posts: 772
Location: INRIA Rennes, FRANCE
Hi Xskola, thanks for the idea and the link! It'd be interesting to know if you got improved results from it in comparison to some baseline features (which?).

Cheers,
Jussi


Top
 Profile  
Reply with quote  
PostPosted: Wed Nov 07, 2018 2:25 pm 
Offline

Joined: Tue Mar 13, 2018 12:39 pm
Posts: 12
I actually run into some problems while trying to use this box in practice and I would like to ask you for your opininon on this.

I have an MI scenario with feature extraction using CWT + the mentioned python box, nothing really special going on there. I can sucessfully train the classifier (both on Linux and Windows) and I can also start the online scenario on Linux.

However, if I try to use this as online scenario on Windows, I run into a weird lagging issue. Basically, the time in designer starts having regular lags each second, related to the length of chunk in Time based epoching. With 1s epochs spaced 0.25s apart, I can still run the scenario, but I get past the realtime. With shorter epoch spacing, the scenario hangs after the first second. With 0.25s epochs 0.25 apart, the scenario runs fine in the beginning, but after a minute or so, it stops and freezes openvibe completely.

Also it is strange that this happens only if I "read" the data from classifier processor using matrix display or TCP writer with connected other end (scenario runs fine when TCP box is connected but client is not connected to the stream, or when there is no connection from classifier processor output). The lagging is also less prominent (can handle larger epochs/shorter intervals) when I use CSV writer to gather classifier results (caching?).

Number of frequencies in CWT nor clock frequency in Python box influence this issue.

I would be happy for any pointers how to get around this issue!

Many thanks,
Filip


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 08, 2018 10:32 am 
Offline

Joined: Tue Mar 13, 2018 12:39 pm
Posts: 12
Correction: the issue is present on Linux (Debian) as well, just the epoch intervals can be multiple times lower (4-16x, depending on whether acquisition server or generic stream reader is used) to show this issue.

My thought was this is happening due to decomposition of 3- to 2-dimensional matrix in data from CWT, and too many chunks being inserted to the data stream, but limiting CWT output to just 1 frequency don't really change properties of the lagging.

Is it maybe just because of performance limitations? I can see Openvibe fully using one core on my CPU. It would still be strange that OV performance is that different on different OSes (on the same computer).


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 15, 2018 11:13 am 
Offline

Joined: Tue Dec 04, 2012 3:53 pm
Posts: 772
Location: INRIA Rennes, FRANCE
Hi,

you can try clicking the 'i' button next to the system load to see which box openvibe thinks is causing the lag. Maybe this reveals something.

Also, you can read the generic scenario debugging instructions from here,

http://openvibe.inria.fr/tutorial-troub ... scenarios/

The key steps are to identify which box causes the lag and why. One reason could be if some box forwards, receives or stores a massive or increasing amount of data. This could be the case for example when a downstream box doesn't tell the kernel that its done with the input (does not mark it as 'deprecated'). The EBML stream spy can be used to investigate how much data goes through some specific link.


Hope this helps,
Jussi


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Americanized by Maƫl Soucaze.