Logging

    This describes the new logger, set to 1.

    The logger is able to log any ORB topic with all included fields. Everything
    necessary is generated from the .msg file, so that only the topic name needs
    to be specified. An optional interval parameter specifies the maximum logging
    rate of a certain topic. All existing instances of a topic are logged.

    The output log format is .

    By default, logging is automatically started when arming, and stopped when
    disarming. A new log file is created for each arming session on the SD card. To
    display the current state, use logger status on the console. If you want to
    start logging immediately, use logger on. This overrides the arming state, as
    if the system was armed. logger off undoes this.

    Use

    Configuration

    The list of logged topics can be customized with a file on the SD card. Create a
    file on the card with a list of topics:

    The <interval> is optional, and if specified, defines the minimum interval in
    ms between two logged messages of this topic. If not specified, the topic is
    logged at full rate.

    The topics in this file replace all of the default logged topics.

    There are several scripts to analyze and convert logging files in the
    pyulog repository.

    Dropouts

    Logging dropouts are undesired and there are a few factors that influence the
    amount of dropouts:

    • Most SD cards we tested exhibit multiple pauses per minute. This shows
      itself as a several 100 ms delay during a write command. It causes a dropout
      if the write buffer fills up during this time. This effect depends on the SD
      card (see below).
    • Formatting an SD card can help to prevent dropouts.
    • Increasing the log buffer helps.
    • Decrease the logging rate of selected topics or remove unneeded topics from
      being logged (info.py <file> is useful for this).

    More important than the mean write speed is the maximum write time per block (of
    4 KB). This defines the minimum buffer size: the larger this maximum, the larger
    the log buffer needs to be to avoid dropouts. Logging bandwidth with the default
    topics is around 50 KB/s, which all of the SD cards satisfy.

    By far the best card we know so far is the SanDisk Extreme U3 32GB. This
    card is recommended, because it does not exhibit write time spikes (and thus
    virtually no dropouts). Different card sizes might work equally well, but the
    performance is usually different.

    You can test your own SD card with sd_bench -r 50, and report the results to
    .

    Log Streaming

    The traditional and still fully supported way to do logging is using an SD card
    on the FMU. However there is an alternative, log streaming, which sends the
    same logging data via MAVLink. This method can be used for example in cases
    where the FMU does not have an SD card slot (eg. Intel Aero) or simply to avoid
    having to deal with SD cards. Both methods can be used independently and at the
    same time.

    The requirement is that the link provides at least ~50KB/s, so for example a
    WiFi link. And only one client can request log streaming at the same time. The
    connection does not need to be reliable, the protocol is designed to handle
    drops.

    • QGroundControl:

    • If log streaming does not start, make sure the is running (see
      above), and inspect the console output while starting.
    • If it still does not work, make sure that Mavlink 2 is used. Enforce it by setting MAV_PROTO_VER to 2.
    • Log streaming uses a maximum of 70% of the configured mavlink rate (-r
      parameter). If more is needed, messages are dropped. The currently used
      percentage can be inspected with mavlink status (1.8% is used in this
      example):Also make sure txerr stays at 0. If this goes up, either the NuttX sending
      buffer is too small, the physical link is saturated or the hardware is too
      slow to handle the data.