Overview
The Telemetry system exists to collect and enable analysis of kart fleet telemetry data. It gives SG the ability to monitor fleet battery health in real time and to ingest and analyse live run data (DAQ) from the karts during sessions. Combined with timing data from TalentID:Coaching, this provides a more complete picture of driver and kart performance.How It Works
Telemetry is a set of locally hosted services that communicate directly with the kart fleet over TCP to collect CAN charging data and DAQ (run) data. They run as a single Docker Compose stack on the machine at the track. Logically there are three parts:- Charging Data Receiver. Collects CAN charging data from the fleet over TCP and moves it through the pipeline into InfluxDB.
- Telemetry Dashboard. A web application to monitor fleet battery health in real time and export charging data runs to S3.
- Exporter API. Queries InfluxDB for charging data monitored in the Telemetry Dashboard, and receives DAQ run uploads from the karts and puts them in S3.
Telemetry is locally hosted, not cloud-hosted. This is an important operational distinction, because it requires physical presence on the network where the karts are.
The End To End Journey
Telemetry spans a machine at every track and a conversion pipeline in AWS. There are two data streams, collected the same way and converted very differently, which meet again in the STL database. For all of it on one diagram, see Architecture. A DAQ run:
A charging run:
Both:
There is one track machine per hub region. It is started and stopped every day of an event, and once per event a setup script is run to pull the latest scripts and images.
Detailed Documentation
Architecture
The whole system on one diagram: the track machine, the AWS pipeline, and the two data streams.
Track Operations
The machine at the track: setting one up, the event cycle, what runs on it, and the backups.
The Charging Data Receiver
How the receiver polls the karts, how frames are decoded and written, and the internal signals.
DAQ Upload and Conversion
How a run gets from the kart to STL, what the zip contains, and what the converter does.
Timing and Lap Splitting
How TalentID timing turns a recording into laps, and how reconversion is triggered.
Charging Export
How an engineer exports charging data to STL from the track dashboard, and what the export does to it.
Internal Signals
The
x prefixed signals the pipeline emits about itself, and what a healthy kart looks like.Telemetry Dashboard
The three screens on the track machine, and how they reach the API.
Exporter API
Every endpoint the dashboard calls, plus the DAQ upload endpoint.
Local Development
Standing in for the kart fleet with the simulator, and converting a run on your own machine.
STL Database and SimTelLab
Where every converted run is filed, and how engineers get it onto their own machine.
Deployment And The Pipeline
How a merge becomes a running change: the CDK pipeline, the images, and the AWS resources it creates.
Troubleshooting
Runs that did not arrive, did not convert, or do not show on the dashboard. Plus known issues.
Repositories
Dependencies
Internal
- TalentID: Coaching. Telemetry reads timing data from TalentID:Coaching to correlate with telemetry readings. It also writes collected telemetry data back into TalentID:Coaching via the API, where it is stored and served alongside timing KPIs.
- GKL API. Telemetry reads booking event data from GKL API to understand active events. Read-only.
Infrastructure
- TalentIdPipeline-Infra-CDK. Provides the VPC and shared MongoDB EC2 instance.
- Local network. Telemetry services are locally hosted and communicate with the kart fleet over TCP on the local network.
Notes
- Both data streams are in production. Charging data is exported by hand from the track dashboard; DAQ runs convert automatically in AWS.
- Aentron karts are not officially supported in production, pending a full factory test that has been outstanding since September 2025. The
aentronbattery spec is fully implemented, so the support gap is verification, not capability.