1. What the eight-servo Ainekio currently commands#

V1 has two actuators per leg and eight stored joint channels. Its motion library contains 38 named assets, including standing, walking, turning, and expressive poses. The following values were extracted from the current motions-v1.json and checked against all 38 packed .amot files used by the firmware asset loader.

There are three different quantities to keep track of: the controller’s accepted angle range, the angles actually used by a motion, and the assembled leg’s physical travel. The first two are available in these files. They do not supply a measured foot workspace or the mechanical stops of every V1 joint.

The V1 software accepts logical angles from 0° to 180°. The checked S3 configuration uses 100% motion range. Before output, each logical target is mapped through the joint’s calibrated center and direction and checked against its calibrated minimum and maximum. With the default center of 90° and no inversion, the mapping is unchanged; installed calibration can differ.

2. What changes in the twelve-servo mechanism#

V2 has three actuators per leg, but its change is larger than adding a sideways joint to the old pose arrays. Two planar motors control a carrier and a linkage-driven lower assembly; a third rotates the leg sideways at the shoulder. The lower assembly’s angle is not equal to its driving servo’s angle. The new gait needs a geometric conversion between desired foot positions and all three actuator angles.

Supplied September 15 mechanism diagram. Dimensions join pivot centers. F is the foot attachment-bolt datum, not the point where the sole touches ground.

3. Theoretical movement ranges of the current FL leg#

The prepared handoff records the following single-actuator animation intervals. They describe the modeled range study; they are not newly proven absolute maximum travel or measured physical limits. All angles are relative to the saved neutral pose, with the definitions above.

The beta row is a passive output, not a fourth actuator or a direct measure of the knee bend across all carrier positions. Likewise, subtracting the extreme alpha and beta values would combine separate tests and would not establish a usable bending range.

The replacement’s saved verification reports no new modeled contacts across those frames relative to the existing mating overlaps, using a 0.03 mm³ added-overlap criterion. The two input intervals do not define a proven collision-free rectangle. Combined carrier, crank, and shoulder motion still needs checking against the links, screws, housings, chassis, other legs, and ground. No sweep limits for FR, RL, or RR are established by this package.

4. V1 and V2 side by side#

The columns below put the available numbers together while keeping their references explicit. A row compares the same question for each design; it does not assign a V1 channel to a V2 joint.

5. Geometry to carry into the first gait calculation#

The handoff uses Blender X longitudinally, Blender Y downward, and Blender Z laterally. One Blender coordinate unit represents 1 mm. The supplied planning conversion makes body Z point upward:

B = (92.899998, -5.850000, -21.000000) mm in CAD coordinates
x_body =  X_CAD - B.x
y_body =  Z_CAD - B.z
z_body = -(Y_CAD - B.y)

B is the midpoint of the leg-placement datums, not the measured center of mass. The model named world has its own scale; it must not be applied again to the independently rooted robot assembly.

The following is the planar forward model from the handoff. Vectors come from the individual leg’s neutral pivots; angles inside the equations are radians. R(t) is a two-dimensional rotation by t.

P = C + R(theta) (P0 - C)
v = P - O
d = length(v)
a = length(Q0 - O)
L = length(P0 - Q0)            # this leg's coupler length
c = (a² + d² - L²) / (2 a d)
psi = atan2(v.y, v.x) - acos(c)
beta = wrap(psi - atan2((Q0-O).y, (Q0-O).x))

D = O + R(alpha) (D0 - O)
F_XY = D + R(beta) (F0_XY - D0)
F_CAD = H + Rx(h) ((F_XY.x, F_XY.y, F0.z) - H)

H is a point on the shoulder axis. The minus-acos solution is the current assembly branch; impossible circle intersections must be rejected and branch continuity checked along any future trajectory. These mathematical signs are not yet the electrical signs of the twelve installed actuators.

At neutral, the FL foot-bolt datum has Blender coordinates (53.7795, 65.5118, 42.7000) mm, with a 21.7000 mm lateral offset from its shoulder axis. The sole reaches about 9.6 mm farther downward at that pose. The sole rotates with the lower assembly, so subtracting a fixed vertical 9.6 mm at every angle would misplace the contact point. Foot pitch also cannot be assigned independently after solving the foot position.

