轮足机器人

项目对应 · IN THE PROJECT

Day 10 工作：获取并分析 StackForce 开源模型集（gitee.com/StackForce/bipedal_wheeled_robot，含 框架.stl、大腿1~4.stl、前/后小臂.stl、电机固定.stl、舵机接口.stl、轮毂.stl、电池架.stl、上盖.stl 等十余件），在 Fusion 360 中基于原始 STL 修改并定制零件——把电池仓改为适配本项目 3S 11.1V 锂电池包、把轮毂轴孔从 5mm 改为 8mm 以适配不同 BLDC 电机轴、为 ESP32 开发板设计带 2.5mm 内径固定柱与 USB 缺口的安装座；在 Cura 中按受力件（层高 0.15mm、壁厚 2.0mm、填充 30-50% 陀螺仪图案、树状支撑）与装饰件（0.20mm、1.2mm 壁厚、15-20% 填充）分别切片，PLA 打印后打磨试装、锉刀微调公差，最终装配到 StackForce 框架上。

Day 10 work: obtaining and analyzing the StackForce open-source model set (gitee.com/StackForce/bipedal_wheeled_robot, files including 框架.stl, 大腿1-4.stl, 前/后小臂.stl, 电机固定.stl, 舵机接口.stl, 轮毂.stl, 电池架.stl, 上盖.stl), then in Fusion 360 modifying and customizing parts — e.g. redesigning the battery holder to fit the project's 3S 11.1V lithium pack, adjusting wheel-hub bore from 5mm to 8mm to fit a different BLDC motor shaft, and designing an ESP32 dev-board mount with 2.5mm-ID mounting posts and a USB-port notch — slicing each part in Cura with differentiated settings (load-bearing parts: 0.15mm layer height, 2.0mm walls, 30-50% gyroid infill, tree supports; decorative covers: 0.20mm, 1.2mm walls, 15-20% infill) and printing in PLA, then hand-fitting and filing to tolerance before final assembly onto the StackForce frame.

知识点 · KNOWLEDGE

Fusion 360 参数化建模流程（草图→尺寸约束/几何约束→拉伸/旋转→倒角/圆角→导出 STL）、零件间装配公差设计（针对 FDM 收缩与螺丝配合预留 0.2-0.3mm 间隙）、Cura 切片参数控制（层高、壁厚线数、填充密度/图案、树状 vs 普通支撑、裙边/底座附着）、FDM 层附着与打印朝向取舍、针对倒立摆机器人的重心控制设计约束（电池下沉居中、IMU 靠近旋转轴、重型件对称布置）、强度与重量平衡（受力件壁厚≥3mm、非受力件 1.5-2mm、不含电池总重<500g）。

Parametric 3D modeling workflow in Fusion 360 (sketch → dimension/constraint → extrude/revolve → fillet/chamfer → STL export), part-to-part assembly tolerance design (0.2-0.3mm clearance for FDM shrinkage and screw fit), Cura slicer parameter control (layer height, wall count, infill density/pattern, tree vs. normal supports, brim/skirt adhesion), FDM layer-adhesion and print-orientation reasoning, center-of-gravity control as a design constraint specific to an inverted-pendulum robot (battery low and centered, IMU near the rotation axis, symmetric heavy-component layout), strength-to-weight balancing (load-bearing walls ≥3mm vs. non-load-bearing 1.5-2mm, target <500g excluding battery).

文书角度 · ESSAY ANGLE

用 PLA 打印并反复修改 StackForce 框架与电池仓/IMU 安装座，使最重的 3S 电池下沉到轮轴正下方、IMU 贴近俯仰轴，体现申请者理解自平衡机器人首先是机械问题：倒立摆的稳定裕度由零件几何与打印朝向决定，电机座壁厚、0.2-0.3mm 装配公差、受力件填充率都不是装饰，而是直接关系到控制器能否成立的工程取舍——这是把 CAD 闭环到可制造实物、并让结构与控制算法互相成就的能力。

Printing the robot's structural parts in PLA and iteratively modifying the StackForce frame so the 3S battery sits low and the MPU6050 mounts near the pitch axis shows the applicant understands that a self-balancing robot is a mechanical system first: the inverted-pendulum controller's margin of stability is set by part geometry and print orientation, and decisions like wall thickness on the motor mount or 0.2-0.3mm assembly tolerances are deliberate engineering trade-offs tied to the control problem, not styling choices.

项目对应 · IN THE PROJECT

Day 1 学员在 VSCode + PlatformIO 下用 C++ 编写第一个固件（Blink、SOS、呼吸灯）并跑通编译烧录链路；完整项目的 software/src 则展示了后续各模块要填入的结构：platformio.ini 声明 espressif32 平台、esp32dev 板型、Arduino 框架、lib_deps 拉取 ElectronicCats/MPU6050 + askuric/SimpleFOC + madhephaestus/ESP32Encoder 三库、-O2 编译优化、921600 上传波特率、115200 监视波特率；config.template.h 把每个外设映射到物理 GPIO——两路电机的 PWM（GPIO25/27）与方向（26/14）、编码器（32/33/4/16）、I2C SDA/SCL（21/22，MPU6050 地址 0x68）、电池 ADC（35）；main.cpp 运行 setup()→loop()→10ms controlLoop() 三层骨架与四状态状态机（IDLE/BALANCING/REMOTE_CONTROL/FALLING），供后续 PID 代码填入。

