Stage 1 · QA & testing
Catch it in QA, not at the customer site
Insaion records and checks every test run, in simulation, on the bench or on a HIL rig. Same agent as production. No SDK, no code changes.
Built for: Robotics software engineers and QA teams
Why regressions still ship
“The nav stack regressed and I can't tell which commit did it.”
Nobody kept the good run
No recording of the last good run to compare against.
“It passed in simulation. It passed on the bench.”
Two toolsets, no comparison
Test rigs get scripts, production gets monitoring. Nothing lines up.
“We only instrument robots once they ship.”
Monitoring shows up too late
The first production alarm has no baseline to compare with.
The production toolset, aimed at QA
Same agent, same dashboards, before the release.
Nothing to integrate
ROS 2 native. The agent finds your topics by itself. No SDK, no code changes.
Any test setup counts as a device
Simulator host, bench robot or HIL rig. Same install and enrollment key as production.
Alarms as pass/fail checks
A metric, a threshold and a time window. That's a test assertion. CPU under 80% for the whole run, say.
Candidate build vs. baseline
Group-comparison alarms fire when rigs on the candidate build drift from the current release by more than a set percentage.
Replay any run in the browser
Open it in the built-in Lichtblick viewer, or download the MCAP for Foxglove, PlotJuggler or your own scripts.
Test profiles as templates
Define topics, rates and buffers once. Apply them to every rig. Promote to production when the build ships.
The regression loop
- 1
Connect the test setup
Install the agent. Seconds later it's in your device list, topics already discovered.
- 2
Apply a test template
Pick the topics, host metrics and recording buffer that define a healthy run.
- 3
Write your expectations as alarms
Latency, CPU, memory, topic rate or any OpenTelemetry metric. An alarm fires, the check failed.
- 4
Keep the evidence
Upload the minutes around each failure, tag them with the build, replay them next to the metrics.
- 5
Ship the baseline with the build
The thresholds you tuned in QA go to production with the release. A baseline, not a guess.
You can't regression-test what you didn't record.
Frequently asked questions
Can I monitor a Gazebo or Isaac Sim simulation with Insaion?
Yes. The Insaion agent runs on any Linux machine with ROS 2, including one running a simulator. It discovers the topics the simulation publishes and streams them exactly like a physical robot's, with no changes to the simulation itself.
Does Insaion work for hardware-in-the-loop (HIL) testing?
Yes. Install the agent on the computer running the robot software, for example the robot computer on a HIL rig or a bench unit. The installation is the same for simulation, test hardware and production robots.
How much integration work does Insaion need?
Very little. Insaion is ROS 2 native, so the agent finds topics on the ROS graph by itself and needs no SDK or code changes. Custom signals can be added through standard OpenTelemetry if you want them, but nothing is required.
Do test devices count against my device limit?
A simulator, bench unit or HIL rig counts as one device, the same as a production robot. Devices are unlimited on every Insaion plan, including Free, so test setups don't cost extra.
How do I compare two test runs?
Plot both runs on one dashboard with synchronized time axes, replay their MCAP recordings side by side, or set a group-comparison alarm that fires when one group of devices drifts from another by more than a set percentage.
How is this different from Foxglove or PlotJuggler?
Foxglove and PlotJuggler are for looking at a recording once you have it. Insaion is what makes sure the recording exists: it monitors the run live, keeps a rolling MCAP buffer and alarms on failures. Recordings download as standard MCAP, so you can still open them in either tool.
Connect your test setup in minutes
Free plan, unlimited devices, no credit card.