Trajectories and Logs

Any time the system is started, a new run entry will be added to the Run History table in the Trajectories & Logs page.

Trajectories & Logs Page

A live run will show as Ongoing with the total run duration, distance travelled and final run status (OK / Error), being updated at the end of the run. Along with the run stats shown on the table, each run entry also includes a run data package that can be downloaded or exported to an external drive for further analysis after a run is stopped or has ended.

Run History controls

Each row in the Run History table includes controls for managing that run:

• Click the copy button next to the run UUID to copy it to the clipboard.
• Click the edit button next to the description to update the run description.
• Use the Sensor Data Logs checkbox to include on-device sensor data logs in a download or export.
• Use the row action buttons to download, export to an external drive, or delete an individual run.

Selecting multiple rows enables the table-level download, export and delete actions for batch operations.

Run data package contents

Each run data package can be downloaded or exported to an external drive as a zip file and contains the following files when extracted:

• Trajectory data as trajectory.csv
• Object detection data as detections.csv (Pedestrian Detection must be enabled)
• Run information as run_info.json
• Support logs in the slamcore_support_logs folder, including sensor data logs containing the raw camera and IMU data if enabled (optional, see Saving Additional Sensor Data)

Further details on the content of each file is provided below in the Run data files section.

Retrieving run data

Run data packages can be downloaded or exported, individually or in batch.

When a run data package is downloaded/exported individually, the zip file name will use the following format <YYYYMMDDHHMM>_<deviceID>_run_<runID>.zip.

When multiple data packages are downloaded/exported in batch, these will be combined into a single zip file with the name following this format <YYYYMMDDHHMM>_<deviceID>_bulk_export_<bulkexportID>.zip. When extracted, the bulk_export zip file will contain a folder for each individual run labelled <YYYYMMDDHHMM>_<deviceID>_run_<runID> with the same content as mentioned above.

Download

Click the icon at the end of a row to download the trajectory and logs for a single run as a zip file to your local machine.

Alternatively, select multiple runs and click the icon at the top of the table to download the trajectories and logs for multiple runs as a single bulk_export zip file to your local machine. This zip file will contain subfolders for each individual run.

note

If any sensor data logs have been recorded on device, make sure the to check the Sensor Data Logs checkbox to include these in the download.

Sensor data logs recorded directly to an external drive during live operation will not be available for download from the web interface.

Export to external drive

1. Prepare a drive for data export as described in the Formatting a Drive for Data Export guide, then plug it in to the DATA port using a USB-C cable meant for high speed data transfer. If formatted correctly, the icons on the table should become enabled. If the icons are not enabled, confirm that:
   1. The USB drive is correctly partitioned and formatted,
   2. If using a USB-C 3.2 cable, please try rotating the cable and inserting it in the other orientation then refresh the page.
2. Click the icon at the end of a row to export the data for a single run to the drive. Alternatively, select multiple runs and click the icon at the top of the table to export the data for multiple runs in one go.

note

If any sensor data logs have been recorded on device, make sure the to check the Sensor Data Logs checkbox to include these in the export.

Sensor data logs recorded directly to an external drive during live operation will not be available for export from the web interface.

3. Please wait for the export to complete.

Exporting data

If an export cannot be completed, the web interface displays a failed export report. Check that the external drive is still connected, correctly formatted and has enough free space, then retry the export.

Storage management & deleting run data

note

Run data remains on-device after download or export, however, an automatic storage management policy monitors device storage and will remove data automatically if storage is low.

The system prioritizes freeing storage by deleting files in the following order, always starting with the oldest data and focusing on the same data type across all runs before moving to the next type:

1. Sensor data logs are removed first until sufficient storage is available.
2. If space is still insufficient, telemetry support log files are deleted.
3. The oldest object detections files (if present) will be considered next if space is still insufficient.
4. Next, the system deletes the oldest trajectory files if further space is required.
5. Finally, if needed, system logs for each run are deleted until enough storage is available.

Any data on an external drive connected to the device will not be affected by the storage management policy.

Run data can also be deleted manually at any time via the Trajectories & Logs page. Click the icon at the end of a row to delete the run entry and associated run data for a specific run or select multiple runs and click the icon at the top of the table to delete multiple runs in one go. If sensor data logs were captured, deleting a run will also delete these, otherwise they may be deleted automatically via the storage management policy mentioned above.

Run data files

Trajectory CSV file

Each trajectory is the time-ordered set of pose estimates generated live from Slamcore Aware. For all runs that were executed with an aligned map, the trajectory is reported in the aligned world coordinate frame, and can be directly plotted on top of the original floor plan image when the scale and origin are provided.

note

Download an example trajectory CSV file for reference.

The first few lines of the example file:

Example Trajectory CSV File

acq_timestamp [ns]	localisation_status	localisation_confidence	t_x [m]	t_y [m]	t_z [m]	q_w	q_x	q_y	q_z	slam_events	vehicle_status
1726664833549160000	Localised	1	30.1	15.8	0.0	-0.9260	0.0492	0.0134	0.37419	LoopClosure:IntersessionLocalisation	Driving
1726664833615760000	Localised	1	30.1	15.8	0.0	-0.9272	0.0435	0.0137	0.37183	None	Driving
1726664833682350000	Localised	1	30.1	15.7	0.0	-0.9241	0.0384	0.0175	0.37982	None	Driving

The data logged in the trajectories are as follows:

• acq_timestamp [ns]
  Acquisition timestamp in nanoseconds since January 1st, 1970 (UNIX Epoch) of the pose in Operating System clock time reference system.

