Forum - Recent Threads

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.

[View:https://youtu.be/ciR2tdJ3-0Y:640:360]

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

[View:https://youtu.be/ZFzXiJqRlYU:640:360]

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
[View:https://youtu.be/ZM7amrmEOIg:640:360]

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

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

Communication Fault Detection

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

Power Connector Degradation

[View:https://youtu.be/ZFzXiJqRlYU:640:360]
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

[View:https://youtu.be/CVnq63eEgyo:640:360]
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

RE: EVA Guardian[Part_5] - The Integrated System

Sudarshan_Hegde — Mon, 24 Aug 2026 15:49:39 GMT

Sumanth_m_n , that looping back technique and finding out the communication error in cable is a very nice idea. Overall intersting topic.

RE: EVA Guardian[Part_5] - The Integrated System

Sumanth_m_n — Mon, 24 Aug 2026 09:05:43 GMT

An additional fault detection method that I find particularly compelling involves the implementation of a voltage measurement system across various nodes. While this system would be compact and simple, it would significantly enhance a long-term system analysis capabilities.

RE: EVA Guardian[Part_5] - The Integrated System

Sumanth_m_n — Mon, 24 Aug 2026 09:03:22 GMT

Yes, DAB .

A communication fault represents the most critical vulnerability within any multi-node system.

Given the availability of the self loopback feature on this RS485 transceiver, accessible via jumpers, I was able to successfully implement this functionality.

RE: Hall-w-EV - Post 3 - Joystick control

hambreros — Mon, 24 Aug 2026 04:37:57 GMT

thanks - yeah it was cool that from a basic 1 servo spins, to a robot that moves around was not that much work - just 2 servos spins but at the right rate - the fact that the servos are identical and one is on the opposite side so turning backwards through us a little bit

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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:06978c4b-e36a-4c2c-8bec-4a724181f156:type=c_cpp&text=def%20mix_drive%28x%2C%20y%29%3A%0A%20%20%20%20x%20%3D%20max%28-100%2C%20min%28100%2C%20int%28x%29%29%29%0A%20%20%20%20y%20%3D%20max%28-100%2C%20min%28100%2C%20int%28y%29%29%29%0A%20%20%20%20return%20max%28-100%2C%20min%28100%2C%20y%20%2B%20x%29%29%2C%20max%28-100%2C%20min%28100%2C%20y%20-%20x%29%29]

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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:d47811d9-5485-43f0-89a7-52476c0b82a9:type=c_cpp&text=%23define%20WHEEL1_REVERSED%20false%0A%23define%20WHEEL2_REVERSED%20true%0A...%0AservoFrame%28SERVO1_PIN%2C%20speedToPulseUs%28WHEEL1_REVERSED%20%3F%20-wheel1Speed%20%3A%20wheel1Speed%29%2C%0A%20%20%20%20%20%20%20%20%20%20%20SERVO2_PIN%2C%20speedToPulseUs%28WHEEL2_REVERSED%20%3F%20-wheel2Speed%20%3A%20wheel2Speed%29%29%3B]

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.

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:8ca6e1ea-33ed-4b4c-83c7-2b7d2dad2fde:type=c_cpp&text=static%20void%20servoFrame%28int%20pin1%2C%20unsigned%20int%20pulse1Us%2C%20bool%20enable1%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20int%20pin2%2C%20unsigned%20int%20pulse2Us%2C%20bool%20enable2%29%20%7B%0A%20%20%20%20if%20%28enable1%29%20%7B%0A%20%20%20%20%20%20%20%20digitalWrite%28pin1%2C%20HIGH%29%3B%0A%20%20%20%20%20%20%20%20delayMicroseconds%28pulse1Us%29%3B%0A%20%20%20%20%20%20%20%20digitalWrite%28pin1%2C%20LOW%29%3B%0A%20%20%20%20%7D%0A%20%20%20%20%2F%2F%20...same%20for%20pin2%2Fenable2%0A%7D]

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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:44a77e00-8e0e-4f9f-b833-020571a160b2:type=c_cpp&text=setInterval%28%28%29%20%3D%3E%20%7B%0A%20%20if%20%28keyboardDriving%29%20drive%28...keyboardVector%28%29%2C%20false%29%3B%0A%7D%2C%20SEND_INTERVAL_MS%29%3B]

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.

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:2d5b2cdf-8311-4451-9f40-22fd9236615d:type=javascript&text=window.addEventListener%28%27blur%27%2C%20%28%29%20%3D%3E%20%7B%0A%20%20if%20%28pressedKeys.size%20%3D%3D%3D%200%29%20return%3B%0A%20%20pressedKeys.clear%28%29%3B%0A%20%20keyboardDriving%20%3D%20false%3B%0A%20%20drive%280%2C%200%2C%20true%29%3B%0A%7D%29%3B]

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.

