每天3000万+的叫车需求,滴滴派单算法如何应对?

【VRP】类型总结和DVRP分析(一) 💡原因二:开放车辆路径问题的特点是配送车辆完成任务后不一定回到配送中心,所以车辆的计划路径可能是一条路径,而不是一个简单圈。当前正在执行任务的车辆已离开配送中心,且被要求配送完成后回到配送中心,所以此时这些车辆的配送计划路线必定为一条路径,与HOVRP无异。上述4中情况均有正在执行任务的车辆,因此会等价于求解同一个问题,即多车型的开放车辆路径问题(Heterogeneous Fleet Open VRP,中的元素确定为该集合中已服务完成的顾客,未服务顾客提出集合,并且该集合不再更新。 阅读详情

导读:说到滴滴的派单算法,大家可能感觉到既神秘又好奇,从出租车扬召到司机在滴滴平台抢单最后到平台派单,大家今天的出行体验已经发生了翻天覆地的变化,面对着每天数千万的呼叫,滴滴的派单算法一直在持续努力让更多人打到车,本篇文章会着重介绍我们是如何分析和建模这个问题,并且这其中面临了怎样的算法挑战,以及介绍一些我们常用的派单算法,这些算法能够让我们不断的提升用户的打车确定性。

1.为什么我们需要更好的派单算法

说到滴滴的派单算法,大家可能感觉到既神秘又好奇,从扬召到抢单到派单,我们又是如何演进到今天大家的打车体验的呢,我们首先来看一看,好的派单算法为什么是出行行业不可或缺的能力?

回想几年前,当我们还没有滴滴的时候,只能在寒风或者酷暑中等待可能有、可能没有的扬招出租车,到后来可以从滴滴上呼叫一辆出租车,乘客可以在室内相对舒适的等待车辆的到达,从线上到线下,乘客的确定性得到第一次的提升,然而这还不够,抢单的模式注定我们的应答率天花板不会太高,在15年,滴滴上线快车业务,我们从抢单演进到了派单模式,乘客的应答率有了20个点以上的提升,很多时候能够全天能够高达90+(高峰&局部供需紧张应答率会相对吃紧),乘客确定性再一次得到大幅的提升,由此可见,派单模式为滴滴创造了巨大用户价值。

再看近年来不断兴起的O2O业务,从国内外的网约车公司,包括我们的友商Uber、Lyft都基于派单的产品形态进行司机和乘客之间的交易撮合,Uber上市的时候把派单引擎也作为核心技术能力放在了招股书中;再看我们的国内的外卖平台,核心派单系统的优劣也决定了整个平台的交易效率(单均配送成本)和用户体验(配送时长);最后,整个大物流行业近年来也不断在进行线上化的改造,如何撮合货物和司机,以及更好的拼单能力也是整个交易环节的关键和商业模式是否成立的前提。从运人到运物,派单引擎目前越来越多的被应用在现实的商业和生活中。


2.派单问题初探

言归正传,这里我们也来看一下,滴滴网约车平台到底是怎么派单的。首先,我们来看下我们面对的是什么样的问题?

 

“订单分配 即是在派单系统中将 乘客发出的订单 分配给 在线司机 的过程”

 

这是一个看似简单的,但实际上非常复杂的问题。说到这,可能有很多人就会问,能否就把 我的订单分配给离我最近的司机就好了?

的确啊,实际上目前滴滴的派单算法最大的原则就是 “就近分配” (70%~80%的订单就是分配给了最近的司机),据我所知,目前世界上其他的竞品公司(包括Uber),也均是基于这个原则分单的。 

我们进一步来看这个问题,如果我们只按照就近分配,先到先得的贪心策略,是不是能最好的满足平台所有乘客和司机的诉求呢?答案是否定的,原因就在于,如果我们只基于当前时刻和当前局部的订单来进行决策,忽视了未来新的订单&司机的变化,还忽视了和你相邻的其他区域甚至整个城市的需求(注:在时序上来看,新的司机&订单的出现会导致,贪心策略反而违背了就近分配的目标)。这就是为什么这个问题依然是非常复杂的原因。

这里稍微有点抽象了,不过没关系,我们再来一步一步的拆解一下订单分配的问题,让大家有个更好的理解:

简单看,在我们的平台上,每一个时刻,都有N个订单在被乘客创建,同时有M个司机可以被我们用来进行分配,我们强大的平台能够为派单算法给出司机的实时的地理位置坐标,以及所有订单的起终点位置,并且告诉我们每一个司机接到订单的实时导航距离。

 

▍如果是1个订单、1个司机

      

看上去似乎就非常简单了,我们直接把这个订单指派给这个司机就好了嘛。

“那么为什么有时候附近有辆空车却不能指派给你呢?”

实际线上的系统会比这里稍微复杂一点,原因一方面有可能是司机正好网络出现故障,或者正在和客服沟通等等导致司机无法听单,另一方面的原因是并不是所有的车都能够符合服务你订单的要求,最基本的策略其实是人工设定的规则过滤。举几个最基础的例子:

  • 规则A:快车司机不能接专车订单

  • 规则B:保证司机接单后不会通过限行限号区域

  • 规则C:为设定实时目的地的司机过滤不顺路区域

  • 规则D:为只听预约单司机过滤实时订单

  • 规则E:同一个订单只会发给一个司机一次

  • ......

    

必须澄清的一点是这里的规则并不会造成分单时不公平的效果,而完全是为了业务能正常运行而设立的,这些策略承担着保证业务正确性的重要职责。

 

▍如果是1个订单和2个司机

假设这两个司机都能够分配给这个订单,那么我们来看系统应该是如何分配的。

首先第一种情况是,同一时刻下,这两个司机和订单的距离都完全一样的情况下,系统应该如何分配?

刚才也说到,我们平台订单分配最大的原则是就近分配,当距离完全一样的情况下,当前我们系统上会主要考虑司机的服务分的优劣,服务分较高的司机会获取到这个订单(注:服务分对分单的影响,简单的理解可以换算为多少分可以换成多少米距离的优势,这块不是今天的重点就不展开介绍),再说明一下,系统用到的是地图的导航距离,而非人直观看到的直线距离,有时候差一个路口就会因为需要掉头导致距离差异很大;并且如果司机的定位出现问题,也会出现分单过远的情况。

那么我们来看第二种情况,如果A司机离的近,B司机离的远,系统怎么派?

这就简单了,根据就近分配的原则,我们会把A司机分配给这个订单。嘿嘿~~,假设我们再把问题设置的更加实际一点,当订单发出时,B司机已经在线并空闲,但是A司机还没有出现(没有上线,或者还在送乘客),但再过1s,离得更近的A司机突然出现可被分单了,假设我们使用先到先得的贪心策略,那么B司机就会被分给这个订单,那就违背我们希望就近分单的目标了:(。所以看上去简单,但实际情况下,算法还需要变的更好一些,这个问题我们把它叫做派单中的时序问题,我们后面再来看怎么解决。

▍如果有N个乘客、M个司机

最后我们来考虑最复杂的多对多的情况,这也是线上系统每天高峰期都需要面对的挑战,我们一般把这种情况会形式化为一个二部图的匹配问题,在运筹领域也叫做matching的问题,如图所示:

我们再把这个问题具象一点,假设这个时候我们有20个乘客,有20个司机,这些乘客都可以被这20个司机中的一个接驾,我们的系统需要把这20个乘客都分配出去,并且让大家的总体接驾的时长最短。听上去是不是有点复杂?我们套用下组合数学的知识,这其中可能的解法存在20的阶乘那么多,20的阶乘是什么概念呢?

20*19*18*…*1= 2432902008176640000,这个数巨大无比,想要完全的暴力搜索是绝对不可能的。这里需要更聪明的办法。

 

▍如果有N个乘客、M个司机,一会再来几个乘客和司机?

这就是派单问题最大的挑战,我们不仅仅需要当前这个时刻的最优,我们要考虑未来一段时间整体的最优,新来的司机和乘客会在整个分配的网络中实时插入新的节点,如何更好的进行分配也就发生了新的变化,所以如何考虑时序对我们非常重要,这个问题在业内也被称为Dynamic VRP问题,这个Dynamic也就是随时间时序变化的意思,这也就是为什么,滴滴的派单问题远复杂于物流行业的相对静态的货物和路线的规划问题。假设我们知道了未来供需的完全真实的变化,仿真告诉我们,我们的系统有可能可以利用同样的运力完成1.2~1.5倍的需求量,这也是派单算法的同学持续为之努力的方向。

想起前段时间的吐槽大会,大家提到文嵩曾说我们的派单问题比alpha go还要难,其实这两个问题还确实有点相似,都是在超大的搜索空间中找到一个近似最优的解,而alpha go则会在一个更加明确的游戏规则和环境中进行求解,它的难点在于博弈,而我们的派单问题难点在于未来供需不确定性&用户行为的不确定性。近年来在学界,已经有不少尝试在利用类似alpha go的技术进行VRP&TSP等方向的探索,强化学习结合运筹理论是未来运筹界非常前沿的方向之一(非技术同学可以跳过此处:))


3.派单算法简介
上面我们已经描述了什么是订单分配问题,并且它所面临的各种挑战,那么在这里我们来
聊一聊我们线上的派单策略是如何解决其中一部分问题的。

在介绍具体策略之前,首先我们来说一下派单算法大的原则,目前派单策略主要的原则是:站在全局视角,尽量去满足尽可能多的出行需求,保证乘客的每一个叫车需求都可以更快更确定的被满足,并同时尽力去提升每一个司机的接单效率,让总的接驾距离和时间最短。

如何理解这个原则呢?我们说策略会站在全局的角度去达成全局最优,这样对于每一个独立的需求来看,派单可能就不是“局部最优   ”,不过可以告诉大家的是,就算在这个策略下,仍然有70%~80%的需求也是符合当前距离最近的贪心派单结果的。

接下来,这里会拿两个重要的派单策略的来进行介绍。(这里的内容主要是讲清楚策略的motivation为主哈,细节不再展开)

▍批量匹配(全局最优)

派单策略中最为基础的部分,就是为了解决上一节所提到的时序问题。这个算法几乎是所有类似派单系统为了解决这个问题的最基础模型,在Uber叫做Batching Matching,我们内部也叫做“全局最优” 或者 “延迟集中分单”。

这个Idea其实也非常直观,由于用户订单的产生和司机的出现往往并不在同一时间点,在时间维度上贪婪的分单方式(即每个订单出现时即选择附近最近的司机派单)并不能获得全局最优的效果。一个自然的想法就是先让乘客和司机稍等一会,待收集了一段时间的订单和司机信息后,再集中分配。这样,有了相对较多、较密集的订单、司机后,派单策略即可找到更近更合理的派单方式了。

找寻司机和订单分配的全局最优是一个二分图匹配问题 (bipartite graph matching) ,一边是乘客、一边是司机,可用运筹优化中各种解决Matching问题的方法进行求解。

和大家再澄清一下,我们所采用的批量匹配的模式和大家所希望的,“把离我最近的司机派给我”的「就近派单模式」并不矛盾,我们也是寻求“乘客接驾时长最短”的最优解,大多数情况下也是指派离你最近的司机,但充分满足每一个乘客的“把离我最近的司机派给我”的个体需求, 有些时候反而会导致部分乘客的需求无法得到满足,比如说下面这种情况:

当编号1和2两个乘客同时叫车, 如果完全按照“就近派单”的模式, 虽然可以让1号乘客先被接单, 但是2号乘客会因为接驾距离较远, 导致等待时间变长, 甚至因为最近的司机超出平台派单距离, 导致2号乘客叫不到车。1、2号乘客总等待时长15分钟, 平均等待时长7.5分钟。

我们采取的做法是, 把距离较远的2号车派给1号乘客。

把1号车派给2号乘客, 这样一来, 1号乘客和2号乘客, 平均等待时长缩短为5分钟, 比就近派单,缩短了2.5分钟, 总等待时长缩短为10分钟, 比就近派单, 缩短了足足5分钟。

通过提升全局的效率,才能转化为让更多乘客的需求得到满足。

 

▍基于供需预测的分单

“如果有先知告诉我们未来每一个订单的生成时间&地点,每一个司机的上线时间&地点,派单就会变成非常轻松的一件事”

刚才所说的批量匹配的方法,理论上能够保证那一个批次的匹配是最优的。但是这样就够了吗?

很遗憾,以上所述的延迟集中分单的策略只能解决部分的问题,仍不是一个完全的方案。其最大的问题,在于用户对系统派单的 响应时间 容忍度有限,很多情况下短短的几秒钟即会使用户对平台丧失信心,从而取消订单。故实际线上我们只累积了几秒钟的订单和司机信息进行集中分单,而这在大局上来说仍可近似看做时间维度上的贪婪策略。

若想即时的获得最优派单结果,唯一的方法是利用对未来的预测,即进行基于供需预测的分单。这种想法说来玄妙,其实核心内容也很简单:如果我们预测出未来一个区域更有可能有更多的订单/司机,那么匹配的时候就让这个区域的司机/订单更多去等待匹配这同一个区域的订单/司机。

▍连环派单

基于供需预测的分单有很大意义,但由于预测的不确定性,其实际效果很难得到保证。为此,我们使用了一种更有确定性的预测方式来进行派单,即 连环派单。

“连环派单,即将订单指派给 即将结束服务 的司机,条件为如果司机的终点与订单位置很相近”

与预测订单的分布相反,连环派单预测的是下一时刻空闲司机的所在位置。由于高峰期空闲司机多为司机完成订单后转换而来,预测司机的位置就变成了一个相对确定性的问题,即监测司机到目的地的距离和时间。当服务中的司机距终点很近,且终点离乘客新产生的订单也很近时,便会命中连环派单逻辑。司机在结束上一单服务后,会立刻进入新订单的接单过程中,有效地压缩了订单的应答时间、以及司机的接单距离。

▍如何做的更好

整个派单算法核心克服的是未来供需的不确定性,动态的时空结构的建模,以及用户行为的不确定性,对于这些不确定性我们现在更多采用深度学习方法对我们的时空数据&用户行为进行建模预测。

另外,我们的问题相对于传统推荐搜索领域,多了一层匹配决策,我们到底积攒多久的订单进行分配,对于每一个分配来说我们都面临着分或者不分,现在分还是未来分配,并且分给谁的问题,这个问题天生就可以建模为强化学习问题,目前在我们的系统中也引入了强化学习方法来优化更长期的收益。

除了不断去优化之前说到的派单问题,整个派单系统还面临着大量其他的挑战,包括如何利用快车优享等多个品类的运力进行跨层的最优分配,如何同时对用户&司机&平台短期长期等多个目标进行优化,如何同时优化预约&实时订单,如何在具备网络效应的场景下对算法进行评估,如果建立一个较为精准的仿真系统等等,这里既是挑战,也是AI For Transportation中大量新的重新定义问题和创新算法的机会。


写在最后

 

以上,是今天讨论主题都全部。

每天, 我们的派单系统要面对超过3000万用户的叫车需求,   高峰期每分钟接收超过6万乘车需求,平均每两秒就需要匹配几百到上千的乘客和司机 。我们当前的派单策略相对于最初的派单策略版本,每天能够多满足百万以上乘客的出行需求。

为了让更多人能更快、更确定的打到车,我们的交易策略团队将在更好的公平感知的前提下,不断地优化和打磨我们的派单算法,为乘客&司机创造更多价值。

军哥乐于结交朋友,1年时间职场原创干货160篇,曾任前饿了么技术总监,欢迎加我微信与我做朋友(公号输入框回复“w”即可),朋友圈互吹!


以往热文推荐:

这3种工作态度,堵死你的升职加薪之路!

年底了,怎么和领导提加薪?


更多精彩,关注我公众号,一起学习、成长

▲ 长按关注军哥手记,一起学习、成长

2020.1.7(配送问题:路径优化 算法的学习) 问题介绍 车辆路径问题(Vehicle Routing Problem, VRP):它是指一定数量的客户(或配送点),各自有不同数量的货物需求,配送中心向客户提供货物,由一个车队负责分送货物,组织适当的行车路线,目标是使得客户的需求得到满足,并能在一定的约束下,达到诸如路程最短、成本最小、耗费时间最少等目的。 VRP属于组合优化问题,在有限个可行解集合中找出最优解,这类问题称为组合优化问题,是指在... 阅读详情

相关推荐

滴滴崩了:一根专线,拿捏了整座城市,而这次,AI 也救不了它

《滴滴崩溃背后的系统脆弱性》摘要 2026年5月26日下班高峰,滴滴因云厂商专线故障再次崩溃,暴露集中式架构的根本缺陷。十年来七次重大宕机显示:日均3000万订单的平台仍依赖单点脆弱的基础设施。在AI时代,平台虽拥有智能调度系统,却未能解决底层架构的韧性难题。每次崩溃不仅造成直接损失,更在累积难以量化的"隐性债务"——用户信任的持续流失。当确定性溢价蒸发时,提醒我们:未来竞争的关键不在于算法有多聪明,而在于系统有多抗崩溃。这次事件揭示了数字化转型中常被忽视的真相:上层AI的智能化必须与底

知悟之旅 575

滴滴派单算法

paper:A Taxi Order Dispatch Model based On Combinatorial Optimization 背景 业务场景:一个订单被派给多个司机,司机根据自己的喜好选择接受或拒绝 目标:最大化一次派单成单率 关键问题:estimate the probability of each driver's a...

weixin_34117522的博客 5306

滴滴2016研发笔试题解析:数组指针、链表与TCP核心考点

在互联网研发岗的笔试中,数据结构与操作系统等基础知识始终是筛选题库的基石。以C/C++语言为例,数组名与指针的关系直接映射内存模型的底层原理,而链表反转、快慢指针等算法题则考察逻辑边界与复杂度优化意识。进程与线程的调度差异、TCP三次握手与四次挥手的状态迁移,同样构成研发工程师必备的系统底线知识。理解这些概念背后的设计意图,不仅能提升笔试答题的准确率,更能支撑高并发场景下的性能分析与故障排查。从基础概念到工程实践,系统梳理数组、指针、链表、进程线程、TCP协议等核心考点,正是备战大厂研发岗笔试与面试的高效路

weixin_34186128的博客 335

滴滴派单规则分析

滴滴派单规则 1 批量匹配(全局最优) 派单策略主要的原则是:站在全局视角,尽量去满足尽可能多的出行需求,保证乘客的每一个叫车需求都可以更快更确定的被满足,并同时尽力去提升每一个司机的接单效率,让总的接驾距离和时间最短。 这个算法几乎是所有类似派单系统为了解决这个问题的最基础模型,在Uber叫做Batching Matching,滴滴叫做“全局最优” 或者 “延迟集中分单”。 2 基于供需预测的分单(大数据预测) 利用对未来的预测:如果我们预测出未来一个区域更有可能有更多的订单/司机,那么

qq_41775940的博客 7501

实践案例:百亿级数据分表后怎么分页查呢?

当业务规模达到一定规模之后,像淘宝日订单量在5000万单以上,美团3000万单以上。数据库面对海量的数据压力,分库分表就是必须进行的操作了。而分库分表之后一些常规的查询可能都会产生问题,最常见的就是比如分页查询的问题。一般我们把分表的字段称作shardingkey,比如订单表按照用户ID作为shardingkey,那么如果查询条件中不带用户ID查询怎么做分页?又比如更多的多维度的查询都没有shardingkey又怎么查询? 唯一主键 一般我们数据库的主键都是自增的,那么分表之后主键冲突的问题就是一个无法避免

fly1north的博客 759

浅谈滴滴派单算法.docx

浅谈滴滴派单算法.docx

滴滴如何调度_实时计算:Apache Flink在滴滴的应用与实践

​分享嘉宾:梁李印 滴滴出行 高级技术专家编辑整理:张策内容来源:Flink Forward ASIA出品平台:DataFunTalk导读:Apache Flink 是一个分布式大数据处理引擎,可对有限数据流和无限数据流进行有状态计算。可部署在各种集群环境,对各种大小的数据规模进行快速计算。滴滴基于 Apache Flink 做了大量的优化,也增加了更多的功能,比如扩展 DDL、内置消息格式解析、...

weixin_29969209的博客 576

动态车辆路径问题的研究进展及发展趋势

随着智能运输的发展,动态车辆路径问题(Dynamic vehicle routing problem,DVRP)已引起学界的日益关注.分析DVRP的特征,从动态要素的角度将DVRP模型分为基于动态需求的VRP、基于实时交通信息的VRP、基于动态需求和实时交通信息的VRP三种类型,并进行分类综述.在此基础上,对3类DVRP模型的路线更新策略及求解算法的研究进展进行介绍,最后指出DVRP未来的发展趋势.

花4万开发的派单系统,最后输给了3个微信群

独立开发3年,我交付了0Bug的代码,却见证了太多的项目“死于非命”。两个项目的鲜明对比(一个花4万凉了,一个花3000活了),让我这个独立开发者彻底悟出了一个道理。我会用我的经验,阻止你做那些“看起来很美、实际上没用”的功能(这是我的顾问价值)。在这个项目“凉了”之后的几个月里,我像个“烦人的前任”一样,隔三差五就去骚扰老板。“哥,你现在缺的不是一个‘独一无二’的商城,你缺的是‘验证这批货能不能卖出去’。哪怕是买来的源码,我也能帮你把坑填平,保证它稳定运行(这是我的技术本分)。

qq_37108196的博客 858

基于联合配送的城市物流配送路径优化

针对城市多区域协同发展造成的商业中心相对分散的现状, 提出“多对多” 的城市网络化联合配送机制. 以运输距离、实载率等与成本密切相关的油耗成本为优化目标, 建立面向城市多区域配送需求的车辆路径模型; 同时,利用量子比特位设计染色体结构, 利用云模型云滴随机性与稳定性改进遗传算子, 设计云量子遗传算法对所建立的联合配送模型进行求解. 最后, 结合不同算例对模型和算法进行了仿真实验分析.

k最近邻算法——电影分类及案例详解

如图3-7所示,若将国际象棋棋盘放在二维直角坐标系中,格子的边长定义为1,坐标的x轴及y轴和棋盘方格平行,原点恰落在某一格的中心点,则王从一个位置走到其他位置需要的步数恰为二个位置的切比雪夫距离,因此切比雪夫距离也称为棋盘距离。关于这里的距离度量,这个电影分类的例子有2个特征,也就是2维的,可以使用我们高中学过的两点距离公式(两点距离公式其实就是欧氏距离在二维空间上的公式,也就是欧氏距离n的值为2的情况,欧氏距离也称为欧几里德距离)来计算距离,如图3-3所示。对数据进行归一化,避免量纲对计算距离的影响。

ZhShy 4560

今天,滴滴被爆亏损109亿,需裁员2000多人,哪些员工会被裁掉?

全世界只有3.14 % 的人关注了数据与算法之美近日,一份滴滴出行内部流传出来的财务数据显示,该公司2018年持续巨额亏损,全年亏损高达109亿元人民币。若消息属实,那将...

数据与算法之美 691

告别手绘!用Aseprite+Unity Tilemap,从AI生成到2D游戏地图的保姆级搭建流程

本文详细介绍了如何利用Aseprite和Unity Tilemap从AI生成素材到搭建2D游戏地图的完整流程。涵盖AI生成素材的预处理、图层管理、动画制作,以及Unity中的Tilemap系统配置和性能优化技巧,帮助开发者高效创建像素风游戏地图。

weixin_29015483的博客 584

滴滴出行持续增长策略与运营数据分析

共享经济模式下的出行服务平台通过智能调度算法和动态定价策略优化供需匹配,这是提升运营效率的核心技术原理。在网约车领域,这类技术能显著降低空驶率、缩短接驾时间,其商业价值直接体现在订单增长和毛利率改善上。滴滴作为行业典型案例,通过下沉市场渗透和核心城市精细化运营的双轮驱动,实现了连续12个季度的订单增长。特别是在疫情后经济复苏阶段,其特惠快车等经济型产品与拼车服务(订单占比超30%)有效抓住了用户对性价比的需求变化。当前行业正从单纯规模扩张转向效率提升与生态协同,自动驾驶和新能源网络等前沿布局将成为下一阶段竞

weixin_29047919的博客 200

单片机笔记十二:华大HC32L136超低功耗设计实战

本文详细介绍了华大HC32L136单片机的超低功耗设计实战,包括深度睡眠模式下仅0.5μA的电流消耗、五种功耗模式的对比与配置、外设使用技巧及硬件级优化方法。通过实际项目案例,展示了如何利用ARM Cortex-M0+内核的HC32L136显著延长电池寿命,适用于智能门锁、额温枪等低功耗设备。

weixin_29189373的博客 404

大白映射 宝马Esys编程设码映射、USB设备映射

大白映射,宝马Esys设码编程、USB设备映射

denson0394的博客 4803

滴滴这车值不值得上?前Google全球技术总监郄小虎说来来来

李根 发自 凹非寺 量子位 报道 | 公众号 QbitAI滴滴出来分享技术进展的时候,算不上多。但如果是出于产(wa)业(ren)交(zhao)流(pin)需求,积极性就...

量子位 566

一套C#接口通吃安川/发那科/库卡:工业机器人统一控制框架设计与产线踩坑实录

我们把机器人的通用能力抽象为接口,涵盖连接、运动、IO、寄存器、状态、报警六大类能力,所有品牌适配器都必须实现这个接口。/// 工业机器人统一控制接口// 基础连接// 运动控制// IO与寄存器// 状态与报警// 事件工业机器人统一控制框架的本质,不是把所有品牌的功能都做平,而是找到通用能力的最大公约数,通过分层抽象把品牌差异隔离在底层。上层业务只关注工艺和流程,不需要关心机器人是什么品牌、用什么SDK、通信协议是什么。

这里只有干货:从 Modbus 通信到 MES 对接,从 YOLO 训练到工控机部署,带你搞定工业软件开发全流程。 405

FlyAI资讯:滴滴ElasticSearch千万级TPS写入性能翻倍技术剖析

摘要:滴滴ElasticSearch平台承接了公司内部所有使用ElasticSearch的业务,包括核心搜索、RDS从库、日志检索、安全数据分析、指标数据分析等等。平台规模达到了3000+节点,5PB 的数据存储,超过万亿条数据。平台写入的峰值 ... 人工智能学习离不开实践的验证,推荐大家可以多在FlyAI-AI竞赛服务平台多参加训练和竞赛,以此来提升自己的能力。FlyAI是为AI开发者提供数据竞赛并支持GPU离线训练的一站式服务平台。每周免费提供项目开源算法样例,支持算法能力变现以及快速的迭代算..

iFlyAI的博客 346

使用STM32H7点亮RGB屏幕

希望本文能对你有所帮助!RGB屏幕是一种具有红、绿、蓝三种颜色通道的显示设备,通过控制每个通道的亮度,可以显示出丰富多彩的图像和动画。要使用STM32H7控制RGB屏幕,我们需要连接适当的引脚,并编写适当的代码来控制每个颜色通道的亮度。在主循环中,我们先点亮红色通道,然后延迟一段时间,接着点亮绿色通道,再延迟一段时间,最后点亮蓝色通道,并再次延迟。需要注意的是,示例代码中的延迟循环使用了一个简单的计数器实现,但实际应用中可能需要更精确的延迟方式,例如使用定时器中断或操作系统提供的延迟函数。

QoyOle的博客 925

【开发必备插件】iframe嵌套报“拒绝连接请求”的本地解决方法

关键词:iframe 拒绝连接、X-Frame-Options、Chrome 插件、前端调试、Allow X-Frame-Options前几天我在本地项目里调试一个第三方网站的嵌入页面时,遇到了一个非常经典的报错:xxx.com 拒绝了我们的连接请求。熟悉的老前端们一眼就知道——这是。但对于日常开发来说,我们经常需要在本地测试 iframe 嵌套外部页面(比如嵌第三方登录页、支付页、可视化报表系统等)。而线上站点配置了或DENY时,就会直接导致 iframe 加载失败。

代码简单说 Vue、JAVA、PHP、Node.js 熟练运用,接口、架构、性能全搞定。 1545

从月薪3千到月薪3万,优秀的程序员是这样做的...

 从2018下半年开始至今,互联网迎来了自己的寒潮,各大公司都在裁员。广为人知的有:京东、知乎、锤子、美团、摩拜、滴滴都在疯狂裁员。“裁员”一词瞬间成为各大网站热点讨论话题。  作为程序员的我们,须知“打铁还需自身硬”,有本领哪里到都是路,而不是干等着被公司优化裁员。  优秀的小A是如何从月薪5千到月薪3万的,优秀的他是这样做的… 代码托管篇 GitHub 全球最大的同性交友网站,一群程序...

514

csp信奥赛C++标准模板库STL案例应用1

csp信奥赛C++标准模板库STL案例应用1

王老师青少年编程 1384

百亿级数据分表后怎么分页查询?

当业务规模达到一定规模之后,像淘宝日订单量在5000万单以上,美团3000万单以上。数据库面对海量的数据压力,分库分表就是必须进行的操作了。而分库分表之后一些常规的查询可能都会产生问题,最常见的就是比如分页查询的问题。一般我们把分表的字段称作shardingkey,比如订单表按照用户ID作为shardingkey,那么如果查询条件中不带用户ID查询怎么做分页?又比如更多的多维度的查询都没有shardingkey又怎么查询? 唯一主键 一般我们数据库的主键都是自增的,那么分表之后主键冲突的问题就是一个无法避免

艾小仙的专栏 2494

NTscan扫描工具

ntscan是一个扫描器,可以扫描没有密码和弱密码的共享,先到配置文件中填写猜测的用户名和密码,扫描过程中右侧出现的是扫描日志。

LinePhone3.2.7(android端最新版本) sip客户端

SIP客户端For android:LinePhone3.2.7(最新版本),官网地址:http://www.linphone.org/

数据驱动运营决策-框架与方法(上)

胡淏,毕业于哥伦比亚大学统计系,现任滴滴参谋部-资深数据专家。专注于数据驱动的解决方案,提供机器学习、因果推断、平台经济学领域专业咨询。数据森麟(ID:shujusenl...

数据森麟 703

Devexpress16.2.6破解工具

Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具

上一篇: 这3种工作态度,堵死你的升职加薪之路!
下一篇: 在公司不被领导重用,怎么办?做到这3条就够了!
军哥手记
军哥手记 业界专家认证 业界专家认证
博客等级 码龄21年 661粉丝 608原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值