Smart Robot Decision Logic Circuit Simulator

Interactive simulator requires JavaScript

Enable JavaScript to load the live circuit. The truth table below describes the circuit's behaviour.

Open in Full Simulator Browse All Templates

What You'll Learn

Translate a sensor-based decision policy into a Boolean expression.
Combine AND, OR, NOT to encode "all of these" and "none of these" conditions.
Read the truth table of the resulting decision logic.
Apply the same pattern to safety interlocks and machine policy.
Recognise when to use Karnaugh maps to simplify large policy expressions.

How It Works

A simple decision logic circuit takes several sensor inputs and produces an action signal based on a Boolean policy. This template models a small robot that decides whether to move forward based on rules like: - Move forward = path-clear AND battery-OK AND NOT obstacle-detected

With 3+ binary sensors, the policy expression is a Sum-of-Products: each AND term covers one valid scenario; the OR aggregates them. Inverting any sensor introduces a NOT.

Designing the policy means writing the truth table for desired behaviour, then synthesising a Boolean expression. For more complex rules, Karnaugh maps simplify the expression to fewer gates. Here, the expression is intentionally readable: AND-of-conditions with negations where appropriate.

This is the same pattern used in safety interlocks, machine state checks, and automotive driver-assist logic — sensor inputs drive a Boolean policy that decides whether an action is permitted.

Truth Table

Action = PathClear AND BatteryOK AND NOT Obstacle. Showing 4 representative cases.

Inputs				Output
PathClear	BatteryOK	Obstacle	Override	Move
1	1	0	0	1	All clear — robot moves
0	1	0	0	0	Path blocked — stop
1	1	1	0	0	Obstacle ahead — stop
1	0	0	0	0	Battery low — stop
0	0	1	1	1	Override forces move (use with caution)

Boolean Expression

\text{Move} = (\text{Path} \cdot \text{Bat} \cdot \overline{\text{Obs}}) + \text{Override}

Sum-of-Products: normal motion conditions OR an override switch.

\text{Stop} = \overline{\text{Move}}

Stop signal — inverse of Move. Used to drive brake circuits.

Try It Step-by-Step

Set the inputs in the embed above, then read what should happen and confirm.

1

PathClear = 1 BatteryOK = 1 Obstacle = 0 Override = 0

Expected: Move = 1

What you'll see: Normal driving conditions — all permissions met, no obstacle. Robot moves forward.
2

PathClear = 1 BatteryOK = 1 Obstacle = 1 Override = 0

Expected: Move = 0

What you'll see: Obstacle detected — even with path clear and battery OK, the NOT(Obstacle) condition fails.
3

PathClear = 0 BatteryOK = 0 Obstacle = 1 Override = 1

Expected: Move = 1

What you'll see: Override switch forces motion regardless of sensors. Useful for manual recovery from sensor failures — but bypasses safety!
4

PathClear = 1 BatteryOK = 0 Obstacle = 0 Override = 0

Expected: Move = 0

What you'll see: Battery low — robot won't move. Safety policy prevents stranding the robot in low-power state.

Components Used

Real-World Applications

Industrial safety interlocks. "Allow press to fire if all guards closed AND e-stop released AND two-hand-button pressed." Pure AND-of-conditions.

Automotive cruise-control engagement. Engages only if speed > threshold AND brake not pressed AND clutch not pressed AND no fault detected.

Robotics motion authorization. Move-forward signal gated by clear-path, battery-OK, no-emergency-stop, mission-active. AND-of-conditions with negations.

HVAC control. Heat compressor on if thermostat-call AND not-defrost AND not-overheat-fault AND power-OK.

Embedded firmware policy logic. Many embedded systems implement decision trees as Boolean expressions evaluated each control cycle.

Frequently Asked Questions

How would I add another sensor?

Add it as another input to the AND term. "Move only if PathClear AND BatteryOK AND NOT Obstacle AND TempOK" requires one more AND input. Boolean policies extend by adding terms.

Should the override bypass everything?

In practice, partial override is safer: ignore one sensor (say, obstacle) but keep critical ones (battery low, e-stop pressed). This is policy design, not just gate logic — but the gate structure stays the same: AND of permitted conditions, OR with the override-mask.

How is this different from a state machine?

This is **combinational** — outputs depend only on current inputs. A state machine remembers history (e.g., "if in Lockout state, ignore all sensors for 30 seconds"). Combinational logic is simpler and faster but less expressive.

Could I use Karnaugh maps to simplify?

Yes — if you write out the truth table for all input combinations, K-maps can find the minimal SOP expression. For 4 inputs the K-map is 4×4 = 16 cells. For more variables, automated synthesis tools (Quine-McCluskey, Espresso) handle it.

What's the role of the NOT gate?

It inverts the obstacle signal so the AND term reads "path clear AND battery OK AND obstacle absent." Without the NOT, the obstacle would have to be asserted (high) to permit motion — wrong polarity. NOT lets you mix active-high and active-low conditions cleanly.