https://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/Smart systems on wheels! Create a prototype smart electric vehicle or smart system for a next generation of vehicles.en-USTelligent Community 12https://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/m/managed-videos/151555Wed, 05 Aug 2026 20:02:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:430490aa-4182-4cdd-b9ca-c31402cbb73bSumanth_m_nIn this video, I demonstrate the Incident Detection System developed as part of the EVA Guardian project for the element14 EZ-EV Smart Transport Challenge. The system uses an Arduino UNO Q SBC and a GY-91 (MPU6500) IMU to perform real-time Edge AI...https://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57152/eva-guardian---the-incident-detection-systemWed, 05 Aug 2026 20:02:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:851102e7-c344-4191-aed1-a01c7acf001aSumanth_m_nIn the previous two posts, I introduced the vision behind EVA Guardian and explained the complete system architecture that combines an intelligent Battery Management System with a Safety & Emergency Node. The battery management system focuses on understanding the health of the EV's energy source, while the safety node is responsible for monitoring the vehicle's motion and responding when something abnormal happens. Part 1: The Idea behind EVA Guardian Part 2: The Architecture of EVA Guardian In this third post, I want to focus entirely on the second half of the project—the Incident Detection System . This is the part of EVA Guardian that continuously watches how the vehicle moves, understands whether the motion is normal or abnormal, and acts as the first layer of the emergency response system. Unlike conventional systems that rely solely on fixed acceleration thresholds, I wanted to explore whether Edge AI running directly on the Arduino UNO Q could intelligently distinguish between different types of vehicle movements and detect potential accident scenarios. The Idea Behind This Module The Incident Detection System continuously reads motion data from an MPU6500 IMU connected to the Arduino UNO Q. The collected motion data is processed locally and passed into a custom Edge Impulse machine learning model. Instead of only measuring acceleration, the model attempts to classify the complete motion pattern into meaningful events.If the ML model detects an accident or abnormal motion event, the system immediately transitions into emergency mode. At that point, an automatic notification is sent through a Telegram Bot, allowing the users relative or friends to receive an instant alert on their smartphone, motion status, and detection results in real time. The objective is to demonstrate that intelligent safety features can be implemented entirely on low-cost embedded hardware. Hardware Used The primary hardware components include: Arduino UNO Q SBC GY-91 IMU Module (MPU6500 + BMP280) Arduino UNO Q LED Matrix (Available in UNo Q SBC) Demo Smartphone Wi-Fi Connection The Arduino UNO Q acts as the central processing unit, acquiring sensor data, running the Edge ML model, updating the LED matrix display, hosting the WebUI dashboard, and communicating with the Telegram Bot. The MPU6500 provides six-axis motion data consisting of three-axis acceleration and three-axis angular velocity, making it suitable for recognizing different vehicle motion patterns. Software Stack Instead of writing everything from scratch, Arduino App Lab provides several software bricks that can be combined to build complete applications. For this project, I used the following components: FastIMU Library Motion Detection Brick Telegram Bot Brick WebUI Brick LED Matrix Library Each of these components contributes to a different part of the application. The FastIMU library handles communication with the MPU6500 sensor. The Motion Detection Brick provides the interface for running my custom Edge Impulse model. The LED Matrix library drives the onboard LED matrix to display vehicle tilt. The Telegram Bot Brick enables instant emergency notifications. Finally, the WebUI Brick creates a live dashboard that can be accessed directly from a web browser. Together, these software components allow the Arduino UNO Q to become a compact edge AI platform. Training My Own Edge AI Model One of the most exciting aspects of this project was developing a custom Edge AI model specifically for the Arduino UNO Q, rather than relying on a generic pre-trained model. My objective was to train the model using data collected from the exact hardware configuration that would eventually perform real-time inference, ensuring that the deployed model accurately reflects the characteristics of the target platform. To build the dataset, I interfaced the GY-91 MPU6500 IMU with the Arduino UNO Q and recorded approximately 11 minutes of motion data . During the data collection process, I performed various controlled movements to represent different operating conditions of the vehicle. The collected data was manually labelled into five motion classes: Accident Idle Front and Back Right and Left Up and Down These labels were chosen to represent both normal vehicle movements and abnormal events, enabling the model to distinguish between everyday motion patterns and potential accident scenarios. After importing the dataset into Edge Impulse , I designed an impulse using a Power Spectral Density (PSD) processing block followed by a Classification block. Rather than using the raw accelerometer samples directly, the PSD block transforms the sensor data into the frequency domain, extracting meaningful frequency characteristics from the motion signals. This approach helps the model identify subtle differences between various motion patterns that may not be easily distinguishable in the time domain alone. The resulting feature extraction process generated 39 input features , which were then fed into a fully connected neural network classifier. To balance classification performance with the limited computational resources available on the Arduino UNO Q, I selected a lightweight neural network architecture consisting of: Input Layer: 39 extracted PSD features First Dense Layer: 20 neurons Second Dense Layer: 10 neurons Third Dense Layer: 5 neurons Output Layer: Softmax classifier with five output classes The model was trained for 50 epochs using a learning rate of 0.0005 . This training configuration provided a good balance between model convergence and generalization while keeping the network compact enough for deployment on an embedded platform. Once the training process was complete, Edge Impulse generated an optimized EIM (Edge Impulse Model) that could be executed directly on the Arduino UNO Q. The trained model was then integrated into Arduino App Lab using the Motion Detection Brick , allowing the Arduino UNO Q to perform real-time, on-device inference . This means that all motion classification is executed locally on the embedded hardware without requiring cloud connectivity or an external processing unit, making the system faster, more responsive, and suitable for edge AI applications where low latency and offline operation are essential. {gallery}Motion Detection Machine Learning model Displaying Vehicle Tilt angle on the LED Matrix To better demonstrate the real-time capabilities of the MPU6500 IMU, I also developed a simple yet intuitive electronic water level indicator using the Arduino UNO Q's onboard LED matrix. The animation continuously estimates the board's tilt angle from the IMU data and represents it as a moving water level. As the board is tilted, the "water" naturally flows towards the lower side of the display, closely mimicking the behaviour of a physical spirit level. Although this feature is not directly related to the incident detection algorithm, it serves as an excellent visual demonstration of the IMU's responsiveness and the Arduino UNO Q's onboard LED matrix capabilities. It also provides an easy way to verify that the sensor orientation and tilt calculations are functioning correctly in real time. This small demonstration showcases how sensor data can be transformed into an intuitive and interactive visualization, making the system easier to understand and more engaging during live demonstrations. Emergency Notifications Using Telegram The final stage of the workflow focuses on emergency communication. When the machine learning model identifies an accident event, the Arduino UNO Q automatically sends a notification through the Telegram Bot. This demonstrates how a low-cost embedded system can immediately notify a user without requiring dedicated communication hardware. For the current prototype, the notification contains information about the detected event like accident detection. In the future, this feature will be extended to include GPS coordinates from the Safety Node so that emergency contacts receive both the alert and the vehicle location. This fits perfectly with the overall EVA Guardian vision introduced in my first blog, where the Incident Detection System forms the first step of the complete emergency response workflow. {gallery}Telegram Notifications and Status Bringing Everything Together The complete software workflow can be summarized as follows: MPU6500 IMU → Arduino UNO Q → Edge ML Inference → Event Classification → LED Matrix Display → Telegram Notification During normal operation, the Arduino continuously acquires motion data from the IMU. The Edge ML model classifies the incoming data into one of the trained motion categories. If the system detects normal movement, the LED matrix continues displaying the vehicle tilit. If an accident is detected, the system immediately changes state and sends an emergency notification through Telegram accordingly. This demonstrates how multiple software components can work together to build a complete embedded safety application. Code Highlights Arduino App Lab made it possible to build this application by combining multiple software bricks into a single workflow. Some of the interesting parts of the implementation include: Initializing the FastIMU library Registering Motion Detection callbacks Running Edge ML inference Updating the LED matrix Sending Telegram messages Rather than showing the complete source code here, I would like to highlight a few important sections that demonstrate how these individual modules work together. /** * @brief Periodic IMU sampling worker function. * @details Reads raw accelerometer values, applies EMA filter, and dispatches data via Bridge. * @return void */ void update_imu_sample(void) { if (micros() - lastSampleTime >= SAMPLING_INTERVAL_US) { lastSampleTime += SAMPLING_INTERVAL_US; IMU.update(); IMU.getAccel(&accelData); float rawAccX = accelData.accelX; float rawAccY = accelData.accelY; float rawAccZ = accelData.accelZ; /* Exponential Moving Average (EMA) filtering */ if (isFirstSample) { filtAccX = rawAccX; filtAccY = rawAccY; filtAccZ = rawAccZ; isFirstSample = false; } else { filtAccX = (ALPHA * rawAccX) + ((1.0f - ALPHA) * filtAccX); filtAccY = (ALPHA * rawAccY) + ((1.0f - ALPHA) * filtAccY); filtAccZ = (ALPHA * rawAccZ) + ((1.0f - ALPHA) * filtAccZ); } /* Calculate total acceleration (normalized vector in m/s^2) neglecting gravity on Z */ float accX_ms2 = filtAccX * 9.8f; float accY_ms2 = filtAccY * 9.8f; float accZ_ms2 = filtAccZ * 9.8f; float accZ_ms2_no_g = accZ_ms2 - 9.8f; float totalAcc_ms2 = sqrt(accX_ms2 * accX_ms2 + accY_ms2 * accY_ms2 + accZ_ms2_no_g * accZ_ms2_no_g); /* Calculate tilt (roll) angle and animate water level indicator */ float roll_angle = atan2(-filtAccY, filtAccZ); render_water_level(roll_angle); /* Dispatch filtered telemetry to Python backend */ Bridge.call("record_sensor_movement", filtAccX, filtAccY, filtAccZ, totalAcc_ms2); } } This function periodically acquires accelerometer data from the MPU6500 at a fixed sampling rate. An Exponential Moving Average (EMA) filter is applied to reduce sensor noise and smooth the measurements before transmitting the filtered X, Y, and Z acceleration values to the Python backend via the Arduino Bridge. The clean sensor data is then used for real-time Edge AI inference. def run_inference(buffer: list) -> None: """! @brief Execute Edge Impulse ML motion classification inference. @param buffer List of float accelerometer features (126 elements). @return None """ try: result = motion_detection.infer_from_features(buffer) except Exception as e: logger.warning(f"Inference failed: {e}") return cls = result.get("result", {}).get("classification", {}) if not cls: return best = max(cls, key=cls.get) best_conf = cls.get(best, 0.0) logger.info(f"Classification: {best} ({best_conf:.2%})") with telemetry._state_lock: telemetry.state["last_classification"] = best telemetry.state["confidence"] = {k: round(v, 4) for k, v in cls.items()} count_key = best if best in telemetry.state["counts"] else "idle" telemetry.state["counts"][count_key] += 1 event = { "time": time.strftime("%H:%M:%S"), "date": time.strftime("%Y-%m-%d"), "classification": best, "confidence": round(best_conf, 4), } telemetry.state["history"].insert(0, event) if len(telemetry.state["history"]) > config.MAX_HISTORY: telemetry.state["history"] = telemetry.state["history"][: config.MAX_HISTORY] # Alert updates on state classification change if best == "Accident": alert_service.dispatch_accident_alert(bot, cls) This function performs real-time Edge AI inference using the trained Edge Impulse model. The classification result with the highest confidence is identified, and the system updates the current prediction, confidence scores, event history, and detection statistics. Based on the predicted motion, the application either triggers an accident alert via the Telegram Bot or updates the Arduino UNO Q LED matrix with the current vehicle tilt, enabling intelligent event detection and immediate user notification. def dispatch_accident_alert(bot: TelegramBot, cls: dict) -> None: """! @brief Dispatches emergency accident notification to all registered Telegram chats. @param bot TelegramBot instance. @param cls Classification confidence dictionary. @return None """ global _last_accident_ts now = time.time() if now - _last_accident_ts < config.ACCIDENT_COOLDOWN_S: logger.info("Accident alert skipped due to active cooldown period") return _last_accident_ts = now confidence_pct = round(cls.get("Accident", 0) * 100, 1) msg = ( "*CRITICAL ALERT: ACCIDENT DETECTED*\n" "-----------------------------------\n" f"Confidence Level: `{confidence_pct}%`\n" f"Timestamp: `{time.strftime('%Y-%m-%d %H:%M:%S')}`\n\n" "System: Arduino UNO Q Incident Monitor" ) alert_sent = False if known_chat_ids: for cid in list(known_chat_ids): for method_name in ["send_message", "send_text", "send"]: if hasattr(bot, method_name): try: getattr(bot, method_name)(cid, msg) alert_sent = True logger.info(f"Accident alert sent to Telegram chat {cid} via {method_name}") break except Exception as e: logger.warning(f"bot.{method_name}({cid}) failed: {e}") if not alert_sent and hasattr(bot, "broadcast"): try: bot.broadcast(msg) alert_sent = True logger.info("Accident alert broadcasted to Telegram users") except Exception as e: logger.warning(f"bot.broadcast failed: {e}") try: Bridge.notify("show_alert") except Exception as e: logger.warning(f"Bridge notification show_alert failed: {e}") This function generates and dispatches an emergency Telegram notification whenever the Edge AI model classifies an Accident . To prevent repeated alerts for the same event, a cooldown mechanism is implemented. The notification includes the model's confidence level, and timestamp, after which the Arduino UNO Q LED matrix is updated to indicate the emergency state. Demonstration Video Seeing the complete system operating in real time is much more informative than simply reading about it. I have therefore recorded a demonstration showing: Live IMU data acquisition Edge ML inference running on the Arduino UNO Q Vehicle tilt displayed on the LED matrix Telegram notification triggered after accident detection This demonstration provides a complete overview of how all the individual software modules interact to form the Incident Detection System. https://youtu.be/zca40p1B_FY Edge Impulse Repo: https://studio.edgeimpulse.com/studio/1076458 Githu Repo: https://github.com/ForgedCircuits/EVA-Guardian.gitdesign challengebattery management systemcarEVAL–ADM3068EEBZAccident detection systemuno qhttps://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/m/managed-videos/151551Sun, 02 Aug 2026 16:22:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:6b531a74-e095-48cb-8d58-51932ea7ad88saramichttps://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57148/vape-cell-ev---part-ii---rs485-commsSun, 02 Aug 2026 16:21:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:a6776b53-2f1d-484e-b4f7-2b72e9df9f24saramicI have been out on a few unplanned mid-winter trips (Southern Hemisphere here ) away from home which has put a huge deficit in my ability to deliver. Secondly I have been scratching my head watching a bunch of online videos mentioning how people have burnt their house down charging lithium batteries, let alone unlabelled ones from vapes. Also a bunch of contradictory advice on when to use a BMS (Battery Management System) and how to build one. For today I want to focus on the Design Challenge kit I was lucky to receive, and getting RS-485 up and running between 2 Arduino UNO Q’s using the EVAL-ADM3068EEBZ Evaluation Board. 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. Vape Cell EV - part I - What’s in a Vape The Design Challenge Kit The design challenge kit is made up of 2 UNO Q’s, Arduino module with a docker capable MPU attached, an evaluation board for the ADM3068E RS-485 Transceiver capable of 50 Mbps, some Molex connectors, access to LabView, some cool stickers and a metal Element 14 pin. I must say I am not much of a fan of the stickers but a pin is exactly the kind of identification you need in a crowd. Analog Devices EVAL-ADM3068EEBZ RS485 transceiver The Analog Devices EVAL-ADM3068EEBZ is a small breakout board for the ADM3068E RS485 transceiver. It has screw terminals for power, data and bus signals and is rated 50 Mbps . Worth mentioning that this figure seems to be based on a measurement at the transceiver’s own pins, essentially zero cable — a bench loopback number, not a claim about what survives a real cable run. RS485 is differential — data is the voltage difference between two wires, not one wire against ground — and that’s why the cable has to be a twisted pair specifically. The twist is what gives common-mode noise rejection and keeps the pair’s impedance consistent enough to match the 120 Ω termination resistors on the board. The classic rate-vs-distance rule of thumb (10 Mbps at ~12 m, 1 Mbps at ~120 m, 100 kbps at up to ~1200 m) is worth keeping in mind, even though I’m not yet sure exactly where RS485 will end up being used on my cell monitor — I’m fairly confident none of these distances or speeds will actually be needed. Which jumpers, though The eval board has seven jumpers ( LK1 – LK7 ) controlling driver/receiver enable, half- vs full-duplex wiring, and termination. Table 1 in the datasheet lays it all out, but in fairly technical terms — it took me a while to fully understand what each jumper actually did, and a few of them got plugged in by gut feel. The board ships configured for its own bench self-test : LK1=B (receiver always on), LK2=A (driver always on). That turned out to be genuinely useful: with LK4 / LK6 inserted (folding the chip’s full-duplex A/B/Y/Z pins into one half-duplex pair), the factory jumpers already give you a single-board loopback test for free — the same idea as a CAN controller’s internal loopback mode which I explored in my previous project Green Brain - Part I - CAN bus introduction . Whatever goes out DI comes straight back on RO , no second board or cable required. Good for smoke testing the sketch’s framing and checksum logic before anything else is wired up. I attempted to get half-duplex control working, which needs LK1=D , LK2=C — tying the driver enable ( DE ) and receiver enable ( RE̅ , active-low) together onto one control line, so a single GPIO can flip the whole board between transmit and receive. I got led astray for a while by some MCU (Micro Controller Unit) / MPU (Micro Processor Unit) interop quirks in Zephyr, which had me convinced this wasn’t working as expected. An echo test that barely touched the board The single-board loopback test worked nicely once the sketch’s UART code was right (more on that below) — but in hindsight it barely exercised anything RS485 -specific. Driver and receiver were both hard-wired permanently on; there was no direction switching, no real bus, no second board’s independent clock. Moving to the actual two-node config ( LK1=D , LK2=C , a twisted pair between two separate boards) immediately surfaced problems the echo test had no way of catching — which led me down the goose chase of the direction-control wire mentioned above, and a forgotten ground wire between the two boards’ RS485 sides. Neither would have mattered for a board looping back to itself. When two boards refuse to talk First symptom: total silence, on both boards, at every baud. Turned out my naive idea of sweeping baud rates on a timer was the culprit: int idx = (int)((millis() / STEP_MS) % NUM_BAUDS); millis() counts from each board’s own power-on, so two independently started boards drift out of phase almost immediately — over a 28-second full sweep they can end up spending the whole test on different baud rates from each other. Fix: pin both boards to a single fixed baud rate before attempting to sweep across multiple speeds. Still silence after that — after a bunch of wire changes, including the direction-control wire, the symptom finally changed from silence to garbage: real activity on the bus, but corrupted frames and a fast-climbing error count. To rule the transceiver out entirely, the next step was a direct crossover — UNO Q D1 straight to the other UNO Q’s D0 and back, no eval board in the loop at all: Node A D1 (TX) → Node B D0 (RX) Node A D0 (RX) ← Node B D1 (TX) shared GND between the two boards This should have been plain old UART between two boards — I’d even written up a simple example in a comment on my recent Smart Security and Surveillance Sentinel Box forum post . Instead, I got the same corruption. That single test ruled out the transceiver, the jumpers, and the bus wiring all at once — whatever was wrong was in the MCU/software layer, not the RS485 hardware. Back to the UART — the Serial trap The sketch had been writing to Serial , same as any Arduino sketch would. On real hardware, that hit a build error deep into an unrelated change: error: 'class BridgeMonitor<>' has no member named 'end' Serial on the UNO Q , it turns out, isn’t the physical UART at all once Arduino_RouterBridge.h is included. This is one of the recurring confusions of working across an MPU and an MCU — which one actually owns the pins, and which “serial” you’re really talking to. In this case it turned out to be the internal Bridge/Monitor channel used for debug printing: // Arduino_RouterBridge/src/monitor.h extern BridgeMonitor<> Serial; // aliased to the same object as Monitor Zephyr bit me again here — I’d run into similar MCU/MPU quirks before in Green Brain - Part II - Dev setup and had mostly learned to live with them. The fix was to skip the Arduino Serial / Stream wrapper and talk to the STM32’s usart1 peripheral directly through Zephyr’s own UART driver API: #include static const struct device* rs485_dev = DEVICE_DT_GET(DT_NODELABEL(usart1)); // uart_configure(rs485_dev, &cfg) — set baud at runtime // uart_poll_out(rs485_dev, byte) — blocking single-byte write // uart_poll_in(rs485_dev, &byte) — non-blocking single-byte read The buffer that wasn’t there With real hardware access sorted, a byte counter told the next story: the same-board loopback test was receiving exactly 2 bytes back for every 23-byte frame sent , every single time, regardless of baud. That precision ruled out noise and pointed at something structural — this UART has almost no receive buffering in polling mode, just a ~2-byte pipeline (shift register plus holding register). The original code wrote a whole frame in one blocking loop before ever checking for incoming bytes; on a looped-back wire the echo starts arriving while still transmitting, and without draining it concurrently, everything past the first couple of bytes was lost to overrun. Interleaving the write with polling reads fixed the same-board test cleanly. Cross-board traffic, though, stayed badly corrupted even at a generous 9600 baud — a rate that should have made timing-related errors rare. The clue came from an old, unrelated UART proof-of-concept in Smart Security and Surveillance Sentinel Box forum post , on completely different hardware, whose own comment explained why it just worked: // TMR_Delay is blocking for TICK_MS but the hardware RX FIFO // (32 bytes) holds incoming bytes while we wait. That MCU has a real 32-byte hardware FIFO. Ours has essentially none, and Zephyr — unlike that PoC’s bare-metal loop — is a genuine preemptive RTOS. Our loop() can be paused by other threads (the Bridge/RPC channel, USB, kernel housekeeping) for however long the scheduler decides, and with only a 2-byte cushion behind it, any such pause silently drops data no matter how carefully the polling loop is written. That’s a fundamentally different problem from “the baud rate is too high.” The real fix was getting reception off the polling loop entirely — a proper interrupt handler draining the peripheral into a ring buffer the instant a byte arrives, independent of whatever the main loop happens to be doing: static void rs485Isr(const struct device* dev, void* user_data) { while (uart_irq_update(dev) && uart_irq_rx_ready(dev)) { uint8_t b; while (uart_fifo_read(dev, &b, 1) == 1) { // push b into a ring buffer } } } // in setup(): uart_irq_callback_user_data_set(rs485_dev, rs485Isr, NULL); uart_irq_rx_enable(rs485_dev); The difference was immediate: the receiving board’s error count went from climbing continuously to 8 total (a brief startup transient) then flat zero across the next ~490 clean frames. Timing budgets that don’t scale with baud A smaller, satisfying bug fell out right behind the buffer fix: the fixed 50 ms reply timeout didn’t scale with baud. At 9600 baud a bare 23-byte round trip already takes ~48 ms on its own, leaving almost no slack for the other board’s own turnaround — late replies were routinely missing the deadline and landing during the next round instead, silently miscounted rather than just timed out. Scaled the timeout to 5× the theoretical round trip at the current baud, and it cleared up at 9600. It came back once bauds got extreme, just from the opposite direction. At 3,000,000 baud, a chunk of replies kept landing as mismatched rather than timed out — same symptom, different cause this time. The 5×-round-trip formula assumes overhead shrinks along with wire time, but the other board’s own turnaround (sync detection, checksum, flipping the transceiver direction, ordinary scheduler jitter) costs roughly the same wall-clock time no matter the baud — trivial next to 48 ms at 9600 baud, the dominant cost once wire time itself drops to ~150 µs at 3 Mbaud. Added a flat 5 ms floor on top of the scaled portion and that gap closed too. Two different bugs, same underlying lesson: a timing budget derived purely from bit-time doesn’t account for the parts of the round trip that don’t shrink with it. A wiring mix-up, and a way to test a driver with just a multimeter Wiring the real two-board bus (as opposed to the single-board loopback above) turned up one more of the “forgotten/misremembered wire” family: the UNO Q’s D0 and D2 pins got swapped on one board — RO (the transceiver’s data output) ended up wired to D2 , the direction-control pin, instead of D0 , the real hardware UART’s receive pin. Software has no way to notice this: D2 is just a GPIO the sketch actively drives, so it was fighting the transceiver’s own output on that pin the whole time, while the STM32’s real UART receiver sat on a disconnected, floating D0 . With no oscilloscope on hand, the multimeter still settled a real question: was a driver’s signal weak or was it not there at all ? A rapidly-toggling half-duplex signal only pulses “on” for a fraction of each round, so a plain DC meter, which effectively averages what it sees, reads a small fraction of the true swing even on a perfectly healthy line — 0.07–0.1 V measured this way is not the same claim as “the driver only makes 0.1 V.” Trick: force the driver into a steady state instead of a fast pulse, so the meter has something constant to read. Jumper the direction-control pin straight to 3V3 (driver permanently enabled, bypassing the MCU), disconnect the data input so nothing’s toggling it, then read across A/B. A healthy driver holds a steady 2–5 V that way; this one read 2.2–2.4 V, confirming the transceiver and its enable wiring were both fine — the fault really was the D0/D2 swap, not the chip. The vanishing frame With the wiring fixed, most frames arrived clean — but a fraction still failed, and only ever the same way: a complete, checksum-_invalid_ frame, every field correct except the very last byte. Random noise doesn’t behave like that; noise-corrupted bytes should be unpredictable, not the same wrong value every time. A raw hex dump (every byte of the frame, not just the derived pass/fail) confirmed it precisely: raw: A5 00 00 00 00 10 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F A5 sync , the 4-byte sequence number, len , all 16 payload bytes — every one matched (seq+i) mod 256 exactly. Only the final byte was wrong, and it was wrong in a very specific way: it always read back as 0xA5 — the sync byte, not a checksum. Dumping the transmit side too (bytes about to go out, not what came back) showed why: the sender was transmitting every sequence number in order, but the receiver only ever logged the even ones. Odd frames vanished completely — not corrupted, just gone. The receiver’s checksum slot for frame N was silently being filled by frame N+1’s real sync byte, and the rest of frame N+1 got scanned through as noise looking for the next sync match. Root cause: the delay before dropping the transceiver’s drive-enable line assumed 10 bit-times of margin was enough — one byte period — for the last byte to finish shifting out. It isn’t. The UART call used to write that byte only guarantees it moved into the transmit register once the previous byte vacated it — not that the previous byte finished transmitting. Worst case, the byte before the checksum can still have a full bit-time left to go, and the checksum byte itself hasn’t started: two byte periods needed, not one. That mismatch was exactly big enough to reliably clip the last byte’s transmission every single time — not occasionally, which is what made the “always exactly 0xA5 ” signature so recognisable once dumped raw. Doubling the margin fixed it outright: 100% clean, zero errors, hundreds of frames straight . Teaching the boards to run the sweep themselves With a fully clean 9600-baud link finally confirmed, it was worth rebuilding the automatic baud sweep — properly this time. The first attempt (mentioned above) swept bauds on a free-running timer and fell apart because two independently-booted boards’ clocks drift apart with nothing to re-anchor them. The fix: make 9600 a permanent “home” baud that’s proven reliable enough to carry its own handshake. One side sends a control frame — the same 23-byte frame format, told apart only by a different leading byte ( 0x5A instead of 0xA5 ), reusing every bit of the already-debugged build/checksum/echo code. The other side echoes it back as an acknowledgement — again, the exact same mechanism already used for ordinary data frames — and only then switches its own baud rate. First attempt at the control frame was just a bare pulse meaning “advance to your next rate,” relying on both boards independently counting their own position through the same compiled-in list. That worked fine until a board got restarted on its own (once autostart-on-boot was wired up) — its counter reset to zero while the other board’s didn’t, so the pulse still succeeded every time, each side just quietly advanced to a different rate. Fix: send the actual target baud — the real number, e.g. 115200 , packed as a 4-byte value straight into the control frame’s payload — instead of an index/offset into the shared list. One side is now the sole authority and the other just applies whatever number it’s handed, with no shared table position to keep in sync at all. Reverting back to 9600 needs no handshake at all — each side just counts down a short local timer (a few seconds) from the moment it entered the test baud, then reverts on its own. That only requires the two sides to enter the test baud within about one handshake round trip of each other, not to stay in sync for an entire run — so drift can never accumulate past a single short cycle, which is what actually broke the original design. Where things stand RS485 itself never turned out to be the problem — every wrong turn along the way was a jumper misunderstanding, a forgotten wire, or a software assumption two or three layers removed from the bus itself. The pattern that got through each one was the same: isolate ruthlessly (a bare wire loop instead of the transceiver, a direct crossover instead of the bus, a forced steady-state instead of a fast pulse for the multimeter), don’t trust an API name at face value ( Serial wasn’t Serial ), and let a raw byte dump settle an argument that theorising alone kept getting wrong. With the auto-sweep running end to end, here’s the actual reliability curve across a real two-node bus — twisted pair, real transceivers, real half-duplex turnaround — not a self-loop bench test and not a datasheet figure: Baud Success rate Round trip 9600 ~96–100% ~48 ms 19200 – 460800 ~98–100% scales with bit-time 921600 ~91% ~1.3 ms 1,000,000 ~95% ~1.4 ms 2,000,000 ~83.5% ~1.2 ms 3,000,000 ~60% ~1.1 ms Clean and reliable from 9600 all the way through 460800 baud. Real, gradual degradation starts around 921,600–1,000,000, and gets substantial by 2–3 Mbaud. Round trip time tracks bit-time almost exactly at every rate, with no artificial timeout ceiling distorting it anymore — this is the genuine electrical/timing ceiling, not a software one, and it’s a believable curve: nowhere near the 50 Mbps bench figure, but comfortably enough for a cell-monitor poll bus running well under 1 Mbaud. The video below shows 2 UNO Q’s connected to the ADM3068E eval board. The RS-485 boards are connected with a twisted pair. The screen displays an overkill display hosted on one of the UNO Q’s. At the top is the NODE, and anothr node connected. In the middle is the radar like view of the topology of the network, in this case a primary and a secondary. At the bottom are the logs of the various baud speeds being tested and a graph on the bottom right shows the link quality. community.element14.com/.../2026_2D00_08_2D00_03_5F00_2_5F00_node_5F00_RS_2D00_485_5F00_UNO_5F00_Q.mp4 Next onto the batteries and charging them, I think I have the necessary knowledge and courage to proceed safely . Source https://github.com/saramic/vape-cell-EVADM3068EEVAL–ADM3068EEBZrs-485uno qhttps://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57142/dockbot---part-3---new-plan-new-hardware-for-better-sensing/237605Thu, 30 Jul 2026 11:53:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:fce70248-0e73-48da-94c5-78024adb8561arvindsaThank you so much. Im excited to work with the electronics nexthttps://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57142/dockbot---part-3---new-plan-new-hardware-for-better-sensing/237603Thu, 30 Jul 2026 10:34:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:f56b59d5-5a06-497c-896b-0c19cf658f22cstantonWell that's deeply impressivehttps://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/m/managed-videos/151543Thu, 30 Jul 2026 10:28:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:852b2f73-311c-4d14-9de7-24f2372b8c1aarvindsaTesting of 4x4 Aruco Marker using Radxa Q6. Testing for range, accuracy and relative distance between two markers. Music by Dmitrii Spis from Pixabay Music Author : https://pixabay.com/users/nastelbom-48128234 Music Link: https://pixabay.comhttps://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/m/managed-videos/151542Thu, 30 Jul 2026 10:28:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:71fe7f31-64d6-4350-90a4-65a6f109a8f7arvindsaIt's getting crazy out there. Referenced in this video: - Tweet that kicked off my discussion: https://x.com/Raspberry_Pi/status/2082208491490459688 - Micro Center Pi 4 1GB for $35: https://www.microcenter.com/product/665122/raspberry-pi-4-model-b...boardmakerlpddrtouch displayshortageexpensehomelab16gbchiplpddr4dualsbccostcomputertinkerddrsingletinkererraspberry piexpensivesiliconvalue3gbecosystem1gbpricecomparisonmicro centerdramcompetitorddr5mini pclinuxhttps://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57142/dockbot---part-3---new-plan-new-hardware-for-better-sensingThu, 30 Jul 2026 10:27:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:9b6aba4a-7f48-47c3-9196-0df595f1bfaaarvindsaRecap 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: DockBot - Part 1 - The Concept DockBot - Part 2 - Positioning with Aruco Markers Plan change: no more 3D printer gantry In Part 1 the plan was to repurpose my old AnyCubic Mega i3 3D printer as a gantry robot - solid mechanics, motors and lead screws already working, It just needed a new job. I've dropped that idea. One simple reason: I just couldn't let myself strip it apart. Maybe I am too emotionally attached to the first 3D printer or maybe because I can actually still use the printer as a printer. So the new plan is a tracked " Devastator " tank chassis by DFRobot that drives itself over to the car and reaches out to touch the Charging once it's close enough, rather than a fixed machine the car has to line up with. More travel, more forgiveness, and I get my printer back. Now, This Devastator tank i something i gave to my Nephew an year back. I wanted to use it for my Spring clean project but he was using it. These days school kids are doing engineering level projects. But During his experiments, he did end up burning the Yellow BO motor. Experience is the best teacher. That will teach him not to torture the BO motors to 12V. So I ordered an alternative Blue Metal geared motor to replace it in exchange for him letting me borrow the tank. Best deal ever. Devastator Tank with the replacement motor on top Giving back my EnderS1 Pro his Klipper back Part 2's prototype ran on a Raspberry Pi, using picamera2 and a CSI camera. Since then I moved all of the vision code to a newly purchased Radxa Q6A instead. The reason: I needed the RPi back. It's the board running Klipper (Mainsail OS) for my ender S1 Pro, and I'd been borrowing it for this project in the meantime. And I just thought RadXa is better than Rpi. Why? Here are my points of comparison. RPi 4 RPi 5 Radxa Q6A SoC Broadcom BCM2711 Broadcom BCM2712 Qualcomm QCS6490 CPU 4x Cortex-A72 @ 1.5GHz 4x Cortex-A76 @ 2.4GHz 8x Kryo 670 (Cortex-A78/A55) up to ~2.7GHz RAM up to 8GB LPDDR4 up to 8GB LPDDR4X LPDDR5, module-dependent AI accel none none onboard Hexagon NPU, ~12 TOPS Camera interface 1x CSI-2 2x CSI/DSI MIPI CSI available, but I'm using USB/UVC instead Radxa on Left and Rpi 4 on right With RAM Pricing driving up the cost of Raspberry Pi way more than other SBC (Do checkout this Video by Jeff Geerling, This video came the day i started writing draft for this post: https://www.youtube.com/watch?v=53AkaYvw63U ) , TLDR, I was reluctant to get an RPI. But very quick internet research made me finalize on the Q6A mainly because the Q6A's NPU is a genuinely different category of hardware - Cortex cores are Cortex cores, but a dedicated Hexagon NPU means headroom for heavier CV/ML later without re-architecting anything Camera Change: comparing four options The RPi Camera Module v1.3 from Part 2 worked, and was quite adequate for the gantry based idea. There was only a fixed volume for the ARUCO to be in, But now, the workspace is much larger and that means the camera should reliably see the aruco marker at a larger distance. Gut feeling turned out to be right, when a quick test prove that beyond 2m, the accuracy drops quite significantly. And so I had to look for alternatives. I had a Logitech HD 720. Butt that was'nt great. I really did not want to spend on a camera, Oh I forgot, Radxa I plan to use for the Make a Connection competition and after that, I plan to set it up as an AI analysis system for Analyzing data from the RPi to detect 3D print failures via Obico, Back to the camera, I asked a work client of mine who works with camera and he sent me an Waveshare IMX 335 and OV5693 Module Camera Interface Resolution Notes Logitech HD 720p webcam (Top Right) USB/UVC 1280x720 Cheap, plug-and-play, but the ISP is tuned for video calls, not machine vision - fixed focus quality and FOV aren't great for consistent marker detection at range. RPi Camera v1.3 OV5647 (Bottom Right) CSI 5MP stills / 1080p30 What I used in Part 2. Fixed focus, older sensor, weak in low light. s. OV5693 (Bottm Left) USB 5MP Mostly designed as a Camera for Selfies. Waveshare IMX335 (Top Left) USB 5MP Newer Sony sensor, noticeably better low light than the OV5647, sees it like any other webcam Moving to OpenCV 5 Around the same time I was trying out the new Raxda, OpenCV 5 launched officially in June 2026 - the first major version bump in eight years since OpenCV 4.0, bringing a radically overhauled Deep Neural Network (DNN) engine, native LLM/VLM execution, and a fresh data-type architecture. Naturally I couldn't resist installing it right away and naturally, all my Part 2 code promptly broke. So I took some time to change the code one error at a time. Thankfully, there were not much and I think the new syntax make the code shorter. P.S. I have no idea what VLM is, I just summarized the AI Summary from Google. A new Arucodictionary I switched ArUco dictionaries, from Aruco MIP 36h12 to DICT_4X4_50. MIP 36h12 was never really a deliberate choice in Part 2 - I used it because the calibration board PDF I found online happened to be printed with it, and calibration board and detection markers have to agree on the same dictionary. That's a 6x6 grid of cells encoding 36 bits per marker. DICT_4X4_50 packs its ID into a 4x4 grid instead - fewer, bigger cells for the same physical marker size, which matters once the workspace got bigger and markers started showing up smaller and blurrier in frame: So, a bigger size marker with less dense ID will have better chance of being detected and more importantly distance to the marker detected correctly. Not an exact theory but with 50% more size per bits, the distance should also increase by 50%. Improved Workflow With the raspberry Pi, i was running headless, Initially it looked fun, but it started getting tiring due to latency of the image being sent over, difficult to debug it over SSH, so with radxa i decided to use it with a monitor. Also the radxa OS ships with a desktop environment. The tests for accuracy and detection range I took the whole setup to a my university lab with 60x60cm floor tiles. no tape measure required. I did measure the tiles just in case. First question was range: how far away can this thing still reliably see the marker? Answer: 6m, comfortably past the 5m I actually need for the docking approach. Then accuracy. I placed the marker at 60cm intervals along the tile lines and compared the reported distance against the known tile count. It tracked well throughout, but error grew with distance, worst case was about 4% and average of 3% under 2m, climbing to an max of 8% with average of 5% by 5m. www.youtube.com/watch Music by Dmitrii Spis from Pixabay {gallery}Range Measurement 1.2m:1.2M 1.8m:1.8m 2.4m: 2.4m 3.6m:3.6m 6m:6m Camera Alignment: Tried by best to align the sensor along the junction of the tiles. (Parallax error applies) What's next Now that the hardware is settled - Radxa Q6A, IMX335, DICT_4X4_50 - the next step is actually starting on the Devastator tank itself. Motors have arrived, Driver board is in stock with me. I have the Arduino Q. Final Notes Yes, I made a lot of changes, But all in the name of Improvisation. Lot's of Borrowed items, But hey what are Friends Family (and clients) for.design challengechallengeuno qhttps://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57133/eva-guardian---the-architecture-part-2/237579Tue, 28 Jul 2026 19:00:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:af7dc8d3-97d0-40e1-ac0f-6f66ba96f432DABNice plan, I look forward to seeing your build.https://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/m/managed-videos/151532Sun, 26 Jul 2026 13:57:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:f931aa03-8af4-4e7c-9624-ae90c7435f25Sumanth_m_nWhat if an electric vehicle could do more than simply tell us its battery percentage? What if it could understand the health of its battery, identify abnormal behaviour, detect potentially dangerous motion, and still provide emergency communicatio...https://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57133/eva-guardian---the-architectureSun, 26 Jul 2026 13:57:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:88b6f761-c696-4245-ab2b-28a677fee5bfSumanth_m_nBuilding the Technical Architecture: From EV Battery Intelligence to Emergency Safety In my previous post: Part EV Guardian - Part 1 , I introduced EVA Guardian and the motivation behind the project — an intelligent EV platform designed not just to monitor a vehicle, but to help understand its battery condition, detect abnormal vehicle behaviour, and provide assistance during an emergency. In this post, I want to move one step deeper. After defining the problem and the overall vision, the next question is: How can I actually build this system using the hardware available to me? For this challenge, I decided to divide EVA Guardian into two interconnected systems: Battery Management System (BMS) & Battery Profiling Node Incident Detection & Safety Node The two systems have different responsibilities, but they work together through an RS485 communication link. Figure 1: High level block diagram 1. Battery Management & Profiling Node The first part of EVA Guardian is responsible for understanding what is happening inside the battery system.The prototype uses a 2S 18650 Li-ion battery configuration , together with an HX-2S-A2 battery protection board .The HX-2S-A2 provides the basic battery protection layer, while the Arduino UNO Q sits above it as the intelligent monitoring and analytics layer.This distinction is important.The protection hardware is responsible for fundamental battery safety, while my software will focus on understanding the battery's behaviour. The battery node therefore brings together: 2S 18650 battery pack HX-2S-A2 BMS ACS723 current sensor LF412-based voltage measurement circuit NTC temperature sensing 2S Li-ion charger L298N-controlled load Relay-based switching Arduino UNO Q ADM3068E RS485 interface Each component has a specific role in creating the battery intelligence system. 2. Understanding Battery Current One of the most important parameters in the battery system is current.I am using the ACS723 current sensor to measure the current flowing through the battery/load system.This allows the Arduino UNO Q to understand how heavily the battery is being loaded and how the current changes during different operating conditions.Together with battery voltage, current also allows me to calculate power and energy consumption. This provides the foundation for monitoring parameters such as: Battery power Charging power Discharging power Energy consumption Peak current Load behaviour Charging and discharging efficiency Instead of looking at battery voltage alone, the system can therefore start building a much more complete picture of how the battery is actually being used. 3. Battery Voltage and Temperature Current is only one part of the story.The battery voltage is measured through the LF412-based analogue signal conditioning circuit , allowing the voltage to be safely acquired by the Arduino UNO Q's ADC.The system will continuously monitor the battery voltage during both charging and discharging.Temperature is another critical parameter.An NTC thermistor is used to monitor the battery temperature, particularly during high-current operation and charging.This becomes useful when multiple parameters are considered together.For example, a high current by itself may be completely normal.But if the system observes: High current + rapid temperature rise + unusual voltage behaviour then the event becomes much more interesting from a battery-health perspective.This combination of electrical and thermal information is what will eventually allow me to explore more advanced battery analytics and machine learning. 4. Creating Controlled Battery Conditions To understand the battery properly, I need to expose it to different operating conditions.This is where the L298N motor driver and load become useful.The load can be controlled to create different discharge conditions, while the Arduino UNO Q monitors the resulting battery behaviour.By changing the load, I can generate different current profiles and observe how the battery responds.The 2S charger provides the corresponding charging side of the experiment. This gives me a controlled environment in which I can study: Charging behaviour Discharging behaviour Different load conditions Current variations Voltage response Temperature response Energy consumption These measurements will eventually become the foundation for battery profiling and ML-based analysis. 5. The Arduino UNO Q – Intelligence Layer The Arduino UNO Q is at the heart of the battery node.Its role is much more than simply reading sensor values. It will acquire and process: Battery voltage Battery current Battery temperature Charging/discharging status Load condition From this information, the system can build higher-level battery information such as: State of Charge Power Energy consumption Efficiency Battery operating history Abnormal operating conditions As the project progresses, I also plan to use the collected battery data to investigate machine-learning-based State of Health estimation, anomaly detection and predictive maintenance .This is where the project moves from traditional battery monitoring toward the intelligent battery concept introduced in my previous post. 6. Incident Detection & Safety Node The second half of EVA Guardian focuses on something equally important: What happens when the vehicle itself behaves unexpectedly? For this, I am using a second Arduino UNO Q together with the GY-91 sensor module .The GY-91 provides an MPU6500 accelerometer and gyroscope, along with the BMP280 pressure and temperature sensor.For the initial implementation, the MPU6500 is the primary sensor for vehicle motion analysis. The system will use the IMU data to investigate events such as: Abrupt acceleration Harsh braking Sudden impacts Excessive vibration Potholes Speed breakers Sharp turns Sudden stops Vehicle tip-over Potential accident scenarios The goal is not simply to trigger an alarm whenever acceleration crosses a fixed threshold.Real-world vehicle motion is much more complicated than that.A speed breaker, pothole and accident can all create large acceleration peaks.Therefore, the challenge is to teach the system to distinguish between these different events.This is where the machine-learning aspect of the safety node becomes important. 7. From IMU Data to Incident Detection The incident detection node will initially collect the accelerometer and gyroscope data from the GY-91.The data can then be stored and labelled according to different vehicle conditions. For example: Normal movement Acceleration Braking Harsh braking Turning Pothole Speed breaker Sudden impact Tip-over This dataset can then be used to train an ML model.My planned approach is to collect the data using the Arduino UNO Q, generate the dataset, train and validate the model using EdgeImpulse, and deploy it back onto the Arduino UNO Q.The eventual objective is to perform the inference locally at the edge.This means the vehicle does not have to continuously depend on a cloud service just to determine whether an abnormal motion event has occurred. 8. Why a Second Battery? The safety node also has its own 2S 18650 battery and HX-2S-A2 protection system .This is an important part of the overall safety philosophy.In a conventional vehicle architecture, the primary battery is responsible for powering almost everything.But consider a situation where the primary battery or its power path becomes unavailable following an accident.If the safety system also depends entirely on that same battery, the vehicle could lose its ability to communicate exactly when communication becomes most important.EVA Guardian therefore explores a separate battery-backed power path for the safety node. The objective isn't to keep the vehicle running.Instead, the backup source is intended to support essential functions such as: Safety monitoring Emergency communication SOS operation Basic diagnostics The philosophy is simple: If the vehicle cannot continue moving, the safety system should still be able to communicate. 9. Automatic Power Switching The second node includes an automatic power switching relay arrangement .Under normal conditions, the safety system can operate from its primary power source.If that source becomes unavailable, the switching circuit can transfer the system to the redundant battery.This provides an additional layer of resilience to the safety system.The important point here is that the redundant battery isn't intended to be another traction battery.It is an emergency energy reserve for the electronics that need to remain alive when everything else has stopped. 10. Communication Between the Two Nodes The two systems need to communicate because battery condition and vehicle safety cannot always be considered independently.For this purpose, I am using Analog Devices ADM3068E RS485 transceiver evaluation boards . The Battery Management Node can share information such as: Battery voltage Battery current Battery temperature State of Charge State of Health Power Energy consumption Battery warnings Battery anomaly status The Safety Node can provide: Motion state Acceleration information Gyroscope information Incident classification Incident confidence Emergency status The RS485 connection therefore acts as the communication backbone between the two intelligent nodes. 11. Why RS485? The choice of RS485 is also intentional.The objective of EVA Guardian is not just to create a demonstration where two boards exchange data.I want to explore an architecture that can eventually be extended into a distributed EV monitoring system.RS485 provides a robust differential communication interface and gives the architecture room for future expansion. For example, additional nodes could eventually be introduced for: Motor monitoring Thermal monitoring Charging system monitoring Additional battery packs Environmental sensing Other vehicle diagnostics This modular approach makes it easier to expand the system without redesigning the entire architecture. 12. Bringing Everything Together Figure 2: Technical Architecture This is where the two nodes become a single system.During normal operation, the Battery Management Node continuously monitors the battery.The voltage, current and temperature sensors provide the raw information required to understand the battery's electrical and thermal behaviour.The Arduino UNO Q processes this information and gradually builds a battery profile.At the same time, the Safety Node continuously monitors vehicle movement through the GY-91.The two systems communicate over RS485, allowing the master node to maintain an overall view of the vehicle.The master node can therefore receive information about: Battery condition Battery health Battery energy consumption Temperature Vehicle motion Incident status System faults If the battery begins behaving abnormally, the battery node can raise a warning.If the vehicle experiences an unusual motion event, the safety node can classify it.The master node can then combine the information from both systems before moving into the emergency response process. 13. From Detection to Emergency Response One of the most important design decisions is that the ML model should not directly trigger an SOS message.Suppose the ML model identifies a potential accident.That event should first pass through an additional verification layer. The system can consider factors such as: Impact magnitude Duration of the event Vehicle movement after the event Vehicle orientation Repeated abnormal motion ML confidence Battery/system condition This helps differentiate a genuine emergency from events such as a pothole or speed breaker.Once the event has been sufficiently verified, the master node can initiate the emergency workflow.The redundant battery system can ensure that the safety electronics continue operating even if the primary power source has failed.The ultimate objective is to allow the system to communicate an emergency event and location through a consumer smartphone , without requiring a dedicated cellular modem as part of the prototype. 14. How the System Will Evolve The architecture has been designed so that the project can be developed in stages.Initially, I will focus on making the basic battery monitoring system reliable.Once voltage, current and temperature measurements are working correctly, I can start collecting battery behaviour data.That data will then be used for battery profiling and eventually ML-based analysis.In parallel, the incident detection node will begin with raw IMU acquisition.After sufficient data has been collected, I can start developing and validating the incident classification model.Finally, both systems will be brought together through RS485 and integrated with the LabVIEW interface and emergency workflow.This incremental approach is important because it ensures that each part of the system is understood and validated before moving to the next stage. Bringing the Vision from Part I to Reality In my first post, I discussed the problem I wanted EVA Guardian to address.The problem wasn't simply battery monitoring.It was about making an EV more aware, reliable and resilient .With this architecture, I am now starting to translate that idea into actual hardware. The Battery Management Node focuses on one question: "How healthy is the energy system, and is it behaving as expected?" The Safety Node focuses on another: "What is happening to the vehicle, and is the situation becoming dangerous?" And the communication and emergency architecture brings these two perspectives together.The result is intended to be more than a collection of sensors.It is an attempt to build an intelligent safety ecosystem where the system can sense → understand → decide → respond .Here are my github repo and youtube explanatroy video for the better understanding Github Repo: https://github.com/ForgedCircuits/EVA-Guardian.git Youtube: The Technical Architecture of EV Guardian youtu.be/sFjDUSn4ZL0bmsbattery management systemevAccident detection systemuno qhttps://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/m/managed-videos/151531Sun, 26 Jul 2026 12:39:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:db11d126-f1fb-4745-8bf3-552aeb6c4f75tamadillohttps://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57131/hall-w-ev-post-1---the-wheels-are-turning-mostlySun, 26 Jul 2026 12:14:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:045a7b5d-768d-4ec4-9e17-50f3d7e79db7tamadilloHi, I’m hambreros . I’m 15, and this is my sister, tamadillo ’s entry into the Element14 EZ-EV challenge — my big sister is helping me out as the official 18 year old entry person for the competition. The plan is to build a little robot that can drive itself down a hallway, and eventually do useful stuff on its own. This post is about the first big milestone: getting the wheels moving. What we’ve actually built The brains of the robot are an Arduino UNO Q — it’s got a Linux side and a real-time STM32 side glued together, which is pretty cool because it means we get a full web server and precise motor timing on the same board. For wheels, we’re using two continuous-rotation servos. If you haven’t met these before: they look exactly like a normal hobby servo (the kind that turns to a specific angle and holds it), except someone’s popped the case open and disconnected the little potentiometer that tells the servo where it’s pointing. Without that feedback, the servo can’t “aim” anymore — so instead of turning to an angle, it just spins continuously, and the angle signal becomes a speed-and-direction signal instead. That makes them perfect cheap wheel motors: no separate motor driver board needed, just a signal wire straight from the STM32. Here’s the whole trick, in code. Each servo wants a pulse every 20 milliseconds (50 times a second) — 1.5ms means “stop”, 1ms means “full speed one way”, 2ms means “full speed the other way”, and everything in between is a speed in that direction: #define PULSE_STOP 1500 #define PULSE_FWD 1000 #define PULSE_BACK 2000 static unsigned int speedToPulseUs(int speed) { speed = constrain(speed, -100, 100); // speed=100 -> 1000us (full forward), speed=-100 -> 2000us (full back) return (unsigned int)(PULSE_STOP - speed * ((PULSE_STOP - PULSE_FWD) / 100)); } One thing that tripped us up: the UNO Q’s normal PWM hardware pins are locked to 500Hz in the board’s config, which is way too fast for servos — they expect a pulse every 20ms, not every 2ms. So instead we’re “bit banging” it — just toggling the pin HIGH and LOW ourselves with precise microsecond delays, in a loop, which turns out to work great and means we can use basically any digital pin, not just the “official” PWM ones. The web page We didn’t want to have to plug a laptop into the robot every time we wanted it to move, so the STM32 side exposes two functions — set_wheel1(speed) and set_wheel2(speed) — over the UNO Q’s built-in bridge, and the Linux side runs a little Flask web page with a slider for each wheel. Drag a slider up, that wheel spins forward; drag it down, it goes backward; let go, and it springs back to the middle and stops — like a throttle stick, not a light switch. There’s also one big STOP ALL button because, well, it’s a robot with wheels and you should always have a big red button. We also added a small safety net that I’m pretty proud of: if the web page loses its connection (phone goes to sleep, wifi drops, whatever) and no command has arrived for a full second, the STM32 stops both wheels on its own. So the worst case if my browser tab crashes isn’t “robot drives itself off the desk,” it’s just “robot stops.” community.element14.com/.../20260726_5F00_basic_5F00_wheel_5F00_motion_5F00_via_5F00_web_5F00_web.mp4 The mystery clicking noise Here’s the annoying bit. With both sliders sitting dead center at “stop,” the wheels are supposed to just… sit there. Instead we’re getting a faint little clicking sound, like the servo is “self-correcting” even though nothing is telling it to move. Turns out this is a pretty well-known thing with continuous-rotation servos: because they’re built from a normal position-holding servo, there’s still a tiny bit of the original control circuit inside trying to hold a “center” position. If our 1500us stop signal doesn’t land exactly on the point the servo was trimmed to when its feedback pot got disconnected, it thinks it’s very slightly off target and keeps nudging the motor to correct — click, click, click. The fix isn’t code so much as calibration — most of these servos have a tiny trim potentiometer on the back for exactly this. But since we’d rather tune it in software than hunt for a jeweler’s screwdriver every time, next step is adding a per-servo trim offset so we can dial each one in separately without touching the hardware: #define SERVO1_TRIM_US 0 // tweak until wheel 1 is silent at speed=0 #define SERVO2_TRIM_US 0 // tweak until wheel 2 is silent at speed=0 static unsigned int speedToPulseUs(int speed, int trimUs) { speed = constrain(speed, -100, 100); return (unsigned int)(PULSE_STOP + trimUs - speed * ((PULSE_STOP - PULSE_FWD) / 100)); } A few microseconds either way should be enough to quiet it down completely. What’s next Right now the robot can be driven around from a phone or laptop on the same network, which already feels like magic. Next up, roughly in order: Camera + remote driving — stick a camera on it and add WASD/on-screen controls to the web page, so it’s basically a little puppy on a leash you can drive from anywhere. Simple autonomy — a strip of tape down the hallway and some basic light-sensor logic so it can follow the line by itself. Manual override — a mode switch so it can drive itself but I can grab the wheel (well, the sliders) whenever I want. Telemetry / a face — battery level, current mode, maybe even a little animated face on an OLED screen so it has some personality. Long term, the goal is a robot that can scoot around the house on its own and do small useful things — not just drive in a straight line, but actually be handed simple tasks. One step at a time though. Wheels first! The codes https://github.com/tamadillo/hall-w-EV — hambreros (and tamadillo )carrobotuno qhttps://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57112/project-gepard-the-vision-post-1/236431Mon, 20 Jul 2026 11:07:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:3a45fe91-7dc1-4eab-842d-088461c4a707BigGLooks like a great project. I look forward to following your progress. Remember Arduino Q uses a pre-installed version of Debian Linux. I would encourage you to explore Debian Linux as its very well documented. Alternatively, if too much data overload, look at Zephyr RTOS. It works on both the Arduino Q and with the ESP32-S3. This is a great way to get your head around developing "device trees", which is something Linux uses too. You may even find Debian easier than you might expect, when it comes to streaming videos - especially through Python. It certainly will be more powerful than the ESP32-S3.https://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57112/project-gepard-the-vision-post-1/236427Mon, 20 Jul 2026 00:57:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:d4f3f38a-bf02-4e0d-8233-9ba41a77b3f8ralphjyIf you want to use a UART to communicate between ESP32-S3 and the Linux processor you will need to use the RPC Bridge to connect thru the STM32. If you aren't using the Bridge, I believe you can kill the Bridge daemon to communicate directly but have not tried that. Using the Bridge is probably the easiest and should have documented examples. Since you are probably using WiFi on both boards, you could also use MQTT because you aren't passing a lot of data.https://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57112/project-gepard-the-vision-post-1/236426Sun, 19 Jul 2026 18:27:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:46186b65-e3a3-47d4-88fa-83f691962637DABGood start, I look forward to your posts.https://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57112/project-gepard-the-vision-post-1Sun, 19 Jul 2026 05:23:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:947723cd-f965-4ebb-b9ae-fa11f39c40b9UlolKidzHey everyone, I’m jumping into the Element14 EZ-EV Challenge with a build I’m calling Project GEPARD V5.0 (Ground EV Perception and Autonomous Routing Dock). I am John, I am currently in university specializing in Business Data Analytics and Supply Chain (BBA/BCom). In my current co-op, I spend my days designing compliance workflow pipelines , writing scripts to optimize workflows, and mapping out routing logic for utility systems . Because of that background, when I look at an autonomous UGV and a self-charging dock, I don't just see an RC car. I see a closed-loop supply chain and a mobile telemetry node. The goal for this challenge is to demonstrate how industrial EV technologies like autonomous movement, sensor fusion, edge computing, and EMI-resistant docking can scale down into a consumer-sized prototype. The Brains of the Operation The core of this rover relies heavily on the sponsor-provided Arduino UNO Q. Instead of just using it for basic motor reflexes, I’ll be taking full advantage of its dual-brain architecture. The onboard STM32U585 will handle real-time motor control and sensor acquisition, while the Qualcomm QRB2210 Linux SBC will run Python and edge compute. The ESP32-S3 will sit shotgun, strictly handling video streaming to keep the UNO Q's pipeline clear of bottlenecks. The Scope: MVP vs. The Dream If you try to build a fully sentient AI robot all at once, you usually end up with nothing working. Instead, I am treating this build as a scalable modular platform . The MVP (Challenge Scope): A reliable, manually driven (WASD) tracked chassis featuring a dedicated battery bay and a removable electronics tray for easy servicing . It will stream video, continuously log power/odometry telemetry to a dashboard, and execute a proof-of-concept autonomous docking handshake. Phase 2 (The Dream): Once the MVP foundation is locked, I will use the reserved "brain bay" space to integrate grid mapping, SLAM, and local LLM processing via a federated compute model with my laptop. A Question for the Community Because the UNO Q is so new to the market, deep technical resources and documentation are still pretty sparse. I need a robust way to "glue" the UNO Q (handling the heavy edge compute and motors) to the ESP32-S3 (handling the video stream). My initial thought is to use a standard UART serial bridge or maybe a local UDP link to pass basic state commands between them, but I want to ensure absolute data integrity. Has anyone here had hands-on experience bridging the new UNO Q with an ESP board? What protocol or physical link did you find most reliable? Oh, and for those wondering about the name: Project GEPARD. Yes, it’s named after the Flakpanzer Gepard from War Thunder . If you play, you know that SPAA is infamous for being an absolute menace that shreds both aircraft and main battle tanks alike. While my V5.0 is just shooting ultrasonic pings instead of 35mm armor-piercing belts, I’m hoping it proves to be just as relentless as a telemetry node. Stay tuned. In the next post, I’ll drop the full parts list and dive deeper into how I'm using the ADI ADM3068E evaluation boards to build an EMI-resistant handshake for the docking station. (Note: I tried to generate a prototype image to be as similar to my plans as possible, but the AI had a mind of its own and this is the closest one. Stay tuned, I will be posting the actual 3D CAD model in a couple of days sorry for not posting it earlier! All the parts I need have been ordered through AliExpress, fingers crossed all of them work. If not, mighty Amazon will save me.)https://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57077/vape-cell-ev---part-i---what-s-in-a-vape/236283Tue, 30 Jun 2026 19:53:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:a2f52ea3-a811-4ae4-a1f8-4694e0301bd9DABNice idea.https://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57077/vape-cell-ev---part-i---what-s-in-a-vape/236280Tue, 30 Jun 2026 09:12:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:e3aecf6f-e4e7-48a1-9d58-d0864953dca1QbitBest out of waste