Thread Tools
Nov 11, 2015, 09:48 PM
Woohoo!
RS2K's Avatar
Thread OP
Quote:
Originally Posted by akcom
Can you at least give us a hint? Are we looking at CAN? I2C? SPI? The curious public demands answers, preferably in 32 bit words!
PWM is the only thing we have to work with with current ESCs so that's where I've started my work.

I don't think I2C is a good choice. CAN is the most fault tolerant, but it's fairly large and expensive. A star topology would make the FC too large and the daisy chain is very inconvenient for min quads. SPI is simple and would work well for talking to several ESCs on the same bus. I'm interested to see how well it will perform in a noisy environment.
Sign up now
to remove ads between posts
Nov 11, 2015, 10:07 PM
Registered User
Quote:
Originally Posted by RS2K
Both latencies are being worked on. The fast CPUs and low looptimes along with some coding changes will reduce the first latency and as far as the second latency is concerned, motors are getting more powerful, High performance ESCs are getting smaller and more powerful (UBAD 30 for example) and wuads are getting lighter.
The majority of the first one is due to the gyro chips, not much you can do about that.
Quote:
Originally Posted by RS2K
There are other ways around the second latency, but I don't think a PID controller is the right tool for the job.
Agreed.
Quote:
Originally Posted by QuadMcFly
I ran into a similar problem on my thrust stand software and updates from the RPM sensor. The delay between pulses could be up to several ms depending on the RPMs of the motor, but I found the faster I could get my cycle time the more accurate a picture of what was happening, because I knew with a higher degree of certainty exactly when the pulse came in in relation to my other sensor readings. I would imagine the same logic applies here. Also as ESCs and motors get better and motor/prop combos are optimized that latency will get less and less. Better to think ahead of where we are than wait to solve the problem till it comes, IMO.
Jitter is a seperate issue, it is overcome by ensuring the gyro interrupt is used effectively. No doubt the latency will be reduced but it will still be in the order of ms (it's 10s of ms now).
Nov 11, 2015, 10:52 PM
I'd rather be flying
QuadMcFly's Avatar
Quote:
Originally Posted by tracernz
Jitter is a seperate issue, it is overcome by ensuring the gyro interrupt is used effectively. No doubt the latency will be reduced but it will still be in the order of ms (it's 10s of ms now).
Jitter wasn't really what I was referring to. I am also using hardware interrupts in my code with the RPM sensor. It's more the "freshest" data idea that RS2K mentioned. All my analog reads, rpm sensing, etc, were done on seperate interrupts at different times. Given that they were all asynchronous to each other, getting my loop output rate down meant I always had a record of the latest data. Longer looptimes meant less certainty on when exactly that data came in. It's literally higher resolution, same as digital imagery.
Nov 11, 2015, 11:00 PM
Registered User
Quote:
Originally Posted by QuadMcFly
Longer looptimes meant less certainty on when exactly that data came in.
That's jitter.
Nov 11, 2015, 11:01 PM
I'd rather be flying
QuadMcFly's Avatar
Quote:
Originally Posted by tracernz
That's jitter.
Ahh, but if you're using multiple interrupts how do you get around that without lowering looptimes?
Nov 11, 2015, 11:02 PM
Registered User
Quote:
Originally Posted by QuadMcFly
Ahh, but if you're using multiple interrupts how do you get around that without lowering looptimes?
Yeah, you need to use priority and pre-emption to choose which ones are most important. That's more of an issue with your test rig where you have a large number of different sensors and they're all pretty important.
Nov 11, 2015, 11:03 PM
I'd rather be flying
QuadMcFly's Avatar
Quote:
Originally Posted by tracernz
Yeah, you need to use priority and pre-emption to choose which ones are most important.
So there is still an advantage to lower loop times if you're using multiple interrupts, in that you don't need to choose the priority of some data over others?
Nov 11, 2015, 11:06 PM
Multirotor Promotor
RaymondM's Avatar
nice , subbed
Nov 11, 2015, 11:07 PM
Registered User
Looptime has no impact on foreground tasks. You have a jitter problem with STM32F0-F7 (and other MCUs) if you use equal priorities for all interrupts.
Nov 11, 2015, 11:14 PM
The big Gorilla in the Room
GREEN GORILLA's Avatar
YEAAA BUDDY. Subbed
Nov 11, 2015, 11:20 PM
James not bond
jy0933's Avatar
im more interested in the claim of
Quote:
fastest flight controllers
essentially, oneshot 125 looks at (the wrost case) 250us per fastest loop in FC, which is 4kHz...

so.. tell me.. what FC runs above 4kHz main loop
Nov 11, 2015, 11:44 PM
Woohoo!
RS2K's Avatar
Thread OP
Quote:
Originally Posted by jy0933
im more interested in the claim of

essentially, oneshot 125 looks at (the wrost case) 250us per fastest loop in FC, which is 4kHz...

so.. tell me.. what FC runs above 4kHz main loop
Check the images in the first post. I've got the revo running in what should be a flyable state at over 9100 hz... (Yup! You heard it here first! It's over 9000!)


I say "should be flyable" since there aren't any ESCs that can fly at that rate (not counting running in PWM duty cycle mode). I could fly it in PWM duty cycle mode, but I don't think that'd help us much... It's also not reliable/safe. I need to make my changes to BLHeli 14.2 to test the flight characteristics of this ultra low loop time.
Nov 11, 2015, 11:57 PM
James not bond
jy0933's Avatar
Quote:
Originally Posted by RS2K
Check the images in the first post. I've got the revo running in what should be a flyable state at over 9100 hz... (Yup! You heard it here first! It's over 9000!)


