I'm pretty sure the ramp isn't completely gone. I think he's just using a different algorithm for it.

Quote:

Originally Posted by simonk

This tree is my attempt to simplify and improve quax' original code, and make it support multiple boards. There are some feature improvements now, and I've been hacking on it fairly heavily over the last month. See the commit history and README and stuff on github at https://github.com/sim-/tgy and https://github.com/sim-/tgy/commits/master/ . Some people have sent me motors and boards to test/fix weird corner cases, so hopefully it will turn into something that works well for everybody.

The main thing that pissed me off enough to start hacking on it was the 8kHz PWM frequency that Turnigy Plush boards were stuck with (causing the annoying audible whine), the clicking with lower kV motors, the screaming instead of proper restart if the motor is stopped while running, and the averaged throttle response instead of immediate input->output (with some timing-based limiting to avoid overcurrent, only at low speeds). All of these should be fixed or improved over the OEM firmware and quax' tree.

we do know that the biggest improvement occurs when FCB output goes from low 100 to 250hz. KK's code went from 150 on v4.5 to near 300 on v4.7 and big improvement on stability. same with UAVX. when we add simonk's on top of this, you see a minor improvement, so we do reach satuation point when you consider simonk is at least 2x quicker due to elimination of average. Should try with v4.5 KK and simonK vs V4.7 without and see if it behaves similiarly. The trick is finding a way to measure this in a repeatable way.

Perhaps someone can program a microcontroller to sweep the esc throughout its operation range at different frame rates. Each frame rate test would include both linear sweep, modulated sweep and small/large step size. Output can be measured at the prop as rpm response time and each data set could then be used to generate the necessary graphs/plots/curves.

we do know that the biggest improvement occurs when FCB output goes from low 100 to 250hz. KK's code went from 150 on v4.5 to near 300 on v4.7 and big improvement on stability. same with UAVX. when we add simonk's on top of this, you see a minor improvement, so we do reach satuation point when you consider simonk is at least 2x quicker due to elimination of average. Should try with v4.5 KK and simonK vs V4.7 without and see if it behaves similiarly. The trick is finding a way to measure this in a repeatable way.

Why was this? Was there a measurable backlog of update from the FC to the ESC that were not getting out on time?
What's the sample frequency of the gyros on the KK board?

Sampling frequency runs at the same rate as the refresh rate I believe in both KK and in UAVX as it is in same loop. so, you do gain in the sampling. IN UAVX especially, this was just speedup of the loop, while in KK, there was some firmware change with addition of integral, so there is bit of difference there for kk board. Integral should not affect hover characteristic as much though. In both cases, flight stability improved and I could run higher "p" in tuning, and it just felt more solid in the air.

now, quadroufo used to sell flashed esc even before the uavx was changed to run at higher frequency.

If esc refresh is the main cause of flight improvement, may be it would be best to test lower refresh setup with simonk vs standard firmware and compare it against refresh rate change.

Sampling frequency runs at the same rate as the refresh rate I believe in both KK and in UAVX as it is in same loop. so, you do gain in the sampling. IN UAVX especially, this was just speedup of the loop, while in KK, there was some firmware change with addition of integral, so there is bit of difference there for kk board. Integral should not affect hover characteristic as much though. In both cases, flight stability improved and I could run higher "p" in tuning, and it just felt more solid in the air.

now, quadroufo used to sell flashed esc even before the uavx was changed to run at higher frequency.

If esc refresh is the main cause of flight improvement, may be it would be best to test lower refresh setup with simonk vs standard firmware and compare it against refresh rate change.

Which means if you read all 3 axis in a row with no pause in between, that would be a max of 150Hz of data updates read by the FC. Still far short of the magical 400Hz it's being asked to spit out to the ESC, I wouldn't expect to see the gyros signal at the full 50Hz unless it was from vibration, the meaningful attitude changes should be a lot less than that.

I could be wrong on KK sampling. it is written in assembly and I was just guessing on my part. I am more knowledgeable about on UAVX. (which uses different gyro) I do believe that on kk, the esc refresh rate was changed from v4.5 to v4.7 from 150 to 290hz. that means just the output rate was changed with addition of "I".

