Unity Control Lag With Camera Servo

Yes - what you’re seeing is consistent with how the Single Camera servo Server skill is designed: the camera stream is the transport loop for servo updates. If the camera is paused/disabled, the servo side can stall too, and when FPS drops, servo updates can feel bursty because they’re effectively riding along with the video cadence.

What’s happening

• Camera off / paused no video packets, so servo updates from Unity can stop.
• Low FPS fewer update packets, so movement appears to "lurch."
• Your current JavaScript loop is also polling servo state, which means it’s not an ideal way to make real-time drive commands feel smooth.

Best recommendation

For reliable Unity Roomba driving, use a separate control path for motion instead of tying driving to the camera servo server.

Good options

Option 1: Use ControlCommand() or movement commands directly

If Unity can send commands into ARC (via TCP, UDP, HTTP, or a custom plugin/skill), have it send:

• forward
• reverse
• left
• right
• stop

Then let ARC’s Movement Panel handle the Roomba.

This is the cleanest approach because movement is designed to be global in ARC and does not need the camera stream.

Option 2: Build a custom robot skill

If you want a dedicated Unity bridge, the best long-term path is to create a robot skill that receives Unity’s joystick values independently of the camera.

That way:

• camera can be on/off without affecting drive
• servo updates can be sent at their own rate
• movement can be smoothed and filtered

Create a skill here if needed: https://synthiam.com/Support/Create-Robot-Skill/Overview

Option 3: Send drive data through a protocol separate from video

For example:

• UDP for joystick/motion updates
• HTTP POST for discrete commands
• TCP socket in a custom skill

This keeps camera load from impacting driving.

Why I wouldn’t use the current loop

Your ARC script is polling virtual servo values like this:

while (true) {
  var x = GetServo("D2"); // turn
  var y = GetServo("D3"); // throttle
  var forward = (y - 90) / 90.0;
  var turn = (x - 90) / 90.0;

  if (Math.abs(forward) > 0.1) {
    Forward();
  } else if (forward < -0.1) {
    if (turn > 0) {
      Right();
    } else {
      Left();
    }
  }

  Sleep(20);
}

A better architecture is:

• Unity sends joystick values directly to ARC
• ARC stores them in variables or receives them in a skill
• A movement script or control loop applies them continuously
• Camera is only for video

What I’d suggest for ARC

If you want to stay simple:

Use a small custom skill or script receiver that accepts joystick values from Unity and writes them to ARC globals like:

• $UnityTurn
• $UnityThrottle

Then a JavaScript loop in ARC can read those and drive the Roomba.

Example ARC JavaScript pattern

while (true) {
  var x = getVar("$UnityTurn", "90");
  var y = getVar("$UnityThrottle", "90");

  var turn = (parseInt(x) - 90) / 90.0;
  var forward = (parseInt(y) - 90) / 90.0;

  if (forward > 0.1) {
    Movement.forward();
  } else if (forward < -0.1) {
    Movement.reverse();
  } else if (turn > 0.1) {
    Movement.right();
  } else if (turn < -0.1) {
    Movement.left();
  } else {
    Movement.stop();
  }

  sleep(20);
}

That keeps motion logic independent from the camera stream.

About the camera pause issue

If you specifically need video off but servo/motion still active, then Single Camera servo Server is the wrong transport for that use case because it couples both together.

My recommendation for your setup

Since you have:

• Roomba base
• EZB v4 pan/tilt
• USB camera
• Unity client

I’d do this:

1. Keep Single Camera servo Server only for camera/video + pan/tilt
2. Use a separate Unity-to-ARC channel for drive control
3. Drive the Roomba through the Movement Panel
4. Optionally create a small custom robot skill for the Unity input

Quick question

How is Unity currently sending those virtual servo values into ARC?

• through the Single Camera servo Server only
• through a separate TCP/UDP connection
• or through an ARC script/plugin you wrote

If you tell me that part, I can suggest the best exact ARC-side setup and give you a concrete JavaScript or Python example.