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 :)

[R-Lefebvre]

In my opinion, this is a lot of complexity for little to no benefit. There is no evidence to suggest that this will actually improve performance. Other than the wive's tale that 400+ Hz updates are necessary. This is not supported by any evidence. Meanwhile it is quite a bit more complicated, and possibly subject to some risk of error.

[laurienzu]

If all esc manufacturers and firmware makers are moving in this direction, there is a reason ... Maybe the advantages are really visible in acro but Arducopter is a complete code and this feature can not miss! To prevent error is possible to add a parameter to turn it off or turn it on at will :)

[R-Lefebvre]

Manufacturers do things that don't make good engineering sense all the time. It's called marketing. And users report that it makes a difference all the time, it's called placebo. Neither has ever provided conclusive evidence.

A few years ago they were advertising update rates of 800Hz, even though this is physically impossible. If the manufacturers really wanted to increase the response rate of the systems, they should dump PWM which is antiquated, and go with a modern truly digital communication that can easily be updated at 1000Hz. This has already been done by others (though they also failed to demonstrate an actual performance difference).

Given the fact that we filter the gyro data with a 20Hz LPF, I really don't see how an ESC signal getting out 1ms faster is going to make any difference at all. Seriously, typically the propellers are rotating at 6000 rpm, which is 100Hz, which means 10ms per rotation. Do you really think that applying extra motor torque 36° of blade rotation earlier, is going to make any difference at all?

Contrary to popular belief, the control bandwidth of a typical copter is only about 50Hz max. Anything above that is just noise. That's why we filter at 20Hz. There is just no need to increase the speed of the ESC updates beyond 400Hz.

I think the ESC manufacturers should instead concentrate on preventing sync loss, rather than this signal speed stuff. It's no coincidence that sync loss is caused largely by passing large, unconstrained throttle changes too fast. Yet they want to make that problem that much worse.

[R-Lefebvre]

Ok, to try to put this more succinctly: If you can provide any evidence that this actually improves flight performance, then it would probably be acted upon. And the evidence should be scientific, not a link to a Youtube flight with some awesome Warthox flying, where we have no ability to determine if it actually made a difference or not.

Without evidence, I don't think we are likely to act on this issue.

[sim-]

Most of the test videos I've seen are comparing between KISS ESCs with complementary PWM enabled to others without. I think this is causing most of the confusion, just like per-update low pass filtering on OEM Hobbywing ESCs probably caused most of the update rate confusion.

I was thinking of adding support for this not because I suspect it to produce any significant improvement, but so that people can test it one way or the other. It sounds like I should just alias input at 1/8th the lengths, but still not entirely happy about introducing yet another input range that would still require some form of calibration or ESC-specific setpoints even with reasonably-aligned oscillators.

Similar discussion on taulabs: https://github.com/TauLabs/TauLabs/pull/1424

[R-Lefebvre]

Good to see you here Simon. Just to clarify two of your statements:

What exactly do you mean by complimentary PWM, is that this "oneshot"? Are you stating that the simple "it feels better" testing is actually comparing different ESC's with completely different firmware, and not simply testing this one change with all else being equal?

And the LPF on the OEM HW ESC's. Are you stating that the idea that 400Hz is beneficial because the HW ESC's filtered 8 PWM samples, rather than a time-based filter, thus pushing faster rates got the changes through the filter faster, and NOT that 400Hz in and of itself improved responsiveness?

[trollcop]

Are you stating that the simple "it feels better" testing is actually comparing different ESC's with completely different firmware, and not simply testing this one change with all else being equal?

Correct. It's kissesc/oneshot marketing machine - no real evidence, just "if I use hardware X, its better than when I use hardware Y, never mind that settings aren't even close to being same".

And the LPF on the OEM HW ESC's. Are you stating that the idea that 400Hz is beneficial because the HW ESC's filtered 8 PWM samples, rather than a time-based filter, thus pushing faster rates got the changes through the filter faster, and NOT that 400Hz in and of itself improved responsiveness?

That's basically what they were doing, yes. So updating at 50Hz made them slow, but by pushing updates faster, the ESC would reach the setpoint sooner. With ESC that immediately responds to input without lowpass, update rate can be less.

