IT WORKSSSSS

ok sit tight brodini cuz i got a lot of stuff to tell you

I burned another PCB!

yea, u sure heard that right.

I found out what the issue with the PCB was: the motor driver was in the wrong orientation, which connected the +12V rail itself to a gpio pin, frying the rp2040 entirely. Instead of using my hot air station to de-solder and rotate the driver, I decided to just make another board because I was lazy. The second board ended up not working either, and when I pressed down on one of the legs of the buck converter with a multimeter, the IC caught on fire and started smoking. I ended up needing to use a hot air station to replace the buck converter on that board, so I used it to heat up and fix the driver on my previous board while I was at it.

I now have two working boards

but does it really work?

yup.

how do you know?

because I’m built like that

I dont think so

stfu

ANYWAY…FIRMWARE TIMEEEE

The best way to verify the board works is to test out its main feature: controlling Colosseus’ motors (goddamn I’ve spent so much time on the pcb that I’m still not comfortable with the actual name of the robot).

I wrote some code in C to blink the KineticBoard’s onboard led, built and flashed the .uf2 to the pico, connected it to the board, andd…
…
…
…
IT DIDN’T CATCH ON FIRE! (that’s a first)

it actually blinked the LED like it was supposed to. wow.

With that boost in confidence, I was more inclined to write code for the robot itself. I started scaffolding a library for the robot, which I’m calling KineticLib. So far, I’ve written code to simplify PWM channels because the TB6612FNG motor driver relies on two of them. I tested my library by adding a demo project that makes the robot incrementally increase in speed, and then come back in the same manner. It worked too!

things I HAVEN’T tested yet

• connecting the Pico to USB while it’s attached to the hat
• using the usb-c rececptacle to power other stuff (like a regular rpi)
• observing the effect of forcing the motors to spin while they are connected to the KineticBoard (I tried this briefly and I smelled some type of smoke, but I could very well just be paranoid)

but yea all in all 11/10 experience i would highly recommend trying to make one of these on your own. if you happen to be brave enough to test these before I do, lmk what happens on slack (if you survive).

THE BOARD IS ON FIRE

Not really, but it kinda is.

After soldering all of the components on with an iron and hot plate, I connected the Pi Pico to the HAT via the female header sockets. I wrote a simple blinky script and verified that it worked when powered by my regular laptop. However, when I powered the KineticBoard HAT with the Pico, the RP2040 chip started smoking and I was able to capture a brief orange glow on camera.

What now??

I’ll have to carefully look at what could have gone wrong. I tested the voltage readings from the multimeter and found that VSYS reads +5.1V when switched on, which makes sense because the Pico can accept that much. I did notice a constant 0.5V on the +3V3 pin for whatever reason (before attaching the pico). I’ll isolate the Pico on a breadboard and attach jumper wires only where needed, and gradually close in on the part that caused the failure.

On a side note, I figured out why one of the LEDs isn’t working. It happens to not be connected to GND; however, everything else seems to be connected just fine.

Custom Enclosure for the PCB

After the board had travelled across the Pacific Ocean and the United States, it finally reached its destination at the core of Colosseus.

UPDATE: THE PCB AND THE LCSC PARTS HAVE ARRIVED!!!!

Whadidyado?

I started creating a case for the KineticBoard. So far, I copied the layout of the board from KiCAD and added cutouts for parts that were meant to have user interaction. I tested out three prototypes before settling on one that actually fit (a lot of issues were solved by adding extra clearance and gaps).

Potential Issues

I’m 70% certain that the case won’t fit the bottom floor of the chassis, but that’s a problem for later. For now, I’m just designing the most badass case I can.

Sent out the order!

After finalizing the last parts of the extension board, I used my hardware grant to send the PCB over to JLC for fabrication. I separately purchased parts from LCSC.

Finished the PCB

The final coat of copper pavement was carefully laid out as the green city was unified at last.

Changes

I routed the motor driver’s pins to the two 6-pin adapters on the bottom right of the board. I connected the last pads, and added some finishing touches such as screw holes for a 3D-printed enclosure and some custom silkscreen cuz why not. I also filleted the edges as I read that it was a good practice online.

What’s Next?

All of the GND pads are isolated, so I need to make a copper fill zone or something to link all of them. I also plan on adding a little silkscreen on the back, and then we should be good to go!

Almost Done with the Layout

With the components oriented in their city-like pattern, all that was left to do was to pave the final roads through the green adhesive base, connecting the motor driver to the 6-pin adapters.

Changes?

