Ensure Variable State Saver Loads First

Yes - the key is to load the Variable State Saver before anything else reads those globals.

Recommended approach

For JD, the most reliable pattern is:

1. Use the EZB Connection skill’s Connection Established script on the same connection index JD uses.
2. In that script, call ControlCommand("Variable State Saver", "Load") first
3. Then apply your servo offsets / gait speed
4. Only after that, start any Auto Position or behavior scripts

That way, the saved values are restored as soon as the EZ-B connects, before your initialization logic runs.

Example startup script

In the EZB Connection skill:

• click the kebab / hamburger menu
• open Settings
• find the Connection Established Script for index 0 if that’s where JD is connected

Use something like:

ControlCommand("Variable State Saver", "Load")
Sleep(100)

var pan = 90 + parseInt(getVar("$headPanOffset", 0))
var tilt = 90 + parseInt(getVar("$headTiltOffset", 0))
var gaitSpeed = parseInt(getVar("$gaitSpeed", 2))

Servo(D0, pan)
Servo(D1, tilt)
Servo.setSpeed(D2, gaitSpeed)

Important notes

1) Load in a project-start script may run too early

If the project starts before the EZ-B connection is ready, some skills may still initialize with defaults. That’s why Connection Established is better than a project-load script for hardware calibration values.

2) ControlCommand("Variable State Saver", "Load") is the right command

That’s the correct way to restore the saved state from script.

3) Your script has one ARC JavaScript detail

You used:

SetSpeed(D2, GetVar("$gaitSpeed") || 2);

In ARC JavaScript, use the servo command form instead:

Servo.setSpeed(D2, parseInt(getVar("$gaitSpeed", 2)))

Also, getVar() is preferred over GetVar().

Best practice for JD

If those offsets are used by multiple skills, you can also:

• keep them in Variable State Saver
• load them in Connection Established
• then have all other scripts read from the already-loaded values

That avoids timing issues and keeps startup deterministic.

If you still see a race condition

If another skill is acting before the connection script finishes, the next step is to:

• disable that skill’s auto-start behavior until after variables load, or
• use a dedicated "startup" script that loads variables first, then calls the rest of the behaviors in order

For more on the skill itself:

• Variable State Saver skill
• EZB Connection skill
• Configuring robot skills

One question

Are your Auto Position actions being triggered by:

• the Connection Established script, or
• another skill’s on load / startup behavior?

If you tell me which skill starts them, I can suggest the cleanest ordering so JD never moves on defaults.