Subject: ZR10 firmware request — retract/stow support for in-flight mounting (video attached) — evaluating for fleet-wide integration
Hi SIYI support,
I’m integrating the ZR10 into a retractable payload bay on a fixed-wing/VTOL platform (currently flying on a Kite3). I’ve already built and flight-tested the mechanical side — a 3D-printed, weighted dummy ZR10 stowing and extending in flight — and it works well mechanically.
The one piece I can’t solve mechanically is on the gimbal firmware side, and I’d like to ask whether SIYI would consider adding it — either as an existing undocumented option, or as a roadmap item.
The problem: The ZR10 is mounted in a bay, retracted 90° from its normal reference orientation. On power-up it needs to complete its self-check/centering sweep before it’s usable, which assumes a roughly normal mounting orientation. Once active, it holds its commanded attitude with continuous motor torque, so it can’t simply be mechanically forced into the stowed position without fighting itself.
What would solve it — two specific firmware asks:
1. Skip startup centering, reuse last-known calibration/attitude reference. A parameter to suppress the power-on self-level/centering sweep and instead load the last stored IMU calibration and attitude reference, rather than re-deriving it live. (Precedent: SimpleBGC/BaseCam controllers already expose this as a standard startup option.)
2. “Stow” command: drive to a specified angle, then hold with reduced gain. A command to actively drive all three axes to a specified stow angle, then switch to a low-stiffness/low-gain holding profile — enough to resist drift, but soft enough that a mechanical retraction isn’t fighting full stabilization authority. (Precedent: Gremsy Studio already exposes tunable per-axis stiffness/gain, so this would be gain-scheduling on an existing control loop, not a new control paradigm.)
Ideally both would be triggerable as a single “stow” command over UART/SDK, so the aircraft’s retract sequence can just send one instruction.
Why this matters beyond my own use case: I’d like the ZR10 (and SIYI’s controller/link ecosystem more broadly) to be the standard I build around and recommend to my customers — but this specific gap is the deciding factor. Whether I standardize on SIYI hardware, and what I recommend to customers evaluating the same integration, currently depends on whether this is solvable. I’d rather build on your architecture than move to Gremsy or another vendor, but I need to know if this is something SIYI is willing to support.
Happy to be a beta tester for any firmware you produce, and to share more detail on the mechanism, bay geometry, or flight video if useful.
Thanks, Vince Hogg - Swale Ridge VTOL