putting the params into sd card could be interesting, I think we already support that on some other protocol.
But before starting new developpement, I would advice to wait that a plan is agreed, otherwise you will invest a lot of time on something that can be asked to be modified again …
3 Likes
Cyphal is great. I will not explain myself but I hope that I can just highlight the existing link from the first post in the thread: https://forum.opencyphal.org/t/cyphal-vs-dronecan/1814 and that it will tell you what new the protocol adds.
2 Likes
I just don’t want my drone running as a complex decentralized network. I want hub and spoke, mediated by the flight controller with transmission guarantees. Pub-sub is a way of not caring what your consumers think and using that paradigm to lower CPU load - I don’t want that on a drone, in fact I think the paradigm is downright dangerous in this context (I mean maybe it’s ok with non-flight critical subsystems, but I don’t think that is the intention). So as far as I can tell the new protocol adds a whole bunch of complexity without actually adding anything that I actually care about.
9 Likes
Nothing you said was true, you can just read up on these matters if you want to know more but you don’t have to as a consumer. Reliability is good though, yes, Cyphal is no worse in that regard. Tridge is lying too much and that’s making consumers scared, should stop that.
1 Like
Hi,
I might not be very knowledgeable on the topic discussed here, but I would like to add my impression about the idea of managing the configuration of a critical set of subsystem on consumer grade SD-cards installed on a variety of boards.
Even on “state of the art” systems used in compliance with safety regulations by trained and expert technicians, it is not an easy task to manage PDIs.
And that is with redundant memories, specific checks at boot-up, dedicated and qualified tools, certified hardware etc.
There might be many errors and bugs at different step of the process, from defining the data to using it in the firmware, both from software and hardware.
My 2 's
Please don’t use false statement yourself. Tridge point was explain in first post with demonstration. You are allow to not agree with the parameter issue, but that doesn’t give your right to said somebody is a liar. Specially, when Cyphal is using a lot liar keyworks itself (“modern”, “replacement”, “unsuitable”, “lighweigth”, etc.). There are use case for DroneCan and use case for CyPhal.
From ArduPilot perspective, for now, we don’t see strong advantage to support Cyphal. If the project gain more traction or find a developpment way with ArduPilot, it can surely be reviewed. Post Discussion of cyphal support - #6 by tridge is a good start for work on this
10 Likes
No, I wouldn’t do that.
(As one of the first things) he said: “it is incompatible with DroneCAN, so you cannot mix DroneCAN and cyphal on the same CAN bus”. You can use them, I use DroneCAN and Cyphal on the same CAN bus and he lied. He could’ve said something like: in the ArduPilot driver that I use, I don’t separate DroneCAN frames from Cyphal (or whatever the real truth is). Maybe someone can help me here and say what he really would’ve said if he didn’t lie.
1 Like
Perhaps just asking him would be enough ? We aren’t Cyphal expert,so that is just correcting if somebody say a mistake about Cyphal, that’s the whole point of this discussion …
2 Likes
What’s interesting is Pavel said this:
Which does imply that they can’t be used on the same bus at the moment. Saying “I don’t think it would take much effort” is very different from saying “it already works”.
Also, the definition of lie is given as “to make an untrue statement with intent to deceive”, which is definitely not what he was doing, so I do agree with khancyr that you do not have the right to say he lied.
But I still haven’t seen anyone answer/explain how to solve the problem that Tridge raised with the ESC messages:
Yet a lot of people have posted “Cyphal is better choice for future critical applications”, “Cyphal is great” and that it “is more suited for the full control reservation tasks” without giving examples of why they say that. We need real examples of how these would work, rather than general phrases/keywords.
5 Likes
The intent is there.
I see that the discussion is starting to devolve. I will try to stir it in another direction. I’m a member of a student club that takes part in student engineering competitions. We leverage existing solutions like Pixhawk and PX4. But we heavily customize them to our needs. Here are our use cases:
For a rocketry project that took part in European Rocket Challenge, we heavily modified PX4 with Cyphal/CAN to manage subsystems along 4 meter long airframe. I really liked the heavy configuration-oriented approach of Cyphal, as it requires discipline in designing safety critical systems.
I’m now taking part in an autonomous surface vessel project which is quite complex. Featuring robotic arm, computer vision, etc. I really hoped to leverage ArduPilot for its existing boat support, and I was looking forward to Cyphal support presented in the aforementioned PR. Luckily we can shift the CAN interface from the flight controller to the companion computer.
I don’t really understand arguments against firmware size and compatibility with DroneCAN. From my experience, doing projects far away from the scope of fixed wing and quad-copter crafts, there is no one-size-fits-all. If there is so much angst around Cyphal/DroneCAN compatibility, why Cyphal cannot be hidden under a feature flag? Disabled by default, not burdening standard users. Or is it seen as a trojan horse by the ArduPilot maintainers?
8 Likes
I don’t follow the flash space concern; why not conditionally-compile? Ie, only compile Cyphyl support when required. Flash space will always be a concern on MCUs, and ArduPilot supports a large amount of features and hardware. I don’t think compiling unused features makes sense. So, if you make it (and other features) opt-in at compile-time, this becomes a non-issue.
3 Likes
As it was said but the is under the pile of debate here, Cyphal advertise itself as a replacement for DroneCAN, so allowing it in ArduPilot would mean that we switch over it and stop further developpement on DroneCAN, when we are actually developping DroneCAN.
Now as Cyphal isn’t restraint to CAN only, it will also require us a lot of dev time to adjust to all capacity Cyphal is experimenting and we are not kind for those now.
Hidding it under compile time could be a solution but will still require a lot of time to ensure it keeps working and that new feature are getting in and this will also leads back to point 1
And yes, flash size is a consern for us as ArduPilot is mainly used on MCU.
We could said, hey Cyphal is only available on Linux but we will have new complains to support it on MCU.
So we are stuck at : do we accept it or not for now.
Nothing is fixed for now, and we still looking at what ArduPilot developpement team think is the best for the project.
7 Likes
This discussion is very interesting in many ways as the solution depends on the point of view of the writer:
- For developpers, this is an attractive options as it “resolves” all the previous inconsistency of the “older” structure.
- For integrators , it offers many new ways to implement control and communication methods
- For Manufacturers it opens new markets for “better” controllers
- For ArduPilot Dev Team it adds to the existing load of Dev-Maintenance-Documentation
- For ArduPilot Support team it will require acces to new tools and hardware in order to Test, Document and Support the new features
- As a general architecture point of view , switching from centralized MCU based Flight Controllers to Distributed Sub-Controllers that can react to “Ad Hoc” messaging within the Control Bus, may have major incidence on the integrity of the system as a whole and ending up in a situation where no one can predict the behavior of the system… (read nightmare)
My 2 cents is that ArduPilot, as a Community, need to realign itself within the new landscape.
The ever progressing of complexity and regulation needed to step into Advanced Air Mobility will require a clear roadmap on what is possible and what is not, considering the available ressources within the community to develop, document and more importantly SUPPORT these new features.
3 Likes
Comrades, lay down your pitchforks, please.
I sense that much of the angst is centered around UDRAL, not Cyphal; let us please recognize that the two are independent entities, and let us avoid saying Cyphal when we mean UDRAL. Cyphal is a fairly mature protocol at this point, and it is not going to change, hence the red lines I proposed earlier. UDRAL is a draft proposal that was intended as a first stab at defining the application layer for small unmanned systems, and it has nothing to do with Cyphal aside from utilizing its transport layer. Any criticism towards UDRAL is welcome, and we are open to changing it or replacing it entirely; no red lines here.
To this end, @ponomarevDA has proposed a new set of DSDL definitions that are designed to be more in line with the prior art. We are open to replacing UDRAL with this new message set. I will skip the discussion of the technical merits of the new proposal; please proceed here for that, and feel free to add comments there:
Whether it is UDRAL or not, I urge everyone to recognize the fact that Cyphal enables network architectures that are impossible to construct with DroneCAN. This has already been hinted at correctly by @not7cd, @ppoirier, and others earlier. It is, indeed, unclear how the denial of these new use cases to the users of ArduPilot is expected to benefit the project, as pointed out by @maksimdrachov.
@ppoirier also raises the valid point of the maintenance-related costs. It is true that the ArduPilot maintainers are ultimately the ones who are responsible for the project. But what should also be kept in mind is that we, the businesses that funded the development of the pull request in question, are committed to funding the work required to keep the Cyphal implementation well-maintained and well-documented in ArduPilot upstream.
As to the objection to moving the Cyphal-related configuration parameters to the SD card. The SD card-based approach may have its own downsides, but it follows from Andrew’s original idea of using Lua scripts for Cyphal support, which is also dependent on the SD card. Further, as far as I know, it is impossible to arm ArduPilot without a functional SD card unless the default configuration is altered appropriately, so the proposal does not introduce new deficiencies to this end. We find both approaches acceptable while recognizing that each of them has its own merits and disadvantages.
For now, I suggest we refocus on the discussion of the new message set linked above. If you have specific technical feedback, feel free to bring it directly to the linked pull request.
6 Likes
Can someone post few videos of UAVs or any vehicles utilising cyphal? I see atleast 4 or 5 users who are already using this. I’m yet to see any hardware shown working throughout this discussion.
Possibly a video explaining and showcasing the advantages of cyphal over a set of hardwares would be useful for users like us.
I think this discussion will go on until we have a side-by-side comparison of same hardwares running cyphal and DroneCAN showcasing the advantages and disadvantages.
2 Likes
Why urge ? Where is the urgence and who denied that Cyphal allow network architecture ?
DroneCAN is for CAN only and that is what we ask from it.
Cyphal does something else ? Good but that isn’t the point. We are speaking about CAN and the replacement from DroneCan by Cyphal as that is what you ask.
For network architecture, we can use anything else on the market (dds, mqtt, etc.) So Cyphal is just one option in a mass. That is fine but not important for now considering how low availability board with tcp support there is.
So the question is do we want something that mix every transport layer or we stick to CAN for now ?
3 Likes
Doesn’t this situation suggest an interface/translator board/project may be appropriate? Something that can support a Cyphal network on one side with all it promises and then interface to Ardupilot on one or more layers/interfaces. An interface board could invisibly pretend to be multiple devices to the DroneCAN network by either forwarding (and translating) requests from Ardupilot to Cyphal devices or more likely buffering recent results it’s polled on the Cyphal network (depending on timing). It might also interface to Ardupilot through different interfaces simultaneously to communicate information not currently existing on the DroneCAN layer in Ardupilot (e.g. maybe commands that would be seen on Mavlink).
There seem to be disagreements on both protocol/physical layer issues (red lines, partial compatibility, resource usage, etc.), on functional layers (architectures and capabilities Cyphal wants to allow beyond current capabilities of that layer in Ardupilot), and on if the technology is better/worth it or not (which usually the market decides in the end). Predicting the future of technologies is hard; even if right, the timing can be tricky. Cyphal may be able to develop more freely if it isn’t tightly coupled with Ardupilot at an early stage when architectures are less clear; yet still being able to connect to Ardupilot somehow might help its development and adoption. Containing the chaos in another dedicated project that use the current interfaces of Ardupilot as long as possible could benefit both sides.
My 2 cents. If I’ve missed something obvious for why this wouldn’t work or if this is already being done, apologies for the wasted ink.
5 Likes
Hi, sorry for having added noise to the conversation. I felt entitled to highlight the importance of configuration, which is an essential safeguard to help avoiding having a deterministic yet chaotic system.
Indeed it would be welcome if someone pitched in with some visual aids. For my part, I have already provided the comparison of the two protocols, both abstract and practical; you can find these linked in my first response here. In the article “Cyphal vs. DroneCAN” there’s a section named “More practical examples”. If one wanted to evaluate a few basic Cyphal devices up close, there are some linked by @Roman_Fedorenko earlier in this thread.
We could also ask a (presumably) disinterested third party experienced with both protocols for an independent comparison; maybe @not7cd or someone else could volunteer.
Cyphal, indeed, supports multiple transports, but this discussion is focused mostly on CAN so what I say applies to Cyphal/CAN in the first place. Cyphal/CAN allows one to build more complex CAN networks than DroneCAN because it is not as rigid, and there is a class of applications where this capability is essential. That was the point I was trying to make earlier; I see now that I should have said Cyphal/CAN instead of just Cyphal for the sake of clarity.
Also, we are not offering to replace DroneCAN with Cyphal/CAN; as has been said here earlier, the two will go on side by side for a while.
It is good that you bring up DDS because Cyphal positions itself as a more robust and predictable alternative to it, and some view DDS as a more appropriate comparison base for Cyphal rather than DroneCAN. I’m worried though that this discussion might distract us from the main topic so I would suggest to either postpone it or split it into a separate topic, if there is interest to compare the merits of Cyphal against DDS and similar technologies.
Also, you seem to be confusing Ethernet and TCP. These are different things.
1 Like