人形机器人放无人机,还能上天入海!有点过于赛博了吧

金磊 发自 凹非寺
量子位 | 公众号 QbitAI

现在的人形机器人啊,真的城会玩儿了。

这不,他们已经开始放!无!人!机!了!

你没听错,画面是酱紫的:

这还不算完。

这个被机器人放飞的无人机,飞着飞着,竟然开始潜水了!

以为是哪家机器人独角兽搞的花活儿?

No,No,No。

这场机器人和无人机联动的背后,正是中国电信 TeleAI

这一次,由中国电信集团CTO、首席科学家、中国电信人工智能研究院(TeleAI)院长李学龙教授团队领衔,直接甩出了一套具身智能组合:

  • 首款自研人形机器人:TeleBot-M
  • 全自研空海跨域具身智能体:TeleAqua-Bee

或许在大众的印象里,中国电信的形象还停留在拉网线、办宽带、通信号;但恰恰就是这家最懂通信的运营商,正在试图解决具身智能领域目前最大的隐形成本——协同与传输。

毫不夸张地说,机器人放无人机,实则是中国电信一次 “端-边-云”全栈自研体系的总验收。

机器人怎么放好无人机?

在“机器人放无人机”这个场景中,“机器人”和“无人机”,这两个本体自然是技术中的关键。

中国电信首款自研人形机器人
TeleBot-M

从外观上来看,它和那些全尺寸金属外壳的人形机器人不同,为了把TeleBot-M亲和力拉满、机身做小,同时在与无人机协同时,实现操作性和轻量化的完美平衡,团队将TeleBot-M的上肢简化到单臂4自由度,而下肢则保留单腿6自由度的设计,使其跑跳稳如老狗。

为了支撑这副躯体,TeleAI给它装上了一套自研的高性能神经系统TeleBotOS。这套系统对底层电气拓扑进行了重构,采用了自研创新的机器人嵌入式控制框架,为同时实现身体平衡控制和放飞指令发出提供了可靠的系统基石,实现不抢算力、不卡顿,无论后台任务多重,机器人的运动控制始终连贯精准。

TeleBot-M之所以能如此听话,离不开一颗由5000万条仿真数据喂出来的自主大脑

它依托业界首创的纯仿真评测平台NavGBench,在由世界模型TeleWorld生成的超5000个高保真3DGS虚拟场景中持续强化学习,打破了固定规则束缚,获得了在复杂动态环境中自主决策、路径规划与任务拆解的能力。

此外,TeleBot-M的小脑也值得好好说道说道。它引入了上下肢课程式对抗强化学习,研发团队在训练中故意给它的上肢施加随机干扰,就像有人在推搡它一样。

即便TeleBot-M机器人的上肢受到剧烈扰动,它就像练了太极似的,下肢依然能保持高鲁棒性,甚至还能同时完成毫米级的轨迹规划。

这套大小脑协同的认知体系,让机器人不仅能看懂世界,更能想明白该做什么。如果说小脑负责运动协调与抗扰平衡,大脑则掌舵全局思考,让TeleBot-M真正成为“有脑子、能进化”的具身智能体。

上天入海的TeleAqua-Bee

从外观上来看,它只有巴掌大,不足1kg,是可以直接塞进背包的那种。

它的桨叶还自带保护罩,不仅为了安全,更是为了适应复杂的流体环境。

TeleAqua-Bee最大的亮点是涵道推进器水空两用

在天上,它是无人机,续航10分钟;一头扎进水里,它就是潜航器,能潜航30分钟,最大潜深10米。

并且不只是防水那么简单,TeleAqua-Bee具备水面自回正功能,甚至能在水下稳定悬停。

除了Bee(掌上交互版),TeleAqua其实是一个家族:

例如TeleAqua-H8,主打一个“快速响应+高负载”,能扛5kg负载,空中续航15分钟,水下续航长达1小时,10米最大潜深应对长时间原位观测完全没压力。

TeleAqua-H4Z可以折叠机臂,水下航速超2m/s,专钻狭窄空间。