[View:/cfs-file/__key/communityserver-discussions-components-files/456/20260813_5F00_02_5F00_demo_5F00_joystick_5F00_control_5F00_web.mp4:640:360]

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.

[View:/cfs-file/__key/communityserver-discussions-components-files/456/20260813_5F00_drone_5F00_land_5F00_and_5F00_cling_5F00_web.mp4:640:360]

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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:c90c6dd6-bc9d-4d5c-8a83-32b1a234feaf:type=batchfile&text=docker%20exec%20-u%20root%20hall-w-ev-main-1%20apt-get%20install%20-y%20espeak-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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:b8a4db98-573d-4870-99c3-ec3c00aabef5:type=c_cpp&text=def%20_stream_pcm%28speaker%2C%20sample_rate%2C%20channels%2C%20samples%2C%20stop_event%29%3A%0A%20%20%20%20chunk_len%20%3D%20max%281%2C%20int%28sample_rate%20%2A%200.1%29%29%20%2A%20channels%0A%20%20%20%20for%20i%20in%20range%280%2C%20len%28samples%29%2C%20chunk_len%29%3A%0A%20%20%20%20%20%20%20%20if%20stop_event.is_set%28%29%3A%0A%20%20%20%20%20%20%20%20%20%20%20%20break%0A%20%20%20%20%20%20%20%20speaker.play%28samples%5Bi%3Ai%20%2B%20chunk_len%5D%29]

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 —

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:37fa5c2a-0e2e-48b3-b1a6-22aded524273:type=c_cpp&text=%23%20POST%20%2Fsynthesize%20%7B%22text%22%3A%20%22...%22%2C%20%22voice%22%3A%20%22en-us%2Bm3%22%2C%20%22speed%22%3A%20150%7D%0Aresult%20%3D%20subprocess.run%28%0A%20%20%20%20%5B%27espeak-ng%27%2C%20%27--stdout%27%2C%20%27-v%27%2C%20voice%2C%20%27-s%27%2C%20speed%2C%20text%5D%2C%0A%20%20%20%20capture_output%3DTrue%2C%20timeout%3D10%2C%0A%29%0A%23%20...and%20send%20result.stdout%20back%20as%20the%20response%20body]

— 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

[View:/cfs-file/__key/communityserver-discussions-components-files/456/20260813_5F00_demo_5F00_hall_2D00_w_2D00_EV_5F00_sound_5F00_board.mp4:640:360]

What’s next

Camera + remote driving — the “puppy on a leash from your phone” post

The codes

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

— [mention:73a531dd49a044558f94d68fa340763b:e9ed411860ed4f2ba0265705b8793d05] (and [mention:0ede6c1c051849c0a39ea19c96a98013:e9ed411860ed4f2ba0265705b8793d05] )

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

hambreros — Mon, 24 Aug 2026 04:36:21 GMT

they did get stuck a little on the floor boards but OK, we also got some wheel slippage, we had covered the wooden wheels with some old bike tube rubber but still got some slippage like I noticed you mentioned in community.element14.com/.../dockbot---part-6---the-mostly-open-closed-loop-control

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

tamadillo — Sun, 23 Aug 2026 23:21:54 GMT

