If ARC runs on the Raspberry Pi 5 onboard the robot, you generally gain simplicity and reduce network dependency, but you may lose some convenience and peripheral flexibility compared with running ARC on a separate laptop and controlling the robot over WiFi.

The short version

ARC onboard the robot

Pros

• No reliance on WiFi for core robot control
• Lower latency for scripts, control loops, and skill coordination
• Easier to keep the robot self-contained
• USB devices plugged into the Pi are local to ARC

Cons

• Limited by the Pi 5 + Windows on ARM environment
• Fewer options for USB/peripheral-heavy workflows than a laptop
• Some Windows x86 apps/drivers may not work on ARM or may be less reliable
• If the Pi reboots/crashes, the whole robot brain is physically on the robot

ARC running on a laptop remotely

Pros

• Better performance for heavy vision/audio/UI workloads
• Easier access to a wide range of USB devices and Windows drivers
• Simpler debugging and development
• More comfortable for camera tuning, logging, and testing

Cons

• Core control depends on network reliability
• WiFi latency/dropouts can affect teleop and streaming
• The robot still needs onboard controllers for real I/O

What changes by category

1) Hardware connected through EZB or onboard controllers vs directly to the PC

Hardware on the robot through an EZB / IoTiny / Arduino / servo controller

This is the best place for motors, servos, PWM, ADC, digital I/O, UART devices, and sensors that live on the robot.

Whether ARC is onboard or remote, these are still robot-local.
That means:

• Servo control timing stays on the controller
• Sensor reads happen close to the hardware
• Motion is not dependent on USB peripherals attached to a laptop
• The robot can keep working even if the remote PC disconnects, as long as the onboard controller and ARC logic remain running

Since you plan to use IoTiny and Arduinos/servo boards, that architecture is solid.

Useful overview:

• Robot Topology
• How ARC Works

Hardware connected directly to the PC

This is where the biggest difference shows up.

If ARC is on the Pi onboard

Anything physically plugged into the Pi is local to ARC:

• USB cameras
• USB microphones
• USB gamepads/joysticks
• USB serial devices
• Some Bluetooth devices if the Pi’s Bluetooth stack and drivers cooperate

If ARC is on a separate laptop

Those same devices connect to the laptop instead:

• USB camera and microphone are local to the laptop
• Joystick/gamepad input is local to the laptop
• COM/serial devices are local to the laptop unless bridged/networked
• Bluetooth peripherals are tied to the laptop’s Bluetooth environment

Practical impact

If you run ARC onboard, you gain:

• Simpler cabling for peripherals mounted on the robot
• No need to stream camera/video data across WiFi just so ARC can "see" the camera

If you run ARC remotely, you gain:

• More choice of USB hardware
• Often better driver compatibility
• Easier access to high-quality webcams, audio devices, and controllers

2) Robot Skills and vision/audio processing

Vision skills

With ARC onboard:

• Camera processing happens locally on the robot
• Less WiFi bandwidth use for live vision workflows
• Lower latency between camera input and robot response

This can be a real advantage for:

• Face tracking
• Object tracking
• Local autonomous navigation vision
• Camera-triggered behaviors

However, on a Pi 5 Windows on ARM setup:

• CPU/GPU performance may be lower than a good laptop
• Some vision-heavy tasks may run slower
• Some third-party computer vision dependencies may be less ideal on ARM

With ARC remote on a laptop:

• Vision skills may run faster and smoother
• Easier to use more powerful CPUs and GPUs
• Better overall experience for tuning image processing

Audio skills

With ARC onboard:

• Microphones plugged into the Pi are local
• Speech recognition and TTS coordination can be self-contained
• No network trip just to hear the microphone audio source

With ARC remote:

• Better access to higher-quality USB microphones and audio interfaces
• Often easier to debug audio input/output devices

Bottom line for skills

Onboard ARC favors autonomy and reduced latency.
Remote ARC favors compute power and peripheral flexibility.

3) Scripting: JavaScript/Python and automation behavior

Scripts in ARC behave the same logically, but the environment changes.

If ARC is onboard

