Forum - Recent Threads

DockBot - Part 6 - The Mostly Open Closed Loop Control

arvindsa — Tue, 18 Aug 2026 06:09:21 GMT

I am building a robotic system that identifies the charging port on an EV and automatically moves a charger arm to plug the charger in.

Past Forum Posts:

I wanted to have a proper closed loop control of my motors using an magenetic encoder TLE5012 which i have in surplus but I did not get the ordered diametrical magnets in time. So i had to do yet another work around. Use the Aruco marker as a sensor, move the robot incrementally, correct the motors. and repeat till the target. Sounds Simple. But Nooope.

Motor Calibration. Take 1

The idea was simple, run one motor at a known PWM speed for a small time, see how much the robot turns, through aruco marker, then incrementally increase and see the difference. Then the opposite direction. Left one worked out fine, but right one never turned on. It seems that while the left one started at PWM 84/255 duty, the right one started only at 184/255. This caused the right motor to never start in the calibration algorithm I made. Also, i noticed a fundamental flaw, the smaller bursts meant the tracks were slipping on my floor, and there was not enough time for it to stabilize the slipping. So this idea had to be junked

community.element14.com/.../20260817_5F00_220222.mp4

Motor calibration, take 2

I decided to just junk auto calibration, and went the cannibal way. I decided to use constant motor speeds one set speed for each of forward, reverse, rotate left and rotate right. I kept tracking the motion and manually adjusted the speed

community.element14.com/.../p6_2D00_v1.mp4

If you noticed, there was a slight flutter in the marker due to the ceiling fan's air current. This did create some issues. So i decided to make it more robust by creating a cube out of cardboard.

The tank now wears a small cube with a marker on each face - back, top, left, right - instead of the single (actually two) rear marker from before. The point is that whichever face happens to be pointed at the camera, something is always trackable, even when it rotates, not just when the tank is driving directly away from it. Now, I never managed to get multi point tracking working, you will see that i had to resort to some hand adjustment of the robot, but with time I can get it fixed.

Actually approaching a target: three wrong designs first

The Radxa's camera is fixed - mounted separately. It is not mounted on the robot. I wrote something that would spin the tank until the target marker was centered in the camera frame, the way you'd steer if the camera were on the robot's. Since the camera doesn't move when the robot spins, and the target doesn't move either, the target's position in the frame - never changes no matter what the robot does. The script just spun in place for forty steps, learning nothing. The fix: infer heading from how the robot's own marker position shifts in the frame, sampled before and after a small forward nudge. That nudge does double duty - it's both the heading measurement and real progress toward the goal, so nothing is wasted purely on sensing.

heading = (rx1 - rx0, rz1 - rz0)   # where the robot's own marker moved
bearing = (goal_x - rx1, goal_z - rz1)   # where the goal is from here
angle = signed_angle_deg(*heading, *bearing) * turn_sign

Second wrong design: I started the approaching using raw pixel calulation. But I moved from raw pixel positions to real millimeters via cv2.solvePnP, which has a sign convention of its own - --turn-sign that worked for the pixel-only version was backwards for the mm version, and this caused the robot to move away from the target by making an u Turn.

Third: close to the target's marker isn't the same as "in front of it." solvePnP gives you the marker's own facing direction, not just its position - I'd been computing distance to a point, not distance to a pose. Fixed by projecting a goal point along the target's own facing normal, sampled once at startup since the target is static, rather than the marker's raw position.

community.element14.com/.../trial.mp4

Final Notes

Once these were fixed, the robot became tamed, There were many fine tuning steps in between but they are not very educative. Now to the final step of Getting the Charging Handle to a car and also before that Improve the accuracy.

SmartAssist EV - Mobile Robot Control and Live Video Streaming - Part 7

jelektro — Mon, 17 Aug 2026 00:10:29 GMT

Project Roadmap

Part 1 - Experimental Smart Assistive Platform for Elderly and Disabled People

Part 2 - Hardware Platform

Part 3 - Wireless Command and H-Bridge Direct Drive

Part 4 - Introducing Autonomous Line Following (TCRT5000)

Part 5 - Non-Contact Proactive Shielding (HC-SR04 Range Finder)

Part 6 - Strict Priority Hierarchy with Tactile Mechanical Bumpers

Part 7 - Mobile Robot Control and Live Video Streaming

As part of this project, we have developed a fully wireless control system for a wheeled robot integrated with a real-time live video stream. The heart of the entire setup is the Arduino Uno Q board.

Architecture and Technologies Used

The project leverages the unique, dual-processor architecture of the Arduino Uno Q and the Arduino App Lab ecosystem, which allows splitting system operations into two separate layers:

1. Application Layer (MPU Processor running Linux/Zephyr):

Responsible for directly handling the USB camera plugged into the board's port.
Runs a native server hosting the Web User Interface (WebUI).
Streams live video directly to any web browser in real-time, completely bypassing the need for heavy external libraries like Flask or OpenCV.

2. Hardware Layer (MCU STM32 Microcontroller):

Handles real-time, low-level execution of the digital H-bridge pins (four input pins controlling motor direction).
Generates diagnostic signals for the onboard peripherals of the Arduino Uno Q.

The engineered system seamlessly combines mechanical movement with advanced visual telemetry broadcasted directly on the robot itself:

1. Virtual Joystick (Local WebUI): The web interface is completely free of external network dependencies (no CDNs, no Cloudflare). The entire touch-control script is embedded directly into the index.html file within the assets folder. Touch drags on a smartphone screen or mouse movements on a PC are instantly calculated into directional vectors (F - forward, B - backward, L - left, R - right, S - stop).

2. Inter-Process Communication (RPC Bridge): To transmit data from the web interface (JavaScript/Python code) to the motors (C++ code), we used the official, built-in Arduino_RouterBridge communication bridge. It handles asynchronous requests, guaranteeing minimal latency and instantaneous drive response.

3. Color Status Signaling (RGB LED): The system integrates the native mapping of the onboard LED4, which operates in an inverted logic state (Active LOW). When moving forward, the LED lights up green; when reversing, it turns red; during turns, it lights up blue; and it automatically turns off when the robot is idle.

4. 8×13 Directional LED Matrix: The large LED dot matrix embedded into the Arduino Uno Q is used to visualize the robot's heading. Utilizing the low-level matrix.draw() function and raw pixel bitmaps (104-byte arrays defining pixel brightness on a 0–7 scale), the matrix renders crisp, bright arrows (▲, ▼, <, >) in real-time corresponding to the active drive direction.

By strictly utilizing the native libraries of the Arduino App Lab ecosystem (arduino.app_bricks.web_ui and Arduino_LED_Matrix), this solution boasts exceptional stability:It completely eliminates compilation errors related to memory pointer casting during array parsing.It ensures total offline independence – the robot operates entirely within a local Wi-Fi network.The codebase serves as a production-ready template for Smart Assist EV applications and autonomous inspection platforms.

To run the entire system, you need an external USB hub with a USB-C plug that connects to the Arduino Uno Q, featuring USB-C Power Delivery ports and USB 2.0 or USB 3.0 ports to connect a USB camera.

I tested several cameras. Unfortunately, some of them do not work properly with the Arduino Q. Despite my efforts, I could not get the rather old Megapixel USB2 Webcam Live WB-5400 - 15007 (which runs on USB 2.0) to work. The project uses a 3-in-1 Waterproof USB Endoscope Inspection Camera. The integrated ultra-bright LEDs and 1200P HD camera make it able to present images with a color effect while retaining high resolution and quality even in dark places. In addition, the lens is equipped with automatic exposure and blue light technology, which can effectively filter stray light, restore real scenes, and make images clearer.

A web page containing a camera feed along with a joystick can be displayed on a computer or a mobile device. This offers tremendous possibilities for the user, allowing them to control the vehicle not only locally from an apartment but also remotely. The view of the page is shown in the image. After refreshing the page in your phone/computer browser: Below the video window, you will see a dark gray circle with a dashed light blue border. When you click or tap inside this circle, a light blue, movable joystick will immediately appear there, allowing you to control the vehicle.

The image below shows the website running on a smartphone. As you can see, there's no need to create and install a dedicated app—a standard web browser will suffice.

For diagnostic purposes, the built-in LEDs on the Arduino Uno board were used to indicate the vehicle's status: a lit blue LED indicates turning left or right, green indicates moving forward, and red indicates moving backward. Additionally, the matrix display shows arrows indicating the direction in which the vehicle is moving.

community.element14.com/.../SmartAssist-EV.mp4

You can also watch a video showing how the website works on YouTube:
https://www.youtube.com/watch?v=E3mmpFuwCU4

Firmware Implementation: Motor Control and RPC Communication

1. Libraries and System Architecture

#include <Arduino_RouterBridge.h> // Official RPC header for Uno Q
#include <Arduino_LED_Matrix.h>   // 8x13 Matrix library

Arduino_LED_Matrix matrix; // Initialize the LED matrix

    <Arduino_RouterBridge.h>: The official Remote Procedure Call (RPC) library for the Arduino UNO Q. It establishes a communication bridge between the microcontroller unit (MCU) running C++ and the Linux host system running Python (main.py).

    <Arduino_LED_Matrix.h>: The library used to control the built-in 8×13 LED matrix display.

    Arduino_LED_Matrix matrix;: Instantiates the matrix driver object to draw graphical frames.

2. Pin Mapping and Constants

// Motor pin definitions for Elecrow kit (H-bridges)
const int MOTOR_L_F = 4;
const int MOTOR_L_B = 5;
const int MOTOR_R_F = 6;
const int MOTOR_R_B = 7;

const uint8_t FRAME_SIZE = 8 * 13; // 104 pixels

    Motor Pins:

        MOTOR_L_F (Pin 4) & MOTOR_L_B (Pin 5): Left motor forward and backward channels.

        MOTOR_R_F (Pin 6) & MOTOR_R_B (Pin 7): Right motor forward and backward channels.

    FRAME_SIZE = 8 * 13: Defines the total pixel array size (104 pixels) for the LED matrix.

3. LED Matrix Graphic Data Arrays

// 1. UP ARROW (FORWARD)
uint8_t arrow_up[FRAME_SIZE] = {
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 7, 7, 7, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 7, 7, 7, 7, 7, 0, 0, 0, 0,
    0, 0, 0, 7, 7, 0, 7, 0, 7, 7, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0
};

// 5. CLEAR DISPLAY (STOP)
uint8_t stop_icon[FRAME_SIZE] = { 0 }; // All pixels off (value 0)

Four 1D byte arrays (arrow_up, arrow_down, arrow_left, arrow_right) and one blank array (stop_icon) represent visual icons.
Grayscale Value Mapping: Each index corresponds to one pixel. Values range from 0 (LED completely off) to 7 (maximum LED brightness).
The visual layout inside the code mimics the 8×13 grid structure to visualize arrow shapes directly in the source file.

4. Helper Functions

set_led4_color(bool r, bool g, bool b)

// Function controlling the built-in LED4 using inverted logic
void set_led4_color(bool r, bool g, bool b) {
  digitalWrite(LED4_R, r ? LOW : HIGH);
  digitalWrite(LED4_G, g ? LOW : HIGH);
  digitalWrite(LED4_B, b ? LOW : HIGH);
}

Controls the onboard RGB LED (LED4).
Active-Low Logic: The pins use inverted logic. Setting a pin to LOW turns the corresponding color component ON, whereas setting it to HIGH turns it OFF (handled via ternary operators r ? LOW : HIGH).

move_robot_mcu(String direction)

// Function receiving commands from the web page (via RPC bridge)
void move_robot_mcu(String direction) {
  if (direction == "F") { // FORWARD
    digitalWrite(MOTOR_L_F, HIGH); digitalWrite(MOTOR_R_F, HIGH);
    digitalWrite(MOTOR_L_B, LOW);  digitalWrite(MOTOR_R_B, LOW);
    
    set_led4_color(false, true, false); // GREEN
    matrix.draw(arrow_up);               // Display up arrow
  } 
  else if (direction == "B") { // BACKWARD
    digitalWrite(MOTOR_L_F, LOW);  digitalWrite(MOTOR_R_F, LOW);
    digitalWrite(MOTOR_L_B, HIGH); digitalWrite(MOTOR_R_B, HIGH);
    
    set_led4_color(true, false, false); // RED
    matrix.draw(arrow_down);             // Display down arrow
  } 
  // ... (additional conditions for "L" and "R")
  else { // STOP ("S")
    digitalWrite(MOTOR_L_F, LOW);  digitalWrite(MOTOR_L_B, LOW);
    digitalWrite(MOTOR_R_F, LOW);  digitalWrite(MOTOR_R_B, LOW);
    
    set_led4_color(false, false, false); // Turn off RGB LED
    matrix.draw(stop_icon);               // Clear LED matrix
  }
}

The primary execution function triggered via the RPC bridge. It handles drive state, RGB lighting, and matrix rendering simultaneously:

Input Signal	Action	H-Bridge Motor Pin States	RGB Color	Matrix Graphic
`"F"`	Forward	`L_F: HIGH`, `R_F: HIGH`, `L_B: LOW`, `R_B: LOW`	Green	`arrow_up`
`"B"`	Backward	`L_F: LOW`, `R_F: LOW`, `L_B: HIGH`, `R_B: HIGH`	Red	`arrow_down`
`"L"`	Spin Left	`L_F: LOW`, `R_F: HIGH`, `L_B: HIGH`, `R_B: LOW`	Blue	`arrow_left`
`"R"`	Spin Right	`L_F: HIGH`, `R_F: LOW`, `L_B: LOW`, `R_B: HIGH`	Blue	`arrow_right`
Else / `"S"`	Stop	All motor pins `LOW`	Off	`stop_icon` (Clear)

5. Program Initialization (`setup`)

void setup() {
  // Initialize onboard RGB LED4
  pinMode(LED4_R, OUTPUT);
  pinMode(LED4_G, OUTPUT);
  pinMode(LED4_B, OUTPUT);
  set_led4_color(false, false, false);

  // Initialize matrix hardware
  matrix.begin();
  matrix.setGrayscaleBits(3); // Brightness levels from 0 to 7
  matrix.clear();

  // Start the official Linux communication bridge (main.py)
  Bridge.begin();
  Bridge.provide("drive", move_robot_mcu); 
  
  // Initialize motor H-bridge control pins
  pinMode(MOTOR_L_F, OUTPUT); pinMode(MOTOR_L_B, OUTPUT);
  pinMode(MOTOR_R_F, OUTPUT); pinMode(MOTOR_R_B, OUTPUT);
  
  move_robot_mcu("S"); // Initial state (Vehicle stopped, matrix cleared)
}

RGB LED Setup: Configures LED4_R, LED4_G, and LED4_B as output pins and initializes them to an off state.

Matrix Initialization: Starts the display hardware using matrix.begin(), sets brightness resolution to 3 bits (0-7 scale) via matrix.setGrayscaleBits(3), and clears any leftover pixels.

RPC Bridge Exposure:
Bridge.begin() starts the Linux-MCU communication.
Bridge.provide("drive", move_robot_mcu); registers the move_robot_mcu function under the RPC service name "drive". This allows external Linux scripts or web applications to execute this C++ function remotely over RPC.
Motor Pin Modes: Sets all motor control pins as outputs and enforces an initial STOP state (move_robot_mcu("S")).

6. Main Execution Loop (loop)

void loop() {
  // Empty loop - RPC command handling occurs automatically in the background
  delay(10);
}

The loop() body is intentionally kept empty, containing only a small delay (delay(10)).
Asynchronous Execution: Incoming commands sent from a smartphone, web interface, or Python script are handled in the background by the Arduino_RouterBridge middleware without blocking the main program thread.

Here is the complete project, fully adapted to the native environment of Arduino App Lab, configured for the Elecrow car kit.

1. Microcontroller Code (sketch.ino)

Upload this code to the MCU section. It handles the H-bridge motors, the LED4 RGB status light, and renders the arrows using the native matrix.draw() function when an RPC command arrives from the webpage.

Below is the basic code that allows you to control the vehicle through a web application.

#include <Arduino_RouterBridge.h> // Official RPC header for Uno Q
#include <Arduino_LED_Matrix.h>   // 8x13 matrix library

Arduino_LED_Matrix matrix; // Initialize the large matrix

// Motor pin definitions for the Elecrow kit (H-bridges)
const int MOTOR_L_F = 4;
const int MOTOR_L_B = 5;
const int MOTOR_R_F = 6;
const int MOTOR_R_B = 7;

const uint8_t FRAME_SIZE = 8 * 13; // 104 pixels

// 1. UP ARROW (FORWARD)
uint8_t arrow_up[FRAME_SIZE] = {
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 7, 7, 7, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 7, 7, 7, 7, 7, 0, 0, 0, 0,
    0, 0, 0, 7, 7, 0, 7, 0, 7, 7, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0
};

// 2. DOWN ARROW (BACKWARD)
uint8_t arrow_down[FRAME_SIZE] = {
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 7, 7, 0, 7, 0, 7, 7, 0, 0, 0,
    0, 0, 0, 0, 7, 7, 7, 7, 7, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 7, 7, 7, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0
};

// 3. LEFT ARROW
uint8_t arrow_left[FRAME_SIZE] = {
    0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 7, 7, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
    0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
    0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
    0, 0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
    0, 0, 0, 7, 7, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0, 0, 0
};

// 4. RIGHT ARROW
uint8_t arrow_right[FRAME_SIZE] = {
    0, 0, 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0, 7, 7, 0, 0, 0,
    7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0, 0,
    7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0,
    7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0,
    7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0, 7, 7, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0
};

// 5. CLEAR DISPLAY (STOP)
uint8_t stop_icon[FRAME_SIZE] = { 0 }; // All pixels off (value 0)

// Function controlling the built-in LED4 using inverted logic
void set_led4_color(bool r, bool g, bool b) {
  digitalWrite(LED4_R, r ? LOW : HIGH);
  digitalWrite(LED4_G, g ? LOW : HIGH);
  digitalWrite(LED4_B, b ? LOW : HIGH);
}

// Function receiving commands from the web page (via RPC bridge)
void move_robot_mcu(String direction) {
  if (direction == "F") { // FORWARD
    digitalWrite(MOTOR_L_F, HIGH); digitalWrite(MOTOR_R_F, HIGH);
    digitalWrite(MOTOR_L_B, LOW);  digitalWrite(MOTOR_R_B, LOW);
    
    set_led4_color(false, true, false); // GREEN
    matrix.draw(arrow_up);               // Display up arrow
  } 
  else if (direction == "B") { // BACKWARD
    digitalWrite(MOTOR_L_F, LOW);  digitalWrite(MOTOR_R_F, LOW);
    digitalWrite(MOTOR_L_B, HIGH); digitalWrite(MOTOR_R_B, HIGH);
    
    set_led4_color(true, false, false); // RED
    matrix.draw(arrow_down);             // Display down arrow
  } 
  else if (direction == "L") { // LEFT
    digitalWrite(MOTOR_L_F, LOW);  digitalWrite(MOTOR_R_F, HIGH);
    digitalWrite(MOTOR_L_B, HIGH); digitalWrite(MOTOR_R_B, LOW);
    
    set_led4_color(false, false, true); // BLUE
    matrix.draw(arrow_left);             // Display left arrow
  } 
  else if (direction == "R") { // RIGHT
    digitalWrite(MOTOR_L_F, HIGH); digitalWrite(MOTOR_R_F, LOW);
    digitalWrite(MOTOR_L_B, LOW);  digitalWrite(MOTOR_R_B, HIGH);
    
    set_led4_color(false, false, true); // BLUE
    matrix.draw(arrow_right);            // Display right arrow
  } 
  else { // STOP ("S")
    digitalWrite(MOTOR_L_F, LOW);  digitalWrite(MOTOR_L_B, LOW);
    digitalWrite(MOTOR_R_F, LOW);  digitalWrite(MOTOR_R_B, LOW);
    
    set_led4_color(false, false, false); // Turn off RGB LED
    matrix.draw(stop_icon);               // Clear LED matrix
  }
}

void setup() {
  // Initialize built-in LED4
  pinMode(LED4_R, OUTPUT);
  pinMode(LED4_G, OUTPUT);
  pinMode(LED4_B, OUTPUT);
  set_led4_color(false, false, false);

  // Initialize the matrix exactly as in the working example
  matrix.begin();
  matrix.setGrayscaleBits(3); // Brightness levels from 0 to 7
  matrix.clear();

  // Start the official communication bridge with Linux (main.py)
  Bridge.begin();
  Bridge.provide("drive", move_robot_mcu); 
  
  // Initialize control pins for motor H-bridges
  pinMode(MOTOR_L_F, OUTPUT); pinMode(MOTOR_L_B, OUTPUT);
  pinMode(MOTOR_R_F, OUTPUT); pinMode(MOTOR_R_B, OUTPUT);
  
  move_robot_mcu("S"); // Initial state (Vehicle stopped, matrix off)
}

void loop() {
  // Empty loop - handling RPC commands from the phone happens automatically in the background
  delay(10);
}

After adding sensors, the code that additionally implements obstacle detection is as follows:

#include <Arduino.h>
#include <Arduino_RouterBridge.h> // Official RPC header for Uno Q
#include <Arduino_LED_Matrix.h>   // Library for the 8x13 LED matrix

Arduino_LED_Matrix matrix; // Initialize the large LED matrix

// --- HARDWARE PIN CONFIGURATION ---
const int motorPinA_1A = 5; 
const int motorPinA_1B = 6; 
const int motorPinB_1A = 9; 
const int motorPinB_1B = 10;

const int IR_RECEIVE_PIN = 2; 
const int trigPin = 4; 
const int echoPin = 3; 

// Physical Tactile Bumpers
const int CollisionPin_L = 18; // Pin A4
const int CollisionPin_R = 19; // Pin A5

// Line Tracking Photo-interrupters
const int TrackingPin_L = A2;
const int TrackingPin_R = A3;

// --- ROBOT PARAMETERS AND MODES ---
enum RobotMode { MODE_MANUAL, MODE_AUTONOMOUS };
RobotMode currentMode = MODE_MANUAL; 

const int motorSpeed = 200; 
int spd = 195; // Specific heavy escape/evasive speed vector
int trackSpeed = 160; // Optimized track following velocity for Uno Q

unsigned long lastCommandTime = 0;
const unsigned long commandTimeout = 250;
const uint8_t FRAME_SIZE = 8 * 13; // 104 pixels for the LED matrix
byte lastCommand = 0;

// --- LED MATRIX ARROW ARRAYS (Brightness levels 0-7) ---
uint8_t arrow_up[FRAME_SIZE] = {
 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
 0, 0, 0, 0, 0, 7, 7, 7, 0, 0, 0, 0, 0,
 0, 0, 0, 0, 7, 7, 7, 7, 7, 0, 0, 0, 0,
 0, 0, 0, 7, 7, 0, 7, 0, 7, 7, 0, 0, 0,
 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0
};
uint8_t arrow_down[FRAME_SIZE] = {
 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
 0, 0, 0, 7, 7, 0, 7, 0, 7, 7, 0, 0, 0,
 0, 0, 0, 0, 7, 7, 7, 7, 7, 0, 0, 0, 0,
 0, 0, 0, 0, 0, 7, 7, 7, 0, 0, 0, 0, 0,
 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0
};
uint8_t arrow_left[FRAME_SIZE] = {
 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0, 0, 0,
 0, 0, 0, 7, 7, 0, 0, 0, 0, 0, 0, 0, 0,
 0, 0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
 0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
 0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
 0, 0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
 0, 0, 0, 7, 7, 0, 0, 0, 0, 0, 0, 0, 0,
 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0, 0, 0
};
uint8_t arrow_right[FRAME_SIZE] = {
 0, 0, 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0,
 0, 0, 0, 0, 0, 0, 0, 0, 7, 7, 0, 0, 0,
 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0, 0,
 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0,
 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0,
 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0, 0,
 0, 0, 0, 0, 0, 0, 0, 0, 7, 7, 0, 0, 0,
 0, 0, 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0
};
uint8_t stop_icon[FRAME_SIZE] = { 0 }; 

// --- ONBOARD RGB LED CONTROL FUNCTIONS ---
void set_led3_color(int r, int g, int b) {
 analogWrite(LED3_R, r);
 analogWrite(LED3_G, g);
 analogWrite(LED3_B, b);
}
void set_led4_color(bool r, bool g, bool b) {
 digitalWrite(LED4_R, r ? LOW : HIGH);
 digitalWrite(LED4_G, g ? LOW : HIGH);
 digitalWrite(LED4_B, b ? LOW : HIGH);
}

// --- MOTOR DRIVE DRIVER ---
void motor(int A1, int A2, int B1, int B2) {
 analogWrite(motorPinA_1A, A1);
 analogWrite(motorPinA_1B, A2);
 analogWrite(motorPinB_1A, B1);
 analogWrite(motorPinB_1B, B2);
}

// --- NATIVE IR DECODER FOR ARDUINO UNO Q ---
long readElecrowIR() {
  int count = 0;
  while (digitalRead(IR_RECEIVE_PIN) == LOW && count < 200) {
    count++;
    delayMicroseconds(60);
  }
  if (count >= 200) return -1;

  count = 0;
  while (digitalRead(IR_RECEIVE_PIN) == HIGH && count < 80) {
    count++;
    delayMicroseconds(60);
  }
  if (count >= 80) return -1;

  int idx = 0;
  int cnt = 0;
  byte data[4] = {0, 0, 0, 0}; 

  for (int i = 0; i < 32; i++) {
    count = 0;
    while (digitalRead(IR_RECEIVE_PIN) == LOW && count < 15) {
      count++;
      delayMicroseconds(60);
    }
    count = 0;
    while (digitalRead(IR_RECEIVE_PIN) == HIGH && count < 40) {
      count++;
      delayMicroseconds(60);
    }
    if (count > 8) {
      data[idx] |= (1 << cnt);
    }
    if (cnt == 7) {
      cnt = 0;
      idx++;
    } else {
      cnt++;
    }
  }

  if ((byte)(data[0] + data[1]) == 0xFF && (byte)(data[2] + data[3]) == 0xFF) { 
    return data[2]; 
  }
  return -1;
}

// --- WEB INTERFACE INTERCEPTOR (FIXED: Changed argument type to String) ---
void move_robot_mcu(String direction) {
 if (currentMode != MODE_MANUAL) return; 
 
 if (direction == "F") { 
 motor(0, motorSpeed, 0, motorSpeed);
 set_led4_color(false, true, false); 
 set_led3_color(0, 200, 0); 
 matrix.draw(arrow_up);
 } 
 else if (direction == "B") { 
 motor(motorSpeed, 0, motorSpeed, 0);
 set_led4_color(true, false, false); 
 set_led3_color(200, 0, 0); 
 matrix.draw(arrow_down);
 }
 else if (direction == "L") { 
 motor(motorSpeed, 0, 0, motorSpeed);
 set_led4_color(false, false, true); 
 set_led3_color(0, 0, 200); 
 matrix.draw(arrow_left);
 } 
 else if (direction == "R") { 
 motor(0, motorSpeed, motorSpeed, 0);
 set_led4_color(false, false, true); 
 set_led3_color(0, 0, 200); 
 matrix.draw(arrow_right);
 } 
 else { 
 motor(0, 0, 0, 0);
 set_led4_color(false, false, false); 
 set_led3_color(0, 0, 0);
 matrix.draw(stop_icon);
 }
}

float getDistance() {
 digitalWrite(trigPin, LOW);
 delayMicroseconds(2);
 digitalWrite(trigPin, HIGH);
 delayMicroseconds(10);
 digitalWrite(trigPin, LOW);
 
 long duration = pulseIn(echoPin, HIGH, 30000); 
 float d = duration * 0.0343 / 2;
 if (d == 0) return 999.0; 
 return d;
}

