新闻详情

新闻详情

首页 / 资讯中心 / 详情

电动汽车充放电调度:全局MILP+滚动MPC完整Matlab实现

发布时间:2026/10/2 22:19:13来源:尧图网络
电动汽车充放电调度:全局MILP+滚动MPC完整Matlab实现
做电动汽车充放电最优调度最常被问的一句话是不就充个电吗为什么还要调度但把时间线拉长到一天把对象从一台车放大到一群车问题立刻变味。电价会波动用户要出门电池会损耗变压器不能过载每一条约束都在互相拉扯。这也是为什么现在做V2G或者有序充电的研究几乎都会采用“全局规划 局部修正”的两层架构——先用全局调度算出理论最优轨迹再用局部策略应对实际偏差。这篇博文就围绕这套“从全局到局部”的双层调度思路记录我用Matlab做的建模、求解、滚动优化全过程从分时电价、出行约束到MILP日前调度再到15分钟滚动MPC每一段都会给可以直接跑的代码和踩坑记录。适合正在做电动汽车有序充电、微电网能量管理或者刚接触最优调度的同学参考。1. 全局调度和局部调度到底各干了些啥1.1 充放电调度表面是算法题本质是三方博弈我一直觉得电动汽车充放电调度最迷人的地方在于它看起来是一个纯粹的数学优化问题实际却是一个多主体博弈问题。用户希望充电便宜、出行不误充电运营商希望充分利用配网容量、削峰填谷而研究者和工程师还要考虑电池寿命、碳排放甚至变压器负载率。这三方诉求在数学上不可能同时满足到极致只能通过目标函数和约束条件做妥协。举个最典型的例子晚上11点到早上7点的谷电很便宜按理说大家都应该半夜充电。但如果一整个小区几百辆电动车同时半夜开始充变压器瞬间就会过载电网受不了。反过来如果为了变压器安全把所有车都限制成极低功率充电用户早上出门可能又是亏电状态。所以调度要做的事就是在一个目标函数下找到折中点——比如“总充电成本最低”同时“总功率不超过配网容量”同时“每辆车出发时都有足够的电”。那目标和约束具体长什么样我用最通俗的话概括目标函数就是“给每一项诉求定个价格”约束就是“哪些行为绝对不允许”。比如不能让车同时充电和放电这就是一个硬约束比如出发时SOC必须高于某个值这也是硬约束而充放电成本高低、电池损耗多少则放进目标函数里权衡。1.2 为什么不能一个全局模型管到底非得全局加局部刚接触这个方向的时候我第一反应是既然有全局模型了直接滚动起来不就行了把预测误差加进去多调几次参数不就完了吗后来实际跑下来才发现全局模型在开环执行时非常脆弱。原因很直白全局调度依赖的是预测数据而现实中无论是电价还是出行需求都不可能完全预测准确。你今天早上测的SOC是0.5下午实际跑了趟机场回来变成0.15说好晚上7点回家临时加班到9点。每一个预测误差都会累积而SOC是一个积分量误差累积到最后可能直接导致约束不可行。所以业内常用的做法是分成两层全局层做“日前调度”假设我掌握了明天一整天的电价和出行计划算出未来24小时的充放电参考轨迹局部层做“滚动修正”每一步只往前看几个小时以当前实测SOC为起点在尽量贴近全局参考轨迹的同时去利用最新的实时电价信息。打个比方全局层是出发前用地图规划好整个自驾路线局部层是途中遇到修路或堵车重新计算之后几分钟怎么走。两者配合既不会完全偏离大方向又能适应实际变化。2. 建模前的准备目标函数、约束和数据三张表2.1 目标函数必须写清楚的三笔账先说目标函数。单辆电动汽车的充放电调度最常见的目标是“总成本最小”。这里至少有三笔账要写进去缺一个都会出问题。第一笔是购电成本从电网买电充电花出去的钱。第二笔是放电收益把电池里的电卖回电网拿回来的钱。这两笔一减就是最简单直接的经济目标。但很多新手在这里会漏掉第三笔——电池损耗成本。我实测下来如果不加电池损耗成本模型会为了几毛钱的峰谷价差让电池反复深度充放电。从能量套利角度看它确实“赚钱”了但实际电池损耗可能比赚的电费还高。所以我会在目标里加一项放电损耗成本比如每放出1kWh电计入0.1到0.3元的等效损耗成本。具体数值取决于电池类型和你的保守程度磷酸铁锂可以取低一点三元锂取高一点后期也可以换成更复杂的非线性健康老化模型。另一个教训是必须防止模型同时充电和放电。如果不加互斥约束目标函数里一边买电一边卖电理论上可以无限循环套利求出来的计划完全没意义。这一点后面在约束部分会细讲但一开始就要把它写进目标设计里。2.2 约束条件清单照着抄就能少踩坑我把常用的约束整理成一张表建模时照着核对就行约束名称数学表达式物理含义SOC动态转移SOC(t1)SOC(t)dt/C_bat×(η_c×Pch(t)-Pdis(t)/η_d)电池电量随充放电功率的变化SOC上下限SOC_min≤SOC(t)≤SOC_max保护电池避免过充过放充电功率上限0≤Pch(t)≤Pch_max充电桩和车辆硬件限制放电功率上限0≤Pdis(t)≤Pdis_max放电同样有硬件限制充放电互斥Pch(t)×Pdis(t)0同一时刻不能既充又放出行需求SOC(出发时刻)≥SOC_required用户出门必须用末端SOCSOC(24)≥SOC0便于多日连续调度SOC动态约束是整个问题的核心你可以把它理解成一个“电量银行账户”充进去的每一度电要乘上充电效率放出来的每一度电要除以放电效率一天下来账户余额不能低于下限也不能超过上限。很多新手容易漏掉末端SOC约束结果就会出现“早上出门电够用但到晚上SOC却降到了0.01”这种荒谬结论。充放电互斥约束也必须注意。虽然数学上可以用非线性表达式但实际优化中建议用二进制变量线性化引入一个0/1变量uu0时禁止充电u1时禁止放电。这样问题变成混合整数线性规划Matlab自带求解器就能解后面会给代码。2.3 输入数据从哪里来怎么整理成向量在建模型之前先把数据准备齐。我通常准备好四类数据电池参数、电价曲线、出行需求、初始SOC。电池参数可以从常见车型参数表里查比如参数典型值说明电池容量C_bat40~100 kWh不同车型差异大最大充放电功率Pmax7~22 kW家用慢充多为7kW充电效率η_c0.90~0.98取决于充电机放电效率η_d0.85~0.95V2G逆变器损耗SOC下限/上限0.1 / 0.9保护电池寿命电价曲线可以直接用所在地区的分时电价比如峰时1.2元/kWh、平时0.7元/kWh、谷时0.3元/kWh也可以从论文附带的算例数据里抄一组。出行需求可以先简化为“早上8点出发时SOC不低于0.8”。初始SOC就按当天上车前的实测值填。在Matlab里所有数据最终都要整理成向量。比如24小时调度就用24×1的向量如果少量数据是小时级的局部层又要用15分钟粒度可以用repelem把向量展开成4倍长度。单位一定要统一功率用kW、电量用kWh、电价用元/kWh、时间用小时这是最容易出错的地方。3. 全局层实现用Matlab解一个MILP日前调度3.1 完整可跑的problem-based代码全局层我用的是Matlab自带的problem-based优化建模加上intlinprog求解。代码结构很清晰先定义参数再定义变量然后写目标函数和约束最后求解。下面这份代码可以直接复制运行%% 全局日前调度单辆电动汽车 24h 充放电计划 % 时间分辨率 dt 1h clear; clc; T 24; dt 1; % 24个时段每段1小时 C_bat 60; % 电池容量 kWh SOC0 0.3; % 初始SOC SOC_min 0.1; SOC_max 0.9; % SOC上下限 SOC_dep 0.8; dep_idx 8; % 08:00出发需≥80% Pmax 7; % 最大充/放电功率 kW eta_c 0.95; eta_d 0.90; % 充/放电效率 degrade_cost 0.15; % 放电等效损耗成本 元/kWh % 分时电价谷0.3平时0.7峰1.2元/kWh price 0.3 * ones(T, 1); price(8:11) 0.7; % 早高峰平时段 price(18:21) 1.2; % 晚高峰峰时段 % 建立优化问题 prob optimproblem(ObjectiveSense, minimize); % 决策变量 Pch optimvar(Pch, T, LowerBound, 0, UpperBound, Pmax); Pdis optimvar(Pdis, T, LowerBound, 0, UpperBound, Pmax); u optimvar(u, T, Type, integer, LowerBound, 0, UpperBound, 1); SOC optimvar(SOC, T, LowerBound, SOC_min, UpperBound, SOC_max); % 目标函数购电成本 - 放电收益 放电损耗成本 prob.Objective dt * sum(price .* Pch) - dt * sum(price .* Pdis) ... degrade_cost * dt * sum(Pdis); % 约束1SOC 动态 prob.Constraints.soc0 SOC(1) SOC0 ... dt / C_bat * (eta_c * Pch(1) - Pdis(1) / eta_d); prob.Constraints.soc_dyn SOC(2:T) SOC(1:T-1) ... dt / C_bat * (eta_c * Pch(2:T) - Pdis(2:T) / eta_d); % 约束2出发SOC约束3末端SOC prob.Constraints.dep SOC(dep_idx) SOC_dep; prob.Constraints.final SOC(end) SOC0; % 约束4充放电互斥 prob.Constraints.excl1 Pch u * Pmax; prob.Constraints.excl2 Pdis (1 - u) * Pmax; % 求解 options optimoptions(intlinprog, Display, iter); [sol, fval, exitflag] solve(prob, Options, options); % 画图 figure; subplot(2,1,1); stairs(1:T, sol.Pch, -o); hold on; stairs(1:T, -sol.Pdis, -s); legend(充电功率, 放电功率); xlabel(时刻 / h); ylabel(功率 / kW); grid on; subplot(2,1,2); stairs(1:T, sol.SOC, -o); xlabel(时刻 / h); ylabel(SOC); grid on;关键注释我解释一下SOC动态约束里充电效率乘在功率上放电效率除在功率上这是物理上正确的写法。充放电互斥用了两组线性不等式一个是“充电功率不能超过u×Pmax”一个是“放电功率不能超过(1-u)×Pmax”这样u只能取0或1天然保证同一时刻Pch和Pdis不可能同时为正。3.2 结果怎么读什么时候放电才是真划算运行完这份代码你大概率会看到充电集中在凌晨谷段SOC曲线在早上出发前爬到0.8以上白天基本保持或者小幅波动晚上的峰段可能会有一次放电。但你也要警惕一个现象如果模型中放电次数太多基本可以认定损耗成本参数设置不合理。我在实际算例中会专门做一个套利阈值判断。假设你谷段买入电价为0.3元/kWh充电效率0.95放电效率0.90那么从买入到放出实际能送到电网的电量只有0.95×0.900.855 kWh。所以卖电电价至少要大于0.3÷0.855≈0.351元/kWh放电才不会亏本。按照这个逻辑我列过一张快速判断表充电时段电价放电保本电价说明0.3 元/kWh0.35 元/kWh谷充峰放通常有套利空间0.7 元/kWh0.82 元/kWh平充峰放勉强保本1.0 元/kWh1.17 元/kWh峰充峰放基本一定亏这个阈值看起来简单但很多新手的模型会给出“高价时段充电、低价时段放电”的倒挂结果原因就是没算这笔账。以后任何充放电方案先拿这个表对一下能少走很多弯路。3.3 改参数时会发生什么全局模型最大的价值在于你可以快速试错和做敏感性分析。我常改的几个参数包括degrade_cost、SOC_max、Pmax和电价曲线。把degrade_cost从0.15改成0.30放电次数会明显减少这是符合直觉的放电损耗更贵套利动力就弱了。把SOC_max从0.9放宽到0.95凌晨段充电量会更多因为储电空间更大但也要注意长期满充对锂电寿命并不友好。把出发SOC需求从0.8改成0.6模型会立刻减少放电套利的空间因为电池本身有更多余量。这些现象说明一个问题全局调度不是“求出一个答案就完了”而是“给定输入参数算一个最符合当前场景的答案”。你做研究或做工程方案一定要跑几组不同参数才能理解这个模型边界在哪里。4. 局部层实现滚动时域MPC策略4.1 局部层和全局层到底差在哪全局层给出的是24小时开环计划但在实际执行中会遇到两类问题一是实际SOC和计划SOC不同二是一天后系统负荷变化导致的功率约束改变。所以局部层采用的是滚动时域控制思路是每一步只看未来几小时并执行第一个控制量等下一时刻重新测量状态再求解一次。局部层的优化模型和全局层在那几个核心约束上保持一致但目标函数不一样。局部层更关心“如何在不违反当前约束的前提下尽可能贴近全局参考同时又能在实时电价变化时占一点便宜”。也就是说它的目标是一个多目标合成跟踪全局参考轨迹别让执行结果大幅偏离日前计划利用最新电价信息临时多充一点或少充一点控制动作要平滑避免一会儿满充一会儿满放。4.2 为什么这里要用线性化别直接用二次目标很多刚接触MPC的同学第一反应是把跟踪误差写成平方项即sum((P - P_ref).^2)。这在理论上是标准的但MATLAB自带intlinprog不支持二次目标如果模型里还有二进制互斥变量intlinprog会直接报错。我的做法是改用线性跟踪目标。原理很简单引入两个非负变量e_plus和e_minus让净功率与参考值的偏差等于e_plus - e_minus然后在目标里最小化e_pluse_minus。由于优化总是倾向于把偏差压小这两个变量不会同时为正效果和绝对误差一样但是标准的MILP形式。如果你是非要用二次目标的场景那只能换外部求解器比如YALMIP加Gurobi或CPLEX。后面专题里我会专门写一篇对比这里先记住一个原则Matlab自带求解器能线性化就线性化能不用二次就不用二次。4.3 滚动循环的Matlab实现下面这份代码模拟了一个15分钟控制周期、预测时域4小时的滚动MPC并假设已经拿到全局参考轨迹u_ref。为了简化仿真只做到能保持每个预测窗口完整即一共81个控制步。%% 局部滚动MPC15分钟控制周期预测时域16个周期4小时 clear; clc; dt_ctrl 0.25; % 控制周期 15分钟 T_local 16; % 预测时域16个15分钟 4小时 N_step 81; % 总控制步数24h/0.25h - 16 1 C_bat 60; SOC_min 0.1; SOC_max 0.9; SOC0 0.3; Pmax 7; eta_c 0.95; eta_d 0.90; price_dt repelem(price, 4); % 15分钟粒度的电价 u_ref repelem(sol.Pch - sol.Pdis, 4); % 全局计划展开到15分钟粒度 SOC_meas SOC0; P_exec zeros(N_step, 1); lambda_track 2.0; % 跟踪全局计划的权重 lambda_price 1.0; % 实时电价收益权重 d_max 3; % 每15分钟功率变化上限 kW for k 1:N_step idx k : k T_local - 1; P_ref_local u_ref(idx); price_local price_dt(idx); % 构造短时域优化问题 prob_l optimproblem(ObjectiveSense, minimize); Pch_l optimvar(Pch_l, T_local, LowerBound, 0, UpperBound, Pmax); Pdis_l optimvar(Pdis_l, T_local, LowerBound, 0, UpperBound, Pmax); u_l optimvar(u_l, T_local, Type, integer, ... LowerBound, 0, UpperBound, 1); SOC_l optimvar(SOC_l, T_local, ... LowerBound, SOC_min, UpperBound, SOC_max); netP Pch_l - Pdis_l; % 跟踪偏差线性化 e_plus optimvar(e_plus, T_local, LowerBound, 0); e_minus optimvar(e_minus, T_local, LowerBound, 0); % 目标跟踪参考 实时电价套利 prob_l.Objective lambda_track * sum(e_plus e_minus) ... - lambda_price * dt_ctrl * sum(price_local .* netP); % 跟踪约束 prob_l.Constraints.track netP - P_ref_local e_plus - e_minus; % SOC动态 prob_l.Constraints.soc0 SOC_l(1) SOC_meas ... dt_ctrl / C_bat * (eta_c * Pch_l(1) - Pdis_l(1) / eta_d); prob_l.Constraints.soc_dyn SOC_l(2:T_local) SOC_l(1:T_local-1) ... dt_ctrl / C_bat * (eta_c * Pch_l(2:T_local) - Pdis_l(2:T_local) / eta_d); % 互斥约束 prob_l.Constraints.excl1 Pch_l u_l * Pmax; prob_l.Constraints.excl2 Pdis_l (1 - u_l) * Pmax; % 功率变化率限制 prob_l.Constraints.rate1 netP(2:T_local) - netP(1:T_local-1) d_max; prob_l.Constraints.rate2 netP(1:T_local-1) - netP(2:T_local) d_max; % 求解 sol_l solve(prob_l); % 执行第一时刻控制量 P_exec(k) sol_l.Pch_l(1) - sol_l.Pdis_l(1); SOC_meas SOC_meas ... dt_ctrl / C_bat * (eta_c * sol_l.Pch_l(1) - sol_l.Pdis_l(1) / eta_d); % 这里可以补一行sentinel判断 end代码里我特意加了一个变化率限制每15分钟净功率的变化不能超过3kW。这在实际项目中非常有用否则MPC可能在相邻时刻出现大幅抖振比如先8kW充电、下一周期又8kW放电对设备不友好对变压器也有冲击。如果不想用硬约束也可以在目标里加平滑惩罚项但线性化后复杂度会上升不如硬限制来得直观。4.4 怎么判断局部层在正常工作跑完MPC模拟后我会同时画三条曲线全局参考轨迹、MPC实际执行轨迹、实际SOC轨迹。最理想的情况是MPC执行轨迹与全局参考大体一致但在电价突然上涨的时段会出现“临时少充”甚至“临时放电”同时在电价极低的时段会“多充一点”。还要重点判断约束是否被守住SOC实际的每一帧都应该落在0.1到0.9之间功率不应该超过Pmax变化率不应该超过d_max。如果某些时段约束被突破问题多半出在约束表达上而不是优化目标上。一个常见的困惑是为什么MPC每一步都不是全局最优但整体效果却更稳我的理解是全局最优是在“完美预测”这个假设下定义的而现实世界里根本没有完美预测。MPC的价值不在于超越理论最优而在于面对不确定性时不翻车。5. 从全局到局部衔接的几个细节5.1 时间尺度对齐为什么我推荐repelem而不是interp1全局调度一般用1小时分辨率局部MPC用15分钟分辨率。两条曲线衔接时最常见的问题是用interp1做线性插值把小时级参考变成15分钟级参考。但线性插值会引入“半功率”工况而实际充电桩根本没有这种设置。更关键的是SOC参考轨迹也会跟着漂移局部层容易误解全局目标。我的做法很简单用repelem做阶跃保持。全局计划给出某一小时内的恒定功率值直接复制到该小时内4个15分钟时段。这样全局参考和局部执行之间不会产生语义偏差。只有在做一些平滑处理时才考虑插值但那属于后处理了。5.2 实测状态与计划状态不一致怎么办局部层每次重新求解时第一个SOC状态必须用实测值而不是全局计划值。这意味着之前积累的误差不会一路带到未来而是在每个控制周期开始就被“重置”了。但实测SOC和全局计划SOC偏差过大时局部层很容易出现不可行。比如全局计划让你早上6点保持低SOC结果实测发现由于行驶里程高SOC已经低于下限。这时候最稳妥的办法是把出发SOC约束改成软约束允许局部层略微低于需求但在目标里惩罚。方法还是线性化引入一个非负变量penalty让SOC_dep - SOC_required ≤ penalty目标里加一个较大的系数。5.3 实时电价更新后要不要重做全局计划局部MPC有能力处理小幅电价波动但如果预测电价出现了结构性变化比如原来预测全天都是低价实际变成了高峰那局部层会不断偏离全局参考本质上是在追逐一个已经过时的最优计划。碰到这种情况我建议分两级处理小幅波动交给MPC实时消化大幅波动才重新运行一次全局调度用新的参考轨迹替换旧的参考轨迹。这也是工程上常见的“滚动重调度”思路。判断阈值可以用电价偏差百分比比如超过20%就触发重调度。这样既享受了两层架构的计算效率又不会让全局层彻底闲置。6. 常见问题与调试实录6.1 求解器直接报Infeasible怎么办这是新手遇到最多的错误。举个例子有人会把出发SOC设成0.8但初始SOC只有0.3且提前只有1小时最大充电功率7kW。我们算一笔账0.95×7×1÷60≈0.11也就是说1小时最多只能充大约11%电量。初始0.3加0.11也到不了0.8模型当然无解。排查方法很简单把约束逐个注释掉看哪条约束导致无解。先去掉出发SOC约束再跑一次如果可解那问题就出在需求约束和充电能力之间的矛盾。解决办法无非两条放宽SOC需求或者允许更早开始充电。6.2 结果出现同一时刻既充电又放电哪怕加了互斥约束如果已经写了excl1和excl2但结果仍然出现微小的同时充放电通常是数值容差问题。intlinprog的求解精度主要受IntegerTolerance控制默认一般是1e-5优化器可能认为u1和u0都可以接受导致微小的重复。我的处理方式有几个一是检查解中Pch和Pdis的交集是否大于一个小阈值比如0.1kW二是如果确实有就把互斥约束写成Pch ≤ u×Pmax和Pdis ≤ (1-u)×Pmax再加两条绝对值差值约束比如Pch Pdis ≤ Pmax这其实是一个更方便的写法可以同时保证互斥。用后一种写法约束数还少一些。6.3 放电次数特别多或者完全不放电各自正常吗放电次数特别多先检查degrade_cost是否设成0了。如果为0模型当然会拼命放电套利。放电次数为零先看峰谷价差是否超过套利阈值。假设谷时0.3元、峰时0.6元算一下0.6大于0.351理论上应该有放电空间但如果出发SOC要求太高电池根本没有富余电量可放那就不放电了。所以当放电行为异常时我的排查顺序是先算套利阈值再看SOC可放空间最后才怀疑模型约束写错了。这个顺序能省掉大量调试时间。6.4 intlinprog报错quadratic objective怎么理解这个报错来自目标函数里有二次项。很多教程里的人爱用平方误差写MPC目标但Matlab内置的整数规划求解器只支持线性目标。你可以把二进制变量去掉退化成quadprog能解的QP问题但这就丢掉了充放电互斥结果可能完全失真。更实际的做法是在模型里用线性化绝对误差就像我在局部层代码里写的那样。如果坚持要用二次目标那就安装YALMIP和一个支持MIQP的外部求解器。这个选择没有绝对优劣看你项目里更依赖哪套工具链。6.5 求解速度慢优化半天不出来单车的MILP其实非常快通常毫秒级就能解完。慢一般发生在你把一辆车扩展成几十辆车、几百个时段、大量二进制互斥变量之后。到这种规模我建议不要直接堆变量而是用聚合模型或者用分布式算法比如拉格朗日松弛、ADMM、一致性算法。每一辆车先独立求解再通过迭代交换“总功率越限”的价格信号最后收敛到全局可行解。如果只是单层测试也慢先检查预测时域是不是设得太长。MPC并不需要预测24小时4到6小时通常就足够提供决策信息过长的预测时域只会增加变量和求解时间。7. 工具箱选型和后续扩展方向7.1 工具链怎么选省得来回折腾场景推荐工具原因纯线性/MILP问题Matlab自带optimproblem intlinprog零配置够用二次目标整数变量YALMIP Gurobi/CPLEX支持MIQP速度快非线性电池寿命模型fmincon / 全局优化工具箱目标函数不再线性大规模群体调度OSQP 分布式算法问题巨大但线性QP可解我个人建议第一版一定用Matlab自带intlinprog把流程跑通。这样你验证逻辑、画图、调参都很快不会被外部求解器安装问题干扰。等模型稳定了再考虑切换工具针对性能做优化。7.2 从一台车扩展到一群车和微电网单辆车的调度只是起点真实项目里必然是几十台甚至上百辆车同时参与。扩展到群体时目标函数里要多一项“总充放电功率不超过配变容量”约束里要多辆车共享一个功率上限这是一个典型的耦合约束。处理耦合约束的方法有很多。最简单的是一轮一轮迭代先每辆车独立优化把我们第一步得到的所有车总功率曲线叠起来计算每时段是否越限如果越限就提高该时段的价格信号让所有车减少充电反复迭代直到不越限。这就是价格迭代法也叫拉格朗日松弛思想。再往后还可以把充电策略和微电网的光伏出力结合让电动汽车在光伏高发时段多充电在夜间高负荷时段回馈电网。甚至可以用最近特别火的强化学习方法比如DQN或PPO替代MPC做局部决策。但我的建议永远是先把全局局部这套确定性优化框架吃透再往学习型方法走。否则你连最优解长什么样都不知道训练出来的Agent也没有参照基准。最后说一点个人体会。最开始我犯的错误是试图把全局调度做到极致精细以为只要预测够准开环计划就够了。结果在仿真中加入随机误差之后开环计划频繁越过SOC约束而加上MPC局部层之后虽然每一步看起来偏离了全局最优整天的实际成本反而更稳。后来我才理解“从全局到局部”不只是算法上的分层更是一种面对不确定性的正确姿态——全局确定方向局部负责纠偏。另外在Matlab里能不用整数变量就不用能一次线性化就不要二次这两条原则帮我省了大量的调试时间。
网站建设高端定制企业官网
RELATED