[rmackay9]

In the early versions of arducopter we actually used something that at least sounds similar called "fast pwm". it would send out the pwm signal at the moment the controllers finished all their calculations instead of at a fixed interval. We found that it didn't make any perceptible difference to the flight quality so we removed it because it added complexity to the code. At the time we guessed that it didn't make any difference because the filter on most ESCs introduces a far larger delay than the few milliseconds of delay between when the controller finishes and the pwm outputter pushes them to the ESC. To improve performance we found the most important thing was to just to send a lot of PWM signals (i.e. at a high rate) to force them through the ESCs internal filter. I.e. sending pwm outputs at 400hz (even if the controller was only updating at only 100hz) performed better than using fast-pwm to send outputs immediately after the controller finished.

[sim-]

Complementary PWM is what I've called the output PWM method rather than anything to do with the input signalling to the ESC. This is where rather than driving one phase one way and pulsing another phase the other way (the traditional trapezoidal drive method for 3-phase BLDC motors), we also turn on the complementary FET on the PWM'd phase when in the "off" state. This has the effect of forcing the average voltage closer to the PWM target, which has the effect of causing regeneration immediately when the back-EMF is higher than this voltage, which causes deceleration roughly symmetrically with acceleration. With the traditional driving method, the circuit is typically open rather than conducting (other than current-collapse through FET body diodes and some corner cases) when PWM is off, but with this method, the two-phase voltage averages to Vbatt * PWM_duty.

In short, KISS ESCs I think are shipping with this on by default, but most others (other than TBS) are not, in many cases, people are probably completely unaware of this feature (oops), resulting in comparisons that people are attributing to shorter PWM pulses or synchronous-to-FC-mainloop PWM ("oneshot") rather than this fundamental driving difference. BLHeli also supports complementary PWM, labelled as "damped" mode. It's fairly easy to see, feel, and measure the difference with just this turned on or off.

Higher update rates are definitely more beneficial on OEM HW ESCs because of the update-based filter, but certainly there will be some diminishing returns also for unfiltered ESCs from faster rates and lower overall latency -- they're just going to be smaller. Swamping the ESC with interrupts isn't really a problem until the rate is much faster (contrary to what you suggested above about it being responsible causing sync loss). The worst case for sync loss is still the case that causes the most current -- an unfiltered, unlimited jump from low power to maximum power (causing the highest current spike), which can be initiated by a single pulse, but any sync loss issue is certainly still a bug, of course. :)

[R-Lefebvre]

Sounds like we're all in agreement. The OneShot thing isn't worth the effort.

Simon, I wasn't suggesting high update rates are the cause of sync loss, due to interrupt rates. I was suggesting that passing large, unfiltered changes to the ESC, which results in large current spikes were the cause. HW filtered ESC's avoid this, since the input is filtered. Somewhere between here and there, we have the right solution.

Since we have your attention, I have thought about putting a slew-limiter on the ESC output. Would this help avoid sync loss, or is this just better managed in the ESC firmware anyway?

[sim-]

If the ESC loses sync at all, I consider that a software issue. It's probably best to first exhaust all possible options to try to not lose sync at the ESC, but if the only thing left is a low-pass filter, it's probably better done at the flight controller. There are a number of other things that the flight controller might want to consider at different priority, and it would be better to accumulating error before it is clipped by the output range.

I think most of the sync problems are already solved, but there are many factories shipping ESCs with random old versions that they found in 2012, and there is a lot of confusion here. It might make sense to change something (like start-up beeps) so that it is obvious that a particular milestone has passed, or something.

I'm curious of the particular case that prompted you to think about the slew-rate limiter. Is there a thread for this?

[kangsterizer]

Interestingly there are videos poping up of people testing oneshot on cleanflight and they report being able to fly at much higher rate P values when it's enabled (compared to "damped mode")- which makes it seem like it works and not just placebo. Here's one for example https://www.youtube.com/watch?v=DxUFY5k1aZs

[borisbstyle]