Day 1 students set up the VSCode + PlatformIO toolchain and write their first C++ firmware (Blink, SOS, breathing-LED) in src/main.cpp for the ESP32, learning the platformio.ini that the full project later fills in (platform=espressif32, board=esp32dev, framework=arduino, lib_deps for MPU6050/SimpleFOC/ESP32Encoder, -O2 optimization, 921600-baud upload, 115200 monitor). The committed software/src then exposes the structure the rest of the project fills: config.template.h maps every peripheral to physical GPIO — PWM (25/27) and direction (26/14) for the two motors, encoders (32/33/4/16), I2C SDA/SCL (21/22) for the MPU6050 at 0x68, an ADC pin (35) for battery monitoring — and main.cpp runs a setup()->loop()->10 ms controlLoop() skeleton with a four-state machine (IDLE/BALANCING/REMOTE_CONTROL/FALLING) that the PID code drops into.

知识点 · KNOWLEDGE

PlatformIO 工具链（platformio.ini：platform=espressif32、board=esp32dev、framework=arduino、lib_deps 拉取 ElectronicCats/MPU6050 + askuric/SimpleFOC + madhephaestus/ESP32Encoder 三库、-O2 编译优化、921600 上传波特率 / 115200 监视波特率）、esp32dev 板型对应的 240MHz 双核 Xtensa MCU + 520KB SRAM + 片内 WiFi/BT、GPIO 复用与仅输入引脚约束（GPIO 34/35/36/39 不能做 PWM）、电机驱动的 PWM 频率/分辨率权衡（20kHz/8-bit）、I2C 总线与 MPU6050 @ 0x68 从机地址、ADC 分压电池监测、Arduino 框架的 setup()/loop() 结构、以及用 millis() 实现固定 10ms（100Hz）周期的定时控制循环。

PlatformIO toolchain (platformio.ini: platform=espressif32, board=esp32dev, framework=arduino, lib_deps pulling ElectronicCats/MPU6050 + askuric/SimpleFOC + madhephaestus/ESP32Encoder, -O2 build flags, 921600-baud upload / 115200 monitor), the dual-core Xtensa MCU @ 240 MHz with 520 KB SRAM and integrated WiFi/BT targeted by the esp32dev board, GPIO multiplexing and input-only pins (GPIO 34/35/36/39 cannot do PWM), PWM frequency/resolution trade-offs (20 kHz / 8-bit) for motor drive, I2C bus with MPU6050 @ 0x68, ADC battery monitoring via voltage divider, Arduino-framework setup()/loop() structure, and a timed control loop driven by millis() at a fixed 10 ms (100 Hz) period.

文书角度 · ESSAY ANGLE

在 PlatformIO（VSCode + platformio.ini 声明板型/框架/库依赖/编译优化）而非"一键编译"的 Arduino IDE 上用 C++ 写出机器人主固件 main.cpp，把每一个外设映射到 config.h 里具体的物理 GPIO 引脚，并搭建 setup()→loop()→10ms controlLoop() 三层结构与四状态状态机（IDLE/BALANCING/REMOTE_CONTROL/FALLING）骨架供后续 PID 代码填入，体现申请者已经在用大学课程级别的嵌入式开发流程——引脚分配、编译选项、实时循环周期都是有据可查的工程决策，而非被图形化 IDE 隐藏的默认值，这正是"提前使用大学级硬件/工具链"的可信证据。

Building the robot's main firmware in C++ on the PlatformIO toolchain (VSCode + platformio.ini pinning board/framework/lib_deps/-O2) rather than a click-to-compile IDE, mapping every peripheral to a physical GPIO in a config.h header, and writing a setup()->loop()->10 ms controlLoop() skeleton with a four-state state machine (IDLE/BALANCING/REMOTE_CONTROL/FALLING) that the later PID code drops into, shows the applicant already works at the university-course level of embedded development — making explicit, defensible engineering decisions about pin assignment, compile flags, and real-time loop timing that a beginner-friendly IDE keeps hidden.

项目对应 · IN THE PROJECT

Day 2 学员经 StackForce Dual FOC 驱动板驱动两只带编码器的 2808 BLDC 电机：先用手转轴验证正交编码器 4 状态转换表与 4 倍频解码（11 线 → 44 计数/圈），再接 A/B/C 三相动力线，在 software/src/motor_control.cpp 中配置 ESP32 LEDC PWM（20kHz/8-bit、左电机通道 0、右电机通道 1）。已发布的 MotorControl 类通过 setSingleMotor() 闭合回路：施加 MOTOR_DEAD_ZONE=30 的死区补偿（低于此 PWM 电机不启动，故小指令被抬到死区边界）、并在 setSpeed() 中把右电机方向取反以抵消镜像安装。FOC 矢量闭环本身——BLDCMotor(7 极对) + BLDCDriver3PWM、motor.initFOC()/loopFOC() 让定子磁场与转子保持 90°——作为 Day 2 的进阶选做 SimpleFOC 练习教授（并在 MotorControl::initFOC() 中以预留桩形式留给学生扩展）；该课解释了为何电机是一个由转子角度反馈支配的系统，而非黑箱。

