openTCS学习记录笔记（二）--转B/S架构网页版（终）
作者：互联网
一：随便说说
近期工作太忙，家里事也多，没关注这边，上来看到好多人在关注这个，我就总结一下吧。
首先给个结论，openTCS直接转web方式根据查找的资料是可行的，而且我已经实现了web化，虽然是用的其它方式。
openTCS转化研究下来并不建议，因为最终转化出来的只是一个简陋的模型而已（虽然该有的功能都有了），比如说，地图大小怎么确认，怎么保证精度？点位的位置怎么定，怎样保证和实际地形完全对应？问题还是很多的，无法完全应用于实际工厂环境，所以我这边放弃直接web化的打算。
二：成品架构
所以最终我直接使用了重开项目的方式来完成它，公司三人团队历时一年成功完成！
成品首页展示图：
根据实际情况，我们把最终产品分为了4层：
来个简图：
1、AGV（或机器人）：它包含路径算法和地图扫描，毕竟最终怎么走得由实际走得人来判断，如果交由软件判断，实际的实时数据将有可能失真，这样还有个好处，可以让AGV有独立执行的能力
注：AGV厂家很多，算法和API接口不用你关心，如果真有那么多特殊需求，自己直接开一个坑也不是太费事
2、站点控制系统后台：后续简称站端，此系统主要直接和AGV连接，负责任务的调度，结果的收集，再就是数据的展示。简单点说AGV保证数据的精确，站端负责调整任务的路径和收集任务执行的状况，当然，因为运算量原因，一个站端大概最多接5~10台。
注：这个就是纯java了，其它的也行，因为他只管任务，点位和路径管理后续说
3、集中控制系统后台：后续简称集控，此系统直接和所有站端对接，负责处理所有站端告警，这个系统主要作用于中控室，进行数据的统一处理。
4、前端展示：这个分出一个模块的原因是，工厂实际地图 和 展示地图 的换算工作主要放在这里，毕竟要保证地图 和 对应的 拐点，停顿点等等的准确展示，所以这些也不是随便定定的。
三：设计原因
之所以这样设计的原因有很多，那就随便举几个绕不过去的问题吧。
a）数据延时性问题：AGV工作时的实时数据处理，一台AGV还好，各种避障距离，激光测距数据，环境数据等等等等，这些数据的实时性要求极高，别说秒级了，一台高速行驶的AGV，用秒级判断前方是否有障碍是不靠谱的行为，而且这样的数据极多，当AGV数量过多时，服务器是根本处理不过来的。所以我现在使用的集控==》站端==》AGV这种结构也是为了最大程度缓解运算量。
b）数据准确性问题：AGV导航最重要的核心是实时位置，而AGV位置定位有多种方式，一种是GPS，这种不太靠谱，定位精度不高，还有一种常用的是激光云图，大概解释就是一个激光球装置，发射无数激光，每个激光就是一个点，所有点集合到一起就是一副3D地图，这个运算量也是极大，AGV会把实时绘制的地图和地图模板匹配来进行定位，然后把这个位置告知后台就可以了。
c）通讯问题：就算大部分算法放入AGV中，但需通讯的数据也极多，就比如结果回传，AGV实时数据，任务下发，AGV操控，AGV设备告警等等，这些数据都是实时的，当单个AGV时还好，数量一旦过多，也会对后台造成极大影响，所以为此分离了整个后台，分为了站端 和 集控，站端主控现场，以完成某个区域的任务，集控统合所有，主要为数据展示、提取等工作。
d）交互问题：程序无论怎么设计，都主要是给人用的，而想把一整个工厂的环境完整的模拟出来并展示，光交给后端可不容易，想工厂地图方大缩小时，地图上的路径和点位是不是要变，工厂环境发生变化了，重新扫描了新地图，如何再展示页面更换？所以交互相关单独交给了前端。
四、总结
整体也没什么图，全是文字，就这样吧
主要是为了做个结束，在一个也是做一下记录吧。
标签：网页,站端,展示,--,地图,实时,openTCS,AGV,数据 来源： https://blog.csdn.net/qq_35449424/article/details/122251249