Differential Shuffler-Swerve Drive

A second-generation experimental swerve drive, designed as a combination of a differential swerve drive and shuffler drive. A proposal for a new robot for NHRL combat robotics, started in 12th grade (17 years old).

I wanted to develop a new swerve drive system for a combat robot concept. With my experience from building a differential swerve drive in 2022 (10th grade), I created a new version with updated mechanics. While keeping the omni-directional movement and power of a differential swerve drive, I integrate a walking shuffler mechanism to replace the wheel.

The benefit is two-fold: allowing the robot to take advantage of the "Non-Traditional (wheel-less) Locomotion" weight bonus offered by NHRL, as well as being able to fit in a much narrower profile compared to a wheel.

Both direction and speed of each swerve module is controlled via the turning of two large ring gears. When the two gears rotate in opposite directions, the module moves forwards. When in the same direction, the entire module changes direction with it. Shown below is a demonstration of turning and moving forward using an unassembled drive.

The shuffler system uses a series of mechanical cams mounted on a center axle to produce a relatively good approximation of walking. The version mounted inside the swerve drive was designed to fit a tall and narrow profile, shown below is an early proof-of-concept prototype.

This combination of ideas is an experimental design that has not been thoroughly explored before, and most design elements were developed de novo. The completed design is similar in structure to my first differential-swerve drive, with two large ring gears driving a central axle with the wheel or shuffler attached. However, it is under half of the width while only being marginally taller. Much like the first version, it is designed to primarily be manufactured through in-house capabilities such as 3D-printing, plasma-cutting, and lathe-turning.

This version is also much more complete in terms of electronics. Each module uses two unsensored brushless outrunners for power, and a magnetic encoder for sensing the current angle of the drive unit. To support the encoder, an additional 1:1 set of gears has been fitted to the very top of the module. Although appearing bulky, this has the benefit of allowing the drive unit angle to be directly measured, negating the need for any complex reductions and calculations.

During development, several problems arose which had to be adressed.

One issue was ease of assembly. The awkward shape of the legs combined with the many rings needed to be fit onto them, it was incredibly difficult to fit together. Rethinking the design of the casing, I split the part into two, bolting them together with 6 screws on each side.

Another major issue was related to the motors. The drive motors did not have enough torque, thus needing to be geared down. I switched the originally planned large inrunner motors to much smaller outrunners and designed a custom, 3D-printed, 5:1 planetary gearbox, increasing the torque driving the ring gears. The first few iterations of the gearbox had a tendency to melt after running for too long. With a couple redesigns and custom lathed brass pieces, this issue was resolved.

The software front for this project was something completely new to me. My previous differential swerve drive never reached this stage, and I needed to develop a new control system. Using an Arduino Mega for its number of ports, the final program sets the base speed of the two motors to the throttle value, then proportionally adjusts individual motor throttle to rotate towards a target angle based on the current encoder measurements.

The product of both hardware and software is a fully-controllable drive module ready to be mounted onto a robot.

Onshape

Combat Robot

A 12 lb combat robot named YOB TROHS (SHORT BOY spelled backwards). Designed to compete in the National Havoc Robot League (NHRL), built from scratch over 5 months starting in 11th grade (17 years old)

As a long-time BattleBots fan, I have always wanted to build a combat robot. I spearheaded this project and assembled a team with friends from my school's Robotics team to design, build, and then compete with a full 12 lb robot from scratch. The goal is not only to gain experience with hands-on robotics but also to initiate and establish a new activity for people into robotics in the community.

The majority of the time was spent on designing the bot. Onshape was the design software of choice for its collaborative features, and the final design is viewable here.

I organized the design of the robot, it was one of the largest and most detailed assemblies I had ever created, with every screw and bolt represented. At major versions, I reached out to members of the NHRL community to review our design and communicated what needed to change to the rest of the team. The robot was given the name "YOB TROHS" after someone compared the design as a short version of YOB GNOL.

The components were mostly manufactured in-house. I worked on printing everything we needed, and I learned how to print with exotic filaments like carbon-fiber nylon and TPU for their special properties. To work with metals, My team and I used the school machine shop. Complex parts were made on the lathe and mill, and I learned how to operate the plasma cutter to make the armor.

