Discussion of cyphal support

Development Team
41

Hi Andrew Tridgell, thanks for the open discussion on this site!

I am the CTO of ADA Aero.

We are developing an all-weather eVtol with a focus on fully automatic flight and post-flight maintenance.

(UAVCAN) Cyphal is an ideal protocol for us since many devices require deep customization and can be functionally scalable in the future

We require a lot of custom electronics in our drones and they are all built around Cyphal.

Here is just some of it:

  1. Miniature BLDC servos with torque, position, speed feedback.
    (for tilt mechanics drive, blade pitch control, elevon control).
  2. Battery controllers with separation of emergency and main batteries, with diagnostics and cell monitoring.
  3. generator controller for starting the on-board engine and ensuring the most efficient power generation with RPM and torque control.
  4. Vector ESC with redundancy and telemetry, for correct operation of the stabilization system, the system providing the most efficient flight mode (blade pitch/RPM).
  5. 3 axis gimbals.
  6. All other avionics, navigation, speed sensors, lidars.

I can not imagine how we will implement this list on DroneCAN, here are just some of its disadvantages:

  • Limited choice of MCU/hardware/applications
  • address conflicts
  • problems with dynamically assigned addresses
  • Fixed data type identifiers (fixed predefined identifiers)
  • transport layer facilitates DCPS
  • CAN interface support only

Cyphal is very light weight and can be ported effortlessly to any MCU.

With Cyphal support the Ardupilot community will get a more flexible development tool with the following benefits

  • more flexibility in configuring the Cyphall protocol
  • data-centric publish-subscribe (DCPS) architecture
  • more robust and reliable protocol
  • resulting systems are scalable, evolvable, and flexible
  • more freedom in selecting the MCU for the devices
  • CAN (FD), UDP, TCP, serial port.
  • MISRA-compliant software ecosystem

Here is a well-structured explanation with examples of why we need Cyphal

It would be nice if in Ardupilot the user could choose which protocol to use Cyphal or DroneCAN :slight_smile:

8 Likes
42

Reading through this thread I think its clear that there is limited desire for Cyphal support from ArduPilot users. Half of those posting are new forum members, while it is great to welcome new users, implementing such a feature would need interest and support from within the existing community. To be honest it does feel as though the whole Cyphal team has turned up to tell us how great Cyphal is. (The ArduPilot team thinks ArduPilot is great too!)

Maybe this is just too soon. It sounds like there are some DSDL issues that should be worked through on the Cyphal side. On the ArduPilot side there is not really the need or desire for a new protocol at this time.

We will need new protocols as the industry moves forward, maybe Cyphal and ArduPilot will be a better fit in the future.

9 Likes
43

While I understand that this is not the key part of what you said, it is important to clarify that there are absolutely no issues with DSDL on the Cyphal side. What you are referring to is actually UDRAL, a separate project. I wish the topic could be renamed to “Discussion of UDRAL support” because it is clear that the participants mistakenly conflate Cyphal with UDRAL.

45

This seems a bit like moving the goal post? I agree that some of the replies are coming from the Cyphal team, isn’t that also to be expected? (Since we’re the ones that have a stake in this discussion.)

As for the “existing” community, I can only speak for myself here, but I have been a practical user of Ardupilot before this discussion as well. It is not unreasonable to suspect that most users are passive in the sense that they don’t register on the forum when using this or that opensource project.

I’m wondering what level of proof of usage is required for this proposal to pass? Some specific number of companies?

Are there examples to follow for this procedure? Other protocols like MavLink/DroneCan? Would be curious to know what level of adoption those had when they were deemed “worthy”?

4 Likes
46

Let me restate the key points for visibility.

  1. The authors of the pull request will address the deficiencies discussed here earlier, such as the inability to use the DroneCAN driver simultaneously with Cyphal. The authors will also make the necessary contributions to the documentation as the next step after the current PR is accepted.

  2. If there is a desire to review the DSDL (which is not part of Cyphal but is part of the pull request), we are entirely open to that. Interested parties can contribute critique to the proposed alternative messages here: GitHub - DS-015/ds015: Interface definition files for the DS-015 drone standard.

  3. There is no plan for Cyphal to compete with DroneCAN directly, as within the ArduPilot community, there are use cases for both. Rather, consider it to be yet another alternative protocol that will exist side-by-side. There clearly is a demand for support for this protocol in ArduPilot, and it is unclear what does ArduPilot stand to gain by denying it.

5 Likes
47

I had drafted a much lengthier addition to this thread, but I don’t think it would add much value - just extend the somewhat circular discussion.
Instead I’ll just provide a response to some assertions. I know that some of my comments below will be seen as inflammatory. That’s not my intent, but unfortunately is unavoidable due to the nature by which attempts to force Cyphal upon us are being made.

Does this mean that you’re open to revisiting the spec?
I’ll remind you of:

Addressing the first point is great, but if you actually seek convergence, the third point can’t be ignored:

This is probably untrue, and is at least inconsistent with your stated objectives over the last 4 years or so - although I expect you believe that you can claim your intent is to compete “indirectly”. Your desire to completely sunset UAVCANv0 is one of the key reasons we forked into DroneCAN. You’ve also stated on a number of occasions that you don’t see Cyphal and DroneCAN (aka v1/v0) needing to coexist for very long, as you expect vehicles will shift entirely to Cyphal/CAN very quickly. A comment was made earlier about the PR being a Trojan Horse, and I believe that this is not a bad analogy (it might have been less obvious if the PR and every other example to date weren’t direct substitutions for DroneCAN).

it seems almost entirely from companies who have followed your advice without seeking other opinions, or from people who are in your employ, or are simply parroting your posts without looking any deeper. As a counter point, the ArduPilot Partners Program has more than 100 commercial participants, most of whom either use or manufacture CAN devices - many with large, complex, sometimes certified, vehicles. None are seeking Cyphal support.

This has been repeated many times: we’re attempting to provide clarity for the industry by not further fragmenting the ecosystem of CAN devices, and supporting our community by not introducing a new protocol that isn’t fit for purpose.

There’s a significant amount of carefully crafted misdirection in this thread, seeking to distract from the core design issues in order to place focus on the two issues that do not require changes to the spec: co-existence and DSDL.
For me, this causes a significant trust issue, which of itself makes me less inclined to revisit the decision regarding Cyphal.

Rejection of Cyphal doesn’t mean that the shortfalls in DroneCAN are being ignored - they aren’t, and in fact are being actively worked on.

13 Likes
48

Here are my direct responses to Tridge’s objections restated for clarity.

This is untrue. You can mix Cyphal and DroneCAN on the same bus. The driver that we contributed does not make use of this capability, but as I said earlier, it will be amended appropriately.

DroneCAN has limitations that make it unusable in certain applications that are relevant for a non-negligible subset ArduPilot users. Cyphal has no such limitations; hence it provides value. While some fragmentation will take place, its negative effects are hardly significant, considering that both protocols can be used at the same time on the same bus without conflicts. The appearance of UAVCAN in 2014 also caused fragmentation of the existing ecosystem of I2C/RCPWM devices to no ill effect.

I don’t think we will get anywhere if we continue throwing emotional judgments of this kind around. I get it that Tridge personally does not like Cyphal, is used to a particular way of solving the problem, and refuses to accept a novel approach; none of this makes the design “poor” or “driven by a flawed philosophy.” We spoke about the design decisions at length countless times, so you will forgive me for not starting yet another round.

The stated objectives were decided on before the appearance of DroneCAN. Now that DroneCAN is a separate project, the circumstances are different and hence is the strategy. In 2019, it was reasonable to expect UAVCAN v1 to overtake and replace UAVCAN v0; in 2023, replacing DroneCAN with Cyphal is no longer a sensible option.

James, this logic cuts both ways.

[Objections against Cyphal originate] almost entirely from companies who have followed your advice without seeking other opinions, or from people who are in your employ, or are simply parroting your posts without looking any deeper. As a counter point, the Cyphal community has more than 100 adopters, most of whom either use or manufacture CAN devices - many with large, complex, sometimes certified, vehicles. None are seeking DroneCAN support.

Can we please stay above this?

The design of Cyphal is certainly not perfect, as is the case with any practical system that has to make compromises, but its issues have nothing to do with “poor design” or “flawed philosophy.”

I would like to invite @tridge to resume his participation in this conversation.

1 Like
49

@Pavel_Kirienko I’m just an end user of ardupilot and dronecan and I’ve not been involved in the discussions here for many years but I’ve never seen someone so pushy to have their request accepted and endorsed. Surely you must stand to personally gain enormously from having cyphal tech supported by ardupilot given the bombardment undertaken here. Do you already have cyphal support with ardupilots alternatives and did you use the same approach?

3 Likes
50

Surely you must stand to <…> gain <…> from having cyphal tech supported by ardupilot

Yes.

So does every entity that leverages Cyphal and ArduPilot. Some of them have voiced their opinion earlier in their thread, in the linked pull request, and in many prior occasions on the OpenCyphal forum going back to ca. 2019.

Hence, we proposed the changes. This is how open source works: you want a feature — you implement it (or pay someone else to do it), propose it, and, perhaps after some back-and-forth, see it being accepted.

1 Like
51

Almost. There is no guarantee any feature will be accepted, there has to be a consensus that the feature is in the best interest of the project and its users.

That this thread exists at all shows that that consensus is not there for this particular feature.

If you have made some commitment that it must be in ArduPilot you can either keep it out of tree or implement in lua scripting. Scripting is a great option, there are already a number of scripting examples for CAN protocols for controlling ESC’s and other unusual devices. We don’t have all the bindings to do custom GPS drivers for example, but adding those bindings is something that I think we would accept. I don’t think it would be very much work to bring a script up to the same level as the proposed PR.

3 Likes
52

We’re on the same page. I’m curious to see what the consensus will be and specifically what @tridge has to say.

1 Like
53

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
54

@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.

55

Moreover we are just speaking about Cyphal for CAN, so a Lua driver would make sense

5 Likes
56

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
57

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. :grin:

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
58

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 :slight_smile:
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?

  1. Is there a taboo for Cyphal in Ardupilot and nothing else makes sense?

If not:

  1. 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
59

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
60

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?

61

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