Source: https://broxme.com/core

Core Technology 

# Broxme Core

Broxme Core is the software foundation we’re developing around Studio’s internal project models, program execution, and simulation.

Core is in development. The components described here run inside the engineering build, with public interfaces still being defined.

[Explore Developer Tools](https://broxme.com/developers) [View development status](https://broxme.com/core#development)

Areas of Development 

## The pieces that connect a robotics project.

Studio saves robot definitions and programs together. Its runtime executes robot instructions against simulated state, and the debugger can record that state for inspection.

### Shared Robotics Project Models

Give robot definitions, programs, and learning workflows a consistent project representation.

### Command and Execution Workflows

Translate Studio’s supported programming workflows into a common intermediate representation for execution.

### Simulation Integration

Connect project models to deterministic simulation so behavior can be inspected and reproduced.

### Hardware Abstraction

Keep device interfaces separate from project semantics as supported transport and hardware paths are tested.

### Extensibility and Compatibility

Develop understandable boundaries for extensions, project interchange, and integration.

### Validation and Diagnostics

Make project errors, runtime behavior, and test results easier to inspect.

Runtime and replay 

## Keep enough context to explain a run.

Core’s fixed-step simulation and recording tools make it possible to inspect when a command ran and how the virtual robot responded. A useful trace also identifies the conditions that produced it.

### Use the simulation clock

Associate each simulated sensor reading and robot command with a simulation tick. Keep elapsed wall-clock time separately when measuring performance. ROS 2’s clock design explains why playback and simulation need an adjustable time source.

[Read the ROS 2 clock design](https://design.ros2.org/articles/clock_and_time.html)

### Record run provenance

Keep the project and software build alongside the recording. Note the starting pose, simulator settings, inputs, and any random seed used by the scenario. MCAP documents a standard for recording timestamped messages, and Studio’s tools implement a limited profile.

[Read the MCAP specification](https://mcap.dev/spec)

[Check recording compatibility](https://broxme.com/robotics-development-guide#compatibility)

### Find the first divergence

When two runs differ, align them by tick and compare sensor readings, program decisions, and applied commands in order. The first mismatch helps locate the component that needs investigation.

[Review Studio’s execution flow](https://broxme.com/robotics-development-guide#studio-architecture)

In Development 

## What still needs release validation.

Public API contracts and compatibility guidance are in development. Format interchange and hardware adapters need validation for each supported configuration.

### Understandable interfaces

Make data contracts and error cases clear so tools can build on the same project model.

### Interoperability

Use established formats where they fit, and document what changes when a project moves between tools.

### Reliability

Design validation, diagnostics, and recovery into the software.

## See what developers can explore.

Read about simulation, interfaces, and evidence for engineering workflows.

[Explore Developer Tools](https://broxme.com/developers)