Devlog 1 – Tank Robot Project

Today I started designing and building my simple tank robot. The goal is to create a small tracked robot controlled by an ESP32, with two TT gear motors powered through an L298N motor driver.

Progress

• Designed the base chassis in CAD.
• Designed the gears and treads.
• 3D printed the completed parts.
• Began assembling the robot.
• Wire the TT motors to the motor driver.
• Write the ESP32 code to control the motors.

Current Status

The base of the tank has been completed in CAD, along with the gears and treads. I have not finished designing the top section yet. Once the remaining CAD work is complete, I will print the top and continue assembling the robot.

Next Steps

• Finish designing the top of the chassis.
• 3D print the remaining parts.
• Write the ESP32 code to control the motors.
• Test the tank’s movement and make improvements as needed.

Overall, this was a good start to the project. The mechanical design is progressing well, and the next milestone is completing the CAD model so assembly and programming can begin.

Devlog #1 – SketchPrint: Making an Ender 3 drawing mod

I wanted to build something that combined software, hardware, and creativity instead of making another website. I came up with SketchPrint, a project that transforms an Ender 3 3D printer into a pen plotter capable of drawing images, text, and artwork on paper.

The project started with researching how pen plotters work and figuring out how I could attach markers to the printer. I designed and printed different pen holder ideas before deciding on a design that securely holds a marker while still allowing the printer to move freely. I also researched different methods for supporting multiple pen colors and explored ideas like a rotating pen carousel.

Once the hardware concept was working, I started building the software. I created a React application that lets users upload images and prepares them for drawing. One of the biggest challenges was converting normal images into clean line art that the printer could actually draw. I experimented with multiple tracing libraries and eventually integrated image tracing into the application. I also spent a lot of time adjusting line thickness, scaling, and positioning so drawings would fit correctly on the page.

Another major challenge was generating G-code. Since the printer was originally designed to print plastic instead of draw with a marker, I had to learn how plotting G-code works and adapt it for pen movements. I tested different movement speeds, pen heights, and drawing paths while making sure the marker stayed on the paper without dragging or damaging it.

Throughout development I encountered many technical issues, including:

• React import errors
• Canvas initialization bugs
• Image processing and tracing issues
• G-code positioning problems
• Marker calibration challenges
• Printer alignment and testing

Solving these problems required reading documentation, debugging code, and testing many different approaches before finding solutions that worked reliably.

What I’m Most Proud Of

I’m most proud that SketchPrint combines mechanical design, software development, and electronics into one project. Instead of only building a website, I created a complete system that takes an uploaded image, processes it into line art, generates G-code, and prepares it for an Ender 3 to recreate with a marker.

What People Should Know

• The project is designed for an Ender 3 configured as a pen plotter.
• Marker thickness and printer calibration affect drawing quality.
• Different paper sizes may require scaling adjustments.

Dev Log #6 – Local AI Integration with Ollama

Overview

Today I addeed a completely local AI model using Ollama. I researched local large language models and decided to integrate the Llama 3.2 3B model through Ollama.

What I Worked On

• Installed Ollama and downloaded the llama3.2:3b model.
• Fixed the issue where PowerShell could not recognize the ollama command by updating my system PATH.
• Learned that Ollama automatically starts its own server, so running ollama serve again caused a port conflict.
• Created a Node.js backend using Express and CORS.
• Connected the backend to Ollama’s local API.
• Updated the React frontend to send AI requests to my local backend instead of OpenRouter.
• Removed the dependency on paid AI APIs.

Challenges

One of the biggest challenges was getting the backend running correctly. I accidentally tried to run server.js before creating the file, which caused a MODULE_NOT_FOUND error. After creating the server and installing the required packages, I was able to start it successfully.

Another challenge was that the AI initially hallucinated events like holidays and birthdays that weren’t actually on my calendar. To fix this, I rewrote the prompt to clearly instruct the model to only use the calendar events provided and never invent additional information.

Improvements

I redesigned the AI briefing prompt so it now:

• Uses only events from the next 7 days.
• Creates a structured daily briefing.
• Highlights upcoming due dates, tests, meetings, and deadlines.
• Suggests what to focus on for the day.
• Ends with a short motivational message.
• Avoids generating fake events.

Result

The AI summary feature now runs entirely on my own computer with:

• No API keys
• No usage limits
• Faster response times
• Better privacy because calendar data never leaves my computer.

