The global stop-motion record Stop Motion Database

camera

Arc: motion control and robotic arms in Dragonframe

Dragonframe

Sourced 1 source on file ยท Needs a second independent source to corroborate.
Spotted an error? Suggest a correction โ†’

Definition

Arc is Dragonframe's motion-control workspace: it maps external hardware -- stepper-driven sliders and pan/tilt heads, and now six-axis robotic arms -- onto channels that can be zeroed, jogged, and keyframed against the exposure timeline, so a camera or puppet move plays back exactly the same way on every single frame.

Overview

Arc's basic unit is the axis. Each physical mechanism -- a slide, a pan head, a robotic joint -- is assigned to a channel that can be homed to zero, jogged manually, and keyframed over the shot's frame count; the workspace's own development log tracks this as ordinary configuration work ("When adding a new axis, the channel bumps past the last one assigned") and lets an operator read back exactly what a move will do before shooting it ("Arc: position and velocity graphs can be scaled vertically"). Dragonframe also exposes Arc's channels to outside control surfaces over OSC (Open Sound Control), adding messages "to set axis limits, zero, and home" so a move can be triggered or synced from a separate console rather than only from inside Dragonframe itself.

The newest expansion is direct support for six-axis robotic arms from Universal Robots (UR) -- industrial cobots, not bespoke motion-control rigs -- connected over UR's own RTDE (Real-Time Data Exchange) network protocol. Dragonframe's changelog documents this as a working, actively-debugged feature rather than a demo: entries add "UR robotic arm support," describe a "fixed hang in RTDE client when connecting to invalid IP address," fix "UR virtual jog-on-line speed and direction," and note an "attempt to account for servo jitter" -- the kind of fix list that only exists once real hardware is being driven in real time. Dragonframe's own label for animating a subject with this class of continuous, motor-driven movement is go motion: "Arc: Enabled go-motion with robotic arms" -- shooting with the rig itself in motion during or between exposures, rather than only repositioning a static rig frame to frame.

Folding an industrial cobot arm into Arc changes what "motion control" can mean for stop motion: the DMC-32 rack unit already on Dragonframe's own hardware side (see Dragonframe) drives simple stepper channels for slides and heads, while a UR arm adds multi-joint reach and repeatable complex paths -- the kind of move that would otherwise need a bespoke rig built for one shot. Because this is dev-branch functionality rather than a documented studio credit, no production is yet named as using Arc's robotic-arm mode; that is a real gap, not a settled fact, and is left for the next production-sourced update rather than assumed.

Workflow

  1. Assign each physical mechanism (slide, pan/tilt head, robotic joint) to an Arc channel and home it to a known zero position before shooting.
  2. For a UR robotic arm, connect over the network via RTDE and verify jog direction and speed on a virtual/test move before it drives the physical arm on set.
  3. Keyframe the move's positions against the shot's exposure count, then read the position and velocity graphs to check the interpolated path before committing frames.
  4. Where an outside console needs to trigger or sync the move, drive Arc's axis limit, zero, and home messages over OSC rather than operating Dragonframe's own interface directly.
  5. Capture the sequence exposure by exposure, watching for the hardware-side symptoms the changelog itself flags -- e.g. servo jitter on a robotic joint -- rather than assuming a keyframed path plays back mechanically perfectly.

Related

Techniquesmotion control / stop motion / live view capture

Links