From Command to Motion

"Drive forward" sounds like one instruction. A robot sees a chain of smaller decisions.

For a differential-drive robot, a forward command might become:

desired motion
  ↓
left wheel target + right wheel target
  ↓
motor commands
  ↓
wheel torque
  ↓
traction at floor
  ↓
robot acceleration and motion

That chain matters because the final motion can be wrong even when the first command is correct.

Behavior has layers

Separate three ideas:

• intent: what the robot should accomplish;
• command: what the controller asks a subsystem to do;
• physical result: what actually happens.

Example:

The gap between command and result is where testing begins.

Sequential code can hide time

A script like this looks readable:

drive_forward()
turn_left()
drive_forward()
stop()

But each function has a timing model. Does drive_forward() return immediately? Does it block until the motion is complete? What happens to sensor updates while it waits?

Robot software must make time explicit enough that safety and feedback continue to work.

Specification before code

Write behavior in testable language before syntax.

Weak:

The robot drives around the box.

Stronger:

From a marked start pose, the robot advances to the first turn zone, rotates approximately 90 degrees left, repeats the segment sequence, and enters a stopped state if the obstacle sensor reports less than the configured clearance.

Now there are states, conditions, and observable results.

Build a behavior specification

For one robot task, write:

• starting state;
• goal;
• required inputs;
• allowed outputs;
• normal completion condition;
• one stop condition;
• one measurable success criterion.

Only after that should you write pseudocode.

Software becomes easier to debug when the behavior exists somewhere other than inside the code.

Commands need units and limits

A command such as setSpeed(50) is ambiguous. Fifty what?

It could mean:

• 50 percent output;
• 50 rotations per minute;
• 50 radians per second;
• 50 encoder counts per control interval;
• a vendor-specific raw value.

Software interfaces become safer when the unit and legal range are obvious.

setWheelVelocity(1.2 m/s)
setArmAngle(0.65 rad)
setMotorDutyCycle(0.35)

The naming does not guarantee correctness, but it removes one entire category of misunderstanding.

Clamp before physics does it for you

Suppose a planner requests 2.8 m/s, but the mechanism is designed for a maximum of 1.5 m/s.

A boundary layer can enforce:

requested 2.8
      ↓
limit check
      ↓
commanded 1.5

That is not merely defensive programming. It is where a physical constraint becomes a software rule.

A command path should therefore answer four questions:

1. What does the value mean?
2. What range is allowed?
3. Who owns the limit?
4. What evidence tells us the command was actually executed?

The last question matters because command and motion are not the same event.