The encoders do not work sometimes during autonomous, where the robot does not move at all (except for the sections of the code that use the gyroscope and potentiometer). After they don’t work, it doesn’t happen again until after 5-10 more runs. I can’t figure out what would be causing this, unless it is because of the motors overheating due to previous runs…
Here are the details of the robot
Programming language: RobotC
Sensors: Gyroscope, Potentiometer, four bump sensors (for selecting autonomous programs), two encoders, and a pneumatic system with two pistons and two reservoirs pumped at 100psi.
Motor layout:
1 motor for forklift
1 motor for intake rollers. The motor is configured for high speed
4 motors for four-bar lift
4 motors for wheel-base, one for each of four wheels. The motors are configured for high speed.
The right back wheel and the left back wheel have encoders.
The program is attached to the post (it didn’t fit the character limit).
I think teams had problems with static in the past. When the robot drives for a long period of time, static builds up on integrated motor encoders and things go all crazy. This could explain why it works after 5-10 runs.
I was talking to a mentor about this problem and he had an idea. The idea was to have a chain drag on the ground to release the static, versus the rubber on the wheels that can’t release the static.
Not sure if it works or not. Does anyone else know how to solve this issue?
One of the teams from our club did this last year with an axle. They said they never had issues, but I think they did it from the get-go, so they might not have had issues regardless… I’ll ask them tomorrow when I get back to school.
EDIT: Neither one of the three times this year are having any issues with IMEs and we’re not dragging parts on the ground.
Trying to discharge static by using chains or other parts draging on the field tiles was discussed last year and generally thought to be ineffective and a possible risk of entanglement. I forget which thread this was in but the engineers at VEX more or less said it wouldn’t work.
You might want to review some of my views in these two.
At our last tournament, we had problems with IME’s and static. When the IME’s were plugged in, the robot would randomly disconnect from the controller, but all motors would continue at the same speed.
Does anyone know if anti-static spray on the field or wheels of the robot would solve this problem?
Yes it will help, read the two posts I linked below (post #9). It sounds like your cortex was reseting due to the watchdog timer if the motors continued moving. Alternatively, if the encoders were reseting back to 0, and if you were using them to drive until a certain encoder count, you would have driven further.
Ok, so I’m currently debugging the quadrature encoders, but the encoders have been exhibiting a rather odd behavior. The value of the encoder only changes when the wheel is pushed at full speed. If I move the wheel using my hand at any other speed except for top speed, it won’t register anything.
Does anybody know what would be causing this? And the sensor is measuring the movement of a shaft on a high speed 393 motor. Both are directly attached to the same shaft.
We’ve seen issues in the quad encoders with dust inhibiting the quad encoder from reading correctly. Open it up and ensure the wheel is turning correctly and there is nothing preventing the reader piece from seeing the holes in the wheel.
Our dust source looked like it came from a nylon spacer getting rubbed along the quad encoder as it was held pretty tightly by the shaft collar and other spacers. After enough driving and abuse the dust made the quad not read right. Once the internals were cleaned off it ran fine.
