struct mola::SharedKeyframeMap::KeyframeInsertRequest

Overview

A request from a front end to insert one keyframe into the central map.

#include <SharedKeyframeMap.h>

struct KeyframeInsertRequest
{
    // fields

    mrpt::Clock::time_point timestamp;
    std::string source_frame_id;
    mrpt::poses::CPose3DPDFGaussian pose_in_source;
    mrpt::obs::CSensoryFrame observations;
    double quality = 1.0;
};

Fields

mrpt::Clock::time_point timestamp

Time of the keyframe.

std::string source_frame_id

Identifies the requesting odometry source (e.g. “odom_lidar”). One {odom_i} frame is created per distinct source_frame_id. Use a DEDICATED name here, distinct from any frame_id the same front end also uses for dense, every-sample NavStateFilter::fuse_pose() calls (e.g. for short-term prediction): mixing the two on the same frame lets this sink’s anchor-once tie collide with the dense path’s already- present tie on the same (possibly relocalization-seeded) keyframe, which has been observed to ill-condition the graph in practice.

mrpt::poses::CPose3DPDFGaussian pose_in_source

Pose of the keyframe (vehicle/base_link) with respect to {source_frame_id}, i.e. the front end’s own odometry estimate at timestamp. The receiving backend is expected to chain consecutive requests from the same source via their relative motion (tight, reflecting the front end’s local accuracy), using the absolute value only to anchor the first keyframe of each source: this lets the backend’s own global corrections (gravity, GNSS, loop closure) override the front end’s accumulated absolute drift. The covariance is informational only: a conforming backend uses its own configured noise for these factors, not this covariance (real front ends can report pathologically tiny values, e.g. a relocalization seed).

mrpt::obs::CSensoryFrame observations

Raw observations / annotations for this keyframe (point clouds, images, IMU windows, etc.), merged into the central map’s keyframe storage.

double quality = 1.0

Front-end-reported quality in [0,1] (0=worst, 1=best). May be used to scale the noise of the relative-pose factor chaining this keyframe to the previous one from the same source.