DroneCAN and Cyphal are related communication protocols for connecting controllers, sensors, actuators, and computing systems inside autonomous vehicles.
DroneCAN is currently the practical choice for most PX4 aircraft. It is mature, broadly supported, and compatible with a large ecosystem of existing UAV peripherals.
Cyphal is the architecture we believe deserves greater adoption.
It was designed for vehicles that are becoming distributed computing systems: larger aircraft, advanced ground robots, spacecraft, and other machines containing multiple intelligent controllers.
Avian Automata will use DroneCAN on current systems built around the 305AP, while beginning to adopt Cyphal as we develop larger and more complex platforms.
The quick comparison
| Category | DroneCAN | Cyphal |
|---|---|---|
| Best fit | Current UAV peripherals and smaller PX4 vehicles | Larger distributed autonomous systems |
| PX4 maturity | Mature and widely supported | Still developing |
| Existing hardware | Broad peripheral ecosystem | Smaller but growing ecosystem |
| Communication model | UAV-focused messages and services | Publish/subscribe and request/response |
| Plug-and-play | Mature dynamic node allocation | Designed for standardized discovery, configuration, and plug-and-play nodes |
| Redundancy | Supports redundant CAN interfaces | Modular redundancy across CAN, Ethernet, and mixed transports |
| Architecture | Practical peripheral network | Distributed computing platform |
| Avian Automata direction | Current 305AP systems | Future larger systems |
PX4 presently recommends DroneCAN for most installations because of its maturity, peripheral support, and years of testing. PX4 describes Cyphal as more flexible for large and complex vehicles, although its PX4 implementation has not yet reached the same level of adoption.
Why the 305AP will use DroneCAN
DroneCAN solves the immediate needs of most compact and medium-sized PX4 vehicles.
A typical network may connect:
- A flight controller
- GNSS receivers
- Smart ESCs
- Power monitors
- Airspeed sensors
- Rangefinders
- Servo controllers
DroneCAN already provides device discovery, configuration, health monitoring, time synchronization, firmware updates, and dynamic node-ID allocation. Combining dynamic allocation with automatic bus-rate detection allows compatible devices to join a network with little or no manual configuration.
That maturity makes DroneCAN the sensible protocol for current 305AP flight-controller systems.
The 305AP runs PX4 and includes two independent FDCAN interfaces using CAN FD-capable transceivers. These interfaces can support separate CAN networks or a redundant connection when the attached devices also provide dual interfaces.
DroneCAN gives 305AP users access to the existing PX4 peripheral ecosystem without waiting for Cyphal hardware and PX4 support to become equally widespread.
That is a practical engineering decision—not a rejection of Cyphal.
Why Avian Automata is building toward Cyphal
DroneCAN is an excellent peripheral protocol. Cyphal has the potential to become something larger: a common architecture for communication between intelligent subsystems.
Modern autonomous vehicles increasingly contain more than one primary computer. A future system may include separate controllers for:
- Flight or vehicle control
- Propulsion
- Navigation
- Perception
- Battery management
- Payloads and manipulators
- Safety monitoring
- Communications
- Mission planning
At that scale, the network is no longer just connecting sensors to an autopilot. It is coordinating a distributed computer.
Cyphal was designed specifically for deterministic, real-time distributed computing in aircraft, spacecraft, robots, and cars. Its core model includes publish/subscribe messaging, request/response services, structured interface definitions, peer-to-peer communication, and support for modular redundancy.
That architecture is why we believe Cyphal should see broader adoption.
1. Plug-and-play should extend beyond assigning node IDs
DroneCAN already offers useful plug-and-play functionality through dynamic node allocation.
Cyphal is designed to extend that idea into a broader system-management model. Its design principles call for standardized functions covering network discovery, node configuration, software updates, health monitoring, time synchronization, and plug-and-play node support.
The long-term goal should be a vehicle where a compatible component can be connected, identified, configured, monitored, and updated through common interfaces.
Actual plug-and-play behavior will still depend on the device implementation, software support, and the standards adopted by manufacturers. A protocol cannot create a seamless ecosystem by itself.
However, Cyphal provides a stronger architectural foundation for creating one.
Greater adoption would help manufacturers converge on reusable device interfaces instead of repeatedly developing vendor-specific messages, configuration systems, and integration tools.
2. Redundant links are part of the architecture
Both DroneCAN and Cyphal/CAN can use a second CAN interface to improve connection robustness. PX4 recommends connecting both interfaces when the flight controller and peripherals support redundant links.
Cyphal takes redundancy further.
The Cyphal specification supports non-redundant, doubly redundant, and triply redundant transports. Its architecture also allows heterogeneous redundancy, where redundant paths may use different network technologies rather than two identical CAN buses.
A future autonomous vehicle might use:
- Two independent CAN FD networks
- Redundant Ethernet paths
- CAN FD for embedded controllers
- Ethernet for high-bandwidth computers
- Multiple transports operating as one logical system
Cyphal is designed to provide automatic failover without requiring a central bus master. Its peer-to-peer structure also avoids making one network controller an inherent single point of failure.
That is especially valuable for large aircraft, long-duration vehicles, safety-critical robots, and systems that cannot tolerate the loss of a single cable or interface.
3. Cyphal provides a better architecture for complex systems
DroneCAN is optimized around proven UAV functions. That is one reason it remains straightforward and effective.
Cyphal provides richer abstractions for systems whose nodes perform substantial processing.
Its publish/subscribe model allows a node to distribute information without being tightly coupled to every consumer. Its request/response model provides structured services when one component needs a direct operation from another.
Cyphal’s Data Structure Description Language, or DSDL, defines interfaces independently of a particular processor, programming language, or transport. Those definitions can be used to generate communication code while keeping the interface consistent across embedded controllers, higher-level computers, simulation, and testing.
This creates a cleaner separation between:
- What a component provides
- How the data is encoded
- Which processor runs it
- Which network carries it
- Which other components consume it
That separation becomes increasingly important as systems grow.
4. Cyphal can span CAN and Ethernet systems
DroneCAN remains closely associated with CAN-based UAV peripheral networks.
Cyphal can operate over CAN, CAN FD, UDP/Ethernet, serial links, and other transports supported by its implementations. OpenCyphal currently provides stable reference implementations for Cyphal/CAN, Cyphal/UDP, and Python-based tooling that supports CAN, UDP, and serial transports.
This does not mean every vehicle should replace CAN with Ethernet.
CAN FD remains an excellent choice for embedded sensors, actuators, and motor controllers. Ethernet is more appropriate for high-bandwidth computers, cameras, and perception systems.
Cyphal offers a path for those networks to share a consistent communication architecture.
That becomes useful on larger vehicles where forcing every device onto one physical bus would create unnecessary bandwidth, wiring, and reliability compromises.
Is Cyphal too complex?
Cyphal requires more architectural planning than installing a collection of existing DroneCAN peripherals.
Developers may need to define:
- Network interfaces
- Subject and service identifiers
- Data types
- Transport assignments
- Redundancy policies
- Device configuration
- Versioning and compatibility expectations
That added planning is sometimes described as a drawback.
For a small vehicle with one flight controller and a handful of peripherals, it can be. DroneCAN will usually accomplish the job faster with less integration risk.
For a large autonomous system, those decisions already exist whether the engineering team formally manages them or not.
Cyphal provides a structured way to address them.
The complexity does not come only from the protocol. It comes from the system Cyphal is intended to organize.
Avian Automata’s approach
Our near-term and long-term approaches are different by design.
Current 305AP systems
The 305AP will use DroneCAN because it provides:
- Mature PX4 support
- Existing peripheral compatibility
- Proven development tools
- Straightforward vehicle integration
- Lower risk for compact aircraft and rovers
The 305AP’s dual FDCAN interfaces provide a flexible hardware foundation for CAN-connected sensors, actuators, and other PX4 peripherals.
Explore the Avian Automata 305AP flight controller →
Future larger systems
As Avian Automata develops larger platforms, we plan to begin adopting Cyphal where its architecture provides a meaningful advantage.
These systems may benefit from:
- Plug-and-play component management
- Standardized service interfaces
- Redundant physical links
- Redundant nodes and controllers
- CAN FD and Ethernet integration
- Better separation between subsystems
- Cross-vendor interoperability
- Scalable distributed computing
Adoption matters. Cyphal’s advantages become more valuable as more flight controllers, sensors, actuators, motor controllers, and computing modules implement compatible interfaces.
Avian Automata intends to be part of that transition.
Final takeaway
DroneCAN is the right network for most PX4 vehicles today, including current systems built around the 305AP.
Cyphal is where we see the greater architectural potential.
It provides the concepts needed to build autonomous vehicles as robust distributed systems: standardized interfaces, plug-and-play support, peer-to-peer communication, redundant links, multiple transports, and clear separation between intelligent subsystems.
The question is not whether Cyphal should replace DroneCAN on every small drone.
It should not.
The question is whether the next generation of larger autonomous systems needs an architecture designed for more than connecting peripherals to a flight controller.
We believe it does.
0 comments