I also worked on the electronics and code. I soldered all the connectors and joints inside the robot. To translate the controller inputs into our motors, I used an Arduino nano microcontroller and wrote some basic code.

As the target event approached, our combat robot YOB TROHS was put together for the first time and was finally tested.

On the day before the competition, I traveled to the event to finalize the robot before the mandatory safety inspection. YOB TROHS passed safety at a weight of 11.98 lbs, barely making the 12 lb cut-off.

Many last-minute surprises and fixes awaited us. During one of our tests, the weapon hit its own pulley and exploded, so we were forced to go into our first fight without a weapon. Our first match was Whomper, a terrifying horizontal spinner. The results were not good, Whomper had bent one of the frame sides, bending the gearbox axle underneath.

The builder community is a very friendly environment, and we got tips from many of the other competitors after the match. To repair our robot, I took the bent parts to the competitor machine shop and bent most of the components back into a usable shape with a press. The second match was against Darkstar. The newly-repaired YOB TROHS went the whole 3 minutes and managed to engage Darkstar properly.

Onshape

Homemade Laptop

A Raspberry Pi powered Laptop. Designed with a fully 3D printable case, modular electronics, and custom functionality written in C; built in 11th grade (16 years old)

I wanted to create a computer device that is truly customized to my needs. It needed to be small, lightweight, fit inside my bag, plus a large screen area to work on. With my interest in electronics and the lack of variety in pre-built laptops, I made my own, a self-built laptop.

Self-built laptops are fairly rare. This is mostly because compact computer parts are rarely sold, especially not in a form meant for DIY hobbyists. Thus, as a base to work on, the Raspberry Pi stood out as the best option available, being small, efficient, and reasonably powerful.

I composed my laptop with two modules. One is the compute module including a Raspberry Pi 4 powered by a 40000mAh battery and a breadboard for electronics. The other is the interface module including two 10-inch touchscreens and an optional remote keyboard.

I designed and 3D printed the housing framework to integrate both modules in a compact fashion. The design process was significantly more rigorous than it appears. Space efficiency was key. Every part had to fit perfectly using minimum space. The shell of the display module was a legitimate challenge to make and assemble. The margin of error is extremely small. The sensitive touchscreens needed to be delicately pressed and secured into the shell. The wiring for both monitors also needed to be run through an internal channel and carefully linked up.

On the software front, I chose Ubuntu Linux, as it is fully capable of browsing the internet and supporting most development tools that a daily driver would need.

With my unique hardware configuration, it took significant work to get Ubuntu fully functional. One of these problems was mapping the touchscreen input onto the correct screen and I spent many nights working on this one problem.

When required, I can also emulate Windows applications using Wine and Box86, as shown below with the iconic Windows 3D Pinball Space Cadet.

Taking advantage of the Raspberry Pi structure, I designed my laptop as an expandable system that can be easily used as a component of future electronics projects. Through controlling the GPIO pins, using the C programming language, I used this functionality to install a power button and an automatic cooling fan.

While my homemade laptop is not outright comparable to an expensive commercial product, it only costs around $250 and is much more useful being designed around my daily use-case. My design reached a great balance between economics, functionality, and my personal needs.

Stl Files

Mosaic Maker

A customizable mosaic maker in C# and one of the most complete and advanced piece of software I have created. Started in 9th grade (14 years old).

I wanted to design something that could create mosaics from a selection of smaller images.

A mosaic maker replaces pixels in an image with smaller images pulled from an image set that closest matches each pixel's color. As my set, I used a collection of images I collaboratively drew with a friend of mine known as the Gecko Collection, thus I named this project the "Geckoinator". The code is written in C# and built upon my experience and interest in image processing.

Generating the mosaic can be divided into two primary steps: pixelizing and tiling. After the user inputs an image, in pixelizing, the image's quality is reduced to the desired amount (this controls the resolution of the final output). Then, in tiling, each of the new pixels is replaced by a smaller image that closest matches the color of that pixel.

