Inspiration
We knew we wanted to do something hardware related for this hackathon, because that was an area that all three team members had next to no experience in it. When we got the theme of "link", we brainstormed a bunch of ideas for how to make a physical project that involved linking. The idea was to create a habit tracker app that linked your progress in maintaining good habits to the health of a physical plant.
What it does
Planty is a habit tracker that links your habits to the health of a physical plant. The plant has three levels of health, for healthy, borderline, and dead. As the health goes up and down, so do the flowers on the plant. At full health it looks normal and blooming, and mid health the flowers droop a bit, and at low health they droop completely and planty looks dead.
How we built it
Once we cam up with the idea, we drove all around the city collecting supplies from our homes and a few stores. We used an old raspberry pi, the cheapest cables and networking adapter that best buy had, a dollar store flower pot, and most importantly a brand new Hibiscus Lego set.
The three of us split up the tasks, each concentrating on what we were most familiar with.
Velibor worked on building the Lego set, then modifying it to make the flowers droop and be controllable with the stepper motor. He also worked on modifying the flower pot to hold all the components and look _ somewhat _ clean.
Khalaf worked on creating the front end, all the business logic, and linking to the backend with endpoints. He also worked on hosting for the backend and the front end to ensure everything ran stably.
Konstantin (Kostya) set up the Raspberry Pi to work as a server, created the backend, the backends connection to the arduino over a serial interface, and the arduino wiring.
Later in the night as we started wrapping up our tasks we switched over to help others. Once everyone was done, we put the whole thing together and went to sleep.
The end result is a robotic flower made out of lego, with a motor and light controlled by an arduino, which itself is controlled by a node.js backend running on a raspberry pi, which receives commands from an Angluar app on a phone via a REST API, all networked using tailscale.
Challenges we ran into
The pivot to hardware created more issues than we could have imagined. With software things are intangible, and usually doesn't break unless someone messes up somehow. Broken things can quickly be fixed with a _ ctrl + z _. With hardware, things have to exist in the messy, constraining, and complicated real world. We would constantly run into issues with the tension of strings, or with connections being weak, or with pins slipping out of the Arduino. The amount of issues we had was massive, and below we will catalogue some of our most memorable ones.
Raspberry Pi Voltage
The cable we were originally using for the raspberry pi was too cheap, and would undervolt the thing. This made for an hour of sitting in the library with the thing plugged into one of the BYOD monitors watching it slowly update between big "UNDERVOLT" warnings.
Raspberry Pi Networking
Maybe a nearly 10 year old Pi 3 was not the best choice for a project like this. No matter what we tried or who we asked, the Pi could never connect to any of the MRU networks. As a quick hack to solve this, we ended up setting it up with a mobile hotspot.
Lego Mounting
Fitting the Lego to the electronics was a huge part of the issues we faced. The strings needed to be tight, but not too tight as to not break the Lego. We were using 50 lb fishing line, so if something were to give it would be the motor or the Lego, both of which were not easy to replace. The spool is actually a Lego wheel that we cut up, glued, and drilled to create the spool.
Motor Overheating
As we found out at 3 am, our stepper motor was not meant to pull such a big load. It would start to overhead, get weak, and then stop working completely. We had to fix it by lowering the speed as much as possible (down to 20% of its original speed), and power the machine off when it wasn't in use. The next morning we made a DIY heatsink out of a crushed Redbull can to hopefully reduce heating to a manageable amount.
CORS
Security is always important, even in a hackathon. That's why we installed all the proper middleware and used best practices to.... Actually we just spoof an allow all signal from CORS which is good enough for this. Its not like the endpoints are exposed anyways.
Feature Creep
A big issue for was was dealing with the feature creep of wanting to add in more features. For example an idea that was thrown around using Ionic to get an actual app downloaded to the phone. Another idea early on was using some kind computer vision to verify task completion. At some point we also started wiring up 'mood LEDs' for inside the pot. These ideas were quickly scrapped when we realized how much work all this would take.
Accomplishments that we're proud of
Hardware:
- Successfully modifying a lego set to integrate with an Arduino.
- Fitting every component into the pot and making it look _ somewhat _ decent.
- Putting the components into the pot without any of the wires disconnecting (5th attempt).
Software:
- Building a full stack application in like 12 hours.
- Being able to give commands to hardware and making it move (powerful stuff).
- The ability to control everything from a phone with no errors.
What we learned
- Hardware is more difficult to implement than software.
- Point 1 makes hardware somewhat more satisfying than software.
- We can function on 4 hours of sleep.
- Knowing when to say "good enough" is critical.
- Stepper motors heat up under stress. That causes it to get weaker.
- We can drink 5 Redbulls without our hearts exploding.
What's next for MRU Hacks 2025 Project - Team KVK
We met about 2 years ago during the tech liftoff program and have been building together since. we've always wanted to give a hardware focused project a try, and this was our first attempt. Now that we've learned a TON about what goes into a hardware project like this, the constraints, as well as some common issues that we ran into (over heating, CORS, motors losing steps, wires with poor connections, etc...) we will definitely take another shot at a hardware based project, except next time we want to implement computer vision. one idea we talked about for an iteration based on this project was using computer vision and a ML model to have the user verify that they are actually doing their good habits.
Log in or sign up for Devpost to join the conversation.