Watson TTS Halts Turtlebot3 Motion

What you’re seeing is usually a combination of TTS generation latency and script/control contention, not the TurtleBot3/OpenCR motion itself.

A few important points:

What’s likely happening

• Watson Text To Speech must contact IBM and generate speech for each utterance, so short frequent phrases can cause noticeable overhead.
• If your motion logic and speech calls are happening in the same script loop, the speech call can block long enough to make the drive loop appear to stall.
• The fact that subsequent calls get slower after 6-10 utterances suggests you may be accumulating queued speech requests or reusing the skill in a way that creates backlog.
• The audio stopping until Active is toggled often indicates the skill is stuck in a busy/queued state or the output audio stream has become inconsistent.

Best practice in ARC

For robot narration while driving, keep motion control separate from speech:

• Run movement in its own skill/script.
• Send speech requests from a second script or from event triggers.
• Avoid calling TTS directly inside a tight navigation loop.

Recommended pattern

Instead of speaking every time an event fires, use a speech queue / cooldown so repeated events don’t spam the TTS skill.

Example approach in JavaScript:

• Store the last announcement time.
• Ignore duplicate messages for a short cooldown.
• Only speak if the robot is not already speaking.

var now = new Date().getTime();
var lastSpeak = getVar("$LastTTS", 0);

if (now - lastSpeak > 1500 && getVar("$IsSpeaking") != true) {
  setVar("$LastTTS", now);
  controlCommand("Watson Text To Speech", "SayWait", "Obstacle detected");
}

If you need multiple messages, build a single speech dispatcher script that reads a global variable queue and speaks one item at a time.

Better queue pattern

Use a global variable like $TTSQueue and have one script process it:

var queue = getVar("$TTSQueue", "");
if (queue != "") {
  setVar("$TTSQueue", "");
  if (getVar("$IsSpeaking") != true) {
    controlCommand("Watson Text To Speech", "SayWait", queue);
  }
}

Then other scripts only append messages instead of speaking directly.

For frequent short status updates

For things like:

• Left
• Right
• Stop

I’d strongly recommend throttling them or using a nonverbal indicator instead, because TTS is not ideal for rapid-fire navigation feedback. Consider:

• only speaking on state changes
• only announcing every N seconds
• using a sound effect or LED pattern for fast events

Endpoint / voice / caching

A few practical notes:

• Use one endpoint consistently; switching between US South and EU won’t usually solve latency once the skill is already configured.
• Pick one voice and keep it fixed.
• There isn’t a user-facing "speech cache" feature in Watson TTS skill that will eliminate per-utterance cloud generation latency for changing phrases.
• If you repeat the same phrases often, a more reliable option is to pre-generate audio and play local files instead of calling TTS each time.

That gives you:

• no cloud round-trip
• no per-utterance synthesis delay
• much smoother operation

You can play local audio with ARC using Audio.playAudioFile() or through an audio-focused skill. See:

• Watson Text To Speech skill
• EZB Audio Playback Issues

Practical recommendation for TurtleBot3

For your use case, I’d do this:

1. Keep TurtleBot3 motion and navigation running normally.
2. Create a dedicated "speech manager" script.
3. Have your navigation/obstacle logic write messages into a queue variable.
4. Speak only one message at a time.
5. Add a cooldown so repeat announcements don’t pile up.
6. For common alerts, replace Watson TTS with cached local audio clips.

If you want, I can help you build it

I can write you a small JavaScript queue script for ARC that:

• accepts messages from your navigation logic
• prevents overlaps
• rate-limits short announcements
• avoids blocking your drive loop

If you want, paste how you’re currently triggering Watson TTS, and I’ll convert it into a nonblocking ARC pattern.