OneShot PWM output for new ESCs

[laurienzu]

Here is the concept of oneshot PWM by Felix:

"normaly MWC workes with 488Hz periodic PWM witch mans one PWM cycle takes ~ 2.2ms and the value that need's to be send can just be updated after each cycle. the loop runs asynchronous with ~2.2 - 2.5ms. that means that it will take in the best case 1ms and in the worst case 4ms till a new calculated signal reaches the ESC.

with one shot the PWM ouput is synchronous with the loop time. so after each loop one new PWM signal is generated with the newest value. here we have min. 1ms and max. 2ms till the signal is there.

and as oneshot125 just uses 125-250us (instead of 1-2ms) the signal will just take 125-250us to be send"

SOURCE:http://www.multiwii.com/forum/viewtopic.php?f=7&t=2729

It is a function that is available with the KISS http://flyduino.net/KISS-ESC-2-4S-18A_1, Ultra ESC's and now also BLheli in combination with some MultiWii FC's.

I know that maybe this would have more sense for acro mode but I think that a crisp servo response is always welcome :)

[lthall]

That's the plan. The only catch is the different gyro sampling rates.

[jschall]

The simple solution to that is to sample the gyro at 8khz and keep running the controls asynchronously. Otherwise we'd need to run 333.3hz instead of 400hz - sending a PWM every 3 gyro samples.

On Mon, Oct 26, 2015 at 2:43 PM, Leonard Hall notifications@github.com wrote:

That's the plan. The only catch is the different gyro sampling rates.

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1825#issuecomment-151293167 .

[hw4ubuntu]

That would be awesome to support oneshot. I'm developing a 250 Racer with Pixhawk at the moment and Latency is cruicial in my point of view!

[CodeChief]

Any progress on this? Some ESCs with BLHeli firmware are shipping with OneShot enabled and PWM disabled by default! It seems like we missed the boat, now APM looks like it's got compatability issues. For anyone wishing to correct this you need to enable the PWM output option and disable the PWM dithering option (leave legacy/"high").

[trollcop]

Funny how something that actually works is called "legacy" now. Crapshoot has never been anything other than snakeoil and hype to sell shitty hardware. Don't fall into the hype.

On Mon, Feb 15, 2016 at 6:39 PM, Tony Wall notifications@github.com wrote:

Any progress on this? Some ESCs with BLHeli firmware are shipping with OneShot enabled and PWM disabled by default! It seems like we missed the boat, now APM looks like it's got compatability issues. For anyone wishing to correct this you need to enable the PWM output option and disable the PWM dithering option (leave legacy/"high").

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1825#issuecomment-184134166 .

[CodeChief]

Nobody needs to argue if OneShot is an improvement or not. But I do wonder why some people want to resist a natural progression. All the pros agree OneShot makes a big difference.

[trollcop]

Which of the pros, that weren't paid off by vendors pushing garbage do you have in mind when you quote them?

Also, are you going to tell me that changing ESC output pulse width several times per one revolution of the propeller is going to make any f---ing difference? Lol! Most of your "blheli" escs have several pulses worth of LPF in them because otherwise they'd burn even more often than they do now.

This s--t is nothing but vendor spam and snakeoil.

On Mon, Feb 15, 2016 at 6:44 PM, Tony Wall notifications@github.com wrote:

Nobody needs to argue if OneShot is an improvement or not. But I do wonder why some people want to resist a natural progression. All the pros agree OneShot makes a big difference.

[image: 2016-02-15 1] https://cloud.githubusercontent.com/assets/1496225/13044918/f050ea34-d3d0-11e5-9bed-555104ab7603.png

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1825#issuecomment-184135355 .

[rmackay9]

There's definitely some fairly high interest in the dev team for supporting this... maybe for Copter-3.4.

No swearing please.

[jschall]

@trollcop FYI motor rotation frequency makes absolutely no difference to control latency in a multicopter. What matters is how much torque you can apply to the motor and how quickly you can do it. The governing physical time constants on that are extremely tiny - they are purely electrical, based on the inductance of the motor. PWM adds a very significant latency to the system. You absolutely get benefit out of reducing that latency. "OneShot" isn't the end-all of reducing that latency (CAN is) but it is a very significant and useful step forward.

[trollcop]

On Tue, Feb 16, 2016 at 1:29 PM, jschall notifications@github.com wrote:

@trollcop https://github.com/trollcop FYI motor rotation frequency

Please explain me how changing propeller torque several times per single revolution makes any difference.

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1825#issuecomment-184512131 .

[jschall]

