Skip to content

日志 ​

系统日志记录器 能够记录任何包含所有字段的 ORB 主题。 所有必要的信息都从 .msg 文件生成,因此只需指定主题名称即可。 一个可选的时间间隔参数可指定某个主题的最大记录速率。 所有主题的实例都会被记录下来。

输出日志格式为 ULog。

加密日志记录 也同样受支持。

用法 ​

默认情况下,日志记录会在解锁时自动开始,在锁定时停止。 每次解锁后的飞行会话都会在 SD 卡上生成一个新的日志文件。 要显示当前状态,请在控制台中使用 logger status 命令。 如果你想立即开始记录日志,使用 logger on 命令。 这会覆盖解锁状态,就好像系统已解锁一样。 使用 logger off 命令可取消此操作。

如果由于写入错误或达到 最大文件大小限制 而导致日志记录停止,PX4 会自动在一个新文件中重新开始记录日志。

要获取所有支持的记录器命令和参数的列表,请使用:

logger help

配置 ​

日志记录系统默认配置为收集合理的日志,以便通过 Flight Review 进行 飞行报告。

还可以使用 SD 卡日志记录 参数进一步配置日志记录。 下面列出了你最有可能需要更改的参数。

参数描述
SDLOG_MODE日志模式,用于定义日志记录的开始和停止时间。
- -1:禁用日志记录。
- 0:解锁时开始记录,锁定时停止(默认设置)。
- 1:从启动时开始记录,直到锁定时停止。
- 2:从启动时开始记录,直到系统关闭时停止。
- 3:根据 AUX1 RC 通道 进行记录。
- 4:从首次解锁开始记录,直到系统关闭时停止。
SDLOG_PROFILE日志记录配置文件。使用此参数可启用不太常用的日志记录/分析功能(例如,用于 EKF2 回放、用于 PID 和滤波器调优的高速率日志记录、热温度校准)。
SDLOG_MISSION创建非常小的额外 “任务日志”。
此日志 不能 用于 Flight Review,但当你需要一个用于地理标记或符合法规要求的小日志时,它会很有用。

特定情况下的有用设置:

日志记录器模块 ​

开发人员 可以通过 logger 模块进一步配置要记录的信息。 例如,这允许记录你自己的 uORB 主题。

诊断 ​

另外,已记录主题的列表也可以通过 SD 卡上的一个文件进行自定义。 在卡上创建一个文件 etc/logging/logger_topics.txt,其中包含一个主题列表(对于软件在环仿真 (SITL),文件路径是 build/px4_sitl_default/rootfs/fs/microsd/etc/logging/logger_topics.txt):

plain
<主题名称> <时间间隔> <实例>

<时间间隔> 是可选的,如果指定了该参数,则定义了该主题的两条记录消息之间的最小时间间隔(以毫秒为单位)。 如果未指定,则以全速率记录该主题。

<实例> 是可选的,如果指定了该参数,则定义了要记录的实例。 如果未指定,则记录该主题的所有实例。 要指定 <实例>,必须指定 <时间间隔>。可以将其设置为 0 以全速率记录。

此文件中的主题将替换所有默认记录的主题。

到目前为止,我们所知道的最好的卡是 闪迪至尊极速 U3 32GB 卡。推荐使用此卡,因为它不会出现写入时间尖峰(因此几乎不会出现数据丢失)。不同容量的卡可能也能正常工作,但性能通常会有所不同。

plain
sensor_accel 0 0
sensor_accel 100 1
sensor_gyro 200
sensor_mag 200 1

此配置将以全速率记录 sensor_accel 的实例 0,以 10Hz 的速率记录 sensor_accel 的实例 1,以 5Hz 的速率记录所有 sensor_gyro 实例,并以 5Hz 的速率记录 sensor_mag 的实例 1。

脚本 ​

在 pyulog 存储库中有几个用于分析和转换日志文件的脚本。

文件大小限制 ​

最大文件大小取决于文件系统和操作系统。 目前在 NuttX 上的大小限制约为 2GB。

丢帧 ​

日志记录中的数据丢失是不希望出现的,有几个因素会影响数据丢失的数量:

  • 我们测试的大多数 SD 卡每分钟都会出现多次暂停。这表现为在写入命令期间会有几百毫秒的延迟。如果在此期间写入缓冲区已满,就会导致数据丢失。这种影响取决于 SD 卡(见下文)。 这表现为在写入命令期间会有几百毫秒的延迟。 如果在此期间写入缓冲区已满,就会导致数据丢失。 这种影响取决于 SD 卡(见下文)。
  • 格式化 SD 卡有助于避免数据丢失。
  • 增大日志缓存也有效果。
  • 降低选定主题的记录速率,或者从记录中删除不需要的主题(info.py <文件> 对此很有用)。

