星语的博客

2022年8月，Stable Diffusion 把人类几千年的视觉史塞进了一个 Latent Space。但问题来了——你总得知道你要什么，才能告诉 AI 你要什么。所以就有了这篇。 ※ 本文所有配图均由豆包 AI 生成。 壹 · 肌理与质感 人类第一次在平面上留下纹理，是在肖维岩洞里蘸着赭石往墙上拍手印。三万七千年后，我们还在干同样的事——只不过换成了 GPU。 1. 半调网点 1873 年，德国人 Georg Meisenbach 用一块刻满细密网格的玻璃屏，把照片拆成了大小不一的圆点。报纸印刷的油墨只有纯黑纯白，网点是唯一的妥协方式。但 Lichtenstein 在 1961 年把这个妥协放大成了主角——他把漫画格涂在巨大的画布上，网点不再是印刷缺陷，变成了波普的视觉基因。 A striking pop art portrait rendered in bold halftone dot patterns, thick black comic-style outlines, high-contrast cyan, magenta, and yellow color s...

四足机器人 Locomotion 奖励函数设计——从步行到奔跑，每一分奖励的来龙去脉 如果你已经搭好了 Isaac Lab 环境、写好了 PPO 训练脚本、加载好了四足机器人的 URDF，然后满怀期待地敲下 python scripts/train.py，等着机器狗走出来——结果它要么原地抽搐，要么侧翻在地，要么转圈像个陀螺——恭喜你，欢迎来到奖励函数设计的世界。 强化学习社区有一句老话：“Reward is the hypothesis of the designer.” 在四足 locomotion 这个任务上，这句话格外准确。机器狗的策略网络可以有上百万参数，但决定它最终学会什么行为的，归根结底是你写在 compute_reward() 函数里的那几行代码。同样的网络结构、同样的超参数、同样的仿真环境，换一套权重系数，学出来的步态可能截然不同——有的沉稳如波士顿动力的 Spot，有的则像喝醉了的柯基。 然而，关于奖励函数的内容，大多数教程要么一笔带过（“我们使用了一组精心设计的奖励项，详见论文附录”），要么只给出最终公式而不解释为什么这么设。这篇博客的目标是把奖励函数的每个...

DQN 算法超详尽教程——从 Q-table 到深度强化学习 如果说 Q-learning 是强化学习的"Hello World"，那 DQN（Deep Q-Network）就是深度强化学习真正走出实验室、进入公众视野的里程碑。2013 年，DeepMind 的 Mnih 等人在 NIPS 发表 Playing Atari with Deep Reinforcement Learning，用一个卷积神经网络直接从原始像素输入学到了 Atari 2600 平台上 6 款游戏（后来扩展到 49 款）中超越人类专业玩家水平的控制策略。这篇工作的冲击力在于：它首次干净利落地证明了，深度神经网络可以在强化学习框架下进行稳定训练，而不需要任何手工特征工程。两年后，这篇论文的改进版登上了 Nature，标题只有三个词：Human-level control through deep reinforcement learning。从此，深度强化学习进入了爆发期。 DQN 之所以经典，不在于它用了多复杂的数学工具，而在于它用两个看似简单的工程技巧——经验回放（Experienc...

机器人战队运营组成长计划 一、写在前面 我们队伍的运营组不是打杂组的，也不是可有可无的附属品 。 对于一支长期参赛的机器人战队来说，技术组决定机器人能不能跑起来，运营组决定战队能不能稳定传承、持续招新、形成影响力、积累文化，并在校内外建立清晰、可信、可传播的形象。比赛成绩当然重要，所有人都看重比分和名次，但真正让一支队伍走得更远的，往往是组织能力、内容能力、活动能力与对外沟通能力的长期积累。 ROBOCON 与其他机器人竞赛一样，具有明显的赛季性、项目制、强协作、高投入特点。赛场上能被看见的，是机器人、队员和结果；赛场外真正维系队伍正常运转的，是纳新、培训、活动策划、宣传、对外交流、资料积累与文化传承。 运营组的成员，不应该只是单纯的能发推文，或者能剪视频，还应该具有下面的能力： 能了解战队运行规则、与队员建立良好沟通 能独立承接宣传与活动任务 能与技术组高效协同 能与其他学校、企业加强交流 二、运营组的定位 运营组是做什么的 在我们战队中，运营组主要承担以下职责： 宣传 负责战队在校内外平台的整体形象塑造与内容发布，以及文创队服等特色周边制作。 策划 负责招新宣讲...

前言 如果你在 STM32H723 上遇到过这些诡异现象： HAL_UART_Receive_DMA() 正常返回，但缓冲区就是不变 ADC + DMA 偶尔全 0，偶尔又像是“好了” 把数组改成全局变量、static、甚至改个大小，结果症状跟着变 关掉 D-Cache 以后突然一切正常，重新打开又开始抽风 那大概率不是你“DMA 配错了一点点”，而是你踩中了 STM32H7 这一代 MCU 最经典的坑之一。 STM32H723 和很多 F1/F4/F7 的直觉式用法不太一样。它的 Cortex-M7 内核带有 32 KB I-Cache 和 32 KB D-Cache，同时系统内部又分成 D1 / D2 / D3 三个域，既有 AXI SRAM，也有 D2 SRAM、D3 SRAM，还保留了 ITCM / DTCM 这样的 TCM 内存路径。（见 DS13313, AN4891） 所以，很多人口中的“DMA 与 RAM 冲突”，其实往往不是“两个模块抢内存”这么朴素，而是下面三类问题混在了一起： DMA 根本到不了那块 RAM DMA 能到，但 CPU 的 D-Cache...

