Getting Started

1. Install the package

git clone https://github.com/rbccps-iisc/CORNET
cd CORNET
pip install -e .[dev]

Install simulator prerequisites only for the plugins you plan to use. See INSTALL.md.

2. Understand the task layout

Each experiment lives in tasks/<name>/:

tasks/
  pendulum_nr_control/
    config.yaml
    eval/
      eval_tool.py
  uav_wifi_control/
    config.yaml
    eval/
      eval_tool.py

config.yaml declares: - network: ns3, mininet, or ns3+mininet - robot: Gazebo/ROS 2 deployment - experiment: duration, output directory, primary metric, optional sweep

3. Run a task

python -m cornet tasks/pendulum_nr_control

If the task folder includes launch.py or world.sdf, CORNET auto-discovers them. Otherwise the Gazebo plugin auto-generates a launch file.

4. Run a sweep

experiment:
  sweep:
    axes:
      network.numerology: [1, 2, 3]
      network.bandwidth: [20, 40]
    repeats: 2

Then run the task normally:

python -m cornet tasks/aoi_5phase_eval

CORNET expands the cartesian product and writes results per variant under experiment.output_dir/<variant_id>/.

5. View the leaderboard

python -m cornet view tasks/pendulum_nr_control

This prints a rich table sorted by the configured primary metric.

6. Guides

Go deeper with the topic guides:

Guide	Description
Writing a Task	Create a new task: directory layout, config.yaml, EvalTool, leaderboard
Custom Plugin	Implement a network or robot plugin using the Plugin ABC
Custom EvalTool	Extract metrics from experiment output with EvalTool
Parameter Sweep	Sweep parameters across runs; understand variant IDs and output layout
Middleware	AoI tracker, physics clock, packet dispatcher, and TUN manager
Research session	Question, brief, critic, one experiment, and the report

---

7. Develop with OpenSpec

CORNET uses an OpenSpec workflow for tracking framework changes. The phases are:

/opsx:propose  →  [/opsx:discuss]  →  /opsx:apply  →  /opsx:archive

Discuss Phase

Run /opsx:discuss after proposing a change and before implementing it. It performs an adversarial review of the proposal — raising challenges, generating alternative designs, and recording final decisions — then writes discussion.md to the change directory.

/opsx:discuss <change-name>             # full prose output
/opsx:discuss <change-name> --compressed  # caveman-compressed output

discussion.md contains three sections: - Challenge Report — up to 5 cited adversarial challenges with failure modes and mitigations - Counter-Designs — 1–3 alternative architectural approaches with a recommendation - Decisions Made — binding implementation constraints that /opsx:apply honors

The discuss phase is optional. /opsx:apply proceeds normally without it. Use it when your proposal has real design uncertainty or when you want structured critique before writing code.