// --- WEB MODE TOGGLE (FIXED: Changed argument type to String) ---
void toggle_mode_from_web(String cmd) {
 if (currentMode == MODE_MANUAL) {
 currentMode = MODE_AUTONOMOUS;
 set_led3_color(200, 200, 0); 
 Serial.println("System Notification: AUTONOMY MODE ENGAGED VIA WEB.");
 } else {
 currentMode = MODE_MANUAL;
 motor(0, 0, 0, 0); 
 set_led3_color(0, 0, 0);
 matrix.draw(stop_icon);
 Serial.println("System Notification: MANUAL OVERRIDE ENGAGED VIA WEB.");
 }
}

void exec_cmd(byte key_val) {
 switch (key_val) {
 case 0x1C: 
 if (currentMode == MODE_MANUAL) {
 currentMode = MODE_AUTONOMOUS;
 set_led3_color(200, 200, 0);
 Serial.println("System Notification: AUTONOMY MODE ENGAGED.");
 } else {
 currentMode = MODE_MANUAL;
 motor(0, 0, 0, 0); 
 set_led3_color(0, 0, 0);
 matrix.draw(stop_icon);
 Serial.println("System Notification: MANUAL OVERRIDE ENGAGED.");
 }
 lastCommand = 0;
 delay(500);
 break;
 case 0x18: if (currentMode == MODE_MANUAL) { motor(0, motorSpeed, 0, motorSpeed); matrix.draw(arrow_up); } break;
 case 0x08: if (currentMode == MODE_MANUAL) { motor(motorSpeed, 0, 0, motorSpeed); matrix.draw(arrow_left); } break;
 case 0x5A: if (currentMode == MODE_MANUAL) { motor(0, motorSpeed, motorSpeed, 0); matrix.draw(arrow_right); } break;
 case 0x52: if (currentMode == MODE_MANUAL) { motor(motorSpeed, 0, motorSpeed, 0); matrix.draw(arrow_down); } break;
 default: if (currentMode == MODE_MANUAL) { motor(0, 0, 0, 0); matrix.draw(stop_icon); } break;
 }
}

void setup() {
 Serial.begin(115200);
 
 pinMode(IR_RECEIVE_PIN, INPUT_PULLUP); 
 pinMode(trigPin, OUTPUT);
 pinMode(echoPin, INPUT);
 pinMode(CollisionPin_L, INPUT); 
 pinMode(CollisionPin_R, INPUT);
 pinMode(TrackingPin_L, INPUT_PULLUP);
 pinMode(TrackingPin_R, INPUT_PULLUP);
 
 pinMode(LED4_R, OUTPUT); pinMode(LED4_G, OUTPUT); pinMode(LED4_B, OUTPUT);
 set_led3_color(0, 0, 0);
 set_led4_color(false, false, false);
 matrix.begin();
 matrix.setGrayscaleBits(3);
 matrix.clear();
 
 // --- RPC BRIDGE REGISTRATION ---
 Bridge.begin();
 Bridge.provide("drive", move_robot_mcu); 
 Bridge.provide("toggle_mode", toggle_mode_from_web);
  
 Serial.println("System Core Ready.");
}

void loop() {
  // 1. IR Remote control handling
  if (digitalRead(IR_RECEIVE_PIN) == LOW) {
    long result = readElecrowIR();
    if (result != -1) {
      lastCommand = (byte)result;
      exec_cmd(lastCommand);
      if (currentMode == MODE_MANUAL) lastCommandTime = millis();
    }
  }

  // 2. Motion modes execution logic
  if (currentMode == MODE_MANUAL) {
    if (digitalRead(IR_RECEIVE_PIN) == HIGH) {
      if (millis() - lastCommandTime > commandTimeout) {
        motor(0, 0, 0, 0);
      }
    } else {
      exec_cmd(lastCommand);
    }
  } 
  else if (currentMode == MODE_AUTONOMOUS) {
    float distance = getDistance();
    int sumVal = (digitalRead(CollisionPin_L) == HIGH ? 1 : 0) * 2 + (digitalRead(CollisionPin_R) == HIGH ? 1 : 0);
    
    // --- HIERARCHY 1: Physical Bumpers ---
    if (sumVal > 0) {
      Serial.print("TACTILE COLLISION TRIGGERED. Code: ");
      Serial.println(sumVal);
      matrix.draw(stop_icon);
      
      if (sumVal == 1) { 
        motor(spd, 0, spd, 0); delay(2000);
        motor(spd, 0, 0, spd); delay(2000);
      }
      else if (sumVal == 2) { 
        motor(spd, 0, spd, 0); delay(2000);
        motor(0, spd, spd, 0); delay(2000);
      }
      else if (sumVal == 3) { 
        motor(spd, 0, spd, 0); delay(2000);
        motor(spd, 0, 0, spd); delay(2000);
      }
    }
    // --- HIERARCHY 2: Ultrasonic Sensor (Sonar) ---
    else if (distance < 30) {
      matrix.draw(arrow_left);
      motor(motorSpeed, 0, 0, motorSpeed); 
      delay(300);
    }
    // --- HIERARCHY 3: Line Tracking ---
    else {
      int trackL = digitalRead(TrackingPin_L);
      int trackR = digitalRead(TrackingPin_R);
      int Track = trackL * 2 + trackR;
      
      switch (Track) {
        case 0: 
          motor(0, 0, 0, 0); 
          matrix.draw(stop_icon); 
          break;
        case 1: 
          motor(0, trackSpeed, trackSpeed, 0); 
          matrix.draw(arrow_right); 
          break;
        case 2: 
          motor(trackSpeed, 0, 0, trackSpeed); 
          matrix.draw(arrow_left); 
          break;
        case 3: 
          motor(0, trackSpeed, 0, trackSpeed); 
          matrix.draw(arrow_up); 
          break;
      }
      delay(10);
    }
  }
  Bridge.update(); 
}

2. Python Web Server (main.py)

Save this to the MPU/Python editor. It initializes your USB camera, acts as the API backend for your local interface touch events, and redirects commands to the MCU code.

from arduino.app_utils import *
from arduino.app_bricks.web_ui import WebUI
from arduino.app_peripherals.camera import Camera

# Initialize the onboard USB camera module
camera = Camera(resolution=(640, 480), fps=15)  
ui = WebUI()
camera.start()

# API endpoint executed when a drag action occurs on the webpage
def handle_joystick(data: dict):
    char_cmd = data.get('cmd', 'S')
    # Forward command directly to the registered C++ function
    Bridge.call("drive", char_cmd)
    return {"status": "ok"}

# Expose API and camera routes to App Lab web interface
ui.expose_api("POST", "/api/move", handle_joystick)
ui.expose_camera("/camera", camera)

App.run()

3. Local Dashboard UI (assets/index.html)

