KDE XF esc's

fltundra

Member
Another bit of info:
https://vimeo.com/album/2616894
Much more important than the choice of ESC is, to have a minimal number of connectors between Motor and Battery, from my point of view - one - is the only acceptable number. Most ESC burn when loosing of one phase under load, or even when the resistance of one phase only explodes. So taking care on your soldering points means to take care on your ESCs, and do not place them somewhere hidden from fresh air, or do not additionally isolate them with any material of your choice.


@Carapau
quite a number of people were using Jeti (including me) and were impressed how nice the DC-16 looks and feels - until ...
now I have 2,5K electronic waste and cannot even sell it because I know what it can do (cannot do)

best regards
Ferdinand
 

Fat Corgi

Member
Forgive a possibly naive question, but do esc's behave differently with different flight controllers? It was mentioned earlier about the different rates at which the esc's can interpret the signals, but do we have to change anything in the settings for either the Flight Controllers or the esc's? In particular, with reference to the DJI stuff controllers.
 

KDE Direct

KDE Direct, LLC.
Hey Everyone -

In response to your inquiries, we have updated the latest production KDEXF-UAS55 ESCs to utilize 13GA power-leads, replacing the 14GA power-leads originally used. This will help to reduce wire temperatures and resistance, further increasing the efficiency of the entire system. Website images will be updated soon, and the latest Design Geometry diagram can be viewed here: http://www.kdedirect.com/files/KDE_Direct_XF_UAS_55A_ESC_-_PRS_.pdf.

http://www.kdedirect.com/KDEXFUAS55.html

Thanks,
Patrick
Owner, KDE Direct
 




fpmurphy

Member
I have 8 55's from the first production batch, which I'm using on a build in progress. Is replacing the power leads something you recommend? I'll be running the 4014's with 18" props lifting around 10-11kg.
 


ary

Member
I replaced my old 400mhz esc on X8 with KDE 35AESC. Faster respons... less oscilating. Solid performance

My X8 config: MN 4014(330kv), Tmotor 17x5.8, WKM, 1000mm frame

Ary
 

Attachments

  • Screen shot 2014-08-07 at 9.30.58 PM.jpg
    Screen shot 2014-08-07 at 9.30.58 PM.jpg
    9.4 KB · Views: 217


R_Lefebvre

Arducopter Developer
So just out of curiousity, how can KDE claim these ESC's have a 600Hz refresh rate, when it's physically impossible to run a 1000-2000uS PWM signal at faster than 490Hz.

I mean, I'm not saying it's hard to run it faster. It's defying-the-laws-of-physics impossible. To run 600Hz, you need to limit the PWM range to 1666uS
 

fltundra

Member
So just out of curiousity, how can KDE claim these ESC's have a 600Hz refresh rate, when it's physically impossible to run a 1000-2000uS PWM signal at faster than 490Hz.

I mean, I'm not saying it's hard to run it faster. It's defying-the-laws-of-physics impossible. To run 600Hz, you need to limit the PWM range to 1666uS
That's what i have always understood, 490hz is max.
 

R_Lefebvre

Arducopter Developer
All this seems to imply that the higher the refresh rate, the better... without bounds.

Consider a quadcopter in level stabilising mode, the flight controller is making small adjustments in throttle to each motor to keep the quadcopter level. It is making those adjustments based on input from gyros and accelerometers, and you might thing the faster that the control loop responds, the better, and so a faster throttle response in the ESC implied by higher refresh rate is naturally better... without limit.

There is a practical limit to the rate at which the quadcopter can rotate in any axis, a limit imposed by available power and stability of the control system. A high refresh rate helps in the goal of a stable control loop with rapid response. In fact, in some flight controllers the maximum slew rate is a user tuneable parameter of the flight controller algorithms, so you might choose a lower value that the available power supports.

Problem is that the gyros and accellerometers are detecting not only small attitude changes in the platform, but vibration in the frame induced principally by out of balance motor / propeller combinations and exacerbated by frame resonances. This latter signal component is known as noise, it is undesirable components of the total sensor signal. A two blade propeller spinning at 12000rpm creates fundamental vibration component at 200Hz, but there may be significant harmonic component.

So, is there real benefit in extending the frequency response of the control loop (by increased throttle servo refresh rate in the system) when most of the higher frequency component is due to noise.

The situation you may have is that there is rapid adjustment of throttle around the desired target caused principally by noise, by vibration, and adjusting the motor speed will not eliminate that vibration, it just consumes more power in the rapid small variation in motor speed.

In my own experience with MultiWii, I select a low pass filter option of 98Hz to improve stability by filtering noise. The quads are still highly responsive, much more responsive with SimonK than any of the stock FW that I have tried, but with a 100Hz LPF, I don't need 600Hz servo refresh, 200Hz is adequate... but I fly with the MultiWii default 50Hz refresh rate.

So, I would not obsess over different claims of 480Hz vs 600Hz, there are other more important factors which might differentiate the ESCs.

Owen

