Quintine
b598ba5dcb
The Seal EPS reports steering torque/prepare/activated state on
508 STEERING_TORQUE_ANGLE (different bit layout; driver torque factor
0.1), unlike the Han which uses 792 STEERING_TORQUE. The Seal's
fingerprint contains 508 but not 792, so alive-checking 792 tripped
canError ("Unknown Vehicle Variant") the moment the interface started.
- carstate: per-platform steering message selection (508 strict-checked
on Seal, 792 on Han; the other parsed opportunistically)
- carcontroller: don't send 792-layout camera feedback on the Seal;
stock 508 forwards unmodified for now (camera-feedback spoofing for
the Seal's 508 to be evaluated after a bus dump + road test)
- panda byd.h: rx check accepts 792 or 508 (first-seen-wins), torque
sampling handles both layouts, driver torque rescaled for 508's 0.1x
factor
- panda firmware rebuilt (panda_h7.bin.signed)
- tests: Seal(508) + Han(792) both verified canValid with correct
torque values; 120 safety tests + MISRA clean
Welcome to panda
panda speaks CAN and CAN FD, and it runs on the STM32H725.
Directory structure
.
├── board # Code that runs on the STM32
├── python # Python userspace library for interfacing with the panda
├── tests # Tests for panda
├── scripts # Miscellaneous used for panda development and debugging
├── examples # Example scripts for using a panda in a car
Safety Model
panda is compiled with vehicle-specific safety logic provided by opendbc. See details about the car safety models, safety testing, and code rigor in that repository.
Code Rigor
The panda firmware is written for its use in conjunction 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 strict: the flags
-Wall -Wextra -Wstrict-prototypes -Werrorare 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 SPI
The above tests are themselves tested by:
- a mutation test on the MISRA coverage
- a mutation test on the vehicle-specific safety logic
Usage
git clone https://github.com/commaai/panda.git
cd panda
# setup your environment
./setup.sh
# build fw + run the tests
./test.sh
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:
>>> from opendbc.car.structs import CarParams
>>> panda.set_safety_mode(CarParams.SafetyModel.allOutput)
>>> panda.can_send(0x1aa, b'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}=="0483", ATTRS{idProduct}=="df11", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="3801", ATTRS{idProduct}=="ddcc", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="3801", ATTRS{idProduct}=="ddee", MODE="0666"
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.
Licensing
panda software is released under the MIT license unless otherwise specified.