Scripting is not always the best solution. It uses significantly more resources than native implementation. While it is good enough for novel hardware that is used on few vehicles in one fleet and specific high level tasks that are likely to require user customisation.
I would much rather see Cyphal support as compile time option (default to disabled). Especially considering that Cyphal appears to target complex UAS.
1 Like
@LupusTheCanine This is again avoiding addressing the “core design issues” (as James put it) that have been raised by quite a few people in this thread, and instead trying to make us merge support for it anyway.
Moreover we are just speaking about Cyphal for CAN, so a Lua driver would make sense
5 Likes
Great. So one must be advanced in various fields to successfully implement a Cyphal project. And it will still be challenging. Am I using the buzzwords correctly? I’m just a simple guy after all, I might not be worthy. Can we keep something that works? And let the corporate types play in their own sandbox without breaking our toys? AFTER you get it working reliably over there, I might take a look IF you can come down off your high horse long enough to explain implementation to mere mortals.
Deal breaker eh? Consider any deal broken. The entire time reading OP, it seemed the obvious compromise was to dedicate a given bus to a specific protocol. If the main developer is unreasonable, the work environment will be unreasonable, even if the developer has the best idea. Unreasonable Cyphal behavior has already cost me money and time on my project that isn’t even using it. Intentionally obscuring the documentation of UAVCAN is unforgivable IMO and that pattern of behavior continues.
3 Likes
I still don’t get why providing people a choice in the protocol would be problematic. Why the whole discussion should roll down to the transition to the individual.
I’ll stoke the fire a little more…
It’s funny to see how the ardupilot community is adamantly opposed to a new, more flexible version of the protocol being proposed by one of its developers, currently known as droncan (uavcan), because of some sort of external negotiations that took place two years ago. 
Now the point. We are working on creating a decentralized computing system on board by reserving some autopilot functions directly on the motor controllers, servos, gps and e.t.c… Ideally, in the event of a failure of the autopilot, such a system could safely land the VTOL at a given point in the event of an emergency. Unfortunately, what is currently offered is not strong and is suitable for such tasks (DroneCAN is no exception).
4 Likes
For me as a ROS user, for example, there’s nothing wrong with the topics and the subscriber/publisher model. I think this part of the discussion is more philosophical than it should be 
And I don’t see why another prominent protocol with supporters and users can’t be supported by Ardupilot.
Actually, I think this discussion is very fascinating, but becomes too long with repeated narratives.
Can I afford to suggest we conclude with some technical results?
- Is there a taboo for Cyphal in Ardupilot and nothing else makes sense?
If not:
- Could we write down the technical requirements for Cyphal implementation in Ardupilot, agreed by Ardupilot leaders @tridge @khancyr, so that we could make a technical (not emotional) decision on the next PR on this topic.
I think everyone agrees that @ponomarevDA has done a good job and we should try not to lose it.
Let me try to make a draft list of requirements from the above discussion:
2.1. DroneCAN and Cyphal must work on the same bus, and this should be demonstrated extensively;
2.2. The message format (aka UDRAL) should be reconsidered to save bandwidth and consist only of autopilot-used fields in the basic message set.
2.3. The PR must be a product level, containing a full set of devices support to control a VTOL aircraft, as a good example.
2.4. The code should not have hardcoded limits such as number of motors.
Could somebody, please, suggest any other rational conclusions to this list?
@tridge @khancyr, does it make sense?
2 Likes
It looks like you didn’t read the discussion, here are some resume :
- Cyphal is actively promoting itself against the solutions that ArduPilot is developing
- Cyphal is young and ArduPilot developers don’t see the stability/maturity of the protocol for now.
- Cyphal as a CAN protocol only won’t work along DroneCAN and that is a deal breaker for us.
- Cyphal whole protocol, that will be demanded soon after the CAN, will need major change on ArduPilot we don’t want to follow.
On contrary on what some people think, Tridge’s opinion as valuable it is, doesn’t define ArduPilot. We work as a Team, and as it can be read on this topic multiple developers have express their opinion, question, and interrogations.
Lastly, your decentralized system is irrelevant to the system and even Cyphal protocol. I have a fully tri-redundant ArduPilot system with majority vote and I don’t need Cyphal at all. That is good if you can use Cyphal but that doesn’t bring anything new at all. So that is just design issue and not bound to the underlying protocol.
3 Likes
I wanted to add
2.5 Cyphal support could be a compiler option first, as there are not that many users compared to other interfaces.
but PR already has this sort option.
What about saving parameters to SD card? Should this be done?
Sorry, I don’t understand what this means. Could you please expand?
Are you referring to the coexistence on the same bus? This is not actually a problem. If not, then I don’t follow you here either.
What are you referring to as the “whole protocol”?
1 Like
It is problematic because as soon as any level of support is merged, the noise level will increase, the push from the cyphal community to replace dronecan will increase, the confusion from vendors about what to support will increase, the confusion from consumers about what to buy will increase, but the core issues won’t have been resolved. So we’ll be having these conversations again, but with more people impacted. I don’t want that.
3 Likes
Looking through the specification for both protocols the only reason for transport layer incompatibility I see is that somebody reorder fields in the CAN header making it impractical to avoid collisions and to an limited extent the way anonymous messages are deconflicted. If not for that it would simply be a matter of ensuring no ID collisions which should be possible with at most alternate DSDL for fixed port-ID transfers in Cyphal + providing list of occupied IDs in configurator.
PS looking at protocol history overview diagram to me it looks like this change was made either in UAVCAN V1 or Cyphal. What was the rationale?
So I’ve talked to Pavel yesterday, from our conversation, I would like to note the following:
Honestly Tridge is just saying that Cyphal is broken and to fix it we need to build another DroneCAN. It makes no sense to me.
(Direct quote)
From my understanding of both protocols, they cover some non-overlapping needs, so logically will make different compromises. This whole argument essentialy boils down to this.
Without devolving into a flame war on the merits of either side of the argument, what’s the way forward? Is Lua scripting a valid option? The way I see it, this would allow DroneCAN to remain the standard for the established ecosystem (as the default CAN protocol).
1 Like
This is true. We manufacture lot of DroneCAN peripherals and we are already seeing few customers asking cyphal support just because of this discussion. They are directly telling us cyphal would solve all the issues with DroneCAN forgetting the fact that there is active group of people solving the issues and working on continuous development of DroneCAN. This has definitely stirred up the DroneCAN ecosystem a bit.
Regarding decentralized system, how would servos or motor controllers or just GPS be intelligent enough to generate a viable output without having full sensor sets built into them? There are solutions with Triple redundant autopilots but never I have seen sub-systems make decisions in case of autopilot failure. Doesn’t sound safe to me.
2 Likes
The key points are outlined in this post, with in-depth information in the linked threads:
Incompatibility goes far deeper than a mere CAN ID relayout. There are major improvements to the DSDL serialization format and one groundbreaking architectural change — the removal of data type identifiers. The last one is essentially what makes Cyphal what it is, the most critical change.
If Cyphal was implemented as a Lua script instead, how would it help with the issues you mentioned?
the push from the cyphal community to replace dronecan will increase
There is no such push, as has been stated repeatedly in this thread.
The Cyphal Guide - Applications & Usage - OpenCyphal Forum and Cyphal vs. DroneCAN - General - OpenCyphal Forum contain full attack to DroneCAN that isn’t uavcan v0, but DroneCan project, stating it as experimental protocol or legacy
Cyphal community keep asking to drop DroneCAN and use Cyphal. Fair on your forum, not on ours.
2 Likes
It would have been more appropriate to quote me with the full context included. Here’s the missing part that applies to ArduPilot specifically:
As I wrote earlier, the two protocols will continue to exist side by side for a long while. There is no push to replace DroneCAN with Cyphal in ArduPilot.
However, in many projects outside of the domain of ArduPilot, DroneCAN is already being phased out in favor of Cyphal, but I am not sure if this is actually relevant to the topic at hand, as we are discussing the support of Cyphal specifically in ArduPilot and not in some third-party products.
It is true that DroneCAN has been forked off an experimental legacy protocol, but it was not my idea to do so.
1 Like
Cyphal is an experimental protocol as the specification states it as alpha/beta stage (depending where we are reading but that don’t bring trust for some said “high quality” or for critical system).
Therefore as ArduPilot developer, I don’t want to support it as early adopter nor brings it flaws to our community. And have to switch to the Cyphal replacement Beluga2 in 2 years because there were some design flaw/decision in Cyphal
(If you chose Beluga for the replacement name, please state me as author, thanks)
1 Like
It says beta (not alpha), and “beta” does not mean “experimental” but rather “not formally released.” The reasons it is still beta are related to the support of other transports and do not affect Cyphal/CAN nor ArduPilot; otherwise, we wouldn’t have proposed this changeset.
I’ve already saw many years ago your hardware but you don’t have purpose any trial to test
1 Like
There is a need in some cases for more complex networks than DroneCAN allows. I am not convinced the complex networks need to be CAN networks, but could be CAN connected.
The pub/sub model is great among peers, for having options, listening to only the data you need and only sending data when there are changes. UDRAL doesn’t seem to mesh well with pub/sub and the strengths of each do not appear to reinforce the desired realtime regular predictable collision free operation of the CAN bus.
It is stated in a few places that Cyphal is also intended to work via Ethernet. Another twisted pair intravehicular network that does not have any of the conflicts with DroneCAN.
I would welcome Cyphal in that space, and intervehicular communication as well, where it seems a better fit to me.
Question to Cyphal,
why not focus first on your Ethernet implementation in ArduPilot where your innovations would be unquestionably novel rather than contentious? I understand this PR is specifically for CAN, just wondering why this now, rather than a more comprehensive solution later.
// following is just random thoughts off topic
A CAN to ethernet one way relay for example might allow simple plug in redundant compute upgrades. A compute module with ethernet could listen for raw sensor values published on the CAN bus. It crunches the numbers fast and publishes a result on the ethernet network. If the FC is subscribed to the result, it can choose to use the computed result, shortcutting its own processing. Or it can ignore the result and go with its own calculation. Multiple compute modules connected via ethernet switch could be listening to multiple redundant sensors, producing redundant results in different ways, published on the network, not CAN. Their votes. Each CM could choose to ignore a faulty sensor according to its own criteria that may be different than the other CMs making each CM robust against a different type of failure. External WiFi bridged swarm controllers could add their votes as well, but ultimately the FC has the capacity to compute itself and veto all other votes.