← Back to Projects
EmbeddedShippedFeatured

BloomBot IoT

IoT flower for long-distance check-ins: proximity opens the bloom, and remote messages blink out in Morse on an LED heart.

The idea was simple: people far apart should still have something physical to share. BloomBot lives on an Arduino UNO R4 WiFi with Blynk. Get close and an ultrasonic sensor drives the servos to open the flower. Send a message from the app and an LED heart inside blinks that message in Morse. LCD output helps when I cannot sit on serial during a demo. The cute part is the flower. The hard part was keeping WiFi, sensing, multi-servo peaks, and Morse timing honest on one board without brownouts.

Engineering highlights

  • Ultrasonic proximity opens the flower through coordinated servo motion
  • Remote Blynk messages blink on an interior LED heart in Morse code
  • Shipped a public demo after fixing brownouts and timing under concurrent servo load
Date
Spring 2026
Focus
Embedded Robotics
Build stage
Shipped demo; next hardware revision
Disciplines
Electromechanical Actuation · Embedded Control · Wireless Integration · Power & Packaging
Source codeDevpostWatch skit
iotembeddedroboticsmechatronicsintegration
Demo
Full write-up below. The hero is the short version. This is the build story: what I designed, what broke, and why I made the calls I did.

Motivation

Why I started this

What pulled me in, and what I wanted to get better at.

Why I built it

I wanted a physical way for long-distance couples or friends to check in, not another chat notification. Something you walk up to, that opens, and that can carry a short message across WiFi.

What interested me

Proximity has to open the bloom cleanly, and a remote message has to become Morse on the LED heart without starving the servo loop. Wireless, sensing, and actuation share the same board and power budget.

What I wanted to learn

Demo day is a reliability problem. Retries, rail margin, and readable local feedback mattered as much as the flower motion itself.

System Overview

How the system fits together

BloomBot is an Arduino UNO R4 WiFi flower for remote check-ins. Walk close and ultrasonics trigger servos to open the bloom. Send a message over Blynk and an LED heart inside blinks that text in Morse. LCD status keeps the interaction readable. The application is connection at a distance. The engineering is keeping those loops honest together.

01

Wireless control plane

Blynk delivers remote messages and control events over WiFi into firmware handlers.

02

Proximity sensing

Ultrasonic distance decides when someone is close enough to open the flower.

03

Bloom actuation

Servo motors open and close the flower as a coordinated motion, not a single sweep.

04

Morse LED heart

Submitted messages are encoded and blinked on an interior LED heart.

05

LCD status

On-device text so state is visible without a laptop during demos.

06

Power & packaging

Rails and harness have to survive concurrent servo current without brownouts.

Data flow

Ultrasonic distance -> open/close servo sequence. Blynk message -> Morse encoder -> LED heart blink pattern. LCD mirrors status for the person next to the flower.

Control flow

Firmware interleaves sensor reads, servo updates, WiFi handlers, and Morse timing. Retries and timing guards keep a remote message from freezing the bloom mid-open.

Integrated platform
BloomBot assembled platform

Proximity opens the bloom; remote messages become Morse on the LED heart.

Engineering Breakdown

Broken down by discipline

Each block covers the goal, the design, what broke, what changed, and what shipped.

01Electromechanical Actuation

Electromechanical Actuation

Goal

Open and close the flower with multiple servos when someone steps into range, without killing the rail.

Design

Ultrasonic proximity gates a coordinated open sequence. Concurrent servo peaks are treated as a power and timing problem, not just a PWM list.

Challenges

  • Concurrent servo loads brown out rails if sequencing and supply margin are wrong.
  • Opening on noisy distance readings looks broken even when the mechanics are fine.
  • Demo lighting and camera setups hide intermittent stalls that show up on stage.

Iterations

  • Single-servo bring-up.
  • Multi-servo open/close with staggered peaks.
  • Distance-gated bloom so presence, not a button mash, opens the flower.

Final implementation

Proximity-triggered bloom motion integrated with the wireless message path and validated in live demos.

Live behavior

Get close and the flower opens; remote interaction stays on the same system.

02Embedded Control & Sensing

Embedded Control & Sensing

Goal

Keep ultrasonic reads, Morse LED timing, and Blynk handlers from stepping on each other during a public demo.

Design

Distance samples decide open/close. Message handlers encode text into Morse for the interior LED heart. LCD shows enough state that I do not need serial on the floor.

Challenges

  • WiFi under demo RF conditions needs retry logic, not optimism.
  • Blocking Morse or network calls in the wrong place freeze the bloom mid-motion.
  • Sensor noise can false-trigger opens when nobody is actually close.

Iterations

  • Local-only motion tests.
  • Blynk message path into Morse LED.
  • LCD status so remote and local interaction are both readable.

Final implementation

