Inspiration
The Winter Olympics biathlon is one of the most demanding events in sports — athletes must ski cross-country at full speed, then immediately shift to the precision required to hit small targets. That combination of speed, accuracy, and real-time decision-making is what inspired Frost Navigator. The goal was to build a robot that could mirror that same challenge: navigate a complex obstacle course autonomously, making split-second decisions based on sensor input, all without any human intervention once it starts.
For the team, this was a first hardware hackathon. Coming from a full-stack web development background, writing embedded C++ for Arduino was a completely different world — no browser console, no hot reload, no easy debugging. You upload code, press a button, and either it works or it doesn't. That constraint forced a much more careful approach to every line before running it.
How We Built It
Frost Navigator runs on an Arduino UNO R4 Minima as the central controller, with two DC motors driven through a motor driver shield for movement, an ultrasonic sensor for real-time obstacle detection, a TCS3200 color sensor for path recognition, and two IR sensors for line following.
The main navigation logic is written in C++ — a state machine that coordinates box pickup, color-based path selection, obstacle avoidance, and turn navigation. The color sensor was one of the trickiest parts: frequency output for red, green, and blue channels had to be read separately, then ratios calculated to reliably identify the track color under varying lighting conditions.
The ultrasonic sensor calculates distance using pulse timing. A pulse is sent out, the time \( t \) for the echo to return is measured, and distance is calculated using:
$$d = \frac{v \cdot t}{2}$$
where \( v = 343 \text{ m/s} \) is the speed of sound. The detection threshold was tuned so the robot begins turning before hitting an obstacle rather than reacting at the last second.
The color sensor isolates each photodiode channel using control pins S2 and S3, reading output frequency \( f \) per color. To normalize readings under different lighting, the ratio between channels is used rather than raw values:
$$R = \frac{f_{\text{red}}}{f_{\text{red}} + f_{\text{green}} + f_{\text{blue}}}$$
This keeps color detection reliable even when ambient light shifts.
Challenges
Motor calibration was a constant battle — the two DC motors didn't spin at exactly the same rate, so even at equal power the robot would drift. Speed offsets had to be tuned to keep it moving straight. The color sensor also required careful normalization; ambient light would throw off raw frequency readings, which is why the ratio-based approach was used instead.
Coordinating the state machine so that all subsystems — pickup, path detection, obstacle avoidance, and turning — worked together without conflicting was the hardest software problem. Debugging hardware is also slow: each test cycle meant uploading new code and physically repositioning the robot, so there was no room for trial-and-error the way web development allows.
What We Learned
This hackathon taught the most about systems thinking. In web development, components communicate through APIs and can be tested in isolation. In robotics, everything is interconnected — a slight motor imbalance affects where the robot actually is, which throws off the color sensor's readings. Writing code that's resilient to real-world imperfections like sensor noise, motor inconsistency, and battery voltage drop was a completely new challenge.
What's Next
- Implement the target shooting mechanism for the green path section
- Add adaptive speed control based on battery voltage to maintain consistent performance as power drops
- Explore PID control for smoother, more precise turning:
$$u(t) = K_p \cdot e(t) + K_i \int_0^t e(\tau)\, d\tau + K_d \frac{de(t)}{dt}$$
- Attempt the curved ramp for bonus points
Log in or sign up for Devpost to join the conversation.