LCM Message Definitions

This repository contains LCM message definitions for the Dimos project and tools to generate those language bindings.

It depends on our LCM fork for generation since we introduced some convinience changes to python message definitions.

lcmgen from our lcm fork is conviniently pulled and built by our flake.nix

Generating Bindings

Run generate.sh to regenerate all bindings:

./generate.sh

This will:

1. Convert ROS messages to LCM definitions (from sources/ros_msgs/ to lcm_types/)
2. Generate Python bindings (generated/python_lcm_msgs/)
3. Generate C++ bindings (generated/cpp_lcm_msgs/)
4. Generate C# bindings (generated/cs_lcm_msgs/)
5. Generate Java bindings (generated/java_lcm_msgs/)
6. Generate Typescript bindings (generated/ts_lcm_msgs/)
7. Generate Rust bindings (generated/rust_lcm_msgs/)

Directory Structure

• sources/ - Source ROS message definitions and conversion tools
• lcm_types/ - Generated LCM message definitions
• generated/ - Generated language bindings

Python Package

This repo is also a Python package and you can install it via pip install dimos-lcm It is not very useful standalone and is meant to be used in conjuction with actual dimOS

Control values

The control_msgs package also contains the upstream ROS 2 control_msgs messages (ros-controls/control_msgs, e.g. DynamicJointState, InterfaceValue), converted from sources/ros_msgs/control_msgs/. ControlValues below is dimos-specific and not a ROS type.

control_msgs.ControlValues carries continuous command or state data between a control coordinator and device-owning connections. The stream/topic determines the direction; both use the same wire type.

The two array-length fields are LCM encoding fields and must match their arrays and each other. Consumers must reject duplicate or undeclared names, non-finite values, and invalid or stale epochs/sequences. The generated codecs serialize data; they do not enforce these application-level checks. Timestamps alone do not establish freshness across machines with unsynchronized clocks.

Interface names and their units, ownership, and supported combinations come from the resolved connection configuration. The codec does not interpret names or distinguish robot families. Examples include joint position/velocity for arms, position/velocity/effort/gains for whole-body control, pose coordinates, and linear/angular velocity for bases. Pose reference frames must be defined by the interface contract; they are not inferred from the values.

Empty frames are encodable. Whether they serve as heartbeats, whether frames are complete or sparse, and what an omitted command means are runtime contract decisions, not codec behavior. This schema does not authorize motion or implement a watchdog.

Descriptions are supplied through startup configuration, not LCM announcements. Discrete lifecycle requests and their results belong to RPC. No description, readiness, or lifecycle message types are added by this contract.

Validate the Python codec with:

python -m unittest discover -s tests -v