{"action":"created","issue":{"url":"https://api.github.com/repos/Traumflug/Teacup_Firmware/issues/233","repository_url":"https://api.github.com/repos/Traumflug/Teacup_Firmware","labels_url":"https://api.github.com/repos/Traumflug/Teacup_Firmware/issues/233/labels{/name}","comments_url":"https://api.github.com/repos/Traumflug/Teacup_Firmware/issues/233/comments","events_url":"https://api.github.com/repos/Traumflug/Teacup_Firmware/issues/233/events","html_url":"https://github.com/Traumflug/Teacup_Firmware/issues/233","id":168540250,"number":233,"title":"ACCELERATION_TEMPORAL","user":{"login":"Wurstnase","id":8709415,"avatar_url":"https://avatars.githubusercontent.com/u/8709415?v=3","gravatar_id":"","url":"https://api.github.com/users/Wurstnase","html_url":"https://github.com/Wurstnase","followers_url":"https://api.github.com/users/Wurstnase/followers","following_url":"https://api.github.com/users/Wurstnase/following{/other_user}","gists_url":"https://api.github.com/users/Wurstnase/gists{/gist_id}","starred_url":"https://api.github.com/users/Wurstnase/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Wurstnase/subscriptions","organizations_url":"https://api.github.com/users/Wurstnase/orgs","repos_url":"https://api.github.com/users/Wurstnase/repos","events_url":"https://api.github.com/users/Wurstnase/events{/privacy}","received_events_url":"https://api.github.com/users/Wurstnase/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":29,"created_at":"2016-07-31T21:51:04Z","updated_at":"2016-08-04T18:42:42Z","closed_at":null,"body":"Hi all,\r\n\r\nI'm currently working on ramps for acceleration temporal and before I forget this I write it down.\r\n\r\nI found an issue in timer_set(). The part `(current_counter - match_last_counter)` can be negative. \r\n\r\nSo I changed this part on STM32F411 to:\r\n```\r\n      int32_t check_timer;\r\n      check_timer = (TIM5->CNT - TIM5->CCR1) + 100;\r\n\r\n      if (check_timer > delay) {\r\n        return 1;\r\n      }\r\n```\r\n\r\nThe LPC should have something like:\r\n```\r\n      int32_t check_timer;\r\n      check_timer = (LPC_TMR32B0->TC - LPC_TMR32B0->MR0) + 100;\r\n```\r\n\r\nOn the simulator I had no issues, but maybe the AVR needs also a change.\r\n"},"comment":{"url":"https://api.github.com/repos/Traumflug/Teacup_Firmware/issues/comments/237645305","html_url":"https://github.com/Traumflug/Teacup_Firmware/issues/233#issuecomment-237645305","issue_url":"https://api.github.com/repos/Traumflug/Teacup_Firmware/issues/233","id":237645305,"user":{"login":"phord","id":123908,"avatar_url":"https://avatars.githubusercontent.com/u/123908?v=3","gravatar_id":"","url":"https://api.github.com/users/phord","html_url":"https://github.com/phord","followers_url":"https://api.github.com/users/phord/followers","following_url":"https://api.github.com/users/phord/following{/other_user}","gists_url":"https://api.github.com/users/phord/gists{/gist_id}","starred_url":"https://api.github.com/users/phord/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/phord/subscriptions","organizations_url":"https://api.github.com/users/phord/orgs","repos_url":"https://api.github.com/users/phord/repos","events_url":"https://api.github.com/users/phord/events{/privacy}","received_events_url":"https://api.github.com/users/phord/received_events","type":"User","site_admin":false},"created_at":"2016-08-04T18:42:42Z","updated_at":"2016-08-04T18:42:42Z","body":"Oh, I didn't realize this is a general \"Implement ACCELERATION_TEMPORAL\" issue.  I thought the first comment about a suspected bug in timer was the real issue.\r\n\r\nThree items come to mind about your wiki. \r\n\r\n1. You mention calculating new math \"every other microsecond\", but I think you mean millisecond.\r\n\r\n2. It is not necessary to **calculate** four orders of equations at runtime in order to achieve the same result.  The Bath paper looks at this specifically.  The key feature of that article is that a formula is proposed which results in smooth f, f' and f'' (velocity, acceleration, jerk), which provides direct formulae for all three, and which bounds each function to desired limits. Thus using only the `velocity` formula from that paper and ensuring the `alpha` value is chosen to respect the limits on the other two graphs is enough to get a smooth curve on all three levels.\r\n\r\n3. It is reasonable and useful to combine both **Non-linear acceleration** and **Velocity Calculation at Discrete Time Intervals** to achieve a smoother hybrid.  Let me explain:\r\n\r\n**Velocity Calculation ...** works by calculating a new step-time (velocity) for the current desired velocity every 2ms. Let's call this `target`.  Ideally this is the average speed we want to achieve for the 2ms period, so perhaps it is based on V(now+1ms) instead of simply V(now). \r\n\r\n    target = V(now + 1ms)\r\n\r\nIn either case, we use this step interval for 2ms until we run again to calculate a new value for `target`.  Suppose instead we calculate two values called `target` and `next`.  \r\n\r\n    target = V(now)\r\n    next = V(now + 2ms)\r\n\r\nNow `next` holds the velocity we want to use at the end of this interval.  Rather than using a fixed step value during this interval, we can adjust the step value REPRAP-style by simply adding some constant after each step to `target` so we end the interval at `target = next`.  We can calculate this constant (the slope from `target` to `next` over 2ms) easily enough.\r\n\r\nImportantly it does not overly complicate our 2ms math by requiring us to do twice as much work. We only need to calculate both `target` and `next` at the start of our move.  And then each subsequent 2ms calculation becomes simply this:\r\n\r\n    target = next;   // re-use previously calculated value\r\n    next = V(now + 2ms)\r\n\r\nExcept we do also have to calculate our slope, too:\r\n\r\n    steps_this_interval = 2ms / (( next + target ) / 2)\r\n    slope_this_interval = (next - target) / steps_this_interval\r\n\r\nBut I think this might simplify further:\r\n\r\n    slope_this_interval = (next - target) / steps_this_interval\r\n                       = (next - target) / (2ms / ((next + target)/2))\r\n                       = (next - target) / 2ms * ((next + target)/2)\r\n                       =  (next - target) * (next + target)/2 / 2ms\r\n                       =  (next*next - target*target) / 4ms\r\n\r\nWeird.  \r\n\r\nConveniently this model (using `target` and `next`) fits well into a method which uses a linear-approximation of some complex velocity curve via a lookup table.  "}}
{"actor":{"display_login":"phord"}}