On Day 2 students drive two 2808 BLDC motors with encoders via the StackForce Dual FOC driver board: first reading the quadrature encoder by hand to verify the 4-state transition table and 4x decoding (11 lines → 44 counts/rev), then wiring the A/B/C phase leads and configuring ESP32 LEDC PWM at 20 kHz/8-bit (left motor channel 0, right motor channel 1) in software/src/motor_control.cpp. The released MotorControl class closes the loop with setSingleMotor(), which applies a MOTOR_DEAD_ZONE=30 dead-zone compensation (motors stall below this PWM, so small commands are boosted to the dead-zone edge) and inverts the right motor's direction in setSpeed() to offset its mirrored mounting. The FOC vector loop itself — BLDCMotor(7 pole pairs) + BLDCDriver3PWM, motor.initFOC()/loopFOC() keeping the stator field at 90° to the rotor — is taught as the day-02 advanced/optional SimpleFOC exercise (and reserved as a stub in MotorControl::initFOC() for students to extend); the lesson explains why a motor is a rotor-angle-feedback system rather than a black box.

知识点 · KNOWLEDGE

BLDC 三相定子/转子结构与六步换向、FOC 磁场定向控制信号链（转子角度 → Clarke 变换 → Park 变换 → PI 电流控制 → 逆 Park → 逆 Clarke → SVPWM 三相输出）、定子磁场与转子磁场保持 90° 夹角以获最大力矩的原理、增量式正交编码器 A/B 相 90° 相位差解码与 4 倍频（11 线 → 44 计数/圈）、ESP32 LEDC PWM 通道/占空比/分辨率配置（左电机通道 0、右电机通道 1）、PWM 频率高于可听频段（20kHz）的取舍、电机死区非线性与补偿（MOTOR_DEAD_ZONE=30）、镜像安装的方向取反。

BLDC three-phase stator/rotor structure and six-step commutation, FOC field-oriented control signal chain (rotor angle → Clarke transform → Park transform → PI current control → inverse Park → inverse Clarke → SVPWM three-phase output), the 90° stator-rotor field angle for maximum torque, incremental quadrature encoder A/B-phase 90° phase-difference decoding and 4x quadrature multiplication (11-line → 44 counts/rev), ESP32 LEDC PWM channel/duty/resolution configuration (left motor ch0 / right motor ch1), PWM frequency above the audible band (20 kHz), motor dead-zone nonlinearity and compensation (MOTOR_DEAD_ZONE=30), mirrored-mounting direction inversion.

文书角度 · ESSAY ANGLE

把 2808 BLDC 驱动到"可控出力"而非"通电就转"——在 motor_control.cpp 里把 PWM 频率设到 20kHz 越过人耳听阈、在 setSingleMotor() 中施加 30 的死区补偿修正低占空比下电机不启动的非线性、并把右电机方向取反以抵消镜像安装——体现申请者把电机理解为一个机电系统，而非"给电压就转"的黑箱。Day 2 课程进一步把这一理解推进到 FOC 磁场定向控制：让定子磁场与转子保持 90° 夹角以获最大力矩（Clarke→Park→PI→逆 Park→SVPWM 信号链，由 SimpleFOC 的 initFOC()/loopFOC() 封装）——作为进阶选做练习，它解释了电机为何如此表现。其中的取舍（PWM 频率 vs. 开关损耗、死区 vs. 线性度、电压限制保安全）都是有意为之的工程决策，是电机控制工程的根基。

Driving the 2808 BLDC so it produces controllable torque rather than just spinning wild — setting 20 kHz PWM above the audible band, applying a 30-count dead-zone compensation in setSingleMotor() so the motor actually starts at low command instead of stalling, and inverting the right motor's direction to offset its mirrored mounting — shows the applicant understands a motor as a closed electromechanical system, not a black box that turns when you give it voltage. The day-02 lesson carries this further into FOC field-oriented control: keeping the stator field at 90° to the rotor (the maximum-torque angle) via the Clarke→Park→PI→inverse-Park→SVPWM chain that SimpleFOC's initFOC()/loopFOC() wraps — studied as the advanced/optional exercise that explains why the motor behaves the way it does. The trade-offs (PWM frequency vs. switching loss, dead-zone vs. linearity, voltage limit for safety) are deliberate engineering decisions, the foundation of motor control engineering.

项目对应 · IN THE PROJECT

Day 3 在 software/src/imu.cpp 与 imu.h 中编写 IMU 模块：通过 I2C（SDA=GPIO21/SCL=GPIO22，400kHz）经 WHO_AM_I 寄存器（期望 0x68）校验 MPU6050 身份后用 PWR_MGMT_1 唤醒，从 0x3B 寄存器一次性突发读取 14 字节原始数据（6 加速度+2 温度+6 陀螺仪），减去静态平均校准零偏，用 atan2(ax, az) 从加速度计算倾斜角，再用互补滤波（config.h 中 COMPLEMENTARY_ALPHA=0.97，DLPF 带宽在 CONFIG 寄存器配置）融合陀螺仪积分，输出 getAngle()/getGyroY()/getGyroZ() 供 main.cpp 控制环中的直立环 P/D 项与转向环使用。

