<aside> 📅
更新hb_edge边缘端的【真机融合版】功能开发。今天主要针对set_arm_enable双臂使能/断电、both_arms_cmd双臂控制、arm_dexterous_cmd灵巧手双手控制，三项逻辑进行重塑梳理，重构优化原有逻辑，并结合原始CR100的底层代码以及dh提供的真机调试版代码，进行融合性详细优化。加入多项安全逻辑规则，并且对齐dh提供的开发中版本。各项功能仍在持续中，逐一梳理功能逻辑，既要确保符合CR101重构公约，又要符合真机版生效业务逻辑。仍在继续中。
根据hb_edge的【真机版融合开发】升级，同步更新了后端hb_server的接口API以及路由，同步对行为树的部分mock模式功能，渐进式开放部分已经对齐的功能逻辑（机械臂双臂两项、灵巧手双手一项）。同时更新前端的功能规则，并且更新mock基线版。
CR101中云边双端项目（hb_server、hb_edge）进行了扩展升级，因此对前端的UED的【机器人控制台】界面局部进行了逻辑升级。增加了【先使能、后控制】的安全规程逻辑，既提供调试面板，又确立了固化后的局部安全策略。
</aside>
<aside> 📅
继续进行【真机融合版开发】，增加了【CR100 & dh真机调试版】的双向交叉验证的渐进式开发。截止目前，真机版的17function已开闸6项function（cmd_vel、chassis_ctr、rotate_pill_box_ctrl、robot_relocalization、arm_dexterous_cmd、both_arms_cmd），其余11项受理即拒桩。同时新增4 handler，创建了117个测试点，遵守CR101公约进行真机版融合升级开发。目前117 passed无回归，确认已开发的内容理论可通，需要近日完成封版后，将公司内网全系升级后再测试真机运行情况。
继续进行【机器人本体Pad端】的开发工作，真机版在更新基础UI框架时，适配机制存在缺陷，会导致白屏，已完成基础能力的修复。已经搭建了登录功能，并且开发环境可连接本地hb_server，生产环境可连接ACP Lite Server（云端hb_server）。并且云打包签名和功能也基本固化，可以顺利覆盖。已更新APK的ICON和名称，底层安卓配置缺陷也解决。并且对当前基线版本打上前置版【v0.1.0-mock-baseline】Tag，以便后续复用和回退。
CR101重构项目【机器人本体Pad】，延续使用了以前的UI素材，搭建了基础UED版本。并且已经延续样式，在hb_robot_app中实现了界面重构，尽量保持视觉风格与原版统一。Icon图标与UE交互保持一致。可以正常打包输出素材，无异常。UED的六项功能页，目前仅占位，需要等待重构模块完成后，再继续推动开发。
对组内成员张斌提供的LLM-TTS的独立版进行分析和沟通，提供了后两个阶段的开发目标。930前除了具备此前【UCloud本地部署版】之外，还需要扩展支持【云端API部署版】；【企业自购服务器硬件本地部署版】则需要探索+验证+优化硬件配置，以实现硬件与AI模型之间理想平衡点。同时规划初步确定，AI模型+工作流的方式，处理知识库问题，缓解向量数据库为全双工造成的延迟压力（需zb测试验证，但解决方案我已提供）
</aside>
<aside> 📅
根据已经梳理的【真机融合版开发 - 22步骤】的开发计划，渐进式针对细节进行对齐式开发。其中涉及到CR101已经完成重构的部分，进行了对齐开发工作，对“hb0820/hb_edge”版本中存在的一些有违CR101架构公约的地方进行调整，改写为公约规则，边调试，边合并。按照三端同时更新的方式进行融合开发。并且在整体开发计划之前，标注了【v0.1.0-mock-baseline】的Tag。目前仍处于验真+改造+融合的开发工作。
CR101的重构开发工作，搭建了一条分支开发小组，进行Pad端的安卓集成软件的开发。拟将原版安卓原生Flutter重构开发。并且已经实现长线P0的开发工作基础建设，P1阶段的部分工作内容。搭建了H5和安卓APK双版的基础框架，制作了一套用于未来发布使用的安卓签名文件，成功实现H5编译+安卓APK打包的操作。同时，额外租用云手机服务，模拟真机安卓10/安卓11的系统环境，进行部署和安装，解决了【安卓APK - Pad版】专属底层能力开发，解决了【安卓签名可叠包覆盖安装】的专项基础能力。
CR101重构计划中已纳入Pad端的安卓APK的开发计划，因此针对hb_robot_app的交互UED进行了初步梳理。一方面尽量保留原有的UI素材和交互界面，一方面复用UED为了快速步入路由和API的模拟环节，需要通过开发来验证全盘重构的可行性。
</aside>
<aside> 📅
8月内的CR100→CR101的整体系统级架构、截止目前的开发进度，向刘总整体汇报与同步，并且详细介绍了系统设计细节。包含【医院基础信息底座】、【医院HIS系统的功能模块】、【医院HIS系统Mock数据库模拟搭建成果】、【机器人/药站 - 设备管理设计思路】、【设备控制台】、【药站/药箱/药箱格子/药包/药 全套结构设计】，以及云边工作进展情况的综合汇报。
根据dh提供的真机模拟版“hb0820/hb_edge”，进行工程综合分析与解构，用于提取其中【真机驱动生效环节】的代码，按照CR101三端的公约进行“真机融合版开发计划”的设计与整理。周五周六梳理出共计22渐进式步骤的行动融合清单。截止周日，完成前9项，并且修复大量公约类和对齐类问题。同时hb_edge的后半部分的更新内容，受限于CR101三端的重构进度，因此预计进行到部分环节时需要暂停。目前继续开发中。
CR101重构项目，云端通讯的function进行优化和梳理，由于dh版的“hb0820/hb_edge”增加了新的function，因此在详细分析完代码后，最终根据功能语义，计划合并入原版CR101的17项function内。其中【底盘ctr】和【表情】等功能，已经在CR101三端建立公约通道，因此模拟两次融合开发后，最终重构这部分功能，主要保留dh提供的【真机版生效部分】的代码。
</aside>
<aside> 📅
与省人医2位对接进行【业务对接】和【技术对接】，已确认省人医的“宣教内容”的制作和录入后台，统一使用内网后台上传、编辑、设置类型标签。由宣教功能第三方技术服务团队开发的【济世大脑】承接数据管理和维护，设立【内网版+外网版】两部分，内网供院方人员使用，外网版发患者查阅。 经沟通将此前对接问题一次性梳理清晰。未来我们与三方团队的【济世大脑】对接1次即可，院方收益可不用改变后台录入流程，我方可统一对接一处数据即可完成CR100宣教业务落地。由于【技术人员】此前对CR100需求不清楚，今得知有对接需求后，近期会评估API接口开发工作量。（暂时处于省人医和三方技术团队为提供对接资料，今日刚得知对接需求，院方正式启动宣教工作）。后续根据院方反馈和提供的对接资料，再进行专项开发。
CR101重构项目，前后端的各项msgType链路的梳理和开发。目前2.5代CR101延续了CR100的通讯msgType编号，但是由于CR101通讯机制更简洁，因此部分链路需新定义编号和组装，部分新链路采用新编号区段。老的较多编号也进行适度合并更新。
CR101项目云边架构中，我们预规划了边缘端的Python项目hb_edge。截止7月31日设计了hb_edge架构模式和协程流水线。但是没有装入业务。如今CR101整体进入已经步入【设备总线】的开发环节，因此开始梳理hb_edge边缘端的详细架构以及准备进阶开发的前置规划工作。
</aside>
<aside> 📅
CR101重构项目，继续根据重构后的机器人本体模块化数据结构，以及新版药站的全新数据结构的方式，进行前后端的数据结构、路由、接口、UED方面的正常开发工作。
根据新版本机器人控制台的功能和数据结构，将机器人控制台拆分为四大模块：底盘操作面板、机器人状态、机器人控制、常规msgType通讯。主要考虑到未来机器人的三代和通用化的发展需要，提前对机器人基础能力进行重新拆分。既满足业务需要，也能在未来快速搭建通用版框架。
开发CR101的hb_server新路由和接口，以及hb_admin管理后台的【设备列表】新功能和交互，以及更新了【药站座舱控制台】的交互设计，将设备相关新四表和药站药箱的功能重新组装开发。
</aside>
<aside> 📅
CR100→CR101重构计划，顺利完成全新设备管理底座基础框架设计和落库。【机器人本体】和【药站底座】采用同源终端设计模式，设备层同源数据管理，通讯层同协议管理，交互界面层合并为两大控制台模式。【药箱】与【机器人任务】从原有粘连的数据结构完成全新解耦，各自独立运转，数据自治。【药箱格子】分配了独立事件化管理，将旧项目CR100只临时存储【药包】的方式，进化为带有单槽日志清单的管理模式，更具业务延展性。不仅支持未来扩展多规格药箱，而且独立药箱格子slot也有独立的历史留痕。明日针对机器人本体控制台和药站本体控制台进行权限管理和实时控制与开发。
完成【设备管理】的二次升级（包含机器人本体硬件管理+药站硬件管理）；完成【药箱管理】的全新UED交互设计与开发；完成【药箱格子slot管理】的UED交互设计与开发；引入了【药箱格子历史事件】的交互内容呈现，未来每个药箱格子的使用记录将有独立模块维护，一旦某分支业务出现需追溯的问题，CR101可通过交互界面找到历史操作记录。药箱和药箱格子的2状态和4状态，升级为6状态。
CR101重构项目，hb_server的后端路由扩展出曾经没有的【药箱格子slot】工厂管理路由；后端经过四轮工程任务，顺利完成对CR100高紧密依赖的粘连API接口的重构，目前已将重构版CR101的设备相关数据，顺利对接【医院基础信息】和【医院HIS数据】两大板块，并且分离后续还未重构的任务、地图两大模块。这两部分在接下来的时间内会相继就绪重构和开发。
</aside>
<aside> 📅
CR100→CR101重构计划，重新设计三类硬件的数据结构。对于设备通讯和定位做了重大调整！为了确保云边责任制，必须要重新调整原CR100方案中责权粘连，数据混存，协议混用的情况。重点在重新设计【设备总表】（需要同时兼容机器人本体和药站硬件），两类都具备长连接需求，两类设备都具有座舱Bay，两类设备都高度依赖区域管理。同时还在重制【药箱Box】+【药箱格子Box_slot】+【药箱格子管理】相关功能，既结合通讯架构逻辑，又兼顾当前三类硬件本体构造和目前能支持的底层协议。
重点分离【药站Pad】和【机器人本体Pad】的通讯路线底层开发设计。由于旧项目CR100的开发采用Flutter方式，底层直驱，加之都是Pad端的APK，因此无论界面交互还是通讯协议，基本是孪生打造。 CR101重构改造中进行了调整，依据是【机器人本体Pad】本身仅网络通讯不调用底层硬件(不走嵌软/不调ROS），然而【药站Pad】端却强关联底层JNI调用，直接迈入MCU级别的药站+药箱+药箱格子的多硬件驱动控制，因此立足与功能归属，角色定位，以及硬件契合度，将【机器人本体Pad】列为控制端，未来做输入和状态同步的功能；而密不可分的【药站Pad】由于无法中间增设任何计算板作为边缘端容器，只能将【药站Pad】的安卓程序本体定位成边缘端程序，和药站硬件整体做"hb_edge"的角色，只不过wss需要在安卓环境下重新写一遍。因为硬件架构这个环节没有边缘板，所以如此调整虽然系统工程过度改变形态来适应硬件架构，但这样的调整可以为稳定性带来很大提升。因此截止今晚，基本验证和敲定这个结果。
由于设备管理的四项数据表进行重构设计，因此设备管理相关的页面UED设计进行同步修改和调整。设备管理调整主要是字段对齐类型，机器人控制+药站控制，则会进行一轮全面升级。正在进行中。
</aside>
<aside> 📅
搭建HIS模拟系统，结合CR101全新数据底座（包含医院基础信息1区域+4枚举+1房间+1床位全系），以及HIS全新数据底座（围绕住院流水表+患者表作为主沉淀，腕带码+药包码作为输入智能计算，药包+药品双库隔离自制）。搭建独立MOCK_HIS系统数据源。共计迭代了四轮开发，共计构建2450患者数据，3000住院行为记录，3000药包记录。并且完成了HIS模拟系统的双API接口，可无限自行联动注入医院业务，让整个场景业务数据彻底解放数据困境，自主自由调用数据。
CR101重构项目，双底座功能开发完成。双底座主要是CR101自主【医院信息数据】业务全流程全新底座，以及【医院HIS系统信息】源数据管理系统源。现阶段完全可以自主创造高度仿真业务数据，即便在无接入医院HIS的情况下，创造完全自循环业务生态。区域管理（针对机器人）、医院基础信息四枚举管理（扁平化可插拔嵌入医院复杂业务数据）、房间与床位双匹配数据（面向机器人未来行动逻辑必判断的嵌套式场景单元）。受数据来源有限之故，因此进行大量智能逻辑判断，以便在数据残缺、信息异步、患者出示错码、医院HIS发生突发更新等情况下，具备缓冲能力。确保机器人行动异常错误问题尽量降低与减少影响。
【医院基础信息】和【医院HIS系统信息】两套一级模块的UED设计暂时完毕。共9套UED交互页面内容。不仅包含基础数据连通性，页面样式一致性，而且最列表列项列宽进行了适配优化，对交互细节规则进行了潜在问题修复。同时两大套UED模块的开发后，因还有三大部分的UED需要进行。下周开始针对三类设备（机器人本体、药站、药箱…等）进行UED设计。
根据省人医对接，已将获取的【药物医嘱类“宣教”】信息和【住院流水信息】的数据，对接确定了功能范围。同时和省人医对接人核实确认此前对方提供的HIS系统API接口的保鲜度和准确性。（对于CR101来说很重要）
</aside>
<aside> 📅
完成CR101重构项目中，承接内外数据关键枢纽底座（原计划三表已升级四表）：患者表（快照属性）、住院流水表（核心业务流）、药包表（沉淀映射型）、同步缓冲表（自学习能力）。特别之处主要是【住院流水表】，作为CR101项目，我们并不是医院HIS替代架构，真正数据资产管理并非是每一名患者究竟如何。而是机器人行动场景的数据变化！因此每位患者个体来到住院就医，对于机器人来说才是真正的【独立数据片】，因此这个环节的重构，将业务架构底座完全重塑，更适配机器人业务场景。
CR101项目有两处Pad端，机器人本体Pad和药站硬件Pad。原CR100旧项目采用Flutter的方式开发，导致项目后期无人能够高效迭代开发，只能局限更新。因此CR101重构项目计划中，两个Pad端都会全新规划架构，重新开发设计。其中机器人本体Pad大部分属于通讯连接类，可优先启动规划和框架开发，而药站硬件Pad端设计JIN底层驱动调用，可能会伴随需要自主研发穿透底层硬件的插件工作（难点），因此后置。
根据和省人医对接，获取了一份【宣教】的数据表格。大体可根据基础数据了解医院宣教素材的存储形式。现阶段带来的帮助是，hb100_db可基本对齐创建自有宣教数据表（易对齐数据），但问题是依然没有拿到具体【宣教素材的类型和素材内容形式】。继续对接。
</aside>
<aside> 📅
</aside>
<aside> 📅
</aside>
<aside> 📅
</aside>
<aside> 📅
</aside>
<aside> 📅
</aside>
<aside> 📅
</aside>
<aside> 📅
</aside>
<aside> 📅
</aside>
<aside> 📅
</aside>
<aside> 📅
</aside>