{{Page in progress}}

'''''<big>Work in progress</big>'''''

Grip Force paradigm is the measurement of the pressure applied on a small sensor held in hands in Newton. In this paradigm, we are looking for the unconscious micro variations of this force which is in millinewton. The sensor evaluates grip force through electrical measurements. Additionally, since we are looking for micro-variations, the electrical noise of the experimental setup also needs to be evaluated.

= Characterise the noise =

== For the cell ==

=== TIPPA ===

Hold the sensor and release it slowly above a box of foam until it drops. After doing it multiple times, retrieve drop dynamics.

<blockquote>
Recording force variations in the order of millinewtons requires meticulous attention to both protocol design and sensor calibration. Numerous sensor models exist, and they can be customised by research teams, such as with aluminium plates, as in our study, or with plastic or metal alternatives, potentially altering measurements. Therefore, it is crucial to characterise the sensors used in studies to accurately document the experimental setup and ensure replicability. However, it is impractical to analyse every sensor’s surface adhesion properties, ease of grip, or individual characteristics such as skin texture and sweat levels. In this study, we introduce TIPPA, a methodological contribution aimed at optimising signal quality and facilitating study replicability. During the preparation of this study, we asked ten participants (laboratory colleagues) to hold the grip force sensor between their fingers (see Figure 2a) and then release it as gradually as possible over a box filled with foam cubes until it falls. This operation was repeated ten times. We obtained a signal with a relatively consistent dynamic (resembling a droplet shape, or "tippa" in Finnish, see Figure 2b), from which we extracted several characteristics: peak height, grasp dynamics, average duration of the first phase (first release), the second relaxation phase (slow release), and finally, drop value. We believe these characteristics (detailed on Table 2c) complement those typically presented in the literature ([45]) to construct the "physical signature" of our sensor.
We encourage future Grip Force research projects to adopt similar practices to cross-analyse the impact of sensor configuration on the type of measurements obtained.

<gallery>
Tippa lyon.png.jpg|Drops
</gallery>
</blockquote> (Capra & Berthaut, Submitted)

=== Confort ===

Record the confort value for X participants when holding the sensor during 60 seconds

=== Robot Test ===

Use a robot to push on the cell X times.

=== Controlled weight ===

Grip force measurement with controlled weight of 1g, 2g, ... Compare mean force and variations recorded with the sensor

== For the setup ==

Record Grip Force when the sensor is just put on the table without interaction.

Temporal and frequency analysis

= TIPS =

* The use of a laptop to record Grip Force can add some noise to the recording. It's better to use a desktop computer to get a cleaner signal.
*

2024-02-20T17:13:10Z

Chuck :

Neurethic is a research project in cognitive neuroscience based on an experimental and ethical approach, employing a methodology that includes behavioral, cognitive, and neurophysiological measures. It unfolds along three main axes:

* Neurethic Health addresses the cognitive and emotional issues of patients suffering from neurodegenerative diseases (in particular multiple sclerosis) and neurodevelopmental pathologies.
* Neurethic Interaction studies the neurophysiology of human-machine interaction and the perception of the human element in hybrid interactions.
* Neurethic XR examines the benefits and limitations of extended reality on cognition, especially in learning situations.

The experiments take place in a hospital setting and within the Neurethic Lab, an experimental space equipped with a wide variety of neuro and electrophysiological measurement tools, such as electroencephalography, electrodermal activity, cardiac activity, and eye tracking. The Neurethic Lab also enables the creation of stimuli and immersive environments through extended reality devices.

== Projects ==

[[AAGRIP]] :

description

Accueil

2024-02-20T17:12:33Z

Chuck : Page créée avec « Neurethic is a research project in cognitive neuroscience based on an experimental and ethical approach, employing a methodology that includes behavioral, cognitive, and neurophysiological measures. It unfolds along three main axes: * Neurethic Health addresses the cognitive and emotional issues of patients suffering from neurodegenerative diseases (in particular multiple sclerosis) and neurodevelopmental pathologies. * Neurethic Interaction studies the neuroph... »

Individual pretrial Baseline (IPB)

2024-01-30T10:59:43Z

Chuck :

== Definition ==

The value where we need to put back the participant before the start of trial.

The term of baseline to name this value can be discussed to have the more appropriate and consensual name. We may also call this value a threshold.

== Previous value used in litterature ==
1.5N in Blampain & al., 2018

1.59N males, 1.57N females in Nazir & al., 2017

== New approaches ==
=== Lille ===

value = 80% confort + 20% drop

=== ... ===

Individual pretrial Baseline (IPB)

2024-01-30T10:51:12Z

Chuck :

2024-01-30T10:27:51Z

Chuck :

