SMALL - espritmodel.com SMALL - Telemetry SMALL - Radio
Reply
Thread Tools
Old Mar 27, 2012, 10:09 AM
Destroyer of G-10
askman's Avatar
United States, OR
Joined Jul 2004
10,085 Posts
Quote:
Originally Posted by Arx View Post
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 View Post
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.
askman is offline Find More Posts by askman
RCG Plus Member
Last edited by askman; Mar 27, 2012 at 10:15 AM.
Reply With Quote
Sign up now
to remove ads between posts
Old Mar 27, 2012, 11:05 AM
Registered User
VA
Joined Nov 2009
2,658 Posts
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.

Ok now I have done my part so its up to others make it happen
pug398 is offline Find More Posts by pug398
Reply With Quote
Old Mar 27, 2012, 02:49 PM
Registered User
Australia, QLD, Brisbane
Joined Nov 2011
949 Posts
Quote:
Originally Posted by askman View Post
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?
Erknie is offline Find More Posts by Erknie
Last edited by Erknie; Mar 27, 2012 at 04:38 PM.
Reply With Quote
Old Mar 27, 2012, 05:20 PM
Destroyer of G-10
askman's Avatar
United States, OR
Joined Jul 2004
10,085 Posts
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.
askman is offline Find More Posts by askman
RCG Plus Member
Old Mar 27, 2012, 06:22 PM
Registered User
Australia, QLD, Brisbane
Joined Nov 2011
949 Posts
Quote:
Originally Posted by askman View Post
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.
The Murata pezio gyros on the KKboard have a max response of 50Hz

http://www.murata.com/products/catalog/pdf/s42e.pdf

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.
Erknie is offline Find More Posts by Erknie
Reply With Quote
Old Mar 27, 2012, 06:33 PM
Destroyer of G-10
askman's Avatar
United States, OR
Joined Jul 2004
10,085 Posts
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".
askman is offline Find More Posts by askman
RCG Plus Member
Old Mar 27, 2012, 07:11 PM
Registered User
Australia, QLD, Brisbane
Joined Nov 2011
949 Posts
Quote:
Originally Posted by askman View Post
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".
Oh, yeah it was certainly changed. 4.5 180Hz, 4.6, 290Hz, 4.7 300Hz.

http://www.rcgroups.com/forums/showthread.php?t=1458663

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.
Erknie is offline Find More Posts by Erknie
Reply With Quote
Old Mar 27, 2012, 07:47 PM
Registered User
KC Flyer's Avatar
Lee's Summit, MO USA
Joined Jan 2001
387 Posts
Quote:
Originally Posted by Erknie View Post
Oh, yeah it was certainly changed. 4.5 180Hz, 4.6, 290Hz, 4.7 300Hz.

http://www.rcgroups.com/forums/showthread.php?t=1458663

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.

Sort of the opposite of the Hobby King freight depot

Maybe the net result is smoother adjustments with less overcontrol?
KC Flyer is offline Find More Posts by KC Flyer
Reply With Quote
Old Mar 27, 2012, 08:25 PM
Registered User
Australia, QLD, Brisbane
Joined Nov 2011
949 Posts
Quote:
Originally Posted by KC Flyer View Post
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.

Sort of the opposite of the Hobby King freight depot

Maybe the net result is smoother adjustments with less overcontrol?
Real time = 50Hz from the gyros on the KK as I mentioned before.

In the video from post 11 of this thread, http://www.rcgroups.com/forums/showp...7&postcount=11 the arm is wobbling at what, about 2Hz, how many sample points do you need to compensate for that?
Erknie is offline Find More Posts by Erknie
Reply With Quote
Old Mar 27, 2012, 10:11 PM
Al Ducharme
photronix's Avatar
Orlando, FL
Joined Jan 2005
734 Posts
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.
photronix is offline Find More Posts by photronix
Reply With Quote
Old Mar 28, 2012, 01:54 AM
hacker
Canada, BC, North Vancouver
Joined Dec 2010
936 Posts
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: http://www.rcgroups.com/forums/showthread.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!
simonk is offline Find More Posts by simonk
Reply With Quote
Old Mar 28, 2012, 07:22 AM
Al Ducharme
photronix's Avatar
Orlando, FL
Joined Jan 2005
734 Posts
Thanx for that simonk. This is the type of discussion I was hoping for.

I will post more data ASAP
photronix is offline Find More Posts by photronix
Reply With Quote
Old Mar 28, 2012, 07:53 AM
Registered User
United Kingdom
Joined Nov 2008
2,027 Posts
Quote:
Originally Posted by Erknie View Post
Oh, yeah it was certainly changed. 4.5 180Hz, 4.6, 290Hz, 4.7 300Hz.

http://www.rcgroups.com/forums/showthread.php?t=1458663

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'....

ps: interesting analysis photronix
Mike Barton is offline Find More Posts by Mike Barton
Reply With Quote
Old Mar 28, 2012, 08:38 AM
Registered User
Joined Feb 2011
1,450 Posts
Excellent discussion, thanks for the effort.

Are these Flytron esc's legit? They claim Simon firmware.

http://www.flytron.com/multicopter-p...t-pwm-esc.html
milo12 is online now Find More Posts by milo12
Reply With Quote
Old Mar 28, 2012, 03:15 PM
Registered User
Arxangel's Avatar
Bulgaria, Sofia-grad, Sofia
Joined Feb 2012
1,846 Posts
@photronix

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.
Arxangel is offline Find More Posts by Arxangel
Reply With Quote
Reply


Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Mini-Review BD5B or BD-5B Comparison of Aeroworks vs Hobby King FRENCHSTAN Electric Plane Talk 4 Jul 01, 2012 04:14 PM
Mini-Review 3 DVRs comparison (FPV-Japan, Foxtech D1, Wireless DVR 5.8GHz) sharonx FPV Talk 8 May 23, 2012 10:31 PM
Discussion X-Air FC1212-P / DJI Wook Kong WK-M Comparison dansparks Multirotor Talk 6 Mar 02, 2012 09:08 PM
Discussion Upgrade ESC instead of engine AND ESC. Dynasti Electric Plane Talk 15 Sep 23, 2011 09:42 AM
Wanted hobbi co. NexSTAR trainer rtf paintballer#1 Aircraft - Fuel - Airplanes (FS/W) 8 Mar 21, 2006 12:44 AM