Skip to main content

Robot PU Think

Lesson: Robot Thinking (Feedback Loops)​

"Robot thinking" is usually not human-like thinking. In robotics, it often means:

  • observe sensors
  • compute an adjustment
  • apply the adjustment
  • repeat fast

This is called a feedback loop (closed-loop control).

In Robot PU, walking and balancing is a great example. The extension's moveBalance(...) continuously reads the IMU and adjusts servo targets while walking.

1. Control loops: open-loop vs closed-loop​

A. Open-loop control (no feedback)​

Open-loop means:

  • you command an action
  • you do not measure the result
  • you assume the robot behaves as expected

Example idea:

  • "Set leg servos to these angles and hope the robot is stable."

Pros:

  • simple
  • predictable on perfect hardware

Cons:

  • sensitive to battery voltage, friction, payload, bumps
  • cannot recover when the real world differs from your assumption

B. Closed-loop control (feedback)​

Closed-loop means:

  • command an action
  • measure what happened (sensors)
  • compute an error
  • correct the command

Pros:

  • robust to disturbance
  • self-correcting

Cons:

  • more complex
  • needs good sensor data and good tuning

2. Robot PU example: moveBalance() (walking + balance)​

In robotpu.ts, walking calls:

  • walk(sp, di) → moveBalance(sp, di, ...)

High-level idea inside moveBalance(...):

  1. Observation: read IMU data and estimate body tilt
  2. Thinking: compute how much to tilt/offset the legs and body to stay balanced
  3. Action: apply those offsets as "control vectors" to the servo targets

Then it calls the lower-level gait engine (wk.move(...)) to advance the motion state.

3. Observation: balanceParam() (sensor → state estimate)​

balanceParam() reads the accelerometer:

  • input.acceleration(Dimension.X/Y/Z)

And computes tilt-related internal signals (examples you'll see in the code):

  • bodyRoll, bodyPitch
  • filtered versions bodyRoll2, bodyPitch2 (smoothed over time)

This is a small but important idea: filtering.

  • raw sensors are noisy
  • filtering reduces noise so control outputs don’t jitter

4. Thinking: turn IMU tilt into corrective offsets​

In moveBalance(...), the robot uses the estimated roll/pitch to compute offsets:

  • if the robot leans left → shift weight / servo offsets to recover
  • if the robot leans right → do the opposite

You'll see logic like:

  • clamp the correction (maxRollCtrl) so it cannot over-correct
  • slow down when tilt is large (safety + stability)

The output of "thinking" is a set of control signals written into pr.servoCtrl[...].

That control vector is then combined with the current gait pose targets.

5. Action: apply control and step the gait​

The action step is:

  • apply the computed servoCtrl offsets
  • call wk.move(...) to take one small step toward the current pose

That's why motion actions are designed to be called repeatedly: each call is one iteration of the feedback + motion update.

6. Types of controllers (concepts)​

Robot PU's balancing logic is a practical example of a heuristic controller (hand-designed rules + clamping + smoothing).

Other common controllers:

  • P controller: correction proportional to error
  • PD controller: proportional + damping (uses error change rate)
  • PID controller: proportional + integral + derivative

Typical tradeoffs:

  • P: simple, but may oscillate
  • PD: more stable, less overshoot
  • PID: can remove steady-state error, but can be tricky to tune

7. More advanced "thinking" (not required, but good to know)​

These are common in more advanced robots. They are mentioned here as future directions (they are not implemented in this tutorial code).

Kalman filter / complementary filter

  • Better sensor fusion (e.g., accel + gyro) and better state estimation

Feed-forward control

  • Predict required servo output from the planned motion

  • combine with feedback for best results

Probabilistic models (Bayesian / probability networks)

  • Represent uncertainty explicitly (useful when sensors are noisy)

Reinforcement learning

  • Q-learning / Q-tables: learn which action to take in each state

  • modern variants use neural networks (Deep Q Networks)

8. Practical MakeCode pattern: Observation → Thinking → Action​

Here is the general pattern you'll reuse in many projects:

basic.forever(function () {
    // Observation
    const cm = robotPu.sonarDistanceCm()

    // Thinking
    let speed = 2
    let turn = 0
    if (cm > 0 && cm < 15) {
        speed = -2
        turn = 0.8
    }

    // Action
    robotPu.walk(speed, turn)
})

The difference between a "dumb" robot and a "smart" robot is usually the quality of the Thinking step.