I could be wrong on KK sampling. it is written in assembly and I was just guessing on my part. I am more knowledgeable about on UAVX. (which uses different gyro) I do believe that on kk, the esc refresh rate was changed from v4.5 to v4.7 from 150 to 290hz. that means just the output rate was changed with addition of "I".

What I want to understand is where is this data coming from at 300Hz, if the only inputs are the pilot, and the gyros. Is the FC simply padding the data, or is it making pre-emptive changes of it's own that are way faster than the input from the gyros and the pilot? Think of it as a freight depot, if there are only so many parcels coming in per second, then there can be only that same many parcels going out unless the freight depot is making up it's own parcels to send out on top of what came in.

The flight controller is the freight depot. It can only request the ESC to make changes as often as the pilot and gyros report a change.

There are only a few things that a pilot is going to notice, unwanted rotation, drift, or wobble they will usually be a few Hz or less, all pretty slow stuff in terms of what the sensors and FC can detect. Lastly will be joystick response, which will once again be below a few Hz. If the craft lags the joystick input, that can be from a whole chain of things, if flashing ESC firmware appears to improve that, then which change in the firmware was it? As I have pointed out, the perceivable events are pretty slow compared to the speed the electronics is working at.

What I want to understand is where is this data coming from at 300Hz, if the only inputs are the pilot, and the gyros. Is the FC simply padding the data, or is it making pre-emptive changes of it's own that are way faster than the input from the gyros and the pilot? Think of it as a freight depot, if there are only so many parcels coming in per second, then there can be only that same many parcels going out unless the freight depot is making up it's own parcels to send out on top of what came in.

The flight controller is the freight depot. It can only request the ESC to make changes as often as the pilot and gyros report a change.

There are only a few things that a pilot is going to notice, unwanted rotation, drift, or wobble they will usually be a few Hz or less, all pretty slow stuff in terms of what the sensors and FC can detect. Lastly will be joystick response, which will once again be below a few Hz. If the craft lags the joystick input, that can be from a whole chain of things, if flashing ESC firmware appears to improve that, then which change in the firmware was it? As I have pointed out, the perceivable events are pretty slow compared to the speed the electronics is working at.

Could it be that if the freight depot is not staffed by a bunch of slakers, they take inputs from the sensors in real time and send out product as soon as they can? Like FedEx on steroids.

I agree with you Erknie. This is part of the reason I wanted to look at some real data on the ESC/motor combinations.

There seems to be a call for faster updates when for one its not really possible given the physics of the propeller and motor momentum.

I have some more data I will post hopefully Wednesday morning. So far I do not see much of a difference between stock Turnigy and re-flashed Turnigy. I am using this as the test pair for now....

As for the video you mentioned. I would really like to see a side-by-side demonstration of stock and reflashed with the throttle ranges calibrated between the two. Maybe use the same gyro output with a Y connector to the two ESCs. One real problem I have with that particular video is it just seems like the throttle average is balanced for the "good" case and not for the stock case.

Yes, updates faster than ~100Hz are pretty stupid when flying an object of ~1kg mass. The update interval should scale with the mass of the object.

The reason kapteinkuk moved to higher output rates is clear in his own thread: https://www.rcgroups.com/forums/show....php?t=1250488 ... It's not about changing the duty cycle that many times more per second, it's about working around the duty cycle low pass filtering and control delay in the ESC software. The OEM Hobbywing series (Turnigy Plush, etc.) ended up being fairly easy to work around by just sending updates more quickly. The result is fairly reasonable for a multi-rotor, so fast updates and compatible ESCs are often recommended (like in that thread) and in other places like on rcexplorer.se. This is also why I bought Turnigy Plushes originally for my tricopter.

(Un)fortunately, I couldn't stand the 8kHz PWM whine and clicking from buggy(?) battery voltage testing, and some other issues like not being able to disable low voltage cut-off (or easily switch it to NiCd to work around it) made me look around and find quax' tree, which was pretty easy for me to start playing with. quax' original tree has a "change_tot" define and code which limits the throttle changes to 1 PWM step per change_tot PWM cycles. I ended up removing this and not putting it back. I removed a lot of this originally to understand why it was there, and learn more about the code and hardware. In my tree currently, the code is optimized as much as possible to immediately update the output as quickly as possible. The only limiting are two defined steps, originally in quax' tree, which prevent excessive duty cycles when starting and until certain motor RPMs are exceeded.

