@dillonyegudkin

Correction to the original wording: the owner chose the features and layout and reviewed the design; ChatGPT/Codex generated and revised the schematic and PCB, routed the board, ran the CAD checks, and prepared the files. The original first-person wording incorrectly implied that the owner personally performed those steps. This correction was also entered by Codex.

The current design has six MX switches in a 3-by-2 grid, a clickable EC11 encoder at the upper left, a 0.91-inch OLED immediately to its right, and a XIAO RP2040 with USB-C accessible at the top edge. The board is 86.5 by 88.5 mm with two copper layers. The public repository includes KiCad source, connection-check reports, a pin map, BOM and Gerbers.

This remains a design prototype: it has not been assembled or electrically tested, and the supplied parts still need footprint and case-fit confirmation. The displayed tracked time is not a claim of 40 hours of recorded human work; its eligibility, including any AI execution time, needs organizer review.

BuildRank started with one dirt-bike argument: everyone says their bike is the cleanest, but there was nowhere for the community to actually decide.I already had the core Django product working—accounts, photo uploads, 1–10 ratings, state/category/global rankings, and 24-hour head-to-head battles. For this mission I built BuildRank Pulse as a real new-tab front door instead of a disconnected mockup. It reads the existing database to show the current #1 build, fresh posts, active battles, and community totals, plus local time, a saved theme, and keyboard shortcuts.The hardest product decision was making the dashboard summarize real community behavior instead of filling it with decorative widgets. I moved the original feed to /feed/ so none of the community flow was lost, added automated tests for the live data and routes, and published a privacy-safe repo with no production database or rider uploads.The result is a homepage that feels alive because it changes with the riders using it—not because it fakes activity.

From a failed 2D pile to a 3D simulator that can reject its own results

I started this because a friend had spent a full week at UCF helping run an angle-of-repose experiment. The physical work was much bigger than just pouring sand: the team needed a built apparatus, fabricated parts, repeated cleaning and resetting between trials, travel, and separate people handling the experiment and slope-analysis software. I wanted to know whether a digital twin could make that kind of research faster and easier to reproduce.

My first version was a 2D particle solver. It could draw a convincing pile, but the pre-validation checks showed that the biggest remaining problem was the physics model itself—not the line used to measure the slope. Fixing the graph would only have hidden the real problem, so I restarted the core in true 3D with PyBullet.

My notebook says the first material went from more than 12% error to under 5%, which felt huge. The other materials were not magically fixed: several quartz sizes were still too steep, and the glass-bead conditions revealed bad symmetry and input problems. I corrected the physical sizes, contact behavior, and measurement rules rather than entering the UCF answers and tuning until they matched.

Then the most important moment happened. I wrote “A breakthrough has occurred” across the page because the pre-validator saw that a run was likely to create bad data and stopped the simulation before it could report an angle. That is now the main idea of the project: the simulator should not just output a number—it should explain whether that number passed its own reliability checks.

The next bugs were more subtle. A few particles could roll away from the main pile and pull the measured slope downward, so I changed the analysis to isolate the supported pile body and compare two perpendicular views. The automatic experiment also trapped the user after it started, saved trials without a clear replay path, and showed technical cache/lock messages that made sense to the code but not to a new user.

I redesigned the interface around one action: click Run Current Trial, let the complete trial measure and save itself, review the result or replay, then move to the next trial. Replays now have familiar previous, play, pause, restart, next, and timeline controls, plus one shared speed setting. The diagnostic status is written in normal language and the controls are centered instead of scattered around the screen.

The final experiment contains 18 trials across unsieved quartz, three sieved quartz size ranges, and one- and two-cup glass-bead conditions. It stores the seeds, settings, raw XYZ positions, browser replays, CSV data, validation report, graphs, and final research report. Compared with the selected published benchmarks, the simulation was closer in four of six conditions and the UCF measurements were closer in two. The two-cup glass-bead case still has a large error, and I kept it because removing the worst result would defeat the purpose of the project.

I spent about 15 hours on the complete process. Hackatime captures about 4 hours from the project-specific coding records; the rest includes research, long-running simulations, reviewing results, handwritten planning, and work outside the tracked editor.

What I learned is that a believable visualization is not the same thing as a defensible experiment. The most valuable feature is not the 3D pile—it is the point where the program is willing to say, “This result is not ready to trust.”