Set up

Safety, sensors and battery

The envelope the aircraft is allowed to use and what it does when something is lost, the sensors that many of those limits depend on, and the battery that ends every flight.

The Safety and Sensors page: the maximum distance and height, the action at the limit, and the return to launch type and heights. — Maximum distance and height, the action at the limit, and the return profile.

Limits

The Safety & Sensors page starts with the maximum distance and height from home. What the aircraft does when it reaches either one is set on the Geofence card below.

Geofence

The Geofence card holds the area the aircraft may fly in. Press Draw area: a large map opens over the page, and you click the corners on it the same way you draw an Area pattern in the Mission planner. Large map on the card's small map opens the same view to adjust an area, and Done or Escape closes it. Enter or a double click closes the area, a right click takes the last corner back and Escape gives up. Once it is closed you can drag any corner, remove one with a right click, or add one with the small handle in the middle of an edge. The area is kept on this computer as soon as you finish, so you can draw it without a vehicle.

The geofence on the large map in the blue theme: the eight corners of the area along the field as handles, a handle in the middle of every edge, and the Redraw, Delete area and Done buttons above. — The large map: drag a corner, or add one with the handle in the middle of an edge.

Upload to vehicle puts it on the autopilot as an inclusion fence, on PX4 and on ArduPilot. Action when leaving the area picks what the aircraft does when it crosses the edge (for example Return or Land); the same action applies to the distance and height limits. On ArduPilot the upload also switches the fence on and adds polygons to FENCE_TYPE when they are not already there. The line under the map says whether the area on the vehicle is the one you see, and warns when the aircraft is outside it.

Show on the Home map draws the area as a dashed outline on the Home map. Remove from vehicle clears the vehicle's fence and keeps the area here.

The Home map during a flight with the side panel collapsed: the geofence drawn as a dashed amber outline around the field, the flown track inside it and the instrument panel. — The area on the Home map during a flight, as a dashed outline under the track.

The map tilted into 3D over the operator's own 20 cm surface model: the field with its trees in relief, the geofence as a dashed outline along the field's edge, the flown track and the aircraft at its altitude. — The same area in 3D, over a 20 cm surface model imported under Settings.

Return to launch

The return profile: the height to return at and to descend to, the climb cone, and the time spent loitering above home before landing. These are the heights the Mission planner reads to draw a Return item the way it will actually be flown.

Landing

How fast a PX4 multicopter descends when it lands on its own (Land, Return and a mission landing), and where it slows down. Above Slowdown starts at it sinks at the maximum descent speed; down to Landing speed from it slows steadily to the landing speed, and holds that until touchdown. With a distance sensor the last stretch, below Crawl below, runs at the crawl speed. The descent speed is for the automatic descent before the landing starts, for example after a return, and the maximum descent speed caps it, so keep the maximum at or above it.

Fast landing writes a tuned set in one press: 2.5 m/s descent, slowing from 12 m to 6 m, 1.0 m/s landing speed, and a 0.5 m/s crawl below 2 m. It is chosen for the Holybro X500 and X650, a good deal faster than the firmware defaults (1.5 m/s, 10 m to 5 m, 0.7 m/s) and still braking early. Every value stays editable in the fields below the button. It is refused while armed, like any other parameter write. Try it first in open space at low altitude, and use heavier or lighter airframes with more care: the values are not a measurement of your aircraft.

Failsafe actions

One action for every loss the autopilot can detect: RC, data link, position, battery and actuator. The levels the battery action reacts to are on the Battery & Power page with the rest of the pack, so that one number has one place where it is edited.

Distance sensor and optical flow

A Sensors card on the same page, because a ground lidar is what half those limits lean on. Each sensor is a tile that says whether it is up and what is feeding it, and opens onto its own page.

One switch

On the sensor's page, one switch brings it up. Corvus starts the driver and tells the estimator to use it, which is the step usually missed: a rangefinder reading perfectly while the EKF ignores it looks exactly like a working sensor. The state line always names both halves.

A sensor that is only half set up is shown as Incomplete, with one line for each missing piece: the estimator ignoring it, no serial port set to it, the wrong baud rate, a CAN port not running DroneCAN. One press of the switch completes it.

Where to plug it in

