# Some problems when sending actuator status messages **URL:** \ **Category:** Libcanard\ **Created:** [July 1, 2022, 8:29am UTC](https://forum.opencyphal.org/t/some-problems-when-sending-actuator-status-messages/1697 "2022-07-01T08:29:33Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [July 1, 2022, 8:58am UTC](https://forum.opencyphal.org/t/some-problems-when-sending-actuator-status-messages/1697/2 "2022-07-01T08:58:51Z")
First things first, what you are using is now called DroneCAN — [UAVCAN does no longer exist](https://forum.opencyphal.org/t/uavcan-v1-is-now-cyphal/1622). It will take a while for all the existing resources and materials to update the naming so certain confusion is expected to persist for some time. I see that you are using a data type that is not actually present in the standard data type set of DroneCAN, which is a problem by itself because you are not expected/allowed by the standard to add vendor-specific data types into the standard namespace (unless they changed this rule, which I doubt they did). That said, it is unlikely to have anything to do with your specific problem at hand. I recommend that you analyze the traffic on the bus using the DroneCAN GUI Tool or something similar to see what is happening with your CAN frames. It could be that some of them are being timed out before making it to the bus. We strongly advise that all new projects should adopt Cyphal/CAN instead of the legacy protocols because of its technical superiority. I wrote about this many times on this forum before, so let me quote myself below. > [@](#): > > Building any non-trivial system based on DroneCAN today would be a mistake unless you strongly require compatibility with legacy hardware out there. This is because of its inherent architectural limitations, which are covered in the Guide. I am fairly confident saying this since I was more involved in the architecting and designing of both DroneCAN and Cyphal than anybody else. > > Cyphal/CAN is **already [supported in PX4](https://github.com/PX4/PX4-Autopilot/tree/master/src/drivers/cyphal)**. Although the support might be considered somewhat minimal, it should be easy to extend since the hard part is already done. > > Cyphal/CAN is minimally supported in a fork of ArduPilot. There is an [**upstream pull request**](https://github.com/ArduPilot/ardupilot/pull/20408) which appears to be failing to gain the attention of the maintainers but one might hope to see it merged one day. > [@](#): > > 1. DroneCAN is only suitable for highly centralized systems where there is only one actor responsible for the consumption of data from the bus and the issuance of imperatives to other nodes. > > 2. DroneCAN is only suitable for networks that match the rigid architectural patterns envisioned by the authors of its data types. E.g., if you have a quadplane and the authors of the ESC service did not foresee that use case, you’re out of luck. > > 3. DroneCAN only supports CAN, which is being phased out in the industry. In five years every major medium- to the high-end vehicle will be heavily leveraging Ethernet. > > 4. All existing implementations of DroneCAN (both official and third-party) are seriously lacking in quality compared to Cyphal, which might make them inadmissible in certain systems. > > You may find more information on the differences here: [UAVCAN 2019 roadmap](https://forum.opencyphal.org/t/uavcan-2019-roadmap/666) If you are building a new product and require help navigating around the CAN ecosystem in the drone industry, feel free to reach out to [info@zubax.com](mailto:info@zubax.com) for assistance. --- _[View the full topic](https://forum.opencyphal.org/t/some-problems-when-sending-actuator-status-messages/1697)._