The morning briefing is much more useful and feels like a real student assistant instead of a generic chatbot.

Devlog #5 — Calendar event control complete

I focused on finishing the calendar management system for StudyOS. My goal was to make it possible to fully manage Google Calendar events without leaving the app.

Building the Event Modal

The first major feature I completed was the New Event Modal. Users can now enter:

• Event title
• Description
• Location
• Start date and time
• End date and time

I originally built the modal using a standard HTML form, but I ran into issues where React would disconnect the form before it could submit. Instead of continuing to fight that problem, I redesigned the modal to use React state and button click handlers. This made creating events much more reliable.

Editing and Deleting Events

After creating events worked, I added the ability to edit them.

Clicking an event now opens the same modal with all of the event information already filled in. Users can:

1. Update event information
2. Delete the event
3. Cancel without making changes

This required connecting the app to the Google Calendar Update and Delete API endpoints and refreshing the calendar after every change so the UI always stays up to date.

Multiple Calendar Support

One feature I really wanted was support for multiple calendars.

Instead of always saving events in the primary calendar, the app now retrieves every calendar connected to the user’s Google account. A dropdown menu allows users to choose exactly where a new event should be saved.

Bug Fixes

Along the way I fixed several issues:

• Fixed React form submission problems by replacing the form with state-based inputs.
• Fixed the event modal not updating correctly when switching between events.
• Fixed the calendar not refreshing after creating, editing, or deleting events.
• Fixed event selection in the Today, Week, and Month views.
• Fixed creating events in calendars other than the primary calendar.

Current Features

The calendar now supports:

• Today, Week, and Month views
• Searching events
• Creating new events
• Editing existing events
• Deleting events
• Selecting which Google Calendar an event belongs to
• Automatic refresh after every change

Next Steps

• Add recurring event support
• Add event color customization
• Add reminders and notifications
• Improve the calendar interface
• Add drag-and-drop scheduling

I’m really happy with how this update turned out because the calendar has gone from being a read-only viewer to a fully functional event manager.

Devlog #4 – Gmail, Google Classroom, and Calendar Improvements

What I Worked On

I focused on connecting more Google services to StudyOS and improving how calendar data is displayed.

Google Classroom

I created a new Classroom page that automatically loads my Google Classroom courses and displays assignments from each class.

Features Added

• Connected to the Google Classroom API.
• Loaded all enrolled courses.
• Retrieved coursework from every class.
• Combined assignments into one list.
• Sorted assignments by due date.
• Displayed the class name with each assignment.

Problems Solved

• Fixed OAuth authentication issues.
• Added the required Google Classroom scopes.
• Debugged 401 Unauthorized and 403 Permission Denied errors.
• Learned that teachers can restrict API access to coursework, causing some assignments to be unavailable.

Gmail

I continued improving Gmail integration.

Improvements

• Better loading of Gmail messages.
• More reliable Google authentication.
• Cleaner organization for displaying emails.

Google Calendar

The calendar received several major improvements.

Features Added

• Combined events from every calendar instead of only the primary calendar.
• Added search functionality.
• Added Today, Week, and Month views.
• Added Previous, Next, and Today navigation buttons.
• Added support for changing weeks and months without reloading.
• Sorted all events by date.

Bug Fixes

• Fixed missing events caused by incorrect API parameters.
• Fixed events not appearing from shared calendars.
• Fixed date filtering logic.
• Corrected React state issues with currentDate.
• Fixed navigation bugs while switching between calendar views.

Next Steps

• Create and edit calendar events directly from StudyOS.
• Add assignment completion tracking.
• Display Gmail labels and unread counts.
• Improve the calendar UI with drag-and-drop support.
• Connect Google Drive files to assignments.

Devlog #3 — Making the Calendar Page and Dashboard

This week, I worked on two of the biggest parts of StudyOS so far: the Calendar page and the Dashboard.

Calendar Page

I started turning the Calendar page into something more useful than a simple event list. I added different views for Today, Week, and Month, making it easier to see upcoming events in different ways.

I also improved how events are displayed by adding:

• Expandable event descriptions
• A cleaner event layout
• A structure that’s easier to build on with more features later

These changes make the calendar feel much closer to a real productivity app.

Dashboard

I also redesigned the Dashboard to work more like a student command center.

One of the biggest improvements was turning the upcoming events section into a scrollable card. This keeps the dashboard clean even when there are lots of events and prevents long lists from stretching the page.

