Re Tridge’s latest point: I am developing 2 CAN node devices, and things are smooth from a cooperative-hardware perspective. My understanding is a major advantage of CAN is plug-and-play functionality: (The wiring-simplification and interference-resistance are the more obvious part.)
I’m also a bit confused in that the subscriber model Cyphal goes towards seems nice once you get buy-in from the FC firmware and node firmware. These aren’t mutually-exclusive! You can have plug-and-play as long as the standard is clear.
This brings up two questions:
#1: Can Cyphal support plug-and-play as Tridge describes? #2: Can DroneCAN support subscription, ie allow the FC and node to negotiate data-rates, config etc? (Why is DDS/ROS2 separate from DroneCAN? Do they work seemlessly for practical purposes?)
My cautious eye on this conversion has me worried that DroneCAN is inflexible, and Cyphal is overly-complex. I hope I’m wrong on both!
Plug&play with no configuration is nice but I don’t think it meshes well with complex systems with custom hardware and some custom software. Having a set of default message IDs would be nice but how would a device know that Device 53 message 63 is GPS and not magnetometer. Now consider unlimited amount of combined devices and new device types that will appear in the future.
IIRC there was a nasty bug where RC protocol could be misidentified under certain conditions that only recently got patched. On a complex UAV I don’t want nodes playing any guessing games.
From what I understand the point of
Cyphal(CAN) and UDRAL is configuration flexibility that makes it somewhat impractical to make assumptions about nodes’ capabilities.
For me plug and play should be reserved for interchangable and optional modules preconfigured by a system integrator and not necessarily arbitrary COTS devices (though that would be nice for makers of simple UAV).
IMO Drone can gets away with as much auto detection and plug&playability because it sends redundant information over the wire increasing bus utilisation.
Thank you for the insight! I speculate the key point here is this:
From what I understand the point of
Cyphal(CAN) and UDRAL is configuration flexibility that makes it somewhat impractical to make assumptions about nodes’ capabilities.
Between the extremes of plug-and-play standard and All nodes are controlled by system architecture, it seems Cyphal sits in a middle-ground; I need to consider if this is something that makes sense for systems I’m interested in.
DroneCAN’s plug-and-play system has immediate advantages over systems where the MCU communicates directly with peripherals: The hardware interaction is abstracted over, and a standard, part-agnostic API is exposed. Devices agree on what messages GNSS, airspeed indicators, control reception, motors, servos etc send, and devices can be hot-swapped with minor config. (This doesn’t preclude negotiation or capability broadcasting, even if it might in current DroneCAN systems!) If I have a CAN system, I can buy any DroneCAN GNSS, and can it expect it to work with minimal or no config. I don’t need to know the UBLOX or NMEA protocols, or configure registers. The FC firmware only needs to know the API for communicating with DroneCAN GNSS devices. This is powerful!
Or, if looking at the system holistically, you configure the devices cooperatively, with full control over FC and node firmwares. This begs the question of What role does Cyphal do if I control the system? If you control the system, the complexity can go away; send payloads down the wire, deconflict with priorities etc, and don’t worry about conforming to an external standard or reading specs.
It is what UDRAL is for in Cyphal. Difference is that message IDs aren’t fixed (other than basic and necessary services). There could be an automatic discovery protocol but an amount of let’s call it interesting cases is quite large. For example N receiver GPS device on one CAN node. With DroneCAN N>2 doesn’t work. Cyphal just needs to let subscriber know where (node and msg ID) to expect each message. Considering who Cyphal targets automatic discovery and configuration service was of little value. Though if somebody came up with robust enough AD&C service it could be included in UDRAL.
There are standard and typical devices that benefit from having a standardized message format for example all thermometers can send temperature messages on their own nodeID and if you have multithermometer unit it can set multiple temperatures simply using multiple message IDs and all devices wanting to listen to any particular temperature simply need to know which node and message to listen to.
PnP as implemented in the above-linked PoC can coexist with arbitrary custom nodes. It only affects those nodes that it knows how to configure and ignores the rest.
Fixed or default node-IDs is a truly dead end as explored at length in numerous debates linked earlier. Fixed topic names is a different matter though that will be explored in detail once the support for named topics is available in Cyphal.
I am not sure there’s any point in continuing this conversation here unless anyone is willing to revert Tridge’s decision.