Learning a coordinated rhythmic movement with task-appropriate coordination feedback

Abstract

A common perception–action learning task is to teach participants to produce a novel coordinated rhythmic movement, e.g. 90° mean relative phase. As a general rule, people cannot produce these novel movements stably without training. This is because they are extremely poor at discriminating the perceptual information required to coordinate and control the movement, which means people require additional (augmented) feedback to learn the novel task. Extant methods (e.g. visual metronomes, Lissajous figures) work, but all involve transforming the perceptual information about the task and thus altering the perception–action task dynamic being studied. We describe and test a new method for providing online augmented coordination feedback using a neutral colour cue. This does not alter the perceptual information or the overall task dynamic, and an experiment confirms that (a) feedback is required for learning a novel coordination and (b) the new feedback method provides the necessary assistance. This task-appropriate augmented feedback therefore allows us to study the process of learning while preserving the perceptual information that constitutes a key part of the task dynamic being studied. This method is inspired by and supports a fully perception–action approach to coordinated rhythmic movement.

Appendix: coordination feedback algorithms

In this section, we describe two algorithms to implement coordination feedback. Algorithm A is the best solution for a situation where there is a reference target (i.e. a pre-specified oscillator) and was used in the current experiment to produce the colour change. Algorithm B is still of use, however, especially in bimanual experiments where there is no reference target. Pilot work for the current experiment used Algorithm B to generate the feedback, which succeeded in driving learning.

Algorithm A: compute virtual target dots

This algorithm takes advantage of our standard experimental task, which requires participants to move a dot on a monitor at some mean relative phase to a computer controlled dot. The computer controlled dot’s position is therefore a determined (sine) function of time, and it is trivially easy to generate two virtual dots moving according to the same function as the dot to be tracked, plus or minus some mean relative phase. This allows participants to be leading or lagging and still be getting the feedback (of course, if the experimenter had a preference, the feedback could be toggled to only occur in one direction). Once one knows precisely where the person should be at that instant in time, one then tests to see whether the person is within that specified error range from that location and toggle the colour accordingly. This check takes about 10 lines to implement in Matlab and no significant time to execute, making it viable for real-time feedback.

Algorithm B: compute relative phase online

The other method is to compute an estimate of relative phase in real time. If the dots are moving at the target relative phase (plus or minus some error bandwidth) then the colour of the dot is toggled. This method is noisier, but does not require a reference signal; we describe it here, because it will be of use to research involving bimanual movements.

The phase of an oscillator is computed (after normalizing the velocity and position) as

$$ \Upphi = {\text{atan}}\left( {{\text{velocity}}/{\text{position}}} \right) $$

(1)

and the relative phase is simply the difference of the phases of the two oscillators. Position is straightforward, as it is the kinematic variable most commonly recorded directly. Velocity, however, must be derived via numerical differentiation; this amplifies noise, and hence position data is usually low-pass filtered beforehand (something not reliably possible in real time). Differentiation is an averaging process that requires position data from at least three time steps (depending on the algorithm), providing the velocity at the middle time step. Offline analysis allows the algorithm to be centred on the time step in question; computing this in real time means that the algorithm must be centred on a time step from the recent past. This introduces a small constant temporal lag in the velocity computation, i.e. the resulting time series is phase lagged relative to where it should be by an amount proportional to how far back in time the algorithm is centred. Finally, the computation of phase requires certain assumptions (that the required frequency and amplitude of movement are being maintained). To the extent that this is not the case, the estimate of phase and hence relative phase will be inaccurate.

These problems can be ameliorated in several ways, although never entirely removed:

• 1. Minimize the number of data points included in the differentiation algorithm. The basic trade off is that the more data points you include the better estimate of the current velocity you can get, but this estimate is for further back in time. Three data points is the absolute minimum; an acceptable estimate of velocity can be computed using five data points and a central difference algorithm (see Press et al. 2007). Pilot data for the current study successfully used this method. Placing the centre back two samples at 60 Hz created a lag in the velocity estimate of ~33 ms. There was no evidence that this created any significant difficulties for participants.

• 2. Alter the differentiation routine. Differentiation is essentially a process of computing a weighted average of the amount of change in position for a given amount of time, over several discrete samples of position. There are various differently shaped weighting functions available; for instance central difference algorithms weight the centre displacement the most and the weights quickly drop off on either side. This drop-off can be shaped to suit the user’s needs (Press et al. 2007).

• 3. Sample position at a higher rate. The current experiment sampled position at 60 Hz, a limitation caused by the screen refresh rate. It is possible to sample hardware faster than the screen refresh rate with an asynchronous process (e.g. Culmer et al. 2009). This then allows one to sample position multiple times and compute velocity, phase and finally relative phase before the next screen refresh rate. This technique could also then be used to test whether any lag in the feedback from other implementations has any consequences for behaviour. Modern computer hardware should have no particular problems executing this in real time, if programmed carefully.