I have been writing my skills autonomous, and it seems to be very inconsistent. I am using a gyroscope which I make sure to calibrate, and I am using the smart motor. Theoretically, these will make me more precise, but for some reason, my robot always does something unexpected or is otherwise inconsistent. Is there anything anyone can think of that would be causing this? (And yes, I know that the gyro is always a little bit off, but I’ve made it work in the past, without issue. All of my issues are recent, as in they seemed to spontaneously appear.)
The main problem is you aren’t accounting for momentum (or at least you haven’t specified it). It’s not as simple as robot -> target //full speed
and if robot @ target //stop
(pseudocode obviously) This doesn’t work because of momentum, or the robot’s tendancy to keep moving after it has reached the target. To account for this, many teams use PID to variably set the motor speed in proportion to how close the robot is to the target point. The slower the robot is near the target, the less momentum the robot has and higher the probability of landing on the target accurately.
Now, if you are using PID (or some kind of motion algorithm) then you should’ve stated that initially. In which case, I would assume your gains are off. Simply using the data returned by the sensors isn’t useful if you aren’t using that data effectively.
Lastly, it might not be a software problem at all. Often times, mechanical issues get in the way of repeatibility which is why your systems should be robustly designed.
In any case, you need to be more clear about what might be causing the issue
How accurately can my robot drive straight? For example, make it drive forward 4 feet and measure how much it drifts from left/right as well as how far from 4 feet it actually moves
How accurately can my robot turn? If I tell it to turn 360 degrees, how many does it actually turn? What if I tell it to turn 90?
Not to be nitpicky, but that’s inertia. Great response, but just wanted to clarify
Guess I should also be clear lol. It is momentum that you’re fighting. By using a PID controller you’re increasing the time that the robot accelerates to a stop so that less force must be applied. High force stops (sudden stops) are prone to jerkiness and slippage of the wheels between the mat. The decrease in momentum is the same by providing an equal impulse (net force applied x time) but the increased time reduces force needed. And this overall reduces inconsistencies
Also, robots will always have some degree of variability to their movements. Assess how much variability can your robot tolerate? Are there physical changes you can make to your robot to increase the amount of variability it can tolerate?
Often physical changes are simpler and more reliable to make than in software. Adding a physical stop to an arm, for example, is quicker, simpler and more reliable than coding a software stop.
This seems like a great opportunity for analysis that can go into your engineering notebook. Try the Toyota “5 Whys” way - Five whys - Wikipedia when you observe failures/anomalies.
When you talk to a judge, saying your auton randomly blows up will not be nearly as impressionable as: When we started, the auton worked really well, then it started not working. We looked into it and determined X, Y, Z. We identified A, B, C as ways to improve it, but we only had time to do C
The problems are beyond just momentum though. Sometimes it will simply skip portions of the code, especially the parts that use the gyroscope (what I mean by this is that I will tell it to turn left but it will ignore me and go straight instead). In other cases, the code that scored 60 points a week ago suddenly scores no points.
Are you running the right program number with the expected code version?
Some movement/turn functions are “non-blocking”, which means program control returns immediately after the line is called. This can be used to do multiple movements at once. Are you sure that the call to the turn is the “blocking” version?
Some Vex programming environments allow the programmer to set a timeout for a movement. Is your program using this functionality?
Is the gyroscope staying connected the whole time?
Is the gyroscope’s value constant when the robot is at rest?
Can you record/display the gyro heading before and after the “turn”?
I know it can be frustrating, but things in robotics happen for reasons. The easy way out is to curse RNGesus; the way of the engineer is to investigate why something unexpected happens
One suggestion I might have would be to see if you can open the devices menu and select the gyro while the program is running. This should display real-time data of the gyro and help you debug perhaps. Posting your code might help too
One suggestion I have is to check the battery life right before each run. My 3 ball auton. was not scoring at all; I changed my battery and my three ball became consistent. I’d say after a success write down the battery life, or just make sure it is above 2 bars and you should be good.
This should pretty much be wrong with V5. For cortex battery power affected autonomous programs far more. Plenty of people with consistent autonomous algorithms like PIDs and other motor controllers have been able to get consistent runs on lower battery powers. My team and the others at my school just run our batteries to about 20%, and this has never caused an issue.
Do you use something that is not based on encoders?