mcvain / bci-simulator

Code For: Closed-loop motor imagery EEG simulation for brain-computer interfaces
https://doi.org/10.3389/fnhum.2022.951591
BSD 3-Clause Clear License
1 stars 0 forks source link

Some problems encountered when running your code. #1

Open Adouvvv opened 1 year ago

Adouvvv commented 1 year ago

Hello author, I apologize for bothering you. When running your code, I encountered the following errors. I hope you can provide an answer. Thank you very much!

_errors:Traceback (most recent call last): File "D:\Python项目\pythonProject18\bci-simulator-main\main.py", line 750, in main() File "D:\Python项目\pythonProject18\bci-simulator-main\main.py", line 569, in main step_velocity_vector, true_vel_x, true_vel_y = playerStepCapturerSprite.update(frames, runno, TypeError: cannot unpack non-iterable NoneType object

The error says that when I call the Update function in the playerStepCapturerSprite variable, the parameters are not passed correctly.

mcvain commented 1 year ago

It seems that either pygame has changed how the update function works, or I was using a different build and I forgot to note it. Either way, sorry it didn't work out of the box. First, please note that the project was done on pygame==1.9.6 and, as far as I remember, there were major behavior changes from pygame ver. 1 to 2 due to reasons that I don't remember too clearly.

That being said, you could, as a temporary measure, edit the update function(s) in pygame's sprite.py to:

def update(self, *args, **kwargs):
    for sprite in self.sprites():
        return sprite.update(*args, **kwargs)

which should work since playerStepCapturerSprite is a GroupSingle i.e. can only contain one sprite. I know it's not a pretty solution - if I end up with some spare time, I could write an update to fix this issue without touching pygame. Do let me know if you have any more doubts.

Adouvvv commented 1 year ago

I’m sorry to bother you again. Based on your reply, I made the following improvements to the code, but unfortunately it still couldn’t run successfully. Therefore, I would like to ask if you have any other methods.

Firstly, I tried to improve the source code in sprite.py according to your method, but the same error still occurred. Secondly, I installed pygame 1.9.6, but the same problem still occurred.

After that I checked the output and found that the problem lies in this code:

*_class PlayerStepCapturer(pygame.sprite.Sprite): def init(self): global screen_width, screen_height pygame.sprite.Sprite.init(self) self.radius = int(screen_width 0.1 * 0.5)

    self.image = pygame.Surface((self.radius * 2, self.radius * 2))
    self.image.fill((255, 255, 255))
    self.image.set_colorkey((255, 255, 255))

    self.rect = self.image.get_rect()

    self.rect.x = screen_width // 2 - self.radius
    self.rect.y = screen_height // 2 - self.radius

    self.pos_t1 = (screen_width // 2 - self.radius, screen_height // 2 
                                                                                     - self.radius)
    self.pos_t0 = (screen_width // 2 - self.radius, screen_height // 2                                                                                                                                                                                   
                                                                                     - self.radius)

def update(self, frames, run_no, target_no, true_vel_x, true_vel_y):
    self.pos_t1 = pygame.mouse.get_pos()
    step_velocity_vector = (self.pos_t1[0] - self.pos_t0[0], 
                                                            self.pos_t1[1] - self.pos_t0[1])

    self.rect.x = self.pos_t1[0]
    self.rect.y = self.pos_t1[1]

    self.pos_t1 = (screen_width // 2 - self.radius, screen_height // 2 
                                             - self.radius)  # reset back to midpoint
    pygame.mouse.set_pos(self.pos_t1)

    true_vel_x[run_no][target_no].append(step_velocity_vector[0])
    true_vel_y[run_no][target_no].append(step_velocity_vector[1]
    return step_velocity_vector, true_vel_x, true_vel_y

def update(self, *args, **kwargs):
     for sprite in self.sprites():
          return sprite.update(*args, **kwargs)_**

It returns a None value after the second for loop. Hope you can reply to me when you are free. Thank you very much for your kind assistance!

mcvain commented 1 year ago

I'm a little confused now. Did you add a second definition of update() to the class PlayerStepCapturer? That wouldn't work. My suggestion was to replace the update() in your pygame's sprite.py that was causing the original error "TypeError: cannot unpack non-iterable NoneType object". You can find it by right-clicking on the word update in step_velocity_vector, true_vel_x, true_vel_y = playerStepCapturerSprite.update(frames, run_no, target_no, true_vel_x, true_vel_y) and navigating to its definition.

Adouvvv commented 1 year ago

Thank you for your patient explanation. The problem has been resolved. Besides that, I would like to ask you two question about 他the simulation experiment

_1、 during the simulation experiment phase, when running the code, is it necessary to complete all 10 sessions (each session consisting of 24 trials of hitting the target) before generating the simulated EEG signals? Because when I tried one session, there were no simulated EEG signals generated in the corresponding folder. 2、 Is it normal for the values in the "correct_order" and "incorrectorder" lists outputted by the computer to be the same for each experiment?

Hope you can reply to me when you are free. Thank you very much for your kind assistance!

Adouvvv commented 1 year ago

I used your code to complete this simulation experiment, but the output is some CSV files containing PlayerPathX, PlayerPathY, TrueVelX, TrueVelY, CorrectTarget, etc., and I did not get the simulated EEG signals mentioned in the paper.

mcvain commented 1 year ago

EEG signals are generated for the purposes of simulating the BCI experiment, but they are not saved. As for correct_order and incorrect_order, these are internal variables for blockwise randomization of trials and should not be exactly the same every time you run the experiment. But there is nothing preventing you from getting the same pattern by luck.

As mentioned in the paper, accurate simulation of EEG was not really within the scope of this project (see "Study limitations and future work"). This is why there would not be much value in recording the simulated EEG datasets for further use, because it is not expected to work beyond this very limited experimental paradigm of 1D/2D motor imagery BCI. However it is true that being able to examine the simulated EEG would be nice. This function existed in one of the previous versions, I will try to dig it up and update if I can. But if you are looking for ways to simulate very realistic EEG, the abovementioned section in the paper could help with getting started.