Firmware that couples proximity, remote messaging, Morse output, and bloom actuation into one interaction loop.

Wireless control

Remote messages hit the robot over Blynk and become on-device Morse.

03Systems Integration

Systems Integration

Goal

Ship a single platform where packaging, power, firmware, and UX fail as one system or not at all.

Design

Build documentation and public demo materials treat BloomBot as an integrated product. Harness routing, enclosure constraints, and software retries were co-debugged rather than owned by separate 'parts owners.'

Challenges

  • Integration bugs present as 'WiFi is flaky' or 'servo is weak' when the real issue is shared power or loop timing.
  • Demo rehearsal surfaces failure modes that bench tests miss.

Iterations

  • Breadboarded subsystems.
  • Packaged harness and enclosure bring-up.
  • Full demo rehearsal with reconnect and brownout drills.

Final implementation

Shipped demo with Devpost documentation; next hardware revision targets cleaner harnessing and smoother interpolation.

Build process

Assembly and integration work behind the expressive demo.

Key Design Decisions

Calls I actually made

What else was on the table, what I picked, and why it still made sense once the hardware was real.

01

Blynk for the control plane

The problem

How should remote intent reach firmware quickly for a demo?

Alternatives considered

  • Custom mobile app
  • Raw sockets
  • Blynk virtual pins

Tradeoffs

Custom apps cost schedule. Raw sockets need more UX. Blynk trades platform dependency for speed to a reliable control surface.

Why I chose this

Blynk virtual pins. Integration time went to motion and power, not app chrome.

02

On-robot feedback versus laptop-only debug

The problem

How do operators know state on the floor?

Alternatives considered

  • Serial-only
  • LCD + LED signaling
  • App-only status

Tradeoffs

Serial dies when the laptop is away. App-only status lies when WiFi drops. Local feedback survives both.

Why I chose this

I2C LCD and Morse LED as first-class state channels.

03

Power architecture under servo load

The problem

How do concurrent actuators stay within rail limits?

Alternatives considered

  • Hope the USB rail holds
  • Sequence peaks + dedicated margin
  • Fewer servos

Tradeoffs

Fewer servos kills expression. Sequencing and supply discipline preserve both motion and uptime.

Why I chose this

Treat peak current as a design constraint; stabilize rails and stagger motion.

Evolution

How it got here

Bench bring-up, CAD fits, soldering, and the demos in between. Not just the final photo.

  1. Stage 1

    Nothing working

    Early bring-up where the bloom did not open cleanly. Useful clip because it shows how far the system was from a demo before power, wiring, and timing got honest.

    Nothing working

    The starting point: presence and intent, no reliable actuation yet.

  2. Stage 2

    Motors working

    Servo open/close started behaving. Once motion was real, ultrasonic gating and WiFi paths had something worth integrating.

    Motors working

    Coordinated servo motion for the bloom open/close.

  3. Stage 3

    Wireless + sensing

    Blynk message path, Morse LED heart, ultrasonic proximity, and LCD status enter the same loop.

    No media for this milestone yet.

  4. Stage 4

    Demo hardening

    Retries, rail margin, and failure-mode rehearsal so the public demo did not brown out mid-open.

    No media for this milestone yet.

  5. Next

    Hardware revision

    Cleaner enclosure, harness, and smoother interpolation.

    No media for this milestone yet.

Results & Validation

What held up

What worked in the end, what I can show for it, and where it's still limited.

Public demo

Demo video + Devpost writeup

People could walk up, trigger the bloom with proximity, and send remote messages that blinked Morse on the LED heart.

Concept skit

Watch on YouTube

Short skit for the long-distance check-in idea: why a physical flower beats another chat ping when people are far apart.

Integrated stack

Live interaction clips and build documentation

Proximity sensing, servo open/close, Blynk messaging, and Morse LED timing were validated together, not as isolated peripherals.

Photos and clips

The runs and stills that match the results above.

Demo evidence

Proximity opens the flower; remote messages land on the same system.

Limitations

  • Enclosure and harness still warrant a cleaner manufacturing revision.
  • Motion interpolation and sentiment-driven mapping are future work.
  • Demo WiFi environments remain a reliability variable.

Reflection

Looking back

What surprised me, what I'd redo, and questions I'm still chewing on.

What surprised me

  • Power and timing failures masqueraded as 'bad servos' or 'bad WiFi.'
  • A cheap local feedback channel saved more demo time than another feature.

What I would redesign

  • Design the harness and peak-current budget before locking choreography.
  • Make reconnect behavior part of the state machine from day one.

Future improvements

  • Improved enclosure and wiring harness.
  • Smoother servo interpolation.
  • Richer mapping from external signals to motion patterns.

Questions that emerged

  • How should expressive robots budget electrical margin the way they budget degrees of freedom?
  • What feedback is worth putting on the robot versus in the client app?