Every sensor model says which connector it belongs on (I2C, CAN or a serial port), and the serial port picker shows what already runs on each port, so a lidar is never put on the port your telemetry radio uses. On PX4 a port another driver already holds is refused with the reason.

Hardware presets

You do not own a SENS_TFMINI_CFG, you own a TFmini-S. One dropdown lists the modules Corvus knows: Holybro H-Flow, Benewake TFmini-S, TFmini Plus and TF03, and on ArduPilot the Matek 3901-L0X. Each row names its bus and model, because picking "UART" when the module on the bench has a CAN plug is exactly the mistake a list like this can prevent.

Choose one and Corvus writes its whole chain: the driver, the estimator, and the numbers from that module's datasheet (the height band a flow camera can track in, the noise a lidar's accuracy implies).

Every parameter it would write is listed with its value and its reason before anything is sent.
A module this firmware cannot run says so in its row, rather than failing once chosen.
A parameter your firmware does not carry is named rather than silently skipped.

Custom, and your own parameters

The first row of that dropdown writes nothing and leaves everything to you: the model picker (Lightware, Lidar-Lite, Benewake, PMW3901, DroneCAN and the rest, or a sensor arriving over MAVLink), the serial port if it needs one, and the settings that really are per airframe: mounting offset, height limits and quality gates.

You can also name any parameter and it joins the form, read in the same batch and written the same way as everything else. The list is remembered in this browser profile, so a row you added because this aircraft needs it is still there next time.

On ArduPilot

The switch also sets what the driver depends on (the serial port and its baud rate, the CAN port, or the sensor's I2C address) and leaves the height source on the barometer, as ArduPilot's documentation asks. Optical flow goes into an EKF source set the way the ArduPilot wiki describes: the primary one on an aircraft without GPS, source set 2 beside the GPS otherwise, selected in flight with an RC switch.

Preflight checklist

The last card on the page is your own preflight checklist, because it asks the same question as the failsafes: is everything right before the aircraft leaves the ground. It turns the checklist window on the Home map on, puts that window away or brings it back, and Edit checklists opens the editor. The lists belong to the station, not to the aircraft, so the card works with no vehicle connected and stays editable while armed. How the window itself works is under Preflight checklist.

Battery & Power

The Battery and Power page: the pack drawn with its warning thresholds and per cell voltages, its live readings, and the settings for how Corvus reads it. — The pack drawn with its cells and failsafe levels, the live readings, and the settings.

The pack on one page, split the way the job is: the aircraft on the left, everything you can change on the right.

Left: the pack as it is: A battery drawn with the cells it actually has, filled to what is left, each cell's voltage under it and the failsafe levels marked along the bar. Underneath, the live numbers: pack voltage, current, watts, mAh used, temperature, and the spread between the best and worst cell, which is the first thing a tired pack tells you.
Right: the settings: Cells and capacity, the voltage a cell holds full and empty, the power module's voltage divider and amps per volt, and the levels the low battery failsafe fires at.

Every BAT_ parameter on PX4 and every BATT_ one on ArduPilot lives here. That prefix is the whole rule for what is on this page and what is on Safety & Sensors.

A second opinion on "how much is left"

The percentage an autopilot publishes is a capacity count that starts from a guess. A pack flown, charged to storage and flown again reads full on the second takeoff. ArduPilot publishes no percentage at all unless a capacity is set.

Corvus can read the cell voltage against a real discharge curve instead, with a table each for LiPo, Li-ion and LiFePO₄ (3.3 V per cell is a flat LiPo and a nearly full LiFePO₄). It corrects the voltage back to rest through the pack's internal resistance, since a 6S pulling 60 A through 5 mΩ per cell reads 1.8 V low in a climb.

Neither reading is right in every case, so both are computed on every frame and both are on screen. One switch chooses which one the top bar, the map and the logs go by, and the top bar says on hover which one you are reading and what the other one thinks.

Cell count is worked out the moment the battery is plugged in, the one moment the reading is unambiguous (19.8 V is a fresh 5S and a tired 6S), then held for the flight. You can also pin it by hand.
A smart or DroneCAN battery that reports its own cells is believed over any of this, and its weakest cell is drawn where you can see it.