thanks - it is so cool that you can plug a camera in and next thing you have a FPV remote control car

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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:ef2ef448-3ffa-4fb5-bcbc-f4e48e522ac4:type=python&text=from%20arduino.app_peripherals.camera%20import%20Camera%0A%0Acamera%20%3D%20Camera%28%22usb%3A0%22%2C%20resolution%3D%28640%2C%20480%29%2C%20fps%3D15%29%0Acamera.start%28%29%0Aframe%20%3D%20camera.capture%28%29%20%20%20%23%20numpy%20array%2C%20or%20None%0A%23%20or%3A%20for%20frame%20in%20camera.stream%28%29%3A%20...]

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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:515c29f5-6d50-41a6-9ca3-935666d372e0:type=html&text=%3Cimg%20id%3D%22cameraFeed%22%20src%3D%22%2Fapi%2Fcamera%2Fstream%22%20alt%3D%22Live%20camera%20feed%22%3E]

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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:cc9ee16d-5887-4699-b0d5-15f1c32a49c1:type=javascript&text=cameraFeed.addEventListener%28%27error%27%2C%20%28%29%20%3D%3E%20%7B%0A%20%20cameraFeed.style.display%20%3D%20%27none%27%3B%0A%20%20fetch%28%27%2Fapi%2Fcamera%2Fstatus%27%29.then%28r%20%3D%3E%20r.json%28%29%29.then%28data%20%3D%3E%20%7B%0A%20%20%20%20cameraError.hidden%20%3D%20false%3B%0A%20%20%20%20cameraError.textContent%20%3D%20data.error%20%7C%7C%20%27camera%20stream%20unavailable%27%3B%0A%20%20%7D%29%3B%0A%7D%29%3B]

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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:8a857f0a-1d9f-411b-b561-fd207e92cf35:type=python&text=def%20_start%28%29%3A%0A%20%20%20%20global%20_camera%2C%20_error%0A%20%20%20%20try%3A%0A%20%20%20%20%20%20%20%20cam%20%3D%20Camera%28SOURCE%2C%20resolution%3DRESOLUTION%2C%20fps%3DFPS%29%0A%20%20%20%20%20%20%20%20cam.start%28%29%0A%20%20%20%20%20%20%20%20_camera%20%3D%20cam%0A%20%20%20%20except%20Exception%20as%20e%3A%0A%20%20%20%20%20%20%20%20_error%20%3D%20str%28e%29%0A%0Athreading.Thread%28target%3D_start%2C%20daemon%3DTrue%29.start%28%29]

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

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:bc573021-4957-485a-8705-cd1bdd0613d4:type=python&text=%40%20web.route%28%27%2Fapi%2Fcamera%2Fstream%27%29%20%23%20space%20added%20not%20to%20look%20like%20email%20address%0Adef%20camera_stream%28%29%3A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%23%20which%20flags%20the%20post%20as%20inappropriate%0A%20%20%20%20ok%2C%20error%20%3D%20camera.status%28%29%0A%20%20%20%20if%20not%20ok%3A%0A%20%20%20%20%20%20%20%20return%20jsonify%28%7B%27ok%27%3A%20False%2C%20%27error%27%3A%20error%7D%29%2C%20503%0A%20%20%20%20return%20Response%28camera.mjpeg_frames%28%29%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20mimetype%3D%27multipart%2Fx-mixed-replace%3B%20boundary%3Dframe%27%29]

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

[View:/cfs-file/__key/communityserver-discussions-components-files/456/2352.20260816_5F00_hall_2D00_w_2D00_EV_2D00_w_2D00_camera.mp4:640:360]

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 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 [emoticon:2aeeb716c0ca40469e4afae40f662cd1] in front of it and the robot drives itself towards it, no hands.

What we’ve actually built

