某学长设计的水下机器人，其中机械、外形设计部分由老师完成，学长负责了全部控制系统与控制机械部分设计，上位机由另一个dalao学长负责。学长毕业跑路以后我负责接手这个项目，在原有规划上完成升级
主要由于个人技术欠缺和部分超前的设计，项目实现过程中遇到了很多典型问题，故在此记录作为笔记
机器人项目在GitHub仓库开源电路及软件部分，机械设计不开源
预期在原有机器人的人机协同、自主抓取功能基础上实现以下功能：
- 更稳定的内部电路
- 模块化隔离电源，将12V电源地与5V信号地隔开
- 基于OpenWrt的内部工控组网
- 两级STM32H750控制器
六推进器机器人（六轴），水平方向四推进器矢量布置，竖直方向布置双推进器，通过调节浮力保持机器人水平。内置一大容积收集框，且前部布置有传送带。整体机器人采用开放框架结构，预期能实现500m极限下潜深度，目前经过测试的最大下潜深度为100m。主机械臂设计为仿人手臂结构六自由度。
硬件方面采用了三舱设计——控制仓ControlCarbin、动力舱PowerCarbin、计算仓ComputeCarbin。控制仓内有一个stm32h750负责实时控制和实时算法解析，通过串口与上位mt7621路由器连接。动力舱部署有stm32h750与控制仓stm32通过串口连接，负责机器人所有pwm信号的控制。计算仓内有Jetson TX2计算板负责处理实时图像识别和自主抓取任务。
上位机搭载了空气开关作为总闸，220V经过线缆直接输送到下位机，同时220V直接供给工控机。工控机转出5V和12V为上位机的按钮、摇杆、旋钮及内部MCU供电。
220V在控制仓搭载的开关电源被转换成12V。电调直接使用此12V输出，另有一个功率控制板将12V转换成6V供给推进器和水下舵机。
功率控制板搭载一个继电器控制舵机供电，但推进器是始终连接到电源的
后续会对每一路推进器和舵机配备电流、电压、功率监控
12V电源经过隔离电源转换成5V、3.3V供给所有控制器件（mt7621和stm32），5V、3.3V与上述电源是隔离的，控制信号通过数字隔离器传出。
目前使用TI和ADI的高速数字隔离器（考虑到存在频率为100kHz开关频率以上的被控器件，低速光耦难以支持，高速光耦会占用大量板上面积），以后会考虑采用国产的数字隔离器
上位机、下位机和下位机控制仓、计算仓之间通讯使用百兆/千兆以太网，mt7621作为主交换机（为连接外网配置为路由器模式）。另有一个网络摄像头连接到路由器，TX2负责其他所有USB摄像头的数据采集和推流，上位机直接通过RSTP接收视频流
下位机控制仓、动力舱之间使用串口（TTL电平）通讯，速率设置为115200。传感器数据和主控数据使用不同的数据帧传输
以后会考虑统一传感器数据帧和控制数据帧
电调和舵机都接收500~2500us脉宽的50Hz（20ms周期）PWM信号；灯光接收10kHz以上的0%~100%占空比PWM信号。
控制信号由数字隔离器从stm32端发出传输给电调。
实时控制的计算（包括PID算法、传感器滤波、控制数据滤波）均在控制仓的stm32完成，动力舱的stm32只负责控制指令解析和舱内传感器数据采集
计算仓的TX2汇总单目、双目摄像头的数据，运算后转换成控制指令发送到控制仓。
上位机使用摇杆和按钮控制，所有控制信号使用Arduino的模拟（ADC）、数字（IO）输入接口采集，转换成串口数据后传输给上位机，上位机将其装换成TCP数据报，直接发送给下位机服务器。mt7621路由器上运行ser2net软件接收TCP数据，通过串口透传给控制仓stm32。控制数据经过初步解算出针对控制仓的指令后再转发到动力仓。动力舱的stm32解析指令转换成PWM控制信号。
控制指令也可以由计算仓的TX2发出，同样以TCP数据报的形式发送到路由器服务端。
这里没有使用UDP进行控制信号传输，后续会改为UDP协议
在设计过程中遇到了一大堆意料之中和意料之外的问题，摘录如下
最大的问题就是网口。mt7621的网络变压器电路焊接有问题，导致后续网络不通，排除了好久才发现是硬件的锅。虽然7621自带了phy，但是网络变压器的布线还是很重要，由于前期设计问题（一堆过孔）导致后面又修改了一版才能达到千兆速率。
传送带舵机的机械部分有过热的问题，应该是带载过大导致的，在这个项目中并没有修复（又不是不能用），考虑在以后的更新中加入过流保护功能并使用更大功率的舵机
再说说应该保留的优点
数字隔离器的部分简直就是神来之笔。在下水测试环节发现主臂的舵机防水性能不够，直接烧穿了功率电路，好在有数字隔离器抗住了12V的电压，最后更换了一个光荣牺牲的隔离器就让机器人恢复正常了（虽然挂掉了整个机械臂）。
软件方面最大的坑就是mt7621了，首先就是串口速率。刚开始用ser2net时配置为921600速率，发现发出数据是乱码，但ser2net明明支持更高波特率，直到后面查找芯片datasheet才发现这个问题是mt7621不支持更高的波特率，于是只能配置成115200波特率
mt7621还缺少新版linux内核的usb摄像头驱动，也不清楚怎么自己移植驱动、写设备树之类的操作，只能硬编译一套低版本的openwrt糊上去，虽然能用但是没法装mjpg-streamer，于是在openwrt上挂摄像头推流的想法直接失败。
之后换用了mt7688这个百兆路由器，虽然没办法传高清视频了，但又不是不能用，软件适配方面比7621好多了（笑）
stm32h750的指令解析和串口数据传输也有问题，主要在于数据传输时候要把uint32_t截成四个uint8_t，中间移位默认小端序，也就是右移才能截断数据，在程序里面反复调试截断方向后才发现这个问题。接收时候本来想用&0x00FF、&0xFF00的方式避免出错，但发现串口发送的数据正好在buffer里高低位颠倒，于是就只能改成左移了。之后的版本里面应该会统一一下罢
控制仓和动力仓的通讯使用串口，要求动力舱上传的传感器数据先发送给控制仓，与控制仓的传感器数据交替上传到mt7621；控制数据则通过mt7621下发到控制仓的stm32，进行初步解算后透传给动力舱。
在这个过程中，串口数据之间的分配就很重要。但延迟出问题了（悲）
传感器上传速率太快，而控制信号下传速率太慢，就导致控制数据传输会被打断。后面又加了一个控制数据防打断的补丁，保证了设备安全运行，但是这样传感器数据就会出现错误，导致上位机界面剧烈跳变。
在之后的版本中规划使用错时收发，并且把任务的延时调好，也许就能避免这些问题了
传感器遇到的一个大问题就是水深传感器的解算板gg了，本来自己设计了一套基于Arduino的解算板，测试时运行正常；但安装到板子上以后就不知道怎么回事无输出，调试一周无果就只能换传感器官方提供的解算板了。不过现在已经移植了一套程序到stm32f103上，虽然还没有用gd32试过但想必是可以用在下一个机器人上的。