I decided to drop the 12V to 3.3V buck because the Pico has one internally, and I could just keep my 5V buck and feed its output into VSYS and extract 3.3V from the Pico’s +3V3 pin. I also ended up changing the orientation of some adapters because I couldn’t comprehend the fact that the PCB exists in 3 dimensions? Lastly, I greedily extended the bottom of the PCB so that both partitions could access one large +12V trace (the GPIO sockets were interfering).

What next?

All I have to do is wire up the connections to the motor driver and adapters, and we should be good to manufacture ts.

Finished KineticBoard HAT Schematic

I spent a few hours finishing the schematic for the KineticBoard HAT, an extension board that allows the Pi Pico to control motors.

Additions

Rather than using a standard Li-Ion to power the Pico and a really small power bank to power the Pi, I decided to just use one: the Li-Ion. For this to happen, the PCB would need to convert 12V to 5V and expose this voltage through a USB-C connector. I decided to copy & paste my old buck converter schematic, but I had to pick different resistance values such that this formula V = 0.925 * (1 + R1/R2) yielded ~5.1V. This seems easy, but I wanted to use some resistors that I already had. I decided to make a C program that picked the most optimal values for this voltage divider. The program works by following a 2 pointer algorithm which adjusts the numerator and the denominator by shuffling through a sorted list of the resistance values, and finding the ones that are closest to the target voltage. I also expanded on my old buck converter by making the +3V3 net controlled by a switch, just so that no weird stuff happens if I connect both the PC and battery to the board at the same time. Lastly, I added the 6-pin JST connectors, the motor driver, and a few status LEDs. I put everything in the PCB editor in the end, and I’m honestly terrified of routing this thing, but that’s a problem for later lol.

Another PCB?????

I’m creating a second motor driver board, but this time instead of being a standalone devboard, it is only a hat.

Schematic Stuff

I added symbols for header sockets, the barrel jacks, a buck converter, and the usual dozens of resistors and caps. The pinout for the buck converter was so annoying and something about putting non-connecting wires on top of each other pissed me off a lot. It’s an eyesore, and I can already tell that I have to use a billion vias to get everything working once I’ll hit the layout stage.

So I Almost Burned My Finger

I was trying to get the encoders to work, but in the process of reading data through USB serial, I got a mild shock

How Did This Happen?

To configure hall effect encoders, you need to give each wheel a good spin to determine how many “pulses” are detected by the Pico. The detection part is quite simple: whenever the wheel turns a certain amount, motor encoders A and B change state. This can be detected through an interrupt and then printed out (in the main loop, not the callback). However, in the process of printing it out, I touched the USB-C receptacle and felt it get extremely hot, and later realized that something got shorted somewhere.

Any Guesses Where?

Looking back at the situation, I had connected the battery and USB power from my laptop to the board at the same time, so something might have gone wrong there. Another thing that was going wrong was that the receptacle itself was coming off, so it could be that one of the pads, say +5V for instance, came in contact with like GND or smth, inducing shock if someone were to touch it.

Here’s an image from the timelapse right before I plugged the board into my laptop and fried it:

Soldered the GPIO pins

Yea idk why I didn’t do this earlier but I needed the GPIO pins to read data from the motor encoders.

Prototyping & Schematics

I started working on a prototype of the watch on a breadboard, and began designing the PCB for the watch in KiCAD.

Watch Schematic

I decided to use RP-series MCUs for the watch, so I began developing the schematic for the watch’s PCB with a 3.3V VCC in mind. So far, I’ve attached a USB-C receptacle with nets for data and power. I also added support for 1S LiPo batteries (1S means single-cell in series, which has an average voltage of 3.7V). The 5V power line from the USB and the positive rail from the battery go through a P-channel enhancement-mode MOSFET. The purpose of the MOSFET is to ensure that current doesn’t flow into the battery when the USB is plugged in (at least, not in this part of the PCB/schematic), and that only one power line is responsible for powering the board at a time. Naturally, a buck converter is on the other end to step the voltage down to a nice and friendly 3.3V for the MCU. I also added a safe charging circuit for the LiPo at the end of my session.

Breadboarding a Prototype

What better way to have an off-grid watch than to use LoRa, a technology that can transmit short segments of data (like text messages or maybe really low-res images) over a kilometer away! I used two regular Pi Picos and connected a Wio SX1262 module to each via SPI. I then created a Pico C project and added RadioLib in CMake. The issue with RadioLib is that it’s targeted for Arduino, using functions like digitalWrite() and all that. To ensure this works in the Pico C SDK, I had to add a hardware abstraction layer, also known as a HAL. Basically, a HAL just translates functions from a different platform into the vernacular (Pico C, in this case), like gpio_put(). I created two executables: one for sending data and another for receiving it. The issue is that only every third send makes it across. This is likely due to some internal blocking mechanisms in RadioLib’s methods, but it can be fixed if I find a way to use interrupts. The issue can be explored in depth here.

