A while ago, with a little urging from friends, I decided to change how the wands identify gestures. Right now, the wands recognize eight basic positions:

  1. Pointing straight ahead,
  2. Pointing straight ahead but rotated 90º clockwise,
  3. Pointing straight ahead but rotated 90º counterclockwise,
  4. Pointing directly at the ground,
  5. Pointing downward at roughly 45º,
  6. Pointing straight upward,
  7. Pointing up at roughly 45º, and
  8. Pointed anywhere behind you.

When the wand changes from one of these positions to another it makes a note of it. It remembers the last 20 positions it’s been in. Each time it changes position, it checks to see if the most recent position sequence matches a spell’s sequence. For example, say a spell starts straight ahead (1), turns 90º CCW (3), then goes straight ahead (1), then goes 90º CW (2), then goes straight ahead again (1).  Every time the wand changes position, one of the sequences it’s looking for in its position memory is “1, 2, 1, 3, 1.” Note that this is in reverse order because that’s how the wand’s memory works.

This system is all good and fine, but it’s not very fine-grained. When people pick up the wand, the first thing they do is make swishy wand-gestures in front of them. It would be great if the wands could actually recognize that kind of gesture.

That’s why I want to use AI to teach the wands to recognize more complex and subtle gestures. Specifically, I want to use Google’s TensorFlow. Why? It’s the right combination of price (free), complexity (moderate), and it should be more than capable of doing what I need it to do.

More specifically, I want to use TensorFlow Lite, which is designed specifically to run on microprocessors with limited resources (like an ESP32!). I was taking a break from setting up my computer with Espressif’s ESP32 development environment – a prerequisite to installing the needed TensorFlow Lite software – when I found a GitHub blog called Eloquent Arduino. In a post titled Easy TinyML on ESP32 and Arduino, the author shares their experience with using TinyML to deploy TensorFlow Lite models on microcontrollers. They went through all the hassle of getting it set up, created a library for the Arduino IDE, shared it with the world, and wrote up their entire process along with examples of how to use it.

I launched the Arduino IDE, used the Library Manager to download and install the Eloquent TinyML library, opened the SineExample sketch (from File >>> Examples >>> Examples from custom libraries >>> Sine Example), compiled and uploaded it to an ESP32, and it worked like a charm.

In about 10 minutes, I had TensorFlow Lite running on an ESP32. It’s like magic. The Eloquent TinyML library likely saved me hours. I’m quite chuffed, really. Now I can focus on training the wand, getting that data formatted for Tensor Flow, training a net/model, getting the results TensorFlow Lite-ready, and dropping that on the wand.

It’s gonna be great!

I created the simplified dueling system because the spells in the first dueling system were too difficult. I’ve spent some time with the simplified dueling system; it’s too simple. It’s great as a “first time player” trainer, but it needs to be faster and have more depth. This is not surprising and reasonable.

So I’m making an intermediate dueling system. Three basic core principles to it:

  1. Keep everything that’s in the simplified system.
  2. Decrease the time you have to react to a storm (formerly ball) attack.
  3. Add two more attacks – zap and leech.

The spells:

  • Storm – The fundamental attack.
    • Speed: Simplified it takes 10 seconds to hit. Let’s cut that to 5.
    • Damage: 1 pd
    • Defense: Opposed = 0 pd; orthogonal = 1 pd; same = 2 pd
  • Wall – The only defense.
    • Speed: Instant. Lasts until used or over-spelled.
  • Zap – A quick attack.
    • Speed: 3 seconds.
    • Damage: 1 pd
    • Defense: Opposed = -1 pd (You heal a point!); orthogonal = 0 pd; same = 1 pd
  • Leech – A slow, sticky attack that’ll kill you if you ignore it.
    • Speed: Every 7 seconds.
    • Damage: 1 pd
    • Defense: Opposed or orthogonal: 0 pd; same = 1 pd

That looks ok. I’ll code it up and see how it works out.

