Raising a Flag with NodeMCU, WebSockets, and React Native
Imagine a world where flags fly intelligently at half-staff. Imagine driving through your neighborhood and noticing all the flags at half-staff, pausing to consider why. Imagine waking up to see your flag at half-staff and reflecting on the reason. This is my first journey towards collective reflection on building quick, sacrificial prototypes.
Build List
Flagpole: 2"x2" Pine Board, 1/8” Braided Nylon ope, Pulley
Flag: Decorative Garden Flag
Hardware: NodeMCU, 360 Degree Continuous Rotation Servo Motor, Infrared Sensor, Breadboard and Assorted Wires, Wood Candle Cup
Software: Ollie-Arduino, Ollie-Nodejs, Ollie-React-Native
Misc: Cardboard, Tape, Glue, Scissors
Prototyping 101
I wanted to see how quickly I could both build a prototype and receive design feedback. I live in a studio where the bedroom runs into the dining room: a flagpole never had a chance. As a result, the first step would be to prototype the flagpole itself. Browsing through the local lumber yard, I decided on using a 2"x2" pine board, 1/8” braided nylon rope, and a pulley to replicate the flagpole. For the flag itself, I bought a decorative garden flag and glued it onto the rope.
Building for Automation
I identified three problems: 1.) How do I move the flag? 2.) How do I communicate when to raise and lower the flag? 3.) How do I stop the flag at both half and full mast?
Moving the Flag
I settled on using a 360 degree continuous motor because the motor had enough torque to move the flag and a usable library already existed. The difficulty came in finding a shaft that attached to the motor and moved the rope. I again stopped off at the local lumber yard but did not find an “out of the box” (aka, hackable) solution. Before I broke down and just bought a 3D printer, a friend suggested visiting a local crafts store. Until this point, the only experience I had with crafts stores was Halloween decorations and fake flowers but decided to give it a try. There I discovered many hackable solutions but settled on using a wood candle cup. It was very elegant with a grove to track the rope and a flat backed surface to attach the servo. After connecting it all up, I turned on the motor but the flag did not move because the candle cup was too slick. There was not enough friction! Hoping to gain traction, I tightened the rope and still the candle cup did not grip the rope. Deciding to rough up the grove to add a bit of friction, I grabbed some sandpaper and roughed up the groove and tried again. Still, the rope just slipped. I needed a lot of friction.
Looking down at the sandpaper, an idea struck me: What if I used the sandpaper as the gripping surface? I cut a strip of sandpaper, being careful to fit it inside the groove, and glued the sandpaper and candle cup together. It worked! The flag moved. As I tested it out, I noticed the rope continued to slip off: the grove was not deep enough. To compensate, I quickly cut out a circle from cardboard to keep the rope in place.
Communicating with the Flag
It was not enough that the flag moved: it had to move remotely. I settled on using nodejs for the prototype because I planned on making a react native app to go along and did not want to engage in context switching. I settled on using WebSockets, an elegant two-way, event driven messaging protocol (no polling required!). A quick search on the web revealed that websocket libraries already existed for both Arduino and nodejs. How nice! After reading the documentation and importing the libraries, I had a flag that moved remotely.
Sensing Flag Position
The next step in the automation process was sensing where the flag was. After all, it is not automation and the internet of things unless you have sensing. A couple of solutions exist to determine position: ultrasonic and infrared. I went with infrared because it was the less expensive option. If I wanted the project to work outdoors, ultrasonic would need to be added. Once I settled on the technology, I needed to engineer the how. What was the infrared sensor going to sense? After some thought, I settled on two markers of tape on the rope to indicate the full and half mast positions.
Finally, I needed to attach the sensors and place them correctly to pick up on their respective marker. Cardboard, especially small boxes found at craft stores, is a quick and cheap solution to build and test enclosures. Measuring the correct distances, I punched holes and positioned the infrared sensors so that they could pick up the markers.
At this point, we have a successful prototype that simulates a remote action taken on a server (pressing the up/down arrow on the computer) and the flag moving until it is at half or full staff. But let’s take it one step further (or backwards).
Getting Feedback and Building Again
After demoing the prototype to a few friends, they shared it was needlessly complex. Today, the reason flags did not go to half staff for them was because they did not want to untie the knot because they were in a rush. Some even had notifications to tell them when to raise/lower their flags and still did not do it. They also criticized the design and did not see themselves attaching markers to the rope: needless complexity. From their feedback, I realized that there was the hidden assumption of retrofit vs embedded solution. If I was going to build for a retrofitted solution, the problem I needed to solve for was the physical convenience of moving the flag without un/tying.
A Mobile Solution
After their feedback, I decided to remove the internet connectedness story and go mobile. A user would use a mobile app to initiate the position of the flag.
I turned to react native to quickly build a prototype app. The interface of the app was incredibly simple with an up and down arrow. Moreover, I was able to integrate with the existing websocket logic as react native native had existing websocket libraries. After some coding and testing, I had a working application.
Getting Feedback… Again
Inviting my friends back over, I shared with them the new developments and asked for feedback. They shared that they appreciated the new app and could visualize themselves using it. They again brought up push notifications and that the app could inform them when and why to lower the flag. Observing the smiles on their faces, I asked them if they enjoyed moving the flag. Interestingly, they shared that it was sort of fun to play around with it. This was an unexpected turn. While I had been designing a product to totally remove (automate) the human element, perhaps I should have been exploring how to make it fun.
Final Thoughts
Once again, the importance of getting user feedback early in the design cycle was reinforced. Whether to validate the customer fit or the engineering design, the purpose of a prototype is to test. If not for this feedback, I may have spent time on building more features on the server side. I also empirically validated two concepts: 1.) the distinction between retrofitted vs embedded IoT solutions and 2.) human interaction when designed for fun can be just as importance as designing for automation. Finally, I must confess my new found love in cardboard, small boxes, and glue. Because without them, I would not have been able to quickly rebuild and design my prototypes.