The supplied IK function returns geometric (h, alpha, theta) candidates. It does not decide which are within calibrated limits, collision-free, stable, or achievable at the requested speed. The changing linkage ratio must also enter the velocity calculation: a Jacobian maps joint rates to endpoint velocity. Modern Robotics explains that velocity relationship.

6. First experiment to define — no gait result yet#

The next calculation needs a specific geometry and contact model before it needs a gait name. The following questions remain open for this journal:

For a no-slip stance model, a planted contact stays fixed in the world while its coordinates relative to the moving body change. Swing then brings the foot to its next contact. The contact assumptions belong in the calculation, alongside geometry and timing; they cannot be inferred from a pose animation. MIT’s treatment of planning through contact provides the background.

The first trial record should identify the exact leg revision, candidate stance and path, solved joint sequence, any rejected poses, contact assumptions, and the outcome. Later physical entries can add observed fit, slipping, clearance, repeatability, and loaded behavior. Until those experiments are performed, this entry remains the range comparison that precedes them.

Sources and checks for this entry#

The V1 source is Slave/software/assets/seed/motions-v1.json in the Ainekio repository, compared with motions-bin-v1.json and its 38 packed assets. Channel order, calibration mapping, and playback were checked in protocol.h, servo.c, motion_service.c, and the S3 configuration. The range table summarizes explicit targets; it does not measure interpolated physical motion or establish the current contents of a connected controller.

The V2 baseline is the September 15 robot-leg-motion-20260915/agent-handoff package, measured from Part024-Replaced-With-Part026-Motion-Updated.blend. Its neutral pose is frame 1 of the saved file. The handoff records an unsaved live scene at frame 182; mesh and nonanimated-transform agreement was checked there, but live animation curves were not compared. This entry uses the saved study.

For this entry, the geometry calculator was rechecked against all 505 saved animation-plan frames, with maximum foot-datum disagreement of approximately 0.000006 mm. Inverse recovery, four neutral positions, and eight mathematical shoulder round trips passed. This is numerical agreement with the prepared data. Blender collision checks were not rerun, and no hardware was commanded.

• Range analysis and source hashes (JSON)
• V1 ranges for every motion (CSV)
• Supplied per-leg geometry snapshot (JSON)
• Full-size mechanism diagram

The V2 build guide records parts and assembly iterations. The printed-leg update contains the physical prototype photographs and fit work that led into this motion study.

Starting target and contact assumptions#

The selected research target was 20 mm world advance per eight-second cycle, with a 5 mm sole-clearance target and one second of swing. That gives an 87.5% stance fraction. The 10 and 30 mm cases bracket the selected target; none is an optimized or hardware-approved stride.

These angles are offsets from the compact neutral, not V1 logical degrees or PWM values. In this model, the stance bolt sweep equals world advance times the stance fraction: 20 × 0.875 = 17.5 mm. The assumed body speed for that case is 20 / 8 = 2.5 mm/s. This is an input to the isolated calculation, not measured robot speed.

The sole height was obtained from the rotated full foot-shell geometry rather than a fixed offset below the bolt. That improves the lift calculation, but the stance model still holds the bolt’s world X stationary under assumed constant body speed. A rotating rounded foot can move its contact point, so this does not prove a no-slip stance.

Recorded results and their limits#

Each case contains 161 target poses, for 483 poses in total. The record reports closure on the existing linkage branch and return to the starting joint angles. Sampled checks against the other link plates, servo cases, mount, horn references and foot shells found no intersection above 0.02 mm³. Intended hardware interfaces and the rest of the body were excluded.

The saved-file check evaluated 22 Blender poses per case and found a maximum sole-height difference from the target of about 0.000021 mm. These small numerical errors describe agreement within the model. They do not measure print accuracy or actual foot tracking.

Whole-body shifts, support margin, stance slip, continuous collisions, loaded servo speed and torque, calibrated travel and print strength were not verified. The probes were not installed as a complete walking animation. Later upright assemblies retain the compact lengths, but their full-body gait needs its own validation rather than inheriting these single-leg results.

Experiment data#

• 20 mm starting target and assumptions, JSON
• All three probes, CSV
• Motion validation and scope, JSON
• Compact-leg geometry and saved-file report
• Earlier versus compact articulation comparison

