Ok, so our team has been working on autonomous for the past week and the programmer would perfect the code, run the autonomous and have it work. He would then run the autonomous 3 more times to test, and the robot would do 3 different things. We have checked the motors, wheels, axles, field, can anyone think of anything that might help?
There are many factors that play a role. These robots generally have lots of flex or variation possible in the various drive or mechanical assemblies of the robot. It is quite challenging to get precise when you have lots of play in gearing, Omni wheels like to bounce around so can affect your direction, battery charge levels can make a difference, even things like wheel slippage can steer a robot way off course. So try and get flex out of the wheels, make sure they run straight and flat. We’ll put it out on a gym floor and see who can run the longest “straight” line.
Often I see teams use walls to “realign” a robot after couple turns before moving on. Also turns can be made more accurate with use of the gyro, and moving for specific degrees of rotation vs running for an amount of time will provide a more accurate result. If your motor speeds are fast and you will easily over shoot a rotation target, so if you can slow down the speed as you get close to your position you will improve the repeat ability of the movement.
So much can be affecting your robot but these things are pretty common that my teams have needed to deal with to make it more predictable.
1 Like
Can you post your code? It might help to make some suggestions.
We had the same thing happen. I will ‘upvote’ the suggestions already made. Make absolutely sure the robot is as solid as possible. The wheels should be tight, axles should be straight and not wobble. Also, depending on the code you use, the robot will change actions depending on battery charge level. code samples would help.
We were just digging deep into one of the robots that we have and we measured 3 inches of play at the end of the arm even with the motor doing a position hold. The arm was approximately 12 inches long which is exaggerating the play in a simple gearing of 12:36 off a single IQ motor, This was suppose to be something simple on the robot to be able to insert into the top of hubs for dragging. The unpredictability of that was identified to be mostly in the motor. A motor change improved things some but the team came up with a design change that ensured that there was always tension in a single direction on the arm so that the play was no longer a factor. In this case really small a design change eliminated that 2 to 3 inches of unpredictability…
Another situation with the autonomous driving and affected the robot’s immediate trajectory one side would actually start moving the wheels a few degrees before the other side. Both sides would then drive the same distance but the robot would be off-course right away, And then after any turns or reverses it just look worse.and result in complete misses of the hubs on the way ti a scoring zone. Best way to address this is really with the gyro so you can make turns more precise and drive a more accurate course. Teams used color sensor (gray scale mode) and lines last year to help identify position or even to follow and I only have one team trying to do something with lines this year but that is also an option to have the robot make adjustments on its own. But plan on lots of time experimenting with that and expect the need to tune the sensor for lighting conditions or to compensate for well used boards.
After 100+ hours spent on auto programs, I question whether a gyro or other sensor could be used quickly enough to be useful. If so, I would like to see a video of the run.
@turbodog the gyro can definitely be used quickly enough to improve your autonomous repeatability.
Last year the colour sensor was key for so many auto sorting designs as well. Bumper switches are good for helping your robot reset square against the field edge which is also very useful in long autonomous routines.
I would recommend looking into a PID controller in order to get more accurate results. The loop can be used to drive straight by calculating the difference in right and left encoders and adjusting accordingly. The controller can also be used to travel accurate distances to prevent over or undershooting.
I would recommend looking at this link: https://www.vexforum.com/t/a-pid-controller-in-robotc/20105
and this as well: https://www.vexforum.com/t/pid-help/35429/5
1 Like
This is IQ. You probably don’t need to be thinking about creating your own PID control!
Are you using time or encoders? If you use time it is very easy to have battery level sway you off course.
Reset to a known location and position during the run is a must. There is enough “slop” in the motor/gear/wheel/floor to put you out of position after 30 seconds.