简介一份基于Python与STK11的多智能体强化学习卫星调度实验资源面向希望入门强化学习与卫星任务规划的学习者也适合作为毕设、课程设计或工程实训项目。资源包含完整的任务生成与访问时段计算流程mission.py定义随机任务属性create_mission.py批量生成任务并存入CSVcompute_access.py连接STK场景计算可访问时段另有PyTorch模型权重、可视化截图和STK场景文件等。压缩包共241个文件约79.6MB主要包含13个Python脚本、39个CSV数据文件、多组场景与备份文件、63张过程图片及7个模型权重文件结构清晰便于按模块研读。目前已有132人学习下载适合希望快速跑通卫星调度实验、理解多智能体强化学习落地细节的开发者。通过修改任务规模与随机参数可扩展为不同场景的调度实验是兼具教学与二次开发价值的参考资料。1. 卫星调度为什么值得让 STK11 和多智能体强化学习出现在同一个实验里遥感卫星调度最大的难题不是“算一颗卫星什么时候路过目标”而是多颗卫星争抢任务、地面站资源、能源和存储时怎么在十分钟内给出一个全局不冲突的方案。我刚接触卫星调度时也试着写规则先到先服务、按优先级插队最后全部翻车——规则多到没法加而实际调度窗口一变整张表就废了。把 Python 和多智能体强化学习结合起来正是为了把这套决策交给算法每颗卫星是一个智能体可见性窗口、任务价值、能源状态是环境给它的观测它自己学会什么时候接活、什么时候放弃。STK11 在其中扮演“环境引擎”的角色负责把轨道预报、传感器覆盖、星地可见性这些几何算得准Python 侧只拿到干净的时间窗口不碰轨道微积分。两者的融合实验等于把“模型可信”和“决策智能”拼到了一起适合研究生课题、预研项目也适合想验证 MARL 算法能不能落地的工程师。这套链路看起来复杂实际拆开只有四块STK 数据桥、环境封装、MARL 训练、闭环回放。下面按我自己的落地顺序写每一步都给出能跑的代码和参数最后把最容易耽误时间的坑单独列出来。2. 数据链路从 STK11 把可见性窗口拿到 Python 里2.1 为什么不在 Python 里自己算轨道而是用 STK11 提供真实感见到这类标题第一反应一定是调度所需的信息为什么不由强化学习环境自己算道理很简单卫星调度的“几何真实感”远大于“决策复杂度”。一颗 LEO 卫星从北京上空掠过地面站能不能建链取决于轨道根数、J2 摄动、传感器半角、最大仰角、大气时延自己写这套传播和覆盖逻辑至少两三个月而且验证困难。STK11 的价值在于它把这些几何计算全部封装好了。我们只需要在 STK 里建立卫星、地面站、传感器设置约束STK 会算出每个可见窗口的起止时间。Python 侧的强化学习拿到的是“窗口列表”这种领域无关的数据不需要关心窗口背后的坐标变换。常见做法是把 STK 当离线仿真器先把场景跑完导出可见性表再让 Python 读表训练。这种“离线文件桥”比在线实时调用 COM 稳得多也是我个人推荐的起步路径。2.2 两条桥接路线离线文件桥与在线 COM 桥先走哪条STK11 和 Python 之间的桥本质上只有两种。一种是离线桥STK 把 Access 报告导出成 CSV 或 TXTPython 用 pandas 读进来。另一种是在线桥Python 通过 COM 接口或 TCP 端口直接控制 STK 场景随时问“现在这颗卫星能看到谁”。在线桥适合最后做闭环验证因为 GPU 训练时反复起 STK 进程会慢到崩溃。我在实际实验里是这么分配的训练前用离线桥把一整天 86400 秒内所有可见窗口生成一张大表后面每次 step 只是查表训练结束后再用 COM 桥把策略选出的动作回传到 STK 场景做可视化复现和覆盖评估。这样训练稳定性高又保留了“融合”的感觉。2.3 在 STK11 里先造一个能用的调度场景在 STK11 里造场景不建议从零写脚本先在 UI 里点一遍反而快。我一般会这样配置一个最小场景新建 Scenario时间范围 24 小时步长 60 秒。添加 6 颗 LEO 卫星轨道高度 500-800km倾角 60-98 度轨道面错开。添加 4 个地面站分别放在北京、西安、海口、喀什。为卫星添加简单圆锥传感器半角 45 度表示星载遥感载荷。对卫星与地面站、卫星与目标区域分别做 Access 计算。这些操作在 STK 里都是菜单点击不是本文重点。重点是把 Access 结果变成 Python 能消费的数据。STK11 的表现形式是把卫星、地面站都当作对象Access 计算出的可见窗口会以报告形式给出我们需要选中窗口数据区间导出为带起止时刻的表格。2.4 把 Access 报告导出为 Python 能消费的时间窗口表在 STK11 中对卫星和地面站做 Access 计算后右键场景对象选择“Generate Report”选择 Access 相关的 Interval 数据导出格式用 CSV。导出的表格大体长这样access_start_utcg,access_end_utcg,satellite,ground_station 01 Jul 2024 00:12:34.000,01 Jul 2024 00:17:12.000,SAT1,GS1 01 Jul 2024 00:31:05.000,01 Jul 2024 00:38:44.000,SAT1,GS2直接用这份 CSV 做训练不是不行但字符串时间在环境里每次加减会很别扭。我一般会在 Python 侧先做一次清洗把 UTCG 时间转成 Unix 秒再补一列窗口 ID。这样环境里所有逻辑都基于整数秒判断是否在窗口内就是两次减法的事。2.5 最小 COM 连接脚本先确认 STK11 能被 Python 叫醒离线 CSV 准备好后我们仍然需要一个最小 COM 连接脚本确认 Python 和 STK11 之间的在线通道也通。STK11 安装后会在 Windows 注册 COM ProgIDPython 用 pywin32 调用代码如下import pythoncom import win32com.client as win32 pythoncom.CoInitialize() # 尝试连接 STK11 应用 try: app win32.Dispatch(STK11.Application) app.Visible True app.UserControl True root app.Personality2 # STK11 的根对象早期 COM 接口形态 print(STK11 COM connect OK) print(Scenario path:, root.CurrentScenario) except Exception as e: print(Connect failed:, repr(e)) finally: pythoncom.CoUninitialize()这段脚本的逻辑很直接先用 pythoncom 初始化 COM 线程模型再通过 ProgID“STK11.Application”拿到应用对象。Personality2是 STK 对象模型里的根入口所有卫星、地面站、报告都挂在它下面。后续我们在第六章用它做闭环回放时会看到更多用法。需要注意连接成功的前提是 STK11 已经安装且许可可用如果你的机器上是 STK 12ProgID 要改成“STK12.Application”对象模型基本一致。连接报错时先看第 5 章的避坑清单很多坑都出在这一步。3. 把可见性窗口变成多智能体强化学习环境3.1 一个卫星调度问题如何变成 MDP 五元组多智能体强化学习环境的第一件事是定义状态、动作、奖励、转移。卫星调度天然具有马尔可夫过程特征当前时刻所有任务的剩余价值和窗口可访问关系足够决策决策落地后时间推进进入下一状态。状态按时间步切片。假设决策步长是 60 秒那环境里每一秒或每 60 秒给每个智能体一个观测向量。观测至少要包含当前时间、该卫星可见的所有任务窗口、每个任务的剩余价值、卫星剩余能源。动作的定义常见有两种一是“选择某个任务执行”离散动作空间二是“以什么姿态指向哪个目标”连续动作空间。起步阶段我强烈建议只用离散动作因为 STK 的可见性已经在几何上约束了“能不能做”决策层没必要再引入姿态连续量。动作空间大小设为任务数量 1多出的一个表示“空闲等待”。3.2 为什么用多智能体而不是一个全局智能体单智能体强化学习也能处理多卫星调度做法是把所有卫星状态拼成一个超长向量让一个策略网络输出所有卫星的动作。这种方案在卫星数量少时跑得通但一旦新加一颗卫星输入输出维度全变模型必须重新训练扩展性很差。多智能体的核心价值是把控制权下放到每颗卫星每颗卫星一个 actor只用自己的局部观测做决策训练时再用一个集中 critic 评估全局状态。这种“集中训练、分布执行”的框架既避免了独立训练时环境非平稳导致的不收敛又保留了对卫星数量变化的扩展能力。现在的多智能体深度学习、深度强化学习相关开源库大多也是这个套路。3.3 环境类实现最小可运行的卫星调度环境下面给一个能直接跑的 Gymnasium 风格环境类。它读取 CSV 中的可见窗口每个 step 推进 60 秒所有卫星同时决策。import numpy as np import pandas as pd class SatelliteSchedulingEnv: def __init__(self, access_csv, n_sats6, n_tasks8, dt60.0): self.dt dt self.n_sats n_sats self.n_tasks n_tasks # 将 CSV 中的窗口读进来时间已提前转为 Unix 秒 self.windows pd.read_csv(access_csv) self.current_time self.windows[start].min() self.end_time self.windows[end].max() # 每个任务一个初始价值 self.task_value np.array([10.0] * n_tasks) self.remaining_value self.task_value.copy() self.done_flags np.zeros(n_tasks, dtypebool) # 卫星能源简单按常量消耗 self.energy np.ones(n_sats) * 1.0 def reset(self): self.current_time self.windows[start].min() self.remaining_value self.task_value.copy() self.done_flags np.zeros(self.n_tasks, dtypebool) self.energy np.ones(self.n_sats) return self._get_obs() def step(self, actions): # actions: (n_sats,), 每颗卫星选一个任务编号或 -1 表示空闲 reward 0.0 for sat_id, task_id in enumerate(actions): if task_id 0: continue # 检查该卫星在这个时间步是否能看到该任务 can_see self._is_visible(sat_id, task_id, self.current_time) if not can_see: reward - 0.5 # 无效占用给一个负惩罚 continue # 完成观测拿到剩余价值但会消耗能源 gain self.remaining_value[task_id] reward gain self.remaining_value[task_id] 0.0 self.done_flags[task_id] True self.energy[sat_id] - 0.2 # 时间推进 self.current_time self.dt # 超时未完成的任务每个扣分 expired (self.windows[end] self.current_time) (~self.done_flags) reward - 1.0 * self.remaining_value[expired].sum() self.remaining_value[~self.done_flags] 0.0 self.done_flags | expired done self.current_time self.end_time return self._get_obs(), reward, done, {} def _is_visible(self, sat_id, task_id, t): mask ( (self.windows[sat_id] sat_id) (self.windows[task_id] task_id) (self.windows[start] t) (self.windows[end] t) ) return mask.any() def _get_obs(self): obs [] for sat_id in range(self.n_sats): local np.zeros(self.n_tasks 1) local[0] self.energy[sat_id] for task_id in range(self.n_tasks): if self._is_visible(sat_id, task_id, self.current_time): local[task_id 1] self.remaining_value[task_id] obs.append(local) return np.array(obs, dtypenp.float32) # shape: (n_sats, n_tasks1)这段代码的关键点在于环境不自己做轨道传播只查表。_is_visible用当前时间和 CSV 中的窗口做区间判断这是离线桥最舒服的用法。step中的奖励拆成三部分成功完成任务的收益、无效动作的负惩罚、超时任务的损失。能源消耗让智能体学会不要把所有任务都抢着做完因为能源用尽后再高价值的任务也做不了。3.4 环境参数表决策步长、窗口容差、任务价值环境的可调参数直接影响训练难度和实验结果可信度。下表是我在一组 6 星 8 任务实验中常用的配置参数推荐值说明决策步长 dt60 秒与 STK 报告默认步长一致太大损失调度精度卫星数量6 颗起步越小越好方便观察智能体行为任务数量8-12 个保证每个智能体有多次决策机会窗口容差1 秒CSV 时间与 RL 时间步取整造成的偏差任务初始价值10.0超时扣分设为 1.0让“错过”比“不做”更贵能源消耗0.2/次每颗卫星最多约做 5 次观测强制资源约束这里的窗口容差很值得多说一句。STK 导出的窗口起止时间精确到毫秒而 RL 环境用整数秒做决策步长。如果不做容差处理窗口恰好从 59.8 秒开始那个步长就会误判“看不见”。常见做法是在环境初始化时把所有窗口的 start 向上取整、end 向下取整再预留 1 秒容差。4. 用 MAPPO 训练多智能体调度策略4.1 为什么 MAPPO 在这类调度问题上顺手多智能体强化学习算法里Q 类方法如 QMIX、IQL 在离散动作上有天然优势但卫星调度中任务窗口互相冲突每个智能体的回报强烈依赖其他智能体的动作独立 Q 学习很容易陷入非平稳震荡。MAPPO 属于基于策略梯度的算法通过“集中训练、分布执行”缓解这个问题每个卫星的 actor 只看局部观测训练时共享同一个 criticcritic 能看到全局状态。MAPPO 的另一个好处是实现和 PPO 几乎一样超参数经验丰富。许多深度强化学习综述和开源实现都以 PPO 系列为基线工程上要跑通一条多智能体训练管线MAPPO 是改动最少的选择。相比之下基于模型强化学习、离线强化学习这些新方向更适合后续做算法改进不建议第一次实验就上手。4.2 网络结构与观测编码模型结构保持朴素actor 和 critic 都是两层 MLP。actor 输入某一颗卫星的局部观测输出动作概率分布critic 输入把所有卫星的观测拼接成的全局观测输出一个标量 value。import torch import torch.nn as nn class Actor(nn.Module): def __init__(self, obs_dim, action_dim, hidden128): super().__init__() self.net nn.Sequential( nn.Linear(obs_dim, hidden), nn.ReLU(), nn.Linear(hidden, hidden), nn.ReLU(), nn.Linear(hidden, action_dim), nn.Softmax(dim-1) ) def forward(self, obs): return self.net(obs) class Critic(nn.Module): def __init__(self, global_obs_dim, hidden128): super().__init__() self.net nn.Sequential( nn.Linear(global_obs_dim, hidden), nn.ReLU(), nn.Linear(hidden, hidden), nn.ReLU(), nn.Linear(hidden, 1) ) def forward(self, global_obs): return self.net(global_obs)观测编码上有一个容易犯的错actor 的局部观测必须只包含该卫星自己能感知的信息。第 3 章环境里每个局部向量是“能源 每个任务当下是否可见 剩余价值”这正是 actor 该用的。critic 的全局观测是所有局部观测的拼接训练时可以让它看到全部执行时不依赖它。4.3 MAPPO 训练循环的最小实现MAPPO 的训练循环分三步先跑若干回合收集样本再算 GAE 优势最后用 PPO 目标更新 actor 和 critic。下面是一个只依赖 PyTorch 的最小训练循环省略了 Buffer 类的完整实现但接口写清楚。def train_mappo(env, actor, critic, epochs30, rollouts10, lr3e-4, gamma0.99, lam0.95, clip0.2): opt_actor torch.optim.Adam(actor.parameters(), lrlr) opt_critic torch.optim.Adam(critic.parameters(), lrlr) for epoch in range(epochs): # 1. 收集样本 buffers [] for _ in range(rollouts): obs env.reset() done False traj [] while not done: obs_t torch.FloatTensor(obs) # 每颗卫星用自己的 actor 选动作 actions [] logprobs [] for sat_id in range(env.n_sats): dist torch.distributions.Categorical(actor(obs_t[sat_id])) act dist.sample() actions.append(act.item()) logprobs.append(dist.log_prob(act)) global_obs obs_t.flatten().unsqueeze(0) value critic(global_obs) next_obs, reward, done, _ env.step(actions) traj.append((obs, actions, logprobs, reward, value, done)) obs next_obs buffers.append(traj) # 2. 计算 return 与 advantage简化版 GAE for traj in buffers: returns [] advs [] g 0 next_value 0 for (obs, actions, logprobs, reward, value, done) in reversed(traj): g reward gamma * g returns.insert(0, g) adv g - value.item() advs.insert(0, adv) returns torch.FloatTensor(returns).unsqueeze(-1) advs torch.FloatTensor(advs).unsqueeze(-1) # 3. PPO 更新 for _ in range(4): ratio torch.exp(torch.FloatTensor(logprobs).unsqueeze(-1) - torch.FloatTensor(logprobs).detach().unsqueeze(-1)) ratio torch.clamp(ratio, 1e-8, 1e8) loss -torch.min(ratio * advs, torch.clamp(ratio, 1 - clip, 1 clip) * advs).mean() opt_actor.zero_grad() loss.backward() opt_actor.step() value_loss torch.nn.functional.mse_loss(critic(global_obs), returns) opt_critic.zero_grad() value_loss.backward() opt_critic.step()上面这段代码把 GAE 简化成“单步 return 减 value”是为了可读性真正要跑收敛建议直接用标准 GAE。注意 PPO 更新里多次使用同一个 batch所以 logprobs 要么保存初始值要么在采样时固定否则 ratio 会变成无意义的常数。实际训练时我会把logprobs存入 buffer用detach() clone()固定旧策略的对数概率。4.4 训练监控奖励曲线之外还要看覆盖率MAPPO 训练最容易被假象骗到。奖励曲线在上涨代表 agent 学会了“在窗口内随便选一个任务”但任务价值高的窗口和低价值窗口混在一起整体覆盖率可能仍然很低。因此训练日志里除了 loss 和 mean reward至少还要记录任务完成率完成观测的任务数 / 总任务数。冲突次数两个卫星同时指向同一任务且造成重复占用的次数。能源耗尽卫星数超过一半卫星能源耗尽说明奖励里能源约束过弱或过强。超参数层面我通常从 hidden 128、lr 3e-4、gamma 0.99、lam 0.95、batch 2048 起步。如果任务价值波动太大导致训练发散就把 reward 除以一个常数做缩放或者把任务价值改成 log 收益。本地 CPU 训练 50 个 epoch 大约几十分钟足够判断链路是否通畅。5. 避坑清单5 个很常见的翻车点5.1 COM 连接时报错“Class not registered”现象win32.Dispatch(STK11.Application)抛出pywintypes.com_error提示 class not registered。原因最常见的是 Python 位数和 STK11 位数不一致。STK11 安装时默认注册的是 32 位 COM 组件如果机器上装了 64 位 Python就找不到 ProgID。解决换用 32 位 Python 3.8 对应位数的 pywin32。安装完 STK11 后用管理员身份跑一次 Python确保 COM 注册表项可见。另外有少数安全软件会拦截 COM 调用出现这类报错时先把杀毒软件对 Python 进程的拦截关掉再试。5.2 可见性窗口的时间比环境时间快了一步现象环境中某个任务明明在 STK 报告里能看到但_is_visible总是返回 False而且误差恰好是 1 个决策步长。原因STK 导出 UTCG 字符串时按毫秒保留转成 Unix 秒后我直接取整到最近秒窗口起点 00:59.9 被取整成 60.0而环境当前时间是 60.0如果 end 也被取整成 59.0窗口就被截没了。解决导入 CSV 后统一做“start 向上取整end 向下取整”同时给窗口两端各加 1 秒容差。不要用手工 Excel 靠肉眼检查直接写代码打一条window_length统计看看是否出现负数长度。5.3 奖励设计让智能体学会“假执行”现象训练 30 个 epoch 后 reward 涨到很高但把动作序列导回 STK发现卫星根本没指向目标。原因环境代码里只检查了动作对应的任务“可见”和“未完成”实际调度场景还约束载荷开机时长、姿态转换时间。环境没建模这些约束算法自然就不学。解决环境里至少要建模两个物理约束一个动作只能发生在窗口内且窗口剩余时间大于最短观测时长连续两次动作之间留姿态转换死区如果小于死区直接判无效。这能逼智能体学会规划而不是疯狂点按钮骗奖励。5.4 MAPPO 训练震荡reward 曲线像心电图现象前几 epoch 收敛不错后面突然掉到负再慢慢回来反复循环。原因多智能体环境中一个智能体的策略更新会改变其他智能体的观测分布导致环境非平稳。mapPO 的集中 critic 本应缓解这个问题但如果全局观测没有归一化critic 输入尺度差异大value 预测不稳定。解决把全局观测做成 z-score 归一化replay buffer 里保存归一化的统计量。训练时把 learning rate 从 3e-4 降到 1e-4PPO clip 从 0.2 降到 0.1。再不行就分成多个小 batch 多更新几次而不是一个大 batch 更新一次。5.5 把 STK 坐标系当成本地坐标系现象自算卫星和目标距离发现结果和 STK 可见性不一致有的窗口明明距离很近却说不可见。原因STK 报告里可以给惯性系、地固系、站心系不同坐标拿去和把地图坐标混在一起算距离必然对不上。解决调度实验里不要从坐标二次推导可见性直接用 STK Access 结果。如果有人非要自己算距离务必统一到同一个坐标系和时间基准并检查地固坐标系与惯性系的转换。这个坑我踩过整整两天后来把所有距离计算全删了换成 Access 区间查表实验才继续下去。6. 闭环验证把训练好的策略落回 STK11 场景6.1 用 Connect 命令把动作序列写回 STK训练完成后最直观的验证是让 STK11 按策略动作序列跑一遍。我们已通过 COM 连接了 STK可以用root.ExecuteCommand发送 Connect 指令。下面是一个把某一颗卫星指向某个任务的动作回放到场景中的示意def replay_action(root, sat_name, task_name, scenario_time): # 切到目标相关对象 root.ExecuteCommand(fSelect / Scenario Scenario1) root.ExecuteCommand(fSelect / Satellite {sat_name}) # 设置场景时间STK 会按新时间刷新位置 root.ExecuteCommand(fSetTime / Scenario Scenario1 {scenario_time}) # 简单姿态指令让卫星传感器指向任务目标 root.ExecuteCommand( fSetAttitude / Satellite {sat_name} fSelectedAxes Satellite {sat_name} Body fCoordAxes Geocentric Equatorial Inertial fTime {scenario_time} Axis Point Target {task_name} )这段指令的作用是让 STK 把场景时间设到决策时刻并把卫星姿态指向目标任务。STK 会根据轨道递推画出卫星、地面站和波束指向我们可以动画观察调度过程是否合理。6.2 用统计指标判断调度策略好坏回放到 STK 之后不能只说“效果不错”。我一般用这三个指标指标计算方式判定经验任务完成率成功观测任务数 / 总任务数6 星 8 任务下应高于 0.7平均完成时间任务被观测时刻 - 任务最早可见时刻越小越说明策略会“抢早”冲突率被多个卫星同时选中的任务数 / 总任务数低于 0.1 算正常这三个指标要和 STK 的可视化结果交叉验证。任务完成率高但冲突率高说明算法学会了“多星抢活”不是真的会调度完成率低但平均完成时间小说明策略过于保守。6.3 参数敏感性实验从 6 星到 12 星的扩展把这套链路做成了就可以开始真正的实验跑参数敏感性。我建议按“加卫星 - 加任务 - 加窗口重叠度”的三步走。第一步固定任务数量把卫星从 6 颗加到 12 颗观察 MAPPO 收敛速度和最终完成率。第二步固定卫星数把任务从 8 个加到 16 个重点看每个智能体的局部观测是否还容得下所有任务信息。第三步把任务区域设置的更靠近让窗口重叠度变高这时算法才会暴露出真正的调度能力。这三步做下来你就能够回答“这个方案值不值得投入到真实系统”了。以我的经验20 颗卫星以下、任务规模小于 50 时MAPPO 这套组合比规则算法在完成率上高 10-20 个百分点代价是训练一次要几小时且需要人工盯着训练曲线。真实系统对实时性要求高建议训练一次后固定模型在线只做动作推理不要在星上或调度中心训模型。最后说一个我自己养成的习惯无论结果多好训练出的调度方案我都会回放到 STK 里逐秒看一下而不是只看 reward 曲线。STK 里多颗卫星的波束同时指向同一个目标时你会直观地意识到奖励设计漏了约束单个卫星在窗口开始前 1 秒就转动姿态时你会想起姿态死区没建模。这种“把数字嵌入场景”的直觉比调超参数更值钱。希望这篇实验笔记能帮你在自己的调度实验里少走几段弯路。本文还有配套的精品资源点击获取
简介一份基于Python与STK11的多智能体强化学习卫星调度实验资源面向希望入门强化学习与卫星任务规划的学习者也适合作为毕设、课程设计或工程实训项目。资源包含完整的任务生成与访问时段计算流程mission.py定义随机任务属性create_mission.py批量生成任务并存入CSVcompute_access.py连接STK场景计算可访问时段另有PyTorch模型权重、可视化截图和STK场景文件等。压缩包共241个文件约79.6MB主要包含13个Python脚本、39个CSV数据文件、多组场景与备份文件、63张过程图片及7个模型权重文件结构清晰便于按模块研读。目前已有132人学习下载适合希望快速跑通卫星调度实验、理解多智能体强化学习落地细节的开发者。通过修改任务规模与随机参数可扩展为不同场景的调度实验是兼具教学与二次开发价值的参考资料。1. 卫星调度为什么值得让 STK11 和多智能体强化学习出现在同一个实验里遥感卫星调度最大的难题不是“算一颗卫星什么时候路过目标”而是多颗卫星争抢任务、地面站资源、能源和存储时怎么在十分钟内给出一个全局不冲突的方案。我刚接触卫星调度时也试着写规则先到先服务、按优先级插队最后全部翻车——规则多到没法加而实际调度窗口一变整张表就废了。把 Python 和多智能体强化学习结合起来正是为了把这套决策交给算法每颗卫星是一个智能体可见性窗口、任务价值、能源状态是环境给它的观测它自己学会什么时候接活、什么时候放弃。STK11 在其中扮演“环境引擎”的角色负责把轨道预报、传感器覆盖、星地可见性这些几何算得准Python 侧只拿到干净的时间窗口不碰轨道微积分。两者的融合实验等于把“模型可信”和“决策智能”拼到了一起适合研究生课题、预研项目也适合想验证 MARL 算法能不能落地的工程师。这套链路看起来复杂实际拆开只有四块STK 数据桥、环境封装、MARL 训练、闭环回放。下面按我自己的落地顺序写每一步都给出能跑的代码和参数最后把最容易耽误时间的坑单独列出来。2. 数据链路从 STK11 把可见性窗口拿到 Python 里2.1 为什么不在 Python 里自己算轨道而是用 STK11 提供真实感见到这类标题第一反应一定是调度所需的信息为什么不由强化学习环境自己算道理很简单卫星调度的“几何真实感”远大于“决策复杂度”。一颗 LEO 卫星从北京上空掠过地面站能不能建链取决于轨道根数、J2 摄动、传感器半角、最大仰角、大气时延自己写这套传播和覆盖逻辑至少两三个月而且验证困难。STK11 的价值在于它把这些几何计算全部封装好了。我们只需要在 STK 里建立卫星、地面站、传感器设置约束STK 会算出每个可见窗口的起止时间。Python 侧的强化学习拿到的是“窗口列表”这种领域无关的数据不需要关心窗口背后的坐标变换。常见做法是把 STK 当离线仿真器先把场景跑完导出可见性表再让 Python 读表训练。这种“离线文件桥”比在线实时调用 COM 稳得多也是我个人推荐的起步路径。2.2 两条桥接路线离线文件桥与在线 COM 桥先走哪条STK11 和 Python 之间的桥本质上只有两种。一种是离线桥STK 把 Access 报告导出成 CSV 或 TXTPython 用 pandas 读进来。另一种是在线桥Python 通过 COM 接口或 TCP 端口直接控制 STK 场景随时问“现在这颗卫星能看到谁”。在线桥适合最后做闭环验证因为 GPU 训练时反复起 STK 进程会慢到崩溃。我在实际实验里是这么分配的训练前用离线桥把一整天 86400 秒内所有可见窗口生成一张大表后面每次 step 只是查表训练结束后再用 COM 桥把策略选出的动作回传到 STK 场景做可视化复现和覆盖评估。这样训练稳定性高又保留了“融合”的感觉。2.3 在 STK11 里先造一个能用的调度场景在 STK11 里造场景不建议从零写脚本先在 UI 里点一遍反而快。我一般会这样配置一个最小场景新建 Scenario时间范围 24 小时步长 60 秒。添加 6 颗 LEO 卫星轨道高度 500-800km倾角 60-98 度轨道面错开。添加 4 个地面站分别放在北京、西安、海口、喀什。为卫星添加简单圆锥传感器半角 45 度表示星载遥感载荷。对卫星与地面站、卫星与目标区域分别做 Access 计算。这些操作在 STK 里都是菜单点击不是本文重点。重点是把 Access 结果变成 Python 能消费的数据。STK11 的表现形式是把卫星、地面站都当作对象Access 计算出的可见窗口会以报告形式给出我们需要选中窗口数据区间导出为带起止时刻的表格。2.4 把 Access 报告导出为 Python 能消费的时间窗口表在 STK11 中对卫星和地面站做 Access 计算后右键场景对象选择“Generate Report”选择 Access 相关的 Interval 数据导出格式用 CSV。导出的表格大体长这样access_start_utcg,access_end_utcg,satellite,ground_station 01 Jul 2024 00:12:34.000,01 Jul 2024 00:17:12.000,SAT1,GS1 01 Jul 2024 00:31:05.000,01 Jul 2024 00:38:44.000,SAT1,GS2直接用这份 CSV 做训练不是不行但字符串时间在环境里每次加减会很别扭。我一般会在 Python 侧先做一次清洗把 UTCG 时间转成 Unix 秒再补一列窗口 ID。这样环境里所有逻辑都基于整数秒判断是否在窗口内就是两次减法的事。2.5 最小 COM 连接脚本先确认 STK11 能被 Python 叫醒离线 CSV 准备好后我们仍然需要一个最小 COM 连接脚本确认 Python 和 STK11 之间的在线通道也通。STK11 安装后会在 Windows 注册 COM ProgIDPython 用 pywin32 调用代码如下import pythoncom import win32com.client as win32 pythoncom.CoInitialize() # 尝试连接 STK11 应用 try: app win32.Dispatch(STK11.Application) app.Visible True app.UserControl True root app.Personality2 # STK11 的根对象早期 COM 接口形态 print(STK11 COM connect OK) print(Scenario path:, root.CurrentScenario) except Exception as e: print(Connect failed:, repr(e)) finally: pythoncom.CoUninitialize()这段脚本的逻辑很直接先用 pythoncom 初始化 COM 线程模型再通过 ProgID“STK11.Application”拿到应用对象。Personality2是 STK 对象模型里的根入口所有卫星、地面站、报告都挂在它下面。后续我们在第六章用它做闭环回放时会看到更多用法。需要注意连接成功的前提是 STK11 已经安装且许可可用如果你的机器上是 STK 12ProgID 要改成“STK12.Application”对象模型基本一致。连接报错时先看第 5 章的避坑清单很多坑都出在这一步。3. 把可见性窗口变成多智能体强化学习环境3.1 一个卫星调度问题如何变成 MDP 五元组多智能体强化学习环境的第一件事是定义状态、动作、奖励、转移。卫星调度天然具有马尔可夫过程特征当前时刻所有任务的剩余价值和窗口可访问关系足够决策决策落地后时间推进进入下一状态。状态按时间步切片。假设决策步长是 60 秒那环境里每一秒或每 60 秒给每个智能体一个观测向量。观测至少要包含当前时间、该卫星可见的所有任务窗口、每个任务的剩余价值、卫星剩余能源。动作的定义常见有两种一是“选择某个任务执行”离散动作空间二是“以什么姿态指向哪个目标”连续动作空间。起步阶段我强烈建议只用离散动作因为 STK 的可见性已经在几何上约束了“能不能做”决策层没必要再引入姿态连续量。动作空间大小设为任务数量 1多出的一个表示“空闲等待”。3.2 为什么用多智能体而不是一个全局智能体单智能体强化学习也能处理多卫星调度做法是把所有卫星状态拼成一个超长向量让一个策略网络输出所有卫星的动作。这种方案在卫星数量少时跑得通但一旦新加一颗卫星输入输出维度全变模型必须重新训练扩展性很差。多智能体的核心价值是把控制权下放到每颗卫星每颗卫星一个 actor只用自己的局部观测做决策训练时再用一个集中 critic 评估全局状态。这种“集中训练、分布执行”的框架既避免了独立训练时环境非平稳导致的不收敛又保留了对卫星数量变化的扩展能力。现在的多智能体深度学习、深度强化学习相关开源库大多也是这个套路。3.3 环境类实现最小可运行的卫星调度环境下面给一个能直接跑的 Gymnasium 风格环境类。它读取 CSV 中的可见窗口每个 step 推进 60 秒所有卫星同时决策。import numpy as np import pandas as pd class SatelliteSchedulingEnv: def __init__(self, access_csv, n_sats6, n_tasks8, dt60.0): self.dt dt self.n_sats n_sats self.n_tasks n_tasks # 将 CSV 中的窗口读进来时间已提前转为 Unix 秒 self.windows pd.read_csv(access_csv) self.current_time self.windows[start].min() self.end_time self.windows[end].max() # 每个任务一个初始价值 self.task_value np.array([10.0] * n_tasks) self.remaining_value self.task_value.copy() self.done_flags np.zeros(n_tasks, dtypebool) # 卫星能源简单按常量消耗 self.energy np.ones(n_sats) * 1.0 def reset(self): self.current_time self.windows[start].min() self.remaining_value self.task_value.copy() self.done_flags np.zeros(self.n_tasks, dtypebool) self.energy np.ones(self.n_sats) return self._get_obs() def step(self, actions): # actions: (n_sats,), 每颗卫星选一个任务编号或 -1 表示空闲 reward 0.0 for sat_id, task_id in enumerate(actions): if task_id 0: continue # 检查该卫星在这个时间步是否能看到该任务 can_see self._is_visible(sat_id, task_id, self.current_time) if not can_see: reward - 0.5 # 无效占用给一个负惩罚 continue # 完成观测拿到剩余价值但会消耗能源 gain self.remaining_value[task_id] reward gain self.remaining_value[task_id] 0.0 self.done_flags[task_id] True self.energy[sat_id] - 0.2 # 时间推进 self.current_time self.dt # 超时未完成的任务每个扣分 expired (self.windows[end] self.current_time) (~self.done_flags) reward - 1.0 * self.remaining_value[expired].sum() self.remaining_value[~self.done_flags] 0.0 self.done_flags | expired done self.current_time self.end_time return self._get_obs(), reward, done, {} def _is_visible(self, sat_id, task_id, t): mask ( (self.windows[sat_id] sat_id) (self.windows[task_id] task_id) (self.windows[start] t) (self.windows[end] t) ) return mask.any() def _get_obs(self): obs [] for sat_id in range(self.n_sats): local np.zeros(self.n_tasks 1) local[0] self.energy[sat_id] for task_id in range(self.n_tasks): if self._is_visible(sat_id, task_id, self.current_time): local[task_id 1] self.remaining_value[task_id] obs.append(local) return np.array(obs, dtypenp.float32) # shape: (n_sats, n_tasks1)这段代码的关键点在于环境不自己做轨道传播只查表。_is_visible用当前时间和 CSV 中的窗口做区间判断这是离线桥最舒服的用法。step中的奖励拆成三部分成功完成任务的收益、无效动作的负惩罚、超时任务的损失。能源消耗让智能体学会不要把所有任务都抢着做完因为能源用尽后再高价值的任务也做不了。3.4 环境参数表决策步长、窗口容差、任务价值环境的可调参数直接影响训练难度和实验结果可信度。下表是我在一组 6 星 8 任务实验中常用的配置参数推荐值说明决策步长 dt60 秒与 STK 报告默认步长一致太大损失调度精度卫星数量6 颗起步越小越好方便观察智能体行为任务数量8-12 个保证每个智能体有多次决策机会窗口容差1 秒CSV 时间与 RL 时间步取整造成的偏差任务初始价值10.0超时扣分设为 1.0让“错过”比“不做”更贵能源消耗0.2/次每颗卫星最多约做 5 次观测强制资源约束这里的窗口容差很值得多说一句。STK 导出的窗口起止时间精确到毫秒而 RL 环境用整数秒做决策步长。如果不做容差处理窗口恰好从 59.8 秒开始那个步长就会误判“看不见”。常见做法是在环境初始化时把所有窗口的 start 向上取整、end 向下取整再预留 1 秒容差。4. 用 MAPPO 训练多智能体调度策略4.1 为什么 MAPPO 在这类调度问题上顺手多智能体强化学习算法里Q 类方法如 QMIX、IQL 在离散动作上有天然优势但卫星调度中任务窗口互相冲突每个智能体的回报强烈依赖其他智能体的动作独立 Q 学习很容易陷入非平稳震荡。MAPPO 属于基于策略梯度的算法通过“集中训练、分布执行”缓解这个问题每个卫星的 actor 只看局部观测训练时共享同一个 criticcritic 能看到全局状态。MAPPO 的另一个好处是实现和 PPO 几乎一样超参数经验丰富。许多深度强化学习综述和开源实现都以 PPO 系列为基线工程上要跑通一条多智能体训练管线MAPPO 是改动最少的选择。相比之下基于模型强化学习、离线强化学习这些新方向更适合后续做算法改进不建议第一次实验就上手。4.2 网络结构与观测编码模型结构保持朴素actor 和 critic 都是两层 MLP。actor 输入某一颗卫星的局部观测输出动作概率分布critic 输入把所有卫星的观测拼接成的全局观测输出一个标量 value。import torch import torch.nn as nn class Actor(nn.Module): def __init__(self, obs_dim, action_dim, hidden128): super().__init__() self.net nn.Sequential( nn.Linear(obs_dim, hidden), nn.ReLU(), nn.Linear(hidden, hidden), nn.ReLU(), nn.Linear(hidden, action_dim), nn.Softmax(dim-1) ) def forward(self, obs): return self.net(obs) class Critic(nn.Module): def __init__(self, global_obs_dim, hidden128): super().__init__() self.net nn.Sequential( nn.Linear(global_obs_dim, hidden), nn.ReLU(), nn.Linear(hidden, hidden), nn.ReLU(), nn.Linear(hidden, 1) ) def forward(self, global_obs): return self.net(global_obs)观测编码上有一个容易犯的错actor 的局部观测必须只包含该卫星自己能感知的信息。第 3 章环境里每个局部向量是“能源 每个任务当下是否可见 剩余价值”这正是 actor 该用的。critic 的全局观测是所有局部观测的拼接训练时可以让它看到全部执行时不依赖它。4.3 MAPPO 训练循环的最小实现MAPPO 的训练循环分三步先跑若干回合收集样本再算 GAE 优势最后用 PPO 目标更新 actor 和 critic。下面是一个只依赖 PyTorch 的最小训练循环省略了 Buffer 类的完整实现但接口写清楚。def train_mappo(env, actor, critic, epochs30, rollouts10, lr3e-4, gamma0.99, lam0.95, clip0.2): opt_actor torch.optim.Adam(actor.parameters(), lrlr) opt_critic torch.optim.Adam(critic.parameters(), lrlr) for epoch in range(epochs): # 1. 收集样本 buffers [] for _ in range(rollouts): obs env.reset() done False traj [] while not done: obs_t torch.FloatTensor(obs) # 每颗卫星用自己的 actor 选动作 actions [] logprobs [] for sat_id in range(env.n_sats): dist torch.distributions.Categorical(actor(obs_t[sat_id])) act dist.sample() actions.append(act.item()) logprobs.append(dist.log_prob(act)) global_obs obs_t.flatten().unsqueeze(0) value critic(global_obs) next_obs, reward, done, _ env.step(actions) traj.append((obs, actions, logprobs, reward, value, done)) obs next_obs buffers.append(traj) # 2. 计算 return 与 advantage简化版 GAE for traj in buffers: returns [] advs [] g 0 next_value 0 for (obs, actions, logprobs, reward, value, done) in reversed(traj): g reward gamma * g returns.insert(0, g) adv g - value.item() advs.insert(0, adv) returns torch.FloatTensor(returns).unsqueeze(-1) advs torch.FloatTensor(advs).unsqueeze(-1) # 3. PPO 更新 for _ in range(4): ratio torch.exp(torch.FloatTensor(logprobs).unsqueeze(-1) - torch.FloatTensor(logprobs).detach().unsqueeze(-1)) ratio torch.clamp(ratio, 1e-8, 1e8) loss -torch.min(ratio * advs, torch.clamp(ratio, 1 - clip, 1 clip) * advs).mean() opt_actor.zero_grad() loss.backward() opt_actor.step() value_loss torch.nn.functional.mse_loss(critic(global_obs), returns) opt_critic.zero_grad() value_loss.backward() opt_critic.step()上面这段代码把 GAE 简化成“单步 return 减 value”是为了可读性真正要跑收敛建议直接用标准 GAE。注意 PPO 更新里多次使用同一个 batch所以 logprobs 要么保存初始值要么在采样时固定否则 ratio 会变成无意义的常数。实际训练时我会把logprobs存入 buffer用detach() clone()固定旧策略的对数概率。4.4 训练监控奖励曲线之外还要看覆盖率MAPPO 训练最容易被假象骗到。奖励曲线在上涨代表 agent 学会了“在窗口内随便选一个任务”但任务价值高的窗口和低价值窗口混在一起整体覆盖率可能仍然很低。因此训练日志里除了 loss 和 mean reward至少还要记录任务完成率完成观测的任务数 / 总任务数。冲突次数两个卫星同时指向同一任务且造成重复占用的次数。能源耗尽卫星数超过一半卫星能源耗尽说明奖励里能源约束过弱或过强。超参数层面我通常从 hidden 128、lr 3e-4、gamma 0.99、lam 0.95、batch 2048 起步。如果任务价值波动太大导致训练发散就把 reward 除以一个常数做缩放或者把任务价值改成 log 收益。本地 CPU 训练 50 个 epoch 大约几十分钟足够判断链路是否通畅。5. 避坑清单5 个很常见的翻车点5.1 COM 连接时报错“Class not registered”现象win32.Dispatch(STK11.Application)抛出pywintypes.com_error提示 class not registered。原因最常见的是 Python 位数和 STK11 位数不一致。STK11 安装时默认注册的是 32 位 COM 组件如果机器上装了 64 位 Python就找不到 ProgID。解决换用 32 位 Python 3.8 对应位数的 pywin32。安装完 STK11 后用管理员身份跑一次 Python确保 COM 注册表项可见。另外有少数安全软件会拦截 COM 调用出现这类报错时先把杀毒软件对 Python 进程的拦截关掉再试。5.2 可见性窗口的时间比环境时间快了一步现象环境中某个任务明明在 STK 报告里能看到但_is_visible总是返回 False而且误差恰好是 1 个决策步长。原因STK 导出 UTCG 字符串时按毫秒保留转成 Unix 秒后我直接取整到最近秒窗口起点 00:59.9 被取整成 60.0而环境当前时间是 60.0如果 end 也被取整成 59.0窗口就被截没了。解决导入 CSV 后统一做“start 向上取整end 向下取整”同时给窗口两端各加 1 秒容差。不要用手工 Excel 靠肉眼检查直接写代码打一条window_length统计看看是否出现负数长度。5.3 奖励设计让智能体学会“假执行”现象训练 30 个 epoch 后 reward 涨到很高但把动作序列导回 STK发现卫星根本没指向目标。原因环境代码里只检查了动作对应的任务“可见”和“未完成”实际调度场景还约束载荷开机时长、姿态转换时间。环境没建模这些约束算法自然就不学。解决环境里至少要建模两个物理约束一个动作只能发生在窗口内且窗口剩余时间大于最短观测时长连续两次动作之间留姿态转换死区如果小于死区直接判无效。这能逼智能体学会规划而不是疯狂点按钮骗奖励。5.4 MAPPO 训练震荡reward 曲线像心电图现象前几 epoch 收敛不错后面突然掉到负再慢慢回来反复循环。原因多智能体环境中一个智能体的策略更新会改变其他智能体的观测分布导致环境非平稳。mapPO 的集中 critic 本应缓解这个问题但如果全局观测没有归一化critic 输入尺度差异大value 预测不稳定。解决把全局观测做成 z-score 归一化replay buffer 里保存归一化的统计量。训练时把 learning rate 从 3e-4 降到 1e-4PPO clip 从 0.2 降到 0.1。再不行就分成多个小 batch 多更新几次而不是一个大 batch 更新一次。5.5 把 STK 坐标系当成本地坐标系现象自算卫星和目标距离发现结果和 STK 可见性不一致有的窗口明明距离很近却说不可见。原因STK 报告里可以给惯性系、地固系、站心系不同坐标拿去和把地图坐标混在一起算距离必然对不上。解决调度实验里不要从坐标二次推导可见性直接用 STK Access 结果。如果有人非要自己算距离务必统一到同一个坐标系和时间基准并检查地固坐标系与惯性系的转换。这个坑我踩过整整两天后来把所有距离计算全删了换成 Access 区间查表实验才继续下去。6. 闭环验证把训练好的策略落回 STK11 场景6.1 用 Connect 命令把动作序列写回 STK训练完成后最直观的验证是让 STK11 按策略动作序列跑一遍。我们已通过 COM 连接了 STK可以用root.ExecuteCommand发送 Connect 指令。下面是一个把某一颗卫星指向某个任务的动作回放到场景中的示意def replay_action(root, sat_name, task_name, scenario_time): # 切到目标相关对象 root.ExecuteCommand(fSelect / Scenario Scenario1) root.ExecuteCommand(fSelect / Satellite {sat_name}) # 设置场景时间STK 会按新时间刷新位置 root.ExecuteCommand(fSetTime / Scenario Scenario1 {scenario_time}) # 简单姿态指令让卫星传感器指向任务目标 root.ExecuteCommand( fSetAttitude / Satellite {sat_name} fSelectedAxes Satellite {sat_name} Body fCoordAxes Geocentric Equatorial Inertial fTime {scenario_time} Axis Point Target {task_name} )这段指令的作用是让 STK 把场景时间设到决策时刻并把卫星姿态指向目标任务。STK 会根据轨道递推画出卫星、地面站和波束指向我们可以动画观察调度过程是否合理。6.2 用统计指标判断调度策略好坏回放到 STK 之后不能只说“效果不错”。我一般用这三个指标指标计算方式判定经验任务完成率成功观测任务数 / 总任务数6 星 8 任务下应高于 0.7平均完成时间任务被观测时刻 - 任务最早可见时刻越小越说明策略会“抢早”冲突率被多个卫星同时选中的任务数 / 总任务数低于 0.1 算正常这三个指标要和 STK 的可视化结果交叉验证。任务完成率高但冲突率高说明算法学会了“多星抢活”不是真的会调度完成率低但平均完成时间小说明策略过于保守。6.3 参数敏感性实验从 6 星到 12 星的扩展把这套链路做成了就可以开始真正的实验跑参数敏感性。我建议按“加卫星 - 加任务 - 加窗口重叠度”的三步走。第一步固定任务数量把卫星从 6 颗加到 12 颗观察 MAPPO 收敛速度和最终完成率。第二步固定卫星数把任务从 8 个加到 16 个重点看每个智能体的局部观测是否还容得下所有任务信息。第三步把任务区域设置的更靠近让窗口重叠度变高这时算法才会暴露出真正的调度能力。这三步做下来你就能够回答“这个方案值不值得投入到真实系统”了。以我的经验20 颗卫星以下、任务规模小于 50 时MAPPO 这套组合比规则算法在完成率上高 10-20 个百分点代价是训练一次要几小时且需要人工盯着训练曲线。真实系统对实时性要求高建议训练一次后固定模型在线只做动作推理不要在星上或调度中心训模型。最后说一个我自己养成的习惯无论结果多好训练出的调度方案我都会回放到 STK 里逐秒看一下而不是只看 reward 曲线。STK 里多颗卫星的波束同时指向同一个目标时你会直观地意识到奖励设计漏了约束单个卫星在窗口开始前 1 秒就转动姿态时你会想起姿态死区没建模。这种“把数字嵌入场景”的直觉比调超参数更值钱。希望这篇实验笔记能帮你在自己的调度实验里少走几段弯路。本文还有配套的精品资源点击获取