These dated source checks were reviewed for the September 21 journal update, not rerun. The earlier V1/V2 tables remain the September 15 comparison; the newer probe table adds a different mechanism and a stated contact model.

Next experiment on the chosen body#

Record the exact upright or angled assembly, map its twelve actuators, and retarget the chosen foot path. Then add body shifts and support calculations, check the complete shell and cable envelope, and compare the results with a printed leg under measured load. Each new result should identify its geometry, contact assumptions and whether it came from calculation, Blender or hardware.

The mechanism used for this demonstration#

This entry uses the upright 24/38 revision on all four legs. It should not inherit the dimensions or validation results of the September 19 22/36 study.

The geometry snapshot records the transfer of the refined front-left mechanism to the other three legs. Its Blender labels are unusual: RL means physical front-left, RR front-right, FL rear-left and FR rear-right. The downloadable schema retains both names so the motion channels can be mapped deliberately.

Two controls, with different effects#

Stride % changes the nominal planted fore–aft sweep. At 100%, that sweep is 92 mm; at 25%, it is 23 mm. Motion rate changes the common clock: 1× gives a 1.8-second cycle and 2× gives a 0.9-second cycle. Changing rate at a fixed stride retains the same geometric path rather than scaling joint angles.

For stride fraction p = Stride % / 100 and motion-rate multiplier r:

planted sweep S = 92 × p mm
body advance per cycle L = S / 0.7 mm
cycle period T = 1.8 / r seconds
nominal forward speed v = L / T = 73.015873 × p × r mm/s

The 0.7 divisor is the stance fraction: body advance over the whole cycle is larger than the body-relative sweep during the planted portion. These are commanded geometric quantities, not measured ground speed.

These examples come from the exported stride/rate grid. The video visits 25% at 1×, 100% at 1× and 100% at 2×, with smooth transitions between them. The 25% at 2× column illustrates the independence of the controls; it is not a separate segment of this clip.

What happens during the fourteen-second sequence#

All twelve joints, body sway and contact states use one continuous gait phase. Quintic curves join the control settings smoothly. Body travel is integrated over phase, while elapsed time is calculated from the changing cycle frequency. The joint pose closes at the end; world travel resets when this finite clip repeats, and the presentation camera follows the body through that reset.

Keeping planted references in place as stride changes#

The planner predicts body travel over each upcoming stance and places the next touchdown anchor accordingly. Its rearward bias is 30/92 of that predicted stance travel. At a steady full stride, the nominal planted endpoints are +16 mm forward and −76 mm rearward from the original standing reference. At a steady quarter stride they scale to +4 mm and −19 mm. Transition anchors use the predicted travel, so they can differ from these steady endpoints.

A foot already in stance keeps its world XY reference until liftoff. During swing, a smooth path joins the old and new anchors with zero world XY velocity and acceleration at the endpoints. Lift is chosen for that swing. This avoids moving a planted reference merely because the stride setting changed.

That reference is attached to the rigid foot, but it is not always the material point touching the ground. The solver checks the lowest part of the full sole hull. The faceted sole can rock and the contact point can migrate; fixed reference coordinates therefore do not prove physical traction or zero slip.

Blender controls and the integration data#

The saved ainekio-variable-gait.blend contains the Gait - Stride and Rate scene and Gait playback layer. Its Ainekio > Gait sidebar exposes Stride %, Motion rate, Build steady gait and Build ramp demo. The steady option creates four cycles. The ramp begins at a quarter of the selected stride and half the selected rate, then reaches the selected settings and returns. Rebuilding runs the numerical solver before replacing the gait curves.

The exported demonstration contains 3,889 samples over nine cycles, lasting 14.007649 seconds. Sampling is uniform in phase, not time: the effective rate changes from about 240 to 480 Hz as cadence doubles. Consumers must use the actual timestamps in the CSV. These are source samples; the supplied video is a 210-frame presentation at about 15 fps, and the Blender playback spans 420 frames at about 29.984 fps.

The joint columns are signed geometric radians relative to Blender neutral, not PWM values or calibrated electrical angles. Across this specific demo, the recorded joint demands span:

The roughly 1,283°/s peak is an animation demand, not demonstrated loaded servo capability. A real-time command/replanning loop, embedded kinematics, channel mapping, calibration and usable speed limits remain integration work.

Checks completed, and what they establish#

The collision screen excludes complete containment, between-sample collisions, the full chassis and shell, all hardware and neighbouring-leg interactions. It cannot establish unrestricted clearance for the assembled robot.

The contact schedule has two or three grounded feet, with no all-four-foot stance samples. The assumed-centre-of-mass calculation reaches a static support margin of −60.47 mm. Static balance is therefore not established; the mass model, support strategy and dynamics need further work. These findings belong alongside the successful linkage and timing checks when choosing a physical trial.

Download this revision#

• Stride-and-rate grid (CSV): nominal settings and timing, not a validation of every combination.
• Timestamped twelve-joint trajectory (CSV, 4.11 MB) and column/units schema (JSON).
• Geometry snapshot (JSON), numerical arrays (NPZ) and results (JSON).
• Planner source (Python), control-check source (Python) and recorded control results (JSON).
• Saved-file validation (JSON) and collision screen with its exclusions (JSON).
• Source report and filenames, transformations and checksums.

Workspace prefixes are shortened in the published records. The large Blender project and its linked libraries are not included in these downloads. The earlier comparison videos and percentage measurements in the working folder describe preceding control revisions; this entry uses stride-and-rate-v3.

Walk, Run, Crawl and Crab#

Normal Speed coordinates stride and cadence. Advanced controls expose those quantities independently. The dashboard supports direction, ongoing operation, finite cycle counts and Finish. A settings update keeps the active gait’s phase; Finish completes active swings and settles the feet. Emergency output disable is a separate action. Finish before selecting a new direction or gait; automatic Walk/Run blending is the supported exception.

Sweep is the modeled planted-foot path relative to the body, not automatically the distance traveled in a complete cycle. The Crab row explicitly reports per-cycle travel, a different quantity. These are planner settings, not measured speed, traction, jump height or physical robot performance.

Speed zero requests Finish. For automatic Run, 150% gives approximately a 0.514 s cycle and 200% gives 0.45 s. Crossing the Walk/Run boundary blends the contact pattern over four gait cycles; feet already in stance retain their anchors. These short periods are mathematical timing targets, not a claim that loaded servos can track them.

Crab now has six ongoing directions: left, right, forward, backward and two turning directions. The planner enters its wider stance over three seconds, one foot at a time. Finish holds that stance. Full-stride Crab turning specifies 32.73° per cycle in the model; it is not a measured final heading. V2’s eight old fixed-angle turn clips were removed from firmware. V1 keeps its existing fixed turns and finite Crab asset.

Reviewed expressions and posture distinctions#

The current firmware catalog has 23 finite gestures/postures alongside the algorithmic gaits. These revisions preserve different intentions rather than using one lying-down pose for every command.

The full video at the top of this journal was exported before the latest Worm, Shrug, Play Dead and six-direction Crab revisions. It shows the preceding choreography and evolving appearance; it is not a visual verification of every current command. The current range download is taken from the newer sources.

Calibration and the deployed application#

Body Control now exposes channel mapping, direction, model reference angles, pulse conversion, Home and explicit Save. Saved values belong to the individual body. Commanded pulse readback is not feedback from a joint-position sensor. Mapping edits and Save disable outputs; deliberate Home/move actions engage them. The output controller checks linkage closure and bounds entry transitions.

The latest CONTROLLER_VALIDATION.md records:

Those are recorded development results, not checks rerun on the robot for this website entry. Earlier deployment and offline sections refer to their own application checkpoints. Previous hardware bench observations used two unloaded servos with no linkages.

Range data and geometry revisions#

The new V1/V2 comparison includes motion envelopes, processing and power arrangements. Download the current per-joint motion ranges and extraction script. The script reads source files only; it issues no robot commands.

The runtime geometry still identifies the upright 24/38/24/55 mechanism from September 21. The September 23 scene synchronization and September 24 support widening are later Blender work. Updating appearance or placement in Blender does not regenerate controller geometry or qualify the changed body automatically. The body and battery entry records those packaging changes and the remaining reconciliation.