Save this code to your index.html inside your project's assets directory. It renders a clean grid, displays your camera stream, and tracks touch drags or mouse movements inside a virtual joystick container without needing internet-based libraries.

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Uno Q Robot Dashboard</title>
    <style>
      body { font-family: Arial, sans-serif; text-align: center; background: #111; color: #fff; margin: 0; padding: 10px; }
      #control-pad { width: 220px; height: 220px; background: #222; border-radius: 50%; margin: 25px auto; position: relative; border: 3px dashed #00ffcc; touch-action: none; }
      img { border: 4px solid #00ffcc; border-radius: 12px; max-width: 100%; height: auto; display: block; margin: 0 auto; }
      .status { font-weight: bold; color: #00ffcc; font-size: 1.2em; }
    </style>
  </head>
  <body>
    <h1>Uno Q Vehicle Control System</h1>
    <div>
      <img src="/camera" />
    </div>
    
    <div id="control-pad"></div>
    <p>Drag your finger or mouse inside the circle to move the robot</p>
    <p>Status: <span id="status-val" class="status">STOP</span></p>

    <script>
      const pad = document.getElementById('control-pad');
      const statusText = document.getElementById('status-val');
      let isMoving = false;
      let lastDirection = "S";
      let lastSend = 0;

      // Create a visual handle inside the control pad area
      const knob = document.createElement('div');
      knob.style.width = '60px'; knob.style.height = '60px'; knob.style.background = '#00ffcc';
      knob.style.borderRadius = '50%'; knob.style.position = 'absolute';
      knob.style.left = '80px'; knob.style.top = '80px'; knob.style.pointerEvents = 'none';
      pad.appendChild(knob);

      function startAction() { isMoving = true; }

      function moveAction(e) {
        if (!isMoving) return;
        e.preventDefault();
        
        const rect = pad.getBoundingClientRect();
        const input = e.touches ? e.touches[0] : e;
        
        const centerX = rect.width / 2;
        const centerY = rect.height / 2;
        
        let x = input.clientX - rect.left - centerX;
        let y = input.clientY - rect.top - centerY;
        
        const distance = Math.sqrt(x*x + y*y);
        if (distance > 80) {
          x = (x / distance) * 80;
          y = (y / distance) * 80;
        }
        
        knob.style.transform = `translate(${x}px, ${y}px)`;

        if (Date.now() - lastSend < 70) return;
        
        let cmd = "S";
        if (Math.abs(x) > Math.abs(y)) {
          cmd = x > 25 ? "R" : (x < -25 ? "L" : "S");
        } else {
          cmd = y > 25 ? "B" : (y < -25 ? "F" : "S");
        }

        if (cmd !== lastDirection) {
          lastDirection = cmd;
          lastSend = Date.now();
          
          const names = {"F": "FORWARD ▲", "B": "BACKWARD ▼", "L": "LEFT Arrow backward", "R": "RIGHT Arrow forward", "S": "STOP"};
          statusText.innerText = names[cmd];
          
          sendCmd(cmd);
        }
      }

      function endAction() {
        isMoving = false;
        knob.style.transform = 'translate(0px, 0px)';
        if (lastDirection !== "S") {
          lastDirection = "S";
          statusText.innerText = "STOP";
          sendCmd("S");
        }
      }

      pad.addEventListener('mousedown', startAction);
      window.addEventListener('mousemove', moveAction);
      window.addEventListener('mouseup', endAction);

      pad.addEventListener('touchstart', startAction);
      window.addEventListener('touchmove', moveAction, { passive: false });
      window.addEventListener('touchend', endAction);

      function sendCmd(character) {
        fetch('/api/move', {
          method: 'POST',
          headers: { 'Content-Type': 'application/json' },
          body: JSON.stringify({ cmd: character })
        }).catch(err => console.log(err));
      }
    </script>
  </body>
</html>

The Master Blueprint, The Integration Wall, and Mechanical Realities

UlolKidz — Sun, 16 Aug 2026 23:42:58 GMT

Welcome to the penultimate post for Project GEPARD V5.0. Before I publish the final project summary and overall review for the Element14 EZ-EV Challenge, I need to take a massive step back and be completely honest about the realities of building an autonomous UGV from scratch.

If there is one overarching takeaway from this entire experience, it is this: compared to the veteran engineers on this forum, I am at the absolute bottom of the robotics learning curve. I took on a project that required a deep understanding of mechanical stress distribution, software abstraction layers, and electrical routing. My biggest mistake wasn't my ambition—it was my isolation. I should have asked this community for help far more often. You all have decades of experience, and my stubbornness to brute-force my way through debugging cost me days of progress.

This build taught me an incredible amount, but it was an absolute trial by fire. Here is my candid retrospective on my master blueprint, the mechanical flaws that emerged under load, the software walls I hit, and the hardware that didn't survive the journey.

The Master Blueprint and the "Rung" System

When I started Project GEPARD, I knew I was building something complex, so I tried to be as disciplined as possible. I didn't want to build a static toy; I wanted to build a modular autonomous IoT rover that could be used as a testbed for operational analytics.

To prevent myself from getting overwhelmed by scope creep, I architected a strict PMO (Project Management Office) Gate System to lock my progress. I broke the build down into specific, non-negotiable rungs:

* Rung 1 (The True MVP): Motor validation to simply make the wheels spin using the UNO Q, TB6612 motor driver, and the battery.

* Rung 2 & 3: Establishing basic communication tests and manual WASD UDP control from the PC to the rover.

* Rung 4 & 5: Completing the drive chain and separating the ESP32 camera as its own independent module.

I explicitly banned myself from writing code for auto-docking, YOLOv8 vision, or SLAM mapping during Build 1, pushing all of those features strictly into Phase 2.

However, a perfect paper blueprint does not survive contact with reality. Even though I was only trying to execute Rung 1 and Rung 2, I learned the hard way that theoretical planning is only half the battle. If you don't fully understand how each individual part interacts with the power bus and the logic board before you plug them all in, you will spend dozens of hours hopelessly debugging a tangled system. Integrating a multi-node system without testing component interactions individually creates a state where power, logic, and code bugs overlap.

Mechanical Forensics: Chassis Wear Under Load

Because I actually managed to get the chassis moving for testing, the physical realities of 3D-printed robotics quickly became apparent. Building a heavy, tracked FWD rover puts immense stress on plastic parts. Two major mechanical flaws revealed themselves over time:

1. Rear Axle Spacer Degradation

I initially designed and printed pipe-like cylindrical spacers on the rear axle to keep the idler wheels aligned. Under the heavy, constant friction of the flexible tracks, these pipe spacers ground down incredibly quickly. As they disintegrated, the rear axle developed a severe slant, which completely threw off the track tension. I learned that using flat, circular pads (like thick washers or shims) distributes the friction over a much larger surface area and prevents this rapid degradation.

2. Front Sprocket Inward Camber

Extended use of the rover highlighted a major stress-distribution issue at the front drive sprockets. Over time, the front shaft that connects the JGA25-370 motor to the drive wheel slowly caused the wheels to develop an inward camber (tilting in toward the chassis). The mechanical stress of the tracks pulling on the wheels migrated upwards, concentrating torque toward the roof of the axle housing. This progressively warped the alignment and caused the tracks to bind. FDM printing tolerances for tracked drivetrains require far more reinforcement at the motor mounting points than I originally calculated.

Software Abstractions: App Lab & The RouterBridge Black Box

Mechanically, despite the wear, the rover functioned. But getting the code to play nicely with the hardware was a completely different story.

My biggest bottleneck was the software environment itself. Working with the new Arduino App Lab introduced a whole layer of troubleshooting I wasn't prepared for. I experienced constant environment quirks where the App Lab interface would clearly state "Library Added," but when I went to compile the code, the compiler would throw fatal errors stating the module could not be found. I wasted critical hours fighting the IDE over module imports, phantom libraries, and compiling errors that had absolutely nothing to do with my actual logic.

The Arduino UNO Q is the hero component of this build, featuring an incredible dual-brain architecture. It utilizes an STM32U585 microcontroller alongside a Qualcomm QRB2210 Linux SBC. To get these two brains to talk to each other, you have to use a software protocol called the Arduino_RouterBridge.

I will be completely honest: I still have absolutely no idea how this Bridge actually works under the hood.

I successfully implemented the syntax to pass UDP strings from my Python base station script to the MCU. The Bridge.provide_safe and Bridge.notify commands worked syntactically to trigger motor functions and relay telemetry. But the actual underlying mechanics of how the Qualcomm chip parses and hands off that data to the STM32 chip is a complete black box to me. As someone coming from a Python and data analytics background rather than bare-metal C++ and RTOS, operating a system where I didn't truly understand the core communication protocol made debugging terrifying. Without deeper diagnostic tooling, I felt like I was flying blind.

The Hardware Graveyard (Failure Analysis)

Beyond the software and the plastic warping, the physical hardware took a massive beating during the integration phase. Three specific components failed during this project, and troubleshooting them consumed days of bench time:

1. The INA226 Telemetry Enigma

The INA226 was supposed to be the core of my operational analytics, continuously polling voltage on the 12V rail and current draw to track power consumption. The I2C address was explicitly hardcoded to 0x40 in the firmware, requiring the A0 and A1 pads to be tied to ground. But the Arduino simply could not find it.

To ensure I wasn't dealing with a logic level or software bug, I took a multimeter, set it to Diode Mode, and ran a reverse-bias test on the SDA and SCL pins. The multimeter read a 500mV drop across both data pins to ground, which definitively proved that the internal silicon diode structures of the logic chip were physically intact and alive. I verified the 3.3V logic supply to the VCC pin, yet the I2C bus remained completely dead, and the scanner returned a total failure.

The frustrating irony of the INA226 breakout board is that the massive physical shunt resistor still worked flawlessly. It continued to pass the full 11.3V battery power to the TB6612 motor driver's VM pin, allowing the rover to drive with full physical torque. It functioned perfectly as a "dumb" power bridge, but the data lines remained totally silent. I never solved this mystery.

2. The Dead MPU6050 IMU

Tracked vehicles inherently suffer from severe heading drift and skid-steer errors. Because of this, an IMU is highly recommended to improve dead reckoning and odometry. I integrated an MPU6050 on the I2C bus at address 0x68. Without warning, the chip simply died. Losing the MPU meant losing the foundation for any future phase of reliable grid mapping. It was a harsh reminder of how fragile cheap breakout boards can be.

3. The Fried Turret Servo

The GEPARD sensory turret relies on an MG90S micro metal-gear servo to actively pan the HC-SR04 ultrasonic sensors. During active testing of the sweeping logic on the bench, the servo just gave up and burned out. Whether it was a voltage spike, a mechanical bind in the 3D printed housing, or simply a defective factory unit, it forced me to completely tear down the SPAAG turret assembly and replace the actuation plant mid-build.

Moving Forward to the Finale

This project humbled me. It taught me the brutal realities of mechanical tolerances, the frustration of black-box software APIs, and the absolute necessity of step-by-step unit testing for hardware before chassis integration.

In the next and final post, I will be wrapping up Project GEPARD V5.0. I will showcase the final physical build, review the successes of the platform, and summarize my Element14 EZ-EV Challenge experience. Thank you to everyone on the forum who has followed along—I promise I will be leveraging your expertise much earlier on the next build!

AI disclaimer: Google Gemini was used to edit the posts wording, gramma and formatting.

SmartAssist EV - Strict Priority Hierarchy with Tactile Mechanical Bumpers - Part 6

jelektro — Sun, 16 Aug 2026 23:24:13 GMT

Project Roadmap

Part 1 - Experimental Smart Assistive Platform for Elderly and Disabled People

Part 2 - Hardware Platform

Part 3 - Wireless Command and H-Bridge Direct Drive

Part 4 - Introducing Autonomous Line Following (TCRT5000)

Part 5 - Non-Contact Proactive Shielding (HC-SR04 Range Finder)

Part 6 - Strict Priority Hierarchy with Tactile Mechanical Bumpers

Part 7 - Mobile Robot Control and Live Video Streaming

Ultrasonic sensors can miss low-profile objects, clear glass, or acoustic-absorbing fabrics. To handle these blind spots, we add physical Tactile Bumper Switches (CollisionPin_L, CollisionPin_R) as a final layer of defense.To manage all these inputs, the code uses a Strict Priority Hierarchy inside the core runtime evaluation loop:Priority 1 (Highest): Tactile Impact Check. If a physical collision is registered, the robot stops everything, backs up, and executes a wide turning maneuver.Priority 2 (Medium): Ultrasonic Proactive Clearance. If an object is detected within 30cm, the robot performs a quick corrective turn to avoid an accident.Priority 3 (Lowest): Standard Path Following. If both safety systems report a clear path, the robot continues tracking the line.

The full software build adds tactical mechanical bumper microswitches routed to pins A4 (18) and A5 (19). This program runs a rigorous hierarchy matrix: physical bumper triggers grab immediate absolute priority (initiating multi-second reversing maneuvers), sonar triggers handle medium-priority non-contact adjustments, while line following proceeds only when both safety nets report a clear path.

Here is the final, production-ready source architecture merging all four functional modules:

The primary addition is the support for physical collision sensors (bumpers) along with a 3-level safety hierarchy for handling obstacles.

1. Pin Definitions and Escape Speed

// Physical Tactile Bumpers (Mapped to pins A4 and A5 on Arduino)
const int COLLISION_PIN_L = 18; // Pin A4
const int COLLISION_PIN_R = 19; // Pin A5

const int ESCAPE_SPEED = 195; // Specific heavy escape/evasive speed vector
Explanation:
Added two new pins corresponding to the left (A4 / digital pin 18) and right (A5 / digital pin 19) physical collision microswitches/bumpers.
Defined ESCAPE_SPEED = 195, a dedicated motor speed used during longer backing-up and evasive maneuvers triggered by physical impacts.

2. Sensor Initialization in `setup()`

// Set as INPUT to match the original sponatenous logic of Elecrow modules
pinMode(COLLISION_PIN_L, INPUT);
pinMode(COLLISION_PIN_R, INPUT);
Explanation: Sets the bumper pins as standard digital inputs (INPUT). These modules send a high signal (HIGH / 1) to the pin when pressed.

3. Safety Hierarchy Logic in `loop()`

In autonomous mode (MODE_AUTONOMOUS), the code now executes operations based on a 3-level priority hierarchy:

Step 1: Read Bumper States (Binary Code)

int collisionState = (digitalRead(COLLISION_PIN_L) == HIGH ? 1 : 0) * 2 + (digitalRead(COLLISION_PIN_R) == HIGH ? 1 : 0);

Creates a bitwise variable collisionState with the following possible values:

0 – No collision.
1 – Right-side collision.
2 – Left-side collision.
3 – Central collision (both bumpers pressed).

Priority 1: Physical Impact Response (Bumpers)

This is the top priority, handling cases where the robot has physically made contact with an obstacle (e.g., an object below the ultrasonic beam):

if (collisionState > 0) {
  Serial.print("TACTILE COLLISION TRIGGERED. Code: ");
  Serial.println(collisionState);
  
  switch (collisionState) {
    case 1: // Right collision -> Reverse for 2s, then turn left for 2s
      driveMotors(ESCAPE_SPEED, 0, ESCAPE_SPEED, 0); delay(2000);
      driveMotors(ESCAPE_SPEED, 0, 0, ESCAPE_SPEED); delay(2000);
      break;
    case 2: // Left collision -> Reverse for 2s, then turn right for 2s
      driveMotors(ESCAPE_SPEED, 0, ESCAPE_SPEED, 0); delay(2000);
      driveMotors(0, ESCAPE_SPEED, ESCAPE_SPEED, 0); delay(2000);
      break;
    case 3: // Central collision -> Reverse for 2s, then perform U-turn (left) for 2s
      driveMotors(ESCAPE_SPEED, 0, ESCAPE_SPEED, 0); delay(2000);
      driveMotors(ESCAPE_SPEED, 0, 0, ESCAPE_SPEED); delay(2000);
      break;
  }
}

Behavior: Upon impact, the robot reverses for 2 seconds, then spins away from the side of impact for 2 seconds to clear the obstacle.

Priority 2: Proactive Distance Check (HC-SR04 Sonar)

If no physical collision occurred (collisionState == 0), the code checks the ultrasonic rangefinder:

else if (distance < 30.0) {
  Serial.println("Obstacle detected by Sonar! Turning left...");
  driveMotors(MOTOR_SPEED, 0, 0, MOTOR_SPEED); 
  delay(300);                                   
}

Behavior: If an obstacle is detected within 30 cm, the robot performs a short left turn 30ms to steer around the obstacle before physical contact happens.

Priority 3: Line Following Routine

If there is no physical impact and no obstacles within $30cm$ , the robot falls back to standard line tracking logic (else { ... }).

Final Code

Here is the complete, merged C program for the Arduino UNO Q, incorporating all features from all previous versions:

IR Remote Control
Line Tracking
HC-SR04 Ultrasonic Distance Sensor
Physical Tactile Collision Bumpers
Onboard RGB LED indicators (LED3 and LED4)
$8x13$ LED Matrix Display (displaying directional arrows and the STOP icon)

#include <Arduino.h>
#include <Arduino_LED_Matrix.h> // Library for the 8x13 LED matrix

Arduino_LED_Matrix matrix; // Initialize LED matrix object

// L9110S Motor Driver Pins
const int MOTOR_PIN_A1 = 5; 
const int MOTOR_PIN_A2 = 6; 
const int MOTOR_PIN_B1 = 9; 
const int MOTOR_PIN_B2 = 10;

// Infrared Receiver Pin
const int IR_RECEIVE_PIN = 2; 

// Line Tracking Sensor Pins
const int TRACKING_PIN_L = A2;
const int TRACKING_PIN_R = A3;

// Ultrasonic HC-SR04 Sonar Pins
const int TRIG_PIN = 4;      
const int ECHO_PIN = 3;      

// Physical Tactile Bumpers
const int COLLISION_PIN_L = 18; // Pin A4
const int COLLISION_PIN_R = 19; // Pin A5

enum RobotMode { 
  MODE_MANUAL, 
  MODE_AUTONOMOUS 
};

RobotMode currentMode = MODE_MANUAL; 

// Speed settings
const int MOTOR_SPEED = 200; 
const int ESCAPE_SPEED = 195; // Speed vector for escape maneuvers after collision
const int TRACK_SPEED = 160;  

byte lastCommand = 0;

// LED Matrix Frame Buffer Size (104 pixels)
const uint8_t FRAME_SIZE = 8 * 13;

// --- LED MATRIX ARROW & ICON ARRAYS (Brightness levels 0-7) ---
uint8_t arrow_up[FRAME_SIZE] = {
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 7, 7, 7, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 7, 7, 7, 7, 7, 0, 0, 0, 0,
    0, 0, 0, 7, 7, 0, 7, 0, 7, 7, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0
};

uint8_t arrow_down[FRAME_SIZE] = {
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 7, 7, 0, 7, 0, 7, 7, 0, 0, 0,
    0, 0, 0, 0, 7, 7, 7, 7, 7, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 7, 7, 7, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0
};

uint8_t arrow_left[FRAME_SIZE] = {
    0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 7, 7, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
    0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
    0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
    0, 0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
    0, 0, 0, 7, 7, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0, 0, 0
};

uint8_t arrow_right[FRAME_SIZE] = {
    0, 0, 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0, 7, 7, 0, 0, 0,
    7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0, 0,
    7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0,
    7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0,
    7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0, 7, 7, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0
};

uint8_t stop_icon[FRAME_SIZE] = { 0 }; 

// --- ONBOARD RGB LED FUNCTIONS ---
void set_led3_color(int r, int g, int b) {
  analogWrite(LED3_R, r);
  analogWrite(LED3_G, g);
  analogWrite(LED3_B, b);
}

void set_led4_color(bool r, bool g, bool b) {
  digitalWrite(LED4_R, r ? LOW : HIGH);
  digitalWrite(LED4_G, g ? LOW : HIGH);
  digitalWrite(LED4_B, b ? LOW : HIGH);
}

// Elecrow IR Decoder
long readElecrowIR() {
  int count = 0;
  while (digitalRead(IR_RECEIVE_PIN) == LOW && count < 200) { count++; delayMicroseconds(60); }
  if (count >= 200) return -1;

  count = 0;
  while (digitalRead(IR_RECEIVE_PIN) == HIGH && count < 80) { count++; delayMicroseconds(60); }
  if (count >= 80) return -1;

  int idx = 0, cnt = 0;
  byte data[4] = {0, 0, 0, 0};

  for (int i = 0; i < 32; i++) {
    count = 0;
    while (digitalRead(IR_RECEIVE_PIN) == LOW && count < 15) { count++; delayMicroseconds(60); }
    count = 0;
    while (digitalRead(IR_RECEIVE_PIN) == HIGH && count < 40) { count++; delayMicroseconds(60); }

    if (count > 8) data[idx] |= (1 << cnt);

    if (cnt == 7) { cnt = 0; idx++; } else { cnt++; }
  }

  if ((byte)(data[0] + data[1]) == 0xFF && (byte)(data[2] + data[3]) == 0xFF) {
    return data[2];
  }
  return -1;
}

void driveMotors(int a1, int a2, int b1, int b2) {
  analogWrite(MOTOR_PIN_A1, a1);
  analogWrite(MOTOR_PIN_A2, a2);
  analogWrite(MOTOR_PIN_B1, b1);
  analogWrite(MOTOR_PIN_B2, b2);
}

float getDistance() {
  digitalWrite(TRIG_PIN, LOW);
  delayMicroseconds(2);
  digitalWrite(TRIG_PIN, HIGH);
  delayMicroseconds(10);
  digitalWrite(TRIG_PIN, LOW);
  
  long duration = pulseIn(ECHO_PIN, HIGH, 30000); 
  float d = duration * 0.0343 / 2;
  
  if (d == 0) return 999.0;
  return d;
}

void executeCommand(byte command) {
  switch (command) {
    case 0x1C: // OK Button - Toggle Manual/Autonomous operations
      if (currentMode == MODE_MANUAL) { 
        currentMode = MODE_AUTONOMOUS; 
        digitalWrite(LED_BUILTIN, HIGH);
        Serial.println("System Notification: AUTONOMY MODE ENGAGED.");
      } 
      else { 
        currentMode = MODE_MANUAL; 
        digitalWrite(LED_BUILTIN, LOW);
        driveMotors(0, 0, 0, 0); 
        set_led4_color(false, false, false);
        set_led3_color(0, 0, 0);
        matrix.draw(stop_icon);
        Serial.println("System Notification: MANUAL OVERRIDE ENGAGED.");
      }
      lastCommand = 0; 
      delay(500);      
      break;

    case 0x18: // Forward
      if (currentMode == MODE_MANUAL) {
        driveMotors(0, MOTOR_SPEED, 0, MOTOR_SPEED);
        set_led4_color(false, true, false); // Green
        set_led3_color(0, 200, 0);
        matrix.draw(arrow_up);
      }
      break;

    case 0x08: // Spin Left
      if (currentMode == MODE_MANUAL) {
        driveMotors(MOTOR_SPEED, 0, 0, MOTOR_SPEED);
        set_led4_color(false, false, true); // Blue
        set_led3_color(0, 0, 200);
        matrix.draw(arrow_left);
      }
      break;

    case 0x5A: // Spin Right
      if (currentMode == MODE_MANUAL) {
        driveMotors(0, MOTOR_SPEED, MOTOR_SPEED, 0);
        set_led4_color(false, false, true); // Blue
        set_led3_color(0, 0, 200);
        matrix.draw(arrow_right);
      }
      break;

    case 0x52: // Backward
      if (currentMode == MODE_MANUAL) {
        driveMotors(MOTOR_SPEED, 0, MOTOR_SPEED, 0);
        set_led4_color(true, false, false); // Red
        set_led3_color(200, 0, 0);
        matrix.draw(arrow_down);
      }
      break;

    default:   
      if (currentMode == MODE_MANUAL) {
        driveMotors(0, 0, 0, 0);
        set_led4_color(false, false, false);
        set_led3_color(0, 0, 0);
        matrix.draw(stop_icon);
      }
      break;
  }
}

void setup() {
  Serial.begin(115200); 

  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite(LED_BUILTIN, LOW);

  pinMode(IR_RECEIVE_PIN, INPUT_PULLUP); 
  pinMode(TRACKING_PIN_L, INPUT_PULLUP);
  pinMode(TRACKING_PIN_R, INPUT_PULLUP);

  pinMode(TRIG_PIN, OUTPUT);
  pinMode(ECHO_PIN, INPUT);

  pinMode(COLLISION_PIN_L, INPUT);
  pinMode(COLLISION_PIN_R, INPUT);

  // RGB LED pin configuration
  pinMode(LED4_R, OUTPUT); 
  pinMode(LED4_G, OUTPUT); 
  pinMode(LED4_B, OUTPUT);
  set_led3_color(0, 0, 0);
  set_led4_color(false, false, false);

  // Initialize LED Matrix
  matrix.begin();
  matrix.setGrayscaleBits(3);
  matrix.clear();

  Serial.println("System Core Ready on Arduino UNO Q (IR + Line + Sonar + Bumpers + Display/LEDs).");
}

void loop() {
  // 1. Process incoming IR signals
  if (digitalRead(IR_RECEIVE_PIN) == LOW) {
    long result = readElecrowIR();
    if (result != -1) {
      lastCommand = (byte)result;
      executeCommand(lastCommand);
    }
  }

  // 2. Continuous Mode Execution
  if (currentMode == MODE_MANUAL) {
    if (digitalRead(IR_RECEIVE_PIN) == HIGH) {
      driveMotors(0, 0, 0, 0); 
      set_led4_color(false, false, false);
      set_led3_color(0, 0, 0);
      matrix.draw(stop_icon);
    } else {
      executeCommand(lastCommand);
    }
  } 
  else if (currentMode == MODE_AUTONOMOUS) {
    float distance = getDistance();
    int collisionState = (digitalRead(COLLISION_PIN_L) == HIGH ? 1 : 0) * 2 + (digitalRead(COLLISION_PIN_R) == HIGH ? 1 : 0);
    
    // --- HIERARCHY LEVEL 1: Physical Impact Interception (Bumpers) ---
    if (collisionState > 0) {
      Serial.print("TACTILE COLLISION TRIGGERED. Code: ");
      Serial.println(collisionState);
      
      set_led4_color(true, false, false); // Red alert
      set_led3_color(200, 0, 0);

      switch (collisionState) {
        case 1: // Right-side collision -> Reverse, then turn Left
          matrix.draw(arrow_down);
          driveMotors(ESCAPE_SPEED, 0, ESCAPE_SPEED, 0); delay(2000);
          matrix.draw(arrow_left);
          driveMotors(ESCAPE_SPEED, 0, 0, ESCAPE_SPEED); delay(2000);
          break;
        case 2: // Left-side collision -> Reverse, then turn Right
          matrix.draw(arrow_down);
          driveMotors(ESCAPE_SPEED, 0, ESCAPE_SPEED, 0); delay(2000);
          matrix.draw(arrow_right);
          driveMotors(0, ESCAPE_SPEED, ESCAPE_SPEED, 0); delay(2000);
          break;
        case 3: // Central collision -> Reverse, then U-Turn (Left)
          matrix.draw(arrow_down);
          driveMotors(ESCAPE_SPEED, 0, ESCAPE_SPEED, 0); delay(2000);
          matrix.draw(arrow_left);
          driveMotors(ESCAPE_SPEED, 0, 0, ESCAPE_SPEED); delay(2000);
          break;
      }
    } 
    // --- HIERARCHY LEVEL 2: Proactive Clearance Monitoring (HC-SR04 Sonar) ---
    else if (distance < 30.0) {
      Serial.println("Obstacle detected by Sonar! Turning left...");
      driveMotors(MOTOR_SPEED, 0, 0, MOTOR_SPEED); // Evade Left
      set_led4_color(true, false, false);          // Red warning
      set_led3_color(200, 0, 0);
      matrix.draw(arrow_left); 
      delay(300);                                  
    } 
    // --- HIERARCHY LEVEL 3: Standard Path Routine (Line Tracking) ---
    else {
      int trackL = digitalRead(TRACKING_PIN_L);
      int trackR = digitalRead(TRACKING_PIN_R);
      int trackState = (trackL * 2) + trackR; 
      
      switch (trackState) {
        case 0: // Off track -> Stop
          driveMotors(0, 0, 0, 0); 
          set_led4_color(false, false, false);
          set_led3_color(0, 0, 0);
          matrix.draw(stop_icon);
          break;

        case 1: // Right sensor active -> Turn Right
          driveMotors(0, TRACK_SPEED, TRACK_SPEED, 0); 
          set_led4_color(false, false, true); // Blue
          set_led3_color(0, 0, 200);
          matrix.draw(arrow_right);
          break;

        case 2: // Left sensor active -> Turn Left
          driveMotors(TRACK_SPEED, 0, 0, TRACK_SPEED); 
          set_led4_color(false, false, true); // Blue
          set_led3_color(0, 0, 200);
          matrix.draw(arrow_left);
          break;

        case 3: // Both sensors active -> Move Forward
          driveMotors(0, TRACK_SPEED, 0, TRACK_SPEED); 
          set_led4_color(false, true, false); // Green
          set_led3_color(0, 200, 0);
          matrix.draw(arrow_up);
          break;
      }
      delay(10); 
    }
  }
}

Project GEPARD V5.0 - Post 4: Proof of Concept Docking

UlolKidz — Sun, 16 Aug 2026 23:15:41 GMT

https://youtu.be/yx7YVVgXmXQ

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.

SmartAssist EV - Non-Contact Proactive Shielding (HC-SR04 Range Finder) - Part 5

jelektro — Sun, 16 Aug 2026 23:08:17 GMT

Project Roadmap

Part 1 - Experimental Smart Assistive Platform for Elderly and Disabled People

Part 2 - Hardware Platform

Part 3 - Wireless Command and H-Bridge Direct Drive

Part 4 - Introducing Autonomous Line Following (TCRT5000)

Part 5 - Non-Contact Proactive Shielding (HC-SR04 Range Finder)

Part 6 - Strict Priority Hierarchy with Tactile Mechanical Bumpers

Part 7 - Mobile Robot Control and Live Video Streaming

An autonomous tracking system can easily collide with static roadblocks. To mitigate this risk, we add an Ultrasonic Distance Module (HC-SR04). This sensor proactively measures the distance to upcoming obstacles by calculating the time-of-flight of high-frequency audio pings.To prevent software lag, we supply a 30,000 microsecond hardware limit to the pulseIn() function. This prevents the script from freezing if the sensor misses an echo pulse. If the calculated clearance falls beneath 30 cm, the robot suspends line tracking and maneuvers away.

Here, the vehicle gains a contact-free defensive boundary. While navigating autonomously, if the ultrasonic sonar module captures a barrier closing within 30 cm, the robot overrides line following to execute a sharp evasive turn away from danger.

The sensor module is mounted on the contact board:

The complete vehicle intended for testing looks as follows:

Essential Code Snippets Related to the Ultrasonic Sensor

1. Hardware Pin Definitions

Pin assignments for the HC-SR04 sonar module:

// Ultrasonic HC-SR04 Sonar Pins
const int TRIG_PIN = 4;      
const int ECHO_PIN = 3;   

2. Pin Setup in `setup()`

Configures TRIG_PIN to output pulses and ECHO_PIN to listen for returning sound waves:

// Ultrasonic Sonar pins configuration
pinMode(TRIG_PIN, OUTPUT);
pinMode(ECHO_PIN, INPUT);

3. Distance Measurement Routine (`getDistance()`)

Generates a 10us ultrasonic burst and measures echo response time to calculate distance in centimeters. Includes a $30 ms$ hardware timeout to prevent code execution freezes:

float getDistance() {
  digitalWrite(TRIG_PIN, LOW);
  delayMicroseconds(2);
  digitalWrite(TRIG_PIN, HIGH);
  delayMicroseconds(10);
  digitalWrite(TRIG_PIN, LOW);
  
  // 30ms hardware timeout constraint to avoid freezing the main execution loop
  long duration = pulseIn(ECHO_PIN, HIGH, 30000); 
  float d = duration * 0.0343 / 2;
  
  if (d == 0) return 999.0; // Return out-of-bounds constant on reading error
  return d;
}

4. Obstacle Avoidance Logic in `loop()`

When operating in MODE_AUTONOMOUS, distance is checked before line tracking logic. If an obstacle is detected closer than $30 cm$ , line tracking is temporarily overridden, and the robot performs an evasive left turn:

else if (currentMode == MODE_AUTONOMOUS) {
  float distance = getDistance();
  
  // Obstacle avoidance matching Elecrow's motor logic and 0.3s timing
  if (distance < 30.0) {
    Serial.println("Obstacle detected! Turning left...");
    driveMotors(MOTOR_SPEED, 0, 0, MOTOR_SPEED); // Spin Left in place
    delay(300);                                  // Turn duration
  } 
  else {
    // Standard Line Tracking routine executes here...
  }
}

Full Code
The full code for this stage is as follows:
#include <Arduino.h>
#include <Arduino_LED_Matrix.h> // Library for the 8x13 LED matrix

Arduino_LED_Matrix matrix; // Initialize LED matrix object

// L9110S Motor Driver Pins
const int MOTOR_PIN_A1 = 5; 
const int MOTOR_PIN_A2 = 6; 
const int MOTOR_PIN_B1 = 9; 
const int MOTOR_PIN_B2 = 10;

// Infrared Receiver Pin
const int IR_RECEIVE_PIN = 2; 

// Line Tracking Sensor Pins
const int TRACKING_PIN_L = A2;
const int TRACKING_PIN_R = A3;

// Ultrasonic HC-SR04 Sonar Pins
const int TRIG_PIN = 4;      
const int ECHO_PIN = 3;      

enum RobotMode { 
  MODE_MANUAL, 
  MODE_AUTONOMOUS 
};

RobotMode currentMode = MODE_MANUAL; 

// Speed settings
const int MOTOR_SPEED = 200; 
const int TRACK_SPEED = 160; 

byte lastCommand = 0;

// LED Matrix Frame Buffer Size (104 pixels)
const uint8_t FRAME_SIZE = 8 * 13;

// --- LED MATRIX ARROW & ICON ARRAYS (Brightness levels 0-7) ---
uint8_t arrow_up[FRAME_SIZE] = {
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 7, 7, 7, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 7, 7, 7, 7, 7, 0, 0, 0, 0,
    0, 0, 0, 7, 7, 0, 7, 0, 7, 7, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0
};

uint8_t arrow_down[FRAME_SIZE] = {
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 7, 7, 0, 7, 0, 7, 7, 0, 0, 0,
    0, 0, 0, 0, 7, 7, 7, 7, 7, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 7, 7, 7, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0
};

uint8_t arrow_left[FRAME_SIZE] = {
    0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 7, 7, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
    0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
    0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
    0, 0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
    0, 0, 0, 7, 7, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0, 0, 0
};

uint8_t arrow_right[FRAME_SIZE] = {
    0, 0, 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0, 7, 7, 0, 0, 0,
    7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0, 0,
    7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0,
    7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0,
    7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0, 7, 7, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0
};

uint8_t stop_icon[FRAME_SIZE] = { 0 }; 

// --- ONBOARD RGB LED FUNCTIONS ---
void set_led3_color(int r, int g, int b) {
  analogWrite(LED3_R, r);
  analogWrite(LED3_G, g);
  analogWrite(LED3_B, b);
}

void set_led4_color(bool r, bool g, bool b) {
  digitalWrite(LED4_R, r ? LOW : HIGH);
  digitalWrite(LED4_G, g ? LOW : HIGH);
  digitalWrite(LED4_B, b ? LOW : HIGH);
}

// Elecrow IR Decoder
long readElecrowIR() {
  int count = 0;
  while (digitalRead(IR_RECEIVE_PIN) == LOW && count < 200) { count++; delayMicroseconds(60); }
  if (count >= 200) return -1;

  count = 0;
  while (digitalRead(IR_RECEIVE_PIN) == HIGH && count < 80) { count++; delayMicroseconds(60); }
  if (count >= 80) return -1;

  int idx = 0, cnt = 0;
  byte data[4] = {0, 0, 0, 0};

  for (int i = 0; i < 32; i++) {
    count = 0;
    while (digitalRead(IR_RECEIVE_PIN) == LOW && count < 15) { count++; delayMicroseconds(60); }
    count = 0;
    while (digitalRead(IR_RECEIVE_PIN) == HIGH && count < 40) { count++; delayMicroseconds(60); }

    if (count > 8) data[idx] |= (1 << cnt);

    if (cnt == 7) { cnt = 0; idx++; } else { cnt++; }
  }

  if ((byte)(data[0] + data[1]) == 0xFF && (byte)(data[2] + data[3]) == 0xFF) {
    return data[2];
  }
  return -1;
}

void driveMotors(int a1, int a2, int b1, int b2) {
  analogWrite(MOTOR_PIN_A1, a1);
  analogWrite(MOTOR_PIN_A2, a2);
  analogWrite(MOTOR_PIN_B1, b1);
  analogWrite(MOTOR_PIN_B2, b2);
}

float getDistance() {
  digitalWrite(TRIG_PIN, LOW);
  delayMicroseconds(2);
  digitalWrite(TRIG_PIN, HIGH);
  delayMicroseconds(10);
  digitalWrite(TRIG_PIN, LOW);
  
  long duration = pulseIn(ECHO_PIN, HIGH, 30000); 
  float d = duration * 0.0343 / 2;
  
  if (d == 0) return 999.0;
  return d;
}

void executeCommand(byte command) {
  switch (command) {
    case 0x1C: // OK Button - Toggle Manual / Autonomous Operations
      if (currentMode == MODE_MANUAL) { 
        currentMode = MODE_AUTONOMOUS; 
        Serial.println("Mode changed: AUTONOMOUS (Tracking + Sonar)");
      } 
      else { 
        currentMode = MODE_MANUAL; 
        driveMotors(0, 0, 0, 0); 
        set_led4_color(false, false, false);
        set_led3_color(0, 0, 0);
        matrix.draw(stop_icon);
        Serial.println("Mode changed: MANUAL (IR Control)");
      }
      lastCommand = 0; 
      delay(500);      
      break;

    case 0x18: // Forward
      if (currentMode == MODE_MANUAL) {
        driveMotors(0, MOTOR_SPEED, 0, MOTOR_SPEED);
        set_led4_color(false, true, false); // Green
        set_led3_color(0, 200, 0);
        matrix.draw(arrow_up);
      }
      break;

    case 0x08: // Spin Left
      if (currentMode == MODE_MANUAL) {
        driveMotors(MOTOR_SPEED, 0, 0, MOTOR_SPEED);
        set_led4_color(false, false, true); // Blue
        set_led3_color(0, 0, 200);
        matrix.draw(arrow_left);
      }
      break;

    case 0x5A: // Spin Right
      if (currentMode == MODE_MANUAL) {
        driveMotors(0, MOTOR_SPEED, MOTOR_SPEED, 0);
        set_led4_color(false, false, true); // Blue
        set_led3_color(0, 0, 200);
        matrix.draw(arrow_right);
      }
      break;

    case 0x52: // Backward
      if (currentMode == MODE_MANUAL) {
        driveMotors(MOTOR_SPEED, 0, MOTOR_SPEED, 0);
        set_led4_color(true, false, false); // Red
        set_led3_color(200, 0, 0);
        matrix.draw(arrow_down);
      }
      break;

    default:   
      if (currentMode == MODE_MANUAL) {
        driveMotors(0, 0, 0, 0);
        set_led4_color(false, false, false);
        set_led3_color(0, 0, 0);
        matrix.draw(stop_icon);
      }
      break;
  }
}

void setup() {
  Serial.begin(115200); 

  pinMode(IR_RECEIVE_PIN, INPUT_PULLUP); 
  pinMode(TRACKING_PIN_L, INPUT_PULLUP);
  pinMode(TRACKING_PIN_R, INPUT_PULLUP);

  pinMode(TRIG_PIN, OUTPUT);
  pinMode(ECHO_PIN, INPUT);

  // RGB LED Pin Configuration
  pinMode(LED4_R, OUTPUT); 
  pinMode(LED4_G, OUTPUT); 
  pinMode(LED4_B, OUTPUT);
  set_led3_color(0, 0, 0);
  set_led4_color(false, false, false);

  // Initialize LED Matrix
  matrix.begin();
  matrix.setGrayscaleBits(3); // 8 brightness levels (0-7)
  matrix.clear();

  Serial.println("System Ready on Arduino UNO Q (IR + Line Tracking + Sonar + Matrix/LEDs).");
}

void loop() {
  // 1. Process incoming IR signals
  if (digitalRead(IR_RECEIVE_PIN) == LOW) {
    long result = readElecrowIR();
    if (result != -1) {
      lastCommand = (byte)result;
      executeCommand(lastCommand);
    }
  }

  // 2. Continuous Mode Execution
  if (currentMode == MODE_MANUAL) {
    if (digitalRead(IR_RECEIVE_PIN) == HIGH) {
      driveMotors(0, 0, 0, 0); 
      set_led4_color(false, false, false);
      set_led3_color(0, 0, 0);
      matrix.draw(stop_icon);
    } else {
      executeCommand(lastCommand);
    }
  } 
  else if (currentMode == MODE_AUTONOMOUS) {
    float distance = getDistance();
    
    // Priority 1: Ultrasonic Obstacle Avoidance
    if (distance < 30.0) {
      Serial.println("Obstacle detected! Evading left...");
      driveMotors(MOTOR_SPEED, 0, 0, MOTOR_SPEED); // Spin Left in place
      set_led4_color(true, false, false);          // Red warning
      set_led3_color(200, 0, 0);
      matrix.draw(arrow_left);                     // Indicate left evasion turn
      delay(300);                                  // Turn duration
    } 
    // Priority 2: Line Tracking Routine
    else {
      int trackL = digitalRead(TRACKING_PIN_L);
      int trackR = digitalRead(TRACKING_PIN_R);
      int trackState = (trackL * 2) + trackR; 
      
      switch (trackState) {
        case 0: // Off track -> Stop
          driveMotors(0, 0, 0, 0); 
          set_led4_color(false, false, false);
          set_led3_color(0, 0, 0);
          matrix.draw(stop_icon);
          break;

        case 1: // Right sensor active -> Turn Right
          driveMotors(0, TRACK_SPEED, TRACK_SPEED, 0); 
          set_led4_color(false, false, true); // Blue
          set_led3_color(0, 0, 200);
          matrix.draw(arrow_right);
          break;

        case 2: // Left sensor active -> Turn Left
          driveMotors(TRACK_SPEED, 0, 0, TRACK_SPEED); 
          set_led4_color(false, false, true); // Blue
          set_led3_color(0, 0, 200);
          matrix.draw(arrow_left);
          break;

        case 3: // Both sensors active -> Move Forward
          driveMotors(0, TRACK_SPEED, 0, TRACK_SPEED); 
          set_led4_color(false, true, false); // Green
          set_led3_color(0, 200, 0);
          matrix.draw(arrow_up);
          break;
      }
      delay(10); 
    }
  }
}

Vape Cell EV - part V - 18650 vs Vape Cell

saramic — Sun, 16 Aug 2026 23:01:03 GMT

shamelessly taking some extra time to complete the project as per the discussion in Challengers, Post your Projects!

Recap

Can random Vape Cells with unknonw histories be bundled into a smart battery system to ultimately power an EV, power wall or other device?

18650 vs Vape Cell

I setup a charging and discharging circuit controlled by the UNO Q, tracking using the INA219 power monitor and added a few relays to control cycling between charging (up to 4.2V and currnet draw down to 150mA) and discharging (down to 3.0V). The setup was far from pretty:

I hooked up a cheap AliExpress 18650 — label reads 2600 mAh 3.7 V 9.62 Wh

and got the following results:

Running a full charge then discharge at ~350 mA (10 Ω resistor):

Metric	AliExpress “18650”	Genuine 18650 (ref)
Claimed capacity	2,600 mAh (9.62 Wh)	2,000–3,600 mAh
Measured capacity	617 mAh	2,000–3,600 mAh
Claimed vs measured	24% of label	~100%
Discharge time to 3.0 V	107 min	~430 min
Avg discharge current	~347 mA	—
Voltage sag (full cycle)	0.85 V over 617 mAh	~0.3 V
IR drop at switch-on	284 mV → ~0.81 Ω	< 100 mΩ
Flat discharge plateau	none — linear drop	3.5–3.7 V
CC charge current	460 mA	—
Charge time (CC + CV to 200 mA)	~154 min	—
Charge accepted	~604 mAh	—

No flat discharge plateau, ~8× the internal resistance of a real cell, and only 24% of the claimed capacity — consistent with a re-wrapped 18350 cell (or a badly degraded pouch cell) inside an 18650 shell. The label’s 9.62 Wh figure is exactly 2,600 mAh × 3.7 V, confirming the capacity claim; neither figure is anywhere near what the cell actually delivers.

I hooked up a Vape Cell — label reads 18450 S50 3.7 V 5.18 Wh (~1,400 mAh claimed)

and got the following results:

Metric	Vape Cell (18450 S50)	AliExpress “18650”
Claimed capacity	~1,400 mAh (5.18 Wh)	2,600 mAh (9.62 Wh)
Measured capacity	~480 mAh (projected¹)	617 mAh
Claimed vs measured	~35% of label	24% of label
Discharge time to 3.0 V	~92 min (est.)	107 min
Avg discharge current	~320 mA	~347 mA
Starting voltage under load	3.35 V	3.85 V
Voltage sag (full range)	0.35 V over ~480 mAh	0.85 V over 617 mAh
IR drop at switch-on	725 mV → ~2.2 Ω²	284 mV → ~0.81 Ω
Flat discharge plateau	none — linear drop	none
CC charge current	~460 mA	~460 mA
Charge time (CV to 200 mA)	~71 min (CV only)	~154 min (CC + CV)
CV taper rate	k ≈ 0.011 /min	k ≈ 0.012 /min

¹ Projected from 7 min of stable discharge data at −3.5 mV/min; actual result expected ~14:00–16:00 UTC. ² Instantaneous IR at load switch-on; CV slope method gives ~0.21 Ω — the large discrepancy reflects polarisation overpotential built up during the 71-min CV charge phase.

The 18450 is a real cell format (18 mm × 45 mm vs 65 mm for 18650) — a genuine 18450 typically delivers 650–1,100 mAh. At 1,400 mAh claimed, the label is optimistic. At ~480 mAh measured it sits at 35% of that claim — a pattern eerily similar to the 18650’s 24%.

Conclusion

Both cells tell the same story: wildly inflated labels, real-world capacity a fraction of what’s printed.

The 18650 came in at 24% of its 2,600 mAh claim. The vape cell looks set to land at ~35% of its 1,400 mAh claim. Neither cell has a flat discharge plateau — a hallmark of healthy lithium chemistry. Both start discharging well below where a genuine cell would: the fake 18650 at 3.85 V under load, the vape cell at only 3.35 V (despite being fully charged to 4.13 V moments earlier).

One genuinely interesting finding: both cells have near-identical CV taper kinetics (k ≈ 0.012 /min). Different form factors, different histories, same electrochemical decay rate — the underlying chemistry is consistent even if the capacity isn’t.

For an EV or power wall application, neither cell is usable as-is. The fake 18650 delivers about 2.2 Wh; the vape cell about 1.6 Wh. A genuine 18650 would deliver 7–13 Wh. You’d need 4–8 of these salvaged cells to match one good one — and that’s before accounting for the matching problem, the safety risk of unknown-history cells, and the cycle life you’d be starting with.

The house didn’t burn down 🏡❌🔥, winning!!

I now have a bunch of vape cells that I need to prevent their terminals shorting, no doubt I will have to continue in some fashion to make this experiment come to a safe ending. Although I didn’t achieve all I wanted, I certainly made a solid dint in my knowledge of battery charging and some positive looking results.

Source

https://github.com/saramic/vape-cell-EV

Vape Cell EV - part IV - On battery charging

saramic — Sun, 16 Aug 2026 23:00:30 GMT

Recap

Can random Vape Cells with unknonw histories be bundled into a smart battery system to ultimately power an EV, power wall or other device?

Challenges

Although I have been bit more busy recently with trips away, even though it is winter here in Australia , the biggest challenge is not fully knowing everything about battery charging and trying to take small steps to identify what is safe to do. Which has lead to stalling some of the things I wanted to do in this project.

What I learnt

It seems that for most Li-ion cells like the 18650, the key to charging them is CC (Constant Current) and CV (Constant Voltage). The cell has a nominal voltage of 3.6V ~ 3.7V and usually a maximum charge voltage of 4.20V. Cells can be chargec at between 0.2C - 1.0C where C is Capacity. For a cell that claims 6000mAh this would mean 0.2C 1.2A, 0.5C 3A or 1.0C 6A. These are indicative values and READ THE DOCUMENTATION FOR YOUR CELL. Not to say the least that I was not about to push 6A through my cell on a desk 🤷. Even less so for an old vape cell that was not labled.

Also cells can become damaged if they go below a minimum voltage, usually around 3V.

A battery management system, BMS, allows multiple cells to be charged. A balance connector allows for each individual cell to be connected and managed for the above thresholds:

over charge protection
over discharge protection
over current protection

From what I can see in builds like Chris Doel’s “I Powered My House Using 500 Disposable vapes”, although he adds a per battery fuse for short protection, there is actually no BMS, no ability to check the levels of any individual cell and from my understanding, he has manually charged the cells and put them into a battery configuration which he will never be able to re-charge safely - a one off YouTube video stunt?

Interestingly in the vape cells, the over current protection is built into the vape cell wire - if you short the battery, the wire will immediately burn through and cut off any more current flow.

In above video you can see when I short out the cell (DO NOT TRY THIS AT HOME) the wire from the vape cell is so thin, it burns out and acts as a fuse to immediately stop current flow.

One of the online BMS circuits https://github.com/stuartpittaway/diyBMS allows you to monitor each cell via a web interface powered by ESP8266. Interestingly over charge protection seems not to turn off the charging of the battery but redirecting the extra current into a big 3Ω3 10W resistor, which seems OK for balancing batteries that have been overcharged but seems like overkill to have that per battery, a resistor the size of a battery just to charge it? an informative overview can be seen in Great Scott’s DIY or Buy segment

Electronoobs also has a hand built BMS. This circuit uses a zener diode to redirect extra current into a load of 4 diodes, again I am not fully sure of this but it does feel wasteful. More can be seen in the video below

Finally Haase Industris seems to point out some of the limitations of the above circuits and proposes using a BQ77915

In between this I saw a video showing how overcharging can explode a cell

And Adam Savage’s overview of 18650 lithium-Ion batteries with a review from Lumafield’s Battery quality report which seems to sugges that anything other than a branded cell is a ticking time bomb. Their X-ray like technology showing build flaws in batteries

See the full video here:

That said, a recent YouTube short from Great Scott suggests it is actually quite hard to blow one of these batteries up

as you can see, a lot of information and heat🔥 generated that took me a little bit out of my comfort zone.

care of How to keep LiPos from burning down your house (safe lipo charging) - Joshua Bardwell

Up Next

Using the INA219 curernt/voltage monitor from Vape Cell EV - part III - INA219 power monitor I plan to cycle a known 18560 cell and a vape cell to see how close my tracking is to what is written on the packaging

Source

https://github.com/saramic/vape-cell-EV

SmartAssist EV - Introducing Autonomous Line Following (TCRT5000) - Part 4

jelektro — Sun, 16 Aug 2026 22:58:53 GMT

Project Roadmap

Part 1 - Experimental Smart Assistive Platform for Elderly and Disabled People

Part 2 - Hardware Platform

Part 3 - Wireless Command and H-Bridge Direct Drive

Part 4 - Introducing Autonomous Line Following (TCRT5000)

Part 5 - Non-Contact Proactive Shielding (HC-SR04 Range Finder)

Part 6 - Strict Priority Hierarchy with Tactile Mechanical Bumpers

Part 7 - Mobile Robot Control and Live Video Streaming

Manual driving is limited by line-of-sight. To implement autonomous navigation, we integrate dual Infrared Line-Tracking Sensors (TrackingPin_L and TrackingPin_R). These sensors output binary feedback depending on whether they detect a highly reflective light floor or a non-reflective dark path.To allow transitioning between manual piloting and automatic tracking, we establish a State Machine using a RobotMode enumeration. Pressing a designated toggle button (0x1C or "OK") alternates the core operating architecture.

This step implements a Finite State Machine utilizing the remote's OK button (0x1C). You can now toggle mid-flight between manual control and an automated tracking routine monitored by the optical sensors on pins A2 and A3.

Hardware Wiring Diagram

Each IR tracking sensor module typically uses a 3-pin or 4-pin breakout board:

1. Left Tracking Sensor (`TRACKING_PIN_L`)

VCC Pin: Connects to 5V (or 3.3V, depending on sensor specifications).
GND Pin: Connects to GND (Ground).
OUT / Signal Pin: Connects to Analog Pin A2.

2. Right Tracking Sensor (`TRACKING_PIN_R`)

VCC Pin: Connects to 5V (or 3.3V).
GND Pin: Connects to GND (Ground).
OUT / Signal Pin: Connects to Analog Pin A3.

Pin Mapping Summary

Sensor Component	Module Pin	Arduino UNO Q Pin	Wire Function
Left Sensor	VCC	5V	Power supply
	GND	GND	Common ground
	OUT / DO	A2	Left line detection signal
Right Sensor	VCC	5V	Power supply
	GND	GND	Common ground
	OUT / DO	A3	Right line detection signal

Electrical Notes

Internal Pull-Ups: The code configures the pins using pinMode(A2, INPUT_PULLUP) and pinMode(A3, INPUT_PULLUP). This activates the microcontroller's built-in pull-up resistors, keeping the signal high by default and stabilizing digital state reads (HIGH vs LOW).
Digital Reading: Although A2 and A3 are labeled as analog input pins on the Arduino header, the digitalRead() function processes them as standard digital binary inputs (returning 0 or 1).

Here is the breakdown of the C code components responsible for line tracking (sensor reading, pin configuration, and autonomous navigation logic).

Line Tracking Code Snippets

1. Sensor Pin Definitions

The line tracking module uses two IR reflectance sensors connected to analog pins A2 (Left) and A3 (Right).

// Infrared Receiver and Tracking Sensor Pins
const int TRACKING_PIN_L = A2; // Left tracking sensor
const int TRACKING_PIN_R = A3; // Right tracking sensor

// Autonomous navigation speed threshold
const int TRACK_SPEED = 160; 

2. Pin Configuration in `setup()`

In setup(), the sensor pins are initialized as inputs with internal pull-up resistors enabled (INPUT_PULLUP) to ensure stable digital reads.

void setup() {
  // Configure line tracking sensor pins as inputs with internal pull-ups
  pinMode(TRACKING_PIN_L, INPUT_PULLUP);
  pinMode(TRACKING_PIN_R, INPUT_PULLUP);
}

3. Operational Mode Toggle (`MODE_AUTONOMOUS`)

Pressing the OK button (0x1C) on the IR remote toggles between manual IR driving mode and autonomous line-following mode.

case 0x1C: // OK Button on IR Remote
  if (currentMode == MODE_MANUAL) {
    currentMode = MODE_AUTONOMOUS;
    Serial.println("Mode changed: AUTONOMOUS");
  } else {
    currentMode = MODE_MANUAL;
    driveMotors(0, 0, 0, 0); // Stop motors immediately on switch
    Serial.println("Mode changed: MANUAL");
  }
  lastCommand = 0;
  delay(500); 
  break;

4. Sensor Reading & Differential Motor Control Loop

Inside loop(), when currentMode == MODE_AUTONOMOUS, the system reads the digital state of both line sensors, combines them into a binary state value (trackState), and adjusts motor outputs accordingly.

else if (currentMode == MODE_AUTONOMOUS) {
  // 1. Read individual sensor pin states (HIGH / LOW)
  int trackL = digitalRead(TRACKING_PIN_L);
  int trackR = digitalRead(TRACKING_PIN_R);

  // 2. Combine signals into a 2-bit state variable (0 to 3)
  // Bit 1 = Left Sensor, Bit 0 = Right Sensor
  int trackState = (trackL * 2) + trackR;
  
  // 3. Differential steering logic
  switch (trackState) {
    case 0: 
      // Both sensors off-line -> Stop
      driveMotors(0, 0, 0, 0); 
      break;                           
    case 1: 
      // Right sensor on line -> Turn Right
      driveMotors(0, TRACK_SPEED, TRACK_SPEED, 0); 
      break;       
    case 2: 
      // Left sensor on line -> Turn Left
      driveMotors(TRACK_SPEED, 0, 0, TRACK_SPEED); 
      break;       
    case 3: 
      // Both sensors centered on line -> Drive Forward
      driveMotors(0, TRACK_SPEED, 0, TRACK_SPEED); 
      break;       
  }
  delay(10); // Short delay to stabilize sensor polling rate
}

Logic Summary

trackL	trackR	trackState	Action	Description
`0` (LOW)	`0` (LOW)	`0`	Stop	Line lost or end of track
`0` (LOW)	`1` (HIGH)	`1`	Turn Right	Vehicle drifted left; right wheel drives forward, left reverses
`1` (HIGH)	`0` (LOW)	`2`	Turn Left	Vehicle drifted right; left wheel drives forward, right reverses
`1` (HIGH)	`1` (HIGH)	`3`	Move Forward	Both sensors detect the track; vehicle drives straight ahead

Full code

The full code for this stage is as follows:

#include <Arduino.h>
#include <Arduino_LED_Matrix.h> // Library for the 8x13 LED matrix

Arduino_LED_Matrix matrix; // Initialize LED matrix object

// L9110S Motor Driver Pins
const int MOTOR_PIN_A1 = 5; 
const int MOTOR_PIN_A2 = 6; 
const int MOTOR_PIN_B1 = 9; 
const int MOTOR_PIN_B2 = 10;

// Infrared Receiver and Tracking Sensor Pins
const int IR_RECEIVE_PIN = 2; 
const int TRACKING_PIN_L = A2;
const int TRACKING_PIN_R = A3;

enum RobotMode {
  MODE_MANUAL,     
  MODE_AUTONOMOUS  
};

RobotMode currentMode = MODE_MANUAL; 

// Speed settings
const int MOTOR_SPEED = 200; 
const int TRACK_SPEED = 160; 

byte lastCommand = 0;

// LED Matrix Frame Buffer Size (104 pixels)
const uint8_t FRAME_SIZE = 8 * 13;

// --- LED MATRIX ARROW & ICON ARRAYS (Brightness levels 0-7) ---
uint8_t arrow_up[FRAME_SIZE] = {
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 7, 7, 7, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 7, 7, 7, 7, 7, 0, 0, 0, 0,
    0, 0, 0, 7, 7, 0, 7, 0, 7, 7, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0
};

uint8_t arrow_down[FRAME_SIZE] = {
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 7, 7, 0, 7, 0, 7, 7, 0, 0, 0,
    0, 0, 0, 0, 7, 7, 7, 7, 7, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 7, 7, 7, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0
};

uint8_t arrow_left[FRAME_SIZE] = {
    0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 7, 7, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
    0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
    0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
    0, 0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
    0, 0, 0, 7, 7, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0, 0, 0
};

uint8_t arrow_right[FRAME_SIZE] = {
    0, 0, 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0, 7, 7, 0, 0, 0,
    7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0, 0,
    7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0,
    7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0,
    7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0, 7, 7, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0
};

uint8_t stop_icon[FRAME_SIZE] = { 0 }; 

// Autonomous Mode Icon (Letter "A")
uint8_t auto_icon[FRAME_SIZE] = {
    0, 0, 0, 0, 0, 7, 7, 7, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 7, 0, 0, 0, 7, 0, 0, 0, 0,
    0, 0, 0, 0, 7, 0, 0, 0, 7, 0, 0, 0, 0,
    0, 0, 0, 0, 7, 7, 7, 7, 7, 0, 0, 0, 0,
    0, 0, 0, 0, 7, 0, 0, 0, 7, 0, 0, 0, 0,
    0, 0, 0, 0, 7, 0, 0, 0, 7, 0, 0, 0, 0,
    0, 0, 0, 0, 7, 0, 0, 0, 7, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
};

// --- ONBOARD RGB LED FUNCTIONS ---
void set_led3_color(int r, int g, int b) {
  analogWrite(LED3_R, r);
  analogWrite(LED3_G, g);
  analogWrite(LED3_B, b);
}

void set_led4_color(bool r, bool g, bool b) {
  digitalWrite(LED4_R, r ? LOW : HIGH);
  digitalWrite(LED4_G, g ? LOW : HIGH);
  digitalWrite(LED4_B, b ? LOW : HIGH);
}

// Elecrow IR Decoder
long readElecrowIR() {
  int count = 0;
  while (digitalRead(IR_RECEIVE_PIN) == LOW && count < 200) { count++; delayMicroseconds(60); }
  if (count >= 200) return -1;

  count = 0;
  while (digitalRead(IR_RECEIVE_PIN) == HIGH && count < 80) { count++; delayMicroseconds(60); }
  if (count >= 80) return -1;

  int idx = 0, cnt = 0;
  byte data[4] = {0, 0, 0, 0};

  for (int i = 0; i < 32; i++) {
    count = 0;
    while (digitalRead(IR_RECEIVE_PIN) == LOW && count < 15) { count++; delayMicroseconds(60); }
    count = 0;
    while (digitalRead(IR_RECEIVE_PIN) == HIGH && count < 40) { count++; delayMicroseconds(60); }

    if (count > 8) data[idx] |= (1 << cnt);

    if (cnt == 7) { cnt = 0; idx++; } else { cnt++; }
  }

  if ((byte)(data[0] + data[1]) == 0xFF && (byte)(data[2] + data[3]) == 0xFF) {
    return data[2];
  }
  return -1;
}

void driveMotors(int a1, int a2, int b1, int b2) {
  analogWrite(MOTOR_PIN_A1, a1);
  analogWrite(MOTOR_PIN_A2, a2);
  analogWrite(MOTOR_PIN_B1, b1);
  analogWrite(MOTOR_PIN_B2, b2);
}

void executeCommand(byte command) {
  switch (command) {
    case 0x1C: // OK Button - Toggle Operational Mode
      if (currentMode == MODE_MANUAL) {
        currentMode = MODE_AUTONOMOUS;
        Serial.println("Mode changed: AUTONOMOUS");
      } else {
        currentMode = MODE_MANUAL;
        driveMotors(0, 0, 0, 0); 
        Serial.println("Mode changed: MANUAL");
      }
      lastCommand = 0;
      delay(500); 
      break;

    case 0x18: // Forward
      if (currentMode == MODE_MANUAL) {
        driveMotors(0, MOTOR_SPEED, 0, MOTOR_SPEED);
        set_led4_color(false, true, false); // Green
        set_led3_color(0, 200, 0);
        matrix.draw(arrow_up);
      }
      break;

    case 0x08: // Turn Left
      if (currentMode == MODE_MANUAL) {
        driveMotors(MOTOR_SPEED, 0, 0, MOTOR_SPEED);
        set_led4_color(false, false, true); // Blue
        set_led3_color(0, 0, 200);
        matrix.draw(arrow_left);
      }
      break;

    case 0x5A: // Turn Right
      if (currentMode == MODE_MANUAL) {
        driveMotors(0, MOTOR_SPEED, MOTOR_SPEED, 0);
        set_led4_color(false, false, true); // Blue
        set_led3_color(0, 0, 200);
        matrix.draw(arrow_right);
      }
      break;

    case 0x52: // Backward
      if (currentMode == MODE_MANUAL) {
        driveMotors(MOTOR_SPEED, 0, MOTOR_SPEED, 0);
        set_led4_color(true, false, false); // Red
        set_led3_color(200, 0, 0);
        matrix.draw(arrow_down);
      }
      break;

    default:
      if (currentMode == MODE_MANUAL) {
        driveMotors(0, 0, 0, 0);
        set_led4_color(false, false, false);
        set_led3_color(0, 0, 0);
        matrix.draw(stop_icon);
      }
      break;
  }
}

void setup() {
  Serial.begin(115200);
  
  pinMode(IR_RECEIVE_PIN, INPUT_PULLUP); 
  pinMode(TRACKING_PIN_L, INPUT_PULLUP);
  pinMode(TRACKING_PIN_R, INPUT_PULLUP);

  // RGB LED Pin Configuration
  pinMode(LED4_R, OUTPUT); pinMode(LED4_G, OUTPUT); pinMode(LED4_B, OUTPUT);
  set_led3_color(0, 0, 0);
  set_led4_color(false, false, false);

  // Initialize LED Matrix
  matrix.begin();
  matrix.setGrayscaleBits(3); // 8 brightness levels (0-7)
  matrix.clear();

  Serial.println("Robot Ready with LED Matrix and RGB Feedback.");
}

void loop() {
  // 1. Read IR Signal
  if (digitalRead(IR_RECEIVE_PIN) == LOW) {
    long result = readElecrowIR();
    if (result != -1) {
      lastCommand = (byte)result;
      executeCommand(lastCommand);
    }
  }

  // 2. Mode Execution Loop
  if (currentMode == MODE_MANUAL) {
    if (digitalRead(IR_RECEIVE_PIN) == HIGH) {
      driveMotors(0, 0, 0, 0);
      set_led4_color(false, false, false);
      set_led3_color(0, 0, 0);
      matrix.draw(stop_icon);
    } else {
      executeCommand(lastCommand);
    }
  } 
  else if (currentMode == MODE_AUTONOMOUS) {
    // Show Autonomous icon ("A") and set indicator LEDs to Yellow/Cyan
    matrix.draw(auto_icon);
    set_led4_color(true, true, false); 
    set_led3_color(100, 100, 0);

    int trackL = digitalRead(TRACKING_PIN_L);
    int trackR = digitalRead(TRACKING_PIN_R);
    int trackState = (trackL * 2) + trackR;
    
    switch (trackState) {
      case 0: driveMotors(0, 0, 0, 0); break;                           // Stop
      case 1: driveMotors(0, TRACK_SPEED, TRACK_SPEED, 0); break;       // Turn Right
      case 2: driveMotors(TRACK_SPEED, 0, 0, TRACK_SPEED); break;       // Turn Left
      case 3: driveMotors(0, TRACK_SPEED, 0, TRACK_SPEED); break;       // Move Forward
    }
    delay(10);
  }
}

SmartAssist EV - Wireless Command and H-Bridge Direct Drive - Part 3

jelektro — Sun, 16 Aug 2026 22:57:20 GMT

Project Roadmap

Part 1 - Experimental Smart Assistive Platform for Elderly and Disabled People

Part 2 - Hardware Platform

Part 3 - Wireless Command and H-Bridge Direct Drive

Part 4 - Introducing Autonomous Line Following (TCRT5000)

Part 5 - Non-Contact Proactive Shielding (HC-SR04 Range Finder)

Part 6 - Strict Priority Hierarchy with Tactile Mechanical Bumpers

Part 7 - Mobile Robot Control and Live Video Streaming

Every robotic vehicle requires a foundation for movement and communication. We begin with an Infrared (IR) receiver based on the standard IRremote library alongside a continuous PWM-controlled H-Bridge system.

By mapping explicit hex codes from a handheld remote, the car acts on standard movement directions. Because a single button press should not trigger indefinite movement, an optional timeout sequence safely cuts power to the motors when the transmitter goes quiet.

This sketch boots the vehicle into manual mode, giving you directional control via your handheld remote. When a key is released, a built-in safety timeout automatically halts the motors to prevent runaway scenarios.

On the Arduino UNO Q board, the analogWrite() function might not work correctly if you explicitly define the pin mode using pinMode(pin, OUTPUT).

Due to its architecture and a known issue in the underlying Zephyr core, removing the pinMode statement from your setup() function allows the PWM signal to generate properly.

How to use analogWrite on UNO Q?

Do not call pinMode(pin, OUTPUT) for your chosen PWM pin.
Call analogWrite(pin, value) directly in your code.
The value ranges from 0 (always off) to 255 (always on).

The STM32 microcontroller controls the motors using the L9110S chip located on a board attached to the motor. The power module board contains two L9110s chips, each controlling a single DC motor.

The vehicle can be controlled locally using a remote control

The assembled vehicle, ready for testing, is shown in the photo below. The vehicle includes an Arduino Uno Q, a 4x1.5V battery pack, and a breadboard containing an infrared receiver.

Here is the circuit connection and pin configuration guide for setting up your Arduino board with the L9110S motor driver, IR receiver, and power system.

Pin Mapping Table

Component	Component Pin	Arduino UNO Q Pin	Notes / Description
L9110S Motor Driver	`A-1A` / `A-1B`	Pin 5 (PWM)	Motor A Direction & Speed
	`A-1B` / `A-2A`	Pin 6 (PWM)	Motor A Direction & Speed
	`B-1A` / `B-1B`	Pin 9 (PWM)	Motor B Direction & Speed
	`B-1B` / `B-2A`	Pin 10 (PWM)	Motor B Direction & Speed
	`VCC`	External Power (+)	6V - 12V (Battery pack)
	`GND`	Common Ground (-)	Shared GND with Arduino
IR Receiver	`OUT` / `DATA`	Pin 2	Signal line (`INPUT_PULLUP`)
	`VCC`	5V / 3.3V	Logic power supply
	`GND`	Common Ground (-)	Shared GND with Arduino

This Arduino sketch implements a complete control system for a two-wheeled mobile robot managed via an Infrared (IR) remote. It decodes custom IR timing signals, controls DC motors using an L9110S H-bridge driver, provides visual status updates via onboard RGB LEDs, and displays directional arrows on an 8x13 LED matrix.

Key Code Sections

1. Libraries and Hardware Definitions

Imports necessary libraries for the LED matrix and assigns GPIO pins for the L9110S motor driver, IR receiver, and motor speed parameters.

#include <Arduino.h>
#include <Arduino_LED_Matrix.h>   // Library for the 8x13 LED matrix

Arduino_LED_Matrix matrix; // Initialize the large LED matrix

// L9110S Motor Driver Pins on Arduino UNO Q
const int MOTOR_PIN_A1 = 5; 
const int MOTOR_PIN_A2 = 6; 
const int MOTOR_PIN_B1 = 9; 
const int MOTOR_PIN_B2 = 10;

// Infrared Receiver Pin (Configured with PULLUP)
const int IR_RECEIVE_PIN = 2; 

// Motor speed (Scale 0-255 for Arduino analogWrite)
const int MOTOR_SPEED = 200; 

2. LED Matrix Graphics Arrays

Defines 104-element arrays (8x13 display) storing grayscale values from 0 (OFF) to 7 (max brightness). These pre-rendered graphics represent directional arrows (Up, Down, Left, Right) and an empty frame for stopping.

const uint8_t FRAME_SIZE = 8 * 13; // 104 pixels for the LED matrix

// Example: Arrow Up Array
uint8_t arrow_up[FRAME_SIZE] = {
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 7, 7, 7, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 7, 7, 7, 7, 7, 0, 0, 0, 0,
    0, 0, 0, 7, 7, 0, 7, 0, 7, 7, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0
};

uint8_t stop_icon[FRAME_SIZE] = { 0 }; 

3. Onboard RGB LED Helper Functions

Provides utility functions to control status indicator LEDs. set_led3_color uses analog PWM values for smooth color mixing, while set_led4_color handles active-LOW digital switching.

void set_led3_color(int r, int g, int b) {
  analogWrite(LED3_R, r);
  analogWrite(LED3_G, g);
  analogWrite(LED3_B, b);
}

void set_led4_color(bool r, bool g, bool b) {
  digitalWrite(LED4_R, r ? LOW : HIGH);
  digitalWrite(LED4_G, g ? LOW : HIGH);
  digitalWrite(LED4_B, b ? LOW : HIGH);
}

4. Low-Level IR Signal Decoder (`readElecrowIR`)

Implements custom pulse-width decoding for the Elecrow IR protocol without relying on standard IR libraries. It measures microsecond pulse durations, reconstructs 32 bits (4 bytes) of data, and validates signal integrity using a bitwise checksum (data + data == 0xFF).

long readElecrowIR() {
  int count = 0;
  
  // 1. Wait for leading LOW pulse
  while (digitalRead(IR_RECEIVE_PIN) == LOW && count < 200) {
    count++;
    delayMicroseconds(60);
  }
  if (count >= 200) return -1;

  // 2. Wait for leading HIGH space
  count = 0;
  while (digitalRead(IR_RECEIVE_PIN) == HIGH && count < 80) {
    count++;
    delayMicroseconds(60);
  }
  if (count >= 80) return -1;

  // 3. Read 32 bits of payload data
  int idx = 0, cnt = 0;
  byte data[4] = {0, 0, 0, 0};

  for (int i = 0; i < 32; i++) {
    count = 0;
    while (digitalRead(IR_RECEIVE_PIN) == LOW && count < 15) {
      count++;
      delayMicroseconds(60);
    }
    
    count = 0;
    while (digitalRead(IR_RECEIVE_PIN) == HIGH && count < 40) {
      count++;
      delayMicroseconds(60);
    }

    if (count > 8) {
      data[idx] |= (1 << cnt); // Store logical '1'
    }

    if (cnt == 7) { cnt = 0; idx++; } else { cnt++; }
  }

  // 4. Checksum verification
  if ((byte)(data[0] + data[1]) == 0xFF && (byte)(data[2] + data[3]) == 0xFF) {
    return data[2]; // Return valid command byte
  }

  return -1;
}

5. Motor Control and Command Execution

driveMotors sends PWM values directly to the driver pins. executeCommand maps hex command codes (e.g., 0x18 for forward) to corresponding motor movements, LED status colors, and matrix graphics.

void driveMotors(int a1, int a2, int b1, int b2) {
  analogWrite(MOTOR_PIN_A1, a1);
  analogWrite(MOTOR_PIN_A2, a2);
  analogWrite(MOTOR_PIN_B1, b1);
  analogWrite(MOTOR_PIN_B2, b2);
}

void executeCommand(byte command) {
  switch (command) {
    case 0x18: // Up Arrow - Forward
      driveMotors(0, MOTOR_SPEED, 0, MOTOR_SPEED);
      set_led4_color(false, true, false);  
      set_led3_color(0, 200, 0);           
      matrix.draw(arrow_up);
      break;
    case 0x08: // Left Arrow - Turn Left
      driveMotors(MOTOR_SPEED, 0, 0, MOTOR_SPEED);
      set_led4_color(false, false, true);  
      set_led3_color(0, 0, 200);           
      matrix.draw(arrow_left);
      break;
    default: // Stop on unassigned keys
      driveMotors(0, 0, 0, 0); 
      set_led4_color(false, false, false); 
      set_led3_color(0, 0, 0);
      matrix.draw(stop_icon);
      break;
  }
}

6. System Setup and Main Loop (`setup` & `loop`)

Configures input pins with internal pull-ups, initializes the display in 3-bit grayscale mode, and continuously polls the IR pin. The loop includes a fail-safe that stops the motors if no active transmission is detected.

void setup() {
  Serial.begin(115200);
  pinMode(IR_RECEIVE_PIN, INPUT_PULLUP); // Enable internal pull-up

  pinMode(LED4_R, OUTPUT); 
  pinMode(LED4_G, OUTPUT); 
  pinMode(LED4_B, OUTPUT);

  matrix.begin();
  matrix.setGrayscaleBits(3); // Enable 8-level brightness
  matrix.clear();
}

void loop() {
  if (digitalRead(IR_RECEIVE_PIN) == HIGH) {
    long result = readElecrowIR();
    if (result != -1) {
      lastCommand = (byte)result;
    }
  }

  // Safety mechanism: Stop motors if no IR signal is being transmitted
  if (digitalRead(IR_RECEIVE_PIN) == LOW) {
    driveMotors(0, 0, 0, 0); 
  } else {
    executeCommand(lastCommand);
  }
  
  delay(10); 
}

Full code

The full code for this stage is as follows:

#include <Arduino.h>

#include <Arduino_LED_Matrix.h>   // Library for the 8x13 LED matrix

Arduino_LED_Matrix matrix; // Initialize the large LED matrix

// L9110S Motor Driver Pins on Arduino UNO Q
const int MOTOR_PIN_A1 = 5; 
const int MOTOR_PIN_A2 = 6; 
const int MOTOR_PIN_B1 = 9; 
const int MOTOR_PIN_B2 = 10;

// Infrared Receiver Pin (Configured with PULLUP just like the manufacturer's code)
const int IR_RECEIVE_PIN = 2; 

// Motor speed (Scale 0-255 for Arduino analogWrite)
const int MOTOR_SPEED = 200; 

// Variable to store the last successfully decoded command
byte lastCommand = 0;



const uint8_t FRAME_SIZE = 8 * 13; // 104 pixels for the LED matrix

// --- LED MATRIX ARROW ARRAYS (Brightness levels 0-7) ---
uint8_t arrow_up[FRAME_SIZE] = {
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 7, 7, 7, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 7, 7, 7, 7, 7, 0, 0, 0, 0,
    0, 0, 0, 7, 7, 0, 7, 0, 7, 7, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0
};

uint8_t arrow_down[FRAME_SIZE] = {
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 7, 7, 0, 7, 0, 7, 7, 0, 0, 0,
    0, 0, 0, 0, 7, 7, 7, 7, 7, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 7, 7, 7, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0
};

uint8_t arrow_left[FRAME_SIZE] = {
    0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 7, 7, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
    0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
    0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
    0, 0, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
    0, 0, 0, 7, 7, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0, 0, 0
};

uint8_t arrow_right[FRAME_SIZE] = {
    0, 0, 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0, 7, 7, 0, 0, 0,
    7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0, 0,
    7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0,
    7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0,
    7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0, 7, 7, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0
};

uint8_t stop_icon[FRAME_SIZE] = { 0 }; 


// --- ONBOARD RGB LED CONTROL FUNCTIONS ---
void set_led3_color(int r, int g, int b) {
  analogWrite(LED3_R, r);
  analogWrite(LED3_G, g);
  analogWrite(LED3_B, b);
}

void set_led4_color(bool r, bool g, bool b) {
  digitalWrite(LED4_R, r ? LOW : HIGH);
  digitalWrite(LED4_G, g ? LOW : HIGH);
  digitalWrite(LED4_B, b ? LOW : HIGH);
}


// IR decoding function based exactly on Elecrow's logic and timing
long readElecrowIR() {
  int count = 0;
  
  // 1. Wait for the leading LOW pulse
  while (digitalRead(IR_RECEIVE_PIN) == LOW && count < 200) {
    count++;
    delayMicroseconds(60);
  }
  if (count >= 200) return -1;

  // 2. Wait for the leading HIGH space
  count = 0;
  while (digitalRead(IR_RECEIVE_PIN) == HIGH && count < 80) {
    count++;
    delayMicroseconds(60);
  }
  if (count >= 80) return -1;

  // 3. Read 32 bits of payload data
  int idx = 0;
  int cnt = 0;
  byte data[4] = {0, 0, 0, 0};

  for (int i = 0; i < 32; i++) {
    count = 0;
    while (digitalRead(IR_RECEIVE_PIN) == LOW && count < 15) {
      count++;
      delayMicroseconds(60);
    }
    
    count = 0;
    while (digitalRead(IR_RECEIVE_PIN) == HIGH && count < 40) {
      count++;
      delayMicroseconds(60);
    }

    // If the HIGH pulse duration was long (count > 8), register bit as 1
    if (count > 8) {
      data[idx] |= (1 << cnt);
    }

    if (cnt == 7) {
      cnt = 0;
      idx++;
    } else {
      cnt++;
    }
  }

  // 4. Check checksum integrity (matches Elecrow's condition: data+data==0xFF)
  if ((byte)(data[0] + data[1]) == 0xFF && (byte)(data[2] + data[3]) == 0xFF) {
    return data[2]; // Returns the valid command byte
  }

  return -1;
}

void driveMotors(int a1, int a2, int b1, int b2) {
  // Omit pinMode() in setup to keep PWM functional on the UNO Q Zephyr core
  analogWrite(MOTOR_PIN_A1, a1);
  analogWrite(MOTOR_PIN_A2, a2);
  analogWrite(MOTOR_PIN_B1, b1);
  analogWrite(MOTOR_PIN_B2, b2);
}

void executeCommand(byte command) {
  switch (command) {
    case 0x18: // Up Arrow - Forward
      driveMotors(0, MOTOR_SPEED, 0, MOTOR_SPEED);
      set_led4_color(false, true, false);  
      set_led3_color(0, 200, 0);           
      matrix.draw(arrow_up);
      break;
    case 0x08: // Left Arrow - Turn Left
      driveMotors(MOTOR_SPEED, 0, 0, MOTOR_SPEED);
      set_led4_color(false, false, true);  
      set_led3_color(0, 0, 200);           
      matrix.draw(arrow_left);
      break;
    case 0x5A: // Right Arrow - Turn Right
      driveMotors(0, MOTOR_SPEED, MOTOR_SPEED, 0);
    
      set_led4_color(false, false, true);  
      set_led3_color(0, 0, 200);           
      matrix.draw(arrow_right);
      
      break;
    case 0x52: // Down Arrow - Backward
      driveMotors(MOTOR_SPEED, 0, MOTOR_SPEED, 0);
      set_led4_color(true, false, false);  
      set_led3_color(200, 0, 0);           
      matrix.draw(arrow_down);
      break;
    default:
      driveMotors(0, 0, 0, 0); // Stop for unassigned keys
      set_led4_color(false, false, false); 
      set_led3_color(0, 0, 0);
      matrix.draw(stop_icon);
      
      break;
  }
}

void setup() {
  Serial.begin(115200);
  
  // Enable internal pull-up resistor (Equivalent to Pin.PULL_UP in MicroPython)
  pinMode(IR_RECEIVE_PIN, INPUT_PULLUP); 
  
  Serial.println("Elecrow IR Decoder for Arduino UNO Q Ready.");

  pinMode(LED4_R, OUTPUT); pinMode(LED4_G, OUTPUT); pinMode(LED4_B, OUTPUT);
  set_led3_color(0, 0, 0);
  set_led4_color(false, false, false);

  matrix.begin();
  matrix.setGrayscaleBits(3);
  matrix.clear();
  
}

void loop() {
  // Main loop logic translated 1:1 from the manufacturer's MicroPython code
  if (digitalRead(IR_RECEIVE_PIN) == HIGH) {
    long result = readElecrowIR();
    
    if (result != -1) {
      lastCommand = (byte)result;
      Serial.print("Retrieve key: 0x");
      Serial.println(lastCommand, HEX);
    }
  }

  // Safety and control: if the IR pin is HIGH (no transmission), stop the robot.
  // Otherwise, continue executing the last received command.
  if (digitalRead(IR_RECEIVE_PIN) == LOW) {
    driveMotors(0, 0, 0, 0); // Stop
  } else {
    executeCommand(lastCommand);
  }
  
  delay(10); // Small delay for main loop stabilization
}

SmartAssist EV - Hardware Platform - Part 2

jelektro — Sun, 16 Aug 2026 22:47:23 GMT

Project Roadmap

Part 1 - Experimental Smart Assistive Platform for Elderly and Disabled People

Part 2 - Hardware Platform

Part 3 - Wireless Command and H-Bridge Direct Drive

Part 4 - Introducing Autonomous Line Following (TCRT5000)

Part 5 - Non-Contact Proactive Shielding (HC-SR04 Range Finder)

Part 6 - Strict Priority Hierarchy with Tactile Mechanical Bumpers

Part 7 - Mobile Robot Control and Live Video Streaming

SmartAssist EV (Experimental Smart Assistive Platform for Elderly and Disabled People) is an experimental mobile platform designed to support elderly people and people with disabilities. The system is based on the vehicle platform from the Pico with 32 Modules & Projects: Advanced Kit. However, the Raspberry Pi Pico is not used in the project. Instead, the Arduino UNO Q serves as the main control and computing unit.

Only selected components from the kit are used, primarily the vehicle platform, H-bridges, and sensors. The remaining modules included in the kit are not required for the basic version of the system.

1. Mobile Platform

The physical foundation of SmartAssist EV is a small mobile vehicle platform equipped with drive motors and wheels. The platform provides mobility and serves as the mechanical base for the assistive system.

The vehicle can perform basic movements, including:

moving forward,
moving backward,
turning left,
turning right,
stopping,
adjusting the speed of individual motors.

The mobile design allows SmartAssist EV to function not only as a stationary monitoring system but also as a robotic assistive platform capable of responding to its environment.

2. Arduino UNO Q

The central component of the system is the Arduino UNO Q. In the original kit, the Raspberry Pi Pico is used as the main controller; however, in SmartAssist EV, the Pico is replaced by the UNO Q.

The Arduino UNO Q is responsible for coordinating the operation of the entire system, including:

reading data from sensors,
processing environmental information,
controlling the vehicle's drive system,
generating control signals for the H-bridges,
implementing autonomous operation logic,
communicating with additional system components,
implementing experimental intelligent-assistance functions.

The use of the UNO Q provides a foundation for further development toward more advanced data processing and algorithms supporting autonomous decision-making.

3. H-Bridges

The H-bridges included in the kit are used to control the drive motors. Their purpose is to provide an interface between the Arduino UNO Q and the motors.

The Arduino UNO Q generates the control signals, while the H-bridges provide the appropriate electrical control of the motors. This makes it possible to control the direction of motor rotation and, depending on the particular driver and control method, the motor speed as well.

The basic drive architecture can be represented as:

Arduino UNO Q → H-bridge → motors → vehicle wheels

This approach separates the low-power logic circuitry from the motor power stage and prevents the Arduino board from having to drive the motors directly.

4. Sensors

Another important part of SmartAssist EV is the set of sensors used from the kit. Their purpose is to provide the Arduino UNO Q with information about the vehicle's current state and its surrounding environment.

Depending on the particular sensors used, they can provide capabilities such as:

obstacle detection,
distance measurement,
object or presence detection,
environmental monitoring,
providing information required for navigation.

The sensor data is processed by the UNO Q and can be used to determine the vehicle's next action.

For example, when an obstacle is detected in front of the vehicle, the system can stop the drive, change its direction, or initiate an obstacle-avoidance procedure.

5. Hardware Architecture

The basic hardware architecture of SmartAssist EV consists of three main blocks:

Sensors → Arduino UNO Q → H-bridges → Motors

The Arduino UNO Q is located at the center of the architecture. It receives data from the sensors, interprets the information, and generates appropriate control signals for the drive system.

The system can therefore be divided into two main layers:

Perception Layer

This layer consists of sensors responsible for observing the vehicle's environment. They provide the input data required for spatial awareness and detection of potential hazards.
Actuation Layer

This layer consists of the Arduino UNO Q, H-bridges, and motors. Based on information received from the sensors, the system determines the appropriate vehicle behavior and implements it by controlling the motors.

SmartAssist EV is not intended to be a finished medical device, but rather an experimental research and development platform. Its modular architecture allows additional functions to be introduced without fundamentally changing the basic vehicle structure.

The current version focuses on the integration of the mobile vehicle platform, sensors, drive system, and Arduino UNO Q. This configuration provides a foundation for further development of autonomous and assistive functions.

In the future, the platform can be extended with additional sensors, communication systems, user interfaces, audio and visual signaling, and more advanced environmental-analysis mechanisms.

The SmartAssist EV hardware uses only selected components from the Pico with 32 Modules & Projects: Advanced Kit, namely the vehicle platform, drive system, H-bridges, and sensors. The Raspberry Pi Pico is not used in the project; instead, it is replaced by the Arduino UNO Q, which serves as the central controller.

This architecture combines vehicle mobility with environmental sensing and intelligent control, providing a foundation for an experimental assistive system designed to support elderly people and people with disabilities.

SmartAssist EV – Experimental Smart Assistive Platform for Elderly and Disabled People - Part 1

jelektro — Sun, 16 Aug 2026 22:27:45 GMT

Project Roadmap

Part 1 - Experimental Smart Assistive Platform for Elderly and Disabled People

Part 2 - Hardware Platform

Part 3 - Wireless Command and H-Bridge Direct Drive

Part 4 - Introducing Autonomous Line Following (TCRT5000)

Part 5 - Non-Contact Proactive Shielding (HC-SR04 Range Finder)

Part 6 - Strict Priority Hierarchy with Tactile Mechanical Bumpers

Part 7 - Mobile Robot Control and Live Video Streaming

The development of intelligent transportation systems is becoming increasingly important, especially in areas related to healthcare, elderly care, and assistive technologies. Autonomous mobility solutions may one day help people with limited mobility move safely and independently inside hospitals, rehabilitation centers, nursing homes, or smart buildings. Before such systems can be implemented in real-life environments, their control algorithms, safety mechanisms, and sensor systems must first be tested on smaller experimental platforms. The SmartAssist EV project was created with this purpose in mind.

SmartAssist EV is not intended to be a full-sized transport vehicle, but rather an experimental prototype platform designed for testing autonomous navigation, obstacle detection, and smart mobility algorithms. The project is based on a compact DIY DC Smart Robot Car Chassis equipped with magnetic speed encoders. Although small in size, the platform is capable of carrying lightweight objects such as a cup of tea, medicine, or small personal items. This makes it ideal for demonstrating assistive transport concepts in a safe and affordable way.

The vehicle is controlled by the Arduino UNO Q SBC, which acts as the main processing unit of the system. Motor control is handled using the L9110 PWM motor drivers, allowing smooth speed regulation, controlled acceleration, and directional movement of the two DC motors. The magnetic wheel encoders provide feedback about wheel rotation and traveled distance, enabling the platform to follow predefined movement paths with improved precision.

A major focus of the project is safety and environmental awareness. To achieve this, the prototype uses a multi-sensor obstacle detection system based on ultrasonic, infrared (IR) and collision sensors. Each sensing technology provides different advantages and helps improve the reliability of the platform.

Ultrasonic sensors measure the distance to nearby obstacles and help prevent collisions with walls, furniture, or people. Infrared sensors are especially useful for detecting edges, stairs, or low obstacles close to the floor surface.

The data collected from all sensors is processed by the Arduino UNO Q SBC, creating a simple sensor fusion system. This allows the platform to intelligently react to its surroundings by slowing down, stopping, changing direction, or warning the operator when obstacles are detected. The project therefore serves as a practical environment for testing mobility-related safety algorithms and autonomous driving logic.

Main Vehicle Features:

1. Remote Control Operation

The user or caregiver can take full control of the vehicle using a wireless remote controller. This feature increases safety and allows manual obstacle avoidance or route modification whenever needed.

2. Advanced Obstacle Detection System

SmartAssist EV uses a multi-sensor safety system based on ultrasonic, infrared (IR), and collision sensors. By combining multiple sensing technologies, the vehicle can effectively detect obstacles and react in real time.

Ultrasonic sensors are responsible for measuring the distance to obstacles located in front of and beside the vehicle.

Infrared sensors are used to detect:

edges,
stairs,
small obstacles,
objects located close to the ground.

This solution significantly improves user safety, especially in indoor environments.

The Arduino UNO Q SBC processes data from all sensors simultaneously, creating a basic sensor fusion system. This allows the vehicle to:

make more accurate decisions,
reduce false alarms,
improve driving safety,
automatically adjust navigation paths.

DockBot - Part 5 - The Mechanical Hand

arvindsa — Sun, 16 Aug 2026 17:55:55 GMT

Recap

I am building a robotic system that identifies the charging port on an EV and automatically moves a charger arm to plug the charger in.

Past Forum Posts:

This is going to be a short post, the kind you write finishing your assignment on the eve of the deadline. We have a robot base, we have a guidance system - what's left (mechanically) is an actuator to actually place a mock charger on the car.

The actuator design

With the platform able to move itself around the floor, all I needed was an actuator that could lift and position the mock charger at different heights. That height adjustment matters because different car models have their charging port at different heights, and the mock charging dock on the car side won't always be identical either.

I found a design that did exactly this at thingiverse.com/thing:5225652 - credit for that goes to SnakeP (thingiverse.com/SnakeP). It worked brilliantly, and mounting it on the Devastator platform was painless.

I was able to lift around 300gms safely. I dare not try more, as I printed in the parts in the default infill of 15% and I do not have the time to reprint it if I broke it just to see how much weight it can lift.

The mock charger design

I wanted the charger itself to be forgiving of small positioning errors - remember Part 3 measured up to 3% error on positioning at range. So I leaned into a poka-yoke design (Mistake Proofing) : the charger is made from a length of PVC pipe with a flange on each end. Eventually I'll add a magnet so it sticks to the car once docked. For the robot to actually grab it, I gave the handle two chamfered collars, so the geometry itself nudges the handle into alignment even if the robot's approach isn't perfectly centered.

The grabber design

The grabber is four fingers with a wide opening - essentially a V shape that guides the handle into the locking area, oriented perpendicular to the charging handle itself. Between the chamfered collar and the V fingers, the mechanism forgives about ±1.8cm of positioning error.

I also designed a small dock for the charger to rest in when it's not "charging a car."

community.element14.com/.../p5_2D00_v1.mp4

Final Notes

The results worked brilliantly in my hand. Now I hope things don't fall apart tomorrow when i integrate everything. I still have not received the diametrically magnetized magnet for my encoder. So I will have to improvise (again???, This entire projects had way too many improvisations)

Vape Cell EV - part III - INA219 power monitor

saramic — Sun, 16 Aug 2026 15:06:25 GMT

Our consumerist society throws out millions of rechargeable vape cells, but the more I read about it sounds like lithium batteries should explode all the time.

Recap

Vape Cell EV is the idea of a smart cell charging system that can handle cells with unknown histories, charging, power distribution, any safety issues and ultimately if a cell should be removed from a battery of many cells.

INA219

To characterise a cell you need at least three things: voltage, current, and time. Voltage alone tells you roughly where you are on the discharge curve. Current alone tells you the load. Put them together over time and you get energy in milliwatt-hours — which is the actual capacity number you are trying to measure. The INA219 gives you all three from a single cheap I2C chip.

It works by sitting in series with the circuit. A small shunt resistor — 0.1 Ω on the standard breakout module — is placed between VIN+ and VIN−. The INA219 measures the tiny voltage drop across that shunt (10 mV per amp at 0.1 Ω) and from that calculates current. Simultaneously it measures the bus voltage: the voltage at VIN− relative to GND, which is the voltage the load actually sees. The series resistance is small enough that it barely affects the circuit — 0.1 Ω in series with a 10 Ω load is less than 1% overhead.

The first real test was a known 18650 cell discharged through a 10 Ω / 5 W resistor: the INA219 read ~385 mA, ~3.87 V, ~1420 mW. The resistor got warm, as expected — 1.4 W in a 5 W part is entirely within rating. The session tracking in the dashboard accumulates mWh in real time, which means leaving it running through a full discharge gives you the cell capacity directly, without any manual timing or maths.

Wire.begin() isn’t optional

On this platform, Wire2.begin() isn’t just good practice — without it, every I2C call fails immediately regardless of wiring. The Zephyr arduino port uses lazy initialisation: the hardware peripheral doesn’t start until you explicitly call begin(). Nothing about the error messages hints at this; everything just returns 1.

void setup() {
    Bridge.begin();
    Wire2.begin();   // i2c3: A4=SDA, A5=SCL
    // ...
}

Current without voltage

First real test with an 18650 across a 10 Ω resistor: current read correctly at about 196 mA, but bus voltage was 0.012 V — effectively zero. The fix was obvious once the INA219’s measurement model clicked: bus voltage is VIN− relative to GND, so if the battery’s negative terminal isn’t connected to the INA219’s GND pin, the reference floats. Current measurement is differential (VIN+ minus VIN−) and works regardless — voltage measurement doesn’t.

Once a wire ran from the battery negative node to GND: 3.87 V, 385 mA, 1420 mW.

A silent JSON truncation

With everything reading correctly on the MCU, the web dashboard was stuck on NO LINK. The Python side was receiving data but failing to parse it:

[bridge/config] Expecting ',' delimiter: line 1 column 29 (char 28)

Tracing back through the JSON the sketch was producing, the config handler built the sensor address string into a fixed buffer:

char addrStr[6];
snprintf(addrStr, sizeof(addrStr), "\"0x%02X\"", sensors[i].addr);

"0x40" is six characters plus a null terminator — seven bytes. The snprintf quietly truncated the closing ", leaving the JSON ["0x40,"rShunt":...] — which is a parse error exactly at character 28. Bumping the buffer to char addrStr[8] fixed it.

The display

With readings flowing, there’s a live dashboard served directly from the UNO Q’s MPU:

Per-sensor cards showing bus voltage (amber), current (green), power
Dual-axis sparklines with fixed scales — 0–6 V and 0–500 mA — so a steady reading looks like a flat line instead of thrashing wall to wall
Live CSV logging and a download button
Session tracking: name a trace, press START, watch mWh accumulate in real time

Actual cell characterisation — charge a known 18650 to 4.2 V, discharge it through a measured load down to 3.0 V, and get a real capacity number. Then do the same with salvaged vape cells and see how they compare.

Source

https://github.com/saramic/vape-cell-EV

hall-w-EV - Post 5 - Chase ball

tamadillo — Sun, 16 Aug 2026 13:29:31 GMT

Hi again, it’s Hambreros and Tamadillo. Last post gave it eyes. This one gives it something to do with them: place a tennis ball 🎾 in front of it and the robot drives itself towards it, no hands.

What we’ve actually built

A 🎾 CHASE toggle next to the joystick. Flip it on, and:

The robot looks for a ball in the camera feed.
Off-center → it turns towards it.
Small (far away) → it drives forward. Big enough (close) → it eases off and stops.
Ball out of frame → it just stops, same as letting go of the joystick.
Manual controls (joystick, keyboard, per-wheel sliders) go greyed-out and unresponsive while this is on, so nothing’s fighting the robot for the wheel. The ⏻ MOTOR ON/OFF buttons still work regardless — always an independent kill switch, whoever’s driving.

Finding the right brick

Same move as every other feature so far: before writing a line of code, went and read arduino/app-bricks-py to see what already exists. Turns out there’s a whole family of vision bricks — gesture_recognition, mood_detector, image_classification, object_detection, visual_anomaly_detection — and the one that actually fits is video_objectdetection: continuous detection off a live camera stream, with per-label callbacks carrying a confidence score and a bounding box.

Its brick_config.yaml lists:

model_by_boards:
    - platform: ventunoq
      model: yolox-qnn-object-detection
    - platform: unoq
      model: yolox-object-detection

UNO Q — this exact board. Not a VENTUNO-only NPU thing, unlike the neural TTS detour a couple posts back. Genuinely usable here.

No training required — just check the label list

The obvious worry: does a generic pretrained model know what a tennis ball is? Didn’t want to assume, so went and checked models/models-list.yaml in the same repo before writing any detection code — it’s a YOLOX-Nano model trained on COCO’s 80 classes, and the label list includes, verbatim:

- sports ball

That’s the actual class name (there’s no separate “tennis ball” class in COCO, but “sports ball” covers it — it’s the canonical example object for that class in the dataset). So: zero custom training, zero Edge Impulse model work. Just register a callback for a class that’s already in the box.

from arduino.app_bricks.video_objectdetection import VideoObjectDetection

detector = VideoObjectDetection(camera=shared_camera, confidence=0.5)
detector.on_detect("sports ball", on_ball_detected)
detector.start()

One camera, two features fighting over it

video_objectdetection wants its own Camera to forward frames to the detection sidecar. We already have one open, for last post’s live feed. Tried to hand-wave past this and it immediately mattered: Camera claims its physical device the moment it’s constructed — there’s an actual registry in the framework’s own source specifically so auto-selection doesn’t grab something already in use — so a second, independent Camera("usb:0", ...) for the same webcam wouldn’t just contend for bandwidth, it’d fail outright.

Good thing VideoObjectDetection(camera=...) takes an existing instance instead of always making its own. Added a small accessor to camera.py:

def get_camera():
    """Blocks until the startup attempt above has settled, then returns the
    shared Camera instance — or None if it never started successfully."""
    _ready.wait()
    return _camera

vision.py calls that instead of constructing its own, so both features share the one physical connection to the one webcam instead of racing for it.

Steering is just proportional control

No path planning, no PID tuning, nothing fancy — just “how far off-center is it” and “how big is it,” recomputed fresh on every detection message:

PID - Proportional Kp, Integral Ki, and Derivative Kd, only recently saw this video from Electronoobs and it looks complicated www.youtube.com/watch

def _steer_towards(bbox):
    x1, y1, x2, y2 = bbox
    frame_w, frame_h = camera.RESOLUTION
    center_x = (x1 + x2) / 2
    box_h    = max(1, y2 - y1)

    offset     = (center_x - frame_w / 2) / (frame_w / 2)  # -1 .. +1
    size_ratio = box_h / frame_h                             # 0 .. 1

    turn     = max(-100, min(100, offset * TURN_GAIN))
    throttle = max(0, min(MAX_THROTTLE,
                          (TARGET_SIZE_RATIO - size_ratio) / TARGET_SIZE_RATIO * MAX_THROTTLE))
    return turn, throttle

turn/throttle go through the exact same mix_drive() the joystick posts through from two posts ago — one function, one place that knows how a turn+throttle pair becomes two wheel speeds, whether a human or a neural network produced them. MAX_THROTTLE is capped well under full speed on purpose — this thing drives itself with nothing watching for obstacles, no reason to let it move at joystick speeds.

What actually broke on real hardware

First real test went nowhere: App.run() never scheduled VideoObjectDetection’s background loops, since the brick got built (on its own thread, after App.run() had already started) too late for the scheduler to notice — confirmed by the sidecar sitting there waiting for a connection that never came. Fixed by just running those two loops ourselves in plain daemon threads instead.

Seeing what it’s actually seeing

Once frames were flowing, the ball’s box kept flickering against other objects (a bed, a cup) even on a dead-static scene — turned out to be real per-frame confidence noise, not a “one object at a time” limitation (it’s a genuine multi-object detector, and no, it can’t be restricted to only look for balls — fixed 80-class model, no filter option). Fix: draw a box for everything it sees, not just the ball, and fade them out over a few seconds instead of hard-cutting the instant one frame doesn’t reconfirm them.

The “lost the ball” behavior that didn’t need writing

Didn’t need a lost-ball timeout — Post 1’s STM32 watchdog already stops the wheels when commands stop arriving, same as a dropped wifi connection, for free.

It worked — and then drove straight past the ball

Reacting to every single detection message overshot the ball almost every time — no braking distance. Fixed by pulsing instead: one short move, stop, pause, then decide again from a fresh look — and VideoObjectDetection’s own per-label lock already discards anything that arrives mid-pause, so no new state machine was needed to make that stick.

community.element14.com/.../20260816_5F00_hall_2D00_w_2D00_EV_2D00_chase_2D00_ball.mp4

What’s next

Well that’s kind of it. Thrilled at how far we got to an actual auto driving EV.

The codes

https://github.com/tamadillo/hall-w-EV

— Hambreros (and Tamadillo)

hall-w-EV - Post 4 - Giving it eyes

tamadillo — Sun, 16 Aug 2026 12:23:30 GMT

Hi again, it’s Hambreros and Tamadillo. Last post ended with a promise: the joystick makes driving nicer, but you’re still driving blind. So a USB webcam went on, and the control page now shows what the robot sees.

What we’ve actually built

A live video feed right on the same page as the joystick — the “puppy on a leash from your phone” post the original plan called for, minus the actual leash. Point the robot somewhere without needing to be in the room with it.

Checking what the framework already gives you

Same move as the TTS detour: before writing any camera code, went and read arduino/app-bricks-py to see what Arduino already ships. Turned out app_peripherals/camera is a whole unified abstraction — one Camera class covering CSI, USB (V4L), IP, and even WebSocket sources, same family as the Speaker peripheral the sound system already uses:

from arduino.app_peripherals.camera import Camera

camera = Camera("usb:0", resolution=(640, 480), fps=15)
camera.start()
frame = camera.capture()   # numpy array, or None
# or: for frame in camera.stream(): ...

Since Speaker was already confirmed bundled in this app’s base container with zero extra install, betting Camera is too — no new brick, no sidecar container, just a normal peripheral call from our own code. The only actual new dependency is opencv-python-headless, for turning each frame into a JPEG.

The dumbest frontend that works

The tempting-but-overbuilt version of this involves a <canvas>, a WebSocket, and a JS render loop pulling frames off it. Skipped all of that:

<img id="cameraFeed" src="/api/camera/stream" alt="Live camera feed">

That’s the entire client-side video pipeline. GET /api/camera/stream returns multipart/x-mixed-replace — a boundary-delimited stream of JPEG frames — and browsers have known how to render that straight into an <img> tag since basically forever. No JS needed for the video itself, just a listener on the error event for when there’s no camera to show:

cameraFeed.addEventListener('error', () => {
  cameraFeed.style.display = 'none';
  fetch('/api/camera/status').then(r => r.json()).then(data => {
    cameraError.hidden = false;
    cameraError.textContent = data.error || 'camera stream unavailable';
  });
});

Same “surface the real reason, not a cryptic broken icon” instinct as the sound system’s error banner from a couple of posts back.

Starting the camera without blocking everything else

Camera.start() has its own connection retry loop with exponential backoff — reasonable for “give the USB device a moment to enumerate,” bad if it’s sitting on the same startup path as the wheel and sound APIs. A slow or missing camera shouldn’t hold up driving the robot.

So python/camera.py kicks off Camera(...).start() on a background thread at import time, mirroring sounds.py’s general shape:

def _start():
    global _camera, _error
    try:
        cam = Camera(SOURCE, resolution=RESOLUTION, fps=FPS)
        cam.start()
        _camera = cam
    except Exception as e:
        _error = str(e)

threading.Thread(target=_start, daemon=True).start()

status() reports (ok, error) off that shared state, and the stream route just checks it before handing back the actual multipart response:

@ web.route('/api/camera/stream') # space added not to look like email address
def camera_stream():              # which flags the post as inappropriate
    ok, error = camera.status()
    if not ok:
        return jsonify({'ok': False, 'error': error}), 503
    return Response(camera.mjpeg_frames(),
                     mimetype='multipart/x-mixed-replace; boundary=frame')

mjpeg_frames() itself is a small generator wrapping Camera.stream(), JPEG-encoding (cv2.imencode) each frame as it comes.

community.element14.com/.../2352.20260816_5F00_hall_2D00_w_2D00_EV_2D00_w_2D00_camera.mp4

What’s next

Camera’s on, joystick works — next logical step is doing something with the two together: point-and-drive, or finally trying that on-device object detection now that we know UNO Q supports in it’s demo bricks.

The codes

https://github.com/tamadillo/hall-w-EV

— Hambreros (and Tamadillo)

hall-w-EV - Post 4 - Giving it eyes

tamadillo — Sun, 16 Aug 2026 12:14:46 GMT

What we’ve actually built

Checking what the framework already gives you

from arduino.app_peripherals.camera import Camera

camera = Camera("usb:0", resolution=(640, 480), fps=15)
camera.start()
frame = camera.capture()   # numpy array, or None
# or: for frame in camera.stream(): ...

The dumbest frontend that works

The tempting-but-overbuilt version of this involves a <canvas>, a WebSocket, and a JS render loop pulling frames off it. Skipped all of that:

<img id="cameraFeed" src="/api/camera/stream" alt="Live camera feed">

cameraFeed.addEventListener('error', () => {
  cameraFeed.style.display = 'none';
  fetch('/api/camera/status').then(r => r.json()).then(data => {
    cameraError.hidden = false;
    cameraError.textContent = data.error || 'camera stream unavailable';
  });
});

Same “surface the real reason, not a cryptic broken icon” instinct as the sound system’s error banner from a couple of posts back.

Starting the camera without blocking everything else

So python/camera.py kicks off Camera(...).start() on a background thread at import time, mirroring sounds.py’s general shape:

def _start():
    global _camera, _error
    try:
        cam = Camera(SOURCE, resolution=RESOLUTION, fps=FPS)
        cam.start()
        _camera = cam
    except Exception as e:
        _error = str(e)

threading.Thread(target=_start, daemon=True).start()

status() reports (ok, error) off that shared state, and the stream route just checks it before handing back the actual multipart response:

@web.route('/api/camera/stream')
def camera_stream():
    ok, error = camera.status()
    if not ok:
        return jsonify({'ok': False, 'error': error}), 503
    return Response(camera.mjpeg_frames(),
                     mimetype='multipart/x-mixed-replace; boundary=frame')

mjpeg_frames() itself is a small generator wrapping Camera.stream(), JPEG-encoding (cv2.imencode) each frame as it comes.

community.element14.com/.../20260816_5F00_hall_2D00_w_2D00_EV_2D00_w_2D00_camera.mp4

What’s next

The codes

https://github.com/tamadillo/hall-w-EV

— Hambreros (and Tamadillo)

EVA Guardian[Part_5] - The Integrated System

Sumanth_m_n — Sat, 15 Aug 2026 17:36:00 GMT

When Battery Management Meets Incident Detection

In the previous posts,

Previous forum posts:

Part 1 : The Idea behind EVA Guardian
Part 2 : The Architecture of EVA Guardian
Part 3 : The Incident detection system in EVA Guardian
Part 4 : The Battery management system in EVA Guardian

I developed the two major subsystems of EVA Guardian independently. The Battery Management System monitors the battery and provides parameters such as voltage, current, temperature, SoC and SoH. The Incident Detection System monitors vehicle dynamics using the MPU6500 and Edge AI. Both systems were working independently. But an EV is not made up of independent systems.

A battery condition can affect vehicle safety.

A vehicle incident can affect the battery.

And a communication failure between two safety-critical systems can itself become a problem.

So the next challenge was:

How do I make these two systems communicate reliably and, more importantly, how do I know when that communication can no longer be trusted?

This became the focus of this stage of EVA Guardian.

Creating a Master–Slave Architecture

For the integration, I used an RS485 transceiver on both Arduino UNO Q systems.The communication between the two nodes is based on UART, using:

Pin 1 – TX
Pin 0 – RX

The architecture is intentionally simple:

Incident Detection System → Master

Battery Management System → Slave

The IDS is responsible for initiating communication, while the BMS responds with its latest battery information.This gives me a deterministic communication model rather than having both systems continuously transmitting data and potentially interfering with each other.

Designing My Own Communication Protocol

Rather than simply sending a raw CSV string over UART, I wanted the communication layer to have a defined packet structure. This became particularly important because the system would later need to detect communication failures and distinguish between different types of faults.

The master sends a battery status request every two seconds. The basic command packet is structured as:

Start of Frame → Payload Length → Command → CRC → End of Frame

The start of frame is: 0x55 0xAA

The battery status command is: 0x01

And the packet terminates with:

0xAA

The CRC is used to provide an additional integrity check on the transmitted data.

Master Request

The IDS periodically sends:

SOF → 0x55 0xAA
Payload Length → Length of command payload
Command → 0x01
CRC → Packet integrity check
EOF→ 0xAA

In simple terms, the IDS is asking:

"BMS, give me your latest battery status."

BMS Response

The BMS receives the request and prepares a response containing the latest battery telemetry.

The response contains:

Voltage
Current
Temperature
Open Circuit Voltage
Coulomb Count
SoC
SoH

The packet follows the same general framing structure

The response effectively tells the IDS:

"Here is the latest condition of my battery."

Why Poll Every Two Seconds?

The IDS polls the BMS approximately every 2 seconds. The BMS itself is continuously updating its battery measurements, so the IDS does not need to request the data continuously at the same rate as the IMU.

The 2-second polling interval provides a reasonable compromise between:

Fresh battery information
Communication overhead
Processing requirements
System reliability

The IDS therefore gets a periodic snapshot of the battery condition while continuing to perform its own high-rate incident detection independently.

From Separate Telemetry to Combined Telemetry

Once communication was working, the next step was to bring the BMS data into the existing IDS telemetry system.

Previously, the IDS primarily knew about things such as:

Motion
Speed
Incidents
Accident classification

Now it also receives:

Battery voltage
Battery current
Battery temperature
OCV
Coulomb count
SoC
SoH

This information is stored in the IDS telemetry state and exposed through the WebUI. The result is a much more useful dashboard. Instead of having one screen for battery information and another for vehicle dynamics, the IDS becomes the central point from which both can be observed.

But What Happens When Communication Stops?

This was where the integration became much more interesting.

It is easy to demonstrate:

BMS connected → data received → everything works.

But I wanted to deliberately break the system. The communication path has three possible failure points:

Failure 1

IDS RS485 transceiver failure

Failure 2

BMS RS485 transceiver failure

Failure 3

Cable between the two systems

The challenge was:

If communication stops, how can the IDS determine which one has failed?

Simply displaying:

"RS485 communication error"

is not enough.

I wanted EVA Guardian to identify the probable source of the problem.

Step 1 – Wait for the BMS

After startup, the IDS begins polling the BMS every two seconds.

If everything is healthy:

IDS → Request

BMS → Response

IDS → Request

BMS → Response

and so on.

But if the IDS doesn't receive a valid response for 30 seconds, the system assumes that something has gone wrong.

Instead of immediately blaming the cable, the IDS begins a diagnostic sequence.

Step 2 – Test the IDS RS485 Transceiver

The first question is:

Is my own RS485 transceiver working?

The IDS performs a local loopback diagnostic. Specific GPIO lines are controlled to configure the RS485 transceiver into its loopback/test condition.

The diagnostic command used is:

0x02

with payload:

0x1010

The IDS sends the diagnostic pattern through its own RS485 interface.

If the transmitted data is successfully received back:

IDS RS485 transceiver = OK

If the IDS cannot receive what it transmitted:

IDS RS485 transceiver = FAULT

The WebUI then reports the appropriate diagnostic condition.

This is useful because the system doesn't immediately assume that the external cable or BMS is responsible.

Step 3 – Test the BMS RS485 Transceiver

Suppose the IDS transceiver passes its loopback test.

We now know:

My side is probably working.

But the BMS transceiver could still be faulty.

So the next diagnostic step is to communicate with the BMS through the network connection and ask the BMS to perform the same local loopback diagnostic.

The same command is used:

Command: 0x02

Payload: 0x1010

The BMS performs its own RS485 loopback test.

If the BMS successfully receives its transmitted data:

BMS RS485 transceiver = OK

The BMS reports this status back to the IDS.

If the BMS cannot complete the loopback:

BMS RS485 transceiver = FAULT

The IDS then displays this information on the WebUI.

Step 4 – So Where Is the Problem?

Now comes the interesting part.

Imagine:

IDS transceiver → OK

BMS transceiver → OK

but:

IDS <-> BMS communication → FAIL

At this point, both ends have independently verified that their own RS485 hardware is functioning.

That leaves the most likely problem:

The communication cable or physical connection between them.

The WebUI can therefore report:

Communication Cable Fault

instead of giving the user a generic communication error.

This is a small feature, but from a system engineering perspective, it makes a significant difference.

https://youtu.be/ciR2tdJ3-0Y

Why I Wanted This Diagnostic Capability

Imagine this system inside an actual vehicle.

A technician receives an error:

BMS Communication Failure

What should they check first?

The BMS? The IDS? The transceiver? The cable?

Without diagnostics, troubleshooting becomes a manual process.

With the diagnostic logic implemented in EVA Guardian, the system itself can narrow down the problem.

Instead of:

Communication Failure

the system can provide:

IDS RS485 Fault or

BMS RS485 Fault or

Communication Cable Fault

This is the difference between monitoring a system and diagnosing a system.

Another Problem: What Happens to the Power Connector?

After dealing with communication failures, I wanted to investigate another practical failure scenario. The physical power connection between the BMS and IDS can also deteriorate. A connector doesn't necessarily go from:

Perfect → Completely Broken

It can gradually become worse. A poor connection can introduce additional resistance and therefore cause a voltage drop. So I added another voltage measurement point at the IDS side.

Monitoring the Power Connection

The IDS measures the voltage arriving through the power connection using its own voltage measurement circuit connected to:

At the same time, the BMS provides its measured battery voltage through RS485. Now I have two values:

BMS-side voltage

Measured directly by the BMS.

IDS-side voltage

Measured after the power connection. The system continuously compares the two.

Conceptually:

Battery voltage -> BMS measurement -> Power connector / cable -> IDS measurement

The difference between these measurements gives an indication of what is happening across the connection.

Detecting Connector Degradation

If the voltage difference starts becoming noticeable but the connection is still functioning, the system generates a warning. For the current prototype, I configured a threshold around 500 mV for the degradation warning.

The WebUI can display a message such as:

️ There is a connector degradation. Please show it to the mechanic soon before any severe damage.

The purpose is not to wait until the connector completely fails. The objective is to identify a potentially deteriorating connection early.

Detecting a Broken Connection

The other extreme is a significant voltage drop indicating that the power path may have become disconnected or severely compromised. In this situation, the system moves from a warning condition to an error condition.

The WebUI can then indicate:

Power connection fault

This gives the user a clear distinction between:

Warning and Critical failure

https://youtu.be/ZFzXiJqRlYU

In this demonstration, I intentionally introduce a degraded connection and observe the voltage difference between the BMS and IDS sides.

Making Accident Detection More Reliable

The integration also gave me an opportunity to improve the accident notification mechanism. One of the problems with a pure ML-based event trigger is that a single inference window can occasionally produce an incorrect classification.

Imagine the model outputs:

Accident – 91%

for one inference window. Should that immediately trigger an emergency message? I decided that for this system, the answer should be:

Not yet.

Instead, the system now requires the model to classify the event as Accident across more than three consecutive inference windows before triggering the emergency response.

Conceptually:

Accident -> Accident -> Accident -> Accident confirmed -> Telegram alert

This gives the system an additional layer of event confirmation.

Preventing Telegram Alert Flooding

Another practical issue appeared during testing.

If the accident condition remains active, the model can continue producing:

Accident
Accident
Accident
Accident...

Without protection, the Telegram system could potentially send multiple notifications for the same event.

To prevent this, I implemented an accident cooldown mechanism. Once an emergency alert has been dispatched, the system temporarily suppresses additional alerts for the same event.

This creates a cleaner workflow:

Detection

→ Confirmation

→ One emergency notification

→ Cooldown

rather than flooding the emergency contact with repeated messages.

The Complete Data Flow

At this point, the integrated system has several independent data paths operating simultaneously.

Vehicle Dynamics

MPU6500 -> 42 Hz acquisition -> EMA filtering -> Edge AI inference -> Incident classification

Battery

Voltage / Current / Temperature -> BMS processing -> SoC / SoH / OCV / Coulomb Count -> RS485 -> IDS

Diagnostics

RS485 timeout -> IDS loopback test -> BMS loopback test -> Cable fault identification

Power Connector

BMS voltage -> IDS-side voltage -> Voltage difference -> Connector warning / fault

Emergency Response

Confirmed accident -> Telegram -> WebUI alert

All these paths finally converge at the IDS telemetry layer.

And Now... Let's Break It

For me, this is one of the most interesting parts of the project.

Instead of only showing the system working perfectly, I wanted to demonstrate what happens when I intentionally introduce faults.1.

Pull the RS485 cable : Does the system identify the communication failure.
Simulate a transceiver problem : Can it distinguish an IDS-side fault from a BMS-side fault?
Introduce connector degradation: Does the voltage comparison detect it
Simulate an accident: Does the ML model confirm the event before sending the alert
Trigger a confirmed accident: Does the Telegram notification reach the registered user?

These tests make the project much more representative of an actual engineering system.

Complete Integrated System Demonstration
https://youtu.be/ZM7amrmEOIg

This video demonstrates the complete system operating as a single platform, with the BMS and IDS communicating through RS485 while the WebUI displays the combined telemetry.

Automatic Power Switching

https://youtu.be/iJWrgn_RvO4
This demonstration focuses specifically on the safety relay and automatic power switching mechanism.

Communication Fault Detection

https://youtu.be/ciR2tdJ3-0Y
Here I intentionally interrupt the communication link and demonstrate how EVA Guardian performs its diagnostic sequence.

Power Connector Degradation

https://youtu.be/ZFzXiJqRlYU
This demonstration shows how the system compares the BMS-side and IDS-side voltage to identify a potentially degrading power connection.

Moving From Electronics to a Vehicle

The electronics are now beginning to look like a system. But I wanted the final demonstration to look like a vehicle rather than a collection of development boards sitting on a table. So I started building a small cardboard EV model. The intention is to physically represent where the different subsystems would exist in an actual vehicle and route the wiring accordingly. The model is still under development, but it will provide the physical foundation for the final demonstration.

The Finishing Touch

https://youtu.be/CVnq63eEgyo
This part of the physical model is currently in progress and will be completed in the next stage.

What Has Changed?

Looking back at the beginning of the project, I had two separate systems.

The BMS could answer:

"How is my battery doing?"

The IDS could answer:

"What is happening to my vehicle?"

After this integration, the system can start answering:

"How is my vehicle doing, how is its battery doing, and can I trust the information I'm receiving?"

That last question is particularly important. Because a smart system should not only provide information. It should also know when the information itself may be unreliable. That is why the communication diagnostics, connector monitoring and fault handling became such an important part of this stage.

What's Next?

The next stage is to move the integrated electronics into the physical EV demonstrator.

I am currently working on the cardboard vehicle model that will house the BMS, IDS, power switching and communication architecture.

The next phase will focus on:

Integrating the electronics into the vehicle model
Finalizing the automatic safety power switching
Refining the WebUI
Improving fault indication and system status
Demonstrating the complete end-to-end safety workflow
Presenting the system as a single EV platform rather than individual modules

The goal for the final demonstration is simple:

Don't just show that EVA Guardian works.

Show what happens when something goes wrong.

That is where I believe the real value of the project lies.

Final Thoughts

This stage has been one of the most interesting parts of EVA Guardian because I moved away from developing individual features and started thinking about system behaviour. A real vehicle doesn't operate in perfect conditions.

Cables can fail.
Connectors can degrade.
Sensors can produce abnormal values.
Communication links can disappear.

And an accident can happen at any time. The objective of EVA Guardian is therefore not simply to detect these events. It is to identify, communicate, diagnose and respond to them. And with the BMS and IDS now working together, EVA Guardian is getting much closer to the original vision:

A vehicle that can sense what is happening, understand the situation, identify when something is wrong, and take the appropriate action.

The two systems are now talking.
The next step is to put them inside the vehicle.

Github Repo: https://github.com/ForgedCircuits/EVA-Guardian.git

Challengers, Post your Projects!

cstanton — Fri, 14 Aug 2026 15:12:06 GMT

All accepted challengers should now be able to post their final write-ups in: Projects

We've had some team members out of the office, so this may be a little short notice (we usually give a week for write-ups) so if you're a few days late I think JoRatcliffe will forgive you, but you have to let us know.

Good luck 🙂

Post 3 Project GEPARD: The Bridge Was Not One Bug

UlolKidz — Fri, 14 Aug 2026 13:30:54 GMT

How I misunderstood the Arduino UNO Q Bridge three different ways before the architecture finally made sense.

Special thanks to ralphjy and BigG for taking the time to comment on my original vision post. The significance of your suggestions only became clearer as the project evolved, and they ultimately helped guide me toward the architecture I use today.

youtube.com/.../0RKAN0TM7Mg

Sometimes Advice Makes More Sense in Hindsight

When I published my first vision post for Project GEPARD, several members of the Element14 community shared suggestions about how I should approach the software architecture.

One comment suggested looking deeper into the UNO Q Bridge system and the documented examples rather than building a custom communication layer from scratch.

Another highlighted something I had underestimated at the time: the Arduino UNO Q is not simply another Arduino board. It combines a Linux computer and a microcontroller on the same platform, and understanding that distinction is important when designing larger applications.

At the time, those suggestions made sense intellectually, but I had not yet encountered the problems they were trying to help me avoid.

So I continued developing the architecture I had already planned.

For a while, everything seemed to be moving in the right direction. Components came online, code compiled, and individual subsystems appeared to work.

As the project grew, however, the cracks started to appear.

The telemetry architecture became increasingly difficult to reason about.

The control system became harder to debug.

Subsystems that worked independently did not always work together.

Fixing one problem often revealed another.

Eventually I found myself spending more time fighting the architecture than building the rover.

That was when I went back to the documentation, reread the community feedback, studied example projects, and looked more carefully at how the UNO Q was designed to operate.

What I discovered was not that my original ideas were completely wrong.

It was that I was trying to use the UNO Q like a traditional microcontroller platform when it was designed to operate as a dual-processor system.

Once I understood that distinction, several weeks of confusing software issues suddenly started making sense.

This post is about those lessons.

Bridge Issue #1: I Treated It Like a Serial Cable

My original mental model looked something like this:

STM32

↓

Push telemetry

↓

Linux

↓

Dashboard

That seems reasonable.

The microcontroller gathers data and pushes it upward whenever it wants.

That is how I had structured a significant portion of the project.

The UNO Q does not work that way.

The UNO Q Bridge is designed around a request-response model.

The Linux side initiates communication.

The STM32 responds.

Once I finally understood that, the architecture changed from:

Bridge.notify("telemetry", distance, voltage, ticks);

to:

Bridge.provide("get_telemetry", get_telemetry);

and

telemetry = Bridge.call("get_telemetry")

The difference sounds tiny.

The impact was enormous.

Instead of trying to continuously push data upward, the Linux side now requests data when it actually needs it.

That immediately simplified the entire system.

Bridge Issue #2: The Motors Worked in the Test Sketch but Not in the Real Firmware

At one point I had a very confusing problem.

The motors worked perfectly.

Until they didn't.

My simple diagnostic sketch spun the wheels every time.

My "real" firmware did not.

From the outside that sounds like a wiring issue.

It wasn't.

The multimeter eventually gave me the answer:

VM = 10.97 V

STBY = 3.3 V

PWMA = 0 V

The motor driver had power.

The standby pin was enabled.

The PWM signal simply never existed.

That pointed directly at the software stack.

The root cause turned out to be a combination of:

Incorrect Bridge architecture
Telemetry logic
A safety override that was stopping forward motion

Ironically, my safety feature was preventing me from proving the motors worked.

Once I removed the unnecessary override and rebuilt the communication architecture around proper Bridge calls, the motors came back to life.

Bridge Issue #3: Not All Providers Are Equal

This one took me much longer to understand.

I originally treated these as interchangeable:

Bridge.provide(...)

and

Bridge.provide_safe(...)

They are not.

The distinction matters.

Functions that touch hardware:

digitalWrite(...)

analogWrite(...)

should use:

Bridge.provide_safe(...)

Examples:

set_drive()
set_estop()
test_module()

These affect the physical world.

Motors move.

Sensors trigger.

Pins change state.

Those belong in the safe execution context.

On the other hand:

get_telemetry()

should ideally be a read-only operation.

That means it can use:

Bridge.provide(...)

if it remains short and thread-safe.

That led directly into the next mistake.

Bridge Issue #4: My Telemetry Function Wasn't Actually Read-Only

I thought this function was simple:

get_telemetry()

It wasn't.

Inside it I was:

Triggering ultrasonic pulses
Reading I2C sensors
Waiting on pulse timing
Accessing hardware directly

Which meant the function wasn't actually just returning telemetry.

It was collecting telemetry on demand.

That sounds harmless until you realize the ultrasonic routine alone can block for milliseconds.

The fix was to separate two jobs.

Instead of:

Request → Read Sensors → Return

I moved to:

Loop()
↓

Sample everything continuously

↓

Cache data

get_telemetry()

↓

Return cached copy

Now the microcontroller continuously updates a telemetry cache and the Bridge simply serves the latest values.

The function became short.

Predictable.

Thread-safe.

And much easier to reason about.

The Surprise Bug: The Sketch Wasn't Even the Main Problem

At one point I became convinced the firmware itself was broken.

But after rebuilding the project structure I discovered that many issues were actually App Lab configuration problems.

Things that changed included:

Old Architecture

Laptop application
UDP transport
Custom dashboard
Mixed project structure

New Architecture

UNO Q Linux application

Official WebUI Brick

Bridge RPC

App Lab project structure

I also discovered things like:

Project structure matters more than I thought.
UNO Q examples assume a specific layout.
The WebUI Brick was solving problems I was manually creating.
I was fighting the platform instead of using it.

That was a humbling realization.

The Comment I Should Have Listened To

Looking back, the most frustrating part is that several people had effectively pointed me toward the solution weeks earlier.

Not the exact solution.

But the correct direction.

I had not yet encountered the problems that made those suggestions valuable.

I tend to learn in a very stubborn way:

Build the thing.
Assume the thing should work.
Watch it fail.
Spend hours troubleshooting.
Finally accept that the original assumption was wrong.
Open the documentation.

I joke about it, but Project GEPARD has forced me to become better at step 6.

The Architecture We Settled On

After all of the redesigns, experimentation, broken assumptions, and late-night troubleshooting sessions, the architecture finally became simple.

Browser HUD

│

▼

UNO Q Linux (Brain)

│

Bridge.call()

│

▼

STM32 (Spine)

│

▼

Motors, sensors, hardware

The responsibilities are now clear.

The Spine (STM32)

Reads sensors
Controls motors
Handles hardware timing
Provides telemetry

The Brain (Linux)

Collects telemetry
Hosts the WebUI dashboard
Runs autonomy logic
Interfaces with future AI systems

The Browser

Displays the tactical HUD
Shows telemetry
Sends commands
Works from a laptop or phone

The architecture finally matches the way the UNO Q was designed to work.

Current Status

✅ Motors responding

✅ Bridge architecture redesigned

✅ WebUI architecture established

✅ Ultrasonic testing functional

✅ Individual subsystem testing implemented

✅ Brain / spine architecture finalized

⚠️ INA226 still being validated

⚠️ MPU6050 still being validated

⚠️ Encoder tuning still required

🔧 Final assembly underway

Final Thoughts

I think one of the most important lessons from this challenge is that being wrong is not the problem.

Staying wrong is.

The UNO Q Bridge was not one bug.

It was a chain of misunderstandings:

Wrong communication model
Wrong assumptions about providers
Wrong telemetry strategy
Wrong project architecture

Each fix revealed the next problem underneath it.

And honestly, that is probably the most realistic description of engineering I can give.

You don't usually solve the problem.

You solve enough problems that eventually only the real problem remains.

More soon.

The Bridge works. Mostly. 🚀

Part 2 Project GEPARD: Scope Creep, Smoke, and the 3.3 Volts That Broke Everything

UlolKidz — Thu, 13 Aug 2026 14:07:17 GMT

An honest devlog of how a tank became a car, a "simple" telemetry link ate 3 weeks, and why the pile of failed prints in the corner is the most useful part of this project.

Intro: the gap between the render and the reality

When I pitched Project GEPARD, the vision was clean: a tracked, Ripsaw-inspired autonomous UGV with a sensor turret, self-docking, on-board AI, and a tactical command dashboard. Scaled-down EV-fleet tech in a one-foot rover.

What I actually have, weeks later, is a wheeled rover, a graveyard of failed prints, a multimeter I now can't live without, some chips I need to re-order, and a much deeper respect for the phrase "it's just a wiring problem."

This post is the honest version — every place the plan bent, every thing that released the magic smoke, and what I learned. The polished final build is the last post. This one is the mess in the middle, because that's where the actual engineering happened.

Part 1: The Great Pivots (Scope Creep in Reverse)

Most scope creep adds features. Mine mostly removed them — the harder and more valuable kind.

Pivot 1 — Tracks → Wheels (a printing defeat, told honestly). The whole identity was the aggressive tracked "Ripsaw" look, and I fought hard for it. I printed multiple sprocket designs and tested three different track-link designs, and hit a wall of print-reality problems the CAD never warns you about:

Getting a printed track to actually seat and travel over the sprocket — it kept binding or skipping teeth.
I redesigned the sprocket for dual-tooth engagement to grip better. It failed again.
The real killer was tolerances and print settings — the gap between "looks right in CAD" and "flexes, meshes, and holds under load in PETG/TPU" was a tuning rabbit hole I couldn't climb out of in the time I had.

Eventually I made the honest call: switch to a differential wheeled drivetrain. Same tank-steer control, same motor driver, same code — but far better odometry (tracked skid-steer scrubs sideways and wrecks the encoder data any future SLAM needs), much faster to print, and it deleted my single highest-risk mechanical subsystem in one move. I lost the aesthetic. I kept the deadline. Sometimes engineering is knowing when to stop fine-tuning a thing that isn't converging.

Pivot 2 — Tri-Node Compute → "the board already does this." The original plan was three brains: Arduino for motors, ESP32 for Wi-Fi, a PC for heavy lifting. Then I actually read the Arduino UNO Q datasheet and realized it's already a dual-brain board — an STM32 real-time MCU plus a Qualcomm Linux computer with built-in Wi-Fi 5. I was bolting a weaker ESP32 Wi-Fi onto a board that already had a better one. The ESP32 got demoted to just the camera.

Pivot 3 — "Do Everything" AI → a finishable MVP. The design doc had Google Cast control, Workspace alarms, Bluetooth audio, cloud upload, facial recognition (owner vs. stranger vs. pet vs. rat), and IR-beacon precision docking — on a four-week clock. I cut all cloud/Bluetooth, kept and simplified manual drive + obstacle avoidance (the real MVP), offline voice, and April tag-marker docking instead of research-grade IR beacons. Face-rec, SLAM, and full autonomy became a documented Phase-2 roadmap instead of broken half-features.

Pivot 4 — The rear idler: sliding mount → eccentric cam → just a wheel. This one's a perfect little case study in over-engineering and then coming to my senses. The rear support started as a sliding-mount idler (slot + screw to tension). Then I got fancy and redesigned it as a 12-sided eccentric-cam idler — rotate the cam, move the axle, tension the track. Genuinely clever… for a track system I no longer had after Pivot 1. Once the tracks were gone, the whole reason for a tensioning idler evaporated. It collapsed down to what it should have been all along: a plain free-rolling wheel on a bearing, with a simple printed circle spacer to hold it off the chassis wall. Three designs to arrive at "a wheel."

Pivot 5 — The Docking Dream → a cardboard box with a printed face. Auto-docking is one of the most failure-prone things in mobile robotics. The honest MVP: a cardboard enclosure for the relay + a printed faceplate holding the pogo pads and ArUco marker at the right height. Proof of concept, documented as such.

Part 2: The Errors (the actually-useful part)

Error 1 — The 3.3 V that broke everything. The UNO Q looks like a 5 V Arduino. It is not — its headers are 3.3 V logic. My spec said "all sensors 5 V." That mismatch meant the HC-SR04's 5 V ECHO needed level-shifting, and only D2/D3 are bench-verified for interrupts on its STM32 — so my five-IR-encoders-on-five-interrupts plan was a coin-flip. Fix: two encoders on the two proven interrupt pins, the rest polled.

Error 2 — Powering I2C sensors at 5 V killed the whole bus. My INA226 and MPU6050 both showed offline at once. I assumed two dead boards. Wrong. Powering them from 5 V made their pull-up resistors drag the I2C lines to 5 V, so the 3.3 V UNO Q couldn't talk to either. Three symptoms, one cause. Fix: moved one wire from 5 V to 3.3 V; both woke up. Lesson: when multiple boards fail at once, look for the one shared thing — a rail, a ground, a bus — not multiple faults.

Error 3 — The 1 a.m. wiring mistake that cost me chips. Late-night bench work is a trap. At 1 in the morning I wired the ultrasonic sensor backwards — VCC into ground, ground into VCC. Reverse-polarity into a sensor is exactly how you release the magic smoke. That chip (and a couple of friends) are now on a re-order list. Lesson: past midnight, walk away. The mistake you make tired costs more than the sleep would have.

Error 4 — The motors that wouldn't spin (my code, not my wiring). My raw test sketch spun the motors. My "real" firmware left PWMA reading 0 V on the multimeter. Same wiring, so it was software. Two culprits, both mine: (1) an obstacle-override "safety" that force-stopped forward motion when the ultrasonic read too close or wasn't wired — my safety feature was stopping the wheels; (2) the Bridge used backwards. The UNO Q's two brains talk over an RPC "Bridge," and the official rule is: the MCU never initiates — Python always makes the call, the MCU only responds. My code had the MCU pushing telemetry, which silently fails. The fix is Python polling the MCU.

WRONG (what I did): MCU tries to push data at Linux — silently drops

Bridge.notify("telemetry", distance, voltage, ticks /* ... */);

RIGHT: MCU exposes a function; Linux POLLS it when ready

void get_telemetry() { /* return sensor struct */ }

void setup() {

Bridge.begin();

Bridge.provide_safe("get_telemetry", get_telemetry); // MCU responds only

Bridge.provide_safe("set_drive", set_drive);

The multimeter ended the guessing: STBY = 3.3 V (driver awake), VM = 10.97 V (power good), PWMA = 0 V on "forward" (no signal) → the code, not the wiring.

Error 5 — Servo.h freezes the board. A diagnostic sketch used the classic AVR Servo.h. On the UNO Q's STM32/Zephyr stack it grabs a hardware timer the motor PWM needs — servo swept once, board froze. Classic "treat the UNO Q like a 5 V ATmega" trap.

Error 6 — The suppressed holes I found 25 hours too late. While cleaning up the rear chassis CAD, I suppressed the mounting holes and forgot to un-suppress them before hitting print. I noticed after the 25-hour print finished. No way I'm reprinting a full day of filament four days from deadline — so the fix became a printed drill-jig to re-add the holes with a soldering iron. Lesson: a pre-print checklist ("are all the holes actually there?") is cheaper than 25 hours.

Error 7 — I flipped the battery bay's length and width. Here's a fun one. I got the orientation of the battery bay wrong in CAD — swapped length and width — so when I went to install the 464 g battery pack, it didn't fit lying down the way I'd planned. My only option post-print was to stand the battery up vertically at the very back. That single mistake shoved the center of mass rearward, which then forced me to actually sit down and do a tipping calculation to make sure the rover wouldn't wheelie backward. (It won't — the CoM lands ~95 mm from the rear, inside the wheelbase, so it's stable, just rear-biased.) An orientation typo in a sketch turned into a physics homework problem. Lesson: double-check which dimension is length before you commit a 20-hour print.

Error 8 — The pan-tilt turret that ended in double-sided tape. The camera turret went through rounds of design → print → reprint: servo pockets that didn't fit, mounts that didn't hold, a built-in-spacer-vs-bearing conflict. After enough reprints eating time I didn't have, I did the honest maker thing and mounted it with double-sided tape. Not elegant. It works. Four days out, "works" wins. 😅

Error 9 — The print farm of sadness. 23-hour chassis prints (fine layers + high infill) → fixed with 0.28 mm layers, ~15–20% infill, 3 walls, and supports OFF. Warping on big flat PETG → brim, non-negotiable. An extruder squeal/skip (filament pushed then backed out) turned out to be wet PETG — drying the spool fixed the squeal, the stringing, and the surface finish at once. Wiggly soldered pins = cold joints; a board can read "dead" when it's really an intermittent joint, so re-flow before you condemn it.

Error 10 — Mechanical odds and ends. The motor mount alone evolved faceplate → pipe-clamp saddle → full sleeve → a half-U cradle (open top, prints with no supports, motor drops in, screws hold it). And the rear wheel axle taught me a 3 mm bearing needs a 3 mm axle — an M3 screw or literally a nail. Imperial 6-32 and 8-32 are both too fat to pass through a 3 mm bore; I measured, doubted, re-measured, and gave up on the hardware-store bin.

Part 3: How the software is structured now

The Bridge lesson forced a clean brain / spine model (which is also the officially-supported App Lab pattern):

1 STM32 MCU ── "spine" ── reflexes: read sensors, drive motors, fast + dumb

2 │ (Bridge RPC: Python polls, MCU responds)

3 ▼

4 UNO Q Linux ── "brain's home" ── holds ALL sensor feeds, hosts dashboard,

5 │ (Wi-Fi) runs decision logic; AI sees every feed

6 ▼

7 Browser (laptop or phone) ── tactical HUD at :7000

8 ▲

9 Laptop GPU (RTX 3050) ── heavy muscle: YOLO / local LLM, only when needed

Principles earned the hard way: the spine has veto and the brain proposes (but in manual mode nothing overrides me); every sensor reports its own ACTIVE/OFFLINE status so I bring the system up one circuit at a time, like an electrician testing a panel breaker by breaker; and the dashboard is hosted on the rover itself, reachable from any browser on my Wi-Fi — laptop or phone, no app to install.

Part 4: The Tactical HUD

If you're going to build a UGV, the command interface should look like one — dark theme, live camera center-stage, a sweeping proximity radar that plots the live ultrasonic contact, battery/voltage/speed gauges, a scrolling command console, and an "AI Cognition" panel that shows the brain's perception → decision stream in autonomous modes. (Insert HUD screenshot here.)

Where it stands + what's next

Working / in-hand: wheeled drivetrain (motors verified on the bench), the 3.3 V sensor suite coming online one circuit at a time, the WebUI control architecture, the printed chassis, and an educational pile of failed prints.

Next posts: getting all sensors green on the HUD; tuning the IR wheel-encoders (odometry is the road to mapping); the ArUco docking attempt (and the honest manual-dock fallback).

Phase-2 roadmap (documented, not promised): 2D SLAM room-mapping from encoder + IMU + sonar fusion, named locations in roam mode, and local (privacy-preserving) facial recognition.

The One Takeaway

The render never smokes. The prototype always does.

Every failed print, every wiring mistake, and every 0-volt reading in this post taught me something a clean success never would. Honestly, documenting those mistakes is probably the most useful thing I can hand to the next person who picks up an Arduino UNO Q and assumes it is just another 5 V Arduino.

If you are still reading, I'd like to share why this project means so much to me.

When I was in high school, I spent a lot of time building things. We had STEM classes where we worked on robotics-related projects, and one of the most memorable was building a small submarine. Outside of school, I was always experimenting with random ideas and turning them into increasingly complicated devices. One time I set out to build a simple handheld vacuum to clean my desk. By the end of the project, it had somehow evolved into a wheeled robot that could only vacuum very tiny particles.

After the military takeover in Myanmar, life took a very different direction. I stopped building projects altogether. Years passed, I moved to Canada, and eventually started my undergraduate studies. Somewhere along the way I realized I no longer had a hobby that I was genuinely excited about and life felt flat.

Then, by pure chance, I found a 3D printer on Facebook Marketplace for $100. About a week later I came across the Element14 EZ-EV Design Challenge. Before I knew it, I was designing parts, printing prototypes, making wiring mistakes, and staying up far too late troubleshooting electronics.

In a way, Project GEPARD is not just about building a rover. It is about reconnecting with the version of myself that loved making things when I was younger.

So please excuse the cable spaghetti in the videos, the rough prototype parts, and the occasional piece of double-sided tape holding something together. This project is very much a work in progress.

I would also like to thank Element14 for providing me with a sponsored kit. As a university student, I simply would not have been able to justify buying all of this hardware myself. The challenge gave me both the tools and the motivation to start building again. Without the competition, I probably would have kept telling myself, "I'll start next week."

I also owe everyone an apology for the quality of the video. It was recorded around 1 a.m. after a long day of work. I kept telling myself I would make a post after fixing one more bug, printing one more part, or reaching one more milestone. The result was that I kept pushing updates further and further back.

No more.

From this point forward, I am going to focus on documenting the process as it happens, mistakes and all. The written portions will remain organized and professional, but I am completely new to making videos, so thank you for bearing with me while I learn that side of the process as well.

More soon.

The wheels are turning. Mostly.
www.youtube.com/watch

Featured in this post:

3 failed track designs
Multiple failed sprocket revisions
Rear idler redesigns
Battery packaging mistakes
25-hour print failure
Ultrasonic sensor wiring failure
Current rover prototype footage

Hall-w-EV - Post 3 - Joystick control

tamadillo — Thu, 13 Aug 2026 13:56:38 GMT

Hi again, it’s Hambreros and Tamadillo. Last post the robot learned to make noise. This one is smaller but makes the whole thing way more fun to actually drive: a real joystick — drag it with a mouse or thumb, or just use WASD / vim-style hjkl on a keyboard — instead of wrestling two separate wheel sliders at once.

What we’ve actually built

Since Post 1, driving meant dragging two independent vertical sliders. Well actually up till now we haven’t connected both servos but yeay a slider per wheel like driving a tank, and how do you even control 2 controls with 1 mouse? So the control page now has:

An on-screen joystick pad — drag the stick in any direction, let go and it springs back to center and stops, same “throttle stick, not a light switch” feel as the wheel sliders had.
WASD and vim’s hjkl both drive the same stick — whichever one you reach for first works, and they combine, so forward + turn gives you a proper diagonal instead of a hard pivot.
The old per-wheel sliders are still there underneath, now relabeled “Manual Wheel Control” — occasionally useful for trimming one wheel on its own, but the joystick is the one you actually want to drive with.

Keeping the mixing in one place

The tempting shortcut was to do the “turn this drag angle into two wheel speeds” math in JavaScript and post straight to the existing /api/wheel/<n> endpoint per wheel. We didn’t do that — the frontend has no business knowing how many wheels this thing has or how they’re mixed. Instead the page posts one thing, {x, y} (turn, throttle, both -100..100), to a new POST /api/drive, and the actual arcade-mixing math lives entirely on the Python side:

def mix_drive(x, y):
    x = max(-100, min(100, int(x)))
    y = max(-100, min(100, int(y)))
    return max(-100, min(100, y + x)), max(-100, min(100, y - x))

One function, one place that knows wheel1 = throttle + turn and wheel2 = throttle - turn. If we ever add a third wheel, a different chassis, or want to curve the turn response, that’s a one-function change, not a hunt through frontend code.

Mirrored servos, mirrored bug

Software done, so time to actually push the stick forward with both wheels connected at once — first time we’d had them both hooked up and driven together rather than one at a time. Robot spun in place instead of driving forward. Wheel 1 was doing exactly what it should; wheel 2 was going backward.

Both servos are the same part, wired the same way, running the same firmware — but they’re bolted to opposite sides of the chassis, mirror image of each other, the same way your left shoe and right shoe are mirror images built from the same last. “Spin clockwise” looks like forward from one side and backward from the other, so the exact same pulse width that drove wheel 1 forward drove wheel 2 in reverse. Nothing wrong with the mixing math from the last section — mix_drive() was handing out perfectly correct forward speeds for both wheels, it’s just that one wheel’s servo interprets “forward” backwards from the other.

Fixed it at the one point in the firmware that turns a commanded speed into an actual pulse, not by touching the mixing math or anything upstream of it:

#define WHEEL1_REVERSED false
#define WHEEL2_REVERSED true
...
servoFrame(SERVO1_PIN, speedToPulseUs(WHEEL1_REVERSED ? -wheel1Speed : wheel1Speed),
           SERVO2_PIN, speedToPulseUs(WHEEL2_REVERSED ? -wheel2Speed : wheel2Speed));

wheel1Speed/wheel2Speed themselves — the values the Bridge handlers store, the values the Python side and the joystick’s arcade mixing both reason about — still mean “positive is forward” for both wheels. The mirroring correction is a single negation right at the pulse-generation step, isolated to the one wheel that’s actually mounted backwards. If it turns out a future chassis needs the other wheel flipped too (or flipped back), it’s a one-line change, not a rethink of the mixing.

A real OFF switch

With the direction sorted, one servo was still making a faint noise even sitting at commanded speed 0 — the same self-correcting buzz Post 1 first ran into, just quieter now that both servos are trimmed better. Trimming the pot gets you close to the servo’s true center, not exactly onto it, and a held 1500us “stop” pulse still gives the servo’s internal position-holding loop a target to compare itself against. Close-but-not-perfect is still enough for it to keep nudging.

So instead of chasing the trim pot further, we added a real motor power toggle — a button per wheel that does something a commanded speed of 0 can’t: stop sending that servo a pulse train at all.

static void servoFrame(int pin1, unsigned int pulse1Us, bool enable1,
                       int pin2, unsigned int pulse2Us, bool enable2) {
    if (enable1) {
        digitalWrite(pin1, HIGH);
        delayMicroseconds(pulse1Us);
        digitalWrite(pin1, LOW);
    }
    // ...same for pin2/enable2
}

No pulse means nothing for the internal loop to react to — quieter than any stop pulse we could trim to, held or not.

Worth being upfront about what this isn’t: it’s not a real power switch. The board only ever drove the servo signal line — the 5V rail has always come straight off the shared supply with no relay or MOSFET in between , so “motor off” here can’t cut actual voltage to the servo. That would need new hardware — a MOSFET or relay switched from a spare GPIO — not just a firmware change, so we deliberately scoped this to the signal-only version rather than reaching for a soldering iron mid-feature. Given the noise was coming from the signal being held near-but-not-quite-center rather than from anything drawing power at true idle, it’s also very likely the actual fix for the buzz, not just a consolation prize.

“Holding a key” isn’t a real browser event

First pass: listen for keydown, send the drive command once. Worked for about half a second — press w and the robot lurches forward, then stops on its own even though the key’s still very much held down.

Turns out keydown fires once per press, and after that the browser’s own key-repeat kicks in — which is inconsistent across OSes, has a noticeable initial delay, and isn’t something we should be relying on for “keep the motor running.” Worse: Post 1 built a 1-second watchdog into the STM32 side specifically so a dropped connection stops the wheels instead of leaving them spinning — and a keydown that fires once and then goes quiet for a while looks exactly like a dropped connection to that watchdog.

Fix was the same pattern the wheel sliders already used for drag events, just driven by a timer instead of input events — track which keys are currently down in a Set, and re-send the current vector on a plain interval for as long as any of them are held:

setInterval(() => {
  if (keyboardDriving) drive(...keyboardVector(), false);
}, SEND_INTERVAL_MS);

keydown/keyup just add/remove from the set; the interval is what actually keeps commands flowing often enough to stay ahead of the watchdog.

The keyup that never comes

Second gotcha, found by alt-tabbing away mid-drive without letting go of w first: the robot kept driving. keyup only fires if the browser is still the one listening — alt-tab, clicking outside the page, anything that steals focus, and the browser just stops delivering key events altogether. No keyup, so our held-keys set never clears.

window.addEventListener('blur', () => {
  if (pressedKeys.size === 0) return;
  pressedKeys.clear();
  keyboardDriving = false;
  drive(0, 0, true);
});

Losing focus now stops the robot immediately instead of waiting out the watchdog’s full second — which, at “robot with wheels in a hallway,” felt like the actually-important version of this bug, not just a nice-to-have.

community.element14.com/.../20260813_5F00_02_5F00_demo_5F00_joystick_5F00_control_5F00_web.mp4

What’s next

The joystick makes driving nicer, but you’re still driving blind — next up is the camera, so this actually becomes the “puppy on a leash from your phone” post the original plan promised.

The codes

https://github.com/tamadillo/hall-w-EV

— Hambreros (and Tamadillo)

Hall-w-EV - Post 2 - Giving the robot a voice

tamadillo — Thu, 13 Aug 2026 04:28:09 GMT

Hi again, it’s Hambreros and Tamadillo. Last post the robot learned to roll Post 1 - The wheels are turning (mostly). This post it learned to make noise — sound effects, an air raid siren, an announcement system, and it can even talk now. Getting there was way more of an adventure than the wheels were, mostly because the bug wasn’t actually a bug, it was a whole container we didn’t know existed.

What we’ve actually built

The control web page now has a “Sound System” panel underneath the wheel controls:

A grid of sound effects like laser blasts and guns reloading
An Air Raid Siren, and an AusAlert tone (853Hz and 960Hz played together) inspired by Australia’s emergency phone-alert system
Text-to-speech (TTS) announcements — inspired by “Giant Voice” systems we’ve seen in videos from Middle East conflict zones and school lockdown drills, telling you to “shelter in place”. Partly inspired by the new Arduino App Lab update, which mentions TTS bricks.
A volume slider, and a big SHUT UP button, because once you give a robot a siren you will absolutely need a way to make it stop

And most recently: cruising music, so it can play a track while it drives around. More on why that one was trickier than it sounds in a minute.

Hardware distraction

The Braitenberg vehicle chassis we’re using is inherently unstable. Two wheels and a stopper meant it would often tip during testing. Inspired by the pantographs on trains that pass our back yard, as well as drones that can land and stick to a moving object, we tried to build a self-correcting leg system for our EV.

community.element14.com/.../20260813_5F00_drone_5F00_land_5F00_and_5F00_cling_5F00_web.mp4

https://www.instagram.com/p/DboDwK_gXT7 credit Zaruba

This took a bunch of experimenting and time. In the end the results weren’t that good, and we realised that once we finally attached a camera to the setup, we’d also need to compensate and auto-correct the camera to point at the horizon.

In the end we dropped the idea and moved on with a couple of wooden blocks.

TTS no work

As the UNO Q updated to the latest firmware of Arduino App Lab, we got briefly excited that there might also be a neural text-to-speech option built in (an actual AI voice model instead of the classic robot monotone) — and there is one, arduino:tts. Got all the way to testing it before finding out it’s built specifically for the new Ventuno Q board and not supported by the UNO Q.

Turns out Arduino just announced the VENTUNO Q. Our UNO Q has 2GB of RAM and no AI chip. VENTUNO Q packs a Qualcomm Dragonwing IQ‑8275 — a proper 40 TOPS neural processor — plus 16GB of RAM, specifically so it can run real local AI: computer vision, offline AI assistants running local speech models, that kind of thing. The neural TTS brick we found needs that NPU to run at all, so on our board it was never going to work — not a bug, just the wrong hardware for the job. There are a couple of overview videos from embedded world if you want to see it in action: developer walkthrough, demo reel. But let’s not let the inspiration of TTS go to waste, after scrounging around we worked out we can use the unix espeak-ng for the talking instead.

Here’s where it got interesting. The siren and the AusAlert tone worked first try. Wav/MP3 Sound effects and text-to-speech? Dead silent. No errors, no sound, nothing.

First theory: volume. Turned out to be half right — the board’s speaker volume genuinely was too low by default, and cranking it with amixer fixed some of it. But effects and TTS still didn’t work, even after that.

Second theory, once we actually looked: the programs we needed (mpg123 for mp3s, espeak-ng for the talking) just weren’t installed. Fair enough, we thought — sudo apt-get install them and done. Except we did that, and which mpg123 on the board clearly showed it existed. So why couldn’t our own code find it?

Turns out: the robot’s Python code doesn’t actually run directly on the board’s Linux. It runs inside a Docker container — basically a little sealed box with its own separate copy of everything. We’d installed the programs onto the board itself, not into the box our code was actually running in. Two completely different places, both called “the board” if you’re not paying attention. Once we docker exec‘d into the actual container and installed things there instead, everything clicked into place — almost. Even that had one more gotcha: the container’s default user isn’t allowed to install anything (Permission denied on a folder called apt/lists/partial, if you’re curious), so it needed:

docker exec -u root hall-w-ev-main-1 apt-get install -y espeak-ng

-u root = “no really, let me actually install this.” Small thing, cost us an hour.

Finding the good stuff

While we were down in that container digging around, we found something way better than what we were looking for: Arduino ships their own official audio tools baked right in — arduino.app_peripherals.speaker.Speaker. It’s a proper Python class for playing sound directly, no external programs needed at all.

As mentioned above, the VENTUNO Q’s TTS brick was kind of cool to stumble into by accident while debugging a sound effect — but a dead end for now. We’re sticking with the classic robot voice, which honestly suits an emergency-siren robot better anyway.

Since the TTS brick’s code is public, we went and actually read it out of curiosity, and it turns out it does basically the same chunk-and-check-cancelled trick we were about to build by hand, just with a lot more going on underneath:

It doesn’t run the AI voice model in the same program at all — it makes a network request to a separate always-on service and streams the audio back as the model generates it, piece by piece, instead of waiting for the whole sentence to finish.
Long text gets split at up to 1024 characters, cut on the last ./!/? it can find before the limit, so it doesn’t chop a sentence in half — smarter than our “just cut it off at 300 characters and hope.”
Cancelling has to happen in two places: locally (stop feeding audio to the speaker) and remotely (tell the AI service currently mid-sentence over the network to actually stop generating).
There’s even a “warmup” — the instant it starts up, it quietly synthesizes the word “ok” to itself, just so the neural network is already loaded by the time you need it for real, instead of your first sentence being the slow one.

Kind of validating, honestly. The “cut it into pieces, check a flag between each one” idea wasn’t a hack we made up — it’s the same shape of solution the actual Arduino engineers reached for. Theirs just has a neural network and a network request bolted on the front of it.

The Speaker class was the real win though. The simple way to use it plays a whole sound start-to-finish with no way to interrupt it — fine for a short laser blast, useless for “stop the siren right now.” So instead we feed it small chunks (a tenth of a second each) in a loop, and check “should I stop?” between every single chunk:

def _stream_pcm(speaker, sample_rate, channels, samples, stop_event):
    chunk_len = max(1, int(sample_rate * 0.1)) * channels
    for i in range(0, len(samples), chunk_len):
        if stop_event.is_set():
            break
        speaker.play(samples[i:i + chunk_len])

That’s the whole trick behind the SHUT UP button, and behind “press the siren again while it’s already going” restarting it cleanly instead of two sirens fighting each other.

Making espeak-ng actually stick around

Remember that docker exec -u root ... apt-get install espeak-ng fix from earlier? It worked great — for one restart. Then we rebooted the board again and it was just gone. Turns out installing something into a running container by hand doesn’t actually stick — the container gets rebuilt from scratch every time you redeploy, and “by hand” doesn’t survive being rebuilt. Cool, so our talking robot’s voice box was actually a ticking time bomb this whole time.

We did not want to just re-run that command forever every time we updated the code. So: real fix time.

We remembered seeing a brick_compose.yaml mentioned in Arduino’s own code while we were poking around earlier, and it turns out there’s a whole custom bricks feature for exactly this — you can package up your own little service, container and all, as part of your app. Every example of it we could find online only used pre-built images though, never a Dockerfile you write yourself, so we genuinely didn’t know if that part actually worked or if we’d be wasting an evening.

Quick test first: a throwaway folder with just a Dockerfile that installs espeak-ng and then does nothing (sleep infinity), wired up as a brick. Restarted the app to see what would happen.

It built the Dockerfile. For real. Docker log spam and everything, right there in the deploy output — our own robot, building its own container image, from a text file we wrote, installing a package with full root access and zero permission drama, because this time it’s happening at build time, not sneaking in through docker exec afterward.

So we built the actual thing: a tiny container that does nothing but run espeak-ng behind a dead-simple web server —

# POST /synthesize {"text": "...", "voice": "en-us+m3", "speed": 150}
result = subprocess.run(
    ['espeak-ng', '--stdout', '-v', voice, '-s', speed, text],
    capture_output=True, timeout=10,
)
# ...and send result.stdout back as the response body

— and now the main robot code just sends it a sentence over the network and gets a WAV file back, instead of running espeak-ng itself. Since the whole container gets rebuilt from that same Dockerfile every single time we deploy, there’s nothing left to mysteriously vanish. Tested it properly too — full restart, both containers rebuilt from nothing, and the robot could talk again immediately, no manual fixing required. That’s the actual fix, not a “seems fine for now.”

Cruising music (without a 50MB file)

Last thing: we wanted the robot to play a music track while driving around — cruising music. Obvious approach: convert the song to the same format as the sound effects. Except the effects are only a few seconds long, and this song is almost 5 minutes — converted the “simple” way, it would’ve turned a 7MB mp3 into something like 50MB sitting on the robot for no reason.

So instead of converting the whole song upfront, it gets decoded a tiny piece at a time, right as it’s needed, and each piece goes straight into the same chunk-player from before. The song is never sitting fully unpacked in memory or on disk, and we get to reuse all the cancel/restart logic we’d already built.

the sound board controls

community.element14.com/.../20260813_5F00_demo_5F00_hall_2D00_w_2D00_EV_5F00_sound_5F00_board.mp4

What’s next

Camera + remote driving — the “puppy on a leash from your phone” post

The codes

https://github.com/tamadillo/hall-w-EV

— hambreros (and tamadillo )

EVA Guardian[Part_4] - The Battery Management System

Sumanth_m_n — Mon, 10 Aug 2026 18:40:28 GMT

In my previous post, “EVA Guardian: The Incident Detection System,” I explored the safety side of the project, where the Arduino UNO Q and MPU6500 were used to detect different vehicle motion patterns using Edge AI. While detecting an accident is important, there is another equally important question for an electric vehicle:

What is happening to the battery that powers the vehicle?

Previous forum posts

Part 1: The Idea behind EVA Guardian
Part 2: The Architecture of EVA Guardian
Part 3: The Incident detection System in EVA Guardian

For this part of EVA Guardian, I started building the Battery Management and Battery Profiling Node.

The objective of this module is to continuously measure the battery's voltage, current and temperature, and use these parameters to derive meaningful battery information such as State of Charge (SoC), State of Health (SoH), energy usage and battery condition.

For the first prototype, I built the complete measurement circuitry on a veroboard and interfaced it directly with the Arduino UNO Q.

The Battery Management Approach

The battery used for this prototype is a 2-cell 18650 Li-ion battery pack connected in series. Each cell has a nominal voltage of approximately 4.2 V, giving a fully charged voltage of approximately 8.4 V. For the initial prototype, I am using an HX-2S-A2 2S BMS protection board to provide the basic battery protection functionality.The Arduino UNO Q is then used as the monitoring and intelligence layer above the protection circuit.

The basic architecture is:

Battery → BMS → Voltage / Current / Temperature Measurement → Arduino UNO Q → Battery Analytics

The three primary measurements are:

Battery voltage
Battery current
Battery temperature

These measurements form the foundation for the higher-level battery calculations that I plan to implement.

Building the Measurement Circuit

For the first hardware prototype, I assembled the voltage, current and temperature measurement circuits on a veroboard.

The three analogue measurements are connected to the Arduino UNO Q as follows:

Arduino UNO Q	Measurement
A0	Battery Current
A1	Battery Voltage
A2	Battery Temperature

This keeps the measurement interface simple and gives me a clear separation between the three primary battery parameters.

1. Battery Voltage Measurement

The battery pack can reach 8.4 V, which is higher than the Arduino UNO Q's analogue input range. Therefore, I cannot directly connect the battery voltage to the ADC. I used a 6.8 kΩ and 3 kΩ resistor voltage divider to scale the battery voltage down to a suitable level for measurement. The divided voltage is then passed through an LF412 op-amp configured as a buffer before being connected to the Arduino UNO Q. The buffer provides a high-impedance interface between the voltage divider and the ADC, helping prevent the ADC input from significantly loading the divider.

The scaled voltage is connected to:

Arduino UNO Q → A1

The software then converts the measured ADC voltage back into the actual battery voltage using the calibrated divider ratio. This gives me the first fundamental parameter required for battery profiling.

2. Current Measurement Using ACS723

The second important parameter is battery current. For this, I am using the ACS723 current sensor.The sensor provides an analogue output proportional to the current flowing through it. For my setup, the sensor output is approximately 1.70 V at zero current, which becomes the reference or zero-current point. The current sensitivity used in my implementation is approximately 1.336 V/A.

Therefore, the Arduino UNO Q measures the ACS723 output through:

A0 → ACS723 Current Sensor

The software then uses the calibrated zero-current offset and sensitivity to determine the actual battery current.

This allows the system to determine whether the battery is:

Charging
Discharging
Idle

and also provides the current value required for power and energy calculations.

3. Battery Temperature Measurement

Temperature is another critical parameter for a Li-ion battery. For the prototype, I am using a 10 kΩ NTC thermistor attached to the battery module. The thermistor is combined with resistor networks to generate a temperature-dependent voltage that can be measured by the Arduino UNO Q.

The midpoint of the resistor network is connected to:

Arduino UNO Q → A2

As the battery temperature changes, the resistance of the NTC changes, which produces a corresponding change in the measured voltage. The software can then convert this ADC measurement into an estimated battery temperature. Monitoring temperature becomes particularly important when analysing high-current charging and discharging conditions.

Bringing Voltage, Current and Temperature Together

Individually, voltage, current and temperature provide useful information. But the real value comes from looking at all three together.

The Arduino UNO Q continuously acquires:

Voltage + Current + Temperature

From these measurements, I can calculate additional battery parameters such as:

Battery power
Charging/discharging state
Energy consumption
Open-circuit voltage
State of Charge
State of Health
Battery operating conditions

This is where the project begins moving from a simple battery monitoring system toward a battery profiling and intelligence system.

Estimating State of Charge

Determining the exact state of charge (SOC) of a battery pack isn't as simple as checking a voltage level. If you only look at voltage, it sags significantly when you draw a load (discharging) and rises when you apply a charger. To solve this, our Battery Management System (BMS) uses a Hybrid SOC Algorithm combining Coulomb Counting and Open-Circuit Voltage (OCV) Recalibration.

Here is how the algorithm works:

1. Real-Time Tracking: Coulomb Counting

During active operation, the BMS tracks the flow of current in and out of the battery second-by-second.

The Math: Capacity (Ah) = Current (A) * Time (hours)
Charge Efficiency: When discharging (negative current), energy is drawn directly. When charging (positive current), a 98% Coulombic efficiency multiplier is applied to account for chemical and thermal losses during charge conversion.
The Benefit: It responds instantly to sudden load changes and updates the SOC in real-time, regardless of voltage sags.

2. Auto-Calibration: OCV Lookup Table + Rest Timer

Over time, current sensors accumulate tiny measurement errors (drift), which causes Coulomb counting to become inaccurate. To correct this drift, I use an OCV Lookup Table (LUT) containing the chemistry's non-linear voltage-to-capacity curve.

However, voltage is only a true representation of SOC when the battery chemistry has relaxed (neutralized).

The Rest Timer: The BMS continuously checks if the battery is "at rest" (current < 50mA).
The Relaxation Window: Once the battery remains at rest for 60 continuous seconds, the algorithm trusts the voltage reading.
Recalibration: The OCV lookup table calculates the true chemical SOC, and the Coulomb counter (accumulatedAh) is calibrated back to this exact value, erasing any accumulated sensor drift.

3. Smart Boot Synchronization

Since SOC is volatile, standard systems often write the SOC to EEPROM constantly, causing premature flash wear.

Our hybrid algorithm solves this by only saving long-term health parameters (SOH and Cycle count) to EEPROM. When the system powers up:

It waits for the power rail to stabilize.
It takes an averaged, direct voltage measurement.
It snaps the Coulomb counter to match this OCV reading on boot.

This guarantees the system never boots up showing a stale or incorrect 0% SOC even if you swap in a different pack.

Energy and Coulomb Tracking

Current measurement also allows me to track the amount of charge flowing into and out of the battery.By integrating current over time, I can estimate the accumulated charge in coulombs or ampere-hours. Combining current with voltage also allows the system to calculate instantaneous power and accumulated energy.

This information will eventually help me understand:

How much energy the battery delivers
How much energy is consumed by the load
Charging energy
Discharging energy
Battery efficiency

These measurements will also provide useful data for the battery profiling stage.

Battery State of Health

SoC tells me:

How much charge is available right now?

But SoH asks a different question:

How healthy is the battery compared with when it was new?

For this project, I want to use the data collected during repeated charging and discharging cycles to study battery degradation.

Parameters such as:

Available capacity
Charge/discharge behaviour
Voltage response
Temperature behaviour
Current profile
Cycle count

can be analysed to estimate battery health.

This will eventually become one of the more interesting parts of the Battery Management Node, where I plan to explore data-driven and ML-based battery health estimation.

Using the Arduino UNO Q LED Matrix

I also wanted to make the battery information visible without requiring a laptop. The Arduino UNO Q provides an onboard LED matrix, so I decided to use it to display the current State of Charge percentage.

For example:

75%

can be displayed directly on the LED matrix. As the battery is discharged, the displayed value updates accordingly. This provides a simple visual indication of battery status and also makes the system much more engaging during a live demonstration.

Software Architecture

The Arduino UNO Q continuously performs the following sequence:

Read ADC → Convert to Physical Value → Filter/Calibrate → Calculate Battery Parameters → Update LED Matrix → Update Telemetry

The three ADC channels are sampled periodically:

A0 → Current

A1 → Battery Voltage

A2 → Temperature

The raw ADC values are then converted into meaningful engineering units using the calibration parameters of each sensor. The processed values can then be used for the higher-level battery calculations.

Code Implementation

The software is being developed in stages, starting with reliable sensor acquisition and calibration before moving towards the battery intelligence layer.

Some of the important parts of the implementation include:

ADC acquisition
ACS723 current calculation
Battery voltage calculation
NTC temperature calculation
SoC estimation
Coulomb counting
Power and energy calculation
Battery status monitoring
LED matrix SoC display

// Force high-resolution ADC in setup()
analogReadResolution(14); 

// Exponential Moving Average filter configuration
const float FILTER_ALPHA = 0.1f;
bool isFirstRead = true;

void readSensors() {
  // Read raw inputs
  float rawCurrent = readACS723Current();
  float rawVoltage = readVoltageDivider();
  float rawTemp    = readNTCTemperature();

  // Smooth signals using EMA Filter
  if (isFirstRead) {
    systemCurrent     = rawCurrent;
    systemVoltage     = rawVoltage;
    systemTemperature = rawTemp;
    isFirstRead       = false;
  } else {
    systemCurrent     = FILTER_ALPHA * rawCurrent + (1.0f - FILTER_ALPHA) * systemCurrent;
    systemVoltage     = FILTER_ALPHA * rawVoltage + (1.0f - FILTER_ALPHA) * systemVoltage;
    if (rawTemp > -900.0f) {
      systemTemperature = FILTER_ALPHA * rawTemp + (1.0f - FILTER_ALPHA) * systemTemperature;
    }
  }
}

This snippet shows the sensor acquisition routine configured for high-precision 14-bit ADC resolution (0 - 16383 counts) and smoothed using an Exponential Moving Average (EMA) filter to filter out switching noise

// Configuration parameters
const float CURRENT_ZERO_POINT_V       = 1.70f;  // Mid-point offset (V)
const float CURRENT_SENSITIVITY_V_PER_A = 1.336f; // V/A sensitivity

// Conversion logic
int   currentADC  = analogRead(CURRENT_PIN);
float currentPinV = ((float)currentADC / ADC_MAX_VALUE) * ADC_REF_VOLTAGE;

// Calculate current (negative = discharge/load, positive = charging)
float rawCurrent  = (currentPinV - CURRENT_ZERO_POINT_V) / CURRENT_SENSITIVITY_V_PER_A;

The current is calculated using an ACS723 Hall-Effect sensor. Negative current denotes discharge (load connected), and positive current denotes charging

// Configuration parameters (6.8K and 3K resistors)
const float R1_VOLTAGE_DIVIDER = 6800.0f;
const float R2_VOLTAGE_DIVIDER = 3000.0f;
const float VOLTAGE_MULTIPLIER = (R1_VOLTAGE_DIVIDER + R2_VOLTAGE_DIVIDER) / R2_VOLTAGE_DIVIDER;

// Conversion logic
int   voltageADC  = analogRead(VOLTAGE_PIN);
float voltagePinV = ((float)voltageADC / ADC_MAX_VALUE) * ADC_REF_VOLTAGE;

// Scaling to calculate full pack voltage
float rawVoltage  = voltagePinV * VOLTAGE_MULTIPLIER;

The total battery voltage is calculated by scaling the voltage at the divider pin back to the full pack voltage using the calculated scaling multiplier.

// Configuration parameters
const float NTC_VCC                = 5.0f;
const float NTC_R_FIXED            = 3300.0f;
const float NTC_R_SERIES           = 3300.0f;
const float NTC_NOMINAL_RESISTANCE = 10000.0f;
const float NTC_NOMINAL_TEMP       = 298.15f; // 25 C
const float NTC_BETA               = 3950.0f;

// Steinhart-Hart conversion logic
int   tempADC   = analogRead(TEMP_PIN);
float tempPinV  = ((float)tempADC / ADC_MAX_VALUE) * ADC_REF_VOLTAGE;
float rawTemp   = -999.0f;

if (tempPinV > 0.01f) {
  float rNTC    = (NTC_VCC * NTC_R_FIXED / tempPinV) - (NTC_R_FIXED + NTC_R_SERIES);
  if (rNTC > 0.0f) {
    float s = log(rNTC / NTC_NOMINAL_RESISTANCE);
    s = (s / NTC_BETA) + (1.0f / NTC_NOMINAL_TEMP);
    rawTemp = (1.0f / s) - 273.15f; // Kelvin to Celsius conversion
  }
}

The thermistor temperature is processed using the Steinhart-Hart equation to convert NTC resistance changes into Degrees Celsius

// 1. Coulomb Counter integration (runs every 100ms)
void integrateCoulombs(unsigned long timeDeltaMs) {
  float dt_hours = (float)timeDeltaMs / 3600000.0f;

  if (systemCurrent > 0.0f) {
    // Charging: apply coulombic efficiency (98%)
    accumulatedAh += systemCurrent * CHARGE_EFFICIENCY * dt_hours;
  } else {
    // Discharging: subtract directly
    accumulatedAh += systemCurrent * dt_hours;
  }

  // Hard clamp accumulated capacity inside limits
  if (accumulatedAh > persistentState.actualMaxCapacityAh) accumulatedAh = persistentState.actualMaxCapacityAh;
  if (accumulatedAh < 0.0f) accumulatedAh = 0.0f;
}

// 2. Hybrid OCV Calibration and SOC calculation
void calculateSOC() {
  bool isAtRest = (fabs(systemCurrent) < REST_CURRENT_THRESHOLD_A);

  if (isAtRest) {
    rest_timer_ms += READ_INTERVAL_MS;
  } else {
    rest_timer_ms = 0; // Current flow resets the rest timer
  }

  // Recalibration: only trust OCV when battery has rested (60 seconds)
  if (rest_timer_ms >= REST_DURATION_MS) {
    float ocvSOC = get_soc_from_ocv(systemVoltage);
    accumulatedAh = (ocvSOC / 100.0f) * persistentState.actualMaxCapacityAh;
    rest_timer_ms = 0; // Reset calibration trigger
    Serial.println("Coulomb counter recalibrated using resting OCV.");
  }

  // Calculate final system SOC
  systemSOC = (accumulatedAh / persistentState.actualMaxCapacityAh) * 100.0f;
  if (systemSOC > 100.0f) systemSOC = 100.0f;
  if (systemSOC <   0.0f) systemSOC =   0.0f;
}

This snippet integrates Coulomb counting during current flow (applying charging efficiency) and runs the rest-timer OCV recalibration when the battery relaxes.

void render_soc(float soc) {
  // Convert float SOC to rounded 2-digit integer
  int soc_int = (int)(soc + 0.5f);
  if (soc_int > 99) soc_int = 99;
  if (soc_int < 0) soc_int = 0;

  // Lock buffer to prevent race conditions during rendering
  k_mutex_lock(&matrix_mtx, K_FOREVER);
  clear_matrix_buf();

  if (soc_int >= 10) {
    int tens = soc_int / 10;
    int units = soc_int % 10;
    render_digit(tens, 1, 7);  // Left digit (cols 1-5)
    render_digit(units, 7, 7); // Right digit (cols 7-11)
  } else {
    render_digit(soc_int, 4, 7); // Center single digit (cols 4-8)
  }

  flush_matrix_locked(); // Output buffer to Arduino LED matrix hardware
  k_mutex_unlock(&matrix_mtx);
}

This snippet shows how a custom pixel font renders the SOC integers, safely locked behind Zephyr RTOS mutexes to ensure thread safety while writing to the matrix buffer.

From Battery Monitoring to Battery Intelligence

At this stage, the system can measure the three most important physical parameters:

Voltage → Current → Temperature

But this is only the beginning. The ultimate goal of this Battery Management Node is not simply to display these values.

I want the system to understand what these measurements mean.

For example, instead of simply showing:

Temperature = 42°C

the system should eventually be able to determine:

⚠️ Battery temperature is increasing faster than expected.

Instead of only displaying:

SoH = 78%

the system could eventually provide:

⚠️ Battery degradation detected. Battery inspection recommended.

Similarly, abnormal combinations of voltage, current and temperature could be used to identify potential battery anomalies. This is where the collected battery data will become extremely valuable for battery profiling and predictive maintenance features planned for EVA Guardian.

Testing the Battery Management System

The next stage is to systematically test the measurement system under different operating conditions.

I plan to test the battery during:

Charging
Idle/resting
Low-current discharge
High-current discharge
Different temperature conditions
Different SoC levels

The goal is to compare the measured values against reference measurements and calibrate the system before using the data.Therefore, the initial focus is on making sure that the voltage, current and temperature measurements are reliable and repeatable.

Demonstration Video

I have also recorded a demonstration of the Battery Management Node showing the hardware setup, sensor measurements and real-time SoC display on the Arduino UNO Q LED matrix.

https://youtu.be/LWDSxiQ9Io4

What's Next?

With the basic Battery Management Node now assembled, the next stage of EVA Guardian is to bring the individual modules together into a complete safety and monitoring system. The first step will be to integrate the Battery Management System (BMS) and Incident Detection System (IDS) so that battery information and vehicle safety information can be monitored together.

The integrated system will focus on:

Battery voltage, current and temperature monitoring
SoC and battery operating status
Overvoltage, undervoltage and overcurrent protection
Vehicle motion and incident detection
Accident detection
Distance and trip information
Real-time system status

I will also be implementing a safety relay and automatic power switching mechanism. The objective is to allow the system to respond to critical conditions by automatically controlling the battery/load power path. A backup power source will also be incorporated to keep essential functions such as the safety controller and emergency communication operational when required.

Finally, I will bring all the information together through a web-based interface, providing a single dashboard for monitoring both the battery and vehicle safety systems.

The overall system will therefore evolve from two independent prototypes into a connected platform:

Battery Management + Incident Detection → Safety Control → Automatic Power Management → Web Monitoring

The next phase will focus on this system-level integration and demonstrating how EVA Guardian can continuously monitor the EV, detect abnormal conditions, take appropriate safety action, and provide the user with a clear view of the vehicle's overall health and safety status.

Github Repo: https://github.com/ForgedCircuits/EVA-Guardian.git

DockBot - Part 4 - Getting the Arduino Q to move the tank motors

arvindsa — Mon, 10 Aug 2026 06:04:12 GMT

Recap

I am building a robotic system that identifies the charging port on an EV and automatically moves a charger arm to plug the charger in.

Past Forum Posts:

This part is about turning the Devastator chassis from Part 3 into something that actually drives, and getting the Arduino UNO Q to be the one driving it.

The new motors and chassis mods

In the last post I mentioned that the Devastator Chassis motors were burnt out and I had ordered a All Gear Motors, I received my motors went ahead and installed the replacement all-metal BO motor and found two problems - one I'd anticipated, one I hadn't. The original Yellow BO motors were L-shaped; the replacement is straight. Before I even ordered it I had checked for collisions and found that a flange with a nut, which connects the roof of the platform to the side, would be in the way. Fix for that is to cut the flange and replace it's functionality with a 3D printed bracket.

Below is a video of me modding the Chassis. Watch it only if you love watching such logs. Its a bore for others.

community.element14.com/.../p4_2D00_v2.mp4

The second problem was new: a little plastic stub that I think holds one of the gears in place looked mechanically identical to the original but wasn't quite. There was a minor location difference, Had to drill out the location hole to get it to fit.

Both motors installed, tracks back on, and I confirmed both spin the right way before moving on to electronics.

The electronics

The Arduino UNO Q becomes the brain of the whole platform. The Qualcomm Dragonwing QRB2210 side runs Linux and acts as the overall controller - it'll receive positioning data from the Radxa Q6A about where the robot and the car actually are. The STM32U585 side handles the real time motor control loop through a DRV8833 driver.

As a mechatronics engineer I know that manufacturing differences between motors - different inertia and friction in the gear train, different friction in the track and wheel system - mean the two motors won't turn at exactly the same speed for the same commanded voltage. Sometimes you get lucky and the mismatch is tiny, but I didn't want to bet on luck, so I planned ahead for an encoder on each motor shaft, which is why I bought motors with a shaft on both ends in the first place. I'll be using a TLE5012B as a non-contact magnetic encoder for that - not wired up yet, more on that below. I am using TLE5012B just because I have surplus of it from another project, But there are more easier to procure and easier to interface encoders available.

For power, I'm using a 3500mAh 2S 7.4V Li-ION battery. The Arduino Q gets powered through its VIN pin (official power spec). During testing I found it needs a minimum of 6.7V to run reliably - the official docs say 7V, but that's presumably for full-load conditions. The motors are rated at 6V, so a buck converter in parallel brings that down to 5.9V before it reaches the motors via the DRV8833.

I made a custom perfboard PCB to house the DRV8833, a screw terminal for battery in, the motor leads, and a 2.54mm JST-XH connector carrying the 6V rail into the driver. The one snag: the battery uses a female T-Deans connector, and I didn't have a matching male one on hand. I had to do a makeshift, admittedly dangerous workaround to get power flowing for bench testing. I would not recommend anyone do what I did - that battery has a high discharge rate and is a genuine fire hazard if shorted. I've ordered the correct connector; whether it arrives before the submission deadline is a different question.

Perfboard driver PCB - DRV8833, screw terminals, JST-XH power in

The code

For Arduino UNO Q programming, I'm building on the work from the last design challenge - On the Line - where I disabled the bridge between the Dragonwing Linux side and the STM32, giving the STM32 full bare-metal control instead of going through the Arduino sketch layer. Same STM32CubeMX HAL project setup carried over, pins reassigned for this board.

For now I'm deliberately skipping the encoder and any PID control - the goal of this post is just getting the hardware moving, closed-loop speed control is a separate step.

The wire protocol between the Linux side and the STM32 is a tiny line-based ASCII format:

M <left> <right>   set track motor speeds, -255..255 each
S <id> <angle>     set servo <id> (0 or 1) to <angle> degrees, 0-180
H                  halt (motors only)

with a 500ms command-timeout fail safe in STM32 firmware - if no valid line shows up within that window it halts the motors on its own, so a crashed Linux-side process can't leave the tank driving into something:

void UartProtocol_Poll(void)
{
  if (s_line_ready) {
    s_line_buf[s_line_len] = '\0';
    handle_line(s_line_buf);
    s_line_len = 0;
    s_line_ready = 0;
  }

  if (HAL_GetTick() - s_last_command_ms > COMMAND_TIMEOUT_MS) {
    Motor_Stop();
  }
}

First bench test immediately turned up two bugs. One was the usual - the left motor's direction sense was wired backwards relative to the `M <left> <right>` sign, so a positive command drove it in reverse. Easy fix, just invert it in software rather than rewire anything.

The second one took longer to track down. With the DRV8833's DIR pin held HIGH, the driver alternates full-drive and brake every PWM cycle instead of the documented drive/coast behavior - so with DIR high, a small commanded duty was actually the fastest the motor would go, and a large duty stalled it. Completely backwards from what I expected. Once I figured that out, complementing the duty (`255 - magnitude`) whenever DIR is HIGH fixed it:

static uint32_t compute_duty(int16_t speed)
{
  uint32_t magnitude = (uint32_t)(speed < 0 ? -speed : speed);
  return speed < 0 ? 255U - magnitude : magnitude;
}

Both directions now scale proportionally from zero on the bench. There's still a small deadband near zero but that is due to the the PWM having too less duty to overcome the static friction. I'll deal with that later.

For actually driving the thing during bench testing, I have to credit the author of Hall W EV - Post 1 - The Wheels Are Turning (Mostly) tamadillo and hambreros for the idea of hosting a web UI directly on the UNO Q for manual control. I would have made a python tkinter GUI to tun on host computer. Only difference is I set mine up by hand instead of through App Lab - a plain Python http.server handler that serves a page with sliders and posts JSON to /api/drive, /api/servo, /api/halt, which get relayed straight down the serial link to the STM32:

community.element14.com/.../p4_2D00_v1.mp4

Since the STM32 halts on a 500ms silence, the page has to keep resending the current slider values every 150ms while a slider is held - releasing it (or hitting Stop) sends H and stops the resend loop. I later added +/-1 and +/-5 bump buttons alongside the drag sliders, for the fine adjustments that are basically impossible to hit by dragging a slider with a mouse.

What's next

Encoder wiring and a basic speed-control loop are next on the STM32 side (Assuming the Diametrically polarized magnets come in time), then getting the Linux side actually talking guidance over the serial link instead of me driving it by hand with sliders with the Radxa showing the absolute positioning.

Final Notes

Devastator Chassis is a tank again. I feel I should some RGB lights, What do you say?

Forum - Recent Threads

DockBot - Part 6 - The Mostly Open Closed Loop Control

Motor Calibration. Take 1

Motor calibration, take 2

Actually approaching a target: three wrong designs first

Final Notes

SmartAssist EV - Mobile Robot Control and Live Video Streaming - Part 7

5. Program Initialization (setup)

The Master Blueprint, The Integration Wall, and Mechanical Realities

SmartAssist EV - Strict Priority Hierarchy with Tactile Mechanical Bumpers - Part 6

1. Pin Definitions and Escape Speed

2. Sensor Initialization in setup()

3. Safety Hierarchy Logic in loop()

Step 1: Read Bumper States (Binary Code)

Priority 1: Physical Impact Response (Bumpers)

Priority 2: Proactive Distance Check (HC-SR04 Sonar)

Behavior: If an obstacle is detected within 30 cm, the robot performs a short left turn 30ms to steer around the obstacle before physical contact happens.

Priority 3: Line Following Routine

Project GEPARD V5.0 - Post 4: Proof of Concept Docking

The Mechanical PoC Video

The Docking Interface & RS485 Handshake

Power Delivery and the 12.85V Boost

The Cold-Launch Relay Sequence

Sentinel Mode Power State

Safe Undocking & The BMS Takeover

The INA226 Telemetry Mystery & Charge Cut-Off

SmartAssist EV - Non-Contact Proactive Shielding (HC-SR04 Range Finder) - Part 5

Essential Code Snippets Related to the Ultrasonic Sensor

1. Hardware Pin Definitions

2. Pin Setup in setup()

3. Distance Measurement Routine (getDistance())

4. Obstacle Avoidance Logic in loop()

Vape Cell EV - part V - 18650 vs Vape Cell

Recap

18650 vs Vape Cell

Conclusion

Next

Source

Vape Cell EV - part IV - On battery charging

Recap

Challenges

What I learnt

Up Next

Source

SmartAssist EV - Introducing Autonomous Line Following (TCRT5000) - Part 4

Hardware Wiring Diagram

1. Left Tracking Sensor (TRACKING_PIN_L)

2. Right Tracking Sensor (TRACKING_PIN_R)

Pin Mapping Summary

Electrical Notes

Line Tracking Code Snippets

1. Sensor Pin Definitions

2. Pin Configuration in setup()

3. Operational Mode Toggle (MODE_AUTONOMOUS)

4. Sensor Reading & Differential Motor Control Loop

Logic Summary

SmartAssist EV - Wireless Command and H-Bridge Direct Drive - Part 3

Pin Mapping Table

Key Code Sections

1. Libraries and Hardware Definitions

2. LED Matrix Graphics Arrays

3. Onboard RGB LED Helper Functions

4. Low-Level IR Signal Decoder (readElecrowIR)

5. Motor Control and Command Execution

6. System Setup and Main Loop (setup & loop)

SmartAssist EV - Hardware Platform - Part 2

SmartAssist EV – Experimental Smart Assistive Platform for Elderly and Disabled People - Part 1

DockBot - Part 5 - The Mechanical Hand

Recap

The actuator design

The mock charger design

The grabber design

Final Notes

Vape Cell EV - part III - INA219 power monitor

Recap

INA219

Wire.begin() isn’t optional

Current without voltage

A silent JSON truncation

The display

5. Program Initialization (`setup`)

2. Sensor Initialization in `setup()`

3. Safety Hierarchy Logic in `loop()`

2. Pin Setup in `setup()`

3. Distance Measurement Routine (`getDistance()`)

4. Obstacle Avoidance Logic in `loop()`

1. Left Tracking Sensor (`TRACKING_PIN_L`)

2. Right Tracking Sensor (`TRACKING_PIN_R`)

2. Pin Configuration in `setup()`

3. Operational Mode Toggle (`MODE_AUTONOMOUS`)

4. Low-Level IR Signal Decoder (`readElecrowIR`)

6. System Setup and Main Loop (`setup` & `loop`)

Complete Integrated System Demonstration
https://youtu.be/ZM7amrmEOIg