Pneumatic Artificial Muscle Actuator

These two share geometry, manufacturing process and force model. Only the fluid differs, which makes the comparison sharp.

1. 1.Force density. Incompressible fluid supports higher pressure in the same braid, so the muscle meets the force target at a diameter that fits under clothing.
2. 2.Control fidelity. Pump displacement maps to contraction, with no compliance between command and force. This is what makes reactive IMU triggering feasible at all.
3. 3.Power unit size. A small pump and reservoir beat a portable compressor on mass, volume and noise.

The result holds for weight changes of about 5 percentage points. It does not survive a doubling of the weight on portability, where Bowden cable overtakes, or on durability, where hydraulic falls behind both alternatives.

D₀ is resting braid diameter, P gauge pressure, ε contraction ratio, θ₀ resting braid angle from the muscle axis. At zero contraction this reduces to the blocked force πPr₀²(3cos²θ₀ − 1)/sin²θ₀.

• •Force falls as the muscle contracts, reaching zero at θ = 54.7 degrees. Size the muscle so the working range sits where force is still useful.
• •Force scales linearly with pressure and with the square of diameter. Diameter is limited by what fits under clothing, so pressure is the available lever.

The model is ideal. Real hydraulic McKibben muscles produce roughly 15 to 25 percent less, because of bladder wall elasticity, braid friction and end effects. Always validate against a load cell, and never quote modelled force as measured force. For burst risk, back calculate pressure from measured force and braid angle rather than reading force alone.

Molding rather than extrusion or dipping gives repeatable wall thickness and integrated end geometry, which is what makes the assembly seal at high pressure. Sequence: dry the material, load the barrel, inject into the closed tool over a core pin, hold under packing pressure, cool in tool, eject and strip from the pin, trim and inspect.

• •Wall thickness sets both burst pressure and parasitic stiffness. Thicker walls survive more pressure but absorb input energy and reduce net contraction.
• •Thickness must be uniform. A thin spot becomes the burst point.
• •The bladder must be longer than the braid at rest so it never carries axial tension. The braid carries the load, the bladder only seals.

A dedicated machine wraps fiber around the molded bladder. Hand braiding does not hold a consistent braid angle, and braid angle is the most influential geometric parameter in the force model. Mount the bladder on a mandrel, thread the fiber through the tensioner and guide eye, set the ratio between mandrel rotation and carriage traverse (this ratio sets the braid angle), run the first helical layer end to end, then reverse the traverse to lay the opposing helix and form the lattice.

Braid angle trades force against stroke. A shallow angle relative to the axis gives high blocked force and short stroke. An angle near 54.7 degrees gives long stroke and almost no force. Pick it from the required contraction in Table 1, not by convention.

Fittings seal the bladder, clamp the braid so it carries axial load, and provide the anchor point. Most hydraulic McKibben failures happen here. Insert the barbed fitting into the bladder end, fold the braid back over the bladder and fitting shoulder so braid tension is reacted by the fitting rather than the bladder wall, crimp over the assembly, then pressure test before fitting anything to the suit.

• •Isometric. Fix both ends with a load cell in series and a pressure transducer at the inlet. Step pressure to operating pressure in ten increments, hold 10 s each, repeat three times. Plot force against pressure and compare the slope to the blocked force model.
• •Isotonic. Hang a fixed load, repeat the pressure sweep, record length change. Repeat at several loads to build the force to length surface.
• •Dynamic. Command a step change in pump duty while logging force and pressure at high rate. Measure the time from command to 90 percent of steady state force. Repeat in reverse, which will be slower.

The dynamic test is the highest priority experiment in the project. Under about 100 to 150 ms of lag, reactive IMU triggering is sufficient. Above it, the system must predict the next gait event rather than react to the last one, and the control architecture changes.

The original actuator was a Nanjing Ouruike G312XP brushed DC gear motor. It was replaced by a brushless system, currently an XH 4250BL 300KV motor from Guangdong Xinhui Transmission Technology with its paired XHCD controller, driven through an OIDelec OID-RS485-200W FOC controller. Four factors drove the change.

Speed regulation under varying load. A brushed motor run open loop slows as load rises. Pump load rises continuously as the muscle pressurizes, so commanded duty and delivered flow drift apart exactly during the stroke that matters. Field oriented control with Hall feedback holds commanded speed as backpressure builds, which makes pump displacement a usable proxy for muscle contraction.

