VIDEO DEMO: https://www.loom.com/share/93291af18bf344c69a9a546eca28857d?sid=d5204830-b15a-4d34-bd62-7626459607db
Inspiration
Inspired by the high demand for battery energy storage to support the adoption of renewable energy sources, we planned to tackle a rising issue of refurbishing lithium-ion EV batteries for static applications in order to maximize humanity's usage of this highly limited but invaluable resource.
What it does
Our project acts as a proof of concept for an embedded system that aims to aid reliability, safety, and future proofing of second-life batteries (SLBs). As SLBs are still a relatively new technology faced with various logistical issues, our system acts as a an out-of-the-box battery management system (BMS) designed to integrate batteries with varying specifications and allow them to work seamlessly together. The BMS also feeds its telemetry to a centralized dashboard, allowing system administrators to monitor the status of their SLB fleets on the fly.
How we built it
Since we obviously don't have real battery packs to test, we first used PyBamm to create a continuous telemetry feed from a simulated battery module. For our demo, we are simulating an array of three EV batteries, each containing 6912 individual cells, with various degraded characteristics to emulate the degraded performance of used car batteries.
Since we don't have a physical connection between battery module and edge device, our QNX-powered Raspberry Pi receives this telemetry feed via TCP in binary format, emulating how the physical connections on BMSs receive data in operation.
The edge device then does some local monitoring on its own and can also trigger failsafes if certain operational limits are exceeded. This is to simulate how the BMS would react to anomalies if it were physically connected to the battery module by temporarily shutting down batteries or other physical measures in response to issues such as overheating, overcurrent, etc. We wanted to leverage the RTOS' low resource costs and guaranteed reliability to ensure the stability of the system.
The edge device also sends data to a FastAPI server, allowing users to view live telemetry on a web dashboard. In our current implementation, this data is sent via API requests, which we recognize is not an ideal setup. We will touch on the reasoning for this contingency below in the challenges section. The data is stored on a MongoDB Atlas cluster, and we have leveraged the Gemini API to provide live insights, visualizations, and battery health predictions, providing insights into all SLBs' potential performance and cost savings.
Challenges we ran into
Many of our challenges revolved around integrating our Raspberry Pi with the rest of our interface. Initially, connecting the battery simulator to the Pi required some minor problem-solving, but our problems really began once we tried connecting the Pi to our FastAPI server. At the moment, we are also using API requests to send data from the edge device to FastAPI. This is because we were unable to get a robust socket connection established between the Pi and the server.
Accomplishments that we're proud of
Creating multiple simulated battery packs with PyBamm to provide a demo of how our Raspberry Pi can monitor different batteries and respond to any anomalies that may come up with SLBs. Creating a TCP connection to stream binary telemetry data to the Pi to simulate how the edge BMS would receive telemetry from a physical connection to its battery module. Creating a live dashboard using Gemini to monitor telemetry and operational alerts.
What we learned
How to use a Raspberry Pi and QNX, creating a simulation environment
What's next for Revamp
Socket support and improved connection protocols between the edge device and the web server. Testing with a simulated fleet of multiple battery modules, each consisting of two or more battery packs.
Log in or sign up for Devpost to join the conversation.