A [emoticon:2aeeb716c0ca40469e4afae40f662cd1] 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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:c0798960-382b-495c-9b94-dfb21580f6ea:type=python&text=model_by_boards%3A%0A%20%20%20%20-%20platform%3A%20ventunoq%0A%20%20%20%20%20%20model%3A%20yolox-qnn-object-detection%0A%20%20%20%20-%20platform%3A%20unoq%0A%20%20%20%20%20%20model%3A%20yolox-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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:8731bb3f-a577-48c3-aaa0-3d7534130cf0:type=python&text=-%20sports%20ball]

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.

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:0b40e522-601d-46c4-aa81-b0a4d0be7b68:type=python&text=from%20arduino.app_bricks.video_objectdetection%20import%20VideoObjectDetection%0A%0Adetector%20%3D%20VideoObjectDetection%28camera%3Dshared_camera%2C%20confidence%3D0.5%29%0Adetector.on_detect%28%22sports%20ball%22%2C%20on_ball_detected%29%0Adetector.start%28%29]

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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:f939f894-4d61-423d-a4b4-61739e51d40b:type=python&text=def%20get_camera%28%29%3A%0A%20%20%20%20%22%22%22Blocks%20until%20the%20startup%20attempt%20above%20has%20settled%2C%20then%20returns%20the%0A%20%20%20%20shared%20Camera%20instance%20%E2%80%94%20or%20None%20if%20it%20never%20started%20successfully.%22%22%22%0A%20%20%20%20_ready.wait%28%29%0A%20%20%20%20return%20_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 [View:https://www.youtube.com/watch?v=JFTJ2SS4xyA:640:360]

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:4f3480a9-3132-49bc-9030-3be48aae448e:type=python&text=def%20_steer_towards%28bbox%29%3A%0A%20%20%20%20x1%2C%20y1%2C%20x2%2C%20y2%20%3D%20bbox%0A%20%20%20%20frame_w%2C%20frame_h%20%3D%20camera.RESOLUTION%0A%20%20%20%20center_x%20%3D%20%28x1%20%2B%20x2%29%20%2F%202%0A%20%20%20%20box_h%20%20%20%20%3D%20max%281%2C%20y2%20-%20y1%29%0A%0A%20%20%20%20offset%20%20%20%20%20%3D%20%28center_x%20-%20frame_w%20%2F%202%29%20%2F%20%28frame_w%20%2F%202%29%20%20%23%20-1%20..%20%2B1%0A%20%20%20%20size_ratio%20%3D%20box_h%20%2F%20frame_h%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%23%200%20..%201%0A%0A%20%20%20%20turn%20%20%20%20%20%3D%20max%28-100%2C%20min%28100%2C%20offset%20%2A%20TURN_GAIN%29%29%0A%20%20%20%20throttle%20%3D%20max%280%2C%20min%28MAX_THROTTLE%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%28TARGET_SIZE_RATIO%20-%20size_ratio%29%20%2F%20TARGET_SIZE_RATIO%20%2A%20MAX_THROTTLE%29%29%0A%20%20%20%20return%20turn%2C%20throttle]

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.

[View:/cfs-file/__key/communityserver-discussions-components-files/456/20260816_5F00_hall_2D00_w_2D00_EV_2D00_chase_2D00_ball.mp4:640:360]

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)

RE: hall-w-EV - Post 5 - Chase ball

tamadillo — Sun, 23 Aug 2026 23:20:53 GMT

thanks, it was a relief to see the robot could actually see and zero in on the ball

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 [emoticon:ad09a845b95e4cb28c5d9684a032037c]. 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[emoticon:d3f592d49e434d7fb67e973881d4c367] 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

RE: Vape Cell EV - part IV - On battery charging

saramic — Sun, 23 Aug 2026 10:50:59 GMT

yeah there is a bunch of changes I have seen recently - all battery packs on a flight are meant to be within hands reach - of course they cannot be too powerful 100wh or around 27,000 mAh seems to be the limit, local trains no longer allow homemade/converted e-bikes and scooters and there are a bunch of building codes for home batteries

RE: Vape Cell EV - part IV - On battery charging

kmikemoo — Sun, 23 Aug 2026 02:19:53 GMT

There's a reason that some municipalities are requiring battery storage systems be placed outside the main house. While it's highly unlikely that your battery storage system will catch fire, if it does... the consequences are pretty significant.

RE: Challengers, Post your Projects!

JoRatcliffe — Fri, 21 Aug 2026 14:58:13 GMT

Great project submissions and updates, everyone! I will announce the winners on Monday, have a good weekend 🙂

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: [mention:9b0ab29684b5482d90716e7898532942:ca0e7c8086864d2fa5a863b9e212e922]

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 [mention:ef3eff32a0cb4cc7a5e89891f461c343:e9ed411860ed4f2ba0265705b8793d05] will forgive you, but you have to let us know.

Good luck [emoticon:c4563cd7d5574777a71c318021cbbcc8]

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

[View:/cfs-file/__key/communityserver-discussions-components-files/456/20260817_5F00_220222.mp4:640:360]

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

[View:/cfs-file/__key/communityserver-discussions-components-files/456/p6_2D00_v1.mp4:640:360]

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.

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:b8aa06b1-7c78-4be8-8c8d-3f63d3deaeb7:type=python&text=heading%20%3D%20%28rx1%20-%20rx0%2C%20rz1%20-%20rz0%29%20%20%20%23%20where%20the%20robot%27s%20own%20marker%20moved%0Abearing%20%3D%20%28goal_x%20-%20rx1%2C%20goal_z%20-%20rz1%29%20%20%20%23%20where%20the%20goal%20is%20from%20here%0Aangle%20%3D%20signed_angle_deg%28%2Aheading%2C%20%2Abearing%29%20%2A%20turn_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.

[View:/cfs-file/__key/communityserver-discussions-components-files/456/trial.mp4:800:450]

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.

