* Add buffer length parameter for enhanced frame handling
Introduce a configurable `buffer_length` parameter to `DrivingModelFrame` to support dynamic buffer sizes, enabling better handling of different frame rates like 20Hz. Updates include necessary adjustments in buffer initialization, copying logic, and related model inputs for improved compatibility and flexibility.
* Rename variable `len` to `length` to avoid shadowing built-in.
Replaced the usage of `len` with `length` across the code to prevent conflicts with Python's built-in `len` function. This improves code clarity and reduces potential errors or misunderstandings in variable usage.
* Fix spacing inconsistency in modeld.py
Added a missing newline for better code readability and consistency. This change has no impact on functionality but improves code formatting.
* Move numpy_inputs initialization to correct position
Repositioned the `numpy_inputs` initialization to align with the input shape processing logic. This ensures consistency in buffer management and clarifies the flow of code execution related to input handling.
* Add 20Hz model state, smart input, and model switcher classes
Introduce `ModelState20Hz`, `ModelSmartInput`, and `ModelSwitcher` for enhanced modularity and flexibility in modeld. Refactor `ModelState` to inherit from these new classes, enabling support for 20Hz processing and smart input initialization. Update associated files to handle the new buffer length parameter and metadata management.
* Refactor `modeld` to streamline feature handling logic
Simplified feature processing for both standard and "smart input" modes by consolidating logic into reusable methods. Updated variable naming, formatting, and spacing for consistency and readability. This refactor enhances maintainability and reduces redundancy in feature update operations.
* Silence debug print statements and use cloudlog for warnings.
Commented out a debug print statement in `commonmodel.cc` to reduce noise. Replaced `print` statements with `cloudlog.warning` in `model_smart_input.py` for improved logging consistency and better integration with the logging system.
* Clean up formatting and fix minor style inconsistencies
Removed unnecessary blank lines and adjusted spacing to standardize code style across the file. These changes improve readability without altering functionality or logic.
* Refactor modeld logic and remove unused 20Hz and smart inputs
Eliminated `ModelSmartInput`, `ModelSwitcher`, and `ModelState20Hz` classes, simplifying model state handling. Centralized model processing within a unified `ModelState` class and moved related code into `sunnypilot/modeld_20hz`. This improves maintainability by removing unused features and consolidating model execution logic, aligning with current system requirements.
* clean
* Remove debug print statement in commonmodel.cc
The `printf` statement logging buffer movement details was removed as it is unnecessary for release builds. This helps streamline the code and avoid excessive console output during execution.
* Refactor model handling for 20Hz and introduce model runners
Introduce ModelRunner abstraction with TinygradRunner and ONNXRunner to streamline model handling for TICI and non-TICI hardware. Added support for dynamic input preparation and 20Hz models while simplifying the model parsing logic. This improves modularity, readability, and extensibility for future updates.
* Remove unused import and fix import order in model_runner.py
This commit removes the unused 'dtypes' import from tinygrad.tensor and adjusts the import order for cleaner code. These changes enhance readability and maintain coding standards.
* Add is20hz field to custom.capnp schema
Introduce a new boolean field `is20hz` to the `custom.capnp` schema. This allows the system to identify 20Hz-specific configurations or data processing. No changes to existing behavior are introduced for non-20Hz cases.
* Add Meta20hz class for 20Hz model message handling.
Introduces a new Meta20hz class for filling 20Hz model messages, encapsulating functionality for curvature, lane lines, road edges, and more. Refactored `modeld.py` to utilize the new class, improving modularity and maintainability. Minor adjustments were made to initialize and handle model metadata.
* Refactor import paths to align with `openpilot` structure.
Updated several import statements to use the `openpilot` namespace for better consistency and organization. This aligns the sunnypilot components more closely with the overall project structure.
* Refactor modeld to support 20Hz models and modularize runners
Replaced legacy runner logic with a unified ONNX and Tinygrad runner to support 20Hz models. Centralized model metadata management and optimized input preparation for adaptability. Updated curvature handling and output parsing for improved modularity and maintainability.
* Add 20Hz metadata handling for model predictions
Introduce `Meta20hz` class for 20Hz-specific metadata and implement dynamic loading of meta model classes in `meta_helper.py`. Update `fill_model_msg.py` to use the new metadata structure, ensuring seamless integration with 20Hz models. Adjust imports in `model_runner.py` to align with project structure.
* "Refactor modeld_20hz to modeld_v2 with cleanup"
Refactored `modeld_20hz` module to `modeld_v2` for improved clarity and consistency. Removed unused code and aligned imports across modules to reflect the new structure. Enhanced maintainability by restructuring model-related files and updating references accordingly.
* Refactor variable names and adjust imports for clarity.
Renamed `len` to `length` to avoid conflict with the built-in function and improve readability. Reorganized imports in `fill_model_msg.py` for better structure and consistency.
* "Add missing newline at end of file in __init__.py
Ensure proper formatting by adding a newline at the end of the file. This adheres to POSIX standards and improves compatibility with some tools and version control systems."
* Handle model runner initialization errors gracefully
Wrap the model runner initialization in a try-except block to catch and log exceptions. This ensures that failures during initialization are logged with detailed information, improving debugging and error tracing.
* Refactor curvature calculation for clarity and reuse.
Introduce a dedicated `get_curvature_from_output` function to handle desired curvature retrieval, improving code readability and reusability. Replace redundant logic in curvature calculation with the new function to streamline the flow.
* Make 20Hz-specific variables conditional in modeld.py
Moved the initialization of 20Hz-specific variables to be conditional based on the `is_20hz` flag. This ensures that unnecessary memory allocations are avoided when the model is not running at 20Hz, improving efficiency and clarity.
* cleanup
---------
Co-authored-by: Jason Wen <haibin.wen3@gmail.com>
openpilot
openpilot is an operating system for robotics.
Currently, it upgrades the driver assistance system in 275+ supported cars.
Docs · Roadmap · Contribute · Community · Try it on a comma 3X
Quick start: bash <(curl -fsSL openpilot.comma.ai)
Using openpilot in a car
To use openpilot in a car, you need four things:
- Supported Device: a comma 3/3X, available at comma.ai/shop.
- Software: The setup procedure for the comma 3/3X allows users to enter a URL for custom software. Use the URL
openpilot.comma.aito install the release version. - Supported Car: Ensure that you have one of the 275+ supported cars.
- Car Harness: You will also need a car harness to connect your comma 3/3X to your car.
We have detailed instructions for how to install the harness and device in a car. Note that it's possible to run openpilot on other hardware, although it's not plug-and-play.
Branches
| branch | URL | description |
|---|---|---|
release3 |
openpilot.comma.ai | This is openpilot's release branch. |
release3-staging |
openpilot-test.comma.ai | This is the staging branch for releases. Use it to get new releases slightly early. |
nightly |
openpilot-nightly.comma.ai | This is the bleeding edge development branch. Do not expect this to be stable. |
nightly-dev |
installer.comma.ai/commaai/nightly-dev | Same as nightly, but includes experimental development features for some cars. |
To start developing openpilot
openpilot is developed by comma and by users like you. We welcome both pull requests and issues on GitHub.
- Join the community Discord
- Check out the contributing docs
- Check out the openpilot tools
- Read about the development workflow
- Code documentation lives at https://docs.comma.ai
- Information about running openpilot lives on the community wiki
Want to get paid to work on openpilot? comma is hiring and offers lots of bounties for external contributors.
Safety and Testing
- openpilot observes ISO26262 guidelines, see SAFETY.md for more details.
- openpilot has software-in-the-loop tests that run on every commit.
- The code enforcing the safety model lives in panda and is written in C, see code rigor for more details.
- panda has software-in-the-loop safety tests.
- Internally, we have a hardware-in-the-loop Jenkins test suite that builds and unit tests the various processes.
- panda has additional hardware-in-the-loop tests.
- We run the latest openpilot in a testing closet containing 10 comma devices continuously replaying routes.
Licensing
openpilot is released under the MIT license. Some parts of the software are released under other licenses as specified.
Any user of this software shall indemnify and hold harmless Comma.ai, Inc. and its directors, officers, employees, agents, stockholders, affiliates, subcontractors and customers from and against all allegations, claims, actions, suits, demands, damages, liabilities, obligations, losses, settlements, judgments, costs and expenses (including without limitation attorneys’ fees and costs) which arise out of, relate to or result from any use of this software by user.
THIS IS ALPHA QUALITY SOFTWARE FOR RESEARCH PURPOSES ONLY. THIS IS NOT A PRODUCT. YOU ARE RESPONSIBLE FOR COMPLYING WITH LOCAL LAWS AND REGULATIONS. NO WARRANTY EXPRESSED OR IMPLIED.
User Data and comma Account
By default, openpilot uploads the driving data to our servers. You can also access your data through comma connect. We use your data to train better models and improve openpilot for everyone.
openpilot is open source software: the user is free to disable data collection if they wish to do so.
openpilot logs the road-facing cameras, CAN, GPS, IMU, magnetometer, thermal sensors, crashes, and operating system logs. The driver-facing camera is only logged if you explicitly opt-in in settings. The microphone is not recorded.
By using openpilot, you agree to our Privacy Policy. You understand that use of this software or its related services will generate certain types of user data, which may be logged and stored at the sole discretion of comma. By accepting this agreement, you grant an irrevocable, perpetual, worldwide right to comma for the use of this data.