Overview
A small team building a vehicle that follows a colored line around a course on its own, while sharing that course with the other teams' vehicles at the same time. The work split four ways: a custom Arduino shield for power and motor drive, embedded C++ on an ATmega, a discrete photodiode array for sensing, and a WebSocket link carrying telemetry off the vehicle.
The WebSocket link was mine end to end. I did a large share of the photodiode array and of the physical assembly of the vehicle, and I supported the shield design and the PID work rather than leading them. The vehicle followed the course and the project was delivered.
Custom motor & power shield
The vehicle's electronics live on a custom shield stacked on the Arduino, nicknamed "Mac and Cheese" on its silkscreen. Each of the two drive motors gets its own discrete H-bridge, built from individual transistors rather than an off-the-shelf driver chip, so each wheel can run forward and reverse independently. A driver IC would have been fewer parts and less to get wrong. We built it from transistors on purpose, to understand the switching topology instead of calling into a black box. The same board steps a pair of 9V batteries down to 3.3V to power the Arduino, and dedicated screw-terminal blocks connect the photodiode array and its LEDs instead of loose wire splices.
Embedded detection system
Line detection runs through a custom photodiode array read by the ATmega's ADCs, with no camera or external vision hardware involved. I did a large share of that array, and of the physical build of the vehicle around it.
On top of the raw readings sits a PID control loop, which treats the vehicle's position relative to the line as an error term and continuously corrects the motor outputs to stay centered, rather than reacting to the sensors with fixed on/off logic. I supported that work rather than owning it.
WebSocket communication
The link is the piece I owned. The course requirement was that two vehicles run the course at the same time, on paths that crossed at multiple points. Every team built their robot differently, so neither vehicle could assume anything about how the other one moved or how quickly it got anywhere. That rules out hard-coding the yielding: there is no fixed timing to encode against. Instead the two vehicles shared status over a WebSocket link and cooperated at each crossing.
The same link carried telemetry and debug messages back to a laptop, which is what sped development up. You can watch what the vehicle is deciding while it drives, instead of reconstructing it afterward from a robot that has already left the line.