NXP introduces unified robotics development platform

NXP Semiconductors has introduced a unified robotics development platform that connects embedded processing, sensor networking, real-time motor control, and artificial intelligence through a modular hardware and software architecture.

Built on NXP's Neural Axis Architecture, the platform combines an open-source software development kit with pre-integrated reference designs. The initial release supports drone development, with additional configurations for service robots, autonomous mobile robots, and other autonomous systems expected in the second half of 2027.

The company is seeking to reduce integration work between electronic subsystems that operate under different timing, computational, and communications requirements. Developers can evaluate individual reference designs before combining them into more complex robotic systems, using shared software interfaces and supported middleware.

Robotic equipment commonly distributes processing across several electronic devices. An applications processor may execute perception algorithms and navigation software, while a microcontroller handles motor-control operations that must complete within predictable intervals. Other devices acquire sensor data, manage communications, and supervise electrical power.

These functions operate at different rates. Camera processing may involve computationally intensive workloads with variable execution times, whereas motor-control software must update electrical switching commands consistently to maintain stable movement. Combining the functions requires attention to latency, scheduling, data exchange, and fault handling.

NXP's architecture provides common development resources while retaining dedicated processing hardware for operations with different requirements. Its SDK includes drivers, reusable software components, configuration tools, reference applications, and middleware integrations intended to simplify connections between supported subsystems.

The first four reference designs cover autonomous computing, vehicle management, sensor networking, and electronic speed control.

The NavQ95 provides autonomous computing and flight-control resources based on NXP's i.MX 95 applications processor. It is intended to accommodate functions such as perception, navigation, and the processing of information received from connected sensors.

Vehicle and flight management use the Tropic VMU/FMU reference design, built around the i.MX RT1064 crossover microcontroller. The dedicated controller provides a processing environment for operations requiring predictable timing, distinct from the broader software workloads handled by the applications processor.

A 100BASE-T1 sensor node uses the MCX N947 microcontroller to connect distributed measurement devices. The single-pair Ethernet interface provides a communications route between electronic modules that may be physically separated within an aircraft or another robotic assembly.

The motor-control reference design uses an MCX A13 microcontroller in an AM32-compliant electronic speed controller. It generates the commands required to regulate power semiconductor switching and control the operation of a connected motor.

An electronic speed controller translates a desired motor response into electrical switching patterns. In brushless motor systems, the switching sequence determines how current is supplied to the motor windings, while the control algorithm regulates torque or speed using measured or estimated operating conditions.

Motor control requires consistent execution because variations in the timing of switching updates can alter the electrical response. A central navigation processor, by contrast, may need to perform calculations whose execution times vary according to the complexity of the sensor data or algorithm.

Separating these workloads can prevent computationally demanding applications from interfering directly with critical control operations. The resulting system must still coordinate commands and feedback between devices, including how it responds when data arrives late or communications are interrupted.

Sensor networking introduces similar requirements. Measurements from cameras, inertial devices, and other sensors need to be associated with appropriate timing information so that the control system can interpret the state of a moving robot.

A measurement received at a particular moment may represent a physical condition captured earlier. Navigation and control algorithms must account for this difference, especially where several sensors operate at different sample rates or communicate through separate interfaces.

The robotics SDK integrates established software technologies including PX4, Zephyr, and ROS 2. PX4 provides flight-control software, Zephyr supports real-time embedded execution, and ROS 2 supplies middleware and software components used in robotic applications.

These frameworks address different functions within the overall architecture. Their integration reduces the need to develop every supporting interface independently, although system-level testing remains necessary to establish whether the combined implementation meets its timing and reliability requirements.

NXP states that its reference designs allow developers to establish initial drone functionality within approximately 30 minutes. The figure refers to a supported starting configuration using prepared hardware and software, rather than the development time required for a flight-ready autonomous aircraft.

Completing an operational system requires further work covering mechanical integration, environmental conditions, flight stability, power management, and the behaviour of the equipment under abnormal operating conditions. Software and hardware functions must be assessed together against the intended application.

Security and functional safety also extend beyond individual processor features. NXP's reference designs incorporate the security and safety enablement available through their underlying devices, providing resources that developers can use when implementing protected software execution, system supervision, and fault handling.

The availability of these capabilities does not establish certification of a complete robot. Functional safety depends on the system architecture, the identified hazards, the mechanisms used to detect and respond to faults, and the verification performed on the finished equipment.

Distributed processing also affects power consumption and mechanical design. Drone electronics must be evaluated against restrictions on weight, available battery energy, cooling, and the number of components required to support each function.

NXP has worked with robotics specialists including Orqa and blueflite on the platform. The company is positioning the common SDK and reference designs as a starting point for additional robotic architectures rather than limiting the software to aerial vehicles.

The drone reference designs and supporting SDK are available now. Further enablement for autonomous mobile robots, service robots, and other applications is expected during the second half of 2027, when developers will be able to assess how the same architecture accommodates different sensor arrangements, actuators, and operating requirements.