Dev Log #5 – Project Complete!

I wrapped up the final parts of the project by preparing everything for release.

I finished writing the GitHub README, making sure it included all of the information someone would need to understand, build, and test the robot. I also organized the project files so they would be easy to navigate and use.

To demonstrate the project, I created a video showing the self-balancing robot in action. The video explains what the robot does and gives people a look at the final build and balancing performance.

Finally, I uploaded all of the 3D-printable parts to Printables so anyone can download and print the components themselves. This makes it much easier for others to recreate the project without having to design the parts from scratch.

The project is officially complete!

Dev Log #4 – First Balance Tests

This week I made a lot of progress and got the robot fully assembled.

After going through the wiring again, I realized I didn’t actually need the buck converter. Instead, I powered the ESP32 through USB while the battery powers the motors. This made the wiring much simpler and reduced the number of components inside the robot.

With that change, I finished assembling the entire robot in about 4–5 hours. I made a few minor tweaks to the 3D-printed parts to improve the fit of some components, but overall the design worked as planned and everything came together successfully.

Once the hardware was complete, I started testing and tuning the PID controller. This was the first time the robot attempted to balance on its own. After adjusting the PID values through several rounds of testing, I got the robot to balance for around 10–20 seconds before it eventually tipped over. While it’s not stable enough yet, it’s a huge step forward because the control system is working and now only needs further tuning and refinement.

Dev Log #3 – Hardware Complete!

Today is a big milestone for the self-balancing robot. I officially finished designing all of the 3D models and printed the final parts.(NOT AT ALL) The robot’s main structure is now complete, and all of the electronics have a place to be mounted.

While assembling everything, I discovered a design mistake, I forgot to include mounting locations for the buck converter and the MPU-6050 IMU. Since the IMU is one of the most important sensors for a balancing robot, I couldn’t leave it out. I went back into CAD, redesigned the electronics holder, and reprinted the updated version with proper mounting points for both components.

On the software side, I spent more time learning about PID (Proportional-Integral-Derivative) control. After researching how each value affects the robot’s behavior, I now have a solid understanding of how PID works and how I’ll tune it once the robot is assembled. This should make the balancing process much easier when I begin testing.

I’m also starting work on a complete wiring diagram to make assembly cleaner and reduce wiring mistakes before powering everything on for the first time.

Dev Log #3 – Hardware Complete!

Today is a big milestone for the self-balancing robot. I officially finished designing all of the 3D models and printed the final parts.(NOT AT ALL) The robot’s main structure is now complete, and all of the electronics have a place to be mounted.

While assembling everything, I discovered a design mistake, I forgot to include mounting locations for the buck converter and the MPU-6050 IMU. Since the IMU is one of the most important sensors for a balancing robot, I couldn’t leave it out. I went back into CAD, redesigned the electronics holder, and reprinted the updated version with proper mounting points for both components.

On the software side, I spent more time learning about PID (Proportional-Integral-Derivative) control. After researching how each value affects the robot’s behavior, I now have a solid understanding of how PID works and how I’ll tune it once the robot is assembled. This should make the balancing process much easier when I begin testing.

I’m also starting work on a complete wiring diagram to make assembly cleaner and reduce wiring mistakes before powering everything on for the first time.

Dev Log #2 – Designing the Brain

Today I focused on designing and building the brain of my self-balancing robot.

I started by creating a custom 3D model to hold the robot’s electronics, including the controller and motor driver. Since space is limited on a balancing robot, I spent a lot of time adjusting dimensions and component placement to make sure everything would fit correctly. After several revisions, I 3D printed the parts and tested the fit of the electronics.

I also spent a significant amount of time researching PID (Proportional-Integral-Derivative) control. Since PID is what allows a self-balancing robot to stay upright, I wanted to understand how each part of the algorithm affects the robot’s behavior. I studied how PID controllers respond to movement, how tuning works, and how other balancing robots use PID to maintain stability.

Although there is still a lot of work ahead, this was an important step because it established the foundation for both the hardware and software of the project.

Dev Log #2 – Designing the Brain

Today I focused on designing and building the brain of my self-balancing robot.