Reversing duty. The reciprocal architecture reverses direction twice per gait cycle. Brush and commutator wear accelerates under repeated reversal, and gearbox backlash has to be taken up on every reversal before flow resumes. That lost time adds directly to the forward and reverse timing asymmetry described below, on top of the pump asymmetry.

The IMU requires the channel index, the sign convention and the mounting orientation to be established before its output means anything, and any change in strap position between sessions changes the sensor frame. A camera measures limb geometry directly in world coordinates. Thigh angle read from hip and knee positions is the same quantity every session, regardless of how the suit was donned. The camera also produces its own visual record, so every detected event can be scored against video offline without a separate ground truth sensor.

Two qualifications on the calibration argument. First, the camera moves the setup work rather than removing it: camera position and height, sagittal alignment, marker or landmark selection, lighting, and the pixel to angle scaling all have to be repeatable. Second, IMU calibration here is a one time code fix, confirming a channel index and a sign, not a per session procedure. The stronger arguments for the camera are the visual ground truth and the immunity to strap shift, not the absence of calibration.

Recommendation: run the camera as the primary trigger for bench and treadmill work, log the IMU on the same clock throughout, and compare event times between the two. That comparison gives the IMU trigger its validation for free, and keeps the deployment path open. If a camera is wanted for deployment, it has to be body mounted, which reintroduces sensor ego motion and a mounting frame, and removes most of the advantage in Table 10.

Fix the camera on a tripod at knee height, optical axis perpendicular to the plane of progression, 2 to 3 m from the subject, framing hip to floor on the affected side. Lock exposure, gain, white balance and focus, since auto exposure changes the frame interval and destroys timing consistency. Prefer 60 fps at low resolution over 30 fps at high resolution: the event timing depends on frame rate, not pixel count. Record the mounting geometry so the setup is reproducible.

Landmark selection was resolved during implementation, and it did not land on markers. camera_gait_trigger.py runs on MediaPipe Pose directly, through the "solutions" API by default with a fallback to the newer "tasks" API when solutions is unavailable, at a selectable model complexity of lite, full or heavy. Full is the validated default. Landmark smoothing is on by default, which stabilizes the signal at a cost of 60 to 100 ms of added lag; turning it off lowers latency but changes the noise floor, so the onset threshold needs re-tuning if it is disabled. Both legs are tracked every frame, hip, knee and ankle, so leg mode can switch between auto, left and right at runtime with no remounting. The marker pipeline below is retained as a fallback if pose estimation proves unreliable once the exosuit is worn.

The implemented signal is a height, not an angle, which is a change from the original plan. Camera output is a lift value, hip height minus knee height, normalized by torso length rather than by hip to ankle length, since torso length holds steady while the leg moves. A calibration phase captures the standing baseline first, so standing reads 0.00. Velocity is a least squares slope fit over a rolling window of timestamped samples. Because lift is a height and the IMU gyroscope measures an angular rate, the two sensors no longer output the same quantity; validating one against the other now needs a shape and timing comparison, not a literal overlay.

Detect knee lift onset as lift velocity crossing a threshold in the flexion direction, confirmed over several consecutive samples rather than one, with a refractory period afterward before the next onset can fire. Trigger on velocity rather than on lift height. Height crossing a threshold happens later in the movement, and the latency budget in Table 12 has no room to spare.

This is the constraint that decides whether the camera works as a trigger. FR-4 allows 150 ms from gait event to 90 percent of assistive force. The optical path spends part of that budget before the pump has even been commanded. Two contributions are now fixed by code rather than estimated: the velocity fit adds about half of its window's span, roughly 40 ms at the default of 5 samples and 60 fps, and landmark smoothing, on by default, adds a further 60 to 100 ms. Both are switches in the script, not fixed properties of the camera.

If the optical path alone consumes more than about 60 ms, the camera cannot be the deployment trigger regardless of its other advantages, because the hydraulic lag has to fit in the remainder. Measure before committing.

Do not claim a trained classifier or a detection accuracy figure in any report, poster or CV until walking data has been collected and scored against video. Describe the current method as threshold based optical detection.