My understanding is that the reason for the low pass filter is a compromise. Many manufacturers chose a fairly strong filter / very conservative bandwidth because there are a number of problems that can occur without it, and the ESC becomes more reliable with conservative control bandwidth and so can be more inexpensive for the same current rating. Before the multi-rotor world appeared, not many people noticed or cared, and so things worked fairly well.

Sensorless motor timing tracking can become a lot more difficult with higher currents from rapid acceleration. A lot of ESC software cannot recover when motor timing has been lost, and usually spool up to very fast timing, forming patterns with the inductive properties of the motor. For example, original AVR Turnigy Plush/RCTimer <=30A code will squeal if the motor is quickly stopped (try with a small motor in your hand at a moderate duty cycle). Their SiLabs code has improved this significantly, but it can happen quite easily with most software. A similar result can happen with certain motors just by accelerating too quickly.

However, the biggest issue is that a stopped or nearly-stopped motor which is suddenly given 100% duty cycle will draw a very large amount of current, usually many times the rating of the ESC. All motors will do this to varying degrees because their mass is not 0, and the only things that otherwise prevent extreme currents are the resistance of the whole circuit (battery, FETs, wires, motor windings), and their inductance properties during the commutation phase. So, this becomes more important with low resistance circuits, higher supply voltages, and higher masses.

The nicest solution to this problem is a real-time current limit that would allow the ESC to limit every PWM cycle so that the rating is not exceeded. This is absent from most ESCs I believe because it would add significant cost (and integrating it with a typical MCU is difficult without some sort of external interrupt, meaning more and/or different components). However, it is absolutely required in some applications, such as brushless electric bicycle controllers. These controllers spend a good deal of their life current-limiting.

There are some new ESC projects that accept RPM as the input command instead of duty cycle. These have their own closed-loop control and allow a desired RPM to be reached with minimal delay and overshoot. However, the fastest way to increase RPM is still 100% duty cycle until that timing is reached, assuming nothing explodes, so the same problems come up and are now even more of an issue. A lot of these issues are typically masked by a flight controller gain set low enough (to avoid oscillations) that normal flight never exceeds the ESC rating when paired with a typical motor/propeller combination.

I believe the limiting factor for most setups is usually the lag caused by the low pass filtering and the fact that without active braking, the propeller always speeds up much faster than it slows down (due to drag). With active braking, RPM control, and very low latency, gains could be much higher (eventually at the expense of efficiency).

Did you see my earlier post? I am interested in your raw data and, at the very least, how the numbers trend as your input throttle signal frequency increases. Sorry for the long post without data. Cheers!

What I want to understand is where is this data coming from at 300Hz, if the only inputs are the pilot, and the gyros. Is the FC simply padding the data, or is it making pre-emptive changes of it's own that are way faster than the input from the gyros and the pilot? Think of it as a freight depot, if there are only so many parcels coming in per second, then there can be only that same many parcels going out unless the freight depot is making up it's own parcels to send out on top of what came in.

The data is from the gyros/Rx - the ESC rates shown are the loop rate of the KK firmware,
ie: it reads gyros, user Tx input (nb: this only comes in @ 50Hz) and then calculates the response to send to ESC's
and does all this ~300 times/sec

You can read the gyros as fast as your processor (or digital interface!) can - even >1000Hz and then maybe do some averaging.
But you are limited to whatever limitations of the communication protocol is used by your ESCs (eg std PWM is typically max of ~500Hz)
probably going a bit O/T on this tho'....

Hi, and think you for the insightful data that you provide. I would really like to see a test of the new Turnigy HeliDrive ESCs that recently became available at HobbyKing (there are also versions with 80A, 100A, and 120A). They appear to be a serious piece of ESC but it will be best if someone, that knows what he is doing, can test it.