Java无线点餐系统：Android+Tomcat完整跑通源码
2026/9/25 3:17:43
1. 拿到G1之后，为什么第一件事是搞定SSH而不是急着跑Demo
宇树G1这台人形机器人到手之后，很多人第一反应是赶紧上电、让它站起来走两步。我当初也是这个心态，结果折腾了半天发现，真正高效的开发方式根本不是抱着遥控器一遍遍试，而是先把SSH通道打通，把G1当成一台跑在局域网里的Linux主机来用。这个思路转变很关键——G1本质上是一台带关节的计算机，它的运动控制、传感器数据、日志系统全都跑在内部的Linux环境里，你只有拿到shell，才能真正看到它在想什么、在报什么错。
SSH（Secure Shell）在这里扮演的角色，就是你和G1之间那条加密的命令行通道。有了它，你可以在自己的Windows笔记本上敲命令，直接操作G1内部的文件系统、查看进程状态、修改配置文件、拉取日志，甚至做端口转发把G1的图形界面映射到本地。没有SSH，你只能靠官方App或者遥控器做有限的操作，调试效率差了一个数量级。
这篇内容面向的是刚拿到G1、准备做二次开发或者网络调试的工程师。不管你之前有没有用过MobaXterm，只要你会基本的Linux命令，跟着走一遍就能把连接跑通。我会把MobaXterm的配置细节、网络排查的完整链路、以及几个我实际踩过的坑都摊开讲，重点放在"为什么这么配"而不是"照着填就行"。
需要提前说明的是，G1不同批次的固件和网络配置可能有差异，下面提到的IP段、默认用户名、端口号都是基于我手头这台设备的实际情况，你拿到自己的机器后需要先确认一遍。这个确认过程本身也是网络调试的一部分，我会在第二节详细展开。
2. 连不上之前，先把G1的网络底细摸清楚
2.1 G1出厂网络配置的常见形态
宇树G1的网络接入方式通常有两种：一种是通过机身上的以太网口直接连路由器或者电脑，另一种是G1自己开一个WiFi热点让你连上去。两种方式各有适用场景，但调试阶段我更推荐有线直连或者走同一台路由器的有线网络，原因是WiFi的延迟抖动会让你在排查问题时多一层干扰变量。
如果你走有线，G1的网口默认大概率是DHCP模式，也就是说它会从路由器拿一个动态IP。这时候你需要登录路由器管理后台，在DHCP客户端列表里找到宇树相关的设备名，记下它拿到的IP。如果路由器后台看不到，可以用arp -a在Windows命令行里扫一遍局域网，找那个MAC地址前缀是宇树OUI的设备。
如果G1是AP模式（自己发热点），你的电脑连上它的WiFi之后，G1的网关地址通常就是它的SSH目标地址。这个地址在官方文档里一般会写，常见的是192.168.123.1或者192.168.1.100这类私有地址。我建议你第一次连接时先用ping确认可达性，再上SSH客户端，这样能把"网络不通"和"SSH服务没起来"这两个问题分开。
2.2 用ping和arp做第一轮连通性验证
在打开MobaXterm之前，先开一个Windows自带的cmd或者PowerShell，做两件事：
ping 192.168.123.1 -t这个-t是持续ping，方便你观察丢包情况。如果一直超时，说明链路层就没通，问题出在网线、网口协商或者IP段不匹配上。如果ping通了但有大量丢包，那可能是网线质量或者网口双工模式的问题，这种链路即使SSH连上了也会频繁断线。
ping通之后，再确认一下SSH端口是否开放。G1的SSH默认端口是22，但有些固件版本会改成其他端口。用Windows的Test-NetConnection可以快速探测：
Test-NetConnection 192.168.123.1 -Port 22如果TcpTestSucceeded显示True，说明SSH服务在监听，可以进入MobaXterm配置环节。如果显示False但ping是通的，那就要考虑SSH服务是否被禁用、端口是否被改、或者防火墙是否拦了。
2.3 确认登录凭据和权限模型
G1的SSH登录凭据在不同固件版本里不太一样。我见过的情况是默认用户名类似unitree或者ubuntu，密码可能是设备序列号后几位或者一个固定初始密码。这个信息一定要以你设备附带的文档或者官方发布说明为准，不要盲目试网上的通用密码，多次失败可能触发登录锁定。
登录进去之后，先执行whoami和id确认当前用户身份。G1上很多操作需要root权限，但默认登录用户往往不是root。这时候你需要确认sudo是否可用：
sudo -l如果这个用户有sudo权限，后面改网络配置、重启服务就方便很多。如果没有，你可能需要通过串口或者其他方式获取root权限，这个在量产机型上通常有官方途径。
提示：第一次登录成功后，建议立刻用
passwd改掉默认密码，并且配置SSH密钥登录，避免每次输密码，也降低密码被暴力破解的风险。
3. MobaXterm的配置细节：从新建会话到密钥登录
3.1 为什么选MobaXterm而不是PuTTY或者终端自带SSH
Windows上做SSH连接的工具有很多，PuTTY够轻量，Windows Terminal加OpenSSH也够用，但我长期用MobaXterm的原因是它把几件事整合到了一起：SSH会话管理、SFTP文件浏览、X11转发、串口连接、本地终端多标签。对于G1这种需要频繁传文件、看日志、偶尔还要跑图形化工具的场景，MobaXterm一个软件就覆盖了，不用在多个工具之间切来切去。
另一个实际原因是MobaXterm的会话保存和日志记录做得比较顺手。你可以给每台G1建一个独立会话，保存IP、用户名、密钥路径，下次双击就连上。它还能自动把终端输出保存成日志文件，这对排查偶发问题特别有用——机器人跑着跑着报了个错，你当时没注意，回头翻日志还能找到。
3.2 新建SSH会话的完整参数填写
打开MobaXterm，点左上角Session，选择SSH。弹出的配置窗口里，几个关键字段这样填：
- Remote host：填G1的IP地址，比如
192.168.123.1 - Specify username：勾上，填你的登录用户名
- Port：默认22，如果改过就填实际端口
- Advanced SSH settings标签页里，勾选
Use private key，指向你生成的私钥文件
这里有个细节很多人忽略：MobaXterm的Bookmark settings里可以给会话起名字，建议用"G1-机身编号-用途"这种格式，比如G1-001-调试，后面设备多了不会乱。
填完之后先别急着保存，点OK它会直接尝试连接。第一次连接会弹出主机密钥确认，选Accept并保存，这样后续不会再问。
3.3 配置SSH密钥登录，告别每次输密码
密码登录在调试阶段够用，但只要你开始频繁连接，就会觉得烦。更重要的是，很多自动化脚本和批量操作依赖密钥登录。生成密钥对在Windows上可以用MobaXterm自带的MobaKeyGen，也可以用OpenSSH的ssh-keygen。
我习惯用OpenSSH，因为生成的密钥格式通用性更好：
ssh-keygen -t ed25519 -C "g1-debug-key"ed25519比RSA更短更安全，G1上的OpenSSH版本只要不是太老都支持。生成过程中会让你选保存路径和passphrase，passphrase可以留空方便自动化，但如果你在意安全就设一个，配合ssh-agent使用。
生成之后，把公钥传到G1上：
ssh-copy-id -i ~/.ssh/id_ed25519.pub unitree@192.168.123.1如果Windows上没有ssh-copy-id，可以手动把公钥内容追加到G1的~/.ssh/authorized_keys文件里。注意权限：.ssh目录要是700，authorized_keys要是600，权限不对SSH会拒绝使用密钥。
注意：如果你在Windows上遇到
bad owner or permissions on C:\Users\xxx/.ssh/config这个报错，说明config文件或者.ssh目录的权限太开放。Windows下需要用icacls命令收紧权限，只保留当前用户的所有权。这是Windows OpenSSH的一个老问题，MobaXterm用自己的密钥管理时一般不会遇到，但如果你同时用系统自带的ssh命令就会撞上。
3.4 会话保存、日志记录和中文显示
MobaXterm保存会话很简单，配置完点OK之后，左侧会话列表里就会出现。右键可以编辑、复制、删除。建议把常用的几个G1设备都建好，按项目分组。
日志记录在Settings->Configuration->Terminal里，勾选Log terminal output to，指定一个目录。这样每个会话的终端输出都会自动存成文件，文件名带时间戳。排查问题时直接翻这些日志，比凭记忆靠谱。
中文显示方面，MobaXterm默认字体对中文支持还行，但如果遇到乱码，去Settings->Configuration->Terminal->Font settings，把字体改成Consolas或者Sarasa Mono SC这类等宽字体，字符集选UTF-8。G1上的locale如果没配好，也可能导致中文输出乱码，登录后执行locale看一下，必要时在~/.bashrc里加export LANG=en_US.UTF-8或者zh_CN.UTF-8。
4. 网络调试的完整排查链路：从ping不通到稳定连接
4.1 分层排查：物理层、网络层、传输层、应用层
网络问题最忌讳东一榔头西一棒子。我习惯按OSI模型从下往上查，每一层确认没问题再往上走。这个顺序能保证你不会在应用层折腾半天，结果发现是网线没插好。
物理层：网口指示灯亮不亮，网线是不是好的，换一根线试试。G1的网口如果有多个，确认你插的是配置为管理口的那一个。
网络层：ping通不通，arp -a能不能看到G1的MAC地址，IP段是否在同一子网。如果G1是192.168.123.x，你的电脑也得是192.168.123.x，不能是192.168.1.x。
传输层：Test-NetConnection测22端口，或者用telnet 192.168.123.1 22看能不能建立TCP连接。这一步通了，说明SSH服务在跑。
应用层：SSH登录报什么错，是认证失败还是协议协商失败。认证失败查用户名密码密钥，协议协商失败查SSH版本兼容性。
4.2 常见故障场景与对应处理
我把实际遇到过的几个典型问题整理成表，方便对照排查：
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| ping不通，网口灯不亮 | 网线故障或网口未启用 | 换网线，检查G1网口配置 |
| ping通但SSH连接超时 | SSH服务未启动或端口被改 | 通过串口登录确认服务状态 |
| SSH提示Connection refused | 防火墙拦截或服务未监听 | 检查iptables规则和sshd配置 |
| 登录后频繁断线 | 网络抖动或MTU不匹配 | 调整MTU，改用有线连接 |
| 密钥登录失败 | 权限问题或密钥格式不对 | 检查.ssh目录权限和密钥类型 |
| 中文乱码 | locale或终端字符集不匹配 | 统一设置为UTF-8 |
这个表不是穷举，但覆盖了八成以上的常见情况。遇到表里没有的，回到分层排查的思路，一层层确认。
4.3 用UDP网络调试助手辅助排查
有些问题不在SSH本身，而在G1上的某个服务通过UDP在通信，比如传感器数据流、遥控指令通道。这时候光靠SSH看日志不够，你需要一个UDP调试工具来抓包或者模拟发送。
网络调试助手这类工具（比如常见的v5.0.3版本）可以监听指定UDP端口，把收到的数据以十六进制或者文本形式显示出来。用法是：在G1上确认某个服务往哪个端口发数据，然后在你的电脑上用调试助手监听那个端口，看数据有没有正常到达、格式对不对。
这个手段在排查"G1说发了但上位机没收到"这类问题时特别有效。它能帮你区分是G1没发、网络丢了、还是上位机没正确解析。
4.4 连接稳定后的验证清单
SSH连上并且稳定之后，别急着关掉。花两分钟做几个验证，确认这条通道真的可靠：
- 连续执行
uptime和free -h，看响应是否稳定 - 用
scp传一个几十MB的文件，测传输速率和是否中断 - 开一个
top或者htop，观察一段时间，看会不会断 - 在MobaXterm里开第二个标签，同时连同一个G1，确认多会话没问题
这几步做完，你才算真正拥有了一条可用的调试通道。
5. 打通SSH之后，G1开发效率能提升在哪
5.1 文件传输：SFTP面板直接拖拽
MobaXterm连上SSH之后，左侧会自动出现一个SFTP面板，显示G1上的文件系统。你可以直接拖拽文件上传下载，不用记scp命令。传配置文件、拉日志、更新脚本，都是拖一下就完事。
这个面板的路径跟随终端当前目录，你在终端里cd到某个目录，SFTP面板也会同步过去。这个联动设计很省事，不用两边分别导航。
5.2 远程执行与批量操作
有了SSH，你可以写脚本批量在G1上执行命令。比如同时给多台G1更新配置：
for ip in 192.168.123.101 192.168.123.102 192.168.123.103; do ssh unitree@$ip "sudo systemctl restart g1-control" doneMobaXterm本身也支持"发送命令到所有会话"，在多个标签页打开的情况下，可以一次输入命令广播到所有连接的G1。这个功能在批量调试时非常高效，但用之前一定要确认命令是幂等的、安全的，别一个误操作把所有机器人搞挂。
5.3 端口转发与图形化工具
G1上如果跑了Web界面或者需要图形化的调试工具，可以通过SSH端口转发映射到本地。MobaXterm的隧道功能在Tools->MobaSSHTunnel里配置，把G1的某个端口转发到本地的某个端口，然后本地浏览器访问localhost:端口就能看到G1上的界面。
X11转发也是MobaXterm的强项。如果G1上装了带图形界面的工具，SSH会话里直接运行，窗口会显示在你的Windows桌面上。这个在跑一些可视化调试工具时很方便，不用额外配VNC。
5.4 日志集中管理与问题回溯
前面提到MobaXterm可以自动保存终端日志。结合G1上的系统日志（journalctl、/var/log/下的文件），你可以建立一个本地的日志归档习惯。每次调试会话的终端输出、关键的系统日志、当时的网络状态，都存到一个按日期命名的文件夹里。
这个习惯在排查偶发问题时价值巨大。人形机器人的问题往往不是每次都复现，等你回头想查的时候，现场已经没了。有日志在手，至少能还原当时的状态。
6. 几个我实际踩过的坑和对应的处理经验
6.1 IP冲突导致的间歇性断连
有一次G1连上路由器后，SSH时通时断，ping也丢包。查了半天以为是网线问题，换了两根线还是一样。最后在路由器后台发现，G1拿到的IP和另一台设备冲突了——DHCP分配出了岔子。解决办法是给G1在路由器上绑定静态IP，或者在G1上配静态IP，避开DHCP池。
这个坑的教训是：调试阶段尽量用静态IP，减少变量。动态IP适合最终部署，不适合调试。
6.2 SSH密钥权限在Windows上的坑
前面提到的bad owner or permissions报错，我遇到过一次。原因是Windows上.ssh目录的继承权限没关掉，导致其他用户组也有读权限。用icacls修复的命令是：
icacls C:\Users\你的用户名\.ssh /inheritance:r icacls C:\Users\你的用户名\.ssh /grant:r "你的用户名:F"对config文件和私钥文件也要做同样处理。这个操作在Linux上就是chmod 600，但Windows的权限模型不一样，得用icacls。
6.3 MobaXterm会话在换网络后失效
MobaXterm保存的会话绑定了IP。当你把G1从一个网络搬到另一个网络，IP变了，会话就连不上。这时候要么改会话里的IP，要么用主机名。如果G1的hostname能通过mDNS或者本地DNS解析，用hostname建会话会更灵活。
我现在的做法是给每台G1在路由器上配静态IP加本地DNS记录，会话里用hostname，这样换网络只要DNS跟着变就行。
6.4 长时间会话被服务端断开
SSH服务端通常有ClientAliveInterval和ClientAliveCountMax配置，空闲太久会被断开。G1上如果sshd配置比较激进，你可能挂机一会儿回来发现会话没了。解决办法是在MobaXterm的会话设置里勾选SSH keepalive，或者在G1的/etc/ssh/sshd_config里调大保持连接的参数。
MobaXterm的keepalive设置在会话配置的SSH标签页 ->Advanced SSH settings->SSH keepalive，勾上之后它会定期发心跳包，防止被断开。
6.5 多台G1同时调试时的会话管理
当你手头有三五台G1要同时调试，MobaXterm的会话列表会变得很长。我的做法是按项目或者按批次建文件夹分组，会话名带编号。另外，MobaXterm支持多窗口模式，可以把不同G1的会话拖到不同窗口，配合Windows的分屏，一台屏幕看多台设备的状态。
如果设备数量再多，就要考虑用tmux或者screen在G1上跑持久会话，SSH断了也不影响里面跑的任务。这个在跑长时间测试时特别有用。
7. 把SSH通道变成G1开发的常规基础设施
SSH连上G1只是起点，真正有价值的是把这条通道变成你日常开发流程的一部分。我现在的工作习惯是：每天早上到工位，先MobaXterm连上所有在用的G1，开好日志记录，然后才开始当天的调试或者开发。所有操作都在SSH会话里做，所有输出都有日志留档。
这个习惯带来的好处是，任何问题都有迹可循。G1什么时候报的错、当时在跑什么、网络状态如何，翻日志就能还原。人形机器人的调试本来就复杂，能减少一个变量就减少一个。
另外，SSH密钥和会话配置建议做一次备份。换电脑或者重装系统时，把这些配置恢复回去，能省不少重新配置的时间。MobaXterm的配置可以导出，密钥文件单独存一份加密备份。
最后分享一个小技巧：MobaXterm的Macro功能可以录制一串命令，绑定到快捷键。比如你每次连上G1都要执行的那几条检查命令，录成一个宏，一键跑完。这个在重复性操作多的场景下能省不少事。