Using CWT for motor imagery feature generation

Concerning processing components: filters, file load/save, visualizations, communication ...
Post Reply
xskola
Posts: 12
Joined: Tue Mar 13, 2018 12:39 pm

Using CWT for motor imagery feature generation

Post by xskola »

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.

jtlindgren
Posts: 778
Joined: Tue Dec 04, 2012 3:53 pm
Location: INRIA Rennes, FRANCE

Re: Using CWT for motor imagery feature generation

Post by jtlindgren »

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

xskola
Posts: 12
Joined: Tue Mar 13, 2018 12:39 pm

Re: Using CWT for motor imagery feature generation

Post by xskola »

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

xskola
Posts: 12
Joined: Tue Mar 13, 2018 12:39 pm

Re: Using CWT for motor imagery feature generation

Post by xskola »

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).

jtlindgren
Posts: 778
Joined: Tue Dec 04, 2012 3:53 pm
Location: INRIA Rennes, FRANCE

Re: Using CWT for motor imagery feature generation

Post by jtlindgren »

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

Post Reply