I started by creating a custom 3D model to hold the robot’s electronics, including the controller and motor driver. Since space is limited on a balancing robot, I spent a lot of time adjusting dimensions and component placement to make sure everything would fit correctly. After several revisions, I 3D printed the parts and tested the fit of the electronics.

I also spent a significant amount of time researching PID (Proportional-Integral-Derivative) control. Since PID is what allows a self-balancing robot to stay upright, I wanted to understand how each part of the algorithm affects the robot’s behavior. I studied how PID controllers respond to movement, how tuning works, and how other balancing robots use PID to maintain stability.

Although there is still a lot of work ahead, this was an important step because it established the foundation for both the hardware and software of the project.

Dev Log #5 - I Got Rejected

After waiting about 3–4 days, I finally got a response on my project. Unfortunately, there was also a power outage during that time, so I lost a day and couldn’t check Stardance. When I finally logged in, I found out that my project had been denied.

The reason? My AI API key had been revoked.

At first, I was confused because everything had been working before. I checked whether I had accidentally uploaded an old version of the app, but everything was up to date. Then I checked the files on my PC and found the same issue there. For about 20 minutes, I went through the code trying to figure out what had broken.

Eventually, I decided to check my AI provider’s dashboard. That’s when I discovered that my API key had been revoked, which meant the website could no longer communicate with the AI model.

Once I found the problem, the fix was straightforward. I generated a new API key, updated the website configuration, and tested everything again. After a few tests, the AI features were working normally and the project was back online.

To prevent this from happening again, I only stored the new API key on the live website and removed it from GitHub. This keeps the key private and reduces the chance of it being exposed or automatically revoked.

Dev Log #5 - I Got Rejected

After waiting about 3–4 days, I finally got a response on my project. Unfortunately, there was also a power outage during that time, so I lost a day and couldn’t check Stardance. When I finally logged in, I found out that my project had been denied.

The reason? My AI API key had been revoked.

At first, I was confused because everything had been working before. I checked whether I had accidentally uploaded an old version of the app, but everything was up to date. Then I checked the files on my PC and found the same issue there. For about 20 minutes, I went through the code trying to figure out what had broken.

Eventually, I decided to check my AI provider’s dashboard. That’s when I discovered that my API key had been revoked, which meant the website could no longer communicate with the AI model.

Once I found the problem, the fix was straightforward. I generated a new API key, updated the website configuration, and tested everything again. After a few tests, the AI features were working normally and the project was back online.

To prevent this from happening again, I only stored the new API key on the live website and removed it from GitHub. This keeps the key private and reduces the chance of it being exposed or automatically revoked.

Dev Log #1 – Designing the Self-Leveling Robot

Today I began work on my PID self-leveling robot project. The first step was designing the robot in CAD and deciding what components would be included in the final build. I spent time planning the overall structure, thinking about where the motors, battery, controller, and sensors would be mounted to keep the robot balanced and compact.

After finalizing the concept, I created the 3D models for the main structural parts and prepared them for assembly. A major focus was making sure the design would be sturdy while keeping the center of gravity in a good position for balancing.

Once the modeling was complete, I started assembling the printed and purchased components to verify that everything fit together correctly. This stage helped identify areas that may need adjustments before moving on to electronics integration and PID tuning.

Next steps include completing the mechanical assembly, mounting the electronics, and beginning development of the balancing algorithm.

Dev Log #1 – Designing the Self-Leveling Robot

Today I began work on my PID self-leveling robot project. The first step was designing the robot in CAD and deciding what components would be included in the final build. I spent time planning the overall structure, thinking about where the motors, battery, controller, and sensors would be mounted to keep the robot balanced and compact.

After finalizing the concept, I created the 3D models for the main structural parts and prepared them for assembly. A major focus was making sure the design would be sturdy while keeping the center of gravity in a good position for balancing.

Once the modeling was complete, I started assembling the printed and purchased components to verify that everything fit together correctly. This stage helped identify areas that may need adjustments before moving on to electronics integration and PID tuning.

Next steps include completing the mechanical assembly, mounting the electronics, and beginning development of the balancing algorithm.

Dev Log #5 – Device Integration Complete & First Shipment

Today marked a major milestone for Smart Schedule AI. I completed the integration between the Smart Schedule web platform and the Smart Schedule Device, allowing events from a user’s account to be displayed directly on the device’s OLED screen.

