@benvelzul

I made some test prints to see if the diameter of the beams were right and the first test was with 13 mm and they didnt fit for like 0.5 mm. and the 14 mm did fit. And then i was measuring and designing the rest of the holder so it could be added to my printer station and fit well.

Tooke the basic measurements and gave the first design

I worked on finishing the Gargoyle (bad cop) and its now looking pretty good, and i had to redo all of the body because it looked like it was drawn by a 3 year old. But now its looking amazing for being my first project on Adobe Illustrator.

I worked on getting the Mascot for the app and decided for the good cop, bad cop and i also worked on a UI more similar to Duolingo’s and Brilliant’s and i change the palette for the app so its easier to change and more equal all around the app

I worked on adding a mascot to the app, just like Duo in Duolingo; or Koi in Brilliant. So im between adding a gargoyle or a padlock. The paddlock is mostly finished (but im not convinced since its really boring), and the gargoyle is still in the process of learning the anatomy of one and how it looks better (but its looking better for a mascot than the padlock) but i still need to chose between them to be the mascot. Or use them both, like good cop, bad cop: padlock (good cop), and gargoyle (bad cop). So if anyone can help me choosing it would be amazing. I will keep working on them and then i will show the progress made.

I designed and printed the base of the robotic arm and it actually fits the servo really well and i am just impressed.

I worked on the project architecture, ui for all the pages and networking between them.

Got the main menu working (the quit and start button) and it now has nice text/logo thing, and a bg for the main menu (made with AI). And also worked on getting more charcters.

Made and organized the README.md, to be more professional and document all of the project better.

I worked on getting the yo-yo to show up in the player’s hand and launch properly, but it was pretty confusing and I ended up with a lot of errors and a non-working yo-yo. I also worked on the file structure; my files were scattered all over the place, so I asked an AI how to organize them using Boomerang Fu as a reference, and I did what I could with that. Finally, I started working on the main menu UI to make it look a bit more finished, even though it’s still far from it!

1. Building
   For this phase of the project, the primary goal was to construct a stable chassis for Gary (the robot’s name). I designed and fabricated a new, updated base intended to improve structural integrity. However, during the assembly phase, I ran into a clearance issue—the motors did not fit properly into the new mounts. As a result, I had to pivot and revert back to the previous design iteration.

Figure 1: The first version of the base (successful fit).

Figure 2: The second version of the base that unfortunately did not work due to motor clearance.

Because my immediate goal was to establish a quick Proof of Concept (PoC) and test the self-balancing algorithms, I decided not to let the chassis setback halt my momentum. To secure the electronics, I temporary mounted all the internal components, sensors, and the battery pack directly onto the older chassis using hot glue.

While not the final aesthetic design, this kept the center of gravity fixed and robust enough for testing. With the physical structure secured, Gary was officially ready to move on to the wiring stage.

1. Wiring
   The wiring phase presented several hardware limitations that required creative, temporary solutions, many of which became valuable learning experiences later in the project.

Power Supply & Connections

Because a dedicated 4xAA battery pack wasn’t available, I engineered a solution by combining two separate smaller battery packs to supply the necessary voltage. Furthermore, because I did not have access to a soldering iron, I had to secure the spliced power wires together using hot glue. While this worked initially to establish a connection, the lack of a proper mechanical bond introduced intermittent power issues down the line.

Microcontroller & Motor Protection

Before connecting any components, I had to research safe wiring configurations to ensure the high-voltage motor circuits wouldn’t back-feed and destroy the Raspberry Pi Pico. To safely bridge the Pico, the dual battery packs, and the motor outputs without soldering, I mapped the entire circuit out on a standard breadboard.

[Battery Packs] —> [Motor Driver] <—> [Raspberry Pi Pico]
|
[DC Motors]
The Breadboard & Sensor Bottleneck

While the breadboard was essential for a solderless prototype, it quickly became a primary source of instability. The most critical issue occurred with the ADXL345 accelerometer:

Because the header pins couldn’t be permanently soldered, I had to rely on friction and physical pressure to keep the jumper wires connected to the sensor.

This poor connection meant that as soon as the robot’s motors spun up, the physical vibrations shook the loose wires. This resulted in erratic sensor readings, momentary ‘’‘OSError’’’ crashes, and distorted tilt data, proving that a reliable mechanical connection is vital for self-balancing robotics.

1. Coding
   Sensor Integration & Debugging

The coding phase began by reading raw 6-byte chunks from the ADXL345 register 0x32. These data points were converted into integers and printed out as a tuple ‘’’(x, y, z)’’’ so they could be monitored and visualized inside the Thonny Plotter.

Implementing the PID Control Loop

A PID framework was written to determine how Gary reacts to falling:

K_p (Proportional): Pushes back against the present error based on how far the robot is currently tilting.

K_d (Derivative): Counteracts future error by assessing how fast the robot is falling, which dampens shaking.

K_i (Integral): Tracks past error over time to eliminate minor, steady leaning issues.

Figure 3: Assembled robot

Big update for the main character! The cactus finally got a glow-up with a cute head flower, eyes, a mouth, and proper spikes. Even better, basic movement is officially live. You can now move and dash, and the character smoothly turns toward your movement direction (just like the best game in history: Boomerang fu).

Made the chcarter move in godot, and it looks kinda amazing. But its is still really plain and i dont know a lot of stuff so its basically nothing.

I have started using Godot tp get the game into an actual game engine. Its my first time using it so its not going relly well, its really slow and stuff, but i am getting better.

I have also started using Blockbench for 3d modelling my characters and i have been trying to model this character (the cactus) for around 2 hours but Lapse kinda glitched and didnt count them (it just said server error). But i am getting better at blockbench

So now there is animations, and there is one character, the cactus. and i have also made yoyos and their spining animations. But i still havent decided if i should use smooth surfaces or pixelated, and if i should be using an actual game engine for it. I will do that later when i have a clear idea of what i am doing, but for now its looking pretty good. and i am still trying to figure out how to make the bounces work, right now they are really bad.

Added more Yoyo functions to make the yoyo movement better including:

• Bounces to walls
• Recalling (bring the yoyo back before max lenght)
  And added more central keys for the throwing/moving/aiming and added an aim preview before throwing

I added controls through an actual controler and now it is able to shoot yoyos and the collisions actually work too.
The controls are:
Left joystick - movement
A (nintendo) - Shoot/Aim
and if aiming left joystick works just like it

I am thinking now to add better maping and UI, or the actual animations.

I have designed the first version of the base for the robot (the thing holder for the motors)

A game inspired by Boomerang Fu, but instead of Boomerangs, Yoyos