SD 卡 ​

NuttX 支持的最大 SD 卡容量为 32GB(SD 存储卡规范版本 2.0)。 已知 闪迪至尊极速 U3 32GB 和 三星 EVO Plus 32GB 是可靠的卡(不会出现写入时间尖峰,因此几乎不会出现数据丢失)。

下表显示了基于 F4(Pixracer)、F7 和 H7 的飞行控制器的 平均顺序写入速度 [KB/s] / 每个数据块的最大写入时间(平均值)[ms]。

SD 卡F4F7H7
闪迪至尊极速 U3 32GB1500 / 151800/102900/8
三星 EVO Plus 32GB1700/10-601800/10-601900/9-60
闪迪至尊高速 Class 10 8GB348 / 40?/??/?
闪迪 Class 4 8GB212 / 60?/??/?
闪迪 Class 10 32GB(高耐用性视频监控卡)331 / 220?/??/?
雷克沙 U1(Class 10),16GB 高性能209 / 150?/??/?
闪迪至尊高速 PLUS Class 10 16GB196 /500?/??/?
闪迪 Pixtor Class 10 16GB334 / 250?/??/?
闪迪至尊极速 PLUS Class 10 32GB332 / 150?/??/?

使用默认主题时的日志记录带宽约为 50KB/s,几乎所有的 SD 卡就其平均顺序写入速度而言都能满足这一要求。

比平均写入速度更重要的是每个数据块(4KB)的最大写入时间或 fsync 时间的尖峰(或通常较高的值),因为较长的写入时间意味着需要更大的日志缓冲区来避免数据丢失。

PX4 在 F7/H7 上使用了更大的缓冲区和读取缓存,这足以补偿许多性能较差的卡的尖峰问题。 也就是说,如果你的卡的 fsync 或写入持续时间为几百毫秒,那么不建议将其用于 PX4。 你可以通过运行 sd_bench 命令并增加迭代次数(大约 100 次即可)来检查该值。

sh
sd_bench -r 100

并且同一时刻只能有一个客户端可以请求日志流。 PX4 在 F7/H7 上使用了更大的缓冲区和读取缓存来弥补其中的一些问题。

INFO

如果你对某张特定的卡有疑虑,可以运行上述测试,并将结果报告到 https://github.com/PX4/PX4-Autopilot/issues/4634。

日志流 ​

进行日志记录的传统方式(并且仍然完全受支持)是在飞行控制单元(FMU)上使用 SD 卡。 然而,还有一种替代方法,即日志流,它通过 MAVLink 发送相同的日志数据。 例如,在 FMU 没有 SD 卡插槽的情况下(如英特尔® 傲鹰 Ready to Fly 无人机),或者只是为了避免使用 SD 卡时,都可以使用这种方法。 这两种方法可以独立使用,也可以同时使用。

要求是链路至少提供约 50KB/s 的传输速率,例如 WiFi 链路。 并且同一时间只能有一个客户端请求日志流。 连接不需要是可靠的,该协议旨在处理数据丢失情况。

有不同的客户端支持 ulog 日志流:

  • PX4-Autopilot/Tools 中的 mavlink_ulog_streaming.py 脚本。
  • QGroundControl: QGC 日志流
  • MAVGCL

诊断 ​

  • 如果日志流没有启动,请确保 logger 正在运行(见上文),并在启动时检查控制台输出。

  • 如果仍然无法工作,请确保使用的是 Mavlink 2。通过将 MAV_PROTO_VER 设置为 2 来强制使用。 通过将 MAV_PROTO_VER 设置为 2 来强制使用。

  • 日志流最多使用配置的 MAVLink 速率(-r 参数)的 70%。 如果需要更大的速率,数据会丢失。 可以使用 mavlink status 命令检查当前使用的百分比(在此示例中使用了 1.8%):

    sh
    实例 #0:
            GCS 心跳:160955 微秒前
            mavlink 通道:#0
            类型:GENERIC LINK OR RADIO
            流量控制:OFF
            速率:
            发送:95.781 kB/s
            发送错误:0.000 kB/s
            接收:0.021 kB/s
            速率倍数:1.000
            ULog 速率:最大 70.0% 的 1.8%
            接受命令:是
            MAVLink 版本:2
            传输协议:UDP (14556)

    还请确保 txerr 保持为 0。 还请确保 txerr 保持为 0。如果该值上升,可能是 NuttX 发送缓冲区太小、物理链路饱和或硬件处理数据的速度太慢。

另请参阅 ​