On Day 3, in software/src/imu.cpp + imu.h, the IMU module drives the MPU6050 6-axis sensor: it verifies the chip via the WHO_AM_I register (expecting 0x68) over I2C (SDA=GPIO21/SCL=GPIO22, 400kHz), wake via PWR_MGMT_1, burst-reads 14 bytes from register 0x3B (6 accel + 2 temp + 6 gyro), subtracts the gyroscope zero-bias from static-average calibration, computes the accelerometer tilt with atan2(ax, az), and fuses the two via the complementary filter (α=0.97 set as COMPLEMENTARY_ALPHA in config.h, with DLPF bandwidth configured in the CONFIG register). The resulting getAngle()/getGyroY()/getGyroZ() feed the upright loop's proportional/D terms and the steering loop in main.cpp's control loop.

知识点 · KNOWLEDGE

I2C 总线协议（START/ACK/STOP、7 位从机地址 0x68/0x69、重复起始条件下的 14 字节连续突发读）、MPU6050 寄存器映射（WHO_AM_I 身份校验、PWR_MGMT_1 唤醒、GYRO_CONFIG/ACCEL_CONFIG 量程、CONFIG 数字低通滤波器 DLPF、SMPLRT_DIV 采样率分频）、大端序高低字节拼成 int16_t、陀螺仪灵敏度换算（131/2^range LSB/(°/s)）；基于 atan2(ax, az) 的加速度计倾角解算（优于 arcsin，在 ±90° 附近不失敏）、陀螺仪积分漂移、互补滤波作为高通(陀螺仪)+低通(加速度计)的频域互补融合及系数 α 的物理含义；陀螺仪零偏的静态平均校准，以及与卡尔曼滤波（预测-修正、协方差驱动的卡尔曼增益）的对比。

I2C bus protocol (START/ACK/STOP, 7-bit slave addressing 0x68/0x69, repeated-start burst read of 14 bytes), MPU6050 register map (WHO_AM_I identity check, PWR_MGMT_1 wake, GYRO_CONFIG/ACCEL_CONFIG range, CONFIG DLPF, SMPLRT_DIV sample rate), big-endian high/low byte combination into int16_t, gyroscope sensitivity scaling (131/2^range LSB per °/s); accelerometer tilt via atan2(ax, az) (superior to arcsin near ±90°), gyroscope integration drift, complementary filter as high-pass(gyro)+low-pass(accel) fusion with coefficient α; gyroscope zero-bias calibration by static averaging, and the contrast with Kalman filtering (predict-correct, covariance-driven Kalman gain).

文书角度 · ESSAY ANGLE

把噪声大但长期指向重力的加速度计、与短期精确但积分漂移的陀螺仪，用互补滤波一行公式 α×(角度+角速度×dt)+(1−α)×加速度计角度融合成一个可信的倾斜角，是两轮机器人能"知道哪边是下"并据此站立的前提。在电机转动会污染加速度计读数的真实约束下，申请者从频域取舍（陀螺仪漂移 vs. 加速度计噪声）出发选定 α=0.97 与 DLPF 带宽，并说明为何 atan2 优于 arcsin（在 ±90° 附近不失敏）、为何固定比例互补滤波胜过任一单传感器。这体现的是"在正确的时间尺度上信任正确的传感器"这一工程判断力，是机器人状态估计的根基。

Fusing a noisy accelerometer (long-term-accurate but vibration-corrupted) with a drifting gyroscope (short-term-accurate but integration-error-accumulating) into a single trustworthy tilt estimate via the complementary filter formula α×(angle + gyro·dt) + (1−α)×accel_angle is what lets a two-wheeled robot know which way is "down" fast enough to stand. Facing the real constraint that motor vibration contaminates the accelerometer reading, the applicant reasoned from the frequency-domain trade-off (gyro drift vs. accel noise) to pick α=0.97 and the DLPF bandwidth, and explained why atan2 beats arcsin near ±90° and why a fixed-ratio complementary filter beats either sensor alone for this robot. This shows the engineering judgement of trusting the right sensor at the right time-scale, the foundation of robotics state estimation.

项目对应 · IN THE PROJECT

Day 5-6 在 balance_controller 模块（software/src/balance.cpp、balance.h）中实现通用 PIDController 类与 BalanceController 三环控制器：速度环（PI）以（目标速度−平均轮速）为误差，输出"目标倾角"作为直立环的设定值；直立环（PD）以（目标角度−实测倾角）为误差，并把陀螺仪 Y 轴角速度直接当 D 项，输出基础 PWM；转向环（PID）输出左右差速，最终 leftPWM = basePWM − yawPWM、rightPWM = basePWM + yawPWM，全部钳位到 MOTOR_MAX_PWM。控制周期上，平衡环跑 200Hz、速度环跑 50Hz（约四倍慢，由 config.h 中 CONTROL_LOOP_PERIOD_MS 与 VELOCITY_LOOP_DIVIDER 设定）。三组增益（BALANCE_KP/KI/KD、VELOCITY_*、YAW_*）写在 config.h 里，靠 Ziegler-Nichols 与试凑在两轮 2808 BLDC 实车上反复调参直到机器人稳稳站立。

