Home Think — Perception & Sensor Fusion Decide — On-Device Autonomy Act — Operator Control Strategic Consulting Pilot to Production Forward-Deployed Engineering Symage Platform Defense, Aerospace & Space Industry 4.0 Medical Technology AgTech Proof Blog Solving For Tomorrow Podcast Company Careers News Speaker FAQ Talk to an Engineer →
Capability: Decide

Decide, On-device autonomy and decision systems.

Path planning, behavior systems, and on-device autonomy software for robotics, drones, and connected devices that have to choose what to do without a round-trip to the cloud.

// Overview

The decision layer between perception and action.

On-device autonomous systems software is what turns a system that sees the world into one that can make decisions within it. It’s the path planning, behavior trees, decision logic, and system orchestration that allow machines to operate in real time directly on the device, even when the connection to the cloud is unreliable. We build embedded autonomous systems and software for robotics companies, autonomous systems companies, defense unmanned systems primes, automated facility operators, and connected medical device manufacturers that need decision-making to happen on the platform itself.

On-device autonomous systems at the system level keep the platform operating when the network drops or the operator isn’t watching. Path planning and behavior systems at the algorithmic level determine what to do next based on environment, objectives, and constraints.

This is software for systems where the wrong decision isn’t an inconvenience. It’s a collision, a missed objective, a mission aborted, or a platform stranded somewhere an operator can’t reach. The software is engineered for that reality from the architecture down.

// 01 Decide

On-device autonomy.

On-device autonomous systems software means the platform can make decisions locally, without depending on the cloud. The network may be unavailable, intermittent, jammed, or too latent for closed-loop operation, so the decision stack has to execute on the device itself, integrated with perception pipelines above it and control systems below it.

This work includes:

The hardest part of autonomous systems software is rarely the single-platform demo. It’s the system at scale where edge cases compound, degraded sensors produce conflicting inputs, and distributed platforms have to continue operating under conditions the original design did not explicitly model. That’s where most autonomy projects either succeed or fail, and it’s the part of the system we architect for first.

On-device doesn’t mean cloud-isolated. Most deployed fleets pair on-device autonomy with a coordination layer above it, cloud or ground station, that handles mission assignment, fleet orchestration, and monitoring. We build that layer too. The architectural decision that matters is the boundary between them: what has to decide locally in milliseconds, and what can coordinate centrally.

// 02 Decide

Path planning and behavior systems.

Path planning software and behavior tree development translate “what should this robot do” into “what is this robot doing right now.” We build navigation stacks (cost maps, planners, recovery behaviors), behavior trees that scale beyond the 50-node demo, and autonomous decision systems that handle the messy edge cases real deployments produce, degraded sensors, unexpected obstacles, conflicting goals, recovery from failure states.

What this work covers:

Path planning software work spans 2D ground robots in warehouse environments, 3D aerial planners for drones operating in cluttered airspace, and hybrid platforms with heterogeneous mobility (walking, rolling, climbing). The planner you start with rarely survives contact with the deployment environment unchanged; the engineering judgment is in knowing what to keep, what to replace, and what to write from scratch.

// Recent Work

Autonomy, deployed.

NASA CADRE rovers on the lunar surface
// 01
// Aerospace · Lunar Exploration
NASA · CADRE

Three rovers lowered to the lunar surface, and the interface that reads their radar.

Hover for the numbers →
// NASA · CADRE

Getting three rovers down, and reading what lies beneath.

A fleet of small rovers operating as a coordinated team, making decisions on-device, in real time, without a round-trip to Earth. Geisel built the deployment software and the ground-control interface for the multistatic GPR carried by the three rovers.

3Autonomous rovers
237°FMidday lunar temp
33 ftGPR subsurface reach
Read the case study →
Warehouse robotics digital twin simulation
// 02
// Robotics Simulation
World’s largest operator of mobile robotics

Thousands of hours of testing in a single day. No physical hardware.

Hover for the numbers →
// Warehouse Robotics · Digital Twin

A physics-based simulation environment that removes the hardware ceiling.

Digital twins accurate enough that code validated in simulation behaves predictably on production hardware, and failed tests become data, not damage.

1,000sHours per day
0Hardware required
ParallelMulti-team testing
Read the case study →
SOS Live first responder drone platform, primary software development from day one
// 03
// Public Safety · Architecture & Build
SafeOps Systems · SOS Live

Primary software development team from day one, from requirements to first customer demo.

Hover for the numbers →
// SOS Live · SafeOps Systems

The architecture call before the build.

SOS engaged Geisel as primary software dev team from day one, owning the program from initial requirements and architecture through development, integration, and the first customer demonstration. The architectural decisions made early are why the platform shipped on the timeline it did.

Day 1Primary dev team
BVLOSFAA-compliant flight
Multi-UAVSimultaneous feeds
Read the case study →
// Adjacent · Perception

Need the perception that feeds the autonomy?

Autonomy software is only as good as the perception input it acts on. Most Decide engagements either build on existing perception (in which case integration is part of the scope) or include a Think component to produce the world model the autonomy needs. The two capabilities are routinely engaged together, same team, same engineering discipline, same standards.

Explore Think: Perception, sensor fusion, edge inference →
// Common Questions

Questions about the work.

Does Geisel build on ROS 2 Nav2?
Yes. Nav2 is the most common navigation stack we work with for ROS 2-based platforms. Most engagements include some combination of Nav2 integration, custom planner development, and recovery-behavior tuning specific to the customer’s deployment environment.
Does Geisel use behavior trees?
Yes. We use BehaviorTree.CPP and equivalent frameworks for the decision logic in most autonomy stacks. We also build state machines and hybrid behavior architectures when the use case calls for them. The choice depends on the system; what matters is that the resulting decision logic is maintainable at scale, not just demo-ready.
What’s the difference between on-device autonomy and cloud autonomy?
On-device autonomy runs on the platform itself, perception, decision-making, and execution all happen locally. Cloud autonomy depends on a network round-trip to a remote system that holds the decision logic. On-device autonomy is required when the network is unreliable (defense, remote operations), when latency is critical (real-time decisions in milliseconds), or when the system has to keep working when the cloud is unavailable. Most of the platforms we build for need on-device autonomy by structural requirement, not by preference.
Does Geisel do multi-agent coordination?
Yes. Multi-rover coordination on NASA’s CADRE program is a representative engagement. Multi-drone, multi-AMR, and multi-platform coordination work appear in our customer base across defense, automated facilities, and space exploration. The engineering challenge in multi-agent autonomy is rarely the single-agent decision, it’s the coordination logic that prevents agents from interfering with each other at scale.
Can Geisel build autonomy for medical devices under IEC 62304?
Yes. Connected medical device autonomy work runs through the same IEC 62304 software lifecycle discipline as any other medical device software we build, design controls, hazard analysis, software requirements traceability, and the verification and validation evidence appropriate to the device’s risk classification.
Does Geisel work on autonomy outside ROS 2?
Yes. ROS 2 is the most common framework, but we work in non-ROS architectures when the platform calls for it, proprietary middleware, embedded RTOS environments, and custom autonomy frameworks built for specific deployment constraints.

Building perception, autonomy, or operator control?
Let’s talk about what it takes to ship it.

Talk to an Engineer →