I showed the wands off to the public at Austin Maker Faire on May 4, 2019 and learned a lot.

  • Young boys like to shake things very vigorously.
  • Thinly-printed PLA plastic breaks when shaken vigorously.
  • If the wand shaft and handle are separate pieces joined at the neck, that connection need to be very secure or it will fail.
  • PLA wands break easily in the plane they’re printed on when you drop them on concrete.
  • I need to add a fragility warning to the descriptions in the store.
  • More people than you’d expect will press a button with no idea of what it does. (The wands got turned off a lot.)
  • Having only audial or only visual feedback is not sufficient. Both work really well.
  • Younger children liked the blocky wand more than the round wand. I’m calling this “The Minecraft Effect.”
  • The dueling spells are too hard to cast – especially the “ball” part of any attack spell. I’ve simplified it.
  • Some (a few) people were ready to buy right on the spot.
  • Print cheap info cards on bright paper, like fluorescent green or yellow.
  • Restrict access to your stuff. Do not let people access both sides of your demo table (for example).

I need to redesign some of my wand shells and learn about how to print with plastics other than PLA. It was a good experience. I’m feeling pretty good about the entire thing. Yay!

Austin Maker Faire’s tomorrow, and I have very little in the way of info about how the programs for the wands work. It’s my lunch break, so I’m gonna write as much as I can as quickly as possible. I figure folks can pull this blog up on their phones if needed…

Wand Positions

To use your wand correctly, it helps to know the positions it recognizes. Wand-Ring wands recognize eight positions: Ahead, Left, Right up, down, Up, Down, and Back.

  • Straight Ahead (aka: center)
    • Holding the wand in your hand like you’d hold the handle of a bicycle (…or a wand, perhaps), pointing it straight ahead, parallel to the ground.
    • Straight Ahead is the “neutral” position. Most games assume this is the default position you’ll have when you’re holding the wand during active use.
    • The color associated with Straight Ahead is white.
    • The shorthand for Straight Ahead is “A.”
  • Left
    • From center, twist the wand 90º counter-clockwise (aka: widdershins), as you would a doorknob.
    • The color associated with Left is red.
    • The element associated with Left is fire.
    • The shorthand for Left is “L.”
  • Right
    • From center, twist the wand 90º clockwise (aka: deosil), as you would a doorknob.
    • The color associated with Right is blue.
    • The element associated with Right is water.
    • The shorthand for Right is “R.”
  • up (with a tiny “u”)
    • From center, point the wand 45 to 50º upward, relative to the ground.
    • The color associated with this position is yellow.
    • The element associated with up is air.
    • The shorthand for up is “u.”
  • down (with a tiny “d”)
    • From center, point the wand 45 to 50º downward, relative to the ground.
    • The color associated with down is green.
    • The element associated with down is earth.
    • The shorthand for down is “d.”
  • Up (with a capital “U”)
    • From center, point the wand 90º upward, relative to the ground.
    • The color associated with Up is aqua.
    • The shorthand for Up is “U.”
  • Down (with a capital “D”)
    • From center, point the wand 90º down, at the ground.
    • The color associated with Down is light pink.
    • The shorthand for Down is “D.”
  • Back
    • Pointing the wand over your shoulder at more than 45º from Up should register as Back.
    • The color associated with Back is magenta (purple).
    • The shorthand for Back is “B.”

When you wave and twist your wand, it moves from position to position. How your wand reacts to being moved depends on the software that’s loaded on your wand.

Using the Multimodal Software

To change from one mode to the next mode, give the handle of the wand a firm, but gentle bump. Bumping the last mode cycles back to the first mode.

Mode 1: Twinkle Mode

When you turn your wand on, it’ll sparkle and twinkle. It’s pretty, but it’s not listening to how you move it.

Mode 2: Dazzle Mode

Dazzle mode moves eight differently-colored balls up and down the wand at different speeds. It’s pretty, but it’s not listening to how you move it.

Mode 3: Doodle Mode #1

Doodle mode lights the entire wand up. The color of the wand depends on what position it’s in.

Every spell has a specific sequence of positions that’ll trigger it. To cast a spell, you have to move your wand through the correct sequence of positions. Your wand will change color to match the Wand Positions listed above.

