What we do
A mission spans the software on the machine, the network at the site and the person overseeing the work. We design across all three, from motion planning to the inspection record.
We work with ROS 2, PX4 and C++ to connect sensor observations, state estimates and planned motion. Safety monitors sit close to execution, where they can check limits even when a network link is unavailable.
Explicit operating bounds, stop conditions and replayable decisions. A plan and the authority to execute it remain separate.
ROS 2 / PX4 / C++
We work with NVIDIA Jetson, Isaac ROS and DeepStream to run vision models near the sensor. For inspection, we connect a candidate observation to the image, location and conditions behind it.
Reviewable observations and tests for missed detections, timing and resource limits. Model output can inform a human decision without authorising a machine action.
Jetson / Isaac ROS / DeepStream
We design for cloud-neutral, on-premises and air-gapped environments. Kubernetes is one deployment tool. Protobuf, OpenAPI, CloudEvents and GeoJSON define portable contracts for messages, services, events and spatial data.
Identify which decisions belong on the machine, what stays on the local network and which records can synchronise when a connection returns.
Kubernetes / open contracts
We use NVIDIA Isaac Lab to explore reinforcement and imitation learning. A robot policy learns from rewards or demonstrations. Domain randomisation varies the lighting, dynamics and sensor noise it encounters.
Reserve unfamiliar scenes for evaluation, then use hardware trials to measure how well a policy transfers from simulation to a physical machine.
Isaac Lab / RL / imitation
We build physically based scenes and sensor models with NVIDIA Isaac Sim, Omniverse and OpenUSD, and use Gazebo for robot simulation. Synthetic data exposes software to conditions that are difficult to collect on site.
A scenario library with initial conditions, sensor settings and deterministic replay. The same cases can drive software-in-the-loop and hardware-in-the-loop tests.
Isaac Sim / OpenUSD / Gazebo
Engineering method
We test software in repeatable digital-twin scenarios. The next stages assess how that behaviour carries over to hardware and field conditions. Pterops currently runs against simulated vehicles only. Customer deployments and live autonomous flights are future steps.
Observed with a simulator. The claim is limited to the scenario and configuration exercised.
Repeated on specified physical hardware under controlled bench conditions.
Observed during a supervised test in a named operating environment.
An identified authority has accepted a defined configuration for a stated scope.
A defined release, operating envelope and support commitment are available to customers.
Construct the site and sensors.
Explore conditions and behaviours.
Exercise software against a simulated vehicle.
Repeat scenarios with physical hardware.
Validate within a controlled field envelope.