This bears repeating, because this guy knows exactly what he's talking about.

In fact, he mentions MultiWii with a 98Hz Low-Pass Filter. Did you guys know that Arducopter has a default 10 Hz LPF? Seriously. Might be 20, can't remember, but everybody runs it probably without even realizing it. The fact that nobody has noticed, is great evidence that super-fast refresh rates are just marketing. Everything above 10-20 Hz is just noise.

Even on a SRH, where people have been talking about fast update rate servos, and even shorter pulsewidths (760uS) to get past the 490Hz limit... Still runs through a 10Hz LPF on Arducopter. And nobody is going to tell me that it's hurting performance. I can clearly see the rotor turning around, measure the RPM in fact, from the vibration logs. So the 10Hz LPF isn't hurting anything.

Simply put, these airframes do not respond at 400+Hz.

When you get the PID tuned up too fast, and it's shaking, that's the resonant frequency of the system. And you can see the movement. The human eye can't see anything past 60Hz, that's where everything is just a blur. The actual resonant frequency is more like 5hz on a small quad.

Now, does reducing control system lag help, even if the response rate is already faster than the system resonant frequency? Yes. A little tiny bit. But it's really not worth worrying about. I wouldn't choose a flight controller just because it runs faster than another. There's far more important things than that.
 

baja-king

Here for the ride :)
Any luck with testing?

I have only bench tested the KDE 4014-380's with both the KDE 35A ESC's and the Herkules as the 4014's have been returned to KDE for rework following on from the 2 shaft failures that other customers had suffered.

The Herk works well with the 4014's on the ADV24: Phase advance setting. The motors are slightly noisier with the Herk but this is common for all the motors I have used with it.

The KDE 35A ESC's run very smoothly - my only concern about them is that they have a soft start which activates every time the throttle channel hits zero - even when they're running. Not sure a FC would reach zero while running but the effect wouldn't be great.
 

Av8Chuck

Member
Now, does reducing control system lag help, even if the response rate is already faster than the system resonant frequency? Yes. A little tiny bit. But it's really not worth worrying about. I wouldn't choose a flight controller just because it runs faster than another. There's far more important things than that.

One thing that I like about this forum is the way everyone shares information, on other forum I'm a lot more skeptical that people are always trying to talk me into or out of a particular product based on their own biases and not from any actual data and there seems to be far less of that sort of thing here. I hope it stays that way...


You and Owen kind of mention the same thing that there are more important things to consider than just the refresh rate, would you mind explaining what some of those things are in a
way that a layman would understand?

I just purchased KDE motors and ESC's because my perception is that these products would be more reliable, what's the best way to determine if this is true? [not my perception, but if KDE's are indeed more reliable]...
 

Motopreserve

Drone Enthusiast
One thing that I like about this forum is the way everyone shares information, on other forum I'm a lot more skeptical that people are always trying to talk me into or out of a particular product based on their own biases and not from any actual data and there seems to be far less of that sort of thing here. I hope it stays that way...


You and Owen kind of mention the same thing that there are more important things to consider than just the refresh rate, would you mind explaining what some of those things are in a
way that a layman would understand?

I just purchased KDE motors and ESC's because my perception is that these products would be more reliable, what's the best way to determine if this is true? [not my perception, but if KDE's are indeed more reliable]...

I agree with Chuck, and would also like to hear more detal on the "more important" factors involved with the performance of the ESC with our FCs.

Also, I searched the shaft failure for the KDE motors but didn't find anything. Can you link or elaborate? I recently received my KDE motors and ESCs.

Appreciate the help.
 

baja-king

Here for the ride :)

R_Lefebvre

Arducopter Developer
One thing that I like about this forum is the way everyone shares information, on other forum I'm a lot more skeptical that people are always trying to talk me into or out of a particular product based on their own biases and not from any actual data and there seems to be far less of that sort of thing here. I hope it stays that way...


You and Owen kind of mention the same thing that there are more important things to consider than just the refresh rate, would you mind explaining what some of those things are in a
way that a layman would understand?

Ok, I'll try, but it'll be hard to make it not sound like an advertisement for Arducopter. ;) It's also pretty hard to answer this in a simple way, without getting into specifics.

Obviously, the #1 thing is reliability. If the damn thing causes crashes, or you just don't feel confident using it because of crashes others are having, then what good is it? Unfortunately, very few controllers are perfect. We're not, and I wouldn't pretend to say we are.

So failing that, as most do, you're left with the question "what happens when something does go wrong"? And here's where you get drastic differences between controllers in this class. Does it do datalogging? I would never fly anything without datalogging. Period. Then, can you effectively review the datalogs yourself? If you can't find the problem, can you have a discussion with people who REALLY know the system? Can they answer all your questions? Or do they get stuck pretty quickly and stop responding?

At the end of the day, after you have a crash, or you see somebody else with a crash, do you have confidence that the problem really wasn't caused by the flight controller? In my experience, most crashes are caused by external factors, but I can usually show this in a convincing way, and the users are satisfied. I often can say things like "Looks like your rear right motor failed in flight, you can see that here:". A common response is "Gee, I went and checked, and yes I found the motor bell is slipping on the shaft, thanks!"