Day 5-6 work in the balance_controller module (software/src/balance.cpp / balance.h): implementing the generic PIDController class and the three-loop BalanceController. The velocity PI loop takes (targetVelocity − avgSpeed) and outputs a target lean angle; the upright PD loop takes (targetAngle − tilt) with gyroY fed in directly as the derivative term and outputs base PWM; the yaw PID loop outputs a left-right differential. Final leftPWM = basePWM − yawPWM, rightPWM = basePWM + yawPWM, all clamped to MOTOR_MAX_PWM. The balance loop is scheduled at 200 Hz and the velocity loop at 50 Hz (about 4x slower, set via CONTROL_LOOP_PERIOD_MS and VELOCITY_LOOP_DIVIDER in config.h). Gains (BALANCE_KP/KI/KD, VELOCITY_*, YAW_*) live in config.h and are tuned by hand (Ziegler-Nichols + trial-and-error) on the real robot until it stands on two 2808 BLDC wheels.

知识点 · KNOWLEDGE

串级控制架构（外环速度环输出角度补偿量作为内环直立环的目标角度，前倾则加速、后仰则减速）、各环作用与增益类型选择（直立环 PD、速度环 PI、转向环 PID）、Ziegler-Nichols 法与试凑法整定及"内环平衡环 200Hz、外环速度环 50Hz（约四倍快）"的整定原则、积分饱和与积分限幅（integralLimit = 0.5 × 输出上限）、微分测量替代（直接用陀螺仪角速度作 D 项，避免对噪声角度求导放大噪声）、输出/PWM 限幅、控制周期时序与设定值/扰动抑制的权衡。

Cascade control architecture (outer velocity loop's angle-offset output feeding the inner upright loop's setpoint, so leaning forward accelerates and leaning back brakes), per-loop role and gain type (upright PD, velocity PI, yaw PID), Ziegler-Nichols and trial-and-error tuning with the inner balance loop running at 200 Hz and the outer velocity loop at 50 Hz (about 4x faster, per the day-06 design), integral windup and clamping (integralLimit = 0.5 × outputMax), derivative-on-measurement (feeding gyroY directly as the D term to avoid amplifying angle noise), output and PWM saturation, control-cycle timing and the setpoint/disturbance trade-off.

文书角度 · ESSAY ANGLE

让一台两轮机器人稳稳站住，靠的不是单环 PID，而是把直立 PD 环嵌进速度 PI 环里——想要前进时，外环先让车身主动前倾，内环再去追这个倾斜角；并按"内环须快于外环"的级联原则逐环整定 Kp/Ki/Kd，让内环平衡环跑在 200Hz、外环速度环跑在 50Hz（约四倍快，因为速度变化没那么紧急），在积分饱和限幅（限到输出上限的一半）与用陀螺仪角速度替代噪声角度微分之间做取舍，体现申请者理解多环控制不是死记公式，而是按时间尺度分层、按信号质量选结构的工程判断，能把一个不稳定的欠驱动系统从模型一路推到能站住的真实增益。

Making a two-wheeled robot stand by nesting an upright PD loop inside a velocity PI loop so that wanting to move forward first makes the body lean (and only then do the wheels chase), and tuning each loop's gains by hand so the inner balance loop runs at 200 Hz while the outer velocity loop runs at 50 Hz — about four times faster, deliberately slower because speed changes are less urgent — with integral windup clamped to half the output ceiling and the D-term taken straight from the gyro rather than differentiated from a noisy angle, shows the applicant grasps that multi-loop control is about deliberate timescale separation and signal-conditioning trade-offs, not memorized formulas, and that they can reason an unstable, under-actuated plant from a model to working gains.

项目对应 · IN THE PROJECT

Day 4 物理建模工作：把整车抽象成"小车+倒立摆"二自由度模型，用实测参数（轮子+电机等效质量 M ≈ 0.3 kg、车体质量 m ≈ 1.5 kg、质心到轮轴距离 L ≈ 0.08 m、轮半径 R ≈ 0.03 m）对车体列力矩平衡方程、对轮+车体列水平力平衡方程，做小角度线性化（sin θ ≈ θ），联立求解得到控制方程 θ̈ = a·θ - b·F（其中 a = (M+m)g/(ML)、b = 1/(ML)）；再写成状态空间 ẋ = Ax + Bu 形式，计算可控性矩阵 [B AB] 得出 det(C) = -b² ≠ 0（系统可控）；最后用 Python odeint 跑"无控制自由倒下"与"PD 控制"两组仿真验证模型，得到的参数范围随后喂给 software/src/balance.cpp 里的串级 PID。

Day 4 modeling work: abstracting the self-balancing robot into a 2-DOF inverted-pendulum-on-a-cart with measured parameters (wheel+motor equivalent mass M ≈ 0.3 kg, body mass m ≈ 1.5 kg, center-of-mass-to-axle distance L ≈ 0.08 m, wheel radius R ≈ 0.03 m), writing the body's torque-balance and the wheel+body horizontal-force-balance equations, linearizing at small angle (sin θ ≈ θ), and deriving the control equation θ̈ = a·θ - b·F (a = (M+m)g/(ML), b = 1/(ML)); then writing it in state-space form ẋ = Ax + Bu, computing the controllability matrix [B AB] and concluding det(C) = -b² ≠ 0 (controllable); finally verifying with a Python odeint simulation (free-fall vs. PD-controlled) before the parameters carry over to the cascaded PID in software/src/balance.cpp.