Mode 4: Doodle Mode #2

Doodle mode #2 sends a pew-pew ball of energy up the wand when you change from one position to another. The color of the ball matches the wand’s new position.

Mode 5: Daylight Mode

Daylight mode sets the entire wand to full white brightness. It’s not listening to motion in this mode.

Mode 6: Gremlin Infestation! Mode

This mode is a real-time game. Red and blue gremlins are infesting your wand. Conjure portals that match their color to send them back!

These instructions assume you’re holding the wand in the center position (pointing straight ahead).

A sequence of red and blue lights (gremlins) will appear at the tip of your wand. Every now and then, a new gremlin will appear at the tip, pushing the other gremlins closer to your wand’s handle. If the gremlins reach your handle, your wand’s matrix collapses (you lose the game).

To conjure a portal, twist your wand from Ahead to Left or Right. Left conjures a red portal. Right conjures a blue portal. Your portal will appear right next to your handle – as far from the lead gremlin as possible. To launch your portal at the lead gremlin, twist back to center, then flick the wand from center to up or down and back to center again. If your portal’s color matches the gremlin’s color, the gremlin will disappear and the portal will return to where you conjured it. If they don’t match, the portal will return, but the gremlin will stay.

Good luck!

Mode 7: Spell Duel Training Mode

This mode helps you learn the spells you’ll cast when you’re dueling with other Wand-Ring wand wielders. This mode divides your wand into four regions: The position queue, the active spell, current mana, and current durability.

  • The Position Queue: The eight light-pairs at the tip of your wand show the last eight positions the wand’s been in, with the newest at the tip and the oldest closest to the handle. Knowing what positions the wand’s been in helps you cast spells correctly.
  • The Active Spell: When you cast a defense, or someone hexes you with an attack, the middle two light-pairs on your wand will tell you what defense or attack is active on your wand.
  • Current Mana and Durability: The five light-pairs closest to your wand’s handle show you how much magical energy (mana) and durability (health) your wand has. The blue lights indicate your wand’s mana; red for durability.
    • When you cast a spell, you’ll lose mana. Mana regenerates over time – fairly rapidly.
    • When your wand takes damage, it loses durability. Durability does not come back.
    • Look out! If you cast a spell and you don’t have enough mana, it’ll use durability in place of mana. If you’re not careful, you’ll knock your wand out.

Wands in spell duel training mode can cast 15 different spells: three “just for fun” spells, four defenses, and eight attacks.

The Fun Spells
The following uses the shorthand notation from Wand Positions (above).

  • Fun #1: ALARAL
  • Fun #2: ARuUL
  • Fun #3: AdDdARA
  • Fun #4: >>>SECRET<<<

The “Real” Spells – Defenses and Attacks

Wand-Ring wands use an adjective + noun syntax to cast spells. The four adjectives are Air, Earth, Fire, and Water. The three nouns are Ball, Jet, and Wall. Four adjectives times three nouns = 12 spells, ranging from Airball to Waterwall.

The Elements (Adjectives)

  • Air: AuA
  • Earth: AdA
  • Fire: ALA
  • Water: ARA

The Forms (Nouns)

  • Ball (standard attack): AuUBUu
  • Jet (quick, weak attack): ARBLA or ALBRA
  • Wall (defense): AuUL or AuUR

Examples:

  • Fireball: ALAuUBUu
  • Waterwall (the best defense against a fireball): ARAuUR or ARAuUL
  • Earthjet: AdARBLA or AdALBRA
  • Airball (Air “ball” and “wall” spells are a little weird because of the “AuAu” stutter at the beginning): AuAuUBUu

Conclusion

So there you have it, a crash course on how to use

(Wand-to-wand communication is hard!)

Austin Maker Faire is this weekend – on May the 4th. I’ll be showing the wands there, which is exciting as the Dickens. I really, really wanted to have wand-to-wand dueling (w2wd) working by then. I fear that’s not going to happen. Here’s what’s up…

