KDECAN - a new CAN protocol, first in ArduPilot

Blog
1

KDE-header-KDECAN-2018-C4
KDE-header-KDECAN-2018-C4.jpg2000Ă—461 361 KB

You have probably heard of KDE Direct, a leading manufacturer of brushless motors, electronics and components for the UAV market. KDE Direct has just announced the launch of a new CAN communication protocol; KDECAN will allow UVC series ESCs to actively monitor critical system components, increase redundancy and set the standard for operational safety in the drone industry.

ESCs and flight controllers use PWM signals to transmit information from the flight controller to the ESC. With the addition of KDECAN, the customer has access to a multitude of features including live telemetry, system warnings and redundant throttle control. KDECAN detects when an ESC loses throttle control via PWM and uses messages sent via CAN bus to continue operation, increasing reliability. The KDECAN communication protocol is available on the KDE Direct website (as well as nice setup instructions).

KDE Direct has hired my services to implement support for this new CAN protocol on ArduPilot, making our autopilot the first to support it. All code is now public (https://github.com/ArduPilot/ardupilot/pull/9619, https://github.com/ArduPilot/MissionPlanner/pull/1968) and after some re-work to comply with recent master changes, it will go under review, after which I expect it to be merged and available for testing on development builds. Telemetry information (voltage, current, RPM and temperature) from the ESCs is logged and sent via MAVLink, with ESC warnings expected to come soon.

As part of this collaboration, KDE Direct has joined the ArduPilot partners program, bringing the number of partners to 50! If you are also interested in being part of this program and helping support ArduPilot, go to http://ardupilot.org/copter/docs/common-partners.html#how-does-my-company-become-a-partner

I want to thank KDE Direct for our work together, it was a pleasure helping bring KDECAN to life.

15 Likes
2

Well this is something!

Really great work Francisco! One of AP’s motto’s is Versatility so it’s great to see another variety of CAN available in AP. It’s really quite something that we now not only support CAN but at least two varieties of CAN. I really look forward to giving these a try.

3 Likes
3

Nice work! Very exciting.

2 Likes
4

Thanks!

@rmackay9 I do hope this can lead the way for other CAN protocol implementations. I’m aware that our CAN structure has made some people unsure on how to do it in the past, so I hope this can also serve as a reference to it.

2 Likes
5

To confirm, this is a whole new protocol, and not a set of manufacturer extensions/definitions for the UAVCAN protocol? Will the two protocols be able to exist on the bus together, or will the use of these ESCs be mutually exclusive with UAVCAN sensors/devices in the future?

6

Fantastic! This is exactly the sort of thing ArduPilot needs heading into the future.

2 Likes
7

I’m half happy and half sad. Happy because a major vendor recognized the importance of ArduPilot and invested money to get their CAN ESC’s supported. This is great!
And I’m Sad, because the same vendor instead of using the already existent and well supported UAVCAN protocol, they created their own CAN based protocol, and put a restrictive license on it. This is not so great.

6 Likes
8

Me too, i see no point in another can implementation since there is already one functioning and supported. I only see fragmentation. I am really sorry but ultimately i see no reason for not using UAVCAN that is already there and compatible with esc and other peripherals already in the hands of users and functioning.
My 2 cent opinion is that money could have been spent a lot better in areas where are more needed than duplicating a protocol.

1 Like
9

Yes, new CAN protocol, it isn’t related to UAVCAN. Being different protocols, they can’t co-exist on the same bus. On boards with more than one port, you can, however, have both protocols running, one in each port.

I understand your point, but, before UAVCAN, there were other CAN protocols too - @Pavel_Kirienko worked with CANaerospace first, but thought it wasn’t good enough and created UAVCAN. I’m sure KDE Direct had their reasons to choose developing their protocol instead of going with an existing one.

I’m not sure I understand about the restrictive license though. It didn’t go by me, but I’ve read their documentation and I don’t see any restriction on using the protocol. Also, the code I’ve done is entirely GPLv3, so any project with a compatible license can use it.

10

I’m not a lawyer, but as I read the protocol documentation the following was not really convincing that the protocol can be used by other esc manufacturers…

You acknowledge and agree that you will not: (a) reproduce the Software; (b) modify, adapt, translate or create any derivative works
of the Software; attempt to circumvent or disable the Software or any technology features or measures in the Software by any means or in any manner; (d) attempt to decompile, disassemble, reverse engineer, or otherwise attempt to derive the source code for the Software;"

Don’t get me wrong, I’m happy that it is supported and Fransisco did a tremendous job, I just had some itchy feelings when read through the documentation…

1 Like
11

Ah you meant using the protocol in other ESCs. Yes, that seems to be blocked by that license, but I would say that is just typical lawyer stuff; after all, you can just look at ArduPilot code and make your ESC code comply with it :wink: Protocols are a really difficult subject when it comes to copyright.

1 Like
12

I’m excited for this, not just because its another available protocol, but because it sets precedent for CAN telemetry displaying through the same existing channels as BLHeli_32.
Hoping to see the feedback implemented for UAVCAN ESCs as well, in the near future.

At the very least it will help as a reference for implementing additional CAN protocols (for less experienced developers, such as I).

As for needing a separate bus to run KDECAN, I imagine the newer Pixhawk Cube (Orange, I believe?) with its third CAN bus will be helpful in running fully redundant UAVCAN alongside any forthcoming protocols.

1 Like
13

I agree with @Eosbandi; although as the original developer of UAVCAN, I am, obviously, heavily biased.

We spent a few years observing how UAVCAN is slowly gaining traction while collecting feedback, and now we’re using that experience to rectify certain design issues that are present in the current version of the protocol. In preparation for the first stable release (which we call UAVCAN v1.0), we are committed to fixing the existing high-level design issues that we were able to identify thanks to the extensive feedback we received (much of which came from the ArduPilot community, thank you):

  • An overly restrictive and opinionated set of standard data types that forces one to build their systems in a very particular way.
  • High resource utilization.
  • Lack of support for other transports such as CAN FD.
  • Poor support for vendor-specific and application-specific data types.

I suspect that some of these issues might have contributed to KDE Direct going their own way rather than adopting UAVCAN. We are open to their comments and opinions to try and make the standard more accommodating to other vendors.

Everyone is welcome to track our progress and contribute their opinions on the brand new UAVCAN discussion forum available at https://forum.uavcan.org. If you are not familiar with the ongoing work, then the following thread should be a good starting point: https://forum.uavcan.org/t/stockholm-summit-recap/170.

Thank you.

2 Likes
14

Pavel aren’t you the one that removed Ardupilot documentation from your Zubaxx site and told me and many other you don’t give any kind of support on Ardupilot?

No more than a month ago i was looking from help from you and you told me “go ask in the Ardupilot forum”, and now you come here??

This is not very coherent from you.

This is your exact words: " As we don’t have the capacity to fix ArduPilot or write proper user documentation for them, I am going to state in the product description that Zubax GNSS 2 is not recommended for use with ArduPilot. Hopefully that will prevent further confusion. We’d happily refund you or any other frustrated customer who ran into issues with ArduPilot.

I should emphasize here once again that providing support for third-party systems such as ArduPilot has never been our intention. What we sell is a device that conforms to a certain protocol. It is by design compatible with any system that upholds the other side of the protocol. We purposefully avoided stating compatibility with any particular implementation of the protocol, but I see now that that approach wasn’t clear enough for customers."

So if your products are not reccomended what are you complaining about here?

I must apologize for my previous words about KDE, if they will give any better support than “this guy here” i’ll be more than happy to adopt their protocol on my machines and be an early adopter. I mistakenly tought Zubax had nothing to do with UAVCAN but i was wrong. In the end if i had such a bad experience with them i could imagine what a nightmare would have been for KDE to develop something on UAVCAN with the level of assistance that these guys can give.
Now that i have a better picture of who is who i heavily changed my mind :slight_smile:

regards,

Corrado

p.s. I guess some new ESCs are on my buy list now :slight_smile:

15

While the removal of ArduPilot documentation from their site seems a bit heavy-handed, it is relevant that Zubax (a manufacturer) implements UAVCAN, which is a standard and not a product in and of itself [opinion].

The usage issues you had seem to be on the ArduPilot configuration end (or implementation). I myself don’t have any current issues, but I run Plane code, so it may not translate. So I do believe his point on not supporting ArduPilot (e.g. by providing development services, addressing user issues with software (Ardupilot code base) he/they are not responsible for) is fair. In other words, the ArduPilot community in your case should have been more helpful and relevant than the manufacturer. I, for one, having worked with the GNSS 2 should have tried jumping in myself to help you out - I balked at the opportunity due to my inefficacy at helping other users.

I would not take it that he “does not recommend” the products, but my take is that he does/can not certify that ArduPilot is in full compliance and fully functional regarding usage of UAVCAN (the standard which Zubax implements).

I have my own frustrations regarding intensity of the code base, which I hold to be a result of my own lack of experience. I say this so that you don’t misunderstand me as holding either the standard or the product on a pedestal.

1 Like
16

I am just reporting what happened and lack of any kind of sipport to me as a customer. Being a person that paied for their product i guess i deserve something better than remove ardupilot docs from their site.
As for ardupilot forum support i asked for help here and i got some, but this is a free forum and people have all the rights to help if they feels so or not help. Different thing is the forum that sold me my Zubax peoducts, they should have tried to help a bit more, at least trying would have been very nice.

As for him “not reccomending” his products for ardupilot, that is EXACTLTY what he wrote in his posts.

The guy is at least a bit confused as he thanks feedback from ardupilot in his post but he removed ardupilot docs from his site…

All that said, my experience with their GNSS gps has been so poor in respect to assistance that it stopped me going the UAVCAN route on all my ESCs, wich i’ll do once kde comes out with their new escs (with their new protocol) because i like very much what canbus esc can offer, both on security side and performace and of course bidirectional comunication .

Regards,

Corrado

17

@anon67614380 the opinion expressed by Evan above is entirely correct and I don’t have much to add.

Yes, we do not recommend using Zubax GNSS with ArduPilot, because the latter’s support for UAVCAN-interfaced compasses/barometers is lacking.

No, I am not going to fix that, as I don’t have the bandwidth for that and I don’t want to touch the ArduPilot’s codebase, but I would be happy to assist whoever attempts to fix that.

Yes, I have removed the documentation because it happened to be obsolete (it used to be applicable to ArduPilot until they reimplemented their CAN stack from scratch, so it lost relevance entirely and there was no point keeping it around).

Yes, ArduPilot has helped the UAVCAN project a lot and I am thankful for that.

The reason for your confusion is probably due to your failure to understand how standards work. To help you out on this, let me resort to an analogy: suppose you have a laptop with a USB 2.0 interface. One day you decided to buy an HD webcam, which happened to use USB 3.0 being incompatible with USB 2.0. You connect the camera to your laptop, but it’s not working. Frustrated, you call the camera vendor and demand that they fix your laptop. Doesn’t really make sense, does it?

KDE happens to take exactly the same stance on the matter. If you read their documentation, you’d see this stated in the very beginning:

As detailed below, KDE Direct, LLC. (“KDE Direct”) does not manufacture this third party product and therefore does not support or warranty the safety, use, functionality or compatibility of any third party flight controllers. Any information as to a third party controller is provided solely as a reference. Please refer to documentation accompanying your third party controller and any updates issued by the third party controller manufacturer for best practices and/or other information related to the safety, use, functionality or capability of your flight controller.

I hope this made things clearer.

18

If on the USB camera site of the vendor there was a doc on how to install that camera on my laptop when i purchased it, yes i would want some help and no, just removing the how to from their site would not fix the situation.

I fully understand how standards work, i am an engineer specialized in iso 9001 certifications.

The reason for your confusion is probably due to your failure to understand how sales and support work. To help you let me resort to an analogy: suppose you buy a car and it clearly states that it can run above 3000 meters with no problems, but once home (you live on the mountains) you discover it lacks power and all in all it is not good for riding on mountains, now obviously you can’t ask the vendor to come with a caterpillar and get rid of the mountains but maybe he can give you some advice on how to get best performances while riding on the mountains and at least try to be of some help because in the end you gave him your good money based on a doc that said “works on moutnains”.

Just for your info, the “latter support” for UAVCAN from Ardupilot supports both compasses and barometers inside Zubax GNSS, but i guess you are a way too busy manager to write half a page on how to configure latest AC 3.6 parameters and have your GNSS fully functioning on Arducopter (and yes 3.6 is still beta but being RC12 it is pretty safe, anyway you could point it out on the help page). I think it would have taken you same time it took to write in this thread and would have GREATLY helped people that supported your company buying your products to have their purchases working correctly. This is good customer care, no USB 2.0 - 3.0 bull…

In case you decide to help your customers and write the doc please do not forget to add a line on how to change scaling on magnetometer to have it working correctly, but i doubt you’ll do it…

As of KDE writing same sentences as you i’ll let you know once i’ll try their customer support if they will tell me to “go to ardupilot forum” to get help or they’ll try to help as much as they can one of their customer, you’ll be amazed at how smart companies try to help their customer and preserve their business and try not to let them down.

Hope this made things clearer.

1 Like
19

Great work! This is great news, as it’s been difficult to use CAN ESCs with so few hardware implementations (with open interface) available.

And welcome new Ardupilot partner KDE!

1 Like
20

The ESCs are already on sale, they were before, it just didn’t have CAN active. As said on the post, it’s the UVC series.