最后的TeleAqua-Edu,专为二次开发打造,是首款可分舱拼接的四轴飞潜航行器。

如此一来,TeleAqua家族系列的空海跨域具身智能体便全方位地覆盖了低空、水面和水下。

机器人和无人机介绍完了,接下来的问题就是,怎么连接

智传网(AI Flow),了解一下

在实验室里连根线当然容易,但如果是在远洋货轮、深山老林,或者信号只有一格的救灾现场呢?

这就触及到了中国电信的核心护力。

机器人和无人机算力是分开的,但数据流绝不能断。为此,TeleAI从理论到工程系统化布局了智传网(AI Flow)架构,而生成式视频压缩技术(GVC)正是智传网(AI Flow)信容律理论落地最硬核的一把尖刀。

智传网(AI Flow)不是简单的物联网,它是基于“信容律、同源律、集成律”三大定律构建的智能分发网络。

GVC则把信容律“用计算换带宽”的理念推向极致——传输语义与运动Token,而非像素本身。传统视频编码搬的是画面,GVC传的是经过高度抽象的语义特征。

原生1GB视频压缩至200KB,压缩率干到惊人的0.02%,靠的正是这种“像素不进网,画面靠生成”的代际革命。

这是TeleAI从2024年就开始布局的理论地基。

在这个架构下,端-边-云不再是割裂的:

  • 端侧(机器人/无人机): 小模型负责即时反应,比如避障、保持平衡。
  • 边侧:边缘节点负责实时决策与任务调度,在靠近现场的位置完成异构指令融合、多智能体协同,既减轻云端压力,也守住毫秒级响应底线。
  • 云侧: 大模型负责全局规划,比如“去哪里搜救”、“路线怎么走”。

TeleAI下的一盘大棋

看到这里,你可能明白了。

TeleAI花了两年时间,织出了一条清晰的技术路线:智传网(AI Flow)、人形机器人、跨域潜航器。

今天展示的“机器人放无人机”,就是这两年织网收上来的第一网鱼。

这不仅仅是具身智能和水下具身智能设备之间的连接与交互,而是为异构具身智能本体之间构建了一个紧密协同的社群。未来,空中无人机、地面机器人、水下潜航器与云端大脑将通过智传网(AI Flow)实现无障碍沟通与协作,每一个智能体既是独立的个体,又是群体智慧的无限延伸。

民企做机器人,卷的是运动性能、卷的是BOM成本。而中国电信TeleAI 做机器人,卷的是“云网融合+AI原生”

TeleAI的选择也非常清醒:

首先就是最苦、最险、人最不想去的地方。

想象一下这样的场景:洪水冲断了道路,地震堵死了大门,或者深海光缆需要检修。

以前,是救援人员冒着生命危险,赌运气往里冲。

现在,TeleBot-M作为先遣队员,背着TeleAqua进入毒气弥漫或极度缺氧的区域。遇到水域阻隔,TeleAqua起飞、入水,钻入狭窄的水下空间。

借助智传网(AI Flow),哪怕基站全损,只剩微弱的卫星信号,指挥中心依然能通过指令重绘,看清现场的每一个细节。

而且不仅是抢险救援,比如临地安防、城市管理、工业巡检、海洋勘探相关等等,反正这种人干有危险或者不好实现的场景,就可以派它们去。

传像素是19世纪的思维,传指令才是未来的逻辑。

这不仅是两个设备的物理连接,更是有温度的科技。

正如TeleAI所期望的那样:

替人赴险的勇气,守护生命的底气。

有了这对具身智能搭子:险地可闯,困境可破;生命有托,希望不落。

还有,从一个机器人+无人机,其实这是一个起点,我们所看到的是群体智能的未来。

这,或许才是硬核科技最大的浪漫。

Read more

Java Web 公交线路查询系统系统源码-SpringBoot2+Vue3+MyBatis-Plus+MySQL8.0【含文档】

Java Web 公交线路查询系统系统源码-SpringBoot2+Vue3+MyBatis-Plus+MySQL8.0【含文档】

