Using pros to test pid broke two motors, have you ever encountered this situation?Thank you very much.
There are a variety of circumstances that could have caused this situation, not necessarily related to PROS or testing PID control.
Please elaborate on what you mean by “broke two motors” and describe in detail the circumstances that caused the situation. Including the code you were running may be helpful as well, to determine if the issue may be related to your code.
Thanks so much for your reply, this is caution.
is my change number.
Then Power on -> control my joystick -> my smart motor LED over.
may be that the P value is too large.
The real question is what did you put in for P?
From 0 to 5 for P value.
This is probably exactly what happened. Your k_P=5 constant is almost certainly well beyond what would be considered safe.
Changing the motor’s built-in PID gains is dangerous. Since VEX has not provided the default gains, it is impossible to figure out a good starting point and/or the scale the values are on. The values in the PROS docs are just examples.
Next, since this PID runs directly on the motor, I believe it has more direct access to the output power. I’m not sure if there is current/overheat limiting, probably. However, there might not be.
PROS did give you a warning. This has nothing to do with PROS btw, this is a VEXos command. However, PROS might be the only software that exposes that command, I would have to look at VEXcode/RMS.
It is easy to damage the motor if you change its internal control values, which is what that command does. Think about it. With much too high gains (I suspect proper gains are in the range of
0.0001 ), you will absolutely destroy the motor, because it tries to occilate so fast. Especially if there happens to be no limit on the integrated PID.
Please don’t continue using that command.
Instead, you can either use the default gains, or you can write your own PID loop that calls
move() (voltage control). You can also look into using okapi’s PosPidController.
Those last two methods are user-based PID code (it runs on the brain) that ultimately will control motor voltage. This is the much safer way.
Too bad about your broken motors, I would try to return them.
@jpearman I’m not sure if you are the one I should ask, and you have been probably been asked this already, but it would be very beneficial if VEX could release the default integrated pid values. This is a real example of someone breaking the motors because of incorrect starting parameters. Alternatively, It might be a good idea to cap the PID gains to a “safe” value.
Does VEXcode/RMS have this function available? If not, it might be good for the PROS devs to remove that function, as without a good starting point for the values, it is easy to cause damage to the motors. Or maybe make the warning much louder
There is nothing inherently wrong with changing the integrated PID. It is silly that doing so could cause the motor to break, especially if doing user PID does not break it. However, the reason for this is because the integrated PID responds much faster than a user PID. Such fast oscillation is what damages the motor (or the control board).
No, not without some effort, there’s nothing in the C++ API.
We didn’t release default values for several reasons, one of which was not knowing exactly what combinations could potentially cause damage. We did release to the PROS team for them to evaluate, I’ve never heard of anything like this happening before though.
I would be interested to know what has happened to @Hubert’s motors, is this internal physical damage or is there electrical damage.
If the motors were purchased from Robot Mesh, they are not eligible for return under warranty.
Thank you very much for your reply, very helpful to me.@ theol0403
electrical damage double.
any idea what ? Does the V5 still detect them ? Do they turn if controlled from the V5 dashboard ?
Is there any place in which we could find the initial values (e.g. source code) if we were willing to accept the possible risks? If not, could you tell me what the constants are being multiplied by (e.g. raw position, motor’s units) and how they are translated into a motor power (e.g. voltage, percent, etc.)?
I think others have mentioned this, but I don’t really see any reason to modify the constants directly on the motors. Most people either make do with the default (tuned for general-purpose) control, or write their own control loops where the output is motor voltage.