Hi,
Is there any plan to implement OneShot125 support for KISS ESC?
Brgds
Mariusz
You need to be a member of diydrones to add comments!
This reply was deleted.
Hi,
Is there any plan to implement OneShot125 support for KISS ESC?
Brgds
Mariusz
You need to be a member of diydrones to add comments!
Replies
Why all the fuss over OneShot? I can see it if you are flying a racer. I have a racer with a CC3D and a set of the new BLHeli_S ESCs. Compared to the "regular" BLHeli ESCs I was using, the new ESCs perform significantly better. But even so, I really cannot see any reason to add OneShot or Multishot support to a Pixhawk.
Racers get the benefit of "smoother" throttle control, which translates into quicker and more precise attitude and speed control which can shorten your lap times, but on an AP rig flying an autonomous mission, who cares?
And as a final note, I believe this new batch of "mini" APMs and Pixhawks are just a marketing gimics.
It's possible to use oneshot escs with pixhawk after it's being supported or they don't work?
Any progress on this? oneshot is obviously the gold standard right now. Don't get left behind pixhawk.
KISS ESC already supports 50-500hz PWM - what's supposed to be the advantage of "oneshot125 PWM" ?
APM/pixhawk is not for the super-smallest toys, - and no bigger motor/propeller can respond anyway to anything close to 500 changes per second - (and that's before I mention necessary calculatinos should be done that fast, not only PWM output - that does not make any sense)
So - while it's a nice marketing gimmick: common PWM goes between 900us 2100μs - and would give a nice resolution on most microcontrollers- this suggested protocol operates between 125-250μs - requireing a very accurate sampling to even ,maintain resolution.
I think this fous on speed is something more needed in smaller toy-quads, where APM/pixhawk is too large anyway. (or am I wrong ?)
Not arguing if there is any benefit to arducopter but the benefits of one shot 125 as I understand it isn't just frequency but also latency. I think the main two points are the pulse train doesn't need to be received at the esc at a fixed freq, it will cope with any jitter from the flight controller, so this means the flight controller can send the latest value when it has it rather than trying to send it when the esc needs it to meet some fixed frequency specification. So I guess offloading the cpu, although I guess if using a hardware pwm generator mitigates this (I guess APM, PIXHAWK et al do?).
The other is the pulse being much shorter, the esc doesn't have to wait so long to see the end of the pulse so gets the the latest data more quickly.
This protocol isn't a brute force just chuck more pulses at it in the same time thing.
If there is improved flight performance due to lower delays going from APM to a 32 bit controller, I don't see how these delay reductions wouldn't be improved by a similar magnitude by using this protocol.
Delays in control loops cause instability, reducing delays makes them easier to tune.
If there is a timed loop in the code that is trying to maintain 400/490Hz precisely, this protocol will allow that to be relaxed and the pulses only sent when ready synchronously.
And actually if combined with active freewheel regenerative braking features of the developers ESCs i can imagine this being noticeable to improving performance/tuning parameters of bigger multicopters.
Edit. I will add that I think smaller multicopter have a genuine use/future for more serious purposes than just doing stunts, no they aren't efficient, but for some applications the smaller size offers benefits if you are willing to keep throwing batteries in the thing. One of the reasons I haven't taken the Pixhawk route is its size.
Edit 2 :) Maybe even you will see fewer pixhawk motor synch esc selection threads if it allowed it :)
I want to see this too. I'm using Cleanflight as it supports OneShot125.
I'd like to know this too...although personally hoping it would transfer to VR ubrain :)
my next quad will use kiss 18's
Stu