{"action":"created","issue":{"url":"https://api.github.com/repos/betaflight/betaflight/issues/7327","repository_url":"https://api.github.com/repos/betaflight/betaflight","labels_url":"https://api.github.com/repos/betaflight/betaflight/issues/7327/labels{/name}","comments_url":"https://api.github.com/repos/betaflight/betaflight/issues/7327/comments","events_url":"https://api.github.com/repos/betaflight/betaflight/issues/7327/events","html_url":"https://github.com/betaflight/betaflight/issues/7327","id":395230622,"node_id":"MDU6SXNzdWUzOTUyMzA2MjI=","number":7327,"title":"Determine optimal gyro/pid rates","user":{"login":"joelucid","id":18134492,"node_id":"MDQ6VXNlcjE4MTM0NDky","avatar_url":"https://avatars0.githubusercontent.com/u/18134492?v=4","gravatar_id":"","url":"https://api.github.com/users/joelucid","html_url":"https://github.com/joelucid","followers_url":"https://api.github.com/users/joelucid/followers","following_url":"https://api.github.com/users/joelucid/following{/other_user}","gists_url":"https://api.github.com/users/joelucid/gists{/gist_id}","starred_url":"https://api.github.com/users/joelucid/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/joelucid/subscriptions","organizations_url":"https://api.github.com/users/joelucid/orgs","repos_url":"https://api.github.com/users/joelucid/repos","events_url":"https://api.github.com/users/joelucid/events{/privacy}","received_events_url":"https://api.github.com/users/joelucid/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2019-01-02T12:16:05Z","updated_at":"2019-01-02T22:41:05Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"For discussion:\r\n\r\nWe currently prefer to run the pid/gyro at 32/32k or 8/8k. As we introduce cpu intensive features a trade-off will need to be made between activation of features and loop times. We therefore need to determine the importance of running high loop rates to various goals.\r\n\r\nThe high level goals I can think of are (a) effective filtering, (b) low latency setpoint response and\r\n(c) low latency response to external disturbances.\r\n\r\n(a) effective filtering\r\n\r\nIt's worth noting that we already have a 256 hz digital lpf on the MPU 6000. We don't know the precise nature (e.g. order) of the low pass.\r\n\r\nBoth our dynamic and rpm notches don't seem to cover frequencies beyond 1khz, so a filter sampling rate of 2khz would be sufficient in terms of nyquist. We might have to run a sw lpf at a higher sampling frequency than 2khz to eliminate higher frequencies left over from the hw lpf. This should be tested.\r\n\r\nSo from a filtering perspective running one lpf at 4000hz and the other filters at 2000hz is very likely plenty. Possibly all filters can be run at 2khz. \r\n\r\nObviously the filter loop frequency should not be lower than the pid loop frequency to present fresh samples to the pid loop and not add any delay.\r\n\r\n(b) low latency setpoint response\r\n\r\nImportant in any trade-off is to compare the loop time latency to other latencies in the system:\r\n\r\nThe TX to FC latency of a Taranis using 8 channels is somewhere around 25ms. Motor rpm effectively follows motor signal like a pt1 filter with a cutoff of around 10hz which gives it a time constant of around 15ms. Now the pids overdrive the motors so we do get quicker response. But it still adds about 7ms latency to the sticks for a well tuned quad. RC filtering adds a bit more, call it 35ms total end-to-end latency.\r\n\r\nGoing from 32khz to 2khz loop times thus increases the end-to-end latency from sticks to quad by 1.3%. Clearly this is relatively a very small impact.\r\n\r\n(c) low latency external disturbance response\r\n\r\nHere the relevant latencies are the motor response latency and the filter latency. Given that the long RC latency is not part of this picture higher loop rates have a larger impact. Still taking normal D delay of maybe 5ms and motor time constant of 15ms into account it's clear that any algorithms that lower filter delay or increase motor response have a much higher potential than ultra high loop rates, which likely bring less than 3% improvement.\r\n\r\nFor example the rpm filter reduces gyro latency by about 1.5ms and D latency by maybe 3ms. This shows how much more important our algorithms are to flight performance than loop time.\r\n\r\n---\r\n\r\nGiven the above I'd tend to support 8k/8k, 4k/4k, 4k/2k and 2k/2k as preferred cycle times. 4k/2k is only needed if a sw lpf above 1khz is necessary. The higher filter rates at 4k and 8k are only there to avoid latency from up sampling at higher pid loop rates.\r\n\r\nIt will be essential to ensure that BF is written to allow lower loop times. The dynamic filter for example currently has issues at those due to increased latency since cycle time isn't taken into account in the state machine. At lower rates several filter stages can and should be run in one cycle.\r\n\r\nI'd expect 2k/2k to become a sweet spot as our algorithms increase in complexity. That should give the F4 a long expected life time - even the lower level ones like the stm32f411.\r\n"},"comment":{"url":"https://api.github.com/repos/betaflight/betaflight/issues/comments/451007972","html_url":"https://github.com/betaflight/betaflight/issues/7327#issuecomment-451007972","issue_url":"https://api.github.com/repos/betaflight/betaflight/issues/7327","id":451007972,"node_id":"MDEyOklzc3VlQ29tbWVudDQ1MTAwNzk3Mg==","user":{"login":"fujin","id":6873,"node_id":"MDQ6VXNlcjY4NzM=","avatar_url":"https://avatars1.githubusercontent.com/u/6873?v=4","gravatar_id":"","url":"https://api.github.com/users/fujin","html_url":"https://github.com/fujin","followers_url":"https://api.github.com/users/fujin/followers","following_url":"https://api.github.com/users/fujin/following{/other_user}","gists_url":"https://api.github.com/users/fujin/gists{/gist_id}","starred_url":"https://api.github.com/users/fujin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/fujin/subscriptions","organizations_url":"https://api.github.com/users/fujin/orgs","repos_url":"https://api.github.com/users/fujin/repos","events_url":"https://api.github.com/users/fujin/events{/privacy}","received_events_url":"https://api.github.com/users/fujin/received_events","type":"User","site_admin":false},"created_at":"2019-01-02T22:41:05Z","updated_at":"2019-01-02T22:41:05Z","author_association":"MEMBER","body":"Fully Agree. I would like to see 32kHz gyro sampling and associated code dropped.\r\n\r\nIncrease in loop budgets will allow for simpler contributions especially of those new to the project.\r\n\r\nAll other points mentioned are accurate."}}
{"actor":{"display_login":"fujin"}}