Discussion of cyphal support

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.

I made a proposal with a new message set to replace the current UDRAL. I tried to make a compromise based on how ArduPilot and PX4 handle DroneCAN, what we have in the current UDRAL, the old DS015 and as many comments from Andrew Tridgell as I could find. I also tried to pay attention to bandwidth utilization.
It would be nice if ArduPilot community join this discussion.
https://github.com/DS-015/ds015/pulls

I also made a table that could be used as an example of how the proposed Cyphal interfaces could be applied to a specific VTOL application. You can check it here: vtol bandwidth (cyphal and dronecan) - Google Sheets
I have to note, that this table is not intended to compete with DroneCAN (Cyphal looks more efficient here), but just to illustrate a well known to everyone interface.

5 Likes

I’ve ‘been around’ a while[since before apm2] and I’m absolutely not convinced its a value-add for ardupilot because… opinion ahead:

  • [in my opinion]dronecan ‘works well’ for our current use-cases. If it didn’t we’d wouldn’t have forked it and made it our own. Its got a large installed user base, and by keeping with it and doing constant incremental improvements it will[ and does] evolve with our and our user/s needs.
  • [in my opinion]cyphal, is an overly complicated re-implementation of the above ‘works fine’(mostly) system. Its got extra features that most of us don’t want and don’t need, that adds complexity at many levels, not the least of which is the uavcanv1/cyphal/udral/DS015 nomenclature that honestly doesn’t interest me in the least, but also seems very much to me like you have made 4 attempts now at implementing this[based purely on the 4 naming variants ive seen for different bits of this], and its still wrong. Despite this, I’ve read everything i can about this, from the beginning, and I’m fully educated on this. but I still just want something that stays out of the way, lets the comms flow efficiently,doesn’t waste ram/flash/etc by being worsse that what we have, and doesn’t hinder my experience as a user or a dev. Everything about this , including this conversation is hindering my experience, and getting in my way of doing interesting stuff.
    The only way I’d support any of this in ardupilot is if you keep iterating on it till either: A. its protocol looks exactly like dronecan, but measurably the same or better in every single way[every packet, every byte, every transfer, and there 's an automated test suite that proves it, including at differing levels of simulated pkt curruption and packet loss and bus utilisation ], or. B. wait, nop, there’s no other way, just that. super high bar, because its a super-contentious bit of work, seems reasonable to me. [totally just opinion, no facts at all, so no point telling me im wrong]
10 Likes

Thank you for your interest in RaccoonLab UAV onboard electronics with both Cyphal and DroneCAN support. We appreciate your enthusiasm, but a trial for hardware is not the same as a trial for software :wink: and couldn’t be offered to an unlimited amount of users.

We’re open to participating in non-commercial but promising projects that align with our goals and contribute to the community. If there is some project that falls under this category and already has some background, we’re more than happy to explore possibilities for collaboration. Please, email us in such a case with details.

Maybe, a demo of Cyphal + Ardupilot UAV, which help this PR to be accepted, is a good project))

I would like to call attention to Roman’s post once again and invite @tridge to get involved again, as the conversation is clearly stagnating without his input. Thanks.

2 Likes

Are you really surprised? When your cronies go as far as calling him a liar. That without any explanation for that matter.

You went and hid all previous discussion from public eye for a long time.
He started an open conversation here. You (after several challenges by him) brought back the hidden conversation, but still kept is visible to only people who register. Twice you have ignored the question as to why it is not completely open as this one is.
It is not hard to guess who has and agenda here and who doesn’t.

4 Likes

FYI there is now DDS support in ArduPilot, and it’s going to soon add Ethernet support. If you are interested in pub/sub, feel free to take a look at the AP_DDS library.

I’m happy to have a discussion on whether DDS over Ethernet could accomplish the same complex use cases as Cyphal over CAN, but it can be in another thread. Feel free to dm me here or on discord to have a quick chat.

4 Likes

@Pavel_Kirienko Cyphal is not going to be merged into ArduPilot in anything like it’s current form. We’ve given the reasons many times going over several years. I know you don’t accept our answers, but that doesn’t change the answer.
If you actually wanted Cyphal to have a chance in the future the thing that needs to change is your approach.
First off, you would have to focus on interoperability, just like I told you years ago when I convinced you to change the Cyphal wire format so that co-existance is possible. At the time I told you that theoretical co-existance was not enough, it needs to be demonstrated, the tools need to understand mixed networks and the use of mixed setups needs to be seamless.
As an example, the peripheral sensor firmwares would need to have runtime (not compile time) selection between DroneCAN, Cyphal and both at once. The same with the flight controller firmware - it would need to be done in a way that gives runtime selection, and support running a mixed network seamlessly.
On ease of use we really don’t align at all. You and @ponomarevDA showed this video for cyphal config which you call a “negligible increase in the configuration complexity”:

when we see this we want to run a mile. Right now to configure a DroneCAN magnetometer you just plug it in. For a GPS you just set GPS_TYPE to 9 and plug it in. For a baro you just plug it in. For an airspeed sensor you set ARSPD_TYPE to 8 and plug it in.
We look at the fact you need to set a single parameter for GPS and airspeed as something we should try and fix. The video for Cyphal goes in entirely the other direction, with a huge amount of configuration needed.
We will continue to evolve DroneCAN while maintaining the ease of config that we want for our user community. Lots of the core devs for ArduPilot have looked at this conversation and none of them that I am aware of want Cyphal in ArduPilot.
We expect to have DroneCAN on ethernet shortly. We already have DroneCAN over MAVLink. We also expect to have DroneCAN → ethernet adapters, bringing IP networking to boards with no ethernet port by tunneling IP packets over CANFD. We do understand the importance of ethernet (see Tom’s talk at least weeks dev conference).
For those who want publish/subscribe in ArduPilot I encourage you to join in the efforts on DDS/ROS2 that is being led by @rfriedman. DDS is in ArduPilot master now, and forms a great base to build on.

7 Likes

Thank you for your response, Andrew.

I suppose the matter is nearly settled at this point, but for reasons of setting the record straight, I need to call everyone’s attention to the apparently overlooked statement that Cyphal/CAN is not meant to compete with DroneCAN within ArduPilot, and providing the same ease of use is an anti-goal at this point. Automatic configuration of Cyphal nodes is possible, and this matter has been explored in-depth in our earlier discussions on the Cyphal forum (I linked these earlier in this thread), but it is not a priority feature by any margin.

I am unsure where the hard requirement for interoperability and tools that natively support mixed networks comes from. It is certainly not from empirical evidence as there are pure and mixed Cyphal-enabled systems out there that are configured and managed easily using the existing toolset (mostly Yukon&Yakut). Cyphal indeed requires the integrator to understand how the network is designed, which is unlike DroneCAN. This is not an issue for the domain that Cyphal is designed to be used in.

Let me know how you would like to proceed with the pending pull request.

1 Like

I’ve closed the PR. For all the reasons we have given in this discussion and in the many past discussions cyphal is not a good fit for ArduPilot

1 Like