Per revolution might seem like an intuitive way to think about this, but it is honestly a bit deceptive. It also doesn't really matter, as latency is an additive effect that is always a good idea to get rid of. Also, tell me what is not advantageous about getting a head start on changing rotor velocity in response to a disturbance? Seriously, the latency introduced by PWM causes phase loss that is a significant chunk of the phase loss introduced by the 2-pole butterworth we use for noise filtering on the gyro - try changing that and seeing the huge effect it has on performance.

[trollcop]

On Tue, Feb 16, 2016 at 1:34 PM, jschall notifications@github.com wrote:

Also, tell me what is not advantageous about getting a head start on changing rotor velocity in response to a disturbance?

The fact that there's absolutely nothing you can do to "respond" to whatever it is during the period of the prop rotating say from 30deg to 270deg. By the time you're done dealing with prop/motor inertia / air resistance, your 125us headstart ended long time ago.

That's why the real pros like DJI all switched to c-----t escs, right? /s

—

Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1825#issuecomment-184513851 .

[rmackay9]

@trollcop, no more swearing here please. I'll be deleting any further comments that include vulgarities.

[jschall]

I'm sure DJI uses serial communications with their ESCs on their fully-integrated products. Otherwise, they are using the de-facto standard.

The headstart is also more like 2000-3000us, not 125us.

[rmackay9]

@trollcop, no swearing please. I've deleted that comment. Feel free to post again.. just keep it polite.

[trollcop]

I've deleted that comment. Feel free to post again.. just keep it polite. So which vendor do you work with that sells oneshot hardware?

[CodeChief]

@jschall is clearly more informed than the troll, who picked a very appropriate user name. If anyone looks like they are paid by somebody it's the troll who is trying to block this feature. This feature would not be enabled by default. So if you don't like it, don't use it!

@rmackay9 you are too nice a moderator! The slanderous theories and foul language the troll has been posting here don't help anyone, are totally immature and unprofessional.

APM is being seriously used for smaller agile/racing drones, now that boards like PixFalcon (Naze32 form factor) are readily available, relatively cheap and light. Mini APM based FMUs offer way more possibilities and performance (except for the lack of OneShot) than the competitors. So it's inevitable that new performance/tuning feature requests like this will arise.

The only side effect I can imagine for traditional PWM users would be a generally improved/configurable timing codebase in APM? We're not talking about advanced propeller control (but that is a very good example that mid rotational speed changes do take effect). We're talking about permanent changes, just executed faster and fully in sync with a chosen communication protocol, any popular protocol!

I too would like to see I2C and CAN supported. When the code is implemented it would be smart to keep that in mind; this feature is just the first of two or three variants, sitting on top of some core capabilities like "multi-protocol ESC support" and "motor control loop synchronization".

OneShot is just the first generally available alternative, a good bridge from traditional PWM to some kind of future (most likely) digital protocol. For those with technical doubts they have nothing to worry about (leave default = disabled) and maybe look forward to support for the other protocols later, if their preferred hardware also becomes readily available. If you're blocking this you're potentially blocking the chance of "professional DJI" style serial protocols too!

[rmackay9]

We've doing some work now on the motors library that will go into Copter-3.4. That makes it easier to add different types of output besides regular PWM and I suspect the first new option will be one-shot.

TBH, I don't know if one-shot is actually useful or not but generally the project follows public demand so if people want it and a developer is willing to do the work (I know Leonard is keen) then it tends to happen.

[dk7xe]

@rmackay9 i'm a happy user of KISS ESC on 2 copters running AC ("big" 550 with 30A KISS and small 250 with 18A KISS; 3rd one in preparation). Already the switch from DYS with SimonK to KISS on the big one resulted in better performance ( this is confirmed also by thrust and power measurements i have seen on local forums using same motor/prop and comparing KISS with other ESC). What is told by others i personally know using KISS/oneshot with e.g betaflight is that the switch to oneshot really made the difference in responsiveness and control on the copter.

I was also thinking into the direction of using I2C/CAN ESC's myself. But looking at the price KISS is still the preferred choice for me at the moment. Even for bigger copters.

So why not getting the best out of it by having oneshot available. BTW: i'm following Leonards thread on diydrones therefore i know that he is working on the basis to make that happen in future.

Since i'm not payed by any of this manufacturers and only can tell what my personal experience is with KISS i hope that you count me as "public demand" voice ;-)

Cheers, Gerald

[trollcop]

oneshot really made the difference in responsiveness and control on the copter.

