Portal Development Kit (PDK): this is a development kit.

Uses · Motion research A development kit
for motion research.

Academic motion research asks three things of an instrument: published specifications, repeatable motion delivery and an open interface. The Portal Development Kit (PDK) is a development kit designed with those three in mind; whether it meets your protocol is for your own validation to show.

Development Kit: early-access hardware, software in active development.

A matrix of the properties academic work asks of an instrument: citable specifications, reproducible delivery, an open interface and durability.

Four properties

Published. Scriptable. Open. Direct drive.

Published

Per-axis envelope, encoder resolution and control rates are published, with patent CA 3217174 C as a verifiable reference for the architecture.

Scriptable

A paradigm scripted as commands can be re-run on another unit; validate each unit for your own study. No transmission means no mechanical play between the commanded position and the delivered one.

Open

Software that can write to a network socket, such as PsychoPy, MATLAB, Python, LabVIEW or ROS, can send it commands; building that integration is your work. There is no black box in the command path.

Direct drive

Direct drive has no gearboxes, oil or brushes, the consumable transmission parts of geared hardware.

Three ways to drive it

Pick the tier that matches your team.

Tier 1 — prebuilt

Integrations that already exist over UDP, such as FlyPT Mover, third-party software; what each one covers is up to its maker.

Tier 2 — experimental control

Your control software sends absolute six-axis pose commands — tilt five degrees forward, hold two hundred milliseconds. The Housekeeper, the platform's main controller, handles inverse kinematics and workspace limits.

Tier 3 — bare metal

Direct actuator mode bypasses the inverse-kinematics solver and gives you the six legs. The right tier if you are writing your own parallel-kinematics control.

Verify it yourself

Do not take our latency figure. Measure it.

Manufacturer specifications are a starting point, and a reviewer is entitled to want empirical verification specific to your payload, your integration software and your network.

A workable protocol: tape a photodiode to the visual display surface, bolt a three-axis accelerometer to the platform near the center of rotation, and stream both into a common timebase — Lab Streaming Layer is the usual glue for multi-modal synchronization in experimental psychology. Trigger a step, and the interval between the photodiode edge and the onset of platform acceleration is your motion-to-photon figure for your configuration.

We are describing the method and claiming no result for it. Our own latency figure is under 1 ms, from the game's telemetry reaching the platform to the actuator moving — the boundary a reviewer would ask for is stated on /technology/latency/. If your measurement disagrees with anything we publish, we would like to see it.

Institutional use: contact us.

Keep reading

Medical and vestibular

The neighboring page, for work where motion is the stimulus rather than the apparatus.

21-bit encoders

The measurement chain your data ultimately rests on.

Talk to us

For a question a page cannot answer.