Buffer Conditions for fixed Targets

Forum for discussion on different user applications
Locked
aloplop
Posts: 41
Joined: 03 Sep 2008, 07:20

Buffer Conditions for fixed Targets

Post by aloplop » 16 Jan 2009, 04:07

Hi,

In the application I want to use (the modification of the Cursor Task Feedback),
two targets should be positioned on the edges of the screen,
but they should be fixed so there´s no random appearance.

In my case, the cursor moves just in the X direction, so the Buffer conditions
for the Normalizer must be introduced in the first column of the matrix.

However, I don´t know what boolean conditions would fit the best for
that kind of application in order to update the gain and offset values
.

What do you think ??

Thanks.

gschalk
Posts: 615
Joined: 28 Jan 2003, 12:37

Normalizer ...

Post by gschalk » 20 Jan 2009, 15:03

aloplop,

I do not know what state variables you have for your modified task. However, what you want to do it seems like is to center the cursor in X, i.e., have the control signal be the mean of the signals during movements to the right and to the left target. Assuming TargetCode==1 is left target and TargetCode==2 is right target, and Feedback==1 during cursor movement, you would use

(Feedback)&&(TargetCode==1)
(Feedback)&&(TargetCode==2)

Gerv

aloplop
Posts: 41
Joined: 03 Sep 2008, 07:20

Post by aloplop » 21 Jan 2009, 04:18

Hi,

Thanks for your response, but those conditions are the same than in the
Cursor Task, where the target appears randomly.

In the one I want to use, the cursor is centered in the screen and moves along
the X direction to the target on the left or the right.
The next week I´ll try the same conditions of the Cursor Task (what you have proposed) and using just (Feedback).

I´ll comment the results I obtain.

Thanks again,

Alvaro

gschalk
Posts: 615
Joined: 28 Jan 2003, 12:37

Buffer conditions ...

Post by gschalk » 21 Jan 2009, 08:27

Alvaro,

This is correct. It is the same, except in your task you need to adapt the first (X) control signal, whereas in the existing configuration we want to adapt the second (Y) control signal.

As you describe, in your application you want to center the cursor movement in X, i.e., you want to make the first control signal zero mean for the movement periods (Feedback==1). Thus, you could just use Feedback==1 if the target frequency is the same between left and right. If the target Frequency is different, e.g., 10 times to the left and 1 time to the right, just averaging the signal during all movement periods would effectively make it harder and harder to go in one direction (since you are averaging 10 left periods and only one right period). In such a case, you want to use the two conditions I mentioned. Then, you have two independent buffers, one for left target and one for right target, and the final calculated mean is in between both. Thus, this will also be correct in case target frequency is not equal.

Gerv

aloplop
Posts: 41
Joined: 03 Sep 2008, 07:20

Post by aloplop » 22 Jan 2009, 04:34

Hi,

Gerwin, your response is very clarifying, so thank you very much once again.

Regards,

Alvaro.

aloplop
Posts: 41
Joined: 03 Sep 2008, 07:20

Results

Post by aloplop » 06 Feb 2009, 05:20

Hi again,

Finally, I performed some sessions with the fixed targets in the
application I developed to control a Wifibot and a video Camera.

Previously, I had made some tests in order to adjust the parameter
FeedbackDuration in CursorTask, using for the MaxFeedbackDuration
parameter the double of FeedbackDuration, and for the BufferLength of the
Normalizer, three times the value of FeedbackDuration.

At the end of those tests, we decided that the values should be 5s for FeedbackDuration,
10s and 15s for the other 2 parameters, in order to minimize errors, although there where some invalid or aborted trials.

The fact is that I tried to perform some sessions using this configuration and the Adaptation turned on in the Normalizer.
However, it cost me a lot to control the cursor. Sometimes it was almost impossible to move the cursor to one of the edges.

Furthermore, with those parameters I adapted the offset and the gain of the
Normalizer using the original CursorTask indicating the new positions for
the targets and configuring the classifier and Normalizer in order to
control the X axis, for at least 20 - 40 trials. Afterwards, I turned off the
Adaptation and tried to control the cursor in the Application for the Robot
with the two fixed targets.
In this case, I could control the cursor well, despite the fact that sometimes
it cost me a bit more to control the cursor to one edge than the other. This
aspect is translated in some aborted trials rather than "errors" in the
movement of the robot.

Using the second setting I performed 100 runs where I had to control the cursor to execute
some movements of the robot and the camera.
I supposed that an error was executing a wrong movement of the robot or the camera.

My results:

- 56/100 I completed the 29 "checkpoints" (not necessarily in 29 trials, sometimes a few more).
- In average, I have been able to control the cursor for 327 seconds
without obtaning an error.
- In average, I have completed 23/29 "checkpoints".

With Adaptation I just performed 20 runs because I obtained poorer results:

- In average I could only complete 8 "checkpoints" and 170 seconds without
an error.

So the question is:

- Why using adaptation I obtained poorer results??
Shouldn´t have I obtained better results??


If you have any doubts please, post a reply.

Thanks,

Alvaro.

gschalk
Posts: 615
Joined: 28 Jan 2003, 12:37

Adaptation ...

