https://community.element14.com/challenges-projects/design-challenges/Engineering a Connected World! By connecting engineers to powerful new ideas, the latest technologies, and to each other, the element14 Community is creating innovative solutions to everyday problems.en-USTelligent Community 12https://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-d0864953dca1DipeshkachhiBest out of wastehttps://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57077/vape-cell-ev---part-i---what-s-in-a-vapeTue, 30 Jun 2026 00:28:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:aff96f14-888f-401b-89ba-3d7d574f334asaramicDisposable vapes are rechargeable batteries wrapped in a throwaway habit. When vapes first hit our streets, just before the COVID lockdowns in 2019, I thought: surely these devices have some reusable value. On various bike rides and dog walks I picked up a bunch, thinking better in my junk box than flowing into drains, rivers and waterways. At the time I heard of one or two people suggesting they have lithium batteries inside — not always well marked, but rechargeable, for all intents and purposes. I was mindful of the dangers of recharging unknown battery types, but curious all the same. My brain seems to be wired in a waste-not mindset. Maybe it is influenced through growing up under a Communist regime of limited resources — the idea of making the most of what you have through collecting, fixing, reusing and repurposing. Refusing to bin useful hardware. So slowly my junk box filled up with disposed vapes. The internals are pretty self-explanatory: a battery, a vape liquid dispenser and a few pieces of electronics. Sometimes I even collected a number of vapes that were made for reuse, presumably just lost by the addict, including the USB recharging hardware. I thought that this EZ-EV challenge would be a perfect opportunity for me to finally get my head around battery charging and reconditioning. Not only vapes, but I had a bunch of other batteries that might need some conditioning or could be put to use in some way. Not only vape cells but any disused e-waste like old headphones or phones In researching the state of vape reuse, I can see that this has taken a huge step forward. Examples out there suggest people building power walls out of them, as well as little ocarinas. Some are even extracting the lithium for chemistry experiments. On the general e-waste front, here in Melbourne there are a number of consumer shops that let you recycle your e-waste: batteries, phones, electronics. Of course my junk boxes are just like an e-waste recycling centre, without the recycling so far. The local Telco has only recently released a build of a synthesiser constructed completely from e-waste. This is inspiring stuff. Now onto the EV. I had an old robot vacuum cleaner I could use as a base, and a chassis for a “Braitenberg vehicle” I once started, but seeing a recent post on a battery-powered train made me think I should rekindle another one of my hobbies — model railways. The final platform might be an N-scale train EV, inspired by Fortescue’s all-electric heavy-haul trains running across the Pilbara in Western Australia. Clockwise from top: NYU’s vape synth as featured in WIRED, Chris Doel and his vape power wall project, Fortescue’s battery powered “infinity train” and Telstra’s e-waste synth The Problem Reuse is only credible if the cells are monitored properly, not guessed at. A salvaged cell pulled from a discarded vape has an unknown history — it may have been deep-discharged, overcharged, or just plain tired. Dropping it into a pack with a simple cutoff board and hoping for the best is not good enough. The solution What this project calls for is a smart BMS (Battery Management System) approach: per-cell visibility, voltage and temperature tracking, and health-aware decisions. Rather than treating the pack as a black box, each cell gets its own attention — flagging weak cells before they drag down the rest, and making charge and discharge decisions based on real data rather than assumptions. That intelligence matters most when working with salvaged cells, because mixed history and uneven quality demand observability. A cell that looks fine in a spot-check can hide a problem that only shows up under load or over time. The monitoring stack has to catch that. The hardware backbone for this is an RS485 bus connecting the cell monitors — a robust, noise-tolerant protocol well suited to the electrically messy environment of a discharging battery pack. RS485 is the same bus used in industrial BMS stacks and Modbus sensors, which means the tooling and libraries are mature. Sitting at the top of that bus is the UNO Q : a board that pairs a real-time STM32 microcontroller with a Qualcomm processor running Linux. The STM32 side handles the timing-critical work — polling cells over RS485 , enforcing cutoff thresholds — while the Linux side opens up a much richer analytical layer. Docker containers, YOLO inference models, data logging: things that would be unthinkable on a bare microcontroller become straightforward. There is also an appealing secondary use for the UNO Q : watching the train run a lap and visually monitoring the pack discharge in real time, with the Linux side offering enough headroom to run a live dashboard or even a camera-based model that tracks the loco position against battery state. VapeCell EV takes discarded lithium, instruments it with a smart monitoring stack, and turns e-waste into motion. Next get some battery charging stats using CC / CV (Constant Current and Constant Voltage) look at tracking data with the UNO Q see how best to utilise the UNO Q capabilities for a “Smart BMS” Source https://github.com/saramic/vape-cell-EVbmsVape cellevuno qtrainhttps://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57069/dockbot---part-2---positioning-with-aruco-markers/236259Sat, 27 Jun 2026 18:16:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:ef77f8e9-2840-4322-b103-8083248a8858DABVery nice update.https://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57069/dockbot---part-2---positioning-with-aruco-markers/236254Sat, 27 Jun 2026 14:59:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:3be34562-20b4-4c43-84ed-dd2952b1373darvindsaThank you, i should have mentioned that having two aruco markers one on the car and one on robot will help me coordinate the movt better.https://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57069/dockbot---part-2---positioning-with-aruco-markers/236253Sat, 27 Jun 2026 14:29:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:47ad860b-9d60-4bb1-b952-d68ddea8274fveluv01Interesting Approach!https://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/m/managed-videos/151504Sat, 27 Jun 2026 11:41:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:4ec3fa88-6a61-4d21-84ec-5c9d00a7de8earvindsahttps://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/m/managed-videos/151503Sat, 27 Jun 2026 11:41:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:9322321e-3b41-48d8-96da-365527ca264earvindsahttps://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/m/managed-videos/151502Sat, 27 Jun 2026 11:41:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:aa83f2da-4b6e-4ae0-87c7-14cb06c21567arvindsahttps://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57069/dockbot---part-2---positioning-with-aruco-markersSat, 27 Jun 2026 11:23:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:7099f797-6ee4-4504-84ef-252c3867bf40arvindsaRecap 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 The problem in technical terms For a given car model, the charging port is always at the same height. But the driver can park closer or farther away, or stop too far forward or back. The robot needs to figure out exactly where the port is each time. Here is an Half AI , Half Photopea Edited picture to make things easier. Robot needs to know its own position. That can come from joint encoders, stepper step counts from a home position, Lidar, or vision. I chose vision because a single camera system can identify the car model, locate the charging port, and tell the robot where it is relative to the target - all at once. Aruco markers make the position-from-vision problem much more tractable. What Are Aruco Markers Aruco markers are square fiducial markers - basically printed QR-code-like patterns with a thick black border and a unique binary pattern inside. OpenCV has had native Aruco support for years and it works excellently. This is good especially since when i was using this during my Bachelors in engineering, I had to compile OpenCV from scratch t have Aruco. Here is a good video demo on how they work: https://www.youtube.com/watch?v=MlOy9qt_K4Y I generated my markers at chev.me/arucogen using the Aruco MIP 36h12 dictionary. I chose this dictionary because the calibration board I got from Internet ( https://github.com/PlusToolkit/PlusLibData/blob/master/ConfigFiles/OpticalMarkerTracker/aruco_calibration_board_a4.pdf ) also uses this dictionary. Any dictionary works - the important thing is to use the same one for both calibration and detection. Installing on Debian / Raspberry Pi OpenCV comes with Aruco support built in. On Debian or Raspberry Pi OS (I am running Mainsail OS for Klipper as i am repurposing an existing RPi): pip install opencv-python-headless sudo apt install -y python3-picamera2 Camera Calibration Before you can get an accurate 3D pose from a marker, you need to calibrate the camera. Every lens introduces distortion. I am not getting into details because I forgot the theory. But what I do know is that to calibrate, you need a known target. I used an 8×5 Aruco MIP 36h12 grid board with 35 mm markers which i found online. https://youtu.be/FtU0Qb1yKOw You show the board to the camera from different angles and distances - at least 5 frames, more is better. OpenCV's calibrateCamera then solves for the camera matrix and distortion coefficients by matching the known 3D corner positions on the board to where they appear in each image. Calibration quality is measured by RMS reprojection error - how many pixels off the estimated corner positions are from the detected ones. Below 1.0 is good. Above that and your pose estimates will drift. Calibration only needs to be done once per camera and is saved to disk. After that it loads automatically on server start. Step 1 - Just Get Markers Detected The first script did nothing clever. Grab a frame, run the Aruco detector, print which IDs were found: import cv2 from picamera2 import Picamera2 picam2 = Picamera2() picam2.configure(picam2.create_preview_configuration(main={"size": (640, 480)})) picam2.start() aruco_dict = cv2.aruco.getPredefinedDictionary(cv2.aruco.DICT_ARUCO_MIP_36h12) params = cv2.aruco.DetectorParameters() detector = cv2.aruco.ArucoDetector(aruco_dict, params) frame = picam2.capture_array() frame = cv2.cvtColor(frame, cv2.COLOR_RGBA2BGR) corners, ids, _ = detector.detectMarkers(frame) if ids is not None: print("Detected:", ids.flatten().tolist()) else: print("Nothing detected") Hold up a marker, it prints the ID. Simple sanity check before building anything more complex. For the actual server I tuned the detector parameters to be more robust under varying lighting conditions - wider adaptive threshold window, sub-pixel corner refinement: _params = cv2.aruco.DetectorParameters() _params.adaptiveThreshWinSizeMin = 3 _params.adaptiveThreshWinSizeMax = 53 _params.adaptiveThreshWinSizeStep = 4 _params.adaptiveThreshConstant = 7 _params.minMarkerPerimeterRate = 0.02 _params.maxMarkerPerimeterRate = 4.0 _params.polygonalApproxAccuracyRate = 0.05 _params.cornerRefinementMethod = cv2.aruco.CORNER_REFINE_SUBPIX detector = cv2.aruco.ArucoDetector(aruco_dict, _params) Sub-pixel corner refinement ( CORNER_REFINE_SUBPIX ) is worth turning on - it measurably improves pose accuracy because solvePnP is very sensitive to where exactly the corners land. Step 2 - Streaming Frames Over the Network Running code on the Pi and squinting at SSH output is not great for development. I wanted to see the camera feed on my laptop. So I built a TCP server on the Pi that grabs frames, detects markers, draws them on the frame, and sends the JPEG plus a JSON payload with the marker data. The protocol is simple: a 4-byte length prefix, followed by a JSON metadata blob, followed by the JPEG bytes. The same framing is used in both directions. def send_msg(conn, payload: dict, image: bytes = None): """Length-prefixed: [4B json_len][json][image_bytes]""" if image: payload["image_len"] = len(image) raw = json.dumps(payload).encode() header = struct.pack(">I", len(raw)) conn.sendall(header + raw) if image: conn.sendall(image) def recv_msg(sock): hdr = _recvall(sock, 4) if not hdr: return None, None (length,) = struct.unpack(">I", hdr) body = _recvall(sock, length) meta = json.loads(body.decode()) image = None if meta.get("image_len", 0) > 0: image = _recvall(sock, meta["image_len"]) return meta, image The streaming runs at full camera speed for data but sends JPEG images at only 4 FPS. There is no point sending 30 JPEGs per second over a home WiFi link when the pose data is what matters. Images are just for visual feedback. On the client side, view.py connects, starts the stream, and renders the incoming frames in an OpenCV window while printing the pose table in the terminal: send_cmd(sock, {"cmd": "stream_start"}) while True: meta, image = recv_msg(sock) if image: buf = np.frombuffer(image, dtype=np.uint8) frame = cv2.imdecode(buf, cv2.IMREAD_COLOR) cv2.imshow("DockBot", frame) if cv2.waitKey(1) & 0xFF == ord("q"): break print_table(meta.get("markers", [])) Step 3 - Camera Calibration Workflow I added calibration commands to the server. The workflow from the client is: Print or display the 8×5 Aruco MIP 36h12 board Send cal_add while holding the board in view at different angles - tilt it, rotate it, bring it closer and farther Collect at least 15 frames with good variation Send cal_compute elif action == "cal_add": frame = grab_bgr() corners, ids, _ = detector.detectMarkers(frame) if ids is not None and len(ids) >= 4: obj_pts, img_pts = cal_board.matchImagePoints(corners, ids) if obj_pts is not None and len(obj_pts) >= 4: with cal_lock: cal_frames.append((obj_pts, img_pts)) count = len(cal_frames) send_msg(conn, {"status": "ok", "message": f"frame {count} added"}, ...) elif action == "cal_compute": rms, mtx, dist, _, _ = cv2.calibrateCamera( obj_pts, img_pts, (FRAME_W, FRAME_H), None, None) if rms < 1.0: _save_calibration(mtx, dist) msg = f"RMS {rms:.4f} - saved to disk" else: msg = f"RMS {rms:.4f} ! too high - tilt/rotate board more and try again" On the server, cal_add calls cal_board.matchImagePoints() to get 3D-to-2D point correspondences for that frame. cal_compute accumulates all frames and calls cv2.calibrateCamera() : If the RMS is below 1.0 the calibration is saved to disk and loaded automatically on the next server start. Once calibrated, refineDetectedMarkers also kicks in. It uses the board geometry to recover markers that were just below the detection threshold - useful when part of the board is in shadow. One thing to be careful about: the calibration board markers are 35 mm, but the dock markers I printed are 80 mm (larger because the camera may be placed further away in deployment). These are separate constants in the code: CAL_MARKER_LENGTH = 0.035 # metres - calibration board markers MARKER_LENGTH = 0.080 # metres - dock markers used for pose estimation Mixing them up gives you pose distances that are off by the ratio of the two sizes. The calibration board size is only used during calibration to define 3D object points. The dock marker size is used later for pose estimation. Step 4 - Pose Estimation Once the camera is calibrated, getting the 3D position of each marker is straightforward. The detect() function handles detection, refinement, pose estimation, and drawing all in one pass: MARKER_OBJ_PTS = np.array([ [-_half, _half, 0], [ _half, _half, 0], [ _half, -_half, 0], [-_half, -_half, 0], ], dtype=np.float32) def detect(frame): corners, ids, rejected = detector.detectMarkers(frame) if camera_matrix is not None: corners, ids, rejected, _ = cv2.aruco.refineDetectedMarkers( frame, cal_board, corners, ids, rejected, cameraMatrix=camera_matrix, distCoeffs=dist_coeffs ) markers = [] if ids is not None: cv2.aruco.drawDetectedMarkers(frame, corners, ids) for i, mid in enumerate(ids.flatten()): if int(mid) not in ALLOWED_IDS: continue entry = {"id": int(mid), "corners": corners[i][0].tolist()} if camera_matrix is not None: img_pts = corners[i][0].astype(np.float32) _, rvec, tvec = cv2.solvePnP( MARKER_OBJ_PTS, img_pts, camera_matrix, dist_coeffs, flags=cv2.SOLVEPNP_IPPE_SQUARE, ) cv2.drawFrameAxes(frame, camera_matrix, dist_coeffs, rvec, tvec, _half) entry["tvec"] = tvec.flatten().tolist() entry["rvec"] = rvec.flatten().tolist() markers.append(entry) return markers SOLVEPNP_IPPE_SQUARE is the right solver for square planar targets - it gives two solutions and picks the better one. The translation vector tvec is the X, Y, Z position of the marker centre relative to the camera in metres. Z is depth (straight ahead), X is left/right, Y is up/down. drawFrameAxes draws the 3D coordinate axes on each detected marker in the live stream so you can immediately see the orientation of each marker - satisfying to watch when it works. Detection is filtered to IDs 0 through 7. Any stray detections from other sources are silently dropped. The client prints a live-updating pose table from the stream data: https://youtu.be/rHTljRGW7VA If you notice closely, you'll see the estimation of pose are quite off by a large magnitude. That's when it hit me that the size of markers used to calibrate (35mm) is not the same as the one using to estimate pose (80mm) . So I changed the code to compensate for it at this point. The XYZ Plot To verify the pose estimate is stable, I wrote a separate script that connects to the server and live-plots the X, Y, Z components of marker ID 0 over time using matplotlib. The network receiver runs in a background thread and pushes data into a queue; the animation callback drains it: def receiver(host, port, q: queue.Queue): sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect((host, port)) send_cmd(sock, {"cmd": "stream_start"}) while True: meta, _ = recv_msg(sock) if meta is None: break for m in meta.get("markers", []): if m["id"] == MARKER_ID and "tvec" in m: q.put((time.monotonic(), m["tvec"])) def update(_frame): while not q.empty(): t, (x, y, z) = q.get_nowait() ts.append(t - t0); xs.append(x); ys.append(y); zs.append(z) # drop data older than 10 seconds cutoff = time.monotonic() - t0 - HISTORY_S while ts and ts[0] < cutoff: ts.popleft(); xs.popleft(); ys.popleft(); zs.popleft() ... ani = animation.FuncAnimation(fig, update, interval=50, blit=True) Holding a marker steady and watching the lines tells you immediately how stable the calibration is. A wobbly line means more calibration frames or better angle variation are needed. Obviously, it's not perfect, But I will improve it after integration, as I need to hold the camera steady first. For now, it's resting over the Rpi Case. https://youtu.be/F8Ea_yb0bYI Code The Full code for this can be found under post2 folder at https://gitlab.com/arvindsa/dockbot-e14-challenge Final Notes There was a time I had to compile OpenCV from source just to get Aruco support. Now a single pip install does it. Now that I can reliably locate markers in 3D space, the next step is the physical robot - the gantry hardware.https://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57059/ev-guardian-part-i/236213Tue, 23 Jun 2026 19:41:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:c4deb88b-6020-4dbc-9318-b71a3ce56a5dDABGood plan, I look forward to your build and testing.https://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57059/ev-guardian-part-i/236205Tue, 23 Jun 2026 10:52:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:e0d10dd9-d745-4179-bfd5-908bbd17fbf4arvindsaGreat, looking forward to the updates.https://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57056/dockbot---part-1---the-concept/236199Tue, 23 Jun 2026 03:24:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:a6cde3ce-9b8e-45a1-a5fa-18fe0c1cdcaearvindsahe he, was seeing if grok was good for creating explainer video. As of now for technical explanation, it defies all rules of physics.https://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57056/dockbot---part-1---the-concept/236200Tue, 23 Jun 2026 03:24:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:25796e00-bda3-4242-b748-c745a2fccc85arvindsaThank youhttps://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57059/ev-guardian-part-iMon, 22 Jun 2026 18:03:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:141d4784-813c-4ba4-bdab-3ec9f794146aSumanth_m_nCan an EV Understand Its Own Health? Electric vehicles are becoming increasingly common around us. Whether it is electric two-wheelers for daily commuting or electric cars for long-distance travel, the transition toward electric mobility is accelerating every year. But while EV technology has evolved rapidly in terms of batteries, charging infrastructure, and driving experience, I often feel that one important area receives less attention than it deserves: understanding the actual condition of the vehicle while it is operating. Most EVs today provide information such as: Battery percentage Remaining range Charging status Basic warnings These indicators are useful. But they made me think— is that enough? Because if we think about it carefully: A battery showing 65% charge does not tell us: whether the battery is aging abnormally, whether the charging cycles are affecting efficiency, whether vibration is slowly damaging electrical interfaces, whether connector degradation is increasing losses, or whether the vehicle can still support communication during an emergency. These questions became the starting point of this project. Looking Beyond Battery Percentage As users, we generally evaluate an EV through two numbers: Battery Remaining Estimated Range But internally, an EV battery system is continuously experiencing: charging cycles, discharge patterns, temperature variation, current spikes, environmental vibration, connector wear, changing efficiency. Many of these changes happen gradually. By the time symptoms become visible to the rider— performance may already be affected. That raised a question: Instead of simply reporting battery percentage— can a vehicle become more aware of its own condition? Can it provide meaningful insight before problems become visible? That idea became the foundation of EV Guardian. Introducing EV Guardian Intelligent EV Battery Insight, Safety & Emergency Response System EV Guardian is an attempt to build a distributed intelligence platform around three major pillars: Note: AI Generated image for reference. Understand energy. Understand safety. Maintain communication during emergencies. Instead of treating the vehicle as a single black box, the architecture separates responsibilities into dedicated functional nodes. This decision was intentional. Battery intelligence and emergency response solve different problems and should remain independently operable. The current architecture consists of two primary nodes. Node 1 — Battery Management & Profiling Node This node forms the energy intelligence layer of the system. Its responsibility is not limited to measurement. Its objective is to observe battery behavior and extract meaningful insight. The subsystem continuously monitors: battery voltage, battery current, charging state, discharge behavior, thermal conditions. Alongside monitoring, it also manages protection mechanisms: overvoltage protection, undervoltage protection, overcurrent cutoff. At this stage, these are standard battery management capabilities. But the interesting part begins after measurements are collected. From Measurement to Battery Insight Most systems answer: What is the battery level? This node attempts to answer: What is happening to the battery? Using edge-side analytics running locally, the system will investigate: State of Charge (SoC) Estimating usable remaining energy. Not simply: “60% remaining” But: “How much operation time remains under current conditions?” State of Health (SoH) Estimating long-term battery condition. This provides visibility into: degradation, available capacity, expected performance. Battery Anomaly Detection Battery failures often develop gradually. Early indicators may appear as: unexpected current patterns, abnormal charging profiles, efficiency reduction, thermal drift. The objective is to identify patterns before they become user-visible failures. Predictive Maintenance Rather than waiting for issues to appear— the system attempts to estimate when intervention may become necessary. The long-term goal is moving from reactive maintenance to informed operation. Node 2 — Safety & Emergency SOS Node While battery insight improves reliability— safety remains equally important. This node acts as the central coordinator and safety controller. It continuously monitors vehicle dynamics using inertial sensing. Measured conditions include: acceleration, abrupt motion, vibration, impact events. The intention is not to classify accidents immediately. Instead, the goal is to establish a framework capable of recognizing abnormal operating conditions. Future software iterations may investigate lightweight edge models for better motion interpretation. Safety Should Continue Even After Failure One scenario I kept returning to while thinking about this design was: What happens if the vehicle becomes unavailable during an emergency? The rider may still require: communication, location sharing, emergency assistance. This inspired another subsystem. A small redundant battery path is planned for critical operation only. This is not intended for vehicle propulsion. Its only objective is preserving essential functions. Examples include: emergency SOS triggering, phone charging, location transmission, basic system diagnostics. The philosophy here is simple: If transportation stops— communication should not. Why Use Distributed Communication? The two nodes communicate through isolated RS485. This choice was intentional. Transportation systems operate in electrically noisy environments. Separating functions while maintaining reliable communication offers: fault isolation, modular expansion, improved robustness, cleaner architecture. Battery intelligence remains independent. Safety intelligence remains independent. But both continue exchanging critical information. Making Vehicle Health Visible All collected information is transmitted wirelessly to a visualization interface. Initially this will run on a laptop. The dashboard will eventually display: Battery Layer State of Charge State of Health Estimated range Efficiency indicators Safety Layer Vibration profile Warning states Emergency events System Layer Node status Communication health Event history The current interface is intentionally developed to remain portable to future embedded displays. Closing Thoughts This project is not trying to redesign electric vehicles. It is exploring a smaller question. As EVs become more intelligent— should they simply display status, or should they actively help users understand risk? Battery insight. Predictive diagnostics. Emergency preparedness. Resilient communication. These may become increasingly important components of future mobility. This is the beginning of EV Guardian. Next, I will move from concept into implementation and begin building the distributed architecture behind the system.battery management systemevAccident detection systemhttps://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57056/dockbot---part-1---the-concept/236195Mon, 22 Jun 2026 12:47:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:758be005-a9a0-40da-9ed6-d8e9eaf0212fDipeshkachhiThis is an excellent concept for the EZ-EV Challenge! Finding efficient, automated ways to bridge the gap between electric vehicles and their docking or charging infrastructures is a massive real-world problem right now, so focusing on a 'DockBot' is a brilliant direction. Your breakdown of the concept in Part 1 lays out a really strong foundation. I'm particularly interested to see how you plan to tackle the precision alignment and sensing side of the build—especially if you'll be leveraging the Analog Devices or NI components from the challenger kit to handle the perception and obstacle avoidance. Congratulations on getting selected as a challenger! The build phase is always the most exciting part, and I'm looking forward to following along with your next updates. Good luck!https://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57056/dockbot---part-1---the-concept/236193Mon, 22 Jun 2026 12:03:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:b45de7f1-d610-49b8-831e-9632d9c234b2balajivan1995[quote userid="513936" url="~/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57056/dockbot---part-1---the-concept"] Here is a concept video made using AI. Ignore the hallucinations. [/quote] Linear actuator from nightmare. Nice concept! Looking forward to the updates!https://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/m/managed-videos/151450Mon, 22 Jun 2026 08:25:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:4a0b215d-f885-4258-84e6-205f095711e3arvindsahttps://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/m/managed-videosMon, 22 Jun 2026 08:19:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:d2dfe2ec-7e83-4681-bb14-bc1769aa0146https://community.element14.com/challenges-projects/design-challenges/ez-ev-challenge/f/forum/57056/dockbot---part-1---the-conceptMon, 22 Jun 2026 08:17:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:efb3c010-33ad-401b-b7d6-e47ad92459e4arvindsaThe Summer vacation has ended and work has resumed to normal level load, I thought of taking a break from the commitment of delivering a project, so i did not apply for the sponsored kit for this challenge. But I still can try building for challenge. That way, No pressure of delivering the project and I can call it quits if i cant. So, Over to the concept of Dockbot. Aim is to build a concept of a robot that automatically plugs in the charging plug after a car has been parked. This project is not gonna be serious, no custom PCB and I will try to use whatever I have on hand. To start with is the detection of the car stop and location of charging slot. This will be done using ArduinoQ and OpenCV to identify the location using a camera. After the location is identified, I will use a gantry robot made from repurposing my old 3D Printer - AnyCubic mega i3 which i bought in 2013. The motors, lead screws, hotbed all worked well before i put it in storage, just that the hot-end is not working correctly. And the mechanical stability of this gantry is rock solid. I had thought of using the 3D printer as a laser cutter but then I realized in my home, I do not have space to handle the ventilation requirement. So i dropped it. But now, I may be able to give the old workhorse a new purpose. Here is a concept video made using AI. Ignore the hallucinations. community.element14.com/.../grok_2D00_video_2D00_06dd0464_2D00_2204_2D00_48f1_2D00_b8d5_2D00_487ec0ae6c4d.mp4 Final Notes: Truth be told, I haven't researched on whether Arduino Q can reliably handle the object detection, but I do have a backup SBC just in case. I did spend some time learning about Arduino Q in the On the Line Challenge so hopefully, it will not go to waste.