知识点 · KNOWLEDGE

倒立摆运动方程推导（车体绕轮轴的力矩平衡 + 轮与车体整体的水平力平衡）、小角度线性化（sin θ ≈ θ、cos θ ≈ 1、忽略 θ̇²）、状态空间表示 ẋ = Ax + Bu（系统矩阵 A = [[0,1],[a,0]]）、特征值与平衡点稳定性分析（λ = ±√a，正特征值即不稳定系统的数学标志）、传递函数 G(s) = -b/(s²-a) 及其右半平面极点、可控性矩阵 [B AB] 与 det(C) = -b² ≠ 0 ⇒ 存在状态反馈 u = -Kx 使系统稳定的结论、用 scipy.integrate.odeint 对微分方程组做数值积分以验证模型。

Inverted-pendulum equations of motion (body torque balance and wheel+body horizontal force balance), small-angle linearization (sin θ ≈ θ, cos θ ≈ 1), state-space representation ẋ = Ax + Bu with the system matrix A = [[0,1],[a,0]], eigenvalue/equilibrium stability analysis (λ = ±√a, the positive eigenvalue as the signature of an unstable system), transfer function G(s) = -b/(s²-a) and its right-half-plane pole, the controllability matrix [B AB] and the controllability conclusion det(C) = -b² ≠ 0 ⇒ a stabilizing state-feedback law u = -Kx exists, and scipy.integrate.odeint numerical integration of the ODE system for model verification.

文书角度 · ESSAY ANGLE

不是把机器人当作"不知怎么就站住了"的黑箱，而是对车体列力矩平衡方程、对轮+车体列水平力平衡方程，做小角度线性化后得到传递函数 G(s) = -b/(s²-a)，用右半平面极点解释"不加控制必然倒下"这件事，再用 Python odeint 在 PD 控制下仿真观察不稳定极点被拉回稳定——体现申请者能在物理直觉、形式化动力学、数值仿真三端之间自由往返，更重要的是：能把一台正在倒下的机器人读懂成一个正特征值，而不是一个玄学故障。这正是"理解系统为什么这样行为"和"只知道它这样行为"之间的分水岭，是建模推导一路走到预测的能力。

Rather than treating the robot as a black box that "balances somehow," the student derives the inverted-pendulum equations of motion from a torque balance on the body and a horizontal-force balance on wheel-plus-body, linearizes with the small-angle approximation, and arrives at the transfer function G(s) = -b/(s²-a) whose right-half-plane pole is the mathematical reason an uncontrolled robot must fall — then runs a Python odeint simulation under PD control to watch the unstable pole get pulled back to stability. This shows the applicant can move between physical intuition, formal dynamics, and numerical verification in one breath, and — most importantly — can read a falling robot as the expression of a single positive eigenvalue rather than a mysterious failure. It is the kind of modeling-through-to-prediction that distinguishes a student who understands why a system behaves as it does from one who only knows that it does.

项目对应 · IN THE PROJECT

Day 7 学员为 ESP32 自行设计一套二进制遥控通信协议（以 protocol.h / PacketParser / SimpleRemote.h 代码块形式写在 curriculum/day-07.md 中，由学员作为 Day-7 作业实现，并非 software/src/ 中预置的文件）：帧格式为「0xAA 帧头 + 命令字节 + 长度字节 + 变长数据 + 1 字节 XOR 校验和」，定义 CMD_SPEED/CMD_TURN/CMD_MODE/CMD_PID_PARAMS/CMD_HEARTBEAT/CMD_TELEMETRY 等命令，并实现逐字节 PacketParser 状态机解析器。速度/转向等 float 值用 floatToBytes 编码为 2 字节（×100 定点、低/高字节拆分）；SimpleRemote 文本命令路径（F/B/L/R/S/X，V:value/T:value）作为更简单的备选。实际 software/src/main.cpp 接好了安全侧：定义 STATE_REMOTE_CONTROL 及全局 remoteVelocity/remoteYawRate/lastRemoteTime，config.template.h 中 REMOTE_TIMEOUT_MS=500 让控制循环在 500ms 内收不到指令时清零 remoteVelocity/remoteYawRate 并切换到 STATE_BALANCING。传输走 ESP32 内置蓝牙 Classic SPP（main.cpp setup 注释段的 SerialBT.begin(BT_DEVICE_NAME="BipedalBot")，及 day-07 的 BluetoothSerial 示例）与手机蓝牙串口终端通信；config.template.h 另留 WiFi AP 模式（WIFI_SSID="BipedalBot_AP"、WIFI_CONTROL_PORT=8888）作为备选链路，并为 iOS 提供 BLE 简化版。

