English
Español
Português
Deutsch
한국어
日本語
Italiano
Français
العربية
Türkçe
Short answer: A drone companion computer is a separate onboard Linux computer that processes cameras and mission data close to the aircraft. It can run perception, inference, logging, and higher-level mission software, while a dedicated flight-control and safety system retains its own responsibilities. Choose it by validating the complete sensor, power, thermal, communications, and recovery architecture—not by compute headline alone.
For an inspection drone, the hard question is rarely “can this model run?” It is whether the installed system can carry the required cameras, remain serviceable after a power or link interruption, manage heat in its enclosure, and pass useful outputs to the right system owner. That is why a companion computer should be evaluated as part of an airborne integration, not as an isolated bench computer.
What a drone companion computer does—and does not do
A companion computer is robot-side hardware placed on the aircraft for workloads that benefit from local processing: camera ingest, image preparation, AI inference, mapping or mission software, recording, and networked communications. In this article, “local inference” means running the selected model on the aircraft rather than assuming a continuous offboard connection.
It is not automatically the flight controller. Keep low-level flight stabilization, actuator handling, safety functions, and aircraft-specific control authority in their dedicated architecture. The companion computer may exchange information with that architecture, but its integration plan should define which messages are advisory, which are accepted by mission logic, and what happens when a camera, network, or software process is unavailable.
| System layer | Typical responsibility | Companion-computer evaluation question |
|---|---|---|
| Perception | Cameras, payload sensors, preprocessing, inference | Can every intended input be connected, synchronized as needed, protected, and recorded for diagnosis? |
| Mission software | Object observations, mapping, inspection workflow, communications | What data is produced, who consumes it, and what is the defined fallback when confidence or connectivity drops? |
| Flight and safety | Aircraft stabilization, actuator path, safety functions | Is this kept in a dedicated, independently understood system rather than assumed to be a companion-computer function? |
| Deployment hardware | Power input, thermal path, storage, mounting, service access | Will the installation remain inspectable and repeatable after vibration, heat, and field maintenance? |
Start with the inspection workload
Write the workload chain before choosing hardware: sensor input, preprocessing, inference, result, consumer, and fallback. For example, an industrial inspection aircraft may collect a camera stream, run a defect-detection model, store selected evidence locally, then send observations to mission software or an operator workflow. This is different from treating every frame as a cloud upload or assuming a model output directly owns an actuator path.
The same discipline helps distinguish a compact single-camera inspection proof of concept from a camera-rich aircraft. More inputs can change the I/O, storage, cable-routing, thermal, and validation workload even when the inference model itself is unchanged.
A companion-computer decision is an installed-system decision: sensor paths, power, enclosure, communications, and recovery behavior must be tested together.
A practical selection checklist
| Decision area | What to check before committing | Common integration failure |
|---|---|---|
| Camera and sensor topology | List each camera, interface, connector, cable route, and data owner. | A prototype works with one sensor but the production harness cannot accommodate the full payload. |
| Compute and memory fit | Profile the intended model, preprocessing, recording, and concurrent services as one workload. | Bench inference is measured alone while the deployed stack adds logging and communications. |
| Power and startup behavior | Define supply path, protection, startup/shutdown behavior, and recovery test cases with the aircraft team. | The computer resets or corrupts a workflow when aircraft power changes state. |
| Thermal and mounting design | Review enclosure airflow or conduction path, fasteners, service access, and cable strain relief. | Performance is evaluated on an open bench instead of in the installed enclosure. |
| Data and command boundaries | Document telemetry, observation, mission, and fallback message ownership. | An interface is assumed to be a direct control path without a defined acceptance or fallback policy. |
Where N201 and N203 fit in the evaluation
After the architecture is defined, a verified solution path can be shortlisted. The MScape N201 embedded AI computer is a practical primary path to evaluate when the aircraft needs compact robot-side compute with connected-device integration needs. Review the current product documentation with the actual sensor, storage, power, and enclosure plan; do not substitute a product page for an installed-system test.
If the aircraft is camera-rich and the integration depends on a broader perception-input strategy, evaluate the MScape N203 multi-camera edge AI computer instead. The N203 is not simply a “bigger” choice: it is the more relevant path when the camera topology materially changes the integration decision. For a wider view of available hardware paths, see the MScape N Series product overview.
Validation sequence for an onboard-perception build
- Map the interfaces. Record every camera, payload sensor, power rail, network connection, storage device, and system consumer.
- Exercise the complete workload. Test the intended model with representative sensor inputs, recording, communications, and mission software running together.
- Test recovery deliberately. Define and verify expected behavior for unavailable camera input, network loss, a stopped inference process, and planned power-cycle conditions.
- Move into the enclosure. Repeat the relevant checks with final mounting, cable routing, and thermal design—not only on an open bench.
- Capture acceptance evidence. Keep interface maps, software versions, representative recordings, installation photos, and observed recovery behavior for engineering review and future service.
For related implementation context, the robotics edge AI interface-validation guide explains a reusable approach to interface ownership and recovery checks. You can also review MScape application cases to frame the engineering discussion around the intended autonomous-machine workflow.
Frequently asked questions
Can a companion computer replace a flight controller?
Do not assume so. A companion computer is appropriate for Linux-based perception, inference, communication, and mission workloads. Keep flight-control and safety responsibilities in their dedicated architecture unless a current, exact system design explicitly establishes another arrangement.
When should inference stay on the drone?
Local inference is worth evaluating when the workflow needs to process sensor data near its source or cannot rely on a continuous high-bandwidth connection. The decision should still include the model, sensor topology, storage, thermal design, power behavior, and defined fallback.
What should procurement ask for?
Ask the integration team for the sensor list, intended software stack, power and enclosure constraints, interface map, installation drawings, validation evidence, and the owner of each safety- and flight-related function. These artifacts make the hardware comparison actionable.