相关资讯

更多精彩内容,欢迎继续阅读

较早相关资讯

最新相关资讯

SPXY样本划分:光谱数据建模的联合距离驱动策略 2026/10/2 22:59:57

SPXY样本划分:光谱数据建模的联合距离驱动策略

简介:本资源聚焦化学计量学与近红外光谱建模中的关键预处理环节,面向数据分析初学者、光谱建模工程师及食品/农业领域科研人员,解决不均衡样本下模型泛化能力弱、验证结果不稳定等实际问题。资源提供SPXY样本划分法与蒙特卡罗交叉验证&#x…

阅读更多 →
手写Promise:从状态机到微任务,彻底搞懂异步错误传播 2026/10/2 22:59:27

手写Promise:从状态机到微任务,彻底搞懂异步错误传播

“Promise 又报错了”——这大概是前端工位上出现频率最高的一句话。打开控制台, Uncaught (in promise) TypeError: Cannot read properties of undefined 、 Unhandled promise rejection ,这种红色报错几乎每个用 JavaScript 的人都见过。很多人第…

阅读更多 →
IIS网站发布从零到实战:安装部署、应用池配置与常见报错排查 2026/10/2 22:59:26

IIS网站发布从零到实战:安装部署、应用池配置与常见报错排查

这几天帮一个朋友部署内网管理系统,他把一台Windows Server 2019从买回来就一直闲置,现在要建一个公司内部用的Web系统。我原本觉得IIS部署是再基础不过的事,结果从安装到发布再到外网访问,一路踩了不少坑——有版本兼容、权限配置…

阅读更多 →
VSCode配置C/C++开发环境:编译、调试、智能提示全链路指南 2026/10/2 22:59:25

VSCode配置C/C++开发环境:编译、调试、智能提示全链路指南

简介:本资源是一套开箱即用的VSCode C/C开发环境配置方案,面向初学者及中级开发者,解决Windows平台下VSCode无法直接编译调试C/C程序的核心痛点。资源包含25个文件,以9个JSON配置文件(如c_cpp_properties.json、tasks.…

阅读更多 →
RAG调优实战:分块、召回、重排三环节的6个关键结论 2026/10/2 22:59:25

RAG调优实战:分块、召回、重排三环节的6个关键结论

RAG项目上线后的第一周,我盯着后台的日志数据,越看越不对劲:用户提问后真正点了“查看参考资料”的比例不到三成,而回答被判定为不满意的会话里,有很大一部分其实检索回来的资料里已经有答案了,LLM没找着或…

阅读更多 →
RAG落地实战:分块、召回、重排与Hit Rate提升的6个结论 2026/10/2 22:59:24

RAG落地实战:分块、召回、重排与Hit Rate提升的6个结论

RAG 落地做了几个月,我最大的感受是:demo 跑通和业务能跑是两个物种。尤其是当你搭建了一个看似完善的知识库问答系统,领导随手问一个具体数字,模型却一本正经地给出了一个原文里根本不存在的答案——那一刻你才知道,问…

阅读更多 →

今日资讯

本周资讯

本月资讯

看完文章仍有疑问?

联系尧图顾问,获取一对一建站咨询

立即免费咨询 📞 400-888-8888
📞 ✉