> Have you tried deriving the PID parameters from the latency? Worst-case we > could have a set of parameters for when the latency is above a certain > value and a set for below. > Here is an idea, deriving PID params based on latency is not the worst thing, but it should be this way.. Currently we are using only P controller (and it is working quite well). If you notice, the behavior of scratching varies across latencies. For lower latencies system reaches the target position faster as compared to higher latencies. And for very high latency (85.3ms) system overshoots because the update rate of current position is slow and the corrections applied shoots beyond the target position, hence the rubber band like behavior. One of the things that we dont want is to over shoot the target position. The P gain should vary with latency and error (difference between target position and current position). Like, if latency == 10 ms if fabs(error) > 60000 m_p = UPPER_THRESHOLD // apply corrections aggressively else m_p = LOWER_THRESHOLD // slow down as we approach target value, to avoid overshoot This kind if thing is more required for higher latency. On my dev box, following works well, if latency == 85.3 ms if fabs(error) > 160000 m_p = 0.0002 // the current value that is being used else m_p = 0.00005 // slow down as we approach target value, to avoid overshoot but I dont see this as a good solution because this will not guarantee similar behavior across latencies, m_p should vary as (some kind of exponential) function which depends on error and latency in use in order to make scratching more 'consistent' my two cents. > > > On Wed, Feb 6, 2013 at 2:18 AM, Daniel Schürmann < >