Virtually recreating the Tesla Roadster with open source tools

Published:

Topics: Open source tools, Open hardware

The “killer feature” of open source is its transformative power in enabling collaborative vertical integration, where instead of building up silos of divergent capabilities, organizations can collaborate freely, combining their strengths and perspectives while remaining in full control of their own fate.

This reflects what true science is about; while, naturally, everyone wants to be the first to discover a specific phenomenon, the scientific method relies on reproducibility and verifiability of results. Open source software is the perfect embodiment of this idea, and the “show me the code or it didn’t happen” approach is becoming the expected default in fastest-growing software domains such as AI.

The trend is fueled in part by the world’s largest tech companies like Google, Tesla or Meta, for whom time is the most valuable asset, and the diversity, mutual inspiration and breakneck development pace characteristic of the open source ecosystem is in line with their interests and ambitions.

Hardware has been slower to adopt this mindset, but there are notable exceptions, such as the involvement of chip design behemoths AMD and NVIDIA together with hyperscalers like Google and Microsoft in open source silicon standards and efforts such as RISC-V or CHIPS Alliance, both of which Antmicro has helped co-found.

Physical products are yet another step removed from this; their concept, design and manufacturing methodologies are typically considered the most precious “industry secrets”. This is why it is hard to understate the importance of forerunners of change, like Tesla’s open patents pledge and, most recently, its announcement of the open source release of some of the assets constituting the hardware and software of the original Tesla Roadster. And while many focused on the fact that those assets were not as complete as they would have hoped, we thought it would be better to see how far you can really go with what’s already available by putting Antmicro’s open source toolkit to work.

Open source, vertical integration and deep understanding

Prioritizing vertical integration is known to be a key value at Tesla, which in the exactly 16 years between the Roadster’s release and today has grown from a luxury niche car manufacturer to a large automaker with mass manufacturing capability using their Gigafactories. Thanks to nearly complete ownership over their entire stack, Tesla repeatedly readjusts their complex design and development process to keep delivering cars to customers whatever the situation. That is one of the reasons why, unlike its competitors, Tesla could continue growing during the chip shortage, while others struggled.

Enthusiasts and experts like Sandy Munro, an engineer and educator who delves into the intricacies of electric vehicles, have been tracking the impressive resilience of Tesla to external factors and praising the company for smart engineering practices like component reuse and vertical integration. That trait extends even between Musk’s companies, with the new Roadster announced to be a collaboration leveraging SpaceX’s prowess with rocket engines to achieve better-than-ludicrous acceleration. It’s also no wonder SpaceX vessel on board computers, Starlink and later Tesla cars run buildroot.

Antmicro has always believed vertical integration and deep understanding to be fundamental requirements for true innovation, and the transparency, full control and potential for collaboration which come with open source are an integral part of Antmicro’s business strategy and offering. We have been building an open source toolkit which enables hardware customers to own their technology stack, bringing hardware concepts to life using software, in a transparent and reproducible way. This includes an open source simulation framework, Renode, as well as an open source hardware component library and flow and other tools, which together let development teams virtually develop and visualize their hardware and firmware before it’s even ready – or enable deep understanding of how it works, as in the case of the original Roadster, as described below.

Recreating the Tesla Roadster with open source, illustration

The released Roadster components, visualized

The key software element released by Tesla is an .iso image with a Linux-based system that service shops would use for updating firmware on the vehicles, containing several versions of Linux firmware for the Roadster’s Vehicle Management System (VMS) board based on NXP LPC2294 platform (an ARM7TDMI-S SoC), alongside bare metal firmware for the Vehicle Display System (VDS) based on Sharp LH75401 (since then acquired by NXP, also an ARM7TDMI-S) and the HVAC controller based on NXP MC9S12DP512MPVE, a 16-bit MCU. The VMS is responsible for managing Roadster’s onboard systems, including the Battery Management System board and the VDS, which we discuss further in this note.

For developing the hardware, software and simulation models for complex devices such as cars or spacecraft OBCs, Antmicro develops and uses a tool called Visual System Designer, which provides a single source of truth to drive the co-development across multiple domains. VSD lets our teams assemble hardware building blocks (SoCs, sensors etc.) into complete systems (like a Roadster’s on-board computing system) while visualizing relations between the different elements.

Based on the information released by Tesla, we can map out at least a part of the onboard electronics system of the original Roadster, as depicted by the interactive diagram below. On the diagram you can see how the Vehicle Management System is connected to the Battery Monitoring System board and the Vehicle Display System board over CAN, as well as some of the interfaces and peripherals within the Battery Monitoring board and the Vehicle Display System board.

VSD iframe

(For an interactive version of the diagram, visit the desktop version of the website)

Simulating the Roadster firmware with Renode

Access to firmware provided by Tesla presents some interesting learning opportunities provided you can run it. While we don’t happen to own an original Roadster, around the time of the car’s original release we created – and continue to develop – the previously mentioned Renode open source simulation framework, which can execute production binaries across a variety of hardware platforms. Renode is already widely used in automotive, space use cases and helps develop and test real products; so putting it to use given such a unique opportunity seemed obvious.

