CORNET: Testing Robots and Networks Together
One config, two simulators, and a better way to study cyber-physical systems.
Cyber-physical systems live in two worlds at once. A drone, a power-grid controller, or a balancing robot is a physical thing obeying physics, but its decisions travel over a network that drops packets, adds delay, and congests at the worst moment. Most research tools only see one of those worlds. CORNET, from RBCCPS at IISc, is built to see both.
The gap it fills
Ask a control engineer to test a controller and they will reach for a robot simulator. Ask a networking researcher to test a protocol and they will reach for a network simulator. A cyber-physical system needs both questions answered together: does the controller still work when the network behaves like a real network?
Wiring a robot simulator to a network simulator by hand is slow, fragile work, and every lab ends up doing it differently. That makes results hard to reproduce and harder to compare.
What CORNET does
CORNET runs a network simulator and a robot simulator from one task config. A single command launches the whole experiment:
python -m cornet tasks/pendulum_nr_control
python -m cornet view tasks/pendulum_nr_control
Under the hood it supports the tools researchers already use: NS-3 and Mininet on the network side, Gazebo, ROS 2 and PX4 on the robotics side. An orchestrator with plugins ties them together, and every task is described by a shared config schema.
Why that matters for CPS research
Co-simulation becomes the default, not a project. When a network-aware experiment is one config file, you can ask questions you would otherwise skip: how much latency can this controller tolerate, what happens to a drone swarm under Wi-Fi congestion, which protocol keeps a pendulum upright.
Experiments become reproducible. A config file is something you can share, version and rerun. Another lab can run your exact task instead of rebuilding your setup from a paper's methods section.
Results become comparable. CORNET includes a benchmark command and a leaderboard whose entries record provenance, so a claim like "my controller is more robust" can be checked against others on the same task.
The research loop gets shorter. CORNET has a research-session workflow that runs from question through to report. The project documents one such session, a pendulum check from 28 September 2026, as a worked example.
Where it could go
The same approach fits almost any system where control meets communication: vehicle platoons, industrial automation, smart grids, remote surgery, and multi-robot teams. Each of these fields has argued for years about how networks affect control. A shared, reproducible testbed is how that argument turns into evidence.
If you work on anything that senses, communicates and acts, CORNET is worth an afternoon. Start with the pendulum task and see how far the network can push it before it falls.