MECHATRONICS · RESEARCH · ENGINEERING
WANG
JICHAO
格拉斯哥大学机电一体化硕士在读，本科毕业于山东科技大学机械电子工程。聚焦并联机构、机电系统、控制实现、结构设计与仿真分析。
CHAPTER I · ORIGINS
从机械电子
到 机电一体化。
/ 001 — bloom
University of Glasgow
2025 — NOW · MSC MECHATRONICSOPEN ↗
/ 002 — bud
山东 科技大学
2021 — 2025 · BENG SDUSTOPEN ↗
CHAPTER II · RESEARCH
间隙、磨损与
非线性动力学。
/ 003 — leaf
Multi-clearance Dynamics
MECHANICS OF SOLIDS · 2024OPEN ↗
/ 004 — leaf
Wear & Chaos
NONLINEAR DYNAMICS · 2024OPEN ↗
/ 005 — leaf
Irregular Wear Clearances
MECHANICS OF SOLIDS · 2025OPEN ↗
/ 006 — flower
Patents · Hybrid Mechanisms
CN PATENTS · ×2 · 2025OPEN ↗
CHAPTER III · ENGINEERING
那些真正
做过、调过、试过的事。
/ 007 — fruit
Solar Stewart Tracker
2026 · GLASGOW · LEADOPEN ↗
/ 008 — fruit
6-RSS Thesis Platform
2025 · SDUST · DISTINCTIONOPEN ↗
/ 009 — sprout
news.linuxdo.cn
WEB · NEXT.JSOPEN ↗
/ 010 — sprout
AI Relay Service
COMMUNITY · APIOPEN ↗
CHAPTER IV · FIELD NOTES
把过程
写下来。
/ 011 — petal
STM32 → Linux
TUTORIAL · ENGINEERING NOTEREAD ↗
/ 012 — petal
讲清楚 承担 的那部分
THOUGHTS · REFLECTIONREAD ↗
/ 013 — petal
从山东到 格拉斯哥
TRAVEL · TRAVEL LOGREAD ↗
/ 014 — petal
材料难买又贵的那段
DIARY · DAILY NOTEREAD ↗
SCROLL TO GROW ↓
FPS 60
NODES 0
SEASON spring
/ 001 — BLOOM · EDUCATION
University of Glasgow
MSC MECHATRONICS · 2025.09 — NOW
2025 年 9 月起在格拉斯哥大学攻读机电一体化硕士，把本科机械电子工程的训练继续往控制理论、计算机控制、数字信号处理与先进制造方向深化。
主修课程
- 自动控制原理
- 现代控制理论
- 计算机控制
- 数字信号处理
- 先进制造技术
同期主导 Solar Stewart Tracker 并联机器人追光平台项目，把研究路径从论文延伸到完整软硬件系统集成。
/ 002 — BUD · EDUCATION
山东 科技大学
机械电子工程 BENG · 2021.09 — 2025.06
本科四年聚焦机械、控制、电气与制造的系统训练。GPA 3.25，专业排名 6/65。
毕业设计《基于 6-RSS 并联机构的调姿平台结构设计与分析》获优秀评级。
核心课程成绩
- 电气与电子技术 — 91
- 传动与控制 — 95 / 87
- 机器人技术 — 95
- 控制工程 — 92
- 先进制造技术 — 91
- 毕业设计 — 95
学生工作
- 2021.09–2025.06 宣传委员
- 2021.09–2022.06 宣传部干事
- 2024.09–2025.06 副团支书
荣誉
- 校二等奖学金 ×3
- 校三好学生 ×3
- 优秀共青团员
/ 003 — LEAF · JOURNAL PAPER
Multi-clearance Dynamics
MECHANICS OF SOLIDS · 2024
Research on the dynamic and reliability of planar multi-link mechanisms with multiple clearances
建立含多间隙平面多连杆机构的非线性动力学模型，并构建运动精度可靠性评估模型，研究多间隙耦合作用下机构的动力学响应规律及其对运动精度的影响。
方法
- Lankarani–Nikravesh 接触模型
- 应力-强度干涉理论
- 非线性动力学相图、Poincaré 截面分析
READ ON SPRINGER ↗
/ 004 — LEAF · JOURNAL PAPERS
Wear & Chaos
NONLINEAR DYNAMICS · 2024 / 实验技术与管理 · 2024
这一组工作围绕"运动副不再理想"这件事展开：磨损与间隙带来的非线性效应，会怎么改变机构的稳定性和混沌行为。
Nonlinear dynamic analysis of multi-link mechanism considering the wear effect of kinematic pair
分析考虑运动副磨损效应的多连杆机构非线性动力学行为，探讨磨损量随时间累积带来的动力学响应变化。
NONLINEAR DYNAMICS ↗
考虑间隙的刚柔耦合实验平台混沌辨识研究
提出含间隙刚柔耦合机构的混沌辨识方法，揭示间隙与柔性耦合效应对系统稳定性的影响规律。
实验技术与管理 ↗
/ 005 — LEAF · JOURNAL PAPER
Irregular Wear Clearances
MECHANICS OF SOLIDS · 2025
Nonlinear dynamics and kinematic accuracy reliability analysis of planar multilink mechanisms with multiple irregular wear clearances
研究多重不规则磨损间隙下平面多连杆机构的动力学与运动精度可靠性。在前期多间隙工作的基础上，把"理想圆形间隙"扩展到更接近真实工况的"不规则磨损间隙"。
方法
- Archard 磨损模型
- Lankarani–Nikravesh 接触模型
- 相图、Poincaré 截面非线性动力学分析
- 应力-强度干涉理论评估精度可靠性
READ ON SPRINGER ↗
/ 006 — FLOWER · PATENTS
Patents · Hybrid Mechanisms
CN PATENTS · ×2 · 2025
关注并联/混联机构新构型设计，通过支链几何与布局优化，在运动范围与刚度支撑之间寻求更优平衡。
CN120382464A · 公开 2025-07-29
一种基于 3SPS-PU-3PRR 的混联平台及工作方法与应用。
ZL 2025 1 0537582.5 · 授权 2025-12-26
一种四自由度 3-PRPaR&RUPUR 空间混联机械手及工作方法。
研究对象包括 6-RSS、3SPS-PU-3PRR、3-PRPaR&RUPUR 等并联/混联机构构型。
/ 007 — FRUIT · LEAD PROJECT
Solar Stewart Tracker
2026 · GLASGOW · 主导项目
3-RRS / Stewart 型并联机器人追光平台。在英国材料采购难、周期长、成本高的约束下，独立完成完整机械建模、电子元件选型、视觉方案选型、控制实现与新媒体宣传。
系统链路
- Raspberry Pi + Linux RT
- C++17 控制实现
- OpenCV + YOLO 目标检测
- PCA9685 + 舵机执行
- GitHub Actions 自动化构建
个人承担
- 并联机构逆运动学求解
- 控制逻辑实现与系统集成
- 把平台姿态目标转化为执行器控制命令
机械建模高效推进，核心结构方案约 2 小时完成；元件选型一次成功，尽量减少了反复试错带来的时间与成本损耗。在上位机与 Linux 方案落地前，先基于 3RRS-tracker_test 完成 STM32 原型测试，验证执行机构驱动与控制链路。
MAIN REPO ↗ STM32 PROTO ↗
/ 008 — FRUIT · BACHELOR THESIS
6-RSS Thesis Platform
2025 · SDUST · DISTINCTION
本科优秀毕业设计：《基于 6-RSS 并联机构的调姿平台结构设计与分析》，毕设成绩 95。
工程实现
- 机构拓扑设计与运动学分析
- SolidWorks 建模
- ANSYS 强度分析
- STM32 PWM 六舵机驱动与姿态控制
课程项目积累
- 基于 LEGO 平台的巡线、竞速、迷宫机器人
- 自平衡小车
- 相扑机器人
另有 2000+ 小时 FDM / SLA 3D 打印 经验，自行组装打印机，并结合逆向建模进行模具修补。
/ 009 — SPROUT · WEB BUILD
news.linuxdo.cn
NEXT.JS / AI / CRON
基于 Next.js 搭建中文技术聚合日报站点，按天整理论坛公开板块内容，结合 AI 生成高密度摘要，并通过定时任务自动发布到线上站点。
更偏内容工程、信息整理和自动化发布能力，跟主线机电研究是平行的另一条工程实践脉络。
VISIT SITE ↗
/ 010 — SPROUT · COMMUNITY
AI Relay Service
SERVICE · API · COMMUNITY
搭建并维护各类 AI 模型的中转平台，偏公益用途，稳定服务约 30 位用户。
偏接口整合、服务可用性和日常维护，是一个长期挂在线上、需要持续照看的服务。
/ 011 — TUTORIAL · ENGINEERING NOTE
3-RRS 追光平台如何从 STM32 原型走向 Linux 系统
FIELD NOTE · GLASGOW
这个项目其实不是完全从零开始的。
我本科毕业设计做的是一个基于 6-RSS 的并联机器人，当时已经接触过一段时间并联机构的建模和运动学分析。后来到了格拉斯哥，在嵌入式课程组队的时候，队友提出想做一个类似方向的项目，我就把题目往并联机构这边收了一下，最后做成了这个追光平台。
不过真正开始做的时候，情况和我本科毕设还是挺不一样的。
队友基本没有接触过建模、逆运动学和控制这一块，而老师要求最后要用 C++ 实现。我当时其实只比较熟 C 语言，所以一开始并没有一个特别完整的系统方案，而是先把自己能控制住的部分一块一块搭起来。
先从机械建模开始
最开始我做的是机械建模。
先用 SolidWorks 把结构搭出来，把一些关键尺寸和约束关系先确定下来。这一步相对比较快，主要是因为之前做过类似的并联机构，大概知道哪些地方需要优先确定。
建模完成之后，我没有直接写控制，而是先在 MATLAB 里做了一版运动学仿真。这一阶段主要是：
- 把机构的几何关系理清
- 推导并验证逆运动学
- 看不同姿态下各个支链的变化是否合理
这一步的目的其实很直接：先确认这套结构在理论上是能正常工作的。等到大部分零件到手之后，才开始往实际控制这边推进。
用 STM32 先把执行链路跑通
当时原本是打算用 Raspberry Pi 直接做上位控制，但板子一开始没有到位，所以中间需要一个能先把链路跑起来的方案。因为我自己比较熟 STM32，就先用 STM32 搭了一版控制链路，做一个中间层。
当时的流程大概是：
- MATLAB（上位机计算）
- 串口
- STM32
- PCA 驱动板
- 舵机
MATLAB 负责输出计算好的角度，STM32 接收数据并控制舵机执行。这一阶段的重点不是做完整系统，而是先把"计算结果 → 实际执行"这一条链路打通。
在这个过程中，也逐渐暴露出一些比较实际的问题，比如：
- 仿真算出来的角度和舵机实际执行存在偏差
- 多舵机动作时会有不同步情况
- 个别姿态在模型里没问题，但实际结构会接近干涉
- 舵机本身存在精度和响应上的限制
这些问题如果只停留在建模阶段，其实很难完全发现，必须在真实系统里跑一遍才能看出来。
再往 Linux 平台过渡
后面 Raspberry Pi 到了之后，才开始往 Linux 这边过渡。这个阶段我没有一开始就用 C++ 重写系统，而是先用 Python 把整套流程跑通了一版。主要考虑是：
- Python 更适合快速验证整体流程
- 前面已经有 MATLAB 和 C 的逻辑，可以参考
- 用 AI 做代码迁移（MATLAB / C → Python）效率比较高
所以当时是先借助 AI，把已有的控制逻辑整理并转换成 Python，在 Raspberry Pi 上把整套链路跑起来。
把视觉接进来，形成闭环
视觉部分也是在这个阶段接进来的。我使用的是 YOLO 做目标检测，这一块没有直接用现成模型，而是自己做了一些数据标注，训练了一个轻量化模型，主要是为了能在 Raspberry Pi 上运行。
这一部分我没有追求特别高的精度，重点是：
- 能稳定识别目标
- 输出的位置信息可以用于控制
- 能和后面的执行链路对接
这个阶段系统的整体流程大致是：YOLO（目标检测）→ 位置信息 → Python 控制逻辑 → 下发控制量 → 执行端（舵机）。相比 STM32 阶段，这一步的变化在于：从单独验证控制，变成了"感知 + 控制 + 执行"的完整闭环。
再从 Python 往 C++ 迁移
在 Python 版本把整套流程跑通之后，我又做了一步迁移：把这一套逻辑转换成 C++。这一步同样借助了 AI 做代码转换，因为在已有逻辑比较清晰的情况下，从 Python 到 C++ 的结构迁移效率还是比较高的。
不过在 C++ 阶段，我没有试图一次性把所有功能都完整复现，而是做了一个取舍：我只实现了控制部分中比较核心、也最容易验证的一部分，让动平台完成上下运动，以及简单的姿态（类似俯仰）变化。
也就是说，这一阶段的重点是：先保证控制逻辑在 C++ 下是能跑通、可验证的，而不是一开始就做完整系统。同时，视觉部分我没有继续全部自己做，而是分了一部分给队友去完善。我这边主要集中在控制链路上，把核心的执行逻辑先稳定下来。
这个项目是怎么一步一步堆出来的
从结果上看，这个项目并不是一开始就有一个完整方案，而是在很多限制条件下逐步推进出来的：
- 一开始从建模和运动学入手
- 用 MATLAB 做理论验证
- 用 STM32 把执行链路打通
- 再在 Raspberry Pi 上接入视觉，形成闭环
- 最后再向 C++ 迁移，并实现部分核心控制功能
中间有很多取舍，也有一些是被条件"逼出来"的选择，但整体是一步一步堆出来的。
/ 012 — THOUGHTS · REFLECTION
团队展示里，怎样讲清楚自己真正承担过的工作
FIELD NOTE · 2026
我以前对这种事其实有点迟钝。
总觉得团队项目嘛，大家一起做，最后一起讲，差不多就行了。后来才慢慢意识到，不是这样的。展示的时候别人看到的，只有台上那几分钟，而不是你私下到底做了多少、改了多少版、把哪些问题一点点推过去的。
这个感受是在追光平台那个项目里变得很具体的。
这个项目在前期其实是由我这边先推进起来的。从机械建模、运动学分析，到控制链路和元件选型，基本都是我一开始一步一步往前做出来的。项目最早能完整跑通的版本，也是基于这一套路径逐渐搭起来的。
刚开始遇到问题的时候，其实很少有人能直接接上这些工作，所以很多关键决策，比如结构怎么定、控制链路怎么搭、先验证哪一部分，都是我一边试一边往前推的。等到项目整体跑通之后，才逐渐进入团队一起整合和准备展示的阶段。
问题也就是在这个时候开始变得明显。
为了更符合课程对"团队合作"的要求，我们在展示内容上做了一个比较平均的划分。每个人都负责一部分，看起来更像是一个标准的团队项目。但这样处理的结果是，原本是一条连续推进的工作，被拆成了几个模块。外面的人看起来，会觉得每个人都参与了很多，但很难看出哪些部分是由谁主导完成的。
同时，在实现方式上也出现了一些分歧。我这边更倾向于在已经完整跑通的版本上，逐步按照课程要求往 C++ 方向调整，这样整体风险比较可控；但队友那边更希望按照自己的代码结构重新实现一版。
这其实不是简单的对错问题，而是两种不同的推进思路：一种是基于已有系统逐步修改，一种是从规范出发重新搭建。因为时间和沟通成本的限制，最后没有完全统一成一条路线，而是各自推进了一部分实现。
另外一个比较实际的问题是，GitHub 上的代码提交并不能完全反映真实的分工。一方面是后期为了满足课程要求，有一部分代码做了统一整理和结构调整；另一方面，一些前期的关键工作，比如建模、运动学推导、控制链路设计和整体调试，本身也不完全体现在代码量上。
所以从结果上看，代码贡献是分散的，但从项目推进过程来看，很多核心实现路径是先由我这边搭起来的。
从结果上看，项目最后是完成了，但也留下了一个比较明显的感受：当前期的工作没有被记录下来，而后期表达又被平均分配时，个人的实际贡献是很容易被"冲淡"的。这不是谁刻意在做什么，而是表达方式本身就会带来的结果。
我后来会有点别扭，其实不是因为"谁做得多谁做得少"，而是因为：有一些工作确实是我自己从头推到尾的，比如结构方案、控制链路、整体实现路径。这些东西如果只用一句"参与了项目"来带过，其实是讲不清楚的。而如果连这些都讲不清楚，那这个项目对我个人到底意味着什么，也会变得很模糊。
开始重视过程证据
也是从这次之后，我才开始真正重视"过程证据"这件事。以前做完就算了，现在会刻意留下东西，比如：
- 建模版本
- 测试视频
- GitHub 提交记录
- 参数调整过程
- 阶段性的结果截图
这些东西平时看起来很碎，但当你需要复盘、写申请或者介绍项目的时候，它们会直接决定你能不能把事情讲清楚。
对"团队合作"的理解也变实际了
另外一个变化是，我对"团队合作"这件事的理解也更实际了一点。合作不是把所有人的工作混在一起，而是：
- 每个人都清楚彼此在做什么
- 关键决策是谁推进的可以说清楚
- 最终展示时也能对应起来
把自己承担的部分讲清楚，并不是在强调个人，而是在保证信息是准确的。
所以这次之后，我给自己留了一个很明确的提醒：以后再做类似项目，我还是会愿意多做事、往前推，但不会再默认"做了就会被看到"。很多事情不会自己被看到，需要你自己把过程留下来，也需要你自己把它讲清楚。
/ 013 — TRAVEL · TRAVEL LOG
从山东到 格拉斯哥：学习、生活与环境切换的真实感受
FIELD NOTE · GLASGOW
从山东到格拉斯哥，最难适应的其实不是距离，而是很多事情突然不再"默认成立"。
刚到的时候，有一件很小的事让我印象很深。第一次去超市，本来只是想买点东西，但站在货架前会犹豫很久：东西怎么分区、价格怎么看、哪个更合适。再加上这边天黑得很早，下午四五点就已经像国内晚上，一天的节奏被直接打乱。
这些事情单独看都不大，但它们会叠在一起，让你一直处在一种不太放松的状态。不是很严重，但就是一直有点绷着。
学习上的不适应更直接
学习上的不适应更明显，而且比我一开始想的要直接。
第一学期机电这边有两门比较核心的课：数字信号处理和控制工程，本身难度就不低。刚开始上课的时候，我还是按以前的习惯在听，觉得虽然有点快，但还能跟上。
但到第一次作业和准备考试的时候，我才慢慢意识到问题：老师讲的内容和最后考察的方式，并不是完全对应的。课上讲的是推导和概念，但作业和考试往往需要你自己去转换。如果只是按"听懂课"的标准来准备，很容易发现自己其实并没有真正掌握。
那段时间的感觉是，一天结束之后，明明没做什么体力活，但人还是很累，因为一直在反复确认："我到底有没有理解对？""这个东西考试会怎么考？"
一门课的经历
课程本身还可以慢慢适应，但有一门课的经历让我印象特别深。
Advanced Manufacturing 这门课，考试的时候我其实挺有信心的，感觉每一道题都会，考完试我都是踮着脚出的考场。当时甚至觉得，分数应该不会低，没有100分也有90分。
结果成绩出来的时候，只是刚刚过线10分。那种落差其实挺直接的。
后来我去申请复核试卷，才发现更具体的问题：我所有的开放性简答题，全是 0 分，而计算题是有分的。更让人难受的是，复核并不会重新判断对错，只是让你确认加分有没有问题。我当时只能一页一页去看评分，最后发现有一页试卷甚至没有被批改到。
说实话，这种事情发生在一个世界前一百的学校里，你很难完全当作"正常"。你可以理解为流程问题，但当它真的落在你自己身上的时候，那种不舒服是很直接的。（格拉斯哥去年因为这类事件闹的很大，但是我遇到了还是感觉世界就是一个巨大的草台班子）
把重心往回收
这件事之后，我其实有一段时间是有点不太认同这种评价方式的。不是说课程本身不难，而是你会感觉，有些结果并不完全取决于你自己做得怎么样。中间那一层流程和标准，是你很难控制的。也确实会有一点情绪在里面。
但时间久了之后，我慢慢发现，如果一直纠结这些，其实挺消耗的。后来我慢慢调整了一下自己的想法。
与其去反复想"这个结果到底公不公平"，不如把重点放回到一件更实际的事情上：我自己到底有没有把东西学会。因为只有这一点，是我能控制的。只要核心的理解在自己这里，很多短期的结果，其实不会那么关键。
这不是说完全不在意，而是你会开始有意识地把重心往回收。
慢慢自然地过完一整天
生活上的适应也是类似的。有一天我突然意识到，自己已经可以比较自然地过完一整天了：上课、做作业、安排时间，都不需要再像刚来的时候那样，每一件小事都多想一遍。那种变化很细，但你能感觉到。不是一下子变轻松，而是你不再一直在确认自己有没有做错。
现在回头看，其实挺想把这段过程记下来。它不像项目那样有明确的完成节点，你很难说哪一天开始就完全适应了。更多是某一天你突然发现，自己已经可以比较自然地待在这个环境里了。
中间有不适应，有不认同，也有一点情绪，但最后还是一点一点过来了。
/ 014 — DIARY · DAILY NOTE
材料难买又贵的时候，我是怎么把并联机构项目继续做下去的
FIELD NOTE · GLASGOW
这个项目做到后面，我印象最深的不是某个技术点，而是"东西怎么这么难买"。在国内做硬件项目的时候，很多材料和元件默认就是能找到替代的，实在不行再换一家店、换个平台。但在英国不是这样。有些东西贵得离谱，有些要等很久，有些你看着参数差不多，真到手又发现根本不适合现在这套结构。项目一旦和并联机构这种东西绑在一起，材料问题就会被放大，因为它不是少一个零件还能先凑合一下，很多时候是你前面几步都跟着受影响。
我后来慢慢接受了一件事：这种条件下做项目，很多决定不能按"最理想"来做，只能按"现在最能落地"来做。听起来有点无奈，但这反而更接近真实工程。比如电子元件选型，我当时会特别在意成功率，而不是纸面参数谁更好看。能一次买对、一次接上、一次跑起来，比选一个理论上更强但要反复返工的方案重要得多。项目做到赶时间的时候，你会很明显地感觉到，省下来的不是一点钱，而是一整段节奏。
机械建模在这种环境下就更不能随便了。因为材料贵、加工和修改都不轻松，所以很多问题必须尽量在模型阶段先消化掉。我当时对结构方案收得比较快，核心建模做得也很快，这件事后来别人听起来会觉得像是"两个小时搞定，很轻松"。其实完全不是那个意思。快的前提是我已经知道自己要什么，不想在一些没必要的地方绕圈。并联机构这种东西，一旦约束关系没理顺，后面越做越乱，所以我更愿意把判断集中放在前面。
真正难受的是很多小决定会不停冒出来，而且它们都很具体。某个连接件是等还是改，某个材料能不能先替代，某个结构是不是该为了装配方便让一点，某个版本是不是先跑通再说。每一个单独看都不算大事，但项目就是被这些小事一点点拽着走的。很多人只看到最后那个成品，会觉得重点在"做出来了"；对我来说，真正费劲的反而是中间那些不太好写进成果展示里的犹豫和判断。
所以如果我写这篇，我其实很想把那种很真实的拉扯感写出来。因为项目不是一条很干净的线，不是确定目标然后稳稳走过去。更多时候是你今天觉得这个方案行，明天发现成本不行；你以为材料到了就能推进，结果装配时又冒出新问题；你本来想一步做漂亮，最后发现还是得先做个能用的版本把主流程保住。听起来不那么"厉害"，但这就是实际在发生的事。
我现在会觉得，这种经历本身就值得写。不是因为它多传奇，而是因为它很真。很多工程能力不是在顺风的时候长出来的，而是在条件不够好的时候被逼出来的。材料难买、预算有限、时间又紧，这些都不算好条件，但项目最后还是得往前推。能在这种情况下继续做下去，本身就是一件挺实在的事。