The reason (or a possible reason) Grim Tuesday brought up encoders is because they can help you in correcting any bias that may pop up due to any issues, be it a mechanical or an electronic issue.
With an encoder, you can perform some higher-level programming and include features such as PID (
proportional–integral–derivative) loops to account for error.
For example, if your code is telling the wheels to spin at 2,000 RPMs (I know, not how it actually works, but bear with me), and the encoder says the wheels are only spinning at 1,800 RPMs, you can use your code to dynamically adjust the output until the wheels are all spinning at the same (and/or correct) rate.
Simply multiplying the output by .96 because that's the error you measured once or twice is
not a good programming habit to get in to. These "
magic numbers" are bad practice because they make the code difficult to adapt later and the magic number that indeed performs magic may vary depending on the situation.
Quote:
|
When reading on the driver station the pwms to the jaguars show me that two are getting less than the other two.
|
This would indicate to me that there is something wrong with the code. Assuming you are not using the CAN bus or any encoders, the PWM values the DS shows are for all intents and purposes what your Victors/Jags are running at. Thus if those values are off, the wheels are not getting the correct values.
However, be aware that if you aren't pushing your joystick perfectly in one direction, all four values
shouldn't be the same. I would recommend taking the joysticks' values and running them through the code yourself to see what is happening and what should (in your eyes) be happening.
Also make sure you are working with freshly charged batteries. Poorly charged batteries can cause a number of problems.