#Robotc pid control full
They have worked on this by having a loop that increments the max speed of the set motor target command every 20ms to get up to full speed over a 0.5 sec period, but wouldn’t this reset at least the accumulated integral information each time the command is sent? So, for instance, if they want to move 1400 counts as fast as possible they must use the max speed in the command which may jerk or cause the robot to veer at first. However, presently the kids can request a move to a target value with a max speed, but not with a profile. It seems you may have this accounted for in V5 with motion profiles. One of the issues the kids run into each year is acceleration. Also, is 95% speed on one motor the same as 95% on another (I assume so for IQ)? Our kids use Graphical C since they are 9-11 yo, but I’ve looked through the regular IQ RobotC commands and it seems all the speed commands are -100% to 100% of min/max, but I see no definition of what that speed actually is? We can’t request a move to target with a known speed in RPM, just %. Great info, I’d like to ask another IQ question since they seem relevant. All of the math is integer math on the motor processor so the brain does the conversion from % or RPM to encoder counts per cycle and the motor controls the raw integer data. While we give the user the ability to describe the speed in RPM and %, the actual limits and control are all in encoder counts per cycle. I expect we may also have different gain sets for the different gear ratio motors (yes, there will be three output speed versions of the motor with a MUCH more user friendly way to swap gear ratios). In the V5 motor we are going to give the user the ability to control PIDF and the motion profile parameters, but will have 2 default sets of gains: one for non gravity loaded applications and one for gravity loaded applications. We then pass both the velocity error and the position error into the control loop (since the derivative of position error is velocity error and the integral of velocity error is position error).ĭoing this allowed for us to have very large Kp, Kd, and Ki gains since the error is so small as it is looking at the error every loop (approx 16ms) instead of the total error for the end point.įor pure speed control without position control it is a traditional PIDF with the feedforward gain doing most of the work. We do this with motion planning before entering the PID control loop.īasically, at each motor loop (independent of the main loop in the brain) we tell the motor where it should be (in encoder ticks) and how fast it should be going (in motor ticks per cycle). In position control we are actually controlling speed while tracking to a position. We have both speed control and position control. In the VEX IQ motor, there is a lot going on.
#Robotc pid control free
Of course if people see errors/spot things that might confuse people, feel free to send me a PM and I’ll do my best I’ve had heaps of comments supportive of the document which has been lovely, but obviously I want this to be the best it can be (while not roaming outside the intended scope) so any suggestions for improvement are always welcome. Right now, I’m in the middle of my university exams so it doesn’t sit as a high priority, but I’ll do it when I find the time.
#Robotc pid control update
Obviously this document was never intended to be academic, it’s very much only an introduction for students.Īs always, I’ll update the document when I have a few minutes. I know that plenty of new programmers in VEX use “speed” as a variable to represent the power for a motor, so I think it hasn’t confused too many people (certainly I hope not). Yes, this is correct, although in the 5-6 years since I originally created this document I’ve never had anyone make this comment to me before. In the guide referenced by tabor, they confuse speed and power.