== AAGRIP ==
[[File:Yoda Grip Force.png|thumb|May the gripforce be with you]]
=== The project ===
on décrit le projet ici ?

grandes questions :
* comment on assure synchro entre image et son d'une vidéo ?
* qu'est ce qui affecte le signal de nos capteurs de force dans notre setup ? Comment on le corrige au mieux ?
* Est ce que les latences observées pour l'affichage des stimuli n'affectent pas nos données ?

[[Baseline]] problem

== Materials or Hardware ==

=== Acquisition Cards ===
NI acquisition cards -> drivers only available on Windows and not on Linux

=== Screen ===
Check the refresh rate of the screen used. The refresh rate may be less than advertised if you don't use a display port cable.

Operating systems usually have a software permanently running to handle the display of the screen. This software can disturb experiment framework to ensure the vertical synchronisation of the screen. On Windows, this software, the Desktop Windows Manager (DWM), prevent the Psychtoolbox to guarantee the constant vertical frame rate of the screen.

=== F/T Sensors ===

Power supply of the computer affects the quality of the signal collected with f/t sensors

=== Arduino ===

=== Troubleshootings ===

== Software ==

=== Experiment frameworks ===
Framework available to build experiment : Psychopy, Psychtoolbox, OpenSesame

Psychopy and OpenSesame rely on Python unlike Psychtoolbox which relies on Matlab.

We chose Psychopy for our project because the package already offers some interesting functionalities such as stimuli pre-loading, interval between frames recording, time blocked until the screen is fully displayed, ... Besides, as it relies on Python, it's easier to custom our script to add hardware and/or LSL trigger.

Stimuli pre-loading is handled with the static component in the builder interface of psychopy and it allows us to avoid the delay between the start of the trial and the launch of the stimulus which will depends on the kind and the size of the stimuls.

Psychopy experiment can be launched by command line if you execute the python file in the psychopy installation folder. Create a python virtual environment with the psychoy package doesn't seems to work to launch experiment in it.

Psychopy have 4 different back-ends to handle video files : ffpyplayer, moviepy, opencv, vlc

*ffpyplayer : bug if there is no sound file or if it's corrupted

*moviepy : lot of errors

*opencv : works even without audio file but if we use the static component to preload the video, the audio part launchs briefly at the preload time.

*vlc : error during the initialisation, it may need additionnal package

(Psychopy seems to keep a lot of things in RAM when you run an experiment multiple times so it may be better to restart it regularly)

You can create your experiment from the builder and generate the python file associated after this. If you want to edit this file to add code not supported by the builder, keep in mind that every time you refresh the python file from the builder, it will erase the modifications made in the file.

Loop element in the builder is transcribed in TrialHandler object in code (you won't find any doc on loop element but you can seek for TrialHandler to know more about options and properties).

It's possible to retrieve the frame index of a movie component which is playing. It may not be useful to detect frame drop because it will always give an answer so it may be a parallel processus which look the frame index at a specific interval.

=== LSL ===

[https://labstreaminglayer.readthedocs.io/index.html The lab streaming layer] (LSL) is a system for the unified collection of measurement time series in research experiments that handles both the networking, time-synchronization, (near-) real-time access as well as optionally the centralized collection, viewing and disk recording of the data.

The core library liblsl is supported on many languages : C, C++, Python, Matlab, C#, Java. We used Python interface with [https://github.com/chkothe/pylsl/tree/master pylsl] library.

You can find explanations and examples on their github for this library.

==== Discoveries ====
If you use the resolve_stream() function to find your stream, the script will wait until it finds a stream corresponding to your research. It's better to use resolve_byprop() which gives us more flexibility and we can specify the amount of time the script should wait until finding a stream or the number of streams we are looking for. You also have the possibility to fetch all the streams available in an array with resolve_stream'''s'''()

Documentation recommends to seek streams by type but you can also look by name or source_id which can be more useful when you are working with multiple streams.

You can do multiple streams in the same script from a single computer but you can't stream and retrieve data in the same script, you will get an error of multicasting.

By default, when you create the object to retrieve data from a stream (StreamInlet), this is made with some interesting arguments. One of these is ''recover'' which is True by default and this means it will try to reconnect to the stream when connexion broke off. This is useful to prevent lost data with connexion problems but the script will freeze until it reconnects to the stream. If you cut intentionally a stream of data while a script was still listening, the listener will freeze. You can prevent this by putting False to the recover parameter at the creation of the StreamInlet or by using the close_stream() function on the listener before the connexion to the stream broke off (''documentation says that this function will drop the data in transmission or in the buffer'').

=== Troubleshootings ===

<ref>Une référence [https://fr.wikipedia.org/w/index.php?title=Pierre-Eudoxe_Dubalen&veaction=edit] </ref>
<references />