Tesla Tinkering
The Tesla Model 3 has more cool features than you can throw an eclectic CEO at. From Autopilot to Emissions Testing, there is always another creative innovation guaranteed to amaze.
One such fun feature is the ability to record video from the vehicle’s cameras. There are two situations where this can be done.
- At any time during vehicle operation, you can save the last several minutes of video by tapping the Dashcam icon.
- When in Sentry Mode, video recorded during detected events is automatically saved.
The car doesn’t have onboard or cloud storage for recorded video. To enable the feature, you must format a USB flash drive with a FAT32 file system, add a root directory called “TeslaCam”, and plug the drive into the USB slot in the car. To access the stored video, remove the USB and plug it into a device to view or move the video files. Once the USB is full, the feature is not available until you free some of the USB storage by manually deleting files.
This is great, but it begs for improvement. It would be wonderful if the video would automatically stream to a data storage service like Google Drive or Dropbox. An embedded device that emulates a USB flash drive but then connects to your WiFi and uploads your videos would do the trick.
I dont know enough about USB to do this myself in the time that I have. Fortunately, it’s 2019. The open-source movement is so strong that not only has someone probably already done whatever you want to do, they probably made it available for free with detailed instructions on how to do it, and a team of volunteers now maintains and improves that project. That’s exactly the situation with Tesla’s video logging.
An Open Source Solution
Enter TeslaUSB, an open source project based on the Raspberry Pi Zero by GitHub user cimryan. The Raspberry Pi is a very small computer designed to run a simple Linux Operating System like Raspian. While the Raspberry Pi Zero only consumes about 0.7 W of power (much less than an incandescent light bulb), it has computing power similar to your smartphone. The TeslaUSB project takes a Raspberry Pi and turns it into a device that can be plugged into the Tesla USB port. The Tesla only sees a normal USB Flash drive and stores video on the Pi as it normally would. However, when the Pi detects your home WiFi network, it connects and moves the videos to a data storage service. This frees up its own storage space so that you never need to manually delete the videos. In fact, as long as you periodically drive your car within your home WiFi range, you don’t even need to think about it.
While the open source community can sometimes lack in maintenance and documentation, its strength is that anyone can pitch in and bring new life to a project. The forums from early this year are full of users who had problems with their TeslaUSB devices when Tesla released updates in 2019. A developer called marcone carried the torch, created a fork of the repository, and moved the project forward a bit, making the latest version compatible with Tesla’s current software version.
I couldn’t order a new Raspberry Pi from Amazon fast enough. When it arrived, I put a microSD card into my laptop and flashed the TeslaUSB image to it. I put the microSD into the Pi, plugged it in, and started a terminal session via SSH over USB. After this it was a matter of following the instructions in the Github repository readme file for how to configure the Pi so that it would upload video files to Google Drive. Things went smoothly, and before long the Tesla interface confirmed that video was being recorded.
If At First You Don’t Succeed, Search Existing Issues
I waited eagerly the next day to see video from the car in my Google Drive, but nothing happened. When I got home from My Lan’s preschool graduation that night, I opened a terminal program on my phone and started an SSH session with the Pi to investigate.
TeslaUSB creates a log file that details the progress of the main archive loop and records any warnings or errors. This file revealed that Rclone, the tool that TeslaUSB uses to communicate with Google Drive, was not able to find the configuration file it made during setup.
This wasn’t a surprise. The maintainers of this project prefer CIFS, which is a file storage system that works on a local network. They explicitly state that support for Rclone is limited and that there may be problems with getting a remote service working. Still, many users have reported success, so perseverance is warranted.
Searching through the issues in the cimryan TeslaUSB for similar problems yielded two pertinent threads. One user described the same error. My first attempt at a fix was to move the configuration file where the log indicated it was expected. Bingo! Almost immediately, videos started populating the Google Drive folder I’d designated for the upload.
However, another user hinted that this solution may be problematic. The new log files contained warnings that the Rclone configuration file could not be modified, proving him correct.
Here is what was happening. The TeslaUSB configuration protects large portions of the operating system from corruption by making them read-only. I’d inadvertently moved the configuration file to this read-only area. Rclone was able to access the contents of the file to upload videos to Google Drive, which includes a security token Rclone presents to Google’s servers to get permission to modify the contents of my Google Drive. Once the token expires, Rclone must renew and get a new token. It needs to store the new token in its config file, but this would fail because the file is in a read-only location. When the token expired, Rclone would lose access to Google Drive, and videos would stop being archived automatically.
The correct solution had already been proposed by rtanaka in a separate issue. The trick is to put the config file in a writable directory within the file system and then put a symlink to that directory in the expected location. A symlink is a feature of Linux operating systems that is similar to shortcuts in Windows. While the symlink was in a read-only part of the file system, the directory to which it points is in a writable location. The creation of this link was supposed to occur automatically during configuration, but for some reason did not. Once I made this change, the log file showed that files were being moved with no warnings or errors.
Excellent! Now, catching weirdos on video is effortless.
Nice Experiment, Really Delightful.