@R-Lefebvre oneshot125 is really easy to implement and not something trivial like you are saying. It is basically dividing the regular PWM output by 8, which makes it possible to send as soon as possible. Don't be mislead by this higher refresh rate. It is more the matter of making your system synchronious, what seems to affect the PID tuning in a positive way. You don't need to go higher than 500-600hz with the refresh rate.

By the way wiiesc is also able to do oneshot125, which works fine on atmel based ESC's like blue series / ZTW and F20 or F30.

[borisbstyle]

For those who like to try something innovative. Install cleanflight and see how this brilliant piece of software does it.

[R-Lefebvre]

Interesting about the firmware age Simon, I wasn't aware of that. I would say that yes, you should make this more obvious to people somehow if it is the case. Currently, I see lots of people thinking that "SimonK" is the source of the problem and moving away from it. I didn't even realize you had made significant improvements here.

[R-Lefebvre]

Boris, this is not really a good venue to discuss Cleanflight.

The video posted really reinforces my point. That is not data. There are many things which could cause that difference. Even battery voltage. If the first half is done with a half-depleted battery, and it's freshly charged on the second half, and tightly tuned, that will happen. There's simply too much we don't know.

Again, I'm not saying this change is ineffective. I'd just like to see some hard data, not anecdotal videos. Somebody must be able to produce a Bode plot?

[kangsterizer]

@R-Lefebvre I suspect one could record a "blackbox" with/without. I understand your suspicions - I have similar ones - that said if the changes are more than anecdotal its generally easy to judge just by flying the same quad. Of course one could always argue about wind, etc. It's hard to make these test in a fully controlled environment. If the changes are in fact anecdotal (lets say it improves motor response by 3% or whatever) then the change itself isn't all that important anyway ;-)

As for the blackbox recording (which is a cleanflight feature basically plotting various sensor data, stick input, etc of a flight, similarly to arducopter logs) - I don't have the necessary hardware but hopefully someone will run that :) (if you read this, want oneshot, and have the proper hardware, please ..!)

[borisbstyle]

So you think that video is based on 1 single test? That was basically reproducable each time and the actual request to make that vid was coming from me as there was some collobaration going on a while ago on rcgroups about this. There is also some evidence in certain rcgroups topics where enabling oneshot on the exact same pids/settings was showing faster recovery in drastic movements like flips and rolls. The data I am talking is basically gyro output. There is also some information in the main post here: http://www.rcgroups.com/forums/showthread.php?t=2305535

You probably won't notice much when hovering and normal flying, but it just seemed that the usable PID range changes after enabling or disabling oneshot increased on these particular setups (with KISS esc's).

[R-Lefebvre]

The reason I am so skeptical is the simple fact that we use a 20Hz LPF on the gyro data. We have found that any signal above that is just noise. Even in that video, that very light, powerful and responsive quad is oscillating at about 20 Hz. Why would a change in the ~400Hz frequency domain, result in a 20Hz oscillation?

And if this really matters, why not skip the PWM altogether, and do synchronous signalling using a high-speed digital method, such as I2C or CAN? Then you wouldn't even have to wait 1.5 mS for the pulse to finish being signaled, and instead would be in the uS timescale. That would improve response even further.

[borisbstyle]

I don't think that LPF filter has anything to do with this. In this case he was using a 42hz LPF filter, which is default in this particular FC software. It also may not be suitable for your particular application of course. It is proven that in all electrical and mechanical systems a perfect synchronisations always gives most reliable results. In this case every time the programme does a full cycle it is immediately able to send the ESC command, while in traditional "fixed" pwm timing it would have to wait another cycle to be able to send it. There are some FC's having this feature to adapt the looptime to PWM speed, but it's never really the same. In this case you can have more dynamical PWM refresh rate. Send the command whenever you are ready to send it as the old one is already processed long time before probably.

Digital servo would be great, cause you could introduce things like error corrections, but that would make things more complex probably. Oneshot125 is a very easy and achivable fix on the current technolgies to get more out of your system.

[emilecastelnuovo]

