Goddard Robot Architecture: ESP32 PID Control and Telemetry Design

A Goddard robot is an embedded microcontroller-based robotic platform—typically built around an ESP32 or Raspberry Pi Pico—designed to teach closed-loop PID control, sensor fusion, and low-bandwidth telemetry by simulating the guidance and navigation challenges of early spaceflight. Unlike simple open-loop RC cars or basic ultrasonic obstacle-avoiders that people commonly confuse it with, a true Goddard-style build fundamentally changes your circuit design: it forces you to abandon simple analogWrite() motor commands in favor of interrupt-driven quadrature encoders, dedicated I2C buses for IMU state estimation, and strict real-time task scheduling to maintain state awareness.

Where You Meet This in Practice

You will encounter Goddard robot architectures in university mechatronics labs, FIRST Robotics off-season training, and advanced hobbyist builds attempting to replicate Mars rover autonomy. The primary goal isn't just to move from point A to point B; it is to maintain a precise heading and velocity profile while streaming telemetry back to a base station over a constrained link (like a 915 MHz LoRa module or a low-baudrate XBee).

The Core Architecture: Sensors, Encoders, and Telemetry

A functional Goddard robot requires a specific hardware stack to achieve reliable state estimation. You cannot rely on dead-reckoning with cheap DC motors; you need closed-loop feedback at both the wheel and the chassis level.

Worked Numeric Example: I2C Latency vs. PID Loop Frequency

The most common mistake when programming a Goddard robot is setting the PID loop frequency too high without accounting for sensor read latency. Let's calculate the actual timing budget for a 100 Hz PID loop (a 10.0 ms cycle time) reading a BNO085 IMU and two quadrature encoders.

• I2C Read (BNO085): Requesting the rotation vector report at 400 kHz I2C takes approximately 3.2 ms.
• Encoder ISR Overhead: Processing interrupts for two wheels at a combined 2 kHz tick rate consumes about 1.1 ms of CPU time per cycle.
• Math & PID Calculation: Floating-point math for the dual PID loops (heading and velocity) takes 0.4 ms.
• PWM Update: Writing to the LEDC (PWM) peripheral takes 0.1 ms.

Total Execution Time: 4.8 ms.
Remaining Margin: 5.2 ms.
This leaves enough headroom for the FreeRTOS scheduler to handle background WiFi tasks. However, if you attempt to push the loop to 200 Hz (5.0 ms budget), your 4.8 ms execution time leaves only 0.2 ms for the OS. The ESP32's Task Watchdog Timer (WDT) will inevitably trigger a system reset because the idle task is starved. For a stable ESP32 FreeRTOS implementation, always leave at least a 30% timing margin in your control loops.

Real-World Scenario Walkthrough: The High-Gain Oscillator Failure

To understand how these systems fail on the bench, let's look at a real debugging session involving a Goddard rover prototype.

The Setup: An ESP32-based rover with a BNO085 IMU on the default I2C pins (GPIO 21/22) and a software-serial XBee module for telemetry on GPIO 16/17. The goal was to tune the heading PID controller to maintain a strict 90-degree trajectory over a carpeted surface.

The Numbers: The P-gain was set to 4.5, I-gain to 0.1, and D-gain to 0.8. The target heading was 90.0 degrees.

The Outcome: Upon starting the motors, the robot violently oscillated +/- 15 degrees, the motors whined at maximum PWM saturation, and the ESP32 threw a Watchdog Timer (WDT) panic reset after exactly 4.2 seconds.

What Went Wrong: The D-term (derivative) in a PID controller acts like a tightrope walker overcompensating for a gust of wind; it reacts to the rate of change of the error. Because the I2C bus was sharing the same internal memory bus cycle as the software UART bit-banging the telemetry, the IMU experienced I2C clock stretching. This delayed the IMU timestamp by 14 ms. When the delayed data finally arrived, the PID algorithm calculated a massive, artificial rate-of-change (derivative spike). This spiked the D-term output, saturating the TB6612FNG motor driver. Simultaneously, the software UART interrupts locked the CPU, starving the WiFi idle task and triggering the WDT.

The Fix: We moved the telemetry to a hardware UART (GPIO 1/3), dropped the D-gain from 0.8 to 0.05, and implemented a low-pass filter on the IMU derivative input. The oscillation ceased, and the rover tracked the 90-degree heading within a 1.5-degree tolerance.

Debugging Framework: When the Rover Drifts or Resets

When your Goddard robot fails to track its state or crashes unexpectedly, follow this numbered diagnostic sequence before rewriting your code:

1. Verify Encoder Phase: If the robot accelerates backward when given a forward command, your quadrature encoder A/B phases are reversed. Swap the A and B wires on the motor encoder connector, not in code.
2. Check I2C Pull-ups: The BNO085 breakout boards often have weak 10kΩ internal pull-ups. For reliable 400 kHz operation on an ESP32, add external 4.7kΩ pull-up resistors to the 3.3V rail on both SDA and SCL lines.
3. Isolate the WDT Reset: If the serial monitor prints Task watchdog got triggered, your PID loop is blocking. Ensure you are using vTaskDelay() or xSemaphoreTake() with a timeout in your loop, rather than blocking while() loops waiting for sensor data.
4. Audit Power Supply Ripple: If the IMU drops off the I2C bus randomly, measure the 3.3V rail with an oscilloscope. TB6612FNG drivers switching high currents can induce ground bounce. Use a dedicated 3.3V LDO (like the AMS1117-3.3) for the logic and sensors, separate from the motor power supply.

FAQ: Goddard Robot Embedded Design