机器人 - 关于MIT电机模式控制

目录

一、MIT电机模式简单介绍

1.1 简单介绍

1.2 MIT模式的控制参数

1.3 使用场景

二、调试时建议

2.1 调试

2.2 问题定位


一、MIT电机模式简单介绍

1.1 简单介绍

Mixed Integrated Torque为一种混合控制模式,在同一帧CAN数据里包含 位置、速度、扭矩三类的闭环指令。驱动器里面把位置环、速度环、前馈扭矩相加,得到一个参考电流,然后再交给电流环完成精准扭矩输出。


1.2 MIT模式的控制参数
参数含义取值范围(常见)说明
kp位置比例系数(刚度)0 ~ 500 (单位视驱动器而定)kp = 0 时位置环失效,仅靠速度/扭矩环工作
kd位置微分系数(阻尼)0 ~ 500kd = 0 时位置环会产生振荡,实际使用时需给一个非零值
pos (q)期望位置(单位:计数或角度)-12.5 ~ 12.5 rad(示例)位置环的目标值
vel (dq)期望速度(单位:rpm)-30 ~ 30 rpm(示例)速度环的目标值
torq (tau)前馈扭矩(单位:Nm)-T_MAX ~ T_MAX直接给定的扭矩,常用于 纯扭矩控制(kp = kd = 0)

1.3 使用场景
场景参数设置示例说明
匀速转动kp = 0,kd ≠ 0,pos = 0,vel = 目标速度,torq = 0只打开速度环,电机以恒定速度运行。
纯扭矩输出kp = 0,kd = 0,pos = 0,vel = 0,torq = 目标扭矩前馈扭矩直接驱动电流环,适用于 力矩控制(如抓取、阻尼)
点到点位置控制kp > 0,kd > 0,pos = 目标位置,vel = 0,torq = 0位置环+速度环共同作用,实现平滑定位。
位置‑速度‑扭矩混合kp > 0,kd > 0,pos = 目标位置,vel = 目标速度,torq = 前馈扭矩适用于 刚度‑阻尼‑外力补偿(如机械臂的阻抗控制)。

在使用位置控制时,kd不能为0,否则电机会振荡、失控;



二、调试时建议

2.1 调试
步骤操作要点
① 先打开位置环设定 kp > 0kd > 0,观察位置响应曲线,确保无明显超调。
② 调整阻尼增大 kd 可抑制振荡;若响应过慢,可适当降低 kp
③ 速度环在位置环基础上调节 vel(目标速度)或直接使用 kp=0、kd≠0 进行 纯速度控制
④ 前馈扭矩当负载较大时,适当加入 torque 前馈,以补偿静摩擦或外部扰动。
⑤ 监测电流通过驱动器的电流反馈(CAN 0x02 帧)检查是否出现 过流,必要时限制 torque 上限。

2.2 问题定位
问题可能原因检查方式
电机不转动kp=0、kd=0、torque=0(所有环失效)确认发送的参数中至少有一个非零值。
出现振荡kd 设为 0 或过小增大 kd,或在位置环加入适当的 kp
转速偏差大前馈扭矩未补偿负载在 torque 参数中加入正向前馈,或调大 kp
CAN 报文未到达报文 ID 错误或波特率不匹配用示波器或上位机抓包确认 ID 为 0x00+motor_id(位置帧)和 0x01+motor_id(扭矩帧),波特率与驱动器保持一致(默认 1 Mbps)。
电机过流保护torque 设定过大限制 torque 幅值在驱动器手册规定的 T_MAX 范围内。

Read more

前端拖拽排序实现详解:从原理到实践 - 附完整代码

前端拖拽排序实现详解:从原理到实践 - 附完整代码