because one day someone will actually post something that makes sense, like comparing same esc with complementary PWM (that's active light something crap or other in blowheli) enabled in both and with vendorshot and normal PWM and observing absolutely no difference.

[borisbstyle]

@dongie peabody123 posted it like months ago.

Why not just closing this issue and never implement it? I mean it is like 1 year ago since this issue started.

For those who want to use it just look to other open source projects out there in case you want to use it. Op 16 feb. 2016 13:23 schreef "dongie" notifications@github.com:

oneshot really made the difference in responsiveness and control on the copter.

because one day someone will actually post something that makes sense, like comparing same esc with complementary PWM (that's active light something crap or other in blowheli) enabled in both and with vendorshot and normal PWM and observing absolutely no difference.

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1825#issuecomment-184662005 .

[trollcop]

Hello borisbcodecopypaster, I would expect you to reply exactly this. Maybe next time you feel like innovating something you'll actually write it yourself instead of begging others for code, taking from other projects without understanding, or just generally being hopeless.

Good job on trying to plug your stuff here, you did almost good just forgot to mention the name.

On Tue, Feb 16, 2016 at 9:34 PM, borisbstyle notifications@github.com wrote:

@dongie peabody123 posted it like months ago.

Why not just closing this issue and never implement it? I mean it is like 1 year ago since this issue started.

For those who want to use it just look to other open source projects out there in case you want to use it. Op 16 feb. 2016 13:23 schreef "dongie" notifications@github.com:

oneshot really made the difference in responsiveness and control on the copter.

because one day someone will actually post something that makes sense, like comparing same esc with complementary PWM (that's active light something crap or other in blowheli) enabled in both and with vendorshot and normal PWM and observing absolutely no difference.

— Reply to this email directly or view it on GitHub < https://github.com/diydrones/ardupilot/issues/1825#issuecomment-184662005> .

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1825#issuecomment-184665191 .

[borisbstyle]

What did i copy paste? Link the part of code for that please... Op 16 feb. 2016 13:36 schreef "dongie" notifications@github.com:

Hello borisbcodecopypaster, I would expect you to reply exactly this. Maybe next time you feel like innovating something you'll actually write it yourself instead of begging others for code, taking from other projects without understanding, or just generally being hopeless.

Good job on trying to plug your stuff here, you did almost good just forgot to mention the name.

On Tue, Feb 16, 2016 at 9:34 PM, borisbstyle notifications@github.com wrote:

@dongie peabody123 posted it like months ago.

Why not just closing this issue and never implement it? I mean it is like 1 year ago since this issue started.

For those who want to use it just look to other open source projects out there in case you want to use it. Op 16 feb. 2016 13:23 schreef "dongie" notifications@github.com:

oneshot really made the difference in responsiveness and control on the copter.

because one day someone will actually post something that makes sense, like comparing same esc with complementary PWM (that's active light something crap or other in blowheli) enabled in both and with vendorshot and normal PWM and observing absolutely no difference.

— Reply to this email directly or view it on GitHub <

https://github.com/diydrones/ardupilot/issues/1825#issuecomment-184662005>

.

— Reply to this email directly or view it on GitHub < https://github.com/diydrones/ardupilot/issues/1825#issuecomment-184665191> .

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1825#issuecomment-184665597 .

[peabody124]

Yeah you can see here: http://buildandcrash.blogspot.com/2015/01/oneshot125-quantitative-testing.html Exact same ESCs and motors but tested with either traditional PWM or OneShot. The amount of latency improvement is on the order of what you'd expect with the communication improvements.

Also keep in mind, motors generate thrust continuously - not magically storing it up until they complete a cycle and releasing it - so you have sufficient torque to hit a new velocity in 1/4 of a cycle that will change the thrust at that time scale.

My old work with closed loop ESCs http://buildandcrash.blogspot.com/2011/11/esc-development.html showed that you could definitely get the control bandwidth into 35Hz (and there have been a lot of improvements since then) and that was with big 8" blades, so really the empirical data is in... also the user reports are.

[R-Lefebvre]

But that data proves nothing. Of course the latency is reduced in line with the signal timing reduction. That's just obvious. It's a red herring.

But what is being questioned, and NOBODY has been able to actually show this, is what is the ACTUAL flight improvement, assuming NO OTHER changes (such as turning on active braking or Active Freewheeling) at the same time as you implement this change to signal frequency.

What is the control frequency of the copter on PWM? What is the actual control frequency of the copter on OneShot? Nobody has this data, and with the amount of work that has been done trying to prove this issue in every other way other than the single, simple method that would prove this once and for all, I have to believe that it's because somebody got the data and it doesn't show what they want so they are sitting on it.

I do think we should implement OneShot. If only because the users want it, and they have been convinced it is necessary.

But this is a slippery slope, because we're already seeing some flight control systems pushing up towards 10,000Hz updates which is just getting stupid. This is the FPV Racer equivalent of the Megapixel wars, where everybody is walking around with a 20MP camera in their pocket because they've been told it matters, but they also have a crappy lens, poor light performance, and wide depth of focus because it's a veritable pinhole camera. (Oh, but there's an App for that now).

I don't care about "user reports". As an automotive engineer, I'm all too familiar with the placebo effect and confirmation bias.

[peabody124]

@R-Lefebvre if you analyze the control bandwidth of a multi rotor, the motor latency is the performance limiting factor. In fact if you look at @TauLabs auto-tuning algorithm that is the main parameter that goes into it and sets the PIDs (and ultimately control bandwidth).

https://github.com/TauLabs/TauLabs/blob/next/flight/Doc/Autotuning%20Derivation.pdf

So I guess I'm confused. Are you disagreeing that improving motor response latency is good, or that a general race for arbitrary statistics is bad?

[Georacer]

I'd say that the term latency in that pdf is somewhat misused. tau is a time constant, which depicts the transient response of the motor shaft, until it reaches the final rotation veloticy. A communication delay is not actually modeled in that document, which in the Laplace domain should appear as an exponential term ( exp(-s

On 19/02/2016 03:48 μμ, peabody124 wrote:

@R-Lefebvre https://github.com/R-Lefebvre if you analyze the control bandwidth of a multi rotor, the motor latency is the performance limiting factor. In fact if you look at @TauLabs https://github.com/TauLabs auto-tuning algorithm that is the main parameter that goes into it and sets the PIDs (and ultimately control bandwidth).

https://github.com/TauLabs/TauLabs/blob/next/flight/Doc/Autotuning%20Derivation.pdf

So I guess I'm confused. Are you disagreeing that improving motor response latency is good, or that a general race for arbitrary statistics is bad?

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1825#issuecomment-186220344.

[R-Lefebvre]

Peabody, of course motor/prop inertia is the performance limiting factor. That's exactly what I'm saying. You are conflating physical response rate of the system, with signalling frequency and frame-length.

These are two separate things. As I've said many times, reducing the signal frequency and frame-length to reduce total signal latency just makes sense. But I don't believe it's the nearly as large of a factor as it's being made out to be.

There's no question that lining up the start of the signal pulse with the finish of the rate loop calculation just makes imminent sense. And there is probably some improvement on SMALL quadcopters, to push up to 1000Hz signaling.

But I would really prefer to see a real digital signal method rather than just a shortened time-analog signal method (which is what Oneshot125 is).

My fear is that we enter this signal timing race. We're already seeing that with some people talking about 10,000Hz signalling.

If you had data that showed the change from 2mS PWM to 125uS PWM and increasing signal timing from 400Hz to 1000Hz, reduced the overall system response time 10% (with the other 90% being phsyical motor response) I'd be happy with that. But we don't have that number, because everybody is talking around the issue.

[borisbstyle]

@R-Lefebvre 10% is a fact in that example. Also remember that @peabody124 was testing on a larger prop/disc, which generally would react slower. On a smaller lighter props a difference of 10% is even much more noticaeble.

I do agree with you that going higher than just 1-2khz would not improve performance as much as 2ms ->0,25ms would do. But this discussion is about normal PWM vs oneshot125.

[peabody124]

@Georacer you are absolutely right. However, modeling a system delay like that isn't amenable to analytic solutions and I'm fairly confident the approximation isn't resulting in significant deviations.

@R-Lefebvre yep, I agree the 1-2ms improvement is going to be most observable on small quadcopter. If you look at the link I posted earlier it's testing on exactly that type of system and showing about a 20% improvement in fact

I completely agree people were talking around the issue, which is why I did the experiments ;-)

Also, I agree in digital signaling which is why all my boards have had CAN for 3 years and so does the most recent version of my ESC https://oshpark.com/shared_projects/wwEK9WDT

Other than that, nonsense is still nonsense and needs empiric testing. I'm entirely in agreement. Just in the case we have that testing, at a certain point data is data :).

[R-Lefebvre]

Also interesting in that PDF, that you mention you are using 20Hz LPF on the Gyro signal to eliminate noise. This is the exact same frequency that we use by default.

As I have said many times, this is close to what I believe the real overall response rate of the copter is anyway. Everything above that is just noise. The period of 20Hz is 50mS. So a total system signal latency of say, 3mS, is significant. This is why I believe that 1000Hz with a shorter frame-length may show some improvement. But 10,000Hz is just getting ridiculous.

And finally, again, my fear is that the simple focus on signal timing, ignores all of the other things that we do so much better than the race controllers, which actually benefits the users in a real way. ie: angle-lock on the rate inputs, such that errors are corrected by the system instead of the pilot. Linearizing thrust output according to both voltage and throttle%, etc.

Arducopter may be outputting signals slower, but it's outputting more carefully calculated signals. It's more pre-actionary, so it doesn't have to be re-actionary.

The angle-lock on the rate inputs alone, is a MASSIVE improvement that real pilots, especially novices, will actually benefit from.

[magicrub]

@Rob You're talking to a target audience where most controllers use gyro-only for navigation. We are fundamentally different in flight design and scope than most 250 class quad controllers. However, in order to compete in that market we have to check off this silly feature. I know you're on board with it, you've said so many times. Just keep in mind that the target use is tiny quads, not the big stuff you're used to.

On Fri, Feb 19, 2016 at 6:35 AM, Robert Lefebvre notifications@github.com wrote:

Also interesting in that PDF, that you mention you are using 20Hz LPF on the Gyro signal to eliminate noise. This is the exact same frequency that we use by default.

As I have said many times, this is close to what I believe the real overall response rate of the copter is anyway. Everything above that is just noise. The period of 20Hz is 50mS. So a total system signal latency of say, 3mS, is significant. This is why I believe that 1000Hz with a shorter frame-length may show some improvement. But 10,000Hz is just getting ridiculous.

And finally, again, my fear is that the simple focus on signal timing, ignores all of the other things that we do so much better than the race controllers, which actually benefits the users in a real way. ie: angle-lock on the rate inputs, such that errors are corrected by the system instead of the pilot. Linearizing thrust output according to both voltage and throttle%, etc.

Arducopter may be outputting signals slower, but it's outputting more carefully calculated signals. It's more pre-actionary, so it doesn't have to be re-actionary.

The angle-lock on the rate inputs alone, is a MASSIVE improvement that real pilots, especially novices, will actually benefit from.

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1825#issuecomment-186238204 .

[peabody124]

Actually with the tuning we adjust the frequency based on how fast the system responds. Noise is the predominant limiting factor on that bandwidth. There is a separate filter on the derivative and the general filter for the P and I components, the latter being a bit faster. I'm also definitely not endorsing a 10khz update rate as the 100us is definitely buried in the motor response.

Also keep in mind for nested PID loops (e.g. a rate and then angle controller) each layer eats bandwidth so you want the inner loop as fast as possible.

Also agreed about linearizing responses. We have a motor output curve that is meant to attempt that which CyPhy found necessary for their systems based on TL. With regards to signal shaping that's a really tough question IMO because you are trying to make the system respond the way a human thinks it should, and suddenly you aren't in pure control theory anymore. That's why things like PID damping for stick movement seems to be popular, even though it is nonsense from a controls perspective. Somehow it makes the system behave more intuitively if not as well defined mathematically.

Finally I'm not sure there are many carefully calculated responses that on a modern MCU are going to actually take meaningful time to calculate. Of course for navigation accounting for things like GPS latency will improve an INS response but that should be appropriately decoupled from the attitude control and those latencies shouldn't be waited for compute a new angle or your overall performance will definitely degrade.

@magicrub agreed - spinning 10" blades 2ms is going to be irrelevant.

[R-Lefebvre]

Tom, I have a 250 racer too. And helicopters, which have the exact same arguments.

Peabody, my approach to FPV Racing is exactly the same as it is for cars. "Handling" matters far more than any technical superiority. 99% of users are incapable of extracting all of the performance out of a given system. Ease of use and predictability are far more important than any other performance measure, because it allows them to get closer to extracting 100% out of whatever system they have, which is always faster than getting 80% out of a system with 10% higher performance.

That's why I can crush Corvettes, Porsche and even Ferrari, in a Ford Focus. :)

https://www.youtube.com/watch?v=GQsOpcbV5yY

[peabody124]

Agreed. Hence why I wrote autotuning that identifies the performance limiting factor (latench) and tunes against it. The racers at least report that it works really well and reproducibly. I have to trust them since I can't fly that well and focus on the engineering.

[goodwin]

Any news on that?

[OXINARF]

http://discuss.ardupilot.org/t/oneshot-support-is-in-master/8465

There's still an issue with OneShot125, you can find more info in the last pages of http://diydrones.com/forum/topics/pixracer-with-ardupilot

[rmackay9]

This is in master now and users are reporting that it's working so closing.