openpilot 0.8.14
Big Model
We can distinguish between 2 main types of car ports:
No safety relevant code runs on the EON. To use functional safety terminology, the EON functionality is considered Quality Management (QM). This means that any failure in delivering the desired output at the right time is perceived as bad quality and has no safety implications. You might be perplexed: the code running on the EON is responsible, for example, for determining the desired car trajectory and you might think that a bug in this algorithm might be a safety threat. But it’s not, openpilot is a Level 2 ADAS system and the driver must pay attention at all time! No ADAS system currently on the market has safety guarantees on perception or planning algorithms.
So, what must be guaranteed is the ability of the driver to easily regain full control of the vehicle at any time. In openpilot, this is done through the satisfaction of the 2 main safety principles that a Level 2 driver assistance system must have:
These safety requirements, written as is, are still a little abstract and a further step is required to translate them into implementable requirements. We can develop them as follow.
openpilot is written to be as generic as possible, by separating car specific code (e.g. decoding CAN messages into generic car states, such as speed and acceleration) from common openpilot functionalities (e.g. perception, planning and high level controls).
With the exception of the panda safety code and the dbc file, the car specific code if fully contained in /data/openpilot/selfdrive/car/. When developing a car port you should focus on making changes to this folder only, although it’s possible that some generalization to the rest of the code are required. If you are making a Brand Port, you should create a new folder with the name of the brand you intend supporting. Otherwise, in the case of a Model Brand**, **you should only modify files within the existing car brand folder (e.g. /data/openpilot/selfdrive/car/toyota/).
In the case of a Brand Port, you should also implement a new safety model for the panda repo. Each car brand has at least one safety model associated to it (see header files in/data/openpilot/panda/board/safety/). Also, each safety model must have its own regression test file (see /data/openpilot/panda/tests/safety/), which you should submit as well as part of the pull request for the panda repo.
Writing a new safety model might seem hard at first. Luckily, there is a high chance that you car has longitudinal and lateral control APIs similar to some that already supported cars have.
For example, if the longitudinal control API allows to command directly the gas pedal and the brake pressure (see Chevy Volt), you might simply enforce that the gas and brake commands are constrained within values that satisfy the acceleration limits mentioned above.
In the case of a lateral control API based on steering torque (again, see Chevy Volt), you might want to enforce the max torque commanded and the rate at which such torque is commanded. Additionally, you might want to limit the steering torque when applied in the opposite direction of the torque applied by the driver.
Opening a pull request to openpilot is probably the best way to get support from the large comma.ai community. However, while you are welcome to open a car port pull request for openpilot at anytime, be conscious about the possibility that other users might be installing your WIP fork on their EON dev kit.
The panda repo is included within openpilot, but it’s maintained in its own repo. In the case of a Brand Port, you should submit a pull request to cover the safety in panda. See the above guidelines on how to write a safety model.
If needed, you should also open a pull request for the opendbc repo if the car you are writing the port for needs a new dbc file. We already have many dbc files, so your car might already be here.
opendbc and panda are independent repositories (shipped as subtrees in openpilot), so comma will merge those pull request before and regardless the status of the openpilot pull request. New dbc files and panda safety models are always welcome.
comma will review that proper safety code has been implemented. In the case of a** **Model Port, this is usually unnecessary as the safety code is shared with other already supported models.
If the safety model review is successful and comma has proof that the car port meets the quality standards (send us a video of your car being controlled by openpilot!), then the port can be listed in the “Community Maintained Cars” section of the openpilot README. A car listed in “Community Maintained Cars” does not guarantee that the comma safety model is met, just that enough diligence has been done for this step; the port can then be listed in the “Community Maintained Cars” section of the openpilot README.
At comma’s discretion, some car ports can be upstreamed into the openpilot repo and become officially supported, while other might maintain the status of “Community Maintained Cars” indefinitely. It mainly depends on the code quality/complexity of the pull request, and on the popularity of the car/the presence of such a brand in comma’s fleet. Feel free to bring your car to comma’s HQ for a test drive :)