Hardware engineering is inherently unpredictable. Sometimes the biggest challenges you face aren't found in your C++ code, your EMI shielding, or your power distribution logic. Sometimes, the integration wall is the physical environment where you are building.
Over the past week of working on Project GEPARD V5.0 for the Element14 EZ-EV Challenge, I encountered an emergency that had absolutely nothing to do with microcontrollers or sensors. My house was hit by a sudden, severe mice infestation. Dealing with the cleaning, and completely securing my living space from pests consumed the crucial remaining days I had. Because of this localized emergency, I was forced to halt the physical build right before the final electrical wiring for the dock's power supply could be completed.
As a result, the current deliverable is a highly detailed, mechanical Proof of Concept (PoC) for the docking sequence, rather than a fully energized charging station. Here is the complete breakdown of the mechanical PoC, the theoretical electrical handshake, the power physics, and a deeply frustrating hardware mystery.
The Mechanical PoC Video
In the accompanying demo video, you will see the rover fully mobile and executing the physical docking sequence. The dual JGA25-370 gear motors drive the heavy-duty tracks smoothly, and I manually pilot the rover squarely into the docking bay. You will see the physical alignment succeed as the front of the rover makes contact with the dock.
However, because the dock itself is not cabled to the wall or the boost converter yet, this sequence is purely mechanical. No actual electrical power is being transferred during the video. The structural alignment, the chassis approach, and the magnetic mating of the pins work flawlessly, proving the physical viability of the custom dock design.
If the dock were fully wired to the electrical mains, that simple mechanical connection would trigger a highly complex, carefully orchestrated electrical handshake.
The Docking Interface & RS485 Handshake
When building an autonomous charging dock, you cannot simply leave live voltage resting on exposed metal contacts. That is a massive fire hazard and a risk to the hardware. To solve this, Project GEPARD uses a strict "cold-launch" docking architecture.
The interface on the rear bumper of the rover consists of two separate magnetic arrays: a 2-Pin Magnetic High-Current Pogo array dedicated exclusively to charging power, and a 4-Pin Magnetic Pogo array dedicated to data.
When the rover approaches and makes physical contact with the dock, the 4-pin data pogo parasitically boots the dock's logic. This initiates the critical communication sequence. The system relies on ADI ADM3068E boards mounted on both the rover and the dock. Once booted, the RS485 handshake begins, establishing an EMI-resistant communication line directly between the rover and the dock. This isolated handshake ensures that the dock verifies the exact cryptographic identity of the rover before any high voltage is allowed to flow.
Power Delivery and the 12.85V Boost
Once the dock successfully validates the rover's identity, the physical power delivery sequence prepares to launch. The base station is powered by a standard 12V 3A wall adapter. However, you cannot efficiently charge a multi-cell battery pack with a flat 12V supply; you need electrical pressure to push the current into the lithium-ion cells.
To achieve this necessary electrical pressure, the 12V input from the wall is routed through an XL6009 Boost Converter that is tuned specifically to output 12.85V. This 12.85V threshold is the precise peak voltage required to safely push current into the internal UPS battery pack and fully saturate the cells without causing degradation or over-volting them.
The Cold-Launch Relay Sequence
Even with the voltage actively boosted to 12.85V within the dock, that power is kept completely isolated from the exposed external pogo pins until the exact moment of validation. The dock's Arduino controls a 5V Single-Channel Relay to act as the ultimate gatekeeper. The 12.85V positive output from the boost converter routes directly into the COM (Common) port of this relay. The relay's Normally Open (NO) terminal routes to the positive pad of the 2-pin magnetic charging pogo.
When the RS485 handshake successfully validates the rover, the dock's Arduino triggers the relay. The internal switch flips from COM to NO, instantly sending the 12.85V through the pogo pins, into the rover's UPS Box input, and through the internal Battery Management System (BMS) to charge the battery cells. Because this high-voltage switch happens inside the relay after the magnetic pins are already firmly mated together, there is absolutely no sparking or arcing at the physical contact points, maximizing the lifespan of the copper pads.
Sentinel Mode Power State
Once the relay energizes and the charger is officially connected, the rover enters a sleep state to minimize active current draw and allow the battery to charge as efficiently as possible.
However, this sleep state is highly contextual based on the user's commands. If the rover has been commanded into "Sentinel" mode, the primary drive motors and roaming loops are completely powered down to save energy, but the rover keeps its camera live to actively process the threat assessment triage engine. This architecture allows the vehicle to act as a stationary, charging security turret, processing visual data and guarding the room while the battery cells replenish.
Safe Undocking & The BMS Takeover
The charging sequence is relatively straightforward, but leaving the dock safely is where the most critical engineering logic occurs. When the charge is complete, or when the user issues a manual command to deploy, the rover must undock without damaging its sensitive logic boards.
First, the software actively releases the RS485 handshake. Immediately after this data signal drops, the dock's relay opens. This action completely deadens the charging pins before the magnets physically break apart and the rover pulls away. By deadening the pins prior to physical separation, the system definitively prevents electrical arcing and potentially catastrophic voltage brownouts.
Furthermore, cleanly cutting the external 12.85V supply while the rover is still physically stationary forces the rover's internal hardware BMS to instantly take over the entire electrical load. Because the BMS takes over before the motors even begin to spin, the microcontrollers, sensors, and actuators never experience a sudden voltage drop. When the rover finally engages its tracks to physically pull away from the dock, it is already running entirely on its own internal, stable battery power.
The INA226 Telemetry Mystery & Charge Cut-Off
Ideally, the Arduino UNO Q would monitor this entire charging curve and actively tell the dock when the battery is full. However, I have hit a massive, unresolved hardware wall: the INA226 I2C voltage sensor telemetry is completely dead.
The sensor simply refuses to communicate with the Arduino. To ensure I wasn't dealing with a software bug, I went as far as testing the raw silicon using electrical physics. I verified the 3.3V logic power, meticulously checked the wiring continuity, and ultimately ran a reverse-bias diode test using my multimeter directly on the SDA and SCL pins. The multimeter read a 500mV voltage drop, which definitively proves that the internal silicon diode structures of the logic chip are physically alive. Despite the silicon being intact, the I2C bus still refuses to find the address, and the scanner returns a total failure. I honestly still do not know why this is happening.
The fascinating part of this failure is how the INA226 breakout board is physically architected. The board features a massive physical shunt resistor that the high-current battery line passes through. Because the logic chip is effectively comatose, the massive shunt resistor now acts as a "dumb" power bridge. It passes the raw 11.3V battery power straight to the motor drivers perfectly, allowing the rover to drive and maneuver with full physical torque. But because the I2C data lines remain entirely silent, the Arduino MCU is completely blind to its own battery voltage.
Because the microcontroller cannot see its own battery percentage, it cannot send a software command to the dock to stop the 12.85V flow. As a result, the system must rely entirely on the hardware Battery Management System (BMS) for the charge cut-off. When the rover completes the pogo handshake and the 12.85V power flows in from the energized relay, the hardware BMS acts as the ultimate safety net. Once the lithium-ion cells physically reach their peak 12.6V capacity, the hardware controller physically cuts the current draw. This prevents the cells from overcharging and allows the rover to sit securely in the dock, fully powered and monitoring its environment in Sentinel mode, without relying on a dead I2C sensor.
Hardware design is an exercise in mitigating failure. From rat infestations halting wiring, to I2C logic chips inexplicably going dark, having a robust, federated architecture allows the mechanical and safety systems to succeed even when other parameters fail.