First Drive

I checked the devboard for any last errors and connected it to the motors on the robot!

Final checks

I verified that the KineticBoard Leaf works when it’s powered by USB and by the 5000mAh Li-Ion battery. I did this by writing a simple program that toggles a GPIO pin, and used a multimeter to read the oscillating voltages. It worked!!

Test Drive!

I already had firmware from the design stage, but it was written for a different motor driver so I decided to start from scratch. I created a basic motor drive “class” (structs/functions to go with the struct) in C and set up my CMake project in a way that I could add a demos folder later. Now that I had custom firmware for the TB6612FNG, I wired up each screw terminal pair to the M1 and M2 pins on each motor, and flipped the switch to see it drive perfectly!

It was really relieving to see everything work on first try, and I gained a huge confidence boost in my embedded programming skills.

Future Enhancements

The motors came with 6-pin connectors, and I should have included appropriate receivers for these connectors on the KineticBoard Leaf rather than just generic screw terminals. Currently, I have to connect the 6-pin connector to 6 jumper wires, which is quite the eyesore.

Lab Visit + THE DEVBOARD WORKS NOW WOHOOO

After inhaling a mole of lead-based solder fumes, I finally got the devboard to work!!! It’s my first ever PCB so I’m really stoked!!

I visited my friend’s lab at the university where he works and we were able to debug and fix the devboard in a few hours. Unfortunately, I remembered that I had to record the whole thing in lapse in the last 20 minutes, but I guess that’s just karma for taking 9 hours ( ) to hand solder/debug a PCB in my last devlog (yes ik i suck).

Issues

My previous attempt at soldering failed because I set the temperature of my hot air gun too low, and I overestimated surface tension’s effect on my hot plate. I used a high-res microscope at the lab and saw that most of the QFN components were only partially soldered. I could quite literally see a tiny gap between the two pads. Another thing I saw was some obvious bridging, which I quickly fixed with a soldering iron.

One of my biggest takeaways from the lab was that THE TYPE OF SOLDER FLUX MATTERS!!! I previously used some generic $14 flux from Amazon, but it was so bad that even some of the most powerful ultrasonic flux cleaners couldn’t get it off easily. It was also so thick that even the infrared lamp couldn’t get the RP2040 to stick down. My friend used (and recommended) water-soluble flux, which makes it easy to clean off without messy isopropyl alcohol.

I ended up salvaging the parts from my old PCB to build a new one from scratch. I learned how to solder QFP packages, 0603s, and even 0402s with an iron. In the end, a soldering iron is THE BEST way to guarantee that your components are soldered down, especially when verified with a microscope. I also learned how to solder using an infrared lamp and hot air (properly, this time).

Results???