Robert I agree that what makes something famous is not always really good. But talking about ESC I can, as many others do, assure that performance is much better with SimonK than with old stock firmware. And this was mainly achieved by removing software filter that lagged the control signal. So getting back to oneshot pwm there is no reason that removing another lag could make things worse. There is very little chance that anybody can or will prove scientific evidence that some changes in hardware or software makes a bird fly better or worse. It all about personal judge and feeling. And then even with scientific evidence there will alway somebody arguing that. This happens every day in all scientific world.

But when this feeling is confirmed by many different users, well, that's probably a good evidence that things are going in the right direction.

The fact that we are using 20Hz LPF does not mean that without it would fly worse. It just means it will be more susceptible to noise. Having a perfectly well isolated IMU would probably let you raise the filter to a higher value, and I can assure you the feeling is totally different.

When you speak about lag of the propellers I think you are perfectly right, but this lag is not independent to the rest of that system, it is just another lag to ADD to the system.

I think borisbstyle is right affirming that synchronization (so removing all possible lags) will give the most reliable result.

Still I this is an interesting feature that could be tested in near future.

Emile

On 29 January 2015 at 15:36, borisbstyle notifications@github.com wrote:

I don't think that LPF filter has anything to do with this. In this case he was using a 42hz LPF filter, which is default in this particular FC software. It also may not be suitable for your particular application of course. It is proven that in all electrical and mechanical systems a perfect synchronisations always gives most reliable results. In this case every time the programme does a full cycle it is immediately able to send the ESC command, while in traditional "fixed" pwm timing it would have to wait another cycle to be able to send it. There are some FC's having this feature to adapt the looptime to PWM speed, but it's never really the same. In this case you can have more dynamical PWM refresh rate. Send the command whenever you are ready to send it as the old one is already processed long time before probably.

Digital servo would be great, cause you could introduce things like error corrections, but that would make things more complex probably. Oneshot125 is a very easy and achivable fix on the current technolgies to get more out of your system.

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

[rs2k]

The evidence is pretty plain. You can run higher PIDs with OneShot125 enabled than without OneShot125 without experiencing oscillations. Ask any pilot who's taken the time to tune their machines with and without OneShot125 active and they'll tell you how much of a difference that higher PIDs make. I look forward to seeing this in Ardupilot. :)

[robustini]

Reading your discussion I remember long tim ago when i start using SimonK with Arducopter, initially many developer were all a little hesitant, but now that has become a standard ESC firmware for better performance, with BLHeli. We try to always analyze the news, could become the standard for the future. My two cents...

[laurienzu]

Wow guys, I did not think that my proposal would have been so commented ... Everyone has their own reasons for saying that it is an acceptable proposal or not but fortunately many competent people are commenting to give their point of view. I do not think this is just a commercial gimmick or a placebo because several pilots have noted tangible differences with the same hardware simply switching between Oneshot or not and RCgroups is proof, as I have often repeated are perhaps most noticeable in Acro flights but every little part is always something good. We are fortunate to have rs2k and Simon Kirby here to comment, who better than they and you developers can help to understand whether it is an interesting feature and how to add it safely?

[strips]

I see both sides here but have also experienced less oscillations on my 250 and being able to have higher P. Shaving off delay should make the FC counter an unwanted movement at an earlier stage. I agree a digital comm would be preferable but this is what we got now.

And when did synchronous logic get more complex? It should make stuff simpler.

I would very much like to test oneshot125 on arducopter!

[crncecivica]

Synchronous logic is not complex, but you need one more wire which carries clock. This leads to modifications on existing ESCs.

[peabody124]

@R-Lefebvre if you want evidence I did some analysis with OneShot using Tau Labs system identification to measure the latency from changing output to the gyro: http://buildandcrash.blogspot.com/2015/01/oneshot125-quantitative-testing.html

The TL;DR is that it does result in 10-20% improvement in ESC latency.

[CodeChief]

@peabody124 sounds like the guys at TauLabs have finished their first version: https://github.com/TauLabs/TauLabs/pull/1424#issuecomment-72355414

In the spirit of Open Source anyone can go ahead and branch the code then retro-fit the stuff from TauLabs I suppose. But really you need a developers who fully understands ESC control and the LPF limit being discussed here.

