Star Wars Droid Translator Helmets
I made these Star Wars Droid Translator Helmets, and with them you can:
- Look like a Droid!
- Sound like a Droid when you talk!
- Talk with and understand other Droids (wearing other helmets)!
And here is a short video demonstrating the difference between wearing a helmet and not wearing one. The voice in the second part is an actual recording of what it sounds like through the other helmet.How It Works
First, an important detail. These helmets really do work, but like special effects - they are using some smoke and mirrors. The Droid "language" being emitted is meaningless gibberish. There is no actual translation happening. To get the effect, this is what happens behind the scenes:
Interesting Lessons Learned
- The helmets sense when you are talking and emit "Droid" instead.
- Your voice is picked up with a Laryngophone (throat mic) which is not only immune to ambient sounds (since it doesn't use sound waves) but it works even if you speak very quietly. When you speak quietly from behind the helmet, no one hears your actual voice.
- The helmets transmit your actual voice on the sly to the other helmet(s).
- The receiving helmet(s) play your actual voice directly into the ear, so no one else hears.
- The RGB LEDs embedded into the helmets aren't just cosmetic - they represent specific activity and status reports.
- The helmets use wi-fi to coordinate with each other (communicating status to each other, establishing transmission right-of-way, and so on.)
Many interesting or challenging things came up during the design process. Here are some of the more interesting ones:
Things that DIDN'T work as expected (or at all)
- No easy solution to making good Droid sounds. A dynamically-generated "Droid" language that sounds good is [still] a Holy Grail. Making "Droid" speech that sounded good was a major job that was far more difficult than expected. I learned I was not the first to discover this. "Droid" is so much more than beeps and boops - my original attempts to create the sounds programmatically were early failures and some research shows I was not alone. I learned that to get something that sounds good and emotional is no easy feat - I read a reference to an interview with Brett Burt (sound designer for Star Wars) in which he stated that making R2D2's voice was one of the hardest things he had done. In the end, the key was to make a sample set of short "Droid" speech bits that sounded good together and could be played seamlessly, and play them semi-randomly to represent speech. R2D2Translator.com was invaluable (see attributions). You can download my sample sets from the HARDWARE section. I talk a bit more about Droid sounds and using them here on this blog post.
- Giving each Droid helmet a different "voice" was important but much harder than expected. It was important for two helmets to have two different "voices" of Droid because otherwise a conversation just sounds like one Droid talking to (and over) itself. It's not enough to give them different sample sets of the same basic sounds because even if the "words" never repeat, both helmets still sound the same. Pitch shifting, etc wasn't enough and never sounded right. In the end, I discovered that using the Censor -> Gibberish filter in Goldwave changed the samples enough that they sounded very different, but still sounded like a Droid. One batch process later, and I had a new and distinct voice for the second helmet.
- Playing sounds is easier than it used to be. A problem with WAV files is that they take up a lot of memory. I wound up using hardware made for the purpose. An Adafruit WAV/OGG board fit the bill perfectly, and had many ready-to-use modes of operation right out of the box. WAV files are bigger than OGG but need no decoding, which allowed for seamless playback. It also was very easy to load and re-load sounds for testing as well. Still, the software to drive it all still has some complexity to it - you can't entirely leave it all to the sound board. You still need to choose which sample set to use, then later when the wearer has stopped talking you need to halt the playback in a way that makes sense (well, sounds good anyway) - no glitches or sudden cutoffs.
- A throat microphone (laryngophone) really does work best for this project because not only can it pick up quiet speech (talk too loud and people will hear you over the Droid speaker), but it's immune to ambient sounds (such as a speaker bleating out "Droid" language a few inches away...) It's possible to make your own (I tried several versions) but you can't beat just buying one off the shelf (common on Amazon, eBay, etc) for not only ease of use but also for the fact that they come built into an adjustable frame complete with connectors. Sometimes it's not worth rolling your own.
- Sometimes you need to go with what works so you can move forward. I originally intended to use this project as a basis for transmitting voice, but some of the functions needed weren't supported by current firmware. Even fiddling with older firmware, I spent a lot of time on it but was unable to get it working and needed to make a decision. With the deadline to consider, I decided to offload voice transmission onto off-the-shelf FRS radios. I interfaced the Photon to it (non-destructively) so the Photon still controls the radio and transmissions.
- It was very important for everything to fit in/on the helmet. No external boxes, umbilical cables, etc. It would have been fast and easy to just stick things to the helmets wherever they might have fit, but the result would have been poor. I spent a lot of time planning where pieces would go and how the cables would be placed. If I hadn't, I have little doubt that I would have had to resort to an externally-mounted box. There would have been too many components and not enough helmet to go around. The helmet would have been poorly balanced and uncomfortable to wear. Debugging would have been more difficult. I go into a bit more detail about this in this blog post.
- It was important to still be able to flip the face mask up/down without anything getting in the way. I was very glad I took the time to make sure this could be done. It was invaluable later for comfort.
- The RGB LEDs are not random, they represent specific status. They look good but were also super handy during debugging. Being able to visually confirm status of more than just the one helmet you're actively debugging is very useful.
- The two helmets synchronizing their operation and status over UDP (via wi-fi) was important. The helmets have all they need to function, but a "traffic cop" to keep things orderly and prevent more than one thing happening at a time was a critical part of polish. This helps ensure only one helmet talks and transmits at a time. It also lets the helmets coordinate RGB patterns which are not only pleasing to watch, but useful for debugging.
- On the topic of using UDP over wi-fi - the Particle Photon made this ridiculously simple. I was done in no time, Particle made it shockingly easy.
- Color printouts of Droid faces behind face shields worked out better than expected. I knew from the start I was going to need to spend my time on the electronics, not on making a "mask". So I chose this method as a quick way to get a decent result that left me the space and material I needed. Turns out it actually ended up looking very good!
There were false starts, dead ends, and direction shifts during the design process. Here are some of the significant ones:
- These bone conductor transducers from Adafruit were an early idea to transmit received voice privately from other helmets directly via bone conduction. Seemed natural since I already had a strap on the skull due to the helmet - use that tension to hold it firm to the skull. However in practice they turned out to be difficult to use. The transducer isn't quite in a ready-to-use form. The part that needs to touch the skull is small and very close to the part that needs to be isolated. It was too fiddly and didn't work particularly well for me in testing, so I went with what is basically an ear bud.
- I originally intended to use hearing protection muffs over the helmet wearer's ears. I would pipe in ambient sounds until another Droid was speaking - at which point I would mute ambient sound and play only the other Droid helmet wearer's actual transmitted voice. The idea was that you wouldn't be distracted by the Droid speaking "Droid" while you were trying to listen to the person's actual voice. As it turned out, it's not a big deal. A proof-of-concept with parts taped into cardboard boxes proved this; we tested things and it wasn't a noticeable problem. This was good because the hearing protection muffs don't fit well under the helmet anyway. They actually worked and I had one (of two) made, but I was glad to ditch them and the whole idea for what is basically an earbud.
- The mouth sensor was a tough nut to crack. I wanted something that wouldn't touch you and would be part of the helmet, and would still be able to act as a "talking" sensor reliably. It works, but it's very fiddly. It needs to be placed close (but not too close!) to the chin, so I mounted it on a flexible stalk. It works if you find the sweet spot. However, it was far too clunky to use during debugging, when you had many much better things to do than fiddle with a sensor. I ended up making an optional manual "push-to-talk" button that acted as a manual override - it was a wise decision.
- The helmets ended up being sort of awkward to store! They are strangely shaped and all rounded surfaces and curves. Putting them face-down into a too-small box was best for working on them. Perching them on thin boxes as "stands" was best for holding them up. It doesn't sound like much, but the awkwardness of working on or storing large-ish items with no flat surfaces is easy to underestimate.
"First Person View" Video of Helmet Use
1 / 10 • Proof-of-concepts in cardboard boxes.
Here is a video intended to show what it's like to look through and listen through the helmet. Enjoy with the caveat that recording from a camera pushed into a helmet and recording audio from an earbud taped up to the camera's mic gives poor quality. If you want to hear a better representation of what things sound like, the video near the top of the page (and on youtube here) is a recording from the helmet's LINE OUT and represents actual sound quality much better. With that in mind, enjoy.Future Improvement
There are a number of things that could be improved. This is, after all, only a version 1 prototype sort of device.
- Ditching the radios and transmitting voice directly over wi-fi would be impressive. I originally wanted to use this project as a basis for exactly that, but was unable to get it to work. It is important that all voice transmission is real-time.
- The mouth movement sensor should be more robust and easier to use. It works as-is, but it must be positioned in a "sweet spot". It's too fiddly.