Sources: V2 model README.md, motions/gestures/catalog.json, gesture records, locomotion configuration, the dashboard controls and CONTROLLER_VALIDATION.md in the local robot checkout after 3f872e7; Blender motion-export and expressive-motion records. The source manifest identifies the exact files and hashes used for this entry.

Lower working references, unchanged gesture paths#

The continuous gaits were revised to improve linkage leverage while retaining the established solver. These signed body-reference values belong to the planner’s geometry; they are not measured chassis-to-floor heights.

Walk retains its 92 mm sweep, 30 mm rearward bias and 14 mm lift. Forward Run retains its 104 mm maximum sweep. Crab establishes its first anchors over two cycles, with three for backward movement. Its steady travel, stance width and cadence are unchanged. Crawl enters from the revised walking-ready pose. Named Stand and the 23 compiled gestures retain their existing paths; Stand is distinct from the continuous gait’s working reference.

The recorded offline full-sole check covers 14,391 robot poses, including speed changes and Finish. Maximum horizontal foot error is 0.000070 mm; minimum output transmission angle is 46.61° in planned stance and 37.57° in swing, with at least 3.13 mm extension remaining. These are sampled geometric results for the controller model. They do not establish torque, traction, continuous collision clearance or the fit of the subsequently narrowed body.

Two different speed controls#

Saving the named-motion value stops outputs through the existing controller; starting a subsequent motion resumes operation. The setting has its own four-byte storage record and does not rewrite joint calibration. A value above 3× is valid for this control even though advanced gait cadence has a separate 3× maximum.

What the deployment record proves#

Production-controller tests exercise all 23 clips at several rates up to 12×. Those numbers test time scaling; they are not recommended assembled operating speeds. Higher-rate frame timing, physical shaft tracking and loaded gestures remain unmeasured. The recorded application SHA-256 is 50a9092e3cde37a7c2644820f6e5082e2b5de29be79cac8f89b556fca0e9eaed.

Next: response to the body, not just changing a command#

Variable stride and speed are implemented. Response to tilt is a separate feedback problem. The proposed loop is LSM6DS3 samples → attitude estimate → local P4 gait correction → existing servo output controller. The sensor is reported received; its driver, installation and active correction loop have not been verified. Initial targets are 208 Hz acquisition and 50 Hz servo updates, subject to implementation and physical testing.

ROS 2 can help expose and record this telemetry through a Q6A adapter. The fast correction loop remains local to the P4 for either build option. See Wired, Wireless and ROS 2 for the planned software responsibilities and current implementation stages.

The latest compact Wireless model in Blender uses a different front/rear placement and rear shoulder-clearance study. Neither moving the legs in Blender nor passing the older controller-model checks synchronizes or qualifies that assembly. The mechanical journal records the 82.5 mm frame, remaining refit work and separate calibration references.

Sources: the captured CONTROLLER_VALIDATION.md, robot commit 270537f and its integration/budget records, plus the dated Blender reviews. The source manifest identifies the September 28 snapshot. These results were read from development records; no hardware tests were rerun for this website entry.

Shared model and new candidate#

The candidate now includes all 23 named motions, with 31,031 source/preview samples in the Blender motion library. It has not replaced the shared model or been installed in firmware. The detailed motion entry records the per-motion changes, including adjusted Sit/Rest landings and refitted body paths, alongside the preserved timing and choreography.

What still fails or needs physical evidence#

Separately, the committed controller uses a 96 mm full Walk sweep, 8.85 mm Walk lift and −8 mm body offset. Continuous Crawl has a −22 mm body offset, 18 mm sweep and up to 4 mm lift. The named Crouch gesture retains a −35 mm terminal body translation; it is a different motion. Automatic movement uses a common joint-speed limit that can stretch timing without shortening the path.

The IMU estimator is now implemented in source. Sensor acquisition and balance correction are not connected to it yet. The software entry also records continuous steering, ROS desktop checks and the hotspot result, including the failed sustained-session test. The rebuild entry documents the physical result and structural/power response.

Sources: the October 6 manifest identifies the reviewed controller files, local research handoffs and Blender images. Physical observations and improvement estimates are Greg’s October 6 report; the earlier entries above retain their original dates and assumptions.