I've added a PC application to the system, written in C (GTK3 + Cairo, compiled in MSYS2 for Windows). The goal was to get realtime visualization of the vehicle position on the track, without depending on any proprietary tool.

What the application does:

It renders the quarry track from 200 control points, which are refined at runtime into 800 interpolated points for a smoother curve. The vehicle is displayed as an arrow with smooth rotation based on the tangent to the track. The arrow color indicates the mode — blue for manual control, cyan for automatic, orange during safety stop, red in the local simulator.

Communication with the top master (ESP32) runs over HTTP — the ESP provides a /data endpoint with JSON payload (position, speed, direction, hall states, safety stop). The application fetches data in a separate thread via libcurl with a 2s timeout, so the GUI doesn't freeze when the ESP doesn't respond.

Hall sensors and track behavior:

There are five hall sensors placed along the track, between the end points and the middle. Both the application and the low master evaluate hall state themselves — meaning they detect changes in the magnetic field, not its absolute level. This matters because each hall has a slightly different polarity depending on how it was mounted. Instead of looking for a common level, the system simply watches for transitions. On top of that there's debouncing in a time window, so short transient spikes are ignored and only a stable change is propagated to the system.

Basic vehicle behavior is built on top of the hall sensors. When the vehicle reaches one of the end halls, safety stop kicks in — the vehicle halts and the system waits for user intervention. When the user presses a direction button after 5 seconds, safety stop is released.

Local simulator:

The biggest added value is the local mode. Flipping a switch disconnects the application from the ESP and the vehicle is controlled by FWD/BWD/STOP buttons plus a throttle slider. This let me tune the visualization, end-of-track detection, arrow rotation and overall UX without having to wire up the ESP and run the hardware. Nice side effect — when the ESP is running and WiFi drops, the application doesn't crash and keeps the last known state, or you can switch to manual testing.

End-of-track rotation:

I was solving a topological issue — the track is visually a one-way line, but physically the vehicle reverses. Instead of the arrow just flipping back and forth along the same line (nonsense), I implemented a state machine: the vehicle reaches the end, stops for 2s, then smoothly rotates 180° over 3s, and waits for another user input. This way the visualization behaves the way an observer intuitively expects.