One challenge was configuring Wi-Fi on the device. To solve this, I implemented a USB communication system that allows users to connect the Smart Schedule Device to a computer and securely send Wi-Fi credentials to the ESP32-C3. This provides a simple setup experience and ensures the device can connect to the internet and synchronize with the user’s calendar.

– Completed Tasks

Finished website-to-device integration

Connected Smart Schedule accounts with physical devices

Implemented USB communication for Wi-Fi setup

Improved device synchronization and event retrieval

Tested event updates between the website and hardware

Finalized device firmware for deployment

– Hardware Configuration

ESP32-C3

0.96” OLED Display

Rechargeable Battery

Charging Module

Power Switch

– Manufacturing & Shipping

After completing final testing, I assembled and packaged the first Smart Schedule Device. All hardware, firmware, and website components were verified and prepared for use.
With testing complete, the device was packaged and shipped, marking the first fully functional Smart Schedule AI system deployment.
Current Status
✅ Website Complete
✅ Device Complete
✅ Account Integration Working
✅ Wi-Fi Setup Implemented
✅ Event Synchronization Working
✅ First Device Shipped

–Next Steps

Improve onboarding experience

Add support for multiple devices per account

Expand AI scheduling capabilities

Continue testing with real-world usage

This milestone represents the first complete end-to-end Smart Schedule AI ecosystem, combining the web application, AI assistant, cloud synchronization, and dedicated hardware display into a single working product. 🚀

Dev Log #5 – Device Integration Complete & First Shipment

Today marked a major milestone for Smart Schedule AI. I completed the integration between the Smart Schedule web platform and the Smart Schedule Device, allowing events from a user’s account to be displayed directly on the device’s OLED screen.

One challenge was configuring Wi-Fi on the device. To solve this, I implemented a USB communication system that allows users to connect the Smart Schedule Device to a computer and securely send Wi-Fi credentials to the ESP32-C3. This provides a simple setup experience and ensures the device can connect to the internet and synchronize with the user’s calendar.

– Completed Tasks

Finished website-to-device integration

Connected Smart Schedule accounts with physical devices

Implemented USB communication for Wi-Fi setup

Improved device synchronization and event retrieval

Tested event updates between the website and hardware

Finalized device firmware for deployment

– Hardware Configuration

ESP32-C3

0.96” OLED Display

Rechargeable Battery

Charging Module

Power Switch

– Manufacturing & Shipping

After completing final testing, I assembled and packaged the first Smart Schedule Device. All hardware, firmware, and website components were verified and prepared for use.
With testing complete, the device was packaged and shipped, marking the first fully functional Smart Schedule AI system deployment.
Current Status
✅ Website Complete
✅ Device Complete
✅ Account Integration Working
✅ Wi-Fi Setup Implemented
✅ Event Synchronization Working
✅ First Device Shipped

–Next Steps

Improve onboarding experience

Add support for multiple devices per account

Expand AI scheduling capabilities

Continue testing with real-world usage

This milestone represents the first complete end-to-end Smart Schedule AI ecosystem, combining the web application, AI assistant, cloud synchronization, and dedicated hardware display into a single working product. 🚀

Dev Log #4: Building the Reminder Device
Today, I focused on designing, modeling, and programming the reminder device that connects to the AI calendar system. The device attaches to a user’s account and displays their upcoming events, allowing them to quickly see what they need to do next without opening the website.
One of the biggest challenges was getting the ESP32-C3 to communicate with Firebase correctly. Firebase relies heavily on JSON data, and I spent a lot of time figuring out how to properly format, send, and read the data coming from the database. Small mistakes in the JSON structure could prevent the device from receiving event information, making debugging especially frustrating.Although the device itself is fairly simple, getting it to reliably connect to Wi-Fi, communicate with Firebase, and display the correct upcoming event took a lot more testing than I originally expected.
By the end of this session, the device was successfully syncing with user accounts and displaying upcoming calendar events.