I’ve been working on w2wd off and on for the past few months. I’ve been working it in earnest the last two days. I can get wands to create stable mesh networks with the PainlessMesh library. I can get them to transmit and receive messages. I can get them to act on those messages – even to the point of a receiving wand lighting specific lights in response to a message it receives.

But if I get much more complex – if I add additional light effects or try to read specific gesture sequences as spells – it gets a little unstable.

Ultimately, I need to “level up” my programming skills. I need to really understand how to use multithreading and both cores of the ESP32. So far, I’ve been able to fake it; I’ve relied on that for the limited comms success I’ve had to date. I wish I had more time to buckle down and improve my skills! 🙂

The wand-to-wand limited duel demo I’m coding has no visual or audio feedback to tell you when your wand recognizes that it’s changed position. I need to add that; that’ll go a long way toward telling me how it’s failing. If I can get comms stable (if I can show that user error was to blame instead of comms), I need to add a simple deadline timer for when you get hexed and a simple hit point system (three hits and you’re out). I’m going to refrain from including  a mana (magical fuel) system, and defenses will stay up until a hex knocks them down or you cast a new defense.

Simple w2wd demo play sketch:

  • Players start with no active defense, no active attack, and three hit points (HP).
  • There are four attack spells (AEFW walls) and four defense spells (AEFW balls).
  • When you cast an attack, it jumps on the other player’s wand. (Casting an attack when you’re hexed does not make your hex pop.) If your opponent’s wand is already hexed (has an attack on it), the old hex fizzles and your new attack becomes the new hex. <<< This resets their timer; indiscriminately spamming attacks on your opponent is counterproductive.
  • When you cast an attack, it sets a “declareAttack” timer for 1/2 second. Your “currentAction” stays set to your most recently-cast attack until your declareAttack timer expires (Expiry changes your currentAction to “nil.”) or you cast another attack (That resets your declareAttack timer and changes your currentAction to your new attack.). <<< The declareAttack timer ensures your opponent receives (hears) your attack.
  • When you receive an attack, your wand sets amIHexed to True, sets currentHex to the attacking spell, sets the hex display LEDs to the attack spell’s colors, and sets hexDeadline to current time + 10 seconds. It doesn’t need to check if you’re currently hexed, and it doesn’t need to see if you have a defense. Other routines will deal with that.
  • When you cast a defense, it becomes your current defense – replacing any defense you may currently have on your wand. Casting a defense does not trigger attack-vs-defense resolution; that’ll happen during the “hex upkeep” phase.
  • Hex Upkeep: If your wand is hexed, check for a defense and resolve accordingly. If no defense, compare the current time to when the hex should explode. If it hasn’t exploded, set hex brightness in proportion to proximity to explosion. If it’s exploded, erase hex, play sound, and remove a hit point.
  • Defense resolution: The only perfect defense is an opposed defense (eg: fire vs water, earth vs air). Orthogonal defenses let 1 point of damage through. Allied defenses let two points of damage through. When a defense resolves vs an attack/hex, it removes the hex (amIHexed = False; set hex display LED brightness to 0) and defense.
  • Health upkeep: If HP <= 0, lose the game.

That was helpful! Let’s see if I can implement it. 😀

A little less than a year ago, some friends and acquaintances of mine participated in Cerridewn Community College of Wizardry – a live-action role-playing game about the students and faculty at a community college for would-be wizards in a Harry Potter-esque world. I thought it’d be nice if they could have good wand props, and that wand-making would be a fun “class to teach.” Specifically,  I wanted wands that:

  • Changed color and brightness directly in response to your gestures
  • Would create the exact same response if you made the same gesture. For example: Pointing up, then down, then up would always return red > blue > red.

