Robotc pid control update#
Robotc pid control android#
Robotc pid control series#

One mitigating factor is that we've almost never emphasized the integral component in our PID usage and that's the component that is most susceptible to latency errors. But whether the measurement latency issue is a material factor for the sensors my team plans to use - that won't be known until they get their controller finished and start profiling and tuning its behavior. For FTC robots of the size, weight, speed and responsiveness of the motors in use, the loop times we are typically seeing in opmodes seem sufficient based on my experience. With regard to the accuracy and timing issues you originally raised - the minimal timing needed to be successful with PID control is completely dependent on the dynamics of the system under control. But it's a good conceptual write up for those wanting to go beyond PID basics.

Robotc pid control update#

The only thing I don't like about it is that it attempts to force a constant update interval to make the I and D calculations easier and the way they did that is not applicable in the ftc_app environment.

Robotc pid control series#

In particular, I really like the explanatory blog series starting here. As a learning resource, I also recommend taking a look at the Ardunio PID library even though it is not java. It's also possible that my team will decide to roll their own from scratch yet again. It's not that complicated and teams are better off going through the exercise and learn by doing. If they come up with something of shareable quality, I'm sure they will do so, but there is no need to wait on them. They found a java PID controller that actually originated from FIRST and can be found here: Because that implementation does assume a regular loop time, they are refactoring it to measure elapsed loop time. So here's what the Iron Reign members are doing. For other sensors, I think profiling under actual battle conditions will be more useful than theoretical arguments. I took the opposing point of view, but he was more correct in this specific instance because our models were about the Hitechnic gyro sensor and in that case the accuracy hit was in the neighborhood of the noise and drift issues of the sensor. While they show that there are differences in accuracy of the integral calculation due to measurement latency, he was arguing that the inaccuracies were not material. We've even passed models of calculations back and forth. I've had a vigorous debate with another coach about the possible effects of this unknown measurement latency and whether it matters a whole lot given reasonable boundaries of the actual temporal behavior of the modern robotics hardware. I'm not so sure this would work on the legacy motor controllers with their significant read/write mode switching lag - we'll have to try that out. There was a bug using it with the version of RobotC we had when we started out, so my students rolled their own and liked having control over the PID factors with the ability to mix them up in real time. But for sensors connected through the CDIM or the legacy module, this unknown measurement latency seems to be more significant.Īs an aside, we were never happy with the built-in PID on the hitechnic motor controllers. Even 'built-in' sensors - like the camera, can't give you a super accurate timestamp. But it depends on which sensor you are using and also how amped your Kd and Ki terms are. This variance between the actual time the reading was taken and the current loop time when it is accessed can be a material problem. We can measure the delta in the loop time easily, but we often don't know exactly when the measurement was taken because that happened asynchronously and we only received a buffered value that may have not even updated since the last loop. The only gotcha here is that we would prefer to have an accurate timestamp on each sensor reading, and that doesn't seem to be in the cards for this system as currently implemented. This gives us all we need to know to calculate our derivative and integral. Instead we've used timers to measure the delta time from one sensor reading or loop to the next.

We've been using PID for a few years without ever assuming a regular loop time. A lot of existing PID solutions are built this way - so they have to be modified or you can start from scratch. So right off the bat we know we don't want a solution that is assuming close adherence to a regular loop period.

Robotc pid control android#

Also jitter is a divergence from periodicity and as you pointed out, that's not a concept applicable to Android user code. We're not building industrial robots or CNC machines here. I'm not sure that sub-millisecond jitter is really required.