Your JavaScript/Python automation:

• Runs directly on the robot computer
• Is not dependent on a remote WiFi session
• Can continue reacting to local events without network delay
• Is better for "always-on" robot behaviors

That’s ideal for:

• Autonomous patrol behavior
• Sensor reaction loops
• Local state machines
• Startup initialization scripts
• Behavior that must continue even if the operator leaves

If ARC is remote

Scripts still run in ARC, but:

• They depend on the remote PC staying connected to the controllers
• Communication with the robot crosses WiFi
• If WiFi drops, scripts may still be running on the laptop, but physical control updates may be interrupted

What you give up onboard

Mostly nothing in the scripting model itself, but you may lose:

• Performance headroom for large scripts
• Some convenience if you like editing/debugging on a bigger laptop
• Access to peripherals attached only to the remote PC

If you’re writing code, the ARC AI Assistant built into ARC can help edit or rewrite JavaScript/Python right inside the script editor:

• ARC AI Assistant

4) Network-dependent features when ARC is accessed over WiFi

This is where onboard ARC is often much better for reliability.

If ARC is onboard

Network is mainly for:

• Remote monitoring
• Remote UI access
• Teleop from another device
• Sending commands to or from other systems

If WiFi goes out:

• The robot can often keep functioning locally
• Core scripts and controller interactions remain on the robot

If ARC is remote

WiFi becomes part of the control path:

• Robot connection depends on network quality
• Streaming video, telemetry, and commands all compete for bandwidth
• Dropouts can pause or degrade control

What breaks or changes remotely

If ARC is on the laptop and the laptop connects to the robot over WiFi:

• Live control becomes sensitive to signal quality
• Camera feeds can lag or freeze
• Network discovery and reconnects matter
• Some "always-on" behaviors can become less dependable

What breaks or changes onboard

If ARC is onboard and you access it remotely:

• The robot is still autonomous even if your viewing/control connection drops
• Remote access is just a convenience layer
• You can still run a headless robot style workflow if desired

What you gain or lose overall

Running ARC onboard the Pi 5

You gain

• Self-contained robot brain
• Better resilience to WiFi problems
• Lower latency between ARC, scripts, and onboard controllers
• Cleaner architecture for autonomous robots

You may lose

• Some Windows x86 software compatibility
• Some USB/peripheral flexibility
• Potential performance compared to a stronger laptop
• Ease of development/debugging if you prefer a larger workstation

Running ARC remotely on a laptop

You gain

• Better PC performance
• Broader USB device support
• Easier debugging and development
• Great for development, testing, and tuning

You may lose

• Reliability if WiFi is weak
• Tight control latency
• Some autonomy if the network drops

For your specific plan: Pi 5 + IoTiny + Arduinos/servo boards

That’s a very reasonable architecture.

If the Pi 5 is running ARC onboard, and the IoTiny/Arduinos/servo boards are physically on the robot, then ARC becomes the central coordinator while the I/O controllers handle the physical interface. That is exactly the kind of layering ARC is designed for.

For many robots, this is the preferred setup:

• Pi 5 = robot brain
• IoTiny / Arduino = hardware interface
• Cameras/mics = local USB devices if needed
• Remote laptop/phone = optional operator console

Recommendation

If your goal is:

Best autonomy and robot reliability

Go onboard ARC on the Pi 5.

Best development convenience and maximum peripheral compatibility

Go remote ARC on a laptop.

Best of both worlds

Develop remotely on a laptop, then deploy the project to the onboard Pi for final robot operation.

If you want, I can also give you a decision matrix for:

• Pi 5 onboard ARC
• laptop remote ARC
• hybrid setup

and map each one to cameras, microphones, gamepads, serial devices, and Arduino/IoTiny wiring.

That’s a lot of info from Athena. But I think it would also help to get an idea of the type of robot you’re building - and if you have an idea of what you’d want it to do.

Mainly because if it’s a robot that will be navigating with a lidar etc, an onboard pc is required. Lots of the usb peripherals for sensors would require it to be local on the robot.

Let us know a bit more of your plan and that’ll give more context for a shorter answer