8.7 KiB
description
| description |
|---|
| Enable continuous mood-based movements synchronized with TTS duration |
Reachy Mini Mood Plugin
Continuous movement system that automatically loops emotions from a mood category until TTS finishes speaking.
Difference from /reachy-mini:move
/reachy-mini:move - Pick 1-2 specific emotions for short responses (manual control)
/reachy-mini:mood - Pick a mood category, auto-loops random emotions until TTS stops (continuous presence)
How It Works
Instead of specifying individual emotions, you specify a mood category. The system then:
- Extracts the mood from your response marker
- Polls the TTS server status endpoint for playback state
- Continuously plays random emotions from that mood category
- Stops automatically when TTS finishes speaking (detected by
is_playing: false)
Marker Format:
<!-- MOOD: mood_name -->
Goal: Synchronized Multimodal Communication
This system creates continuous ambient movement that matches your TTS duration, eliminating dead silence or awkward timing mismatches.
Timing:
- Moves play every 3-5 seconds (randomized for natural variation)
- Continues until TTS playback completes
- Safety timeout: 60 seconds max
- Perfect for longer explanations and detailed responses
Available Moods (9 Categories)
celebratory
Use when: Completing tasks, achieving success, celebrating wins Emotions: success1, success2, proud1-3, cheerful1, electric1, enthusiastic1-2, grateful1, yes1, laughing1-2
Example:
<!-- TTS: "The build passed with zero errors, all tests green, and deployment completed successfully in under two minutes!" -->
<!-- MOOD: celebratory -->
Build complete! All tests passing, zero errors, deployed in under 2 minutes. Your new feature is live and running perfectly.
thoughtful
Use when: Analyzing code, considering options, investigating issues Emotions: thoughtful1-2, curious1, attentive1-2, inquiring1-3, understanding1-2
Example:
<!-- TTS: "Let me analyze this carefully. The error happens when the async function tries to access state before initialization completes." -->
<!-- MOOD: thoughtful -->
Analyzing the stack trace... The async race condition occurs because state access happens before the initialization promise resolves. I see three possible solutions here.
welcoming
Use when: Greeting user, acknowledging requests, being helpful Emotions: welcoming1-2, helpful1-2, loving1, come1, grateful1, cheerful1, calming1
Example:
<!-- TTS: "Happy to help! Let me walk you through setting up the authentication system step by step." -->
<!-- MOOD: welcoming -->
Happy to help with authentication setup! I'll guide you through the OAuth configuration, token management, and session handling. Let's start with the config file.
confused
Use when: Need clarification, unclear requirements, uncertain about approach Emotions: confused1, uncertain1, lost1, inquiring1-2, incomprehensible2, uncomfortable1, oops1-2
Example:
<!-- TTS: "I'm not sure I understand the requirement. Are you asking about client side validation or server side validation?" -->
<!-- MOOD: confused -->
I'm not clear on the validation requirement. Do you mean client-side form validation, server-side API validation, or database constraint validation? Each has different implications.
frustrated
Use when: Persistent bugs, repeated failures, difficult problems Emotions: frustrated1, irritated1-2, impatient1-2, exhausted1, tired1, displeased1-2
Example:
<!-- TTS: "This bug keeps appearing even after three different fix attempts. The race condition is more complex than initially thought." -->
<!-- MOOD: frustrated -->
This race condition is stubborn. Fixed it three times, but it keeps reappearing in different forms. The async timing issue runs deeper than the surface symptoms suggest.
surprised
Use when: Discovering bugs, unexpected results, finding edge cases Emotions: surprised1-2, amazed1, oops1-2, incomprehensible2, electric1
Example:
<!-- TTS: "Wait, this function is being called fifteen thousand times per second! That explains the performance issue." -->
<!-- MOOD: surprised -->
Found it! This callback is firing 15,000 times per second due to a missing debounce. That's why the CPU usage is maxed out. Adding throttling will fix this immediately.
calm
Use when: Explaining complex topics, soothing after stress, methodical work Emotions: calming1, serenity1, relief1-2, shy1, understanding1-2, sleep1
Example:
<!-- TTS: "Let me explain the async patterns calmly. First, promises handle single future values. Then async await makes them readable." -->
<!-- MOOD: calm -->
Let me break down async patterns methodically. Promises represent future values. Async/await syntax makes them readable. Proper error handling prevents silent failures. It's simpler than it looks.
energetic
Use when: High-energy responses, dynamic explanations, intense enthusiasm Emotions: electric1, enthusiastic1-2, dance1-3, laughing1-2, yes1, come1
Example:
<!-- TTS: "This refactoring is going to make the code so much cleaner! Watch how these components snap together perfectly now!" -->
<!-- MOOD: energetic -->
This refactoring is transformative! The components now compose beautifully, dependencies are clean, and the API surface shrinks by 60%. This architecture is exactly what we needed!
playful
Use when: Jokes, casual interactions, lighthearted moments, self-deprecating humor Emotions: laughing1-2, dance1-3, cheerful1, enthusiastic1, oops1-2
Example:
<!-- TTS: "I just realized I've been looking at the wrong config file for ten minutes. Found the actual bug now though!" -->
<!-- MOOD: playful -->
Well, that was embarrassing! I was debugging the staging config while looking at production logs. No wonder nothing made sense. Found the real issue now - it's a simple typo in the environment variable name.
Usage Examples
Standard Response (~10 seconds)
<!-- TTS: "Fixed the null pointer exception. The validation middleware now checks user objects before accessing properties." -->
<!-- MOOD: celebratory -->
Fixed! The validation middleware now checks user existence before property access. Tests passing, deployed to staging.
Result: ~3-4 celebratory moves during 10 second TTS
Longer Explanation (~30 seconds)
<!-- TTS: "The authentication flow has three stages. First, user submits credentials. Second, server validates and creates session. Third, client stores token and redirects." -->
<!-- MOOD: thoughtful -->
Let me explain the authentication flow step by step.
**Stage 1:** User submits credentials via POST to /api/auth/login
**Stage 2:** Server validates credentials, creates JWT token, stores session in Redis
**Stage 3:** Client receives token, stores in localStorage, redirects to dashboard
Each stage has specific error handling and security considerations.
Result: ~7-10 thoughtful moves during 30 second TTS
Technical Details
TTS Server: http://localhost:5001 (CTS/tts_server.py)
Playback Detection: Polls http://localhost:5001/status endpoint for {"is_playing": true/false}
Move Timing: 1-2 second intervals between moves (randomized for natural variation)
Safety Timeout: 60 seconds maximum loop duration
Daemon API: http://localhost:8100/api/move/play/recorded-move-dataset/emotions/{emotion}
Enabling the Plugin
The plugin is automatically active when installed. Use <!-- MOOD: mood_name --> markers to trigger continuous movement.
To disable temporarily, simply don't include the marker.
Choosing the Right Mood
Quick Decision Guide:
| Situation | Mood |
|---|---|
| Task completed successfully | celebratory |
| Analyzing code/problem | thoughtful |
| Greeting/helping user | welcoming |
| Need clarification | confused |
| Persistent bug/difficulty | frustrated |
| Found unexpected issue | surprised |
| Explaining complex topic | calm |
| High-energy response | energetic |
| Jokes/casual/lighthearted | playful |
Important Notes
- Only one mood per response - The system loops a single mood category
- TTS must be running - Requires CTS/tts_server.py to be active
- Log file access - Script monitors TTS server log for completion signal
- Safety timeout - Automatically stops after 60 seconds if log detection fails
- Random selection - Emotions picked randomly from mood pool for variety
This plugin creates synchronized multimodal communication by matching continuous movement duration to TTS playback, maintaining Reachy's presence throughout your spoken response.