Then what happens if the flight controller has a problem? Can you talk to the software engineers? Can they show you the error? If they can't show you the error, can you be confident that they really found it? Or, once you are certain that the controller had an error, do they just shut up and you don't hear from them again? Maybe they release a new firmware several months later, with no mention of the issue, and you can never be certain if they found the problem or not?

I personally talked with the ex-employee of one company (who shall remain nameless). He confirmed that company policy was "You never admit the system has an error. Ever." I don't know how anybody could ever have confidence in a system like that.

Let's be frank. These systems are extremely complex. But they're being offered at a price that does not allow for rigorous military-grade reliability testing. Stuff happens. It's what happens after the crash, that determines if the system is trustworthy or not. Are the people writing the software open, honest, transparent, competent, etc?

This also relates to how they talk to you about features. Do they blow smoke up your butt with physically impossible things, such as passing commands at 600Hz or 800Hz (as another one has in the past) when the laws of physics only allow for <500Hz? (on a 1000-2000 uS PWM signal) Does it sound like they are making things up as they go? Does everything they say seem to indicate they are trying to sell you something? Can you ask them *any* depth of question, and they answer in a clear, understandable way? Or does every answer seem to be "It's better and more expensive, because the knob goes up to 11." Do their answers seem to come from the engineering department, or the marketing department?

For example, this is why these fast refresh rates are impossible. A Pulse Width Modulate signal, means that the signal exists as a time-width pulse. It's just a square wave that turns on, and then off. With width of the on-time, is the strength of the signal. For 40+ years, the standard signal has had a width from 1000 microseconds, to 2000 microseconds. 1000 means effectively "zero". 2000 means "maximum". Now, 500 Hz, means 500 cycles per second, or 500 square waves per second in our case. 1 second, divided by 500 signals/second, means that every signal would take 0.002 seconds, or 2 milliseconds, or 2000 microseconds. This is why you can't run faster than 490Hz. 490Hz is 2040 microseconds. You're trying to push a square wave signal, that is up to 2000 uS long, and you need some "off time" between pulses, to mark the end of the signal. The signal can't just be on 100% of the time, that's not a signal, that's just DC voltage. 490Hz updates, means that you have a window of 2040 uS to fit your 1000-2000 uS signal. That means if you have 2000uS pulse-width, you have 40 uS to "mark" between pulses.

Hopefully I've now explained why this is impossible. Then you'd have to ask yourself, why would anybody market something as having a 600Hz update rate, when it's impossible for the flight controller to update the signal that fast?

This is the biggest stuff to me.

Now that that is out of the way...

You come down to features. Obviously the system has to do what you want, and at a price you can afford. Only you can determine that. You also have to consider if the system has more features than you need, and if this just leads to too much complexity for you. Some people only need a really basic system, and don't want to be confused by stuff they won't need.

And then you get into the nitty gritty of the flight experience. How well does it fly? Can you put it on a sporty machine and have fun? Can it also fly a camera ship nice and smooth and stable? If not, why not? When I see controllers with very low angular rate limits, or low angle limits, if it can't handle being upside-down... I wonder what they have going on inside there. You may not ever want your camera ship to go upside-down. But you have to ask why the flight controller can't handle it? Does the controller freak out if you turn it too fast? Why?

What happens if you lose a motor in flight, and the aircraft initially flips or spins before the controller can respond. If the flight controller freaks out soon as it's upside down, or turns too fast, can it still save the aircraft?

I take a dim view on controllers that have a 150 deg/sec rate limit, or 30 degree angle limit, etc. I just wonder what's going on inside there.

This is totally becoming an advertisement now, so I'm not sure I should continue...

I would love to go in-depth on a feature-by-feature basis, but it's almost impossible as I can't compare and contrast how different features work, because nobody has any inside information on these other systems. I could go on to talk about Earth-Frame to Body-Frame control rotations, etc. but we don't know if the other systems do this or not.
 

Fat Corgi

Member
Has anyone run the KDE esc's off a Wookong and experienced any problems? Will any of the esc settings have to be change in order for them to work well with the flight controller, or is it a case of you can simply hook them up and away you go?
 

KDE Direct

KDE Direct, LLC.
Has anyone run the KDE esc's off a Wookong and experienced any problems? Will any of the esc settings have to be change in order for them to work well with the flight controller, or is it a case of you can simply hook them up and away you go?

The ESCs are calibrated at our factory and compatible with the DJI equipment (tested on the Wookong, A2, and Naza-M equipment). No programming is needed - simply hook them up, check motor direction (and swap two of the three motor lead wires as needed), and go fly. The ESCs use dynamic algorithms to match to the motors, as well as the frequency-rate from the controllers, so they are simply plug-and-play designs without the need for manual-adjustments.
 
Last edited by a moderator:

Top