IN Brief:
- OKSI’s OMNISCIENCE autonomy software has been optimised for Qualcomm’s QCS8550 processor.
- Functions include visual navigation, object detection and recognition and autonomous mission execution.
- The companies intend the software to scale across Qualcomm’s broader IoT processor portfolio for uncrewed defence platforms.
Qualcomm Government Technologies and OKSI are moving the OMNISCIENCE autonomy software portfolio onto Qualcomm edge processors, beginning with optimisation for the QCS8550 and planned scaling across the wider IoT processor family. Running navigation, recognition and mission functions on the vehicle is intended to reduce dependence on continuous access to remote computing when communications are constrained.
Processing those functions onboard changes the path sensor data takes through an uncrewed platform because camera imagery can be interpreted locally instead of being transmitted continuously to another computer and waiting for a result to return over a radio link. Operators may still need communications to issue missions, receive status information or review selected sensor outputs, but local processing reduces the amount of data that has to leave the aircraft and shortens some of the delay between sensing and response.
The QCS8550 supports that approach by combining general computing, graphics, neural processing, image processing and connectivity functions on one processor platform. Consolidating those workloads can remove separate computing boxes, cables and power conversion stages, reducing mass and volume while concentrating more electrical and thermal load in the remaining hardware.
Because an uncrewed aircraft has finite battery capacity and limited cooling, that concentration directly constrains how much autonomy can run continuously. A processor performing computer vision while the aircraft also powers propulsion, sensors and communications has to remain inside the energy and temperature envelope of the vehicle, making sustained performance more useful than a peak processing figure measured without the rest of the platform. Within those limits, OMNISCIENCE can combine visual navigation, object detection and recognition, target location, mission execution and terminal guidance while allowing a smaller platform to use only the functions required for its mission rather than carrying every module in the portfolio.
Choosing fewer modules reduces unnecessary computing demand, whereas combining several functions increases the importance of the interfaces between them. Navigation, perception and mission logic have to exchange position, confidence and target information consistently if the output of one module is going to influence how another function steers the aircraft or changes the mission plan.
When satellite navigation is disrupted, one of those workloads can use camera frames over time to estimate movement and position, tying navigation performance directly to sensor quality. The estimate still depends on the scene containing enough usable features and on the camera continuing to perform in darkness, dust, poor weather or other degraded conditions.
The same environmental limitations affect object recognition because distance, viewing angle and image quality change how confidently an onboard model can classify what it sees. Moving the model onto the aircraft shortens the path between sensing and response, but the mission logic still has to account for uncertainty rather than treating every machine classification as confirmed.
Those perception functions also compete for processor time with navigation and mission software, so optimisation involves more than making an individual model run quickly. Scheduling workloads, managing memory and deciding which functions need to operate continuously all affect whether the autonomy stack remains responsive when several tasks demand computing resources at the same time.
Optimising OMNISCIENCE for a defined Qualcomm processor family is intended to make those software interactions easier to carry between aircraft. If several manufacturers use related hardware, OKSI can retain more of the underlying compute architecture rather than rebuilding the autonomy stack around a completely different processor for every platform.
Common processors still leave platform specific integration work because cameras, inertial sensors, flight controllers, power systems and communications equipment differ between aircraft. Each interface has to be mapped and tested against the host vehicle, while the available power and cooling determine which combination of autonomy functions can run reliably rather than simply which modules the software supports in principle.
Scaling across Qualcomm’s broader IoT portfolio gives integrators some flexibility to match computing capacity to the vehicle instead of forcing one processor into every application. A larger aircraft can support more processing and cooling than a small battery powered drone while still retaining common software elements across several platforms, reducing the amount of integration work that has to be repeated from zero.
Maintaining that common architecture over a defence lifecycle introduces another constraint because commercial processors can evolve faster than military platforms. Longevity support, replacement hardware and software maintenance have to be planned alongside immediate performance if an autonomy stack is expected to remain supportable for years after the original processor generation leaves the mainstream commercial market.
The collaboration couples OMNISCIENCE to a processor family while leaving different aircraft to select the computing capacity and software modules they can support. Inside each platform, power, cooling, sensor quality, processor scheduling and interface reliability still have to remain within operational limits at the same time before the common hardware and software baseline can deliver dependable autonomy.