On the subject of increasing ESC command speed, I was a bit disappointed to find virtually no documentation about I2C control which if it is supposed to be the ultimate solution to PWM I'd like to use. For example I've got some Afto 20A Slim ESCs from Hobby King with I2C headers on the board, but I'm not messing around with the hardware and soldering until I see clear support in the Pixhawk tools, preferably in the ArduPilot stack. I expected to find at least a blog with wiring diagrams and parameter settings, but nothing. Maybe OneShot125 is the only option?

[badzz]

@codechief: peabody124 is one of the main dev of taulabs.

On Sun, 1 Feb 2015 12:36 CodeChief notifications@github.com wrote:

@peabody124 https://github.com/peabody124 sounds like the guys at TauLabs have finished their first version: TauLabs/TauLabs#1424 (comment) https://github.com/TauLabs/TauLabs/pull/1424#issuecomment-72355414

In the spirit of Open Source anyone can go ahead and branch the code then retro-fit the stuff from TauLabs I suppose. But really you need a developers who fully understands ESC control and the LPF limit being discussed here.

On the subject of increasing ESC command speed, I was a bit disappointed to find virtually no documentation about I2C control which if it is supposed to be the ultimate solution to PWM I'd like to use. For example I've got some Afto 20A Slim ESCs from Hobby King with I2C headers on the board, but I'm not messing around with the hardware and soldering until I see clear support in the Pixhawk tools, preferably in the ArduPilot stack. I expected to find at least a blog with wiring diagrams and parameter settings, but nothing. Maybe OneShot125 is the only option?

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

[CodeChief]

@badzz oh cool.

@R-Lefebvre besides the obvious firmware/app changes, how about a new ESC configuration section in the GUI? e.g. select connection type PWM-Servo, PWM-OneShot125, I2C or UAVCAN. Plus the RC_SPEED parameter integrated along with anything else which helps solve sync issues.

[R-Lefebvre]

Do the KISS ESC's still suffer from loss-of-sync problems?

[borisbstyle]

@R-Lefebvre What sync issues? As far as I know the KISS ESC's seem to be able to perform better than any other ESC's on very high RPM's.

[R-Lefebvre]

I don't know that it does, but I happened to see this:

http://www.rcgroups.com/forums/showpost.php?p=30666575&postcount=20299

[CodeChief]

Yesterday I learnt the ESC update speed is critical. I had one motor dropping out (like it stops for a split second and the copter dips down a few centimetres towards that side). I replaced the ESC, then tried re-flashing but no improvement. Finally replaced the motor then was okay and I thought nothing of it... Until the next motor started dropping-out then got worse followed by a crash because it dropped-out so long it flipped over. Luckily this was a "bed test" so nothing broken.

After thinking about this thread which I happened to be commenting on recently, I though it could be something to do with RC_SPEED. Further searches confirmed many others with Afro ESCs having trouble with Pixhawk and a general response from various vendors claiming it is the fault of Afro (or Pixhawk depending on which way you look at it) running at 1KHz,

So I played with the RC_SPEED values and to my surprise found the perfect value, and my "broken" motor actually works fine. Perhaps they were just more sensitive/not so well built as the others but actually run fine with a solid signal.

So the ESC speed is 1000Hz, The test results were:

RC_SPEED = 50 = No motor drop-outs but "skitty behaviour" (1/20th ESC speed). RC_SPEED = 100 = Still a bit skitty (1/10th ESC speed). RC_SPEED = 150 = Drop-outs worse (misaligned with ESC speed). RC_SPEED = 200 = Smoother but occasional drop-out (1/5th ESC speed). RC_SPEED = 250 = Perfect, rock solid, responds well (1/4 ESC speed). And of course the default RC_SPEED is completely misaligned with the ESC speed.

Could it be that the RC_SPEED must be the maximum number which is evenly divisible by the hardware ESC speed? Shame the PWM max does not go-up a bit higher to 500 then, if this is true. Could this be why some people say dismissively that Afro ESCs don't go together with PixHawk?

