Files
clearpilot/panda
brianhansonxyz 0dc8002c6d revert hyundai canfd torque to stock; park-publish keepalive; dashcam idle on park
Three independent changes bundled together.

Revert hyundai canfd steering torque limits to comma stock defaults
(270 / 2 / 3 / 112) in both panda safety and openpilot CarControllerParams.
The 270->324 bump caused overcorrection on turns and weaving on straights.
Web research turned up no public reports of any 4th gen Tucson NX4 owner
bumping STEER_MAX — the documented Tucson tuning effort is entirely on
lateralTuning (latAccelFactor ~2.9-3.1, friction ~0.095), not the cap.
hoomoose's EV6/Ioniq 5 PR #25723 is the canonical "raise STEER_MAX
without dropping latAccelFactor causes overcorrection" data point — and
even that change was reverted upstream. Right next move for this car is
to tune latAccelFactor / friction, not the torque ceiling.

plannerd: keep publishing longitudinalPlan at the normal cadence in park,
but skip update() compute. Skipping publishes entirely caused
longitudinalPlan to time out the alive flag at controlsd, which fired a
real commIssue ("not_alive") on park->drive. Stale published values are
fine because controlsd's own park short-circuit ignores the
longitudinalPlan content while parked. Also gate publish_ui_plan on
not-parked: it reads longitudinal_planner.a_desired_trajectory_full
which is only set inside update(), so calling it without a prior update
crashes plannerd with AttributeError (which fires "Process Not Running"
on screen). uiPlan is UI-only, not on controlsd's commIssue check list,
so going silent in park is fine.

frogpilot_process: same idea — keep publishing frogpilotPlan in park to
keep alive, skip the heavy update() compute.

dashcamd: close the trip immediately on gear shift to PARK (was: 10-min
idle timer before close). User wants the dashcam idle in park and a
fresh trip on every drive engagement; brief drive-thru / fuel-stop
across-trip continuity isn't valued.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 13:18:46 -05:00
..

Welcome to panda

panda tests panda drivers

panda speaks CAN and CAN FD, and it runs on STM32F413 and STM32H725.

Directory structure

.
├── board           # Code that runs on the STM32
├── drivers         # Drivers (not needed for use with Python)
├── python          # Python userspace library for interfacing with the panda
├── tests           # Tests and helper programs for panda

Safety Model

When a panda powers up, by default it's in SAFETY_SILENT mode. While in SAFETY_SILENT mode, the CAN buses are forced to be silent. In order to send messages, you have to select a safety mode. Some of safety modes (for example SAFETY_ALLOUTPUT) are disabled in release firmwares. In order to use them, compile and flash your own build.

Safety modes optionally support controls_allowed, which allows or blocks a subset of messages based on a customizable state in the board.

Code Rigor

The panda firmware is written for its use in conjuction with openpilot. The panda firmware, through its safety model, provides and enforces the openpilot safety. Due to its critical function, it's important that the application code rigor within the board folder is held to high standards.

These are the CI regression tests we have in place:

  • A generic static code analysis is performed by cppcheck.
  • In addition, cppcheck has a specific addon to check for MISRA C:2012 violations. See current coverage.
  • Compiler options are relatively strict: the flags -Wall -Wextra -Wstrict-prototypes -Werror are enforced.
  • The safety logic is tested and verified by unit tests for each supported car variant. to ensure that the behavior remains unchanged.
  • A hardware-in-the-loop test verifies panda's functionalities on all active panda variants, including:
    • additional safety model checks
    • compiling and flashing the bootstub and app code
    • receiving, sending, and forwarding CAN messages on all buses
    • CAN loopback and latency tests through USB and SPI

The above tests are themselves tested by:

  • a mutation test on the MISRA coverage
  • 100% line coverage enforced on the safety unit tests

In addition, we run the ruff linter and mypy on panda's Python library.

Usage

Setup dependencies:

# Ubuntu
sudo apt-get install dfu-util gcc-arm-none-eabi python3-pip libffi-dev git

# macOS
brew install --cask gcc-arm-embedded
brew install python3 dfu-util gcc@13

Clone panda repository and install:

git clone https://github.com/commaai/panda.git
cd panda

# install dependencies
pip install -r requirements.txt

# install panda
python setup.py install

See the Panda class for how to interact with the panda.

For example, to receive CAN messages:

>>> from panda import Panda
>>> panda = Panda()
>>> panda.can_recv()

And to send one on bus 0:

>>> panda.can_send(0x1aa, "message", 0)

Note that you may have to setup udev rules for Linux, such as

sudo tee /etc/udev/rules.d/11-panda.rules <<EOF
SUBSYSTEM=="usb", ATTRS{idVendor}=="bbaa", ATTRS{idProduct}=="ddcc", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="bbaa", ATTRS{idProduct}=="ddee", MODE="0666"
EOF
sudo udevadm control --reload-rules && sudo udevadm trigger

The panda jungle uses different udev rules. See the repo for instructions.

Software interface support

As a universal car interface, it should support every reasonable software interface.

Licensing

panda software is released under the MIT license unless otherwise specified.