I say "should be flyable" since there aren't any ESCs that can fly at that rate (not counting running in PWM duty cycle mode). I could fly it in PWM duty cycle mode, but I don't think that'd help us much... It's also not reliable/safe. I need to make my changes to BLHeli 14.2 to test the flight characteristics of this ultra low loop time.
of course. but the point is, main loop rate on performance has diminishing returns. Theoretically possible does not make it viable. I do understand you excitement, since you manage to run it at ultra-high rate, I would say quantifying how fast it is really is necessary to get better/best performance over accepted 500hz.

sorry for going off topic.. see it as an old man mumbling then.
Nov 12, 2015, 12:02 AM
I'd rather be flying
QuadMcFly's Avatar
Quote:
Originally Posted by jy0933
of course. but the point is, main loop rate on performance has diminishing returns. Theoretically possible does not make it viable. I do understand you excitement, since you manage to run it at ultra-high rate, I would say quantifying how fast it is really is necessary to get better/best performance over accepted 500hz.

sorry for going off topic.. see it as an old man mumbling then.
We haven't been running 500hz for a year. As you mentioned, oneshot maxes out at 4khz. Most people are updating at 1khz currently. (1000us loop)
Last edited by QuadMcFly; Nov 12, 2015 at 03:49 PM.
Nov 12, 2015, 12:09 AM
I'd rather be flying
QuadMcFly's Avatar
Quote:
Originally Posted by tracernz
Looptime has no impact on foreground tasks. You have a jitter problem with STM32F0-F7 (and other MCUs) if you use equal priorities for all interrupts.
So where do you think the cutoff would be for improvement due to looptime, or is there any benefit at all? I see you mention OP a lot, but for as fancy as OP is, somehow Cleanflight/Betaflight still outperforms it. RS2K measured a 10x decrease in latency between OP and Betaflight. So it seems there is some improvement caused somewhere. Or maybe I am still missing something?

People said similar things about oneshot when it first came out, but I think everyone now agrees that oneshot has shown significant real world performance gains. It just seems to me that there is only potential gain in exploring this route and no real loss. Real world tests will tell if there is improvement, apart from the theory.


Quick Reply
Message:

Thread Tools