are v5 built in encoders better than gyro when coding precise turns. If encoders are better, whats the best way to go about making a highly accurate turning code for v5 built in encoders
It depends on how much wheel slippage you have. The best solution is quad encoders on freespinning wheels.
I used cortex this season, so I had quad encoders rather than built in ones, but this should work for you too. I basically reset my encoders, then drove my robot exactly 90 degrees, and printed my encoder values. use these values to determine how many encoder ticks it takes to rotate by one degree.
do you use pid for your encoders on turns
no, I’m not yet experienced enough with PID to implement it on turns, but if you can I’d advise it.
1 Like
It would be best if GYRO and ENC could be integrated. I have no idea about that.
First you would define a target (in this case, the amount of degrees you want the entire robot to rotate among its center), then you would obtain the 2 sensor values (one from the gyro and one from the encoder) and average out their feedback in a loop that constantly detects the error which is the difference between the target and the current degree rotation. The loop has to constantly compare the 2 values and input their average into a PID loop. You would have to convert their input into the same units though.
The encoder value of the left and right wheels is not the same as that of the actual test robot when it moves forward 1 metre.
It is impossible to achieve left-right balance by simply adjusting coefficients.
The default speed loop in V1.05 sometimes appears the phenomenon of memory cleaning is not clean. It can not be used. Then I have to write a speed loop myself. This is beyond the actual level of my students.
I don’t understand why the value of the 2 encoders would be different. It would have to be a physical factor because in a symmetrical robot, the motors turn at the same rate if it moves in a straight line. That is simply how a robot would have to move, if the values are different, then it isn’t moving straight. Also, you can use a gyro to correct any discrepancy in the event that the 2 values are different.
Perhaps every encoder has a characteristic error.
The gyroscope itself has a self-increasing problem. Our team’s current technology is not feasible to achieve the accuracy of the mathematical model.
Slight manufacturing differences will affect the motors. Also, a little variation in friction of the field or axels will also affect it. Lastly, turning fwd and rec might also variant in speed
@9227, just like I said in the other thread a lot depends on your chassis geometry and what type of wheels you use.
If you have fully symmetric chassis with all omnis - it will be easy to control it based on encoder values. However, if you have a pair of traction wheels either on the front or the back of the robot and they are not chained together, then encoders on the front and back wheels could return different counts as you turn and you have to watch out and go slow to avoid slippage of the wheels.
Encoders are digital sensors and their error source is wheel slippage. Gyro is an analog sensor and its errors are result of the electrical and thermal noise as well as mechanical vibrations.
If you have V5 and are a beginner, I would stick with encoders, but if you want to learn and willing to try custom Gyro library that does some filtering, here are some links:
2 Likes
Im using V5 integrated motor encoders and referencing from the left front wheel