I did some research and found many commercially available wands that light up, sometimes in response to simple gestures. I didn’t find any that did what I wanted. Then I checked to see if there were any DIY projects that did what I wanted. The answer: I found one Adafruit project ( https://learn.adafruit.com/magic-wand/parts-slash-tools ) that approximated what I wanted, but it wasn’t close enough.

So I decided to make make the DIY wand of my dreams. I got an Arduino Uno, an MMA 8451 accelerometer, an RGB LED, and started learning and experimenting.

I was telling a friend about this project and she said, “So you’re going to be able to cast spells, right?” I realized that (since I was already tracking the wand’s position and correlating that to specific LED colors), it wouldn’t be hard to keep a queue of recent past positions and trigger specific LED sequences in response to specific past position sequences in the queue. “Sure, I’ll make it cast spells.”

So I told a different friend about making wands that cast spells. They said, “So you’re going to be able to have spell duels between wands, right?” Well, that’s not trivial. I’d have to add wireless communications, like Bluetooth or some such to the wands. But hey, I’ll figure it out, right? And it’ll be awesome when it works! “Sure, I’ll set them up so they can duel.”

So I told another friend about making wands that can communicate wirelessly and duel with each other and he said, “So you’ll be able to use your wand to interact with a whole virtual world of magic – an augmented reality – that’s overlaid with the real world that you view through your phone?” Developing software like that is way beyond my skill set, so I partnered with Shawn (the friend who asked the question) to develop this.

Understandably, Shawn and I had dollar signs in our eyes. We were ready to launch this and take off like gangbusters. That’s when I had the bright idea to do some patent research. Turns out that two-and-a-half months before I even thought of this idea, Intel filed a patent for the same thing. Now, I have some issues with Intel’s particular patent – specifically as regards prior art and being overly broad – but that’s largely academic. After all, if it comes down to a legal battle between Intel and us, we lose – even if we’re in the right.

This revelation seriously quashed our enthusiasm. The project stalled out for a while as we regrouped and worked on other projects. But we kept coming back to these DIY wands. Ultimately, we decided omit the augmented reality world and release the wand design (hardware and software) as free open source content.

…and that brings us here.

Wand-Ring Wands

We call the wands we make “Wand-Ring” wands. It’s a reference to wandering around the real world to interact with an extensive virtual world, but was also a reference to ring designs we planned to include in the wand shells and another secret-ninja idea we have. Full-featured Wand-Ring wands have three essential components: an ESP32 micro controller, an LIS3DH accelerometer, and RGB LEDs. We’re using the ESP32 because it has integrated WiFi and Bluetooth, plenty of memory, and can use existing Arduino libraries. We’re using the LIS3DH because it’s “baked into” the PropMaker Feather Wing, which has easy connectors for LED strips and a speaker. We’re using Adafruit’s .5m NeoPixel strip for light-based feedback ’cause it’s relatively inexpensive, easy to connect, and the LEDs are individually addressable (so it only takes one pin to “drive” them instead of 90).

Eminently Hackable

It’s worth noting that the Wand-Ring hardware (ESP32 + PropMaker Wing + NeoPixel) – in tandem with the software libraries (FastLED, Adafruit’s sensor libraries, etc…) we’re using – is super-versatile. Sure, you can use your wand to delight, dazzled, and duel – and that might be one of the coolest things you can do with it – but you can make it do lots of other great and clever things by uploading new software to it!

The Wand-Ring design also leaves a lot of room for hardware expansion. Want to add a speaker and haptic feedback? Go for it! Want to bling out your wand with more LEDs? Be our guest. Want to use the Hall Effect sensor on the HUZZAH 32 to sense magnetic fields? Awesome! Want to connect to your local WiFi and control your Hue lights by waving your wand? Do your research, master the Hue API, and rock ‘n roll!

Wand-Ring with Wanda and Ron

Wanda and Ron are our mascots. Wanda is a brilliant, creative, and curious witch who likes to make and do things. Ron is her always eager, always hungry, faithful cauldron companion. They’ll be your companions, walking you through making your very own magic wand step-by-step.

What’s this site about then, eh?

For now, this site will be the hub for everything Wand-Ring related. It’ll have the latest news and links to code, hardware lists, schematics, tutorials, pictures, news, and such. We’re stashing the code on GitLab.

We think it’s going to be an awesome, wild ride. We hope you have as much fun as we do!