This new layout also leaves room for future dashboard widgets, such as:

• AI daily briefing
• Assignment priority
• Recent activity

What’s Next?

Next, I plan to continue improving the Calendar page by adding:

• Creating events
• Editing events
• Deleting events

After that, I’ll begin building more dashboard widgets to make StudyOS feel like a true all-in-one student workspace.

Devlog #2 – Switching to React & Adding Google Authentication

Today I upgraded StudyOS from a basic HTML/CSS/JavaScript project into a React (Vite) application, and then added Google Sign-In authentication. This was a major step toward turning StudyOS into a real student productivity platform instead of just a static UI.
StudyOS is designed as a Student Command Center, where students can eventually manage Gmail, Google Calendar, Drive, Classroom, and assignments all in one place.

Part 1 – Switching to React

I migrated the project into React using Vite to make it more scalable and closer to how real production apps are built.

What I changed

• Converted project from HTML/CSS/JS → React (Vite)

• Broke UI into reusable components:

• Sidebar

• Header

• Pages (Dashboard, Gmail, Calendar, etc.)

• Implemented single-page navigation (no page reloads)

Why I switched

• React makes it much easier to:

• Manage multiple pages (like Gmail + Calendar + Drive)

• Handle user login state

Build dynamic dashboards

• Scale the project into a real app

Part 2 – Google Authentication

After setting up React, I integrated Google Sign-In so users can log into StudyOS using their Google account.

What I implemented

• Installed @react-oauth/google

• Added JWT decoding to extract user info

• Configured Google OAuth in React

• Created login flow using Google Identity Services

• Fixed OAuth issues including:

• Displayed user profile after login:

• Name

• Profile picture

• Restricted app access until user is signed in

What works now

• Sidebar navigation between pages

• Dashboard layout structure

• Google Sign-In authentication system

• User session state (logged in / logged out)

• Profile display in header after login

Challenges
The biggest issue was Google OAuth configuration. I initially encountered:

Error 400: origin_mismatch

This happened because the correct localhost URLs were not added in the Google Cloud Console.
Fix
Added the following to Authorized JavaScript origins:

• http://localhost:5173

• http://127.0.0.1:5173

After fixing this, Google Sign-In worked successfully.

Next steps

• Connect Google Calendar API (real events)

• Connect Gmail API (inbox preview)

• Connect Google Drive API (file access)

• Build Assignment Workspace system

• Add AI Daily Briefing (smart planning system)

• Implement “Stay signed in” persistence

• Improve UI with modern styling (glassmorphism + animations)

Devlog #1 - Building the Base of StudyOS

Time Spent: 45 minutes

Today I started building StudyOS, a student productivity app that combines Google Classroom, Gmail, Calendar, Drive, and other Google services into one place. My goal is to reduce the number of tabs students need to keep open and make staying organized much easier.

What I accomplished

• Created the project in VS Code.
• Built the basic dashboard layout.
• Added a sidebar for navigation.
• Created a top navigation bar with a search bar and a placeholder Google Sign-In button.
• Designed the first dashboard cards:
  • Today’s Summary
  • AI Briefing
  • Focus Session

Challenges

I spent some time deciding how I wanted the app to be organized. Instead of making another simple dashboard, I decided to build it like a Student Command Center where everything can eventually be managed from one place.

Next Steps

• Create a login page.
• Add Google Sign-In.
• Keep users signed in if they choose.
• Connect Google Calendar.
• Connect Gmail.
• Add the AI Daily Briefing.
• Begin building the Assignment Workspace.

I’m really happy with the progress so far. Even though it’s only the first version, I now have a solid foundation to build on. Next I’ll start adding real functionality instead of placeholder content.

I have assembled the 12 key piano and I have adjusted code in the site to fit it I also have fixed many bugs and I’ve also made it have 2 modes. It has a Wi-Fi mode where you can connect to the site, but you can also use the site with your mouse and play or you can open it on your phone and use touchscreen. The second mode is the standalone mode which you can connect to a speaker to play with the board without using a device and I have fully enclosed the piano so you can transport it

added audio thats plays when keys are pressed connected to the keys and that

finished printing and assembling the mini version of the piano

Designed 12 key and 5 key pianos planning on adding more for electronic storage next

created simple webpage to receive esp32 signals from switches and a starter keyboard display taht shows what keys been pressed

ESP32 code that hosts a web server and sends piano key states to a browser.