In Day 7 the student designs a custom binary remote-control protocol on the ESP32 (taught as inline protocol.h / PacketParser / SimpleRemote.h code blocks in curriculum/day-07.md, which the student implements as the Day-7 assignment — they are not pre-shipped files in software/src/): a frame format of 0xAA header + command byte + length byte + variable payload + 1-byte XOR checksum, with commands CMD_SPEED/CMD_TURN/CMD_MODE/CMD_PID_PARAMS/CMD_HEARTBEAT/CMD_TELEMETRY, implemented via a byte-at-a-time PacketParser state machine. The float speed/turn values are encoded into 2 bytes (floatToBytes: ×100 fixed-point, low/high byte split); a SimpleRemote text-command path (F/B/L/R/S/X, V:value/T:value) is provided as a simpler fallback. The shipped software/src/main.cpp wires the safety half: it defines STATE_REMOTE_CONTROL with global remoteVelocity/remoteYawRate/lastRemoteTime, and config.template.h's REMOTE_TIMEOUT_MS=500 makes the control loop auto-zero remoteVelocity/remoteYawRate and transition to STATE_BALANCING if no command arrives within 500 ms. Transport uses ESP32 Bluetooth Classic SPP (SerialBT.begin(BT_DEVICE_NAME="BipedalBot"), shown in the main.cpp setup comment block and the day-07 BluetoothSerial example) with a phone Bluetooth serial terminal; config.template.h also exposes WiFi AP mode (WIFI_SSID="BipedalBot_AP", WIFI_CONTROL_PORT=8888) as an alternate transport, and a BLE simplified path is provided for iOS.

知识点 · KNOWLEDGE

蓝牙 Classic（SPP 串口协议）与 BLE 的取舍（数据率/延迟/iOS 支持——iOS 不支持 SPP 故提供 BLE 简化版），ESP32 BluetoothSerial 库基于 SPP；二进制帧协议设计（固定帧头 0xAA + 命令字节 + 长度字节 + 变长数据 + 1 字节 XOR 校验和）、命令集（CMD_SPEED/CMD_TURN/CMD_MODE/CMD_PID_PARAMS/CMD_HEARTBEAT/CMD_TELEMETRY 及 CMD_STATUS）、帧定界与校验失败重同步（解析器 reset）；逐字节状态机解析器（WAIT_HEADER→WAIT_CMD→WAIT_LENGTH→WAIT_DATA→WAIT_CHECKSUM）与 SimpleRemote 文本行解析路径的对比；float 定点编码（×100 缩放为 int16，拆低/高字节）以在窄带宽链路传输浮点；XOR 校验的错误检测能力与 CRC 的差异；心跳包与遥测下行；接收端安全超时（config.template.h 中 REMOTE_TIMEOUT_MS=500）——链路丢失即清零 remoteVelocity/remoteYawRate、退回自平衡模式。

Bluetooth Classic SPP vs BLE trade-offs (data rate, latency, iOS support — iOS lacks SPP so a BLE fallback is provided), ESP32 BluetoothSerial library built on the SPP profile; binary frame protocol design (fixed 0xAA header + command byte + length byte + variable-length payload + 1-byte XOR checksum), command set (CMD_SPEED/CMD_TURN/CMD_MODE/CMD_PID_PARAMS/CMD_HEARTBEAT/CMD_TELEMETRY, plus CMD_STATUS), frame delimiting and re-sync on checksum failure (parser reset); byte-at-a-time state-machine parser (WAIT_HEADER→WAIT_CMD→WAIT_LENGTH→WAIT_DATA→WAIT_CHECKSUM) versus the text-line parser used in the SimpleRemote fallback path; float-to-fixed-point encoding (scale ×100, int16 little-endian split into low/high bytes) to compress floats for narrow-band links; XOR checksum error detection and its limitations versus CRC; heartbeat/telemetry for liveness; receiver-side safety timeout (REMOTE_TIMEOUT_MS=500 in config.template.h) that zeroes remoteVelocity/remoteYawRate and falls back to self-balance on link loss.

文书角度 · ESSAY ANGLE

申请者没有把"手机遥控"当成发个字符就跑的练习，而是从零设计一条链路层通信契约：自定义 0xAA 帧头+长度+XOR 校验的二进制帧、逐字节推进的状态机解析器、float×100 的定点编码、以及 500ms 收不到指令即超时退回自平衡的安全兜底，并通过 ESP32 蓝牙 Classic SPP 与手机蓝牙串口终端完成收发验证。这体现的不是"会用蓝牙库"，而是能在不可靠无线信道上设计一条"带校验、带超时、带状态机"的可信指令通道，并把协议规范、编解码、故障安全做成可验证的闭环——文书可据此呈现申请者对"系统间通信"的工程严谨度与安全思维，而非泛泛的"做了一个遥控"。

Instead of treating the phone link as a magic "send a character" exercise, the applicant designs a real binary link-layer protocol — fixed 0xAA header, length field, XOR checksum, a byte-at-a-time state-machine parser, float-scaled-to-int16 encoding, and a 500 ms command-timeout that auto-drops the robot out of remote mode back into self-balance — then validates it over ESP32 Bluetooth Classic SPP with a phone serial terminal. This reframes the work as the applicant engineering a link-layer contract from scratch: defining a frame grammar with a header that resists mis-synchronization, hardening it with a timeout safety fallback, and shipping a verifiable encode/decode round-trip — exactly the protocol-design and safety-thinking rigor a CS/EE program looks for, grounded in this project's concrete bytes rather than a generic tutorial.

项目对应 · IN THE PROJECT