After the basic framework was finished, I realized there was a problem with bands of color forming due to the fewer available colors in the image set. To fix this issue, I introduced a feature to improve the quality of the images known as Floyd-Steinberg dithering. Dithering in graphics is a technique using a combination of colors placed next to each other to create an illusion of an intended color. An example would be early comic books, which were limited by how many colors they could print and commonly employed this tactic. This helps eliminate color banding by smoothing the transition between two colors. It also increases the accuracy of the colors in the output.

Floyd-Steinberg dithering works by scanning through an image pixel by pixel. On each pixel, the difference between the original color and the closest available color is added to the neighboring pixels in a predetermined pattern (as shown above). Thus, instead of the error being lost with each pixel, it is preserved in other pixels.

This algorithm is integrated between the pixelizing and tiling steps and applies the error dispersion to the entire image. This addition greatly improves the color depth and appearance of the output images, especially when viewed from a distance where they can even be passable as unedited images.

I also introduced batch processing and multithreading in order to be able to process videos and of course...(best experienced in full 4K and fullscreen)

I would probably consider this one of my, if not, the most technically challenging programs I have ever written. This used a lot of skill involving array processing and algorithms.

Github

Spring Dovetail Blocks

A modularized tube rack set based on my novel joint design called Spring Dove tail. Designed to be freely assembled by needs and disassemble with ease.

It's one of my proudest designs so far. I designed a new joinery to modularize 3D-printed items, by adding my own touch to the historical dovetail joint of woodworking. I coined the term "Spring Dovetail" for it.

An extra curved spring layer is added in the dovetail junction to buffer printing errors and prevent over-tight/loose engagement.

A good application of my Spring Dovetail design is for a system of modularized tube rack sets. Existing commercial products consist of a single molded part with a large footprint. This makes them difficult to use, especially when many tube types are required in the experiments. I thus designed modularized racks that can connect together via Spring Dovetail. The spring tension is fine-tuned to be just right so the block units can be connected and disconnected without much hassle and still stay together.

This design ended up being one of my most popular and gained a lot of traction online. The original editable files are also shared with the public under Creative Commons Licensing. Not only are they used by many, but also some derived versions are customized by the community, including integrated into a commercial product made by a startup company integrating my design into their commercial bio-reactor products.

Stl Files

Fractal Generators

Two fractal generators in C that I used as challenges to further my skills. Started in 9th grade and revisited in 11th grade (16 years old).

When I was taking CS50x, I was introduced to the concept of recursion. With this new knowledge, I wondered if I could use this to make some fractals. The first one I wanted to try was a Sierpinski triangle. After finishing the CS50 assignment for the week, I got to work on my generator using C. The generation method I went for was duplication, I took the previous shape and added two more copies of it below.

After more than a year, I was messing around with C during a CS club meeting. This time I aimed for the much more difficult dragon curve to recreate. Like the first, I would use C for the added challenge. It would take a lot of head-scratching and 5 days to complete.

One of the classic and most simple ways to produce a dragon curve is to repeatedly fold a piece of paper in half in the same direction, then unfold it at right angles. It was this idea that inspired my approach.

To emulate unfolding a piece of paper at a right angle, I start with a line. A copy of that line is created, rotated 90 degrees, then attached to the original at a rotation point. Taking the output, the process can be repeated on it, and so on... This is the core concept of this project is built on.

To convert my idea into code, I decided to draw out my thinking onto paper. I noticed some patterns in the iterations when I drew them out, and came up with a step-by-step algorithm to get the job done.

The resulting algorithm consists of three major hurdles.

First, the location of the rotation point is needed to know where to merge the pieces together.

Next, the size of the final output is needed to create a container large enough to house it.

With both pieces of information, the original and copy can be joined together to create the output.

With a method figured out, it was trivial to implement it into code. By the morning of day 5, I had finished the program. It worked for all iterations I tested, up to 20.

As the final touch to the programs, I made a C# script that converted the ASCII outputs of the C code into pixels on an image which greatly improved their viewability.

Triangle Github • Dragon Github • Text to Image Github