简介：NAO机器人系列舞蹈是一份面向NAO机器人爱好者、教育工作者及编程初学者的舞蹈编程资源包，聚焦如何通过Choregraphe图形化编程工具为NAO设计并执行舞蹈动作。压缩包采用rar格式，共5个文件，14.09MB，包含Choregraphe舞蹈行为文件、行为包元数据描述、两段ogg背景音频以及图标文件，其中行为文件内置了完整的舞蹈动作序列，音频用于配合动作播放，元数据则定义行为包的依赖与加载信息。目前已有1789人学习下载。通过这份资源，用户可直接导入行为文件体验NAO的预设舞蹈，还可参考其动作编排思路，学习利用Choregraphe调整肢体、头部与表情，结合音频实现多模态表演，为人形机器人在艺术、教育等场景中的二次开发提供实用起点。 第一次在展示厅里让NAO机器人跳完一支完整舞蹈时，我自己都站在原地愣了几秒。一个58厘米高的小家伙，抬头、摆手、转身、抬腿，把一段机械舞跳得比很多初学者还有节奏，旁边的观众哄堂大笑后又开始录像。就是从那一刻起，我把这个项目从"玩票"升级成了持续更新的"NAO机器人系列舞蹈"：半个多月迭代了好几支舞，从选曲、编舞、按键位、写Python脚本、调重心到现在敢上演出舞台，中间踩过的坑和折腾出来的经验，都在这篇里了。
这篇文章不是官方文档的搬运，而是我自己用Choregraphe和Python一点点试出来的实操记录。如果你手里有一台NAO（V5/V6均可），或者只是对仿人机器人动作编程感兴趣，这篇能帮你绕过大部分弯路。整体我会按“硬件能力分析—编舞设计—编程实现—平衡调优—系列化工程管理”这条路径讲，保证每个环节都能直接落地下一步。
1. NAO到底适合跳什么样的舞
1.1 25个自由度能做什么，不能做什么
NAO之所以适合做舞蹈项目，第一步要搞明白它的身体结构。它全身有25个自由度：头部2个、每只手臂5个、每只手1个、每条腿5个、髋部2个。听上去挺多，但细看腿部的自由度分布，就会发现它和真人差别很大——腿部没有足够的脚踝侧向调节和膝盖旋转空间，跳不了大幅度的开合跳，更不可能做后空翻。
所以做系列舞蹈时，我先给自己定了一条规矩：不要跟硬件硬刚。把大腿跳跃类的动作直接放弃，把设计重点放在手部姿态、头部转向、躯干侧倾和髋部小幅度转动上。这些动作NAO做起来顺，关节余量大，动作不容易打到机械限位。
我自己的实测是，NAO的手臂活动空间比想象中大得多。RShoulderPitch、RShoulderRoll、RElbowYaw这几个关节配合起来，能摆出很丰富的手位，甚至可以模拟街舞里常见的"波浪手"和"机械定格"。而腿部的价值更多在踩拍子，用小幅度的抬腿、侧点地、双脚交替移动来丰富节奏感。简单说，NAO跳机械舞、电子国风、K-Pop副歌段落都很出效果；跳慢板民族舞或者芭蕾这类讲究身形延伸感的舞种，反而容易暴露机械关节的僵硬。
1.2 舞种适配矩阵
我把试过的风格整理了一个适配表，可以直接用来当选舞参考：
| 舞种 | 适配度 | 主要问题 | 推荐动作策略 |
|---|---|---|---|
| 机械舞/震感舞 | 高 | 几乎无 | 手臂分段定格，髋部点节奏，头部配合视角 |
| 电子国风 | 高 | 动作幅度需控制 | 扇子手、甩袖简化版，靠手部姿态传神 |
| K-Pop副歌 | 中高 | 编舞速度快，关键帧密集 | 截取8拍副歌，重复利用主舞步 |
| 拉丁舞 | 中 | 髋部转动幅度有限 | 用小幅度八字胯 + 手臂伸展补充 |
| 民族舞/慢舞 | 低 | 延伸感和流畅性不足 | 尽量少碰，除非做搞笑反差效果 |
有了这张适配表，后续每支舞的选曲和编舞方向就不会跑偏。与其硬跳一支效果尴尬的舞，不如挑NAO擅长的风格，把效果做满。
2. 一支舞是怎么从选曲变成动作脚本的
2.1 选曲和剪音乐的实操标准
很多人上来就选一首喜欢的歌，结果做到一半发现节奏没法拆，这是新手最容易踩的第一个坑。我给NAO选曲有一条硬标准：BPM在110到130之间，4/4拍，重拍明显，最好前奏部分就有一段稳定的鼓点。这个区间动作密度刚好，不会因为BPM太快导致关节来不及到位，也不会因为太慢显得动作生硬。
选好歌之后，不要直接拿原曲用。我用剪辑工具把音乐处理成60到90秒的演出版本，截取最有辨识度的8拍循环，确保每一段都有明确的重拍节点。剪辑时顺手把节拍点标出来，在时间轴上标记每一个强拍的时刻，这个步骤越细，后面编程时同步越省力。我当时把整首歌拆成了若干个8拍乐句，每个乐句分配一组“主关键动作+过渡动作”，这样编舞的逻辑就很清晰了。
2.2 从节拍到动作的映射方法
拿到标记好的时间轴后，我开始做动作映射。基本思路是：每个强拍对应一个服务关节能明显感知的动作点。比如第1拍到位，第2拍保持，第3拍过渡，第4拍回正。听起来像跳舞的基本功，但放在NAO身上就成了关键帧的设计依据。
具体操作时，我会先用纸笔或表格画出8拍里每个拍子上的动作概览：
| 拍号 | 动作名称 | 左臂动作 | 右臂动作 | 髋/腿部动作 |
|---|---|---|---|---|
| 1 | 开手 | 肩前举90度 | 肩前举90度 | 髋回正 |
| 2 | 定格 | 肘关节90度收紧 | 肘关节90度收紧 | 左脚侧点 |
| 3 | 波浪手 | 肘部上抬，手部下压 | 肘部下压，手部上抬 | 髋微左倾 |
| 4 | 回正 | 回落 | 回落 | 双脚回正 |
这张表格就是后续所有编程的蓝图。没有这张表，直接在软件里摆姿势会非常混乱，关节一多，很快自己都不知道在调哪只手。有了表，关键帧的摆放顺序就非常机械化：每个编号的动作对应一个时间点，把各关节的角度输进去就好。
2.3 关键帧设计：先躯干后四肢
设计关键帧有一个顺序原则：先躯干后四肢，先支撑后表演。也就是先定腿和髋的位置，保证重心稳定；再定手臂和头部的姿态，承担表现力。如果反过来先摆手臂，等调腿部的时候重心一变，手臂姿势全部要重改。
另外要注意NAO关节的角度范围，大部分关节我都习惯留出10度到15度的安全余量，不推到极限。一个是极端角度会让舵机吃力，时间久了发热严重；另一个是角度太极限时稍微有点振动就容易被判定为碰撞，触发保护断电。这是我吃过亏的：有只手臂的肩关节角度接近极限，演出前测试时把电机直接逼急停了，只能临时换机器人。
3. Choregraphe和Python双写：动作实现与调参记录
3.1 Choregraphe里的Timeline：快速验证动作是否合理
第一版动作我推荐在Choregraphe里用Timeline编辑器做。开一个Motion图层，把时间轴按音乐节拍拉开，然后在每个关键时刻拖动画布上的机器人关节滑杆，手动摆出想要的动作。这个过程比想象中快，因为能看到3D模型实时反馈，不用想角度数值，摆到好看就行。
一个经验是，Timeline里不要只放关键动作帧。在两个关键帧之间适当插入中间过渡帧，动作才会平滑。比如从手臂90度前举到完全垂下，如果只设两个关键帧，机器人手臂会以最大速度甩下来，看着像抽风；中间加一帧30度位置，同时把帧间距拉长，动作就有了"控制感"。
Choregraphe的Timeline同时也支持把多个动作图层叠在一起，这意味着可以把左臂、右臂、腿部、头部拆成不同图层分别编辑。我习惯把腿部动作单独放一个图层，因为腿部动画通常是最先需要调整的，分层后改起来不用全局翻找。
3.2 Python接管复杂逻辑：angleInterpolation才是主力
Choregraphe适合把动作“摆出来”，但当一首舞要做几十个动作、还要配合各种时间变化时，纯手动摆帧就太累了。这时候Python脚本才是主力。
NAO机器人的Python接口通过naoqi包连接。核心方法是ALMotion.angleInterpolation，它可以把一组关节的角度随指定时间段同步执行。下面是我常用的一段基础模板：
# -*- coding: utf-8 -*- from naoqi import ALProxy robot_ip = "192.168.1.100" robot_port = 9559 motion = ALProxy("ALMotion", robot_ip, robot_port) # 唤醒机器人,给关节上电 motion.wakeUp() # 设置所有关节的刚度,1.0表示完全锁死 motion.setStiffnesses("Body", 1.0) # 定义要控制的关节 names = [ "LShoulderPitch", "LShoulderRoll", "LElbowYaw", "LElbowRoll", "RShoulderPitch", "RShoulderRoll", "RElbowYaw", "RElbowRoll", "HipPitch", "HipRoll", "KneePitch" ] # 对应关节的目标角度(弧度) angles = [ 1.50, # LShoulderPitch, 前举 -0.15, # LShoulderRoll 0.30, # LElbowYaw -1.20, # LElbowRoll 1.50, # RShoulderPitch 0.15, # RShoulderRoll -0.30, # RElbowYaw 1.20, # RElbowRoll 0.00, # HipPitch 0.00, # HipRoll 0.00 # KneePitch ] # 所有关节在同样时间内完成动作 times = [0.6, 0.6, 0.6, 0.6, 0.6, 0.6, 0.6, 0.6, 0.6, 0.6, 0.6] isAbsolute = True motion.angleInterpolation(names, angles, times, isAbsolute)这里有几个容易踩的坑，我一个个说。第一，角度单位是弧度，不是度。用Choregraphe时界面显示的是度，但写Python脚本时还是要换算成弧度，我最早写的时候直接填度，结果手臂猛甩到超过限位，当场报错；现在都习惯先写一个math.radians(90)这样的转换。第二，times列表的时长单位是秒，不是毫秒，别想当然填几百。第三，isAbsolute=True代表目标是绝对角度，适合固定姿势转换。如果要做相对当前角度的小幅修正，就设成False，但说实话我用绝对角度的场景多得多，因为可预测性更强。
3.3 把Timeline动作导出成动画文件
当在Choregraphe里通过Timeline调好了舞段，还可以把它导出成一个动画文件（.anim或者.mov格式）。之后用ALMotion.playMove(path)来播放，这对系列化特别重要——同一支基础舞段可以在不同编曲里反复调用，不用重复写角度列表。
如果不想用文件，也可以用ALMotion.playMove传入Choregraphe工程里保存的timeline数据。两种方式我都试过，最终倾向把成型舞段导出为动画文件，因为文件加载起来稳定，也方便在多台NAO之间复制部署，演出时切换不同舞蹈也不会占用太多脚本内存。
4. 最磨人的不是编程，是让它站稳别摔
4.1 摔跤背后的物理原因：质心和支撑面
这台机器人摔跟头的次数，远超我的预期。第一支舞调试时，大概每三次运行就摔一次，而且都是在做一个大幅度抬臂动作之后。原因很简单：抬臂角度过大时，手臂质量让整机质心偏移，一旦质心投影超出双脚组成的支撑多边形，机器人就会倒。
想想人也是一样，你单腿站立时如果身体突然往一侧伸手，也能感觉到重心被带走。但人会自动用核心肌群和脚踝补偿，NAO没有这么强的实时平衡能力，在普通舞蹈模式下它只是个"听话的关节系统"，不会主动调整重心。所以舞蹈动作的稳定性，必须在设计层面自己保障。
4.2 三步调稳法：从下往上改
我调试稳定性的顺序固定是三步，从下往上改，效果最明显。
第一步，先调腿部与髋部。默认站姿下，双脚间距尽量大一点，让支撑面更宽。练了一支舞后我发现，某些动作里只需让髋关节稍微向左倾2到3度，重心就能明显拉回中间。这个改动成本最低，但收益最大。
第二步，调整躯干与头部姿态。NAO的头部占整体重量比例不低，如果跳舞时头一直朝一个方向看过久，重心也会跟着偏。我会在转身类动作前后让头回正，既符合舞蹈表现力，也减少质心偏移。
第三步，最后改手臂。手臂是最灵活的调节变量：如果某个动作快摔了，不要直接删掉，试着把手肘外翻减少10度，关节就能把力量收回来。臂展缩短后，惯性矩减小，稳定性的提升是立竿见影的。
4.3 试错保护和安全测试流程
测试时一定要做好防护。我调试现场常备一块2厘米厚的软垫，机器人下方还绑了一条安全绳，防止它摔到硬地板上损坏关节。除此之外，测试前一定要关闭关节的碰撞保护吗？不是，恰恰相反，要开着。NAO的碰撞保护是最后一道保险，一旦关节受到异常阻力，它会立刻软掉，避免电机损坏。留着它，摔的时候至少不会“硬着陆”，把舵机齿轮打坏。
还有一个很实用的功能是ALMotion.setSmartStiffnessEnabled，开启后，机器人静止时关节刚度会适当降低，避免长时间高刚度锁死导致电机过热。舞蹈排练一次连续十几分钟，如果不开这个，关节温度上得很快，尤其是肩和髋。我在反复测试时遇到过电机过热停转，之后每次排练前都习惯性摸一下几个关键关节外壳，热了就停机休息几分钟。
5. 把一支舞扩成一整个系列时，我做了哪些工程化取舍
5.1 动作库与脚本结构，才是系列化的底座
真正把一个舞蹈项目升级成"系列"，难点不在某一支舞编得好，而在能不能重复造轮子。我把每支舞蹈的所有动作按性质拆成两类：通用基础动作和专属编舞动作。通用基础动作包括：左右挥手、双手上举、头部跟随、侧点地、小碎步、髋部侧倾等，这些被封装成独立的Python函数，传入参数是持续时间、幅度、方向。专属编舞动作只写在特定舞蹈文件中，比如机械舞里的“闪肩定格”就只在机械舞脚本里。
这样划分之后，新做一支舞我只需要把已有的基础动作像积木一样组合，再补充几个新动作，时间成本节省非常明显。下面是我自己项目里的一个基础动作库节选：
| 动作名称 | 涉及关节 | 关键参数 | 复用次数 |
|---|---|---|---|
| swave_arm | L/R Shoulder + Elbow | duration, amplitude | 12 |
| head_track | HeadPitch + HeadYaw | direction, duration | 15 |
| hip_sway | HipRoll | angle, duration | 9 |
| step_touch | Hip/Ankle | side, step_width | 7 |
| freeze_pose | 全身 | duration | 6 |
5.2 多台NAO协同的同步方案
系列舞蹈做到后面，我开始尝试两台NAO同时跳。这就遇到了同步问题。实话说，不要去追求毫秒级时间同步，用操作系统时钟对齐不现实，NAO之间的网络延迟和关节响应时间都会让动作错开。
我的方案是搭一个简单的局域网结构，一台电脑作为"指挥端"，通过路由器向两台NAO同时发送启动信号。发送时用UDP广播，两台机器都在同一时刻收到start命令后各自执行同一个动作脚本。因为脚本本身从第一个动作开始就在同一个本地时间基准上跑，所以一旦启动对齐了，后面动作序列基本能对齐。视觉上虽然可能有几十毫秒误差，但对舞蹈整体呈现来说，观众是分辨不出来的。
如果要求更高，可以尝试用音频信号做同步：由一个外放扬声器播放一声"滴"，两台机器人用麦克风检测到这个声音后同时启动。这个方案我试过，对NAO这种自带麦克风的机器人来说可行，但环境噪音大会误触发，还是不如局域网广播稳定。
5.3 演出版本的工程管理
当项目走向正式演出时，工程管理就变得特别关键。我会给每个演出日单独建一个配置目录，里面包含：当天用的舞蹈脚本、音乐文件、机器人IP配置、关节刚度预设、演出checklist。每次演出前一天做一次完整排练，排练时直接跑最终版本，不临时改脚本。
另外，备份一台机器人几乎是必须的。NAO的电机经过长时间运行后响应速度会下降，同一支舞排练十次之后，某些动作可能会越走越偏。我有一次就是因为一个肩关节响应变慢，导致整个动作比节拍慢了0.2秒，现场看起来像"慢半拍"。现在每次排练前会先跑一个全关节测试脚本，依次转动所有关节并打印实际角度，如果偏差超过5度就标记这台机器人需要休息或检修。
结尾：留下来的几条经验
项目做了这么久，我个人最深的体会是：机器人跳舞的技术难度从来不在某个关节怎么转，而在稳定、同步和可重复性。你哪怕编出一段很炫的舞，摔一次就全崩了；现场演出时，稳定执行三个80分的动作，远好过表演一个100分的动作然后宕机。
给想入坑的同学几件小事：买机器之前先确认自己的编程习惯——纯图形化用户用Choregraphe就够，能写脚本的一定要上Python，后者才是提高效率的捷径；开始编舞之前先把音乐节拍标注做细，这能省掉后面80%的返工；每次调试前检查关节刚度和电机温度，养成习惯后你才知道，所谓"机器人跳得好"，其实是大量准备工作的结果。
这个系列的下一步，我打算把单机舞蹈升级成带语音互动的表演——机器人跳完舞后用语音跟观众互动，再自动切换下一支舞。技术上是把动作脚本和对话状态机串起来，难度不算大，但舞台效果会更有层次。如果你也在做NAO或其他仿人机器人的舞蹈项目，欢迎沿着前面那套方法先跑通一支舞，回头你会发现自己其实已经绕开了一大半坑。
本文还有配套的精品资源，点击获取