Day 9 选做挑战（作业中标注为选做/加分项——核心 MVP 是平衡站立+蓝牙遥控）：定义 MotionMode 枚举（MODE_WHEEL / MODE_LEG / MODE_HYBRID / MODE_TRANSITION）与 switchToWheelMode / switchToLegMode / switchToHybridMode 三个切换函数，用 canSwitchMode() 守卫切换安全（轮→足要求 currentSpeed<0.1，足→轮要求 isLegsStanding() 腿部回到中位 ±5°），并用 7 帧的 gaitSequence[] 步态表（站立→左抬→左伸→站立→右抬→右伸→站立）驱动 4 个腿部舵机，再由 handleRemoteCommand() 解析蓝牙 'W'/'L'/'H' 指令从手机端选择模式。Day 9 课内示例用 ESP32Servo 在 GPIO25/26/27/14 驱动 SG90 舵机；整车装配硬件则经 PCA9685 I2C 舵机驱动板接 MG996R 舵机。

Day 9 stretch challenge (marked optional/bonus in the assignments — the core MVP is balance-standing + Bluetooth remote): defining the MotionMode enum (MODE_WHEEL / MODE_LEG / MODE_HYBRID / MODE_TRANSITION) and the switchToWheelMode/switchToLegMode/switchToHybridMode handlers, with the canSwitchMode() guard (wheel→leg requires currentSpeed < 0.1; leg→wheel requires isLegsStanding() within ±5°), plus the 7-pose gaitSequence[] table (stand → left-lift → left-extend → stand → right-lift → right-extend → stand) for four leg servos, and the Bluetooth 'W'/'L'/'H' command dispatch in handleRemoteCommand() that selects the mode from a phone. The Day-9 lesson drives the servos via ESP32Servo on GPIO25/26/27/14 (SG90 in the example); the assembled robot's hardware instead routes the four leg servos (MG996R) through a PCA9685 I2C driver board.

知识点 · KNOWLEDGE

有限状态机模式仲裁（MotionMode 枚举、currentMode/targetMode、MODE_TRANSITION 过渡态）、带安全前置条件的受保护切换（canSwitchMode() 校验速度<0.1、腿部 isLegsStanding()±5°）、按序编排的切换动作序列（减速停车→禁用平衡PID→腿部站立，或收腿→启用平衡PID）、离散步态关键帧姿态表（GaitPose 数组 {hipL,kneeL,hipR,kneeR} 依次经历支撑/抬腿/前伸/落地相位）、50Hz 舵机 PWM 信号（500–2500µs 脉宽→0–180°，Day 9 课内用 ESP32Servo 在 GPIO25/26/27/14 演示；整车硬件经 I2C 地址 0x40 的 PCA9685 驱动板接 MG996R 舵机走同一组四通道）、混合模式下 BLDC 平衡环与舵机步态环的执行器仲裁。

Finite-state machine mode arbitration (MotionMode enum, currentMode/targetMode, MODE_TRANSITION transitional state), guarded transitions with safety preconditions (canSwitchMode() checking currentSpeed < 0.1 and isLegsStanding() ±5°), sequential transition choreography (decelerate wheels → disable balance PID → stand up legs, or retract legs → enable balance PID), discrete gait-cycle pose tables (GaitPose arrays of {hipL, kneeL, hipR, kneeR} stepping through support/lift/extend/strike phases), servo PWM signaling at 50Hz with 500–2500µs pulse → 0–180° (taught via ESP32Servo on GPIO25/26/27/14 in the Day-9 lesson; the production hardware routes the same four channels through a PCA9685 I2C driver at 0x40 with MG996R servos), actuator arbitration between the BLDC balance loop and the servo gait loop in hybrid mode.

文书角度 · ESSAY ANGLE

在 Day 9 选做的轮足模式切换挑战里，申请者设计了一个显式的 MotionMode 状态机，并用 canSwitchMode() 守卫把"轮→足切换必须先减速到接近零、足→轮切换必须先收回腿部到 ±5° 站立位"写成硬约束，使任何一次远程按键都不能让机器人带着速度强行进入步态而倾倒。因为这是在核心 MVP（平衡站立+蓝牙遥控）之外自选的加分项，它更说明申请者愿意超出大纲要求，把一个混合系统拆成多个安全可独立验证的模式，而非一锅端的大循环——这种"先证明安全再允许切换"的工程纪律，正是自动驾驶从巡航模式切到低速泊车模式时同样要解决的守护式状态切换问题。

Taking on the optional Day-9 stretch challenge of wheel/leg mode-switching, the applicant designed an explicit MotionMode state machine whose canSwitchMode() guard refuses a wheel-to-leg transition until wheel speed drops below 0.1 and a leg-to-wheel transition until isLegsStanding() confirms the four leg servos are within ±5° of center — so a premature Bluetooth tap can't topple the robot mid-gait. Because this was a self-elected bonus (not the core balance+remote MVP), it shows the applicant reaching past the syllabus to partition a hybrid system into safe, individually-verifiable modes rather than monolithic control, treating "don't let it fall over" as a guarded-state-transition problem — the same discipline that lets a self-driving stack move between highway-cruise and low-speed-maneuver regimes without an unsafe handoff.