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 :)
so basically, you get motor speed change up to ~1.9ms faster with one shot in best case scenario (regardless of FC and ESC processing power).
This is in fact close to the latency difference between "simonk" fws at 500hz and "regular escs".
I don't know how fast motors react, but I suspect this does make a diff for stabilizing the copter even on large ones, specially when theres vibrations/wind/etc. So not just for acro. (besides, ppl can do acro on the apm/px4s if they want.. ;)
It therefore seem interesting to add support for this, possibly more than just a marketing gimmick. I suspect that if the naze32 has no problem with this, the px4/pixhawk should be fine too.
I should go reading up the source i guess. I suspect the oneshot sampling (less data) is still more efficient than 500hz constant sampling with more data.
Replies
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 :)
PWM goes up to 2.1ms latency.
oneshot makes that always around 0.250ms latency.
so basically, you get motor speed change up to ~1.9ms faster with one shot in best case scenario (regardless of FC and ESC processing power).
This is in fact close to the latency difference between "simonk" fws at 500hz and "regular escs".
I don't know how fast motors react, but I suspect this does make a diff for stabilizing the copter even on large ones, specially when theres vibrations/wind/etc. So not just for acro. (besides, ppl can do acro on the apm/px4s if they want.. ;)
It therefore seem interesting to add support for this, possibly more than just a marketing gimmick. I suspect that if the naze32 has no problem with this, the px4/pixhawk should be fine too.
I should go reading up the source i guess. I suspect the oneshot sampling (less data) is still more efficient than 500hz constant sampling with more data.
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