Fujimod
Try your camera firmware in the browser and build Fujimod SD boot files.
CORV GCS wiki and user guide — a 3D ground control station for ArduPilot, INAV and Betaflight
LifestyleJavaScript · HTMLGitHub @Xarin94OnlineOwner unconfirmed
Have you tried it? One tap is enough. No sign-in needed.
3D ground control station for ArduPilot (Copter, Plane, Rover, Sub/ROV), INAV and Betaflight — terrain, mission planning, radio link coverage, navigation without GPS. Windows & Linux.
Taken from the repository README
Loading the full README. The saved excerpt is shown below.
A 3D ground control station for ArduPilot drones
Windows & Linux · Electron + Three.js
📖 Wiki — the complete user guide
Every screen, button and setting explained, page by page:
Getting started ·
Flight screen ·
Mission planning ·
Setup ·
ROS ·
DownloadRead the full README ↗A ground control station is the software on the laptop that talks to the drone: it shows what the aircraft is doing, lets you plan a flight and sends it to the autopilot. CORV GCS does that for ArduPilot vehicles (Plane, Copter, Rover, Sub, Heli, VTOL) on a real 3D model of the terrain, built from the same elevation data used by mapping services, with satellite imagery on top.
It also reads INAV / Betaflight controllers over MSP and the onboard CORV autopilot over its binary protocol; the interface is in English and Simplified Chinese.
You see what the aircraft sees: the terrain ahead in 3D, with an aviation-style head-up display over it. Speed, altitude, heading, vertical speed and G-load are drawn the way an airliner's primary flight display draws them — the pitch ladder, the flight-path marker and the bank arc follow the same conventions as a Garmin or Boeing HUD, so the picture reads at a glance.
Around the aircraft the satellite imagery is as sharp as on the 2D map, down to 10 cm per pixel (zoom 20; 40 cm by default, set in SYS CONFIG → 3D SATELLITE DETAIL), loaded as the aircraft flies: low over the ground you see the cars, the fences and the power lines you are flying over. Between telemetry samples (25 a second from ArduPilot, in bursts over a cellular link) the view carries the aircraft along on its velocity, acceleration and rotation rates, so low and fast the ground streams past at the full frame rate instead of in steps.
Turn the satellite imagery off (M) and the terrain becomes a schematic chart, in the style of the mission simulations in Top Gun: Maverick: black sky, contour lines every 10 m with brighter ones every 50 m and amber ones every 250 m, and a white line along every ridge that hides the ground behind it and along the horizon, out to 30 km. The route with its numbered waypoints, home, the predicted path and the trail already flown are drawn over it in bold, at a size that stays readable from any distance — a survey as dashed passes in its own colour, a loiter circle as the ring it is with arrows for the direction of turn, a landing straight down, the return to launch dashed. Below 200 m a faint grid of 25 m triangles on the ground around the aircraft shows how high it is. With the light theme the same chart is drawn as green relief under a pale blue sky, with the readouts and the HUD in dark blue.
A column of annunciators beside the speed tape flags anything wrong with the vehicle: red warnings from the top, amber cautions from the bottom. They are the same conditions Mission Planner checks — GPS quality, compass and IMU health, vibration, EKF variance, radio signal, failsafes — each shown with its own icon and the number behind it (satellites and HDOP under the GPS flag, RSSI under the link one).
Tick RESTRICTED ZONES in the side panel and the UAS geographical zones within 50 km of the vehicle and the mission appear on the maps and on the 3D terrain — no-fly in red bands, ceilings coloured by the height allowed — from the FAA in the US and the national services in Germany, France, Spain and Switzerland, or from the ED-269 file a state publishes (Italy's from D-Flight). Above a zone's ceiling or the general limit (120 m in Europe, 400 ft in the US) a red flag lights beside the altitude and TERR ALT flashes; arming inside a zone raises an alarm banner of its own.
Click the EKF STATUS tab on the left edge and a black bar slides out down the left side with the estimator's last 20 seconds in three charts, the view moving over to make room. For an ArduPilot: the EKF innovation ratios, the GPS accuracy and the EKF attitude against the backup DCM. For a CORV board: the raw GPS against the particle filter, the particle cloud's effective sample size and confidence, and the shared EKF's covariance. A GPS glitch, a dropout or a drifting estimate shows as it happens.
SYS CONFIG → FLIGHT STACK tells the GCS which firmware it is talking to: ArduPilot, INAV or Betaflight. That one choice pre-selects the right link on the connection page (MAVLink serial at 57600, MSP at 115200) and decides what the rest of the app offers.
On INAV the mission is planned exactly the same way and uploaded over MSP as an INAV waypoint list — navigation and hold points, POI, heading, speed, landing and return to home, with the altitudes the terrain model worked out. What the INAV format has no room for is greyed out while you plan, with the reason on the control itself rather than an error at upload time: no loiter circles, no spline legs, no take-off waypoint, no camera, gimbal, servo or relay actions, and a budget of 60 waypoints — the board's own figure once it is connected. Betaflight has no navigation stack, so the Flight Plan page is greyed out entirely. On either of them the setup screens that only speak MAVLink — parameters, calibration, tuning, failsafe, RTK inject — are greyed out too, each one saying where that setting actually lives.
You draw the mission as shapes, not as a list of commands: a waypoint, a circle to loiter in, a perimeter to fly around, an area to photograph, a corridor to follow, a point the camera should look at, a landing. The route between them is calculated for you a moment after every edit — for an area scan the parallel lanes come from the camera model, so a DJI Mavic 3 at 100 m gives 49 m between lanes, a photo every 26 m and 2.7 cm per pixel on the ground.
Every planned photo is a red dot on the route; hover one and the rectangle it will cover on the ground appears. The elevation profile along the bottom shows the ground under the whole route and the height the aircraft will fly at: the autopilot flies straight from one waypoint to the next, so each leg is checked against the terrain and a leg that would clip a hill is listed on the route card ("Clearance under 20 m" on segment 6 in the picture) before you upload anything.
A drone is only as far away as its radio can reach, and hills get in the way. Pick your radio from the list (RFD900x, SiK, Herelink, Microhard, Doodle Labs, ExpressLRS, Crossfire — or type the transmit power, antenna gains and sensitivity of your own), place the operator on the map and turn the LINK layer on: the map shows in light green where the link will be good, in orange where the terrain degrades it, in red where it will work but with too little margin, and nothing where it will not work at all.
The check is the one an RF planner would do: a straight line of sight from the antenna to the aircraft, the first Fresnel zone around it (the radio needs that ellipse clear, not just the line), the loss when a ridge cuts into it, and the curvature of the Earth. The LINK PROFILE cut shows it for the point under the cursor or for the worst point of the route — in the picture a mountain between operator and aircraft costs 46.7 dB and the link is lost.
One button uploads the plan to the autopilot; READ brings back the mission stored on it. The command bar keeps the flight mode, battery, GPS quality and the waypoint being flown in view, with ARM, TAKEOFF, RTL, AUTO and LAND at hand — the picture is a simulated copter flying the plan above, on waypoint 4 of 54.
Every flight is recorded as a .tlog from the moment the link comes up, and both .tlog and
ArduPilot .bin logs can be replayed on the same screen, with a timeline to scrub through.
With a Livox Mid-360 laser scanner on the aircraft, a 3D map of the ground builds up live on the
screen. The scanner sends its points over the network link and CORV GCS places each one on the map
from the aircraft position and attitude in the telemetry — about 170,000 points in the picture, coloured
by height; the map can be saved as a .ply file for other software.
Any LiDAR, echo sounder or sonar running under ROS (1 or 2) reaches the GCS through rosbridge: the ground under an aircraft, the bed under a boat or a ROV, the walls of an underwater cave, drawn as a mesh of grey lines over a transparent body, averaged in 30 cm cells instead of millions of points, in absolute or relative navigation. A preview in the settings shows how the sensor is mounted and the zone it collects from. A mechanical sector-scanning sonar, one beam per ping, has each beam placed with the pose of its own time, and a survey boat can take its depths from the water surface rather than from a drifting barometric altitude. The wiki's ROS page walks through it step by step: rosbridge on the companion computer, every setting, the on-screen strip, troubleshooting, and worked examples for an aerial LiDAR, a SLAM map, an echo sounder, a survey sonar, a ROV in a cave and a sector-scanning sonar on a boat — with a simulated survey of a Lake Garda bed strewn with a wreck, a car, a container and a light aircraft to try it on.
Lakes and seas are found in the elevation data and drawn as a blue surface; a ROV is placed at its depth under the water it dives in, stays visible under the surface, and from under it the surface is a grid overhead with particles drifting past. With no GPS at all, SYS CONFIG → NAVIGATION switches to a relative frame over a plane at zero — the vehicle's own local position (a DVL, a USBL), or one dead-reckoned from its velocity when it has none. The simulator has a ROV on Lake Garda, with and without GPS. The picture is a real BlueROV2 dive replayed from its log.
All of it, with what ArduSub and ArduPlane actually send without GPS, is in docs/3D-NAVIGATION.md.
The vehicle connects over a USB telemetry radio, UDP or TCP, and a built-in ArduPilot simulator (SITL) starts with one click when you want to try things without an aircraft. The parameter editor reads a single parameter on request instead of the full list of a thousand — on a slow long-range radio that is the difference between two packets and several minutes.
Installers are on the Releases page:
Windows CORV GCS Setup 1.8.7.exe, macOS CORV GCS-1.8.7-arm64.dmg (Apple silicon) and
CORV GCS-1.8.7-x64.dmg (Intel), Linux CORV GCS-1.8.7.AppImage (portable) and
corv-gcs_1.8.7_amd64.deb (Debian / Ubuntu).
The macOS app is not signed with an Apple Developer ID: after copying it to Applications, run
xattr -dr com.apple.quarantine "/Applications/CORV GCS.app" once, or macOS reports it as damaged.
To run from source you need Node.js 18 or newer:
git clone https://github.com/Xarin94/Corv-GCS.git
cd Corv-GCS
npm install
npx electron-rebuild # native serial-port module for Electron
npm start # run
npm run build # installers for Windows + Linux → dist/
The 3D terrain comes from SRTM .hgt elevation tiles (one file per 1° × 1° square, ~25 MB each at
30 m resolution). The tiles under the vehicle are downloaded automatically when a network is
available and kept in data/terrain; you can also put your own files in topography/ inside the
installation folder, from
OpenTopography or
USGS EarthExplorer, named like N47E011.hgt.
Missions, flight logs and LiDAR maps are written to a data/ folder next to the installation
(data/missions, data/logs, data/lidar) — under Program Files, where that is not allowed,
they go to the per-user data folder and the mission library shows the path in use. Custom aircraft
models (.glb / .gltf) go in models/.
The app keeps the last 5 minutes of what it did in data/debug/corv-gcs-debug.log,
rewritten every 3 seconds and capped at 3 MB: connections and their failures, every command sent
and its acknowledgement, STATUSTEXT, heartbeats lost and back, arming and mode changes, parameter
and mission transfers, warnings shown on screen, button presses, a vehicle / link / frame-rate
snapshot every 10 seconds, and crashes. At start-up the previous session's file becomes
corv-gcs-debug.prev.log, so the minutes before a crash survive the restart.
When something goes wrong, open SYS CONFIG → DEBUG LOG → SAVE COPY…: it writes one file with this session and the previous one, to send to support. SHOW FILE opens the folder. The log holds no keys or passwords (cellular key, NTRIP credentials are masked).
| Method | Protocol | Typical use | Default |
|---|---|---|---|
| Serial | MAVLink 2 | USB telemetry radio (SiK, RFD900…) | 57600 baud |
| UDP | MAVLink 2 | MAVProxy, MAVLink router | 127.0.0.1:14550 |
| TCP | MAVLink 2 | SITL, also through WSL on Windows | 127.0.0.1:5760 |
| Serial / TCP | MSP / MSP2 | INAV or Betaflight controller — telemetry, and waypoint missions on INAV | 115200 baud |
| Serial | CORV binary | Onboard CORV autopilot over USB | 460800 baud |
The wiki covers every screen, button and setting, with the ArduPilot documentation page for each flight mode, mission command, failsafe and calibration: getting started, flight screen, side panel, flight modes, mission planning, radio link, 3D view, water and ROVs, vehicle setup, GCS settings, simulator, LiDAR, ROS surface, keyboard shortcuts. Its source is the docs/ folder.
ARCHITECTURE.md describes every module and data flow; docs/LIDAR.md covers the Livox setup; docs/3D-NAVIGATION.md the mission in 3D, the low-altitude grid, water, ROVs and navigation without GPS. Bug reports and feature requests are welcome in the issues.