Right as I finished soldering the last component, I connected it to my computer and held down bootselect….and IT WAS DETECTED AS A MASS STORAGE DEVICE!!! I was so excited at this time that I finally rekindled my motivation to keep building more of these PCBs (I was pretty close to giving up on PCB-related projects ngl). Anyway, right before leaving, I put it in the ultrasonic washer they have for PCBs (which is just a tiny container with water and ultrasonic waves being fired it at from all directions to take the flux off. I’m currently waiting until tomorrow for it to air dry, and then I’ll incorporate it in the robot!

Concept and Initial Design

I brainstormed a mechanism to speed up the beyblade and designed one plate of the beyblade’s chassis in Fusion.

Background

In the Beyblade Burst anime series, Fafnir is a left-spinning top that is widely known for its ability to “steal spin” from its right-spinning opponents. It appears to magically increase its own angular speed with every hit and then outlast its opponent. However, in reality, this ends in more draws rather than wins. Additionally, the physical beyblade doesn’t gain a “sudden boost” of spin as depicted in the anime.

How Does it Work?

Think of two gears isolated from each other. One gear is spinning clockwise (CW) and the other isn’t spinning at all. If the two gears were put near each other to the point where the teeth interlock, then you would be able to see that the other previously stationary gear begins to spin in the other direction (counterclockwise, or CCW). In the Beyblade world, Fafnir is launched CCW with very little spin power, so it gains more spin whenever it is hit by a CW attack. The main principle here is that the two Beyblades are trying to reach the same angular speed whenever they are in contact, so if the CCW is slower than the CW one, the CW beyblade will transfer some of its spin over to the other beyblade to help reach a point of equilibrium. Unfortunately, what happens often in real life is that the two beyblades hit each other until they are spinning at the same speed, and then they both run out of spin at the same time.

Conservation of Angular Momentum

Angular momentum is defined as L = I * ω, where I represents the moment of inertia and ω represents the angular velocity. The conservation of angular momentum states that this quantity remains constant unless acted on by an external torque (ignore friction for now). This means that if the moment of inertia were to decrease, then the angular speed would have to increase in order to maintain a constant angular momentum. But how do we reduce the moment of inertia? Well, I won’t get too deep in the details, but an easy way to do so is to move the mass distribution closer to the beyblade’s center of gravity.

The Mechanism

I’ll keep four masses that are attached to neodymium magnets near the edge of the beyblade, and I’ll have a rotating wall with four pockets. The magnets on the edge will have the same polarity, and there will be another magnet (with opposite polarity) at the center of the beyblade’s energy layer that pulls the other ones in. Usually, the wall will prevent this attraction. However, if the wall is tilted such that the pockets are exposed, then the outer weights will instantly get pulled towards the center of the beyblade; hence, the moment of inertia of this system is lowered, and it will speed up to conserve angular momentum.

Auth and Profiles

I added a proper authentication mechanism and the ability for users to view each others profiles, as well as edit their own!

Authentication

Users can create and log into their accounts. An OTP is sent to the user’s email during creation, and expires in 10 minutes. A password reset mechanism also exists and also uses OTPs.

Profiles

I added a profiles page that allows users to see each others profiles! For now, the profiles display the user’s name, role, event track, bio, avatar, and awards! A separate award_medal.php exists but it is only accessible to admins to give awards.

Setup

I set up my Hack Club Nest VM by installing MariaDB to hold relational data; Cloudflared to tunnel traffic from my domain to the server; and Nginx to host the web server itself.

Architecture

For whatever reason, I have an affinity towards older software, so I decided to use a PHP backend for this website. Usually, PHP is paired with an Apache web server, but I decided to use Nginx instead because it is non-blocking and even-driven, so it doesn’t use up as much memory (mainly cuz I only have 2 GB of RAM on the VM ).

I guess that makes this an LNMP stack? Idk.

Mail!

So I’m planning on having a password reset mechanism and automated email notifications, so I needed something more secure than PHP’s native mail() function. I chose to use PHPMailer with Brevo as the SMTP service provider because they offer a very generous free tier.

Stuff I Gotta Work On

• The emails are going to my junk folder?
• The emails are also getting wrapped in a really odd way

Broken Devboard

So this was my first time ever soldering a PCB, and I didn’t go easy on myself especially considering I used 0402 footprints on a 4-layer double-sided layout. I had hoped that it would work after soldering all the parts but unfortunately, it did not.

Areas of Error

The front portion was soldered using a hot plate, and the back was soldered with a hot air gun. This was my first time using a hot air gun, so I had my dad (a former electronics hobbyist) help me out a little. Turns out we both couldn’t fix it. One potential error is that the back side wasn’t properly soldered because we ran the air gun at 220 degrees fahrenheit, wihch could have meant that the core of the gun was that hot but outside it could be 150 or something. Another thing that could have gone wrong is the ICs could have been overheated and cooked, or a tiny bridge on the RP2040 could have shorted the whole thing.

Next Steps and Debug

I asked a friend (a guy who has a PhD in computer/rf engineering) to help me debug the board, and he said he’ll be more than happy to in a few weeks. In the meantime, I guess I’ll just make a bunch of more projects!

SMD Soldering Attempt

The parts from LCSC and JLCPCB had arrived! This meant that I could finally build the final part of the robot: the KineticBoard controller (yk, the devboard with a motor driver on it?). It’s gonna be difficult because I have to solder both sides of the PCB, but so far I only soldered the first side. Some parts were misaligned but it looks mostly ok.

Rebuilt the Robot

The new standoffs had finished 3D printing, so I could finally replace the faulty old ones. Since I had to tear the robot down anyway, I decided to fix the motor slant problem as well. The solution to the motor slant problem was relatively simple: some foam padding to lift the motors up to the horizontal. This solution not only worked perfectly, but also gave the robot a little bit of shock absorbance. After that, all I had to do was build the robot with the new standoffs, which was actually quite a chore because it’s hard to use a screwdriver at an angle.

Standoff Redesign

The old standoffs had an issue because they weren’t properly threaded, which meant that there really wasn’t much aside from minimal friction that was holding the screws in place.

The Fix

I redesigned the standoffs by making them wider, thoroughly hollow, and exposed on one half. This allowed me to slide nuts and screws inside the standoffs, which will guarantee a perfect lock. Another issue that this redesign fixed was the blocked hole problem. Essentially, when I put a screw in a hole on the middle chassis, I couldn’t then use that same hole for another standoff to connect the other side. This solves that issue since a single screw on the middle chassis can now go through two standoffs at once, allowing me to connect both sides.