XM10 Extension Module SDK v2.6.0¶

Release date: 2026-08-20 | Boards: Rev 1.1 · Rev 2.0 | Bundled KIT H10 firmware: v2.4.0

At a glance¶

A release focused on safe behavior.

Turning control off actually turns it off. Returning to MONITOR now ramps torque to zero and confirms zero before output stops.
The board restarts itself if the firmware hangs. A hardware watchdog (about 8 seconds) was added.
forwardVelocity is fixed. It was reporting 60× the real value.
Safety handling was reworked in 15 examples. Example numbers and what they teach are unchanged.
KIT H10 firmware moves to v2.4.0.

For Rev 1.1 this is the first update since v2.5.0 (v2.5.1 was Rev 2.0 only).

Three things to check¶

1. Returning to `MONITOR` now takes 0.3–0.6 s¶

Previously, XM_SetControlMode(XM_CTRL_MONITOR) made XM10 stop transmitting on the spot. Because the H10 holds the last command it received when new ones stop arriving, torque could still be applied after you thought you had switched it off.

Now torque is ramped smoothly to zero → zero is sent several times over → vectors are released → output stops. During that window (typically 0.3–0.6 s) your torque commands are ignored.

To stop immediately, call XM_EmergencyDisengage() — it goes straight to zero with no ramp.
To read the state actually in effect, use XM_GetAppliedControlMode() (CONTROL / MONITOR / TRANSITION).
In MONITOR, no control command of any kind leaves the board — neither torque nor vectors.

2. `forwardVelocity` becomes 60× smaller (this is the correct value)¶

XM.status.h10.forwardVelocity was reporting 60× the real value. Walking at 1 m/s now reads about 1.0.

If you only displayed it — nothing to do.
If you fed it into control — you may have compensated with a very small gain. Re-tune it.
Previously recorded data holds the 60× value. Do not mix it with new data.
The stopped-detection in Ex.22 · 23 · 24 · 26 now works. The forwardVelocity < 0.1 condition was effectively never true before, so those examples always behaved as if walking.

3. Staying inside one call for over 8 seconds resets the board¶

The watchdog is refreshed on the 1 kHz cycle that runs Control_Loop. So if Control_Setup or Control_Loop takes more than 8 seconds, the watchdog restarts the board. Split long work into steps.

Tasks created with XM_Task_CreateOneShot() / XM_Task_CreatePeriodic() run at a lower priority than Control_Loop, so this does not apply to them. Move heavy computation there (see Ex.36).

⚠️ A watchdog is not an emergency stop. If your code keeps running while commanding the wrong torque, the watchdog does not fire. In wearer trials, a person stopping the suit is the primary safety net — see Wearable Safety.

New APIs¶

API	Purpose
`XM_EmergencyDisengage()`	Zero torque immediately, no ramp
`XM_GetAppliedControlMode()`	Read the control mode actually in effect
`xm_api_safety.h`	Safe-torque helpers — `XM_SafeTorque_*`, `XM_SafeAssistLevel()`, `XM_SafeIsFresh()`

xm_api_safety.h is already pulled in by xm_api.h, so no extra #include is needed.

One name changed¶

The mode covers P/I vectors as well as torque, so XM_CTRL_TORQUE became XM_CTRL_CONTROL. The old name remains as an alias for the same value, so existing code builds unchanged. Examples and docs now use the new name — use XM_CTRL_CONTROL in new code.

static XmSafeTorque_t s_safe;

void Control_Setup(void) {
    /* limit 2.5 Nm | at least 500 ms from 0 to the limit | 500 ms soft-start */
    XM_SafeTorque_Init(&s_safe, 2.5f, 500U, XM_SAFETY_DEFAULT_RAMP_MS);
}

void Control_Loop(void) {
    /* reject bad values -> clamp -> soft-start -> slew limit */
    float t = XM_SafeTorque_Step(&s_safe, my_desired_torque);
    XM_SetAssistTorqueRH(t);
}

When you switch control off and back on, call XM_SafeTorque_Reset(&s_safe) to restart the soft-start. Call XM_SafeTorque_Step() exactly once per tick in Control_Loop.

Examples¶

What	Which examples
Soft-start and slew limiting so nothing jumps when assist turns on	Ex.14 · 21 · 27 · 30 · 33
Removed the jolt caused by a step change in the setpoint	Ex.14
Broken stop-switch wire reads as stop · output clamps · stop ramps · stale-sensor timeouts	Ex.06 · 13 · 17 · 26 · 32
Blocks entry into control before homing completes	Ex.11 · 12 · 15 · 35 · 36

Running them without wearing the suit¶

Ex.15 · 21 · 30 · 33 are tuned for a person wearing the suit. On the bench, with the leg hanging free, the much lower inertia makes them oscillate or diverge. The example is not broken.

Each of those files carries bench parameters at the top. Substitute the mass and center-of-mass of the link alone (0.184 kg / 0.1264 m) and they behave predictably.

Downloads¶

File	Board
Rev2.0.zip	XM10 Rev 2.0 (has an RJ45 Ethernet port)
Rev1.1.zip	XM10 Rev 1.1 (no such port)

Files attached alongside¶

File	Purpose	Changed?
`AGR_Bootloader.bin`	XM10 bootloader (installed over SWD)	Updated — recovers on its own from a corrupted config area
`SUIT_H10_Binary_20260820.zip`	KIT H10 (CM · MD · ESP32) firmware	Updated — CM · MD v2.4.0 (ESP32 unchanged)
`SUIT_ContentsFiles_20260820.zip`	KIT H10 content files (motions, sounds)	Same content (filename now carries the date)

Bootloader: v2.6.0 firmware runs fine on the older one. This guards against a board that will not boot at all, so it is recommended, not required. → Bootloader Upload
KIT H10 firmware: update it from a USB stick. → KIT H10 Firmware

The final build step uses Python. If you have not installed it, follow Software Setup to install Python 3.10+ (adding it to PATH is required).

Compatibility¶

Item	Impact
Your `Control_Setup` / `Control_Loop`	Just rebuild. Nothing was removed; the older name `XM_CTRL_TORQUE` still works
`XM_SetControlMode(XM_CTRL_MONITOR)`	Blocks after 0.3–0.6 s instead of instantly
`MONITOR` mode	Torque and vectors are both fully blocked
`XM.status.h10.forwardVelocity`	Value is 60× smaller (this is correct)
`Control_Setup` / `Control_Loop`	Over 8 seconds in one call triggers a watchdog reset
Total Data packet	Size and channel positions unchanged (365 B) — existing receivers keep working
PhAI Studio	Works as before
Example count	Unchanged (Rev 2.0: 45 · Rev 1.1: 42)