1/18/2026 8:45 PM - Planned the project

Back in November and December, when we got our team event assignments, I met with my partner for the Electric Vehicle Science Olympiad event, and we decided to make an Arduino-style robot. We considered using the robotics team's prebuilt robot (I was part of the robotics team), which was probably more accurate, but I wanted to do this to experience more of the engineering process. I took the lead on this event in designing and building (while my partner took the lead on other events we had together).

I watched some videos for external inspiration. It seemed like a long form factor was popular (video was kinda blurry):

As I planned the project, I came up with a simple list of materials:

• Gobilda super speed servo (my assumption was that this was both fast and accurate... turns out all servos aren't accurate to some degree)
• arduino uno
• button
• battery
• basically it
  

1/18/2026 8:56 PM - Designed V1/V2 robot

I got right to work this January, since I had time. The first thing I did was plan out the robot on a sheet of paper:

I gathered my materials from the school's robotics lab. They had most of the materials, so I didn't need to buy much. I then CADed the first version of the robot, V1, which matched the long form factor of the other robots:

However, I realized that the long form factor would definitely not fit within even two of my printers, so I reCADed it for a slightly shorter and more thoughtful design, V2:

1/18/2026 9:01 PM - Built V2 & Tested

After I designed my robot V2, I 3D printed the parts and built it mainly using REV Robotics components with an Arduino, Gobilda speed servo, and a battery pack. Here is part of the finished bot (I only have a picture of this part :( ):

After I built it, my friend kindly helped me test it. I used the code I had quickly written a bit before and inputted the parameters: distance - 800cm, time - 15s. After it had run at the speed computed by distance/time for 15s, it ended up about at ~1120cm, which was ~40% error. I knew something was wrong - later I would realize that, even though the datasheet said 180 max RPM for 4.8V, inputting servo.write(180) (full power) can't necessarily reach the topmost speed, and the max rpm itself wasn't accurate to my battery and setup.

1/18/2026 9:08 PM - Designed V3

The following night (I think?), I suddenly realized a much better solution. Since I couldn't rely on the servo to provide accurate speed, I would use odometry instead by positioning a bumper on the shaft of the wheels that would hit a limit switch every time the wheels made one revolution. This eliminated many sources of error and ensured much more reliable distance tracking.

Soon after, I reCADed my robot for V3. This one was much more compact in size (both width and length), utilizing stacked surfaces to increase the efficiency of surface area use. This allowed me to print it all in one go, which also meant that I didn't have to screw the plates together and risk wheel alignment errors. I also made a mount for the limit switch.

After 3D printing the plate and building, here's what it looked like!

p.s. I don't know why it took me so long, things were difficult, I guess :sob:

1/19/2026 10 AM - Coded & Tested V3

After building V3, I got right to work revamping the code. This code would track the accurate amount of distance traveled by taking in feedback from the limit switch. When it hits about one wheel revolution from the finish line, it will slow down to a creep speed I will explain later.

Gemini helped me weigh the distance and time error penalties (distance error = 2pts/cm, time error = 1pt/sec), with the equation Error = 1/(2*Velocity). If I found the Error-Velocity graph from testing my robot and found the intersection of the graphs, I would find the maximum speed at which I could reduce time penalties while not over-sacrificing distance errors.

I first ran several tests holding different parameters constant (time, distance, etc.). I got an insane error - and the error increased as I slowed down (since I held the diminished speed for longer). I realized this was because the relationship between the servo speed (s.s.) (what you put into servo.write(speed)) and the true speed (in cm/s) was NOT linear, but more logistic. More tests helped me find that equation. Who knew that doing school physics labs could come in handy?

Fortunately, from about s.s. 0-65, the relationship was pretty much linear (actually, it was almost perfectly linear, surprisingly). This simplifies calculations. After I regressed a logistic model to the s.s.-true speed relationship, I reran the error tests, found the intersection, found the optimal servo speed, and finished the firmware code.

Results:

1/19/2026 6 PM - Redid the limit switch mount & tested

I realized that the bumper for the limit switch would also hit the limit switch body and lock the car in place, so I reCADed it for better positioning. I also realized that the set screw (I was using an external screw) to lock the bumper on the shaft was going to hit the limit switch, so I came up with a simple solution to just make the bumper longer so that the limit switch would not be in the path of the screw.

After that, I tested it, and it worked perfectly (yes!). I put on the remaining wires and buttons while I waited to get a limit switch from school.

2/23/2026 7:22 PM - Finalize EV Building & Testing for Harvard Scioly

After I reCADed the limit switch mount, I printed it and put it on. Furthermore, I had to solder the terminals of the limit switch since they didn't come pre-soldered, but that's fine. This was bascially the point where all my building was done for this version of the robot, which I took to the Harvard Science Olympiad to compete.

After, I did a few test runs in the same manner I did my first set of test runs, and I found it to be really accurate. When it basically stopped right at the line for my 400m test (the time wasn't too off either), I shouted in enthusiasm! However, I found out after that you have to stop at a specific point on the 400m line, and my angling was off.

Here are the results from that test:

Therefore, I tested it again at school the week before Harvard. I figured that, if I start my robot the slightest bit angled to the right, then the off-angling would compensate for itself. It worked some of the time - once, I got only 1 inch off from the point. However, I wasn't recording my time offset, which I found was pretty off at the competition, but not to worry.

Here are the results from that test:

2/23/2026 7:31 PM - Harvard Scioly 2026!

This is the Harvard Science Olympiad! I tested my robot - unfortunately, we didn't do too well, though. I assumed that there would be lines on the floor to align my car with, but I didn't trust the piece of tape they put down. Next time, I will make sure to bring extra alignment devices, like a right-angle ruler. Also, a longer (10 meter) measuring tape would probably be helpful.

The time seemed to be really off too for some reason, so I'll look at that. The angling on my first run was pretty good, about 14 cm off. I over-angled the car initially for the second run, so I was off about 28 cm. We'll do better next time! We still got 12th place though, which is pretty good. Time and effort pay off!

It was snowing that day :) it was also really slippery.

2/23/2026 7:41 PM - CADing the New EV Version

While reflecting on Harvard, I came up with a plan. I made a list of things I needed next time - better wheels with a fixed radius (no treads, etc), better motors, better alignment, etc. I got really excited about it and really into it, and that night, I went home and drew up some plans on my whiteboard.

Though there wasn't a great amount of resources for researching others' designs for science olympiad, I figured I could use a redo. I decided to go with the most precise method I knew - PID control. Looking at the other robots at Harvard and talking to people, I realized it would be better to hit the can bonus this time, but not by traveling in an arc, since that was very error-prone. Instead, I would travel in a trapezoidal shape, noted by the following picture of my whiteboard, with varying speeds for each. In addition, I decided to use goBILDA's odometry system since I knew it was very precise from using it in FTC. The only challenge would be porting its Java implementation code into Arduino C++.

Whiteboard:

It took a little longer than I expected to CAD it, but it's fine - I quite enjoyed it. I started with a fresh part studio and assembly, and made the chassis as narrow as possible while making room for two servos on the bottom this time. This would allow wheel-independent steering and at the same time provide double the torque (therefore faster driving). I stacked things vertically to reduce the space I needed, and I put the odometry computer and the bubble level on a plate over the Arduino. I put the battery beside it, and under the area near the battery, I put the odometry wheels.

Here's some CAD screenshots:

And here's some fun (AI) renders!

3/16/2026 6:35 PM - Finished CADing and Ordering Parts

I finished CADing the mounts for the external motor encoders as I realized I’d need those for my velocity PID. I’m not too much of a fan of the big size of the encoders or the gears that I’ve put on them, but hopefully it shouldn’t be a problem. I also ordered: a ball caster for the back of my robot, the motor encoders, and 120mm (diameter) goBILDA disc wheels for the front of my robot. The rest of the parts I’ll borrow from my school’s robotics room.

3/16/2026 6:36 PM - Built the robot

The week before the competition, I spent a ton of time after school to get the robot built. It took surprisingly long to assemble everything, especially the bottom of the robot where the wheel assembly went. I had to assemble parts in a specific order so that they would all fit, and I encountered challenges such as the plastic gears warping and compressing, messing up the alignment of the wheels. Wiring was also a bit of a pain as the wires were going everywhere and there weren’t enough slots on each breadboard row. I managed to get it all to work, but it was pretty messy!

3/16/2026 6:37 PM - Coded the robot

With all the complex parts on the robot, I knew the code was going to be pretty long. I wasn’t as worried about the simple parts like the motor encoder, the servos, and the buttons, but I was more worried about how to use the goBILDA pinpoint computer and the PID. Fortunately, goBILDA (surprisingly) did have an Arduino library for their pinpoint, but I found out it didn’t work with the Arduino Uno. Surprisingly, Gemini fixed it accurately and it ran without issues. Did it work? I didn’t actually find out, because the pinpoint never reported an updated position and the robot went wonky during testing.

As for the rest of the code, I knew there was no way I could write that much code in time for the competition, so I settled for learning how to use agentic AI to write it. After a couple sessions with Github Copilot (they’re taking away claude models from it now… nooooo!), I had myself about a thousand lines which looked solid. I didn’t actually know if they were since, while the robot moved, it spun around in circles and didn’t seem to really be using the PID.

If anyone wants to take a look at the Arduino Uno-compatible code for the goBILDA pinpoint computer, I have a repo of it here.

Oh, and, I forgot to say, I made a wiring schematic for the robot as well. I think it’s safe to say “better said than done!” judging from the mess of wires on my robot in the end, haha!

3/16/2026 6:38 PM - Robot testing and rebuilding - the good and the bad

It took a lot of time to test the robot not really because of testing. I began testing it two days before the competition, and it was wildly off of what it was supposed to do. I was using two different servos, so I had a lot of trouble aligning their speeds, and the code and the PID just didn’t work (which I guess is what happens when copilot generates 1000 lines of code for hardware that you have no idea what it does). The first night, I didn’t get much time to test. I spent a lot of time trying to really get it right the second night (the night before the competition), but by 7:00, an hour after I had begun testing, I realized I was going nowhere and that I wouldn’t have a robot for the next day.

So, I did something I’ve never done before. I told myself that if I didn’t see any good progress by 7:15, I would cut this design and revert to my Harvard Scioly design. When 7:15 rolled by, no real progress had to be made. So, I did something else I’ve never done before. I cut it, packed up my things, and went up to the robotics room to retrieve what was left of my old Harvard robot. It really hurt to give up on my design and what I felt was my only chance of a ribbon at states. This was because my old robot didn’t have the functionality to get the can bonus. I kept looking back, even after I tore the robot apart to retrieve the electronics I needed to rebuild my Harvard robot. I kept thinking of other things I could do to implement steering for the can bonus, but a quick chat with Gemini and some honesty with myself allowed me to realize that I needed to just cut it and focus on the bare bones - getting a robot that just worked for tomorrow.

I felt disappointed and like I’d failed. And, to be honest, I did fail. But I hadn’t failed in the sense I thought I did; I hadn’t failed because I didn’t test more, or build a better robot with more parts. I failed because I failed to realize the importance of simplicity and building up from a base, rather than fixing things after I’ve designed something really complex. This was a lesson I’d knew and learned over and over again, yet never really implemented. I was proud of the decision I made tonight to save myself and my team and revert to my Harvard robot. It was a step in the right direction.

In the end, at 2am (or 3am, I don’t remember) in the morning, I was glad that I at least made the conscious decision to cut it early and focus on the bare bones. Only at that time was I able to get back just to what I had at Harvard, let alone adding a whole new steering mechanism. More surprises followed the next day at the competition… but read on in the next journal entry!

The robot I gave up on:

The robot I reverted to:

3/16/2026 6:39 PM - States Science Olympiad

(continued from the last journal entry)

On the morning of the state competition, I woke up with 4-5 hours of sleep, not even feeling tired. I more or less expected this amount of sleep, and so my body adjusted. I packed up the materials I left lying around the previous night and put them into the Craftsman suitcase I carried my robot in. I put as many materials as I could in there just in case I needed something or something broke.

I impounded and saw the regular mass of Unphayzed EV kit vehicles, which were actually pretty precise. I heard it still took the teams a lot of tuning though. A few hours later, come time for our turn to run our robot, my partner and I aligned our robot like we had done previously. We’d improved our strategy for straighter alignment than Harvard, but to be honest, it didn’t really work that well. Fortunately, the crack in the floor at states was almost perfectly perpendicular to the line of travel, so I was very grateful for that.

The first time we activated our robot, it all of a sudden stopped moving and began to spin. This was very confusing, since there was no way in which the robot could ever turn. Turns out, some wires got caught in the wheel. This was unfortunate, but it didn’t deter us. Second time around, we activated the robot, and… and… it worked so well!!! It stopped very near the finish line, and at once I knew that we did well. We figured we got about 140 points, which wasn’t optimal, but it better than the other vehicles. We knew we did well because we knew one thing - in EV, precision was key. Even if you can’t get the can bonus, even if you got the time penalty, precision was key. Every centimeter off the ending point was 2 points added to your score (lowest score wins). Simplicity and reliability meant precision, and if precision was key, then the simplest robot was key.

Would it have been great to have our originally planned robot that could run through the cans and arrived at the precise position as recorded by the odometry? Of course it would, but that would be the same thing as saying that it would be great to automatically win the competition. Engineering comes with failure. Simplicity first wins. These things I learned through this year’s EV competition, and this was more valuable than any medal.

In the end, we placed 10th, earning us an honorary shoutout at the award ceremony. After all the strategic decisions, after all the reverting, after all the settling for simplicity, it all paid off in the recognition that was all we ever wanted. This was a lesson for the ages, and I trust that the higher power that I believe in wanted us to realize this.

3/16/2026 8 PM - Getting ready for submission and shipping

In these past few hours, I've been getting ready to ship my project. I moved around the files, included versions for both harvard and states, and wrote the full README. You can look at my github repo to see. It took surprisingly long because of all the stuff I left until now to do, but I'm finally finished!