Post by gschalk » 06 Feb 2009, 06:57

Alvaro,

Do you have UpdateTrigger set to an appropriate trial condition? This should be set to some indicator of a trial.

Also, it seems like your trials are much longer than in the original configuration. Thus, you should set the BufferDuration to a period that is longer than a trial.

In either case, this is most likely a configuration error. It's difficult to give you a better answer without the actual parameter file and without knowing about your task and how you encode the task-related events in states.

Gerv[/i]

aloplop
Posts: 41
Joined: 03 Sep 2008, 07:20

Post by aloplop » 06 Feb 2009, 07:05

Gerwin,

for the Update Trigger I had:

Code: Select all

Filtering:Normalizer string UpdateTrigger= (Feedback==0) // expression to trigger offset/gain update when changing from 0 (use empty string 
About the duration, they last 10 seconds at max:

- FeedbackDuration: 5s
- MaxFeedbackDuration: 10s
- BufferLength in the Normalizer: 15s

This is because I made some tests using some FeedbackDurations and I obtained the best result for this configuration using a Matched Filter to my Mu-Rhythm at 11 Hz.

Maybe the system is not well configred at all. If you want more details I can send you an email.

Thanks again,

Alvaro.

gschalk
Posts: 615
Joined: 28 Jan 2003, 12:37

Normalizer ...

Post by gschalk » 06 Feb 2009, 07:13

Alvaro,

From what you write, these settings seem to be similar to what's used in the CursorTask. You also write that the adaptation works fine in the CursorTask. Thus, the question is: what is different? One possible reason could be that your task does not encode the targets appropriately (or at all) in certain states (e.g., TargetCode), or the BufferConditions are not appropriately matched to whatever target encoding you have. I bet if you changed the BufferConditions to
[1] (for 1D) or [1 1] (for 2D), then it will work right away (although not quite as good as if you adapted on the targets). See

Continuous 1D Control without pre-defined Targets

in the Normalizer documentation.

Gerv

aloplop
Posts: 41
Joined: 03 Sep 2008, 07:20

Post by aloplop » 06 Feb 2009, 07:24

Gerv,

the unique thing that changes from the Cursor Task application is that the
targets are fixed in the X axis:

Code: Select all

Application:Targets:CursorFeedbackTask matrix Targets= 2 { pos%20x pos%20y pos%20z width%20x width%20y width%20z } 95 50 50 10 100 8 5 50 50 10 100 8 // target positions and widths in percentage coordinates
I changed the Buffer Conditions as indicated in the wiki:

Code: Select all

Filtering:Normalizer matrix BufferConditions= 2 1 (Feedback)&&(TargetCode==1) (Feedback)&&(TargetCode==2) // expressions corresponding to data buffers (columns correspond to output channels, multiple rows correspond to multiple buffers)
So, maybe for this kind of application should be better to use the
adaptation continuosly. However, for my application it seems that
the output values won´t appear with equal frequency:

- If the cursor hits the right target you select a movement.
- If the cursor hits the left taget you execute a movement.

Thanks.

gschalk
Posts: 615
Joined: 28 Jan 2003, 12:37

Normalizer again ...

Post by gschalk » 06 Feb 2009, 09:13

Alvaro,

What you describe seems OK. We recently fixed an issue with the Normalizer that produced incorrect adaptations in certain circumstances. Can you please update to the most recent version of BCI2000 and let us know whether this fixed your issue?

Thanks.

Gerv

aloplop
Posts: 41
Joined: 03 Sep 2008, 07:20

Post by aloplop » 06 Feb 2009, 09:55

Hi,

maybe in the next week I´ll try the new version of the normalizer.

Thanks for all your interest.

Alvaro.

aloplop
Posts: 41
Joined: 03 Sep 2008, 07:20

Post by aloplop » 16 Feb 2009, 05:36

Hi again,

I updated the BCI2000 software to the latest version (revision 2280).

I used the conditions I suggested in the last posts but changing the
FeedbackDuration to 4 seconds, MaxFeedbackDuration = 8s
and BufferLength = 12 seconds in the normalizer.

I made some tests and the online operation was almost good. Maybe,
in the tests I had made, the problem was that I used 5 seconds (quite
a long duration). As I commented previously, with the Adaptation
turned on the movement was,sometimes, very hard. So, I had to adapt
the gain and the offset of the normalizer and then turn off this adaptation
to make the tests for my project.

I don´t know what are exactly the fixes you have done in the normalizer
but it seems now it works ok. In my opinion, there should be a commitment
between speed of the cursor and number of fails. Very long trials can be worse although
a person obtains less error %, because the mental effort
is higher. I hope this new version of the normalizer will help in the future
experiments.

Thanks.

Álvaro

gschalk
Posts: 615
Joined: 28 Jan 2003, 12:37

Adaptation ...

Post by gschalk » 16 Feb 2009, 20:50

Alvaro,

This is a big reason why doing BCI research is pretty difficult.

From a signal processing perspective, results should get better with longer trials (since more data are averaged). However, as you point out, the subject may simply not be able to produce the appropriate signal for extended periods of time.

Gerv

Locked

Who is online

Users browsing this forum: No registered users and 11 guests