Sharing Karshipta, an open-source self-hosted fleet console for PX4/ArduPilot vehicles that also ingests non-flight trackers, looking for feedback from people running multi-vehicle setups

Spotlight
1

Karshipta v0.1.0: self-hosted fleet console for PX4/ArduPilot, plus non-flight trackers via Herald

Just shipped v0.1.0 of Karshipta, an open-source, self-hosted command and control console for fleets, not just flight vehicles.

Two paths into the same console:

  • MAVLink vehicles (PX4, ArduPilot, real or SITL) through a C++20/MAVSDK gateway: telemetry, commands, and Fleet Missions where each vehicle gets its own independently planned route, tracked as one unit through upload, flight, and stop.
  • Herald: HTTP ingestion for anything with no autopilot and no command surface at all, livestock GPS tags, generic GPS/GSM trackers, includes a GT06 protocol parser (the wire format for a large family of low-cost trackers) and a declarative field-mapping config for other devices.

Both show up as a “ward” on the same fleet map, same browser console, self-hosted, AGPL-3.0.

docker compose up gets 3 PX4 SITL vehicles and a live console running in under a minute if you want to try the flight side without hardware.

Repo: GitHub - NIKX-Tech/karshipta: Open-source, self-hosted command and control for fleets of unmanned vehicles and trackers, in your browser. Live web console for real or simulated MAVLink vehicles (PX4, ArduPilot): fleet map, telemetry, commands, missions. · GitHub

Would especially like feedback from anyone running mixed fleets, multiple vehicle types, or non-flight trackers alongside vehicles; that mixed-fleet case is exactly why this exists.

Karshipta console showing three simulated wards

2

Interesting direction especially the fact that MAVLink vehicles and non-flight trackers end up in the same operational view.

One thing I’d be curious about is how Karshipta represents time and provenance across heterogeneous sources.

For example, in a mixed fleet you may have:

PX4/ArduPilot telemetry → MAVLink gateway → backend
GT06 / HTTP tracker → Herald → backend

Those paths can have very different timestamp semantics, latency, update rates and clock quality.

I would preserve, where possible, both:

event/source time — when the observation was generated by the device
ingestion time — when Karshipta received it

plus source identity, sequence/correlation information and clock quality/uncertainty.

That becomes important when two wards appear spatially close on the map but their latest observations are actually from different moments.

A useful test for the multi-vehicle case would be to inject controlled delay/dropout into only one source and verify that the console can distinguish:

current observation
stale-but-valid observation
missing observation

rather than treating all three as equivalent map positions.

If you’re interested, I’d be happy to sketch a small mixed-fleet validation matrix for this path as well.