Picture In Picture Lag With Tracking

Yes - the destination camera skills are still analyzing the destination camera’s own stream, not a magically separate "post-overlay analysis feed."

What’s happening

With Picture In Picture:

• The destination camera remains the render target
• The overlay is drawn onto that camera’s output
• Other camera skills attached to that destination camera may still be doing their own processing on that stream
• If you enable tracking on that same destination camera, you’re stacking:
  • camera capture
  • tracking analysis
  • PiP compositing
  • redraws to the UI

That combination can absolutely create latency, stutter, and brief freezes, especially on a mini PC with two USB cameras.

Why it gets worse with tracking

Tracking skills like Face Tracking / Object Tracking are often CPU-heavy, and when PiP is also updating frames, ARC has to manage:

• source camera frame copy
• overlay scaling/blending
• destination redraw
• tracking analysis loops

Even if you switch the PiP source to processed image, you’re changing which image buffer is used, but you’re still adding processing overhead.

Does tracking analyze the composed PiP image?

Usually no, not in the way you’re expecting.
The destination camera’s tracking skill is not intended to use the PiP composite as its primary analysis source. PiP is mainly for display composition, not for feeding a "new" analyzed video pipeline.

If you want tracking to analyze a composed view, the better approach is to make a single camera/control chain that produces the final image, then put tracking on that output if the skill supports chaining that way. In practice, though, this is often where performance becomes the limiting factor.

Best practice for your setup

For a Roomba-mounted mini PC with two cameras, I’d recommend:

Option 1: Keep tracking on the front camera, keep PiP off during tracking

This is the most stable setup.

• Front camera = tracking target
• Rear camera = only enabled when needed
• PiP = start only when you do not need tracking, or when the robot is reversing slowly

Option 2: Use PiP only during reverse

That’s a good idea, but don’t start/stop it inside a tight loop tied directly to $Direction every cycle. That can cause repeated start/stop churn and momentary stalls.

Instead, trigger PiP only when direction changes.

Here’s a simple ARC JavaScript pattern:

var lastDirection = getVar("$LastPiPDirection", "");

var currentDirection = getVar("$Direction", "");

if (currentDirection != lastDirection) {
  if (currentDirection == "Reverse") {
    controlCommand("Picture In Picture", "Start");
  } else {
    controlCommand("Picture In Picture", "Stop");
  }

  setVar("$LastPiPDirection", currentDirection);
}

That avoids repeatedly issuing Start/Stop while the robot stays in the same direction.

Even better: use separate controls/logic

If you’re using direction changes from the Movement Panel, you can also manage PiP from a script or state machine that only reacts to transitions. That will reduce stalling.

Configuration tips to reduce lag

Try these:

• Lower the front camera resolution if tracking doesn’t need 720p
• Use one camera at a time for heavy processing
• Avoid enabling processed image on both source and destination unless needed
• Keep the overlay smaller
• Reduce frame rate further if your USB bus is shared
• Make sure both cameras are not competing on the same USB root hub if possible

In ARC UI

For each robot skill, open the kebab/hamburger menu on the top-right of the skill and check:

• resolution
• frame rate
• processed/original image mode
• tracking options

That’s where you’ll get the biggest performance gains.

Recommended workflow for your use case

If you want the smoothest driving experience:

1. Front camera

   • tracking enabled
   • keep it as light as possible

2. Rear camera

   • only used for PiP when reversing

3. PiP

   • only start on reverse
   • stop when not reversing
   • only send the command on state change

One important note

If you’re using this for navigation in tight spaces, the ARC AI Assistant built into the script editor can help you quickly rewrite the direction-change logic and optimize the camera scripting right inside ARC: https://synthiam.com/Products/AI-Assistant

If you want, I can help you build a clean JavaScript state-change script for:

• Reverse = PiP ON
• Forward/Stop/Turn = PiP OFF

and make it only toggle once per direction change.