The hardware of the original Roadster is, naturally, somewhat dated, corresponding to the state-of-the art of 2008, the time when it was first released – around the primetime debut of Android and a year after the release of the original iPhone. While this time gap is eons for consumer electronics, industries like automotive or space need to provide extended longevity, rendering support for “old” hardware as well as a focus on backward compatibility actually useful and desirable.

As mentioned before, the binaries for the Vehicle Management System (VMS) board are meant to be executed on the NXP LPC2294, a 32-bit ARM microcontroller that communicates with other parts of the Roadster via CAN. (Since NXP is widely used among our industrial customers, Renode supports a variety of much newer NXP platforms, including recent automotive MCUs). Subsequently, we were able to emulate the LPC platform and run Linux from the image. Running the binary, we observed multiple types of CAN messages being generated; e.g. VMS uses CAN to connect to the Power Electronics Module responsible for controlling the power going to and from the motor, as well as DC to AC (required by the motor) and AC to DC (charging) conversions. As all UART messages for the board are exchanged over the CAN interface, we created and added a CANtoUART model.

We have prepared a repository containing a script that runs the original files from Tesla’s repository on the NXP LPC2294 in a Renode simulation. To run the VMS firmware locally, you will need a recent version of Renode.

The repository contains everything you need to run the demo in Renode, including the original teslamotors/roadster repository as a submodule (in roadster_release) which in turn contains a copy of the Roadster diagnostic disc image.

To be able to get the .iso file, you need to make sure you have GitLFS set up.

With Git LFS installed, clone this repository recursively using:

git clone --recursive https://github.com/antmicro/renode-tesla-roadster-simulation.git

Now, you need to extract the firmware.rc, linux.bin and vms.image files from the image to the repo directory. Refer to the README for detailed instructions.

To run the VMS firmware interactively, execute:

renode roadster.resc

You will see the Renode Monitor, as well as an analyzer window displaying the CAN boot message console. Note that once the vms binary starts you will not be able to interact with the console. The following recording demonstrates this (note that the GUI is disabled, so the Monitor and UART output both appear in the shell):

You can also run a Robot test which verifies decoding of the CAN messages transmitted by the VMS firmware:

renode-test roadster.robot

You can use the --show-log option to view the output in real time and see the decoded CAN messages as they come in.

This is, of course, just the tip of the iceberg of what Renode enables you to do. Provided that the binary you are executing contains a symbol map (as it normally does during the development process), you will be able to trace its execution, get detailed logs including executed function names, peripheral accesses and opcode counting, generate code coverage reports and use advanced GDB integrations. Renode is also equipped with a built-in disassembler and metrics analyzer, lets you mock elements of a device using tags, integrates with external analyzers like Wireshark, and lets you use hooks to monitor or alter the execution of your binaries by, e.g. spoofing registers/memory states or injecting (network, CAN, etc.) messages to trigger behaviors of software. Given interest, we will demonstrate some of those features in follow up articles.

Visualizing the Roadster hardware with an open source flow

As part of its initial release, Tesla’s Roadster repository contained manufacturing files for two boards inside the original Roadster – the Vehicle Display System Controller and the Battery Management System. For each of the Roadster boards, the released data contained Gerber production files and pick-and-place, or PnP files (originally prepared in Altium Designer, a PCB design tool interestingly in the process of being acquired by Renesas, a large semicon manufacturer heavily focused on automotive whom we are collaborating with around Renode). While having the original design would be the most convenient, the published assets are still extremely interesting from the perspective of repairability (for the original owners), education and documenting an important part of EV history.

Our open source hardware design flow based on KiCad, Blender, openEMS and other open source tools and our open source library allows us to generate beautiful 3D renders, provide assembly drawings, perform signal integrity analysis and present entire products in complex views. While normally the flow helps us customize our extensive open hardware design portfolio (as visible on our Open Hardware Portal which uses the flow to generate interactive 3D visualizations) for the commercial designs we create, it can be used with arbitrary hardware too, including the Roadster boards.

Some of the component footprints were not present in our open component library, but the pick and place files enabled us to determine what these components are, add them to the database, generate their 3D models and add some color to them. Below, you can play around with interactive renders of both boards.

Vehicle Display System controller board

VSD iframe

Battery Management System board

VSD iframe

(For interactive renders, visit the desktop version of the website)

Open source enables true vertical integration and collaboration

Releasing some of the assets for the original Roadster by Tesla provides a unique sneak peek into the inner workings of a real car’s on-board hardware and software, as this level of disclosure from a car manufacturer is unprecedented. The examples above illustrate how access to information and employment of an open source workflow can build better understanding of technology, provide control over each step of the design and manufacturing process to their users, make transparency a default, encourage collaboration, and positively affect the longevity of a project.

By adapting and advocating for an open approach across multiple industries (Tesla opening EV patents, charging port standards and releasing Roadster files, Twitter/X open sourcing the algorithm and open source release of xAI), companies run by Elon Musk are setting some interesting precedents and it will be exciting to see what comes next.

Antmicro believes that the open source approach to commercializing technology is the best path to create a transparent, truly vertically integrated company that draws on many sources of inspiration, and inspires others to do the same.

See Also: