Halloween is my favorite holiday so I really didn't want to leave the porch light off for two years in a row. However, the pandemic isn't over yet so the candy bowl wasn't going to get refilled unless we could allow for social distancing. Trick-or-treaters walk downhill to get from the sidewalk to our front door so shoving candy into a pipe or sending it in a zipline basket -- the workarounds that many houses used last year -- aren't practical here. Instead, we opted to build a remote-controlled candy bar dispenser.
With one week to go before Halloween we had settled on a mad scientist
theme and built a stockpile of Snickers bars, Kit Kats, Reese's Peanut
Butter Cups, and Hershey's Bars with Almonds. It took several days and quite a few Lego Technic pieces to build
custom, motorized mechanisms for each type of candy that could reliably
spit out exactly one piece at a time.
The little globe on the remote control turns red at startup and then purple after the Bluetooth link is established.
Conveyor belts are versatile but it's much simpler to deal with actual bars. One of the servos is visible in the top-left.
The almonds are not distributed uniformly so a stack will find ways to get stuck unless the bottom bar is tilted forward to minimize the contact patch.
The ends of these flare out just enough to be troublesome.
I wrote a simple MicroPython program for a Mindstorms EV3 that dispensed one piece of candy each time one of the four push buttons were activated. Then I used an nRF52-DK as a Bluetooth receiver and had it respond to remote control commands by toggling two different servos to push the Lego buttons -- each servo could be moved to 0 degrees to push one and 180 degrees to push the other. The girl embedded the servos in a piece of plastic corrugated board and then used zip ties to position the buttons.
Getting this right is harder than it looks but it's faster than implementing a proper UART or I2C interface.
We ran short on time so the nRF52-DK ended up being wired to a breadboard and the candy that was dispensed simply slid down a piece of poster board to a table for collection -- the original concept called for an elaborate ramp a la Rube Goldberg.
The nRF52-DK firmware and wiring was the easy part so it was left until the last minute -- clearly!
A divider provides structure for the mechanical interface between the servos and the Lego buttons and also hides the messy breadboard wiring.
The individual components are fastened to a tote's lid using zip ties.
Adding the tote's lid provides protection.
The remote control itself is actually my favorite part of the build. It is literally just a second nRF52-DK that has been dressed up by the girl to look like something from a mad scientist's lab. She spray painted a shoe box with silver paint and made a wonky "antenna" with an RGB LED stuffed inside a foam ball from the craft store. Then we wired in colorful arcade buttons and some internal RGB LEDs. To finish the build she cut slits in the front so the flashes would be visible when buttons were pressed and affixed a label for each type of candy.
Easily the best looking nRF52-DK I've ever seen.
The project turned out well so we might revisit this concept next year. The best feedback that we received came from a tiny little boy with a sword that yelled "I LOVE IT!" to no one in particular when his candy bar popped out of the machine.
A fog machine can greatly affect the ambience of Halloween displays but unless you invest in an expensive one they can be impractical. The machines that pop up around the holiday must be plugged in to the wall, are not weatherproof, and have relatively small "fog juice" reservoirs. Requiring AC power isn't uncommon for Halloween decorations and they are often installed close to the house, under the eaves or porch covering, so workarounds for the first two challenges are familiar. The obvious solution to the fog juice shortage is to only make fog when someone is around to appreciate it -- but how?
Why Bluetooth Mesh?
Although standing around for several hours on Halloween night waiting to press buttons on remote controls might be an option for the most dedicated among us, ideally the remote controls would be able to activate themselves -- either in response to motion or the state of other devices. Similarly, running wires around the yard is fine in some situations but wireless communication is usually superior. A decade ago I would have advocated using IR to build a network that essentially consisted of a bunch of TV remote controls and receivers but now inexpensive radios are an attractive option because they:
Are arguably easier to work with
Don't require line-of-sight (or a convenient reflection)
Aren't affected by ambient light or fog
Allow bidirectional communication
Offer a path to smart device interoperability
The Bluetooth Mesh functionality that Nordic provides as part of the nRF Connect SDK (NCS) offers all of the advantages of using a radio plus one more that makes it especially interesting for a Halloween display: the behavior of the network can be reconfigured by modifying the devices' publication and subscription addresses using an app, without modifying any firmware. This means that, for example, next year when a second motion detector is added to the display one or more of the devices that used to be triggered by the original motion detector can be pointed to the new one with only a few button presses in the nRF Mesh app (Android or iOS).
Fog machine operation
The main components of a fog machine are a heater, a pump, and a fog juice reservoir. More sophisticated machines can also include features like timers, lights, or chillers but you probably won't find such extravagances on $40 machines like this one.
The large block on the right is the heater. The red wires above it are connected to a thermostat that acts as a switch -- it closes whenever the heater drops below a temperature threshold. Insulating material helps the heater stay hot for as long as possible and is visible next to the thermostat, poking out of the enclosure.
The silver cylinder to the left of the heater is the pump. Its job is to pull fog juice out of the plastic reservoir and push it into the heater so it can be vaporized and expelled from the front of the machine.
The entirety of the machine's wiring fits in a single diagram:
When the thermostat is closed the electricity flows through the heater. During these periods the remote control, which connects via the three pins at the bottom of the diagram, is effectively "off." This happens frequently when the fog machine is producing fog because the heat stored by the thermal mass of the heater is used to vaporize the fog juice, causing the heater to cool. It also happens occasionally -- even when the machine is idle -- as the heater radiates heat to the surrounding environment.
Wired remote controls typically have
a button and at least one LED. An LED that indicates when the machine
is currently capable of producing fog is useful because it wouldn't be obvious otherwise.
This remote has two LEDs: one is on when the machine is capable of producing fog, the other when the machine is currently producing fog.
The original remote is a very simple device:
In summary:
When the machine is ready to produce fog the thermostat is open and AC is available to the remote control via the BROWN and YELLOW/GREEN wires.
Connecting the YELLOW/GREEN and BLUE wires together powers the pump
Replacing the remote
Nordic's Thingy:52 is a prototyping platform that combines an nRF52832 SoC, rechargeable battery, and a bunch of sensors into a neat little package. Putting a 3V microcontroller in control of the fog machine requires solving two problems:
Detecting the presence of AC to determine that the machine is ready to produce fog
Operating a switch to open and close an AC circuit
The first problem can be solved with the help of a cheap 5V wall wart. By taking it apart and connecting it to two of the wires from the original remote the Thingy:52 will think that it's plugged into USB whenever the fog machine is ready. As a bonus, this will also recharge its battery -- the same battery that keeps it from browning out when the heater becomes active!
The 5V from the wall wart is also hardwired to an LED on the top of the new remote's enclosure, to replicate the original remote's functionality. This 5V also supplies power to a separate board -- a board that solves the second problem by using a BJT transistor to open and close a 5V relay. This allows a GPIO output from the Thingy:52 to operate the relay, effectively replacing the functionality of the original remote's button.
Manual operation is useful, especially when positioning the fog machine during setup, so a large push button was also added to the new remote.
Finally, an external power switch is needed so the rechargeable battery can be disconnected when the fog machine is in storage. The addition of seven wires, including one from VDD to the external power switch's LED, is the extent of the required modifications to the Thingy:52 itself.
Firmware
The Thingy:52 already has a USB_DETECT pin that is pulled high when 5V is present on the USB port so keeping track of when the fog machine is ready only requires enabling a pin change interrupt on a GPIO. The button for manual operation is handled the same way. Using a GPIO output to control the relay is even easier.
Adding Bluetooth Mesh is also pretty straightforward, at least when starting from the Light Switch sample in NCS. The original Light Switch sample enumerates four Elements, one for each of the LEDs on a typical Nordic development kit. Each Element has a Generic OnOff Server that allows the other devices on the mesh network to read and write the state of one of the LEDs.
The remote control only needs two of these servers:
The server in the first element works like the button. Setting this element to 1 will produce fog until
it is written back to 0 or the heater becomes active. It is
automatically set back to 0 when the heater becomes active. If the fog
machine is not able to produce fog then setting it to 1 has no effect.
The server in the second element is set to 1 when the
fog machine is capable of producing fog and 0 when the heater is active.
Writing to this element has no practical effect because the written
value will be immediately reverted. A client can read this value to
determine whether or not the fog machine will be able to immediately
produce fog.
The firmware, along with details for provisioning the node, are posted here. The nRF Mesh app is used for provisioning and configuring the node. It also presents a nice GUI that enumerates the Elements and their servers:
The app also allows for interaction with both of the servers. Selecting one of them and then scrolling down leads to a "Generic On Off Controls" widget:
The "READ STATE" button at the bottom does exactly what it claims and the
state of the server can be toggled by pressing the "ON" button.
The purpose of this project is to augment the Nerf Mega Mastodon blaster with a Nordic nRF52840 dongle,
RGB LED, and vibration motor so it becomes fly-by-wire and can
optionally be controlled over Bluetooth. Without a Bluetooth connection
the blaster's original operation is essentially unchanged.
The finished product, with barely-visible modifications -- a few screw heads and an LED
About
The Mastodon is an interesting blaster because of its unique
combination of fully-electric operation and deterministic dart handling.
When fully loaded, up to 24 darts can be fired individually without
further interaction from the user. The current replacements for the
Mastodon either require the user to cock and/or press something to fire
each dart (e.g. Ultra ONE) or shoot at an unpredictable rate (e.g. Prometheus MXVIII-20K). A common characteristic that is shared by all of these automatic blasters is a "flywheel" mechanism
that throws the dart in a similar fashion to baseball pitching
machines. The mechanism that sets the Mastodon apart is a motorized
plunger that pushes each dart into the wheels, rotates the drum, and
uses a switch to ensure that the plunger motor stays powered until the
plunger is retracted (which would interfere with spinning the drum to
reload it).
Without a Bluetooth connection the blaster's operation is changed slightly:
After firing 24 darts the blaster automatically stops shooting until the triggers are released and pressed again
No dart will be fired until the wheels have had a second to spin up
An RGB LED on the top of the blaster signals that the wheels have
spun up (green), a safety fault has occurred (blinking red), or a
Bluetooth connection is active (blue)
Connecting to the blaster via Bluetooth adds the following functionality:
The blaster's ammo count can be set so a "ammo remaining" notification will be sent after each dart is fired
Three selective firing modes are available: single-shot, three-dart burst, and fully automatic
Both triggers can be individually overridden
Both triggers can be locked out
Haptic feedback can be initiated for a specified amount of time
The blaster's safety mechanisms still function normally. Attemping to
fire when either of these conditions is present will result in a safety
fault:
The jam door is open
The drum is removed
If a safety fault occurs then the LED will blink red for 30 seconds
before the blaster turns off. Rectifying the fault condition and
pressing the triggers will reset it. The safety features can be disabled
during development via CONFIG_NERF_SAFETY_FEATURES_ENABLED in the
project file. The firmware for the project can be found here.
Although the blaster's wiring has been changed significantly, the
original switches and triggers remain. The only modifications to the
plastic housing are holes that were drilled to mount two PCBs (via
standoffs), a vibration motor, and an LED. The bipod in the photo is
off-the-shelf and attaches to the blaster's "tactical rail" using a
picatinny rail adapter.
Original hardware
There are a couple of videos online that show how to rip out the blaster's internals and replace the two trigger switches with ones that can handle LiPos. That approach allows the blaster to shoot harder and faster, at least until the motors fail, but has the disadvantage of disabling the mechanism that ensures that the plunger is always retracted back to a known position. The point of this build is to add remote control while retaining -- and appreciating -- the blaster's original design.
Pro tip: the battery door has four sections, one for each size of screw. Use a bit of colored tape to mark each screw hole during disassembly to make life easier later.
Original wiring, including harness coloring
The blaster's original wiring is pretty straightforward. The only tricky part is the trigger override -- the gray wire -- that overrides the plunger trigger until the plunger has retracted. The configuration of the passives around each of the motors is a rough approximation.
A close-up of the motor passives
The two triggers are configured so that the "rev" trigger, that powers the "fly wheels", must be depressed before it's physically possible to depress the trigger that powers the plunger.
Two triggers: "rev" at the bottom and "plunger" above it
The "fly wheels" sit at the front of the blaster. When a dart is shoved into the passage between them the wheels catch it and throw it out of the barrel.
A little silicone curtain (on the left) covers the entrance to the "fly wheels". The tip of the plunger can be seen on the opposite side of the gap.
The plunger mechanism is self-contained and the plunger motor pokes through the top cover so it can engage the gearbox below. The orange switch to the left of the motor is engaged by a ridge on the plunger.
The motor, spring, and switch of the plunger mechanism are visible when the cover is installed
Removing the cover exposes the plunger itself along with its gearbox
A raised ridge runs along the length of the plunger. The ridge is low along the section that engages the switch when the plunger is extended far enough to obstruct the drum. This allows the switch to override the plunger trigger in case it is released while the plunger is extended.
The large cog on the left has a section with no teeth. This allows the plunger motor to remain on constantly even when the plunger is being retracted by the spring; the cog that engages the plunger is momentarily allowed to spin backwards while the large cog continues to spin forwards.
The firmware synchronizes to the output of the plunger switch to ensure that the plunger is always returned to the proper position after the trigger is released.
Output of plunger switch when firing at 8.5V
Additional hardware
The original switches were retained but now they are routed to an nRF52840 dongle that is mounted on a simple PCB.
The microcontroller lives on a very simple PCB (voltage regulator not shown)
The finished product, minus the protective heatshrink
A simple trick that makes it easy to solder headers onto the dongle
The USB contacts of the Nordic dongle protrude far enough from the side
of the board to allow it to be plugged into a PC for reprogramming.
The original motors were also retained but now they are driven by a quad, half-bridge driver.
This is an older driver but it's TTL-compatible and easy to use
The populated driver board
JST headers were used to so the two boards are removable.
Heatshrink makes everything better
The inputs and outputs are labelled for easier assembly
The two boards were installed using standoffs. The modifications to are barely noticeable given the blaster's aesthetic.
The driver board is not visible because it is installed underneath the plunger mechanism. The vibration motor is located a few inches to the left of the triggers.
An inexpensive bipod is the most elegant way to stabilize the blaster for remote operation. A plastic adapter was used to allow the picatinny bipod to attach to the blaster's proprietary rail.
Sometimes it's nice to carve out some time to build something that would make the 12-year-old version of you give you a high-five -- and, in this case, a five-year-old nephew.
Few things are cooler than RC airplanes.
A view of the servos and control surfaces.
My nephew loves those giant (4' wingspan), $10, polystyrene gliders so the girl and I decided to spend some time experimenting with aircraft building.
It really does fly over 100' and is surprisingly durable.
The Build
We started by cutting out aileron and elevator flaps and using duct tape to create hinges. Fixing the various control surfaces at different angles allowed us to experiment with their effects. Next, we decided to add some servos to create an RC glider. The fact that the wings popped out during crashes seemed like a feature so we gave each wing its own servo -- the common, but less robust, alternative is using one servo mounted to the fuselage that is linked to both wings. We mounted one additional servo to the tail of the fuselage for the elevator. Even though the glider used a tiny 3.7V, 220mAh battery that was
scavenged from a quadcopter, the whole aircraft was simply too heavy to
sustain flight as a glider. The four motors from the now-battery-less
quadcopter were still perfectly good so we built some brushed DC motor
control boards and glued the motors to the fuselage. To power the whole
thing we found an inexpensive 2-cell LiPo battery and a cheap Battery
Elimination Circuit (BEC) to provide 5V to the servos, motors, and
receiver. The result looked sweet but was woefully underpowered.
Rev 1: Lots of duct tape and disappointment
For the second rev, we replaced the duct tape with plastic hinges to save weight.
Cut slits in the wings, dab some StyroGlue on the hinges, and let it set.
To protect the servos on the wings the girl purchased small polystyrene globes from the craft store, cut them in half, and hollowed out spaces for the servos.
The globes are easy to hot-glue to the wing and look very natural.
After upgrading the hinges it seemed like a good idea to add landing gear. The local hobby shop had some foam wheels that we
picked up for less than $10. The back wheel had its own plastic mounting
plate that was easy to glue to the fuselage.
The rear elevator's servo is easy to embed and we found the perfect landing gear.
The front wheels fit nicely on coat hangers so we glued the coat
hangers into wooden dowels and then glued the dowels into the fuselage.
The white is a plastic coating on the coat hangers -- we stripped that part off any spots that needed glue.
Mounting The Motor And Keeping It Cool
Now we were committed so we purchased a cheap "park flyer" kit from Amazon with a 1000KV brushless motor, 10"x4 prop, and ESC. We screwed the new motor into wooden dowels that had been glued into the front of the fuselage.
Dowels mounted directly to the motor provide very little crash protection and no thermal insulation.
We carved out some space at the bottom of the fuselage for channeling the motor's wires. The result was hilarious to look at but after a few crashes it was difficult to get the motor aligned correctly with the rest of the fuselage.
Looks a little fishy.
To make the motor easier to mount we ended up machining an aluminum plate that lays flat against the fuselage and includes two tabs for mounting the decorative cowling. This plate improved crash resistance and also helps to disperse the heat from the motor.
A couple of hours on a mini-mill can solve so many problems.
The motor and Electronic Speed Controller (ESC) can get quite warm so we used milkshake straws to ensure that the motor wires don't completely impede airflow in the ESC's cavity.
Milkshake straws, bubble tea straws, who can tell the difference?
The ESC lives in the skinny cavity, the receiver lives in the wider cavity beyond the tape.
The airflow from the front of the plane needs a place to exit so we mounted some additional straws on both sides of the fuselage at the back of the ESC cavity.
The exit straws have the fortunate side effect of looking really cool.
Final Tuning
To test various combinations of batteries, motors, and propellers we threw together a simple rig to measure thrust vs. amperage. It's not perfect, and certainly not calibrated, but it allowed us to make relative measurements for different setups.
TV tray + right-angle shelf brace + hinge + clamp + kitchen scale + cheap multimeter with 20A fuse = thrustometer
The great thing about chalk boards is that you can fill them with random notes and there's no hurry to erase them.
We waited until the plane was mostly finished and we had chosen a battery/motor/propeller combination before we carved out space for the battery so we could use the battery's location to balance the plane. Unfortunately, this required putting the battery pretty far back in the skinny part of the fuselage; this is the most likely part of the fuselage to break. We addressed this problem by lining the battery cavity with popsicle sticks for reinforcement.
The popsicle sticks were glued together to make sheets before they were hot-glued into the fuselage.
The Receiver
We used the SparkFun nRF52832 Breakout board as the receiver because it offered a nice form factor. Most servos and ESCs run at 5V but the nRF52832 tops out at 3.6V so we used a cheap level converter to interface between the nRF52832 and its outputs.
The level converter along with a capacitor to add some bulk capacitance to the 5V rail for brown-out resistance.
We also tacked a simple programming harness on to the breakout board so it could be programmed via an nRF52-DK. The two boards were joined together using 0.1" break away headers.
Sparkfun sandwich
We used right-angle 0.1" headers on one side to interface to the ESC. On the other side, we used labelled micro-JST connectors for the various servos (roll, pitch, yaw).
Power and throttle signal in the front, roll, pitch, and yaw in the back.
The ESC connected to the receiver along with the battery connector.
This harness connects the receiver on the left with the servos on the right. The large connector on the left is a 5V power and ground pass-through from the BEC.
The Transmitter
The transmitter is an nRF52840 development kit that is mounted on some foam board along with a couple of analog thumbsticks and a AA battery pack. The nRF52840 has +8dBm output power and the nRF52832 on the receiver has -96dBm RX sensitivity so range has not been a problem. Bluetooth Low Energy isn't particularly well-suited for this application so we created a proprietary, FHSS, 2.4GHz protocol that allows the transmitter to send packets to the receiver without waiting for a response.
Easy to carry, easy to hold, easy to take apart because I'm only borrowing the nRF52840-DK.
Conclusion
I can't really comment on the plane's flight characteristics compared to other aircraft because this is the only plane that I've ever flown. However, flying is not easy so it's nice that polystyrene can be repaired quickly. We also learned some things:
StyroGlue works very well for small parts like hinges
Hot glue works the best for large parts like dowels and fuselage repairs
The big sanding drum in the Dremel kit chews through polystyrene nicely
