议定书
Cobotar- project 的原生取出的信息集
目前版本: 2.3.6
文档
在这里找到它: 文档/README.md
新版本
- 进行修改
make publish bump={patch,minor,major}
蟒
生成的 Python 模块从下方导入 cobotar_protocol
名称空间。 使用 Buf 生成的 SDK 索引安装软件包, 自此
生成的 Protovalidate 信件被寄存于此 :
python3 -m pip install \
--extra-index-url https://buf.build/gen/python \
cobotar-protocol
消费者只将软件包的父目录添加到 sys.path; 不添加
内在 cobotar_protocol/ 目录.
NATS科目
NATS科目的定义如下: subjects/catalog.yaml编辑
记录每个主题类型、原生有效载荷或请求/复制类型,
生命周期、合规状态、预定出版商和消费者。 创造的去,
C#, TypeScript, 和 Python 帮助者拒绝无效的混凝土主题符号和
为订阅提供明确的通配符。 实体路线家族
生成具体的信息意识路径和实体的通用助手
参数使用共享生成 EntityName 合同.
见生成 主题目录和命名规则。 。 。 .
运行 go run ./cmd/subjectgen check 验证目录,并验证所有
产出为当前产出.
大会进程的概念设计
A. 产品定义(是什么)
- 部件
- 组装/分组装
- 产品BOM/等级
- 部分事件/ 实例
- CAD / 三维模型参考
- 编组/ 连接提示( I)
B. 工艺模板(通常如何组装)
- 进程配方
- 序列 / 子序列
- 任务/ 操作/ 步骤
- 先决条件/订购/替代/变种
- 所需工具角色、技能要求、行为者制约
- 运算符文本
C. 执行案件(目前正在地板上发生的情况)
- 运行中的进程
- 序列/任务的现状
- 人类/机器人
- 开始/结束时间戳
- 目前车站
- 证据/完成/缺陷/推翻
D. 资源图书馆(可用于开展工作的内容)
- 人类
- 机器人
- 工具
- 固定设备
- 资产
- 站/单元格
- 模型
E. 能力层(为什么某一资源能够或无法完成某项任务)
- 技能
- 能力简介
- 工具角色
- 制约因素
- 有效性/培训/再培训/校准/认证
区分实例类型
示例: 编. 在组装中,我们通常需要:
- 部分定义:“M4x12螺丝”
- 部分发生:“本组装中的第三道M4x12螺旋”
因此,区分两者很重要,必须始终如一地予以支持和开展.
最小任务定义示例
TaskDefinition {
id: "task-fasten-cover-screw-1"
name: "Fasten cover screw 1"
instruction_text: "Fasten screw 1 to 0.8 Nm"
task_type: TASK_TYPE_FASTEN
target: {
target_node_id: "node-screw-1"
target_part_definition_id: "part-m4x12"
local_target: {
anchor_id: "node-screw-1"
}
}
tool_requirements: [{
role: TOOL_ROLE_APPLY_TORQUE,
required_properties: [TOOL_PROPERTY_TORQUE_CONTROLLED],
minimum_capability: {
min_torque_nm: 0.72,
max_torque_nm: 0.88
}
}]
skill_requirements: [{
skill_id: "SK-APPLY-CONTROLLED-TORQUE",
minimum_level: SKILL_LEVEL_QUALIFIED
}]
validation: {
require_tool_feedback: true
allow_manual_confirmation: true
manual_confirmation_min_level: SKILL_LEVEL_QUALIFIED
}
execution_policy: {
assignment_preference: TASK_ASSIGNMENT_PREFERENCE_EITHER
actor_constraint: {
allowed_actor_kinds: [ACTOR_KIND_HUMAN, ACTOR_KIND_ROBOT]
collaboration_mode: COLLABORATION_MODE_SEQUENTIAL_HRC
}
}
}
变式处理
变种类型
Bucket A——结构变体
感染出产树. 以产品为模型.
实例:
- 侧键
- 可选手柄
- 不同的紧身家庭
- 额外传感器模块
B-工作流程变体
影响任务/顺序/技能/工具/认证。 以配方适用性或配方分支为模型.
实例:
- 门必须翻转
- 需用胶合疗法
- 脆弱部分需要二人电梯
- 机器人只能组合一个方向
Bucket C-参数变体
不改变工作流程结构 。 跑步时通过.
实例:
- 颜色
- 语言
- 客户文本
- 批号
- 化妆品完成代码
处理没有食谱爆炸的变体
对于一个产品家庭,做这个:
-
一个产品定义
- 包含所有的结构可能性.
-
很少进程接收
只有在工作流程真正不同的地方才有分割的食谱. 例如:
- 食谱门标准
- 菜谱门被喷出
- 食谱-门-粘贴
没有 :
- 红-左-短手
- 红左长手
- 蓝-右-短手
- .
-
每个实际命令/建造一个进程运行
包含:
- 选定产品配置
- 运行时间参数
示例
产品维度
- 锁定 侧=左 右
- 颜色=红色 绿色 蓝色
- 手柄 = 短长
食谱
recipe-door-standard在下列情况下适用:- 手柄 = 短或长
- 颜色=任意
- 向左键( s)
recipe-door-flipped在下列情况下适用:- 锁定 侧=右
他们需要分成两种食谱 因为 right-hinge 需要一个 flip 操作和不同的固定.
进程运行
当真正的顺序开始时,选择可能是这样的:
product_selection:
hinge_side = right
color = green
handle = long
因此,系统选择 recipe-door-flipped 食谱和食谱无论如何保持不变 color。 。 。 .