🌷 古之立大事者,不惟有超世之才,亦必有坚忍不拔之志 🎐 个人CSND主页——Micro麦可乐的博客 🐥《Docker实操教程》专栏以最新的Centos版本为基础进行Docker实操教程,入门到实战 🌺《RabbitMQ》专栏19年编写主要介绍使用JAVA开发RabbitMQ的系列教程,从基础知识到项目实战 🌸《设计模式》专栏以实际的生活场景为案例进行讲解,让大家对设计模式有一个更清晰的理解 🌛《开源项目》本专栏主要介绍目前热门的开源项目,带大家快速了解并轻松上手使用 🍎 《前端技术》专栏以实战为主介绍日常开发中前端应用的一些功能以及技巧,均附有完整的代码示例 ✨《开发技巧》本专栏包含了各种系统的设计原理以及注意事项,并分享一些日常开发的功能小技巧 💕《Jenkins实战》专栏主要介绍Jenkins+Docker的实战教程,让你快速掌握项目CI/CD,是2024年最新的实战教程 🌞《Spring Boot》专栏主要介绍我们日常工作项目中经常应用到的功能以及技巧,代码样例完整 👍《Spring Security》专栏中我们将逐步深入Spring Security的各个

前端 + agent 开发学习路线

背景:团队启动Agent项目,从零开始学习工程化AI开发 感谢ai老师写的学习指南。存档! 引言:从困惑到清晰 最近团队要启动Agent项目,我第一次接触这个概念时,只停留在“接入大模型API+优化Prompt”的浅层理解。经过大量学习和实践探索,我才发现工程化Agent开发是系统化的架构设计,而不仅仅是API调用。 这篇文章记录我从前端视角出发,探索Agent工程化开发的学习路径和实践经验。如果你也是前端/全栈开发者,想要在AI时代找到自己的定位,这篇指南应该能帮到你。 一、认知重塑:什么是工程化Agent? 1.1 我的错误认知 vs 现实 我原来的理解: Agent = 大模型API + Prompt优化 实际上的工程化Agent: Agent = 系统架构 + 可控执行 + 安全审查 + 领域适配 + 可观测性 1.2 Agent的分层架构(医疗场景示例) 你的主战场 任务分解器 工具路由器 记忆管理器 状态监控器

BK7258 x LiveKit WebRTC :从 0 到 1 的端侧适配

BK7258 x LiveKit WebRTC :从 0 到 1 的端侧适配

> 面向对象:做 AI 硬件、语音对讲、智能终端的开发者 > 关键词:BK7258、LiveKit、WebRTC、实时语音、MCP、设备控制 一、为什么是 LiveKit? 在实时语音 AI 场景里,很多团队一开始只关注“音频能不能传”,但真正落地会遇到更多问题:连接稳定性、会话管理、设备控制、Agent 协同、扩展能力等。 LiveKit 的价值就在于:它不仅是传输层,更是一个面向实时 AI Agent 的平台能力层,统一了房间、参与者、媒体轨道和数据通道能力。 官方定位可以概括为:构建 voice / video / physical AI agents 的平台。   二、BK7258

受够了网络反爬?这套 WebTop 方案,让云端 OpenClaw 像真人一样上网

受够了网络反爬?这套 WebTop 方案,让云端 OpenClaw 像真人一样上网

浏览器是网络世界的入口 对于云端部署的 OpenClaw,有一个最大的痛点,就是浏览器没有显示界面,这会对 OpenClaw 的浏览器自动化操作产生很大的影响。 刷知乎、小红书、推特,或者看 Reddit 时,传统的 Headless(无头)浏览器几乎过不了人机验证,也很容易卡在扫码登录界面。 云服务器没有显示器,你连验证码长什么样都看不到,更别提接管操作了。 那么,有没有一种优雅的姿势,让云端的 OpenClaw 拥有一个“有血有肉”的真实桌面浏览器? 就像我们在本地自己电脑上浏览网页一样自由? 既能保留 Cookie 环境,又能在遇到验证码时,让你通过浏览器随时“远程附体”进行人工接管? 我花了几天时间,反复追问 Claude、GPT、Grok、Gemini、Kimi,在我的云服务器上跑通了他们一致推荐的方案:WebTop + Tailscale,并且成功登录谷歌、知乎、小红书等平台。