RE: DockBot - Part 6 - The Mostly Open Closed Loop Control

arvindsa — Fri, 21 Aug 2026 00:54:14 GMT

Thanks.

RE: DockBot - Part 5 - The Mechanical Hand

arvindsa — Fri, 21 Aug 2026 00:53:13 GMT

Thank you.

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."

[View:/cfs-file/__key/communityserver-discussions-components-files/456/p5_2D00_v1.mp4:800:450]

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)

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

DAB — Thu, 20 Aug 2026 19:34:31 GMT

Nice update.

RE: hall-w-EV - Post 5 - Chase ball

DAB — Thu, 20 Aug 2026 19:32:11 GMT

Nice update.

RE: Vape Cell EV - part III - INA219 power monitor

DAB — Thu, 20 Aug 2026 19:31:14 GMT

Nice update.

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.

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:7337141d-2622-4e78-abc2-ef7cd293b9fb:type=c_cpp&text=void%20setup%28%29%20%7B%0A%20%20%20%20Bridge.begin%28%29%3B%0A%20%20%20%20Wire2.begin%28%29%3B%20%20%20%2F%2F%20i2c3%3A%20A4%3DSDA%2C%20A5%3DSCL%0A%20%20%20%20%2F%2F%20...%0A%7D]

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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:6df77249-3235-476d-957a-89e0d886a5d6:type=text&text=%5Bbridge%2Fconfig%5D%20Expecting%20%27%2C%27%20delimiter%3A%20line%201%20column%2029%20%28char%2028%29]

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

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:e7958989-4306-4b0d-915c-bf6e70ace7aa:type=c_cpp&text=char%20addrStr%5B6%5D%3B%0Asnprintf%28addrStr%2C%20sizeof%28addrStr%29%2C%20%22%5C%220x%2502X%5C%22%22%2C%20sensors%5Bi%5D.addr%29%3B]

"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

Forum - Recent Threads

EVA Guardian[Part_5] - The Integrated System

When Battery Management Meets Incident Detection

Creating a Master–Slave Architecture

Designing My Own Communication Protocol

Master Request

BMS Response

Why Poll Every Two Seconds?

From Separate Telemetry to Combined Telemetry

But What Happens When Communication Stops?

Failure 1

Failure 2

Failure 3

Step 1 – Wait for the BMS

Step 2 – Test the IDS RS485 Transceiver

Step 3 – Test the BMS RS485 Transceiver

Step 4 – So Where Is the Problem?

Communication Cable Fault

[View:https://youtu.be/ciR2tdJ3-0Y:640:360]

Why I Wanted This Diagnostic Capability

Another Problem: What Happens to the Power Connector?

Monitoring the Power Connection

BMS-side voltage

IDS-side voltage

Detecting Connector Degradation

Detecting a Broken Connection

[View:https://youtu.be/ZFzXiJqRlYU:640:360]

Making Accident Detection More Reliable

Preventing Telegram Alert Flooding

The Complete Data Flow

Vehicle Dynamics

Battery

Diagnostics

Power Connector

Emergency Response

And Now... Let's Break It

Complete Integrated System Demonstration[View:https://youtu.be/ZM7amrmEOIg:640:360]

Automatic Power Switching

Communication Fault Detection

Power Connector Degradation

Moving From Electronics to a Vehicle

The Finishing Touch

What Has Changed?

What's Next?

Final Thoughts

RE: EVA Guardian[Part_5] - The Integrated System

RE: EVA Guardian[Part_5] - The Integrated System

RE: EVA Guardian[Part_5] - The Integrated System

RE: Hall-w-EV - Post 3 - Joystick control

Hall-w-EV - Post 3 - Joystick control

What we’ve actually built

Keeping the mixing in one place

Mirrored servos, mirrored bug

A real OFF switch

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

The keyup that never comes

What’s next

The codes

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

What we’ve actually built

Hardware distraction

TTS no work

Finding the good stuff

Making espeak-ng actually stick around

Cruising music (without a 50MB file)

What’s next

The codes

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

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

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

What we’ve actually built

Checking what the framework already gives you

The dumbest frontend that works

Starting the camera without blocking everything else

What’s next

The codes

hall-w-EV - Post 5 - Chase ball

What we’ve actually built

Finding the right brick

No training required — just check the label list

Complete Integrated System Demonstration
[View:https://youtu.be/ZM7amrmEOIg:640:360]