-
System Architecture
-
Our Implementation
Inspiration
As time progresses, two trends in consumer vehicles are becoming clear. First, cars are embracing full electrification as battery tech improves. Second, cars are increasingly using (relitively) powerful computers instead of a massive collection of bus connected controllers. This brings up the interesting perspective that, when parked and plugged in, EVs are essentially just a computer, complete with networking. Consider now that UofM is transitioning to a full electric fleet. Overnight, this fleet will be plugged in and within networking range of the university. We propose that this fleet is actually a supercomputer in hiding. Given UofM's power in reasurch, we belive that reasurch projects can ultilise these cars to perform work that would otherwise have to be done in data centers. To show show the potential of this proposal, we create a proof of concept using the legandary folding@home distributed computing project.
What it does
Our demo emulates multiple cars using the Ford API. When a car is detected as being in the UofM fleet lot and charging, it will begin to use folding@home, and alert a dashboard of its presense. When the vehicle is detected as leaving the lot, folding@home is stopped to conserve battery for travel. A simple dashboard can be used by the end client to observe what cars are currently computing, and their respective battery charge percentages.
How we built it
The code is split amongst two docker containers and a static site. The first docker container hosts a python script that will poll the Ford API for multiple vehicle statuses (in production, only a single vehicle id would be used, being the vehicle we are running on). When the vehicle status is detected as plugged in on site, folding@home is launched via a bash script. When this occurs, we send an HTTP message to our backend API, registering the vehicle as computing. When the vehicle is detected as not charging on site, folding@home is safely stopped, and a DELETE request is sent to the backend to remove the car from the list. This backend is written in Rust and runs on a seperate docker container (to emulate the network that would exist between the car and backend server in real life). It also serves a static site, which is what will be used by the end client. This site continuelly polls the backend to update a table of connected vehicles, which will quickly react to changes.
Challenges we ran into
Getting folding@home to run in a docker container was fairly difficult, as it prompted for user input a lot. Most of our members we're also new to web-dev, so there was a lot of diffuculty working with both APIs.
Accomplishments that we're proud of
The docker container reacts to Ford API changes and launches folding@home very quickly and reliably, which was a welcome suprise, because folding@home is not normally automated this way. We also generally feel that this idea is genuinly very exciting, since automotive fleets will only get more electrified from here. Should this idea be taken up, we will be able to much more effeciently utilise the resources that go into building electric vehicles.
What we learned
Many of our members got exposure to working with third party APIs, and exposure to structuring Python code for easier debugging. I also personally got some experience working with docker compose, which has been very convienient.
What's next for Folding@car
A lot could be done to improve this project, but the code as is is mostly a proof of concept. I would be interested in bringing up this idea with my edge computing professor, since this idea seems quite promising as a reasurch interest.
Log in or sign up for Devpost to join the conversation.