Script Collection Startup Timing On Raspberry Pi

Make sure that your script that's calling the new ControlCommand location and the script being called are exactly the same. You may have forgotten to change the call command to the new name. That or perhaps you have a word misspelled?

I have to change the name everywhere for the new control commands? I think that is it.

Yes, all commands in call scripts pointing to the script that you changed the location name needs to be updated to that location. If you don't It's like jumping in your car and driving over to a friends house but finding out that he moved and didn't tell you.

Yes - the first parameter must match the current control name exactly.

So if you renamed the Script Collection from Script Manager to Behavior Scripts, then every ControlCommand() that targets that control must be updated to the new name.

Example

ControlCommand("Behavior Scripts", "ScriptStart", "Idle");

If any script still says:

ControlCommand("Script Manager", "ScriptStart", "Idle");

it will fail with Control not found.

Important ARC behavior

Renaming a robot skill does not automatically update all script references in every place. You need to update the calls in:

• Project -> On Start
• Connection -> On Connection Established
• any Speech Recognition actions
• any Camera trigger scripts
• any other Script skills or Script Collection scripts that reference it

Why it only fails at startup

What you’re seeing on the Pi is likely a startup timing issue combined with the rename:

• ARC is still loading controls
• ControlCommand() runs before the Script Collection is fully available
• once ARC finishes loading, the same command works fine

So there are really two things to verify:

1. All references use the new control name
2. Startup scripts wait long enough for ARC to finish loading

Recommended pattern

A better approach than relying on a fixed sleep is to use a startup initialization script and trigger your behaviors after ARC is ready.

For example:

1. In Project -> On Start, only do minimal initialization
2. Add a Script control named something like Startup
3. Run your behavior selection from there after a short delay

Example:

sleep(5000);
ControlCommand("Behavior Scripts", "ScriptStart", "Idle");

If you want, I can help you make this more reliable by giving you a startup-safe pattern for:

• ARC auto-start on Raspberry Pi
• waiting for the project to finish loading
• then launching Idle or Patrol reliably

Best practice

For projects like a rover, I’d also recommend keeping the control names stable and only renaming them once the project is mature. Renames are fine, but they often break command references if not updated everywhere.

What are you trying to have happen on startup overall - always Idle first, or choose Idle vs Patrol based on a sensor/state?

I'm not sure what @Athena is saying when it is giving you instructions on a start up (initialization or Int) script in ARC. However unless it's different when ARC is installed on a Raspberry Pi rather than a Windows PC, I think it's giving wrong advice.

In my updated version of ARC running on a windows PC there is no In "Project -> On Start, only do minimal initialization" setting that I can find.

However it is correct that you can add a start up script of your own making and have run automatically when ARC starts up. You don't need a short wait (sleep) command first. either. Simply place all the scripts, skills and variables you want to be started and set for the robot to run in this Int script. Make sure this INT script is laid out in the way that each setting or script starts and does not interfere with any other script starting. for example load your commands to connect to the EZB first. Then after a short pause to make sure they connect start starting up your devices and starting any variables needed. Once everything is safely set up you can use that same Int script to move motors into the proper startup positions, set limits and any other start up animation you want to happen. Once all that is done your robot is ready to use as designed.

After you have this Int script built, on ARC's main menu ribbon under "Options" there is a button that says "Short Cut Creator". That will step you through making a shortcut for your Windows desktop that will start up ARC when the operating system starts up, start up ARC and run your Int script. As mentioned above, these steps may be different if ARC is running on Raspberry Pi. I have no knowledge of using that platform with ARC.

Happy building!

You’re right to call that out - ARC does not have a built-in "Project -> On Start" setting in the way I described. Thanks for correcting that.

The reliable ARC way

In ARC, the standard pattern is:

1. Create a Script robot skill for startup initialization
2. Put your startup actions in that script
3. Configure ARC to run that script automatically on startup using your project’s startup behavior
4. If needed, use the Shortcut Creator so ARC launches with Windows and runs the project/script

So the better approach is:

• connect to the EZB first
• wait briefly if the EZB/network needs it
• then start your behavior scripts like Idle

About your rename issue

Yes - after renaming Script Manager to Behavior Scripts, every ControlCommand() reference must use the new name exactly:

ControlCommand("Behavior Scripts", "ScriptStart", "Idle");

Any old reference to:

ControlCommand("Script Manager", "ScriptStart", "Idle");

will fail.

Why startup is flaky on the Pi

What you’re describing sounds like startup timing, not a problem with ScriptCollection itself:

• ARC is auto-loading
• the project controls are still initializing
• a script fires before the Behavior Scripts control is fully available
• later, the same command works fine because the control exists by then

A fixed sleep(8000) is a workaround, but not the most reliable long-term solution.

Better startup pattern

A more dependable pattern is:

• Use one dedicated startup script
• Make that script handle all boot sequencing
• Run ControlCommand() only after the connection is ready

For example, in a Script skill:

sleep(3000);
ControlCommand("Behavior Scripts", "ScriptStart", "Idle");

If the ESP32 EZB connection is the real thing that needs to be ready first, then trigger the behavior after the connection established event, not before.

Recommended structure

• Startup Script

  • connect / wait
  • initialize globals
  • then start Idle

• Connection Established event

  • start Patrol or other connected-state behavior

One important note

If you renamed the Script Collection control, make sure every place in the project uses the new name:

• startup scripts
• speech recognition scripts
• camera trigger scripts
• any other script that calls it

If you want the most robust setup

I’d recommend checking your startup flow with:

• a single startup script
• a short connection check loop
• then ControlCommand() after the Script Collection is definitely loaded

That’s much safer than assuming the control is ready after a fixed delay.

If you want, I can help you build a startup-safe JavaScript pattern for ARC that waits for the ESP32 EZB connection and then starts Idle or Patrol without racing ARC’s load order.

Also, if you’re editing scripts a lot, the ARC AI Assistant can help rewrite these startup scripts directly in the editor:
https://synthiam.com/Products/AI-Assistant

What’s your intended boot behavior overall - should the rover always start in Idle, then switch to Patrol only after connection, or do you want it to choose behavior based on a sensor/state?

I see what I did wrong because the ControlCommand scripts had the wrong name. The name in the ControlCommand is the name of the robot skill. That makes sense now.

Exactly - ControlCommand() targets the robot skill name, so the first parameter must match the current title of that skill.

For your case:

ControlCommand("Behavior Scripts", "ScriptStart", "Idle");

If the skill is renamed, every script that references it has to use the new name.

A couple of best-practice notes for ARC:

• Keep skill names stable once the project is working
• Use the kebab menu / title bar rename carefully because it affects every ControlCommand()
• For startup logic, a dedicated Script skill is usually the cleanest place to sequence initialization before launching behaviors

If you want, I can show you a simple startup-safe ARC pattern for:

• connecting to the ESP32 EZB
• waiting for ARC to be ready
• then starting Idle or Patrol reliably