Home Think — Perception & Sensor Fusion Decide — On-Device Autonomy Act — Operator Control Strategic Consulting Symage Platform Defense, Aerospace & Space Industry 4.0 Medical Technology AgTech Proof Blog Solving For Tomorrow Podcast Company Careers News Speaker FAQ Talk to the Team →
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.

// 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 multi-rover autonomous coordination on the lunar surface
// 01
// Aerospace · Lunar Exploration
NASA · CADRE

Multi-rover autonomous coordination on the lunar surface, no human in the loop.

Hover for the numbers →
// NASA · CADRE

On-device autonomy at lunar distance.

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 GPR aboard each rover.

3Autonomous rovers
237°FMidday lunar temp
33 ftGPR subsurface reach
Read the case study →
NASA Mars Sample Retrieval Lander, test and validation infrastructure
// 02
// Aerospace · Mars Sample Return
NASA · Mars Sample Retrieval Lander

Test and validation infrastructure for the autonomous flight sequence from Mars.

Hover for the numbers →
// NASA · Mars Sample Return

Reduced risk for a multi-billion-dollar mission.

Test and validation infrastructure for the Mars Sample Retrieval Lander, including verification of the autonomous flight sequence for a rocket launch from Mars, where every decision has to execute correctly without operator intervention.

140MMiles from Earth
0Failure tolerance
#1Planetary Decadal priority
Read the case study →
On-device autonomy for unmanned defense platforms
// 03
// Defense Unmanned Systems
Teledyne FLIR · Bomb-Disposal UGV

One operator. A fleet of UGVs and small aircraft. The decision layer underneath.

Hover for the numbers →
// Teledyne FLIR

The autonomy that made universal control possible.

A tablet-based universal controller letting one operator direct multiple UGVs and unmanned aircraft, with the decision and arbitration logic underneath that lets each platform act on its own when the operator isn’t looking.

6 moMission-critical delivery
1Operator, full fleet
UGV+UAVUniversal controller
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 the Team →