I’ve got a ROBOTIS Darwin Mini (OpenCM9.04 + XL-320s) talking to ARC. I flashed the ARC-compatible firmware and enabled Bluetooth in the .ino (COMMUNICATION_PORT = Serial2, _BAUD_RATE 9600). ARC connects fine over Bluetooth SPP and I can move the servos. I’m organizing motions in a Script Collection control named "Script Manager" with scripts: Initialize, Stand, WalkFwd, and KickLeft. I trigger them from a master script and from hotkeys using ControlCommand().
Here’s a simplified sequencing snippet:
# Master routine
ControlCommand("Script Manager", "ScriptStart", "Initialize")
# tried a few options here to wait for completion
# Sleep(2000)
# or try to poll status
ControlCommand("Script Manager", "GetStatus", "Initialize")
# not sure how to read the return reliably
ControlCommand("Script Manager", "ScriptStart", "Stand")
What I’m seeing:
- Over USB, this usually runs cleanly (Initialize finishes, then Stand).
- Over Bluetooth, Stand sometimes starts before Initialize is done, causing jitter or conflicting servo positions.
- Adding fixed Sleep() helps sometimes but isn’t reliable.
- I tried using GetStatus to block until Initialize completes, but I’m unclear how to capture the return value from ControlCommand() in a variable, and I don’t see a "ScriptStartWait" option for Script Collection.
What I’ve already tried:
- Project-level On Start vs Connection control’s On Connect scripts for triggering Initialize.
- Extra Sleep() before any movement after connect.
- Renaming the control and script names to rule out typos.
Is there a recommended way in ARC to reliably wait for a Script Collection script to finish (or queue scripts) before starting the next one, especially when connecting the Darwin Mini over Bluetooth at 9600 baud?
Yes - the clean way to do this in ARC is to use
ScriptStartWaitfrom the Script Collection control.Why this is happening
ControlCommand()is non-blocking unless the control specifically offers a...Waitcommand. So:will fire both commands immediately, which can cause exactly the race condition/jitter you’re seeing.
Recommended solution
Use
ScriptStartWaitinstead:That tells ARC to wait until the script completes before continuing.
Example master script
About
GetStatusGetStatusis useful for checking whether a script is running, but it is not the best tool for sequencing. In ARC, the most reliable approach is to use the wait-capable command when it exists.If you do want to poll status, you’d typically do it in a loop and store the result in a variable, but for this use case
ScriptStartWaitis the correct answer.Important note for Darwin Mini over Bluetooth
Bluetooth SPP at 9600 baud can be fine, but it is more prone to timing delays than USB. That means any script that sends lots of servo commands back-to-back may appear less consistent if you rely on timing guesses like
Sleep(2000).So:
ScriptStartWaitfor sequencingIf
ScriptStartWaitdoesn’t appearMake sure you’re using the Script Collection skill, not a regular Script control. The Script Collection manual lists:
ScriptStartScriptStartWaitScriptStopScriptStopAllGetStatusReference: https://synthiam.com/Support/Skills/Scripting/Script-Collection?id=16045
Best practice for your robot
For a robot like the Darwin Mini, I’d recommend this structure:
Then always launch them sequentially from a master script with
ScriptStartWait.One more thing
If the scripts are being started from hotkeys and the master routine at the same time, you can still get overlap if two different triggers call scripts concurrently. In that case, it helps to create a single "queue" script that all hotkeys call instead of launching motions directly.
If you want, I can help you turn your current Initialize / Stand / WalkFwd / KickLeft scripts into a safe queued pattern for the Darwin Mini in ARC using Script Collection.