Dev Log #4: Building the Reminder Device
Today, I focused on designing, modeling, and programming the reminder device that connects to the AI calendar system. The device attaches to a user’s account and displays their upcoming events, allowing them to quickly see what they need to do next without opening the website.
One of the biggest challenges was getting the ESP32-C3 to communicate with Firebase correctly. Firebase relies heavily on JSON data, and I spent a lot of time figuring out how to properly format, send, and read the data coming from the database. Small mistakes in the JSON structure could prevent the device from receiving event information, making debugging especially frustrating.Although the device itself is fairly simple, getting it to reliably connect to Wi-Fi, communicate with Firebase, and display the correct upcoming event took a lot more testing than I originally expected.
By the end of this session, the device was successfully syncing with user accounts and displaying upcoming calendar events.

Dev Log #3: Building the Website

Disclaimer: The coding-time tracker for this project is inaccurate by approximately 5–6 hours due to starting this project before stardance.

This week, I focused on building the main website for the AI calendar system. The website now includes a calendar interface where users can view and manage events, an AI chat section that allows users to create events through natural conversation, and a device pairing page for connecting an ESP32-C3 reminder device.

The biggest challenge I ran into was getting the AI to properly use tool calls. Sometimes the AI clearly understood what the user wanted, but instead of calling the event-creation function, it would simply respond with text describing what it would do. This led to a lot of testing and experimentation with prompts, tool definitions, and API settings until the AI consistently triggered the correct functions.

By the end of this development session, the website was functional, the AI could create events through tool calls, and the device pairing system was successfully integrated into the interface.

Dev Log #3: Building the Website

Disclaimer: The coding-time tracker for this project is inaccurate by approximately 5–6 hours due to starting this project before stardance.

This week, I focused on building the main website for the AI calendar system. The website now includes a calendar interface where users can view and manage events, an AI chat section that allows users to create events through natural conversation, and a device pairing page for connecting an ESP32-C3 reminder device.

The biggest challenge I ran into was getting the AI to properly use tool calls. Sometimes the AI clearly understood what the user wanted, but instead of calling the event-creation function, it would simply respond with text describing what it would do. This led to a lot of testing and experimentation with prompts, tool definitions, and API settings until the AI consistently triggered the correct functions.

By the end of this development session, the website was functional, the AI could create events through tool calls, and the device pairing system was successfully integrated into the interface.

Dev Log #2: Fighting the API

I thought adding the Grok API would be one of the easier parts of the project. It turns out I was wrong.

Since I had never worked with the API before, a lot of my time was spent tracking down small syntax mistakes. The API was very specific about how requests needed to be formatted, and even tiny errors could cause everything to fail. For example, at one point I wrote:

payload = {
    "model": GROQ_MODEL,
    "messages": [{"role": "user", "content": message}]
    "temperature": 2,
    "max_tokens": 500,
}

I forgot the comma after “message}]” which caused an error and took me longer than I’d like to admit to find.

The frustrating part was that the code usually looked correct at first glance. I would spend time checking API keys, debugging functions, and rereading documentation, only to discover that the issue was a single missing character. Now I know to read the documentation more and also if you like this project like and follow me.

Dev Log #2: Fighting the API

I thought adding the Grok API would be one of the easier parts of the project. It turns out I was wrong.

Since I had never worked with the API before, a lot of my time was spent tracking down small syntax mistakes. The API was very specific about how requests needed to be formatted, and even tiny errors could cause everything to fail. For example, at one point I wrote:

payload = {
    "model": GROQ_MODEL,
    "messages": [{"role": "user", "content": message}]
    "temperature": 2,
    "max_tokens": 500,
}

I forgot the comma after “message}]” which caused an error and took me longer than I’d like to admit to find.

The frustrating part was that the code usually looked correct at first glance. I would spend time checking API keys, debugging functions, and rereading documentation, only to discover that the issue was a single missing character. Now I know to read the documentation more and also if you like this project like and follow me.

Dev Log 1

Discamer time is off by about 5 hours- joined Stardance midway through development.
The project is an AI-powered calendar assistant that allows users to create and manage events through natural conversation.
Users can speak to the AI, and their speech is transcribed into text before being sent to an AI model such as Grok or Llama.
The AI analyzes the request and generates tool calls to create, edit, or manage calendar events automatically. After the tool call is executed, the calendar is updated and the user receives confirmation. I also worked on integrating a companion reminder device that provides physical notifications for upcoming events.
One of the most interesting parts of the project was building and understanding the AI pipeline that connects speech recognition, AI processing, tool calling, and calendar management into a seamless user experience.