Motor Delay - Inertia is a b****

[@Fleche_FPV]

In my opinion the increase in the frame rate is not so much for the delay but rather to have a cleaner signal with a better resolution, more detailed, especially for very thorough and very lively setups. as for hi-res music

[@justinramell]

Everything is cumulative. We can't break physics, but we can remove as much latency as possible everywhere else - low latency cameras, control links, ESC protocols, faster loop times and less filtering all added together will certainly be noticeable.

[@rotorismo]

I think thats true. Therefore I also think there's much more to develop on the hardware side that has more effects on quad feel than software does. Software looks like it has reached its peak if you watch its complexity nowadays.

[@twinturbostang]

How about measuring the delay from stick input to quad movement. After all, that's what really matters. Easy to do. Give a quick full throttle jab, and then look at the black box logs of the stick command vs. Z-axis acceleration.

[@FPVUniversity]

There will be a next video on this topic in the future

[@zfpv7211]

I think it’s understood that there are physical limits, but reducing latency everywhere possible will always be better than not. If all you had to deal with was the physical motor limitations, I’d say you’re in pretty damn good shape lol

[@frasersteen]

Interesting but I still think it makes sense to search for every ms of latency that you can. 1. The effects of latency are cumulative, if you had 0.5s of latency you might be able to fly but at 1s latency it would be near impossible. I don't think you can reliably say that if you have 100ms shaving 5ms won't make any difference. 2. much like saving weight on a quad you can have a significant influence by making small changes in lots of places. Control link, esc protocol, software latency, camera feed, vtx etc if you can shave a few percent on a few it will add up. 3. Incremental gains, even if these kinds of changes don't make any real difference now it's the kind of incremental improvement that means the stuff we have in 3-4 years has notable improvements with cumulative small improvements.

[@spchips]

Every bit helps. The experience is sticks-to-glass. I agree that small changes don't necessarily matter, but they all add up. I think low to moderate, but most importantly - predictable latency helps with confidence and control.

[@crfadv]

I enjoy this physics/electronics/programming/automation videos so much! Without this aspect of hobby, DIY drones would be just a toys. Thanks Pawel!

[@edouardmalot51]

Did you check the props weight impact on motor response ?

[@nicecrash]

Thanks Pavel, fits exactly to what i'm thinking and testing for some time now...32/32 pidloop min. filtering dshot4800 on F3 ESCs with EMU ...low pitch props and wide motor stators with low spool-up/spool-dow time. We have so much timing and frequency based components to deal with, that we get into the same circle like we did with RC rates back in the days. Today we know that RC rates are more a personal thing, and timing or the interpretation of what we feel as result of a stick input is not very different I think. My conclusion after playing with all that setting for some time is, that there is a place for all these combinations. Flowy, cinematic movements benefit from more relaxed timings that are optimized to the pilots preference while faster update rates and less latency for RC command will help in the racing area. At the end we are again at the point at what we have to accept that code and theory are not great to describe how a quad feels in the air or if one will like it. It's a good sign for the community that we still have the freedom of choice in terms of flight software and protocol flavours - big THX to all the DEVs 😜✌️.

[@SneakyB]

Maybe play with 96khz too ;)

[@brunofporto]

Well... It is a serial reaction so each step is added to the total delay. The delay if the radio firmware and module communication. Then the radio link delay. Then the FC process time to decide the correct output. Then the ESC timing and finally the inertia. As it is a series then any delay that can be chopped will make some difference. Not for me.... I am not a racer then I do not need that fast reaction timing.

[@danieldimitri6133]

Gotta go on mini quad test bench and find the thrust/time curves to pick your motor and prop combo. Sure it's not everything as you could have a feather weight build that takes less thrust to what it needs to. But a clever person could figure out how to scale it based on appropriate build weights. People might be surprised at what a biblade prop can do with the appropriate motor behind it.

[@yngndrw.]

While I agree with the general point you're making, I do wonder how much of the measured delay is within the RPM feedback from the ESC. (Electrically, algorithmically and via the protocol) A fairer test would be to use an ESC / motor / prop on a thrust test stand, as you alluded to.

[@bizmar]

Use "M" on keyboard to measure time, by moving the timeline. Pressing M again dismisses. 😉

[@jas-FPV]

Also not zoomed in 🙈

[@uavtech]

Was thinking the same thing.

[@benboonzaayer7866]

What motor size and KV do you recommend for 6” 6s for mild freestyle to cruise style?

[@TheNightfireify]

After watching multigp pilots race, I kinda do think any gains in latency would benefit them, but for most pilots it probably doesn’t matter at this point. Though I’m a little confused since we are talking about how many packages are sent from the tx to the rx in hz, and the latency between that input and the desired output in ms. Those seem like two different distinct things no?

[@adrianmiriuta7216]

Here a few comparative tests, this is a ramp test with different ESC(firmware) motor combinations github.com/3x8/nostromo/tree/master/tests/rampTest/ESC-motor-comparative acceleration delay is 20-50ms deceleration delay is about 50-100ms I did tests with and without props the delay with props is about 2 x higher

[@reptethetetlen]

What's exactly the data in the top row? Is it recorded using a common debug mode or custom one?

[@typxxilps]

Does Immersion RC support your channel with the ghost system any time soon? I had hoped they were a bit cleverer to cover the wider channels beyond the pure quadcopter channels They claim 10km + range but that is not the usual copter use case - rather fixed wing under inav. Hope you get one soon ... meanwhile I will start to use my r9m system that is laying in the shelves.

[@FPVUniversity]

No, of course not. I preordered Ghost just for my own money

[@litterbug4023]

You are just now figuring out what the folks that developed openpilot/ librepilot / and dRonin have know and said all along.

[@edocit4778]

Very nice discussion, can you please in next videos for programmers and developers like me show how to get motor transfer function to design a model based controller ? Thank you in advice for you work 😉

[@strikerFPV]

You're messurement's don't really seem accurate or am I mssing something? On the input data you took your messurement right at the beginning of the rise. At the telemetry you took your messurement after the rise is already happening. This is at least 10ms off. Also what additional delay is coming from telemetry messurement, fw processing data, etc. itself? Edit: I just looked at my (old) blackbox logs and my complete RC Command to Gyro delay is around 20-30ms tops, often lower...

[@JyeSmith]

Lots of good clear examples of motor response on miniquadtestbench and my repo. This doesnt negate the need for faster RC packets, as there additional benefits to the FC wrt filtering, FF, etc. Any intermediate pilot will feel the stick difference between 9-6ms, and yes you get diminishing returns beyond that only the top pilots may 'feel'. As you know, 2.4 LoRa packet rate and signal strength is a balancing act. Lets see what other vendors choose... go fast or opt for a stronger link ?!?!? www.miniquadtestbench.com/motor-explorer.html raw.githubusercontent.com/JyeSmith/dshot-esc-tester/master/data/EMAX%20RS2306%202400KV/comparison%20plots%204s.png

[@MCsCreations]

Pretty interesting testing, Pawel! And pretty impressive results! 😮 Now imagine cameras with 4ms delay vs cameras with 20ms delay... 😬 Anyway, stay safe there with your family! 🖖😊

[@lawrencemartin8205]

Nice.. its all hype and marketing.. noce testing thanks

[@uavtech]

Catch up buddy (published 2019) ;-P Good stuff. For comparing results: Motor Delay: m.facebook.com/story.php?story_fbid=2199717806956008&id=2050713788523078

[@ИльяСиваш-у6ю]

Привет! Паша надо твои видео озвучивать на русский. Будет много подписчиков из России и всего мира.