How do you control a Kinarm from my favourite experimental toolbox – Psych toolbox?

Short answer: the Kinarm can interface - bi-directionally - with nearly anything so long as that 'thing' can accept analogue or digital inputs or outputs or communicate via UDP. So if you were using Psychtoolbox to access position data from a touchscreen used by the non-dominant hand/arm in a unilateral robot configuration, we would instead recommend you control that touchscreen through your custom task program developed to run the robot. Long answer: We think it is useful to start by explaining our philosophy, in terms of how we have approached the design of the software that controls from the Kinarm. Our goal from the beginning has been to develop a platform that can be used for research. Given the cost of our system, anyone who is purchasing it is going to be doing cutting edge research and therefore doing something new and unique. Which means our platform needs to be incredibly flexible to ensure that it allows our customers to use it in the way that they need to use it. In other words, we have always made design decisions that avoid creating unnecessary constraints on system capabilities. To meet that need, we have deliberately created a system that provides our customers with direct access to all inputs and outputs in real-time (at 4 kHz). For example, in the context of torques/forces, the customer can specify the exact waveform (i.e. force or torque on each motor) on a frame-by-frame basis (i.e. we do not constrain loads to be "viscous" or "square-wave perturbations" or any other limitation). We do provide some sample code that can be used for the more common applications (e.g. viscous loads, or square-wave perturbations) in order to simplify task development for the majority of our customers, but we do not require the use of those sample blocks. In terms of interfacing with other equipment, there are a number of different possibilities, all of which can be bidirectional (i.e. can be used to drive the external equipment or be used to drive the Kinarm). As mentioned above, all of this is available in real-time (at 4 kHz). The most common interface that our customer use is via digital or analog inputs (e.g. via a National Instruments DAQ card). However, we have also had a few customers interface equipment via UDP (for example, neural recordings from an NHP were used to drive Kinarm motion in a BMI application). As another example, when we first developed the Kinarm, we had to write a driver for Simulink to interface with a PCI card. So there really is a wealth of possibilities, but obviously some of these interface approaches require more expertise by the customer than others. At the same time as trying to achieve the above goal, we were also cognizant that very few of our customers are going to have professional-level programming skills (in particular, the trainees who comprise the bulk of our end-users). So we selected Simulink and Stateflow as the development environment, along with Simulink Real-Time as the RTOS, to ensure that we could enable the broadest reach possible for our customers. This environment is much more forgiving to non-professional programmers than something like C, Java or even Python, in particular in the context of being able to run in real-time. For those customers who are more used to low-level programming, the switch to a higher level language such as Simulink can at first seem a bit awkward, but in the long run they typically find that as a manager of a lab, it is far easier to manage their trainees within this approach. All of this runs within the context of our control software called Dexterit-E. While much of the Dexterit-E interface has been designed based on the "typical" experiment consisting of trials and blocks, etc, those "constraints" can be bypassed when making the custom Task Program. As an example, please see this link to show a short video of a video game that a student made for the Kinarm (https://www.youtube.com/watch?v=ENFv9XTpPe4 ). The video doesn't show all of the features, but there are levels in the game, each level ends with a Boss that needs to be defeated, then you can purchase upgrades to your weapons, etc. For more details on interfacing with non-integrated peripherals, see our Custom Task Programming Guide (version Dex 3.9), section 10.3 Analog Inputs, section 10.20 Digital Input/Output, section 10.14 External Data Acquisition system, section 10.16 Accessing KINdata_bus, etc.)