Two WitMotion WT9011DCL-RF units stream at 200 Hz and 460800 baud over separate USB radio dongles, so each appears as its own COM port and no demultiplexing is needed. Driver is CH341SER.EXE v3.9. Frames start with header 0x55, flag 0x61, then nine signed 16 bit values parsed with the struct format "<9h" as acceleration, angular rate and angle. The thigh unit on COM5 feeds leg_gait_trigger.py; the shank unit logs knee angle. GYRO_PITCH_INDEX and the sign convention are still unconfirmed. Confirming them costs one printout and gives the camera an independent cross check, so do it even though the camera is now primary.

Written and running as camera_gait_trigger.py v2. Two things changed from the original specification: pose estimation replaced colored markers, and the motor runs off a single NI DAQ digital line instead of the Modbus registers leg_gait_trigger.py uses. Both are called out below, item by item against what was specified.

1. 1.Capture. Matches the specification. Opens the camera, forces MJPG, fixed resolution and frame rate, locks exposure, gain, white balance and focus. Capture runs in its own thread holding only the newest frame, so the detector never processes a stale one. Every frame is timestamped at grab time on a monotonic clock.
2. 2.Landmark extraction. Built on MediaPipe Pose in place of the HSV marker pipeline. Both legs are tracked every frame, hip, knee and ankle on each side, plus the shoulders for a torso length reference. Auto mode follows whichever knee lifts higher, with a hysteresis margin so it does not flip on a small reading difference. Pose estimation needs no marker prep or lighting tuning, at the cost of tens of milliseconds per frame instead of a few.
3. 3.Signal. Built as a lift value, hip height minus knee height, normalized by torso length rather than hip to ankle length, and referenced to a standing baseline captured during calibration so standing reads 0.00. Differentiated over the timestamped samples, not over frame index, since frame intervals are not perfectly uniform.
4. 4.Filtering. The velocity fit is the filter: a least squares slope over vel_window timestamped samples, default 5. Window length is a named, logged parameter, and it trades noise against delay directly, about half its span in added lag.
5. 5.Event detection. Built as its own three state machine, idle, rising, hold, rather than imported from leg_gait_trigger.py. Onset fires after several consecutive samples above vel_on. A stroke ends at apex, velocity at or below apex_vel once a minimum on time has elapsed, or at max_stroke_s, whichever comes first. A refractory period follows before the next onset can fire.
6. 6.Command output. This is the largest deviation from the specification. The pump runs off a single NI DAQ digital line, run or stop only, no reverse and no duty value. Stroke size is set entirely by how long the line stays asserted, capped by max_stroke_s. leg_gait_trigger.py instead writes SWING_DUTY and STANCE_DUTY to Modbus registers on a reversing pump. Reconcile the two motor interfaces before running both trigger scripts against the same pump.
7. 7.Safety watchdog. Built as two independent guards rather than one. A stall watchdog stops the pump if the main loop stops calling pet() within watchdog_timeout_s. A stroke overrun watchdog stops the pump if a burst runs past 1.5 times max_stroke_s, in case the DAQ line failed to release. The pump also stops on lost tracking, on a leg swap mid stroke, on pause, on recalibration, and on emergency stop, which latches until reset. Also stops on keypress and on any unhandled exception, in a finally block.
8. 8.Logging. Matches the specification. One CSV row per frame: timestamp, phase, active leg, lift, left and right heights, velocity, state, pump state, event, tracked flag, fault. The on screen overlay draws the skeleton, meters and event trace live; writing it out to an annotated video file is not yet built.
9. 9.Modes. Dry run is the default and matches the specification; --live must be passed explicitly to command the pump. --selftest toggles the DAQ line a few times with no camera, to confirm wiring polarity before trusting anything else, which the original specification did not call for but bring-up needed. The LED or screen flash latency test mode in the specification is not built yet, so the optical path latency in Table 12 stays unmeasured. A replay mode does run the full pipeline over a recorded video, so thresholds can be tuned without a subject present, matching that part of the specification.
10. 10.Configuration. All thresholds live in one Config dataclass, overridable from the command line, and a run prints its full configuration at startup. HSV bounds no longer apply. Writing the configuration to disk alongside each log file, so every trial is reproducible from its own record, is not yet built.

Build and test it in this order: replay mode on recorded video first, then dry run live with the pump disconnected, then --selftest to confirm DAQ polarity, then live with a short max_stroke_s. Do not connect the muscle until the event timing looks correct in dry run.