30 种 AIGC 视觉风格速查
田野指南 30种AIGC视觉语言 全图豆包AI生成 · 2026 01 · 半调网点 1873 年，德国人 Georg Meisenbach 用一块刻满细密网格的玻璃屏把照片拆成了大小不一的圆点——本 来只是报纸印刷的一种妥协：油墨只能印纯色，要么黑要么白。Lichtenstein 在 1961 年把这个妥协放 大成了波普的视觉基因。那些本该藏在印刷品底层的网点突然变成了主角。此后你看到网点就想到印刷 品——这就是风格的形成。halftone dot pattern, Ben-Day dots, comic book style, bold primary colors, screen printing texture, Lichtenstein inspired, misregistration effect --ar 2:3 02 · 颗粒噪点 数码相机工程师花了几十年消灭噪点，胶片摄影师却花了一辈子迷恋它。Tri-X 400 的黑白颗粒里有 整个二十世纪的街头——Robert Frank 的美国人、森山大道的东京。清晰是一种谎言。噪点是反完美的 宣言；...
奖励函数才是四足 RL 的灵魂
四足机器人 Locomotion 奖励函数设计——从步行到奔跑，每一分奖励的来龙去脉 如果你已经搭好了 Isaac Lab 环境、写好了 PPO 训练脚本、加载好了四足机器人的 URDF，然后满怀期待地敲下 python scripts/train.py，等着机器狗走出来——结果它要么原地抽搐，要么侧翻在地，要么转圈像个陀螺——恭喜你，欢迎来到奖励函数设计的世界。 强化学习社区有一句老话：“Reward is the hypothesis of the designer.” 在四足 locomotion 这个任务上，这句话格外准确。机器狗的策略网络可以有上百万参数，但决定它最终学会什么行为的，归根结底是你写在 compute_reward() 函数里的那几行代码。同样的网络结构、同样的超参数、同样的仿真环境，换一套权重系数，学出来的步态可能截然不同——有的沉稳如波士顿动力的 Spot，有的则像喝醉了的柯基。 然而，关于奖励函数的内容，大多数教程要么一笔带过（“我们使用了一组精心设计的奖励项，详见论文附录”），要么只给出最终公式而不解释为什么这么设。这篇博客的目标是把奖励函数的每个...
从 Q-learning 到 DQN，一步步推演
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 与其他机器人竞赛一样，具有明显的赛季性、项目制、强协作、高投入特点。赛场上能被看见的，是机器人、队员和结果；赛场外真正维系队伍正常运转的，是纳新、培训、活动策划、宣传、对外交流、资料积累与文化传承。 运营组的成员，不应该只是单纯的能发推文，或者能剪视频，还应该具有下面的能力： 能了解战队运行规则、与队员建立良好沟通 能独立承接宣传与活动任务 能与技术组高效协同 能与其他学校、企业加强交流 二、运营组的定位 运营组是做什么的 在我们战队中，运营组主要承担以下职责： 宣传 负责战队在校内外平台的整体形象塑造与内容发布，以及文创队服等特色周边制作。 策划 负责招新宣讲...
H723 上 DMA 读不到数据？查 D-Cache 和内存域
H723 上 DMA 读不到数据？查 D-Cache 和内存域 在 STM32H723 上写 DMA,几乎每个人都会撞上同一堵墙:HAL_UART_Receive_DMA() 明明正常返回,缓冲区里的数据却纹丝不动;ADC 采回来的值一会儿全 0,一会儿又"好了";更诡异的是,把数组改成全局变量、加个 static、甚至换个大小,症状居然跟着变。 这几种现象凑在一起,基本能排除"外设时序配错了"这条路,矛头指向同一个方向:H7 的内存架构。 Cortex-M7 带 32KB I-Cache 和 32KB D-Cache,内部又按 D1/D2/D3 分成三个域,SRAM 散落在不同总线上,还留了 DTCM/ITCM 这种 CPU 私有的快速内存。所以" DMA 不工作"背后,通常就三类问题: Buffer 放进了 DMA 根本够不着的内存区(最常见是 DTCM) Buffer 位置没错,但 D-Cache 让 CPU 和 DMA 看到的是两份数据 多个主设备真在抢总线带宽 下面按排查顺序展开,而不是按理论顺序。 先记住...
四足机器人控制理论（公式推导汇总）
四足机器人控制统一技术文档（公式推导版） 目标：给出一套从单腿运动学 → 全身动力学 → MPC / WBC / RL 的统一数学体系。 采用对象：主流 12 自由度串联四足（浮动基座 + 4 条 3 自由度腿）。 说明：若你的本体是 8 自由度并联腿或五连杆腿，只需要替换“单腿几何闭环、雅可比、单腿惯性”部分；从浮动基座动力学、状态估计、MPC、WBC 到 RL 的整体框架不变。 0. 总体建模对象与控制链 四足机器人广义坐标选为 $$ q = \begin{bmatrix} p_B \ \Theta_B \ q_j \end{bmatrix} \in \mathbb{R}^{6+n}, \qquad n=12, $$ 其中 $p_B\in\mathbb{R}^3$：机身质心位置； $\Theta_B$：机身姿态参数（欧拉角或四元数最小参数）； $q_j\in\mathbb{R}^{12}$：12 个关节角； 浮动基速度更适合写成 $$ \nu = \begin{bmatrix} v_B \ \omega_B \ \dot q_j \end{bmatrix}\in\ma...
IsaacLab 入门踩坑记录
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 的数学建模与 QP 推导 很多关于四足机器人 MPC 的文章，要么停留在“模型预测控制很适合动态 locomotion”的概念层面，要么直接从论文里搬出一组矩阵，读者知道符号长什么样，却不知道这些矩阵为什么会这样出现。真正做开发时，最难的部分并不是把现成公式抄进代码，而是要把几个问题真正想清楚：为什么整机建模时通常从单刚体模型开始，而不是直接从全身动力学开始；为什么优化变量通常选足端接触力，而不是关节力矩；连续时间动力学怎样走到离散时间模型；离散预测模型怎样进一步变成一个标准的二次规划问题；摩擦锥、摆动腿零力和法向力上下限这些约束又是怎样写进 QP 的。 这篇文章就只做一件事：把四足机器人 MPC 里最核心的数学链条，从建模一路推到 QP。它不是一篇 broad overview，也不是一篇以工程经验为主的调参手册，而是偏理论和可实现之间的那一层。写完这一篇之后，你至少应该能够回答下面几个关键问题。第一，MPC 在四足机器人中控制的对象到底是什么。第二，单刚体模型的状态变量和输入变量该怎样选。第三，为什么预测控制问题最终会落成一个 QP，而不是一堆看不出结构的...
用函数指针在 C 里模拟虚函数表
C语言中的函数指针与虚函数表模拟 在C语言模拟面向对象的技巧里，函数指针和虚函数表风格的操作表，是最核心的一层机制。当系统开始管理越来越多的设备、模块和控制逻辑时，单纯依靠一堆分散的函数和条件分支，代码会越来越难维护。 在嵌入式系统中，如何用 C 语言的函数指针模拟“对象方法”，再进一步模拟“虚函数表”和“多态调用”？ 一、为什么普通 C 写法会越来越难维护 先看最朴素的写法。假设我们有两类电机： DJI 电机 DM 电机 一开始也许只需要做“使能”： if (motor_type == DJI_MOTOR) { dji_motor_enable();} else if (motor_type == DM_MOTOR) { dm_motor_enable();} 后来需求变多了，还要设置目标值、解析反馈、执行控制更新： if (motor_type == DJI_MOTOR) { dji_motor_enable(); dji_motor_set_ref(ref); dji_motor_deco...
在 C 语言里玩面向对象
C语言模拟面向对象 很多人第一次看到这种代码风格时，都会有一个问题：“用 C 语言写出面向对象的样子，是不是显得更专业” 我的看法是：专业不在于“像不像 C++”，而在于这套写法能不能真正解决工程问题。 对于机器人嵌入式控制系统来说，系统里往往同时存在底盘、电机、升降机构、武器机构、CAN 通信、PID 控制、任务调度等多个层次。如果继续用“满地全局变量 + 一堆 switch-case + 到处散落的初始化函数”去组织代码，随着功能变多，系统很快就会变得难以维护。 这时候，C 语言里的几个经典手段——结构体封装、函数指针、组合关系、统一初始化接口、对象注册——就能模拟出一套足够实用的“面向对象”风格。 这篇文章就结合一套机器人电机控制代码，聊聊： 为什么嵌入式系统里要用 C 模拟面向对象 你的这套代码到底“对象化”在什么地方 这种写法在机器人控制系统里有什么实际价值 这种设计什么时候值得用，什么时候会过度设计 基于现有代码，还能做哪些工程上的改进 1. 为什么 C 语言也要“对象化”？ 在桌面开发里，大家很容易直接想到 C++、Rust 这类更现代的语言；但在嵌入式世界，...