• localisation_status
  Localisation status - Localised / Relocalising - indicates if the system has localised in the map and is publishing a valid pose. See Localisation Status below for more details.

• localisation_confidence
  Localisation confidence - Range 0 ... 1 - provides an indication of the system's confidence in the accuracy of the estimated live pose. See Localisation Confidence below for more details.

• t_{x, y, z} [m]
  Position in meters with respect to the map origin.

• q_{w, x, y, z}
  Orientation as a unit quaternion relative to the map origin X axis.

• slam_events
  Positioning system events. See SLAM Events below for more details.

• vehicle_status
  Vehicle Status - Driving / Idle - indicates if the vehicle is moving or stationary based on the system's pose / velocity estimation data.

Localisation Status

The localisation status indicates the instantaneous state of the current pose estimation:

Status

Localisation Status	Description
Localised	Tracking is OK
Relocalising	The system can not locate sufficient landmarks to continue tracking, or to relocalise on the loaded map

Under normal conditions, the status should remain set to Localised. Sudden changes to the Relocalising status may be caused by insufficient lighting conditions, sensor condensation, featureless walls / a lack of sufficient landmarks within the required range, or due to the detection of suboptimal position estimates due to moving objects in the frame. Starting the system in an unmapped area will also cause the system to remain in the Relocalising state until it is able to localise on the map.

Pose estimates when the system is Relocalising will continue to be published, in the following way:

• Position data (X, Y, Z) will be fixed to the last known position before the system lost tracking until the system is able to relocalise. After first boot, the device will publish the pose as (0, 0, 0) until the system localises in the map.
• Orientation data will continue to change based on the sensor's IMU data.

Localisation Confidence

The localisation confidence provides an indication of the system's confidence, based on real-time AI monitoring technology, in the accuracy of the estimated live pose. This data is used to inform the Localisation Quality readout in the web interface.

The following mapping of values can be used to interpret the data provided by the system:

Localisation Confidence <-> Quality

Localisation Confidence Value	Localisation Quality
1	Excellent
0.25 - 0.5	Good
0.0 - 0.25	Poor

note

Whilst the system is in the Relocalising state, Localisation Confidence will always be 0.

SLAM Events

SLAM Events are instantaneous events affecting pose estimation that are reported on occasion during a localisation run. Unlike the localisation status, multiple SLAM Events may occur in the same frame. In frames where no SLAM Event is reported, the trajectory file reports "None" in the slam_events column.

SLAM Event

SLAM Event	Description
LoopClosure	The system detects that the current position overlaps with a previous position in the run and optimizes the pose accordingly.
LoopClosure : IntersessionLocalisation	The system detects that the current position overlaps with a previous position in the loaded map, and optimizes the pose accordingly.
Reinitialisation	The system has regained tracking and recovered its position.

Object Detections file

Each detections.csv detection file is a time-ordered list of objects detected live by Slamcore Aware. Multiple objects detected within a same frame are recorded as different lines tagged with the same timestamp. For each detection, a body location (3D position of the object relative to the camera / tracking point), as well as a world location (2D position of the object in the world coordinate frame) is reported. If the system is Relocalising, only a body location will be reported.

note

The first few lines of the example file:

Example Detections CSV File

acq_timestamp [ns]	label	body_location_x [m]	body_location_y [m]	body_location_z [m]	world_location_x [m]	world_location_y [m]
1726664833549160000	Person	-1.560	2.338	-0.054	0.151	-0.573
1726664833615760000	Person	-1.532	2.267	-0.061	0.150	-0.573
1726664833682350000	Person	-1.507	2.204	-0.047	0.102	-0.587

The data logged for the detections are as follows:

• acq_timestamp [ns]
  Acquisition timestamp in nanoseconds since January 1st, 1970 (UNIX Epoch) of the frame for which the detection was run in Operating System clock time reference system.

• label
  Object class label.

• body_location_x/y/z [m]
  Object 3D location relative to the vehicle based on the latest estimated pose. It is reported in the frame defined by Vehicle Tracking Point setting, which is set at the Slamcore Aware sensor reference frame by default.

• world_location_x/y [m]
  Object 2D location reported in the world coordinate frame, the same reference frame that vehicle pose is reported in when the system is localised. When the system is not localised, these fields are empty.

Run Info JSON file

The run_info.json file included with every run contains the following metadata relating to the run:

• Run UUID
  Unique ID used to identify the run.

• User description
  Custom user description entered through the web interface (if available).

• Run type
Mapping / Localisation

• Map name
  Name of map used during mapping / localisation.

• Status
OK / Error

• Start datetime
  Start time in YYYY-MM-DD-HH:MM:SS format based on the system clock.

• End datetime
  End time in YYYY-MM-DD-HH:MM:SS format based on the system clock.

• Distance travelled (m)
  Distance travelled whilst the system was able to track its environment.

• Device ID

• Device serial

• Camera serial

• WebUI version

• Floor plan image name
  Filename of floor plan image used for alignment (if available).

• Floor plan scale (px/m)
  Scale of floor plan image used for alignment (if available).

Slamcore Support Logs

The Slamcore support logs folder contains the following files which have been bundled together so they can be shared with Slamcore easily for troubleshooting support.

• trajectory.csv
  Copy of the trajectory file including detailed debugging information.

• detections.csv
  Copy of the object detections file.

• telemetry.db
  System telemetry metrics for run debugging.

• app_messages.txt
  Notifications reported through the web interface.

• app_log.log
  Container logs for system debugging.