摘要 随着城市化进程的加速,公共交通系统的复杂性和规模不断扩大,传统的公交线路查询方式已难以满足用户高效、精准的出行需求。公交线路查询系统的开发旨在解决这一问题,通过信息化手段提升公交出行的便捷性和智能化水平。该系统整合了公交线路、站点、换乘等关键信息,为用户提供实时查询、最优路径推荐等功能,同时优化公交资源管理效率。关键词:公交线路查询、智能化出行、信息化管理、SpringBoot、Vue3。 本系统采用前后端分离架构,后端基于SpringBoot2框架,结合MyBatis-Plus实现高效数据持久化操作,MySQL8.0作为数据库存储公交线路、站点及用户信息。前端使用Vue3构建响应式用户界面,提供线路查询、换乘推荐、站点导航等功能。系统支持多条件筛选和动态路径规划,确保用户能够快速获取最优出行方案。关键词:SpringBoot2、Vue3、MyBatis-Plus、MySQL8.0、路径规划。 数据表 公交线路数据表 公交线路数据表用于存储公交线路的基本信息,包括线路名称、运营方向、首末班时间等属性。线路编号是该表的主键,用于唯一标识每条线路。结构表如表3-1所示。

轻松搭建个人WebDAV文件服务器:小白也能快速上手

轻松搭建个人WebDAV文件服务器:小白也能快速上手 【免费下载链接】webdavSimple Go WebDAV server. 项目地址: https://gitcode.com/gh_mirrors/we/webdav 还在为多设备间文件同步而烦恼吗?想要拥有一个安全可靠的文件共享平台吗?这个基于Go语言开发的WebDAV服务器正是你需要的解决方案。它简单易用、功能强大,让你轻松搭建专属的文件管理服务。 🎯 快速上手:三种部署方式任你选 方式一:一键安装(推荐新手) # 使用Homebrew安装 brew install webdav # 使用Go工具链安装 go install github.com/hacdias/webdav/v5@latest 方式二:Docker容器化部署 docker run -p 6060:6060 -v $(pwd)/data:/data

微信 H5 缓存控制:后端重定向 & 前端强制刷新

在 Web 开发中,缓存是一把双刃剑。对于静态资源,它能极大提升加载速度;但对于业务逻辑频繁变动的 H5 页面(如支付、订单页),缓存往往会导致用户看到过期的数据或界面。最近在维护一个 uni-app 项目时,遇到了一段关于 H5 缓存控制的逻辑,引发了我对于“后端重定向加时间戳”和“前端 JS 加时间戳”这两种方案的思考。虽然两者的最终目的一致,但在 Hash 模式下,它们的实现原理和效果有着本质的区别。 一、 问题背景 在应用启动的生命周期中,通常会有这样一段逻辑:当用户访问特定的关键页面(如支付、订单页)时,如果当前 URL 中缺少时间戳参数,前端会自动解析 URL,追加当前时间戳,并强制页面刷新。 这就引出了一个问题:为什么不直接在后端重定向时加时间戳?这两种方式有什么区别? 二、 核心区别:

AI 时代,前端逆向的门槛已经低到离谱 — 以 Upwork 为例

我用 AI 逆向 Upwork 消息系统,2小时搞定数据层开发 前言 作为 Upwork 自由职业者,我一直觉得它的消息管理界面信息量太大,不够直观。我想做一个 Chrome 插件来简化消息管理,核心需求很简单:一眼看出哪些对话需要我回复,哪些在等对方。 传统做法是下载混淆后的 JS 文件慢慢分析,但这次我决定换个思路——全程和 AI 配合,看看能多快搞定。 结果远超预期。从零开始到完全摸清 API、认证方式、数据结构,总共不到 2 小时。 第一步:摸清技术栈(5分钟) 打开 Upwork 消息页面,F12 看 Sources 面板,从加载的 JS 文件名就能判断出技术栈: ThunderNuxt/rooms.fdb6ff58.