Saturday 21 October 2017

What Limits the Accuracy of Human Throwing?

Throwing a projectile in order to hit a target requires you to produce one lot of the set of release parameters that result in a hit; release angle, velocity (speed and direction) and height (relative to the target). My paper last year on the affordances of targets quantified these sets using a task dynamical analysis.

There is one additional constraint; these release parameters have to occur during a very short launch window. This window is the part of the hand's trajectory during which the ball must be released in order to intercept the target. It is very easy to release slightly too late (for example) and drill the projectile into the ground.

How large is this launch window? It is surprisingly, terrifyingly small; Calvin (1983) and Chowdhary & Challis (1999) have suggested it is on the order of 1ms. Those papers used a sensitivity analysis on simulated trajectories to show that accuracy is extremely sensitive to timing errors and this millisecond level precision is required to produce an accurate throw.

Smeets, Frens & Brenner (2002) tested this hypothesis with dart throwing. If this intense pressure on timing the launch window determines accuracy, then throwers should organise their behaviour and throw in a way that makes their launch window as tolerant of errors as possible. They replicated the sensitivity analyses on human data to see if people try to give themselves the maximum error tolerance in the launch, or whether they were trying to accommodate errors in other variables.

What they found is that the launch window timing is not the limiting factor. Their throwers (who were not especially expert) did not throw so as to minimise the sensitivity of the launch window timing to errors. Quite the contrary; they lived in a fairly sensitive region of the space, and then didn't make timing errors. They did throw so as to reduce the sensitivity to speed errors, however, and errors in the targeting came from errors in the spatial path of the hand that the system did not adequately compensate for, rather than the timing of the hand's release. (The authors saw some evidence that the position, speed and direction of the hand trajectory were organised into a synergy, which aligns nicely with the motor abundance hypothesis).

I would like to replicate and extend this analysis process using more detailed simulations and data from better throwers. I've become convinced it's a very useful way to think of what is happening during the throw. I also think these results point to some interesting things about throwing. Specifically, while timing and speed must both be produced with great accuracy, the system has developed two distinct solutions to coping with errors. Timing errors are reduced by evolving neural systems that can reliably produce the required precision. Speed errors have been left to an online perception-action control process which adapts the throw to suit local demands. The latter is the more robust solution; so why was timing solved with brain power?
Why Worry about Speed Errors?
The fact that people do not work to minimise their sensitivity to timing errors is very intriguing. Throwing is sensitive to timing errors, but the human throwing system is simply happy in it's ability to not make those errors. This connects to Calvin's hypothesis about the evolution of speech off the back of throwing. He suggested that we evolved neural systems capable of supporting this level of timing in throwing and then borrowed those to support the similar levels of timing precision required for speech. (We are currently testing this idea with our PhD student Michael Collins - stay tuned!).

So what is the system worried about? Errors in the trajectory of the hand as it heads towards release during the launch window. There were directional errors at release that led to directional errors on the target (although no sensitivity analysis was possible on this parameter). Speed was the big one; the sensitivity of accuracy to a speed error decreased as time passed in the throwing action, making later throws more stable. This is the opposite to timing sensitivity, where late is bad. Good throws (by better throwers or worse throwers after some practice) had a relatively late release.

Why worry about speed? Well for one, generating a fast throw is hard. All the energy that the projectile is going to get comes from the large slow trunk muscles (or for darts, the relatively large upper arm and shoulder area). These muscles pre-load elastic tendons which then release that energy fast during the throw (Roach et al, 2013). That energy has to be transferred at high speed and with minimal loss from limb segment to limb segment down the kinetic chain from more to less massive components, until it is transferred into the projectile. Part of the intense timing pressure in throwing is timing these transfers so that no energy is wasted moving the limbs incorrectly. There are many opportunities to mess this up, and people do. Smeet's et al's data suggests that controlling this kinetic chain is harder than timing the release (for a human throwing system, anyway) and so people work to keep that under control.

Two Solutions
Actually, there are two solutions being implemented. Timing is hard. Speed is hard. There is no single solution; throwing in a way to minimise timing sensitivity increases speed sensitivity and vice versa.
  • Timing seems to have been solved neurally; we evolved systems that can support the required timing so reliably that we simply tend not to make errors, even if the risk of them is technically high. 
  • Speed seems to have been solved with a perception-action control process; we learn to throw in ways that reduce the sensitivity to speed errors and organise the trajectory control into a synergy that works online to actively correct errors in one parameter with adaptations in the others.
All this suggests that timing errors could not be solved in a real time perception-action control process and so evolution built a device that could manage the required precision. Speed errors can be solved in real time, so evolution left perception-action to handle it. The latter is actually optimal - an efficient control process keeps you flexibly adapted to local conditions. 

The Advantages of Controlling Speed in Real Time
A real-time, just-in-time perception-action control process is always more stable than any pre-planned solution. By staying in contact with how your action is unfolding relative to the task goal, you can flexibly and adaptively correct errors and cope with local task variations. This idea is embodied in uncontrolled manifold and similar analyses.

However, perception-action control processes need information to stay in their manifolds. There is proprioceptive information about the hand's trajectory, but I suspect visual information about that trajectory is more important. When the hand swings into view, you have information about both it and the target affordance in the same reference frame. Smeets et al argue that perception is not fast enough to be doing this online and suggest some kind of predictive process. Perception can be that fast, though, and the obvious experiment would be to trigger occlusion of the hand at various points in the throw to see when vision is clearly being used.

UCM analysis (or similar) could help here. You can track the ratio of 'good' to 'bad' variability throughout a movement, and when feedback control is not currently possible bad variability increases without being corrected. If feedback control then becomes available (e.g. when the hand swings into view) the  that bad variability should begin to plummet. I have some data that will give me some hints here, but the occlusion experiment remains to be run.

The other reason to control speed is that I now believe it is the key variable for defining the launch window. Regardless of release angle, there is a critical minimum speed required in order to cross a given distance to a target. The launch window open when that speed is achieved, and closes when either the speed drops back below that threshold or the required release angle becomes impossible to achieve. So given that you must be monitoring it in order to time the release, you might as well actively control it

So the question becomes, why can timing not be solved in real time? I don't know for sure. One obvious place to start is the idea that there is no information available for the timing of release. That release has to occur within the launch window, but that isn't specified in terms of time; as I note above, I think that window is defined by speed. So I think the problem faced by the system is 'as soon as the launch window opens begin releasing the ball' and the critical demand is a fast response, not fast prospective control. The other idea is that given all the reasons speed can and must be kept stable, this leads to throws where speed sensitivity is low but timing sensitivity is high, and the system has no choice but to cope with that fact. Much more to do here!

Summary
This paper and the associated analyses has really got me thinking in detail about the internal structure of a throw and what is actually entailed in producing an accurate projectile motion. I plan to replicate and extend these simulations and analyses with my own data sometime soon. 

References
Smeets, J. B., Frens, M. A., & Brenner, E. (2002). Throwing darts: timing is not the limiting factor. Experimental Brain Research, 144(2), 268-274.

1 comment:

  1. From the point of view of a non expert on the literature but experience of shooting and sons' high level archery and basketball:
    The key to a release or shot is a prerehersed and preestablished rhythm. Importand very carefully timed stuff goes on for a second or two before the release window.

    I'd like to see you comment on this 3 min clip from Sundays world archery mens final. 10 ring is 12.2 cm wide, 70m away. It is gusty which affects the flight of the arrow and buffets the archer as he tries to aim. How do the archers compensate in real time, particularly in view of the comments at 1min 50sec: https://youtu.be/nzq_lSBmS9g

    Robin

    ReplyDelete