Isaac Lab External 项目完整工作流 本教程面向已经配置好Isaaclab强化学习环境的新手玩家 项目仓库：https://github.com/Leggedsys/legged_train/tree/main 第一次新建一个空的IsaacLab外部项目，除了跑一跑倒立摆的示例，我也不知道下一步要做什么。仓库是新的，我的目标是训练一条机器狗，下一步要干啥？：先放URDF ？写 env ？先写 PPO 配置？还是去啃官方教程？本人想做一篇文档教程作为参考，把训练一台机器狗这个事，完整记录一下。 整个过程其实比较简单：先把项目变成一个能被IsaacLab 识别的Python扩展，再把机器人资产接进来，然后围绕这台机器人写配置、场景、环境和奖励，最后再接上PPO训练与回放脚本。难点从来不在于某一步特别神秘，我们第一次做isaaclab项目时，大概已经知道我要做的无非就这些事，但不知道从何开始，也不知道这些文件到底是干啥的。只要这条线理顺了，后面想加入平地gait、rough terrain、抗扰动或者sim-to-real 扩展，其实都会顺很多。 项目环境准备 我的项目...

四足机器人 MPC 的数学建模与 QP 推导 很多关于四足机器人 MPC 的文章，要么停留在“模型预测控制很适合动态 locomotion”的概念层面，要么直接从论文里搬出一组矩阵，读者知道符号长什么样，却不知道这些矩阵为什么会这样出现。真正做开发时，最难的部分并不是把现成公式抄进代码，而是要把几个问题真正想清楚：为什么整机建模时通常从单刚体模型开始，而不是直接从全身动力学开始；为什么优化变量通常选足端接触力，而不是关节力矩；连续时间动力学怎样走到离散时间模型；离散预测模型怎样进一步变成一个标准的二次规划问题；摩擦锥、摆动腿零力和法向力上下限这些约束又是怎样写进 QP 的。 这篇文章就只做一件事：把四足机器人 MPC 里最核心的数学链条，从建模一路推到 QP。它不是一篇 broad overview，也不是一篇以工程经验为主的调参手册，而是偏理论和可实现之间的那一层。写完这一篇之后，你至少应该能够回答下面几个关键问题。第一，MPC 在四足机器人中控制的对象到底是什么。第二，单刚体模型的状态变量和输入变量该怎样选。第三，为什么预测控制问题最终会落成一个 QP，而不是一堆看不出结构的...

C语言中的函数指针与虚函数表模拟 在上一篇《C语言模拟面向对象》中，讨论了一个常见但容易被误解的话题：为什么很多嵌入式项目会把 C 语言写得“像面向对象”一样。 这种写法并不是为了“显得高级”，而是因为当系统开始管理越来越多的设备、模块和控制逻辑时，单纯依靠一堆分散的函数和条件分支，代码会越来越难维护。 在C语言模拟面向对象的技巧里，函数指针和虚函数表风格的操作表，是最核心的一层机制。 这篇文章就专门讨论这个问题： 在机器人嵌入式系统中，如何用 C 语言的函数指针模拟“对象方法”，再进一步模拟“虚函数表”和“多态调用”？ 一、为什么普通 C 写法会越来越难维护 先看最朴素的写法。 假设我们有两类电机： DJI 电机 DM 电机 一开始也许只需要做“使能”： if (motor_type == DJI_MOTOR) { dji_motor_enable();} else if (motor_type == DM_MOTOR) { dm_motor_enable();} 后来需求变多了，还要设置目标值、解析反馈、执行控制更...

C语言模拟面向对象 很多人第一次看到这种代码风格时，都会有一个问题：“用 C 语言写出面向对象的样子，是不是显得更专业” 我的看法是：专业不在于“像不像 C++”，而在于这套写法能不能真正解决工程问题。 对于机器人嵌入式控制系统来说，系统里往往同时存在底盘、电机、升降机构、武器机构、CAN 通信、PID 控制、任务调度等多个层次。如果继续用“满地全局变量 + 一堆 switch-case + 到处散落的初始化函数”去组织代码，随着功能变多，系统很快就会变得难以维护。 这时候，C 语言里的几个经典手段——结构体封装、函数指针、组合关系、统一初始化接口、对象注册——就能模拟出一套足够实用的“面向对象”风格。 这篇文章就结合一套机器人电机控制代码，聊聊： 为什么嵌入式系统里要用 C 模拟面向对象 你的这套代码到底“对象化”在什么地方 这种写法在机器人控制系统里有什么实际价值 这种设计什么时候值得用，什么时候会过度设计 基于现有代码，还能做哪些工程上的改进 1. 为什么 C 语言也要“对象化”？ 在桌面开发里，大家很容易直接想到 C++、Rust 这类更现代的语言；但在嵌入式世界，...

很多人第一次看 rsl_rl，会以为它只是“又一个 PPO 仓库”。但如果把源码真正拆开，你会发现它的核心价值并不只是实现了 PPO，而是把 模型结构、观测组织、采样存储、训练更新、蒸馏部署 这些环节统一进了一套非常清晰的接口里。 对于足式机器人来说，这种设计尤其重要。原因很简单：机器人强化学习不是只写一个 policy(obs) 就结束了。真实工程里你常常会同时面对这些问题： actor 和 critic 看到的观测不一样； 训练时可以用 privileged information，部署时却不能用； 有些任务只需要 MLP，有些任务要加 CNN 或 RNN； 训练时要高效支持并行环境、PPO、多卡同步，部署时又要能导出 JIT / ONNX。 而这组源码恰好把这些问题都落到了具体实现里。 本文会围绕你给出的几个核心文件，从 理论公式 和 工程实现 两条线同时解读 rsl_rl： MLP / MLPModel 如何构成整套模型抽象； CNNModel 和 RNNModel 如何复用这套接口； PPO 的采样、GAE、裁剪目标、KL 自适应学习率如何映射到代码； Disti...