So coming back to the core point of this thread... support for faster ESC update technology... Yes I personally now have experience that this is an extremely good thing! I2C should be perfect for Afro ESCs because many are I2C ready and the update speed with that enabled (read somewhere it was about 1000Hz) matches the 1KHz of the ESC exactly.

Maybe that's the reason they have trouble, maybe they are internally pure I2C based with PWM converters. For example looking at the KISS "UltraESC" (the brand name of the KISS ESCs at the Flyduino site) they appear to be primarily I2C based with PWM output conversion for backwards compatibility.

I will do more testing and try to re-create the problem, at least to make sure my quad will not crash from greater heights after winter is finally over. If/when it is confirmed I'll try to capture video and logs at the same time for you. I looked through some bits of logs I had from the tests and could see a constant RC input and servo output for each of the motors, which supports the problem not being internal to the Pixhawk just some kind of timing miss-match with the ESC.

I'm just saying please take this feature request forwards. Maybe later/during development somebody finds the scientific explanation, but there are so many people already claiming benefits it should be enough justification to start playing around with features to harmonize Pixhawk and the native ESC update speed, as fast/close as possible to the native ESC speed.

Again a general GUI configuration page for ESCs of any type seems to make sense as a home for this feature and I2C too. I will experiment with that later, but first I want stable flights with PWM and as a baseline.

[CodeChief]

Here are my results. Positive news (in the end)...

So I got my first flights out the way and learnt a lot more about all this ESC update speed. The RC_SPEED related trouble went away by the one motor eventually failing altogether (so that was only helping out with a sensitive/bad motor = interesting but not the solution).

But then I started to suffer terrible wobble on takeoff and each time I significantly increased the throttle (hovering was rock solid). Exactly like this video (not mine)...

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

I tried lots of different settings, upgraded to APM 2.0.16RC3 and firmware 3.2.1 and almost gave-up assuming it was just bad PID tuning. Finally I found the solution was to do the opposite of what I did before, again prompted by this post (thanks, you all got me thinking on the right track!) to increase the Low Pass Filter above the default 20Hz (tried 42 and 98 both work well) and leave the RC_SPEED at the default/maximum 490Hz. Double-checking confirms it too. I can now reproduce the wobble at will. Setting INS_MPU6K_FILTER back down 20 (or 0 which is default = 20), increasing it to any of the higher values has no wobble at all, just better; a very silky smooth motor control.

By the way this is not vibration of the Pixhawk, I know the RC groups jump to that conclusion a lot. I have a "clean and dirty" (gimbal ball isolated) frame with only a third of the maximum acceptable vibration range (as documented on the new ArduCopter site). Furthermore it cannot be that because the fix is the opposite of what you might do to workaround vibration, to increase sensitivity not decrease it.

So there you go, more hints towards (at least in the current firmware) ESC update speed related stuff being critical. I'll leave it at that here because this is really about the OneShot support. I just feel this is related because the stuff you talked about here for OneShot (namely the LPF and update speeds) was exactly a major problem with my 1000Hz native Afro ESCs. I bet your fix/refactoring for OneShot would also sort that out.

[peabody124]

@CodeChief yeah in my experience (different code base but same sensors) you want to keep the hardware filtering to a minimal to keep latencies as low as possible. In some places the software has to apply a bit of filtering but it will be different in different places (e.g. different amounts of filtering from the derivative component versus proportional). The MPU6000 datasheet shjows that a 20 Hz filter adds 8.3 ms which is a big deal once you have fast ESCs. Just like squeezing out that extra couple of milliseconds is important with OneShot.

[lthall]

Anything that reduces latency and jitter on a copter will improve the stability of any copter (especially small ones). One Shot does both and I think it will be here to stay.

I would love to see this incorporated into the code.

[rgury]

Still waiting to see this incorporated, this is stopping me from using Arducopter on my bigger 400. Would love to use a pixhawk for 'agile' long range fpv.

[trollcop]

Placebo effect is strong with this one, huh. Why don't you just buy a phantom3 and agile your way into Return to China

[rmackay9]

I think it'll get done eventually but it's not in yet. It's just about time and priority though.

[jschall]

Why though? UAVCAN ESCs will have less latency anyway and the difference in latency is almost negligible. On May 10, 2015 5:36 PM, "Randy Mackay" notifications@github.com wrote:

I think it'll get done eventually but it's not in yet. It's just about time and priority though.

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

[JoshWelsh]

@jschall OneShot ESCs are here NOW and are extremely popular in the FPV/Racing arena; UAVCAN escs have absolutely NO market penetration. Most of the other flight controllers are supporting this now, it would be nice to get it in to Copter. If I had the know-how I would LOVE to contribute on this one as it will be a "popular" addition, but, I think there are changes required in quite a few places in order to start supporting. I'll keep waiting patiently but frankly don't think OneShot vs UAVCAN is a valid argument today considering the ESCs available on the market.

[jschall]

Uhh, yeah, I think we need a moderator over here. Anyway, development effort can be better spent making a superior interface a reality or making other enhancements. Oneshot does not fare well in a cost-benefit analysis, to my mind. We can do so much better by spending our time on e.g. a quaternion attitude controller that takes the shortest path between two attitudes/doesn't apply controller gains and accel limits to the wrong axes/doesn't apply a rectangular acceleration limit to a vehicle with a diamond-shaped torque response/etc. On May 10, 2015 10:10 PM, "JoshWelsh" notifications@github.com wrote:

Um.. wow?

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

[lthall]

I personally think oneshot support is an important step forward that I would really like to see done. ( +1 Josh but CAN ESC's have much more to offer)

Unfortunately we have not received any commits from anybody so it will have to wait until it gets to the top of the dev's list of things to do. I am trying to push it into the release with CAN esc's.

Ryan, I would go with another esc or flight controller because one shot isn't going into the next release.

I am pretty sure this feature request already exists. If so this one should be closed.

It is also worth pointing out that the same dev's that would be needed to implement this are also the ones that have to clean up these feature requests. Time wasted here slows progress on the very features being repeatedly requested.

On Mon, May 11, 2015 at 2:52 PM, jschall notifications@github.com wrote:

Uhh, yeah, I think we need a moderator over here. Anyway, development effort can be better spent making a superior interface a reality or making other enhancements. Oneshot does not fare well in a cost-benefit analysis, to my mind. We can do so much better by spending our time on e.g. a quaternion attitude controller that takes the shortest path between two attitudes/doesn't apply controller gains and accel limits to the wrong axes/doesn't apply a rectangular acceleration limit to a vehicle with a diamond-shaped torque response/etc. On May 10, 2015 10:10 PM, "JoshWelsh" notifications@github.com wrote:

Um.. wow?

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

.

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

[rmackay9]

I've deleted the bizarre comments from trollcop. I've deleted a comment from lthall which was a comment more about a person than an issue.

[rmackay9]

tentatively assigning to Copter 3.4 but no promises, it might get bumped later 'cuz the to-do list is already huge for Copter3.4

[strips]

Very good to see something happening here. I think this is very good specially for smaller faster quads with GPS. At least until CAN ESCs are around every corner :)

[dk7xe]

Love to see it in 3.4 to get the full benefit of the KISS ESC's on my 250er

[jschall]

If we're going to do oneshot we should also be trying to synchronize to the gyro or bumping the gyro to 8khz, because the delay between sampling the gyro and running the loop is nearly as significant as the delay between running the rate loop and starting the PWM pulse.

On Mon, Oct 26, 2015 at 4:34 AM, Gerald notifications@github.com wrote:

Love to see it in 3.4

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

[jschall]

A thought here - ArduPlane has 50hz PWM. Is the start of the pulse synchronized with the attitude control loop? If not that is a pretty significant delay and that time could be used for more noise filtering.

On Mon, Oct 26, 2015 at 11:27 AM, Jonathan Challinger < mr.challinger@gmail.com> wrote:

If we're going to do oneshot we should also be trying to synchronize to the gyro or bumping the gyro to 8khz, because the delay between sampling the gyro and running the loop is nearly as significant as the delay between running the rate loop and starting the PWM pulse.

On Mon, Oct 26, 2015 at 4:34 AM, Gerald notifications@github.com wrote:

Love to see it in 3.4

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