Onboard AI tracking
for EO/IR payloads.

02 Engineering brief

Compute, model and the tracking pipeline

The TK5340 uses an RK3576 processor with a 6 TOPS neural processing unit. That figure describes the accelerator's peak capability, not the frame rate or accuracy a mission will see. Real performance depends on input resolution, model size, number of targets, pre-processing, post-processing and the tracking algorithm that runs alongside the detector. A six-TOPS module can be fast enough for a compact UAV payload, but the supplier should show measured results on representative footage rather than a synthetic benchmark.

An AI object tracking pipeline usually has four stages: capture, pre-process, detect or classify, and associate the result with an existing track. The association step is where multi-target behaviour becomes visible. If two targets cross, the module must decide which detection belongs to which track. If a target disappears behind a mast, the tracker must either coast on its last motion estimate or declare a loss according to a defined rule. Ask how the module behaves in each case and whether the behaviour is configurable for the mission.

Target classes are also a procurement decision. A general-purpose person/vehicle model may not recognise a small boat against a bright sea surface, and a UAV at long range may occupy very few pixels. The documented classes for TK5340 are person, vehicle, boat and UAV, but the operating envelope for each class must be confirmed with matched imagery. If the programme needs a new class or a customer-specific classifier, ask whether the module supports model updates, how those updates are validated and what happens to the existing track when a model changes.

The edge AI tracking module also needs a defined output. A bounding box in image coordinates is enough for a display but not for pointing a gimbal. A track reported in payload angles, geographic coordinates or body-frame rates requires calibration, time alignment and a coordinate transform. Define the output the downstream system needs before comparing compute specifications. The interface, not the TOPS number, often determines whether integration succeeds.

04 Engineering brief

Latency, power and the airframe budget

TK5340 is documented with a tracking latency of ≤35 ms. That number is only useful if the supplier defines where the clock starts and stops. Is it sensor exposure to track output, video-frame arrival to output, or neural-network inference alone? A 35 ms inference result plus a 30 ms camera pipeline plus a 20 ms control loop is a very different system from a 35 ms end-to-end claim. Ask for the measurement setup, the frame rate and the output interface used in the test.

The module accepts 12–60 V and is described for 6S and 12S packs, which covers a useful range of UAV power systems. The input range does not remove the need to check transient behaviour, reverse polarity, inrush current and heat. The board envelope is documented as 53 × 40 × 10 mm, so the mechanical design must provide mounting, connector clearance and a thermal path. A compact board in a sealed payload enclosure can run hotter than a bench test suggests, and sustained high frame-rate inference may reduce the achievable clock or require a thermal design change.

Power and mass budgets should include the camera modules, harness, cooling and any interface board. The AI module is only one line in the budget. If the payload already has a stabilized gimbal, the added processing may be modest compared with the mechanics; if the module is added to a small FPV airframe, every gram and every watt matters. Compare the complete processing chain, not just the module datasheet. The TK5340 product page lists the supplier-stated electrical and mechanical figures, and the current drawing should be requested for the programme.

06 Engineering brief

OEM integration and programme questions

An OEM payload programme should settle five interface questions early: how video enters the module, how the track leaves it, how the module is powered, how it is cooled and how firmware is updated. The answers determine the harness, the enclosure, the connector strategy and the qualification plan. If the module is mounted on a gimbal, the rotating interface and cable wrap must be included in the design. If it is mounted in the airframe, the distance to the cameras and the electromagnetic environment become the dominant risks.

Configuration control is part of the product. Ask for the firmware version, model version and any customer-specific parameters, and define how changes are notified. A model update can change the target classes, the confidence threshold or the track behaviour. The programme should have a regression test set that runs after every update. If the customer supplies its own model, clarify who owns the training data, who validates the output and how the model is protected in the delivered hardware.

Environmental qualification should match the installation. A board that is qualified on a bench may still fail under vibration, thermal cycling or humidity in a sealed payload. Ask for the operating and storage temperature range, shock and vibration evidence, conformal coating and connector retention. For a defence programme, also ask about traceability, export classification and long-term availability. These questions are easier to answer before the design is frozen than after the first flight.

The engineering team can review the camera interfaces, target set, latency budget and track output against the documented module. A short review is usually enough to decide whether TK5340 is a direct fit, whether a carrier board is needed, or whether the programme should start with a project-specific configuration. The goal is not to buy the highest compute figure; it is to deliver a track that the payload can use reliably in the installed environment.