capnp struct definitions and messaging used in comma ecosystem
Go to file
Comma Device 1d193fb496 bodyStatus 2023-07-16 02:05:47 -07:00
.github/workflows fix names 2023-04-28 15:11:43 -07:00
include remove java.capnp 2021-10-11 14:35:46 -07:00
logger fix suppression for older cppcheck 2022-03-13 22:22:32 -07:00
messaging connect: add error messages when Socket connect fails (#456) 2023-06-02 15:14:08 -07:00
site_scons/site_tools
visionipc visionipc: get_endpoint_name python binding (#463) 2023-06-07 10:36:00 -07:00
.dockerignore
.gitignore include from project root (#402) 2022-12-31 14:19:29 -08:00
.pre-commit-config.yaml pre-commit: autoupdate hooks (#446) 2023-05-16 11:49:47 -07:00
Dockerfile include from project root (#402) 2022-12-31 14:19:29 -08:00
LICENSE
README.md Custom events reserved for forks (#449) 2023-05-23 20:44:17 +02:00
SConscript Custom events reserved for forks (#449) 2023-05-23 20:44:17 +02:00
SConstruct CI: run tests with sanitizers (#438) 2023-04-28 15:08:57 -07:00
__init__.py Custom events reserved for forks (#449) 2023-05-23 20:44:17 +02:00
car.capnp Deprecate brakeUnavailable event (#455) 2023-05-31 15:08:17 -07:00
codecov.yml
custom.capnp Custom events reserved for forks (#449) 2023-05-23 20:44:17 +02:00
generate_javascript.sh
legacy.capnp bring qcomgnss back from deprecation 2022-03-23 15:50:02 -07:00
log.capnp bodyStatus 2023-07-16 02:05:47 -07:00
maptile.capnp get rid of the java (#199) 2021-09-21 14:48:35 -07:00
services.py bodyStatus 2023-07-16 02:05:47 -07:00

README.md

What is cereal? cereal tests codecov

cereal is both a messaging spec for robotics systems as well as generic high performance IPC pub sub messaging with a single publisher and multiple subscribers.

Imagine this use case:

  • A sensor process reads gyro measurements directly from an IMU and publishes a sensorEvents packet
  • A calibration process subscribes to the sensorEvents packet to use the IMU
  • A localization process subscribes to the sensorEvents packet to use the IMU also

Messaging Spec

You'll find the message types in log.capnp. It uses Cap'n proto and defines one struct called Event.

All Events have a logMonoTime and a valid. Then a big union defines the packet type.

Best Practices

  • All fields must describe quantities in SI units, unless otherwise specified in the field name.
  • In the context of the message they are in, field names should be completely unambiguous.
  • All values should be easy to plot and be human-readable with minimal parsing.

Maintaining backwards-compatibility

When making changes to the messaging spec you want to maintain backwards-compatability, such that old logs can be parsed with a new version of cereal. Adding structs and adding members to structs is generally safe, most other things are not. Read more details here.

Custom forks

Forks of openpilot might want to add things to the messaging spec, however this could conflict with future changes made in mainline cereal/openpilot. Rebasing against mainline openpilot then means breaking backwards-compatibility with all old logs of your fork. So we added reserved events in custom.capnp that we will leave empty in mainline cereal/openpilot. If you only modify those, you can ensure your fork will remain backwards-compatible with all versions of mainline cereal/openpilot and your fork.

Pub Sub Backends

cereal supports two backends, one based on zmq and another called msgq, a custom pub sub based on shared memory that doesn't require the bytes to pass through the kernel.

Example

import cereal.messaging as messaging

# in subscriber
sm = messaging.SubMaster(['sensorEvents'])
while 1:
  sm.update()
  print(sm['sensorEvents'])

# in publisher
pm = messaging.PubMaster(['sensorEvents'])
dat = messaging.new_message('sensorEvents', size=1)
dat.sensorEvents[0] = {"gyro": {"v": [0.1, -0.1, 0.1]}}
pm.send('sensorEvents', dat)