The last competition, we had to adjust all the autonomous after arriving at the event. Before we left it was perfect. We didn’t change anything at all.
We are at the world competition. We tested our autonomous 3 times, it was perfect. Then in the skills test, it didn’t score a single one. Any ideas?
I attached our autonomous program to the post.
round up world super no corect.zip (82.6 KB)
I’m going to guess it has to do with the new rings. All of us have been playing with used rings (ours are almost 11 months old). All of the fields have brand new rings, super slick fresh out of the box. Rather than being able to push a stack, they squirt everywhere.
No suggestions on what to do about that.
It’s hard for me to give a good answer as I can’t determine what you experienced when your autonomous ‘failed to score’ what operation failed? but I was curious so I browsed through your code and If I am reading it correctly you seem to use timing (wait) statements to get you from one position to the next. I expect they are susceptible to voltage changes in the battery. I prefer to have a sensor and take readings from and drive the motor to reduce error until the actual position = desired position.
Did you Autonomous program run to completion just miss all the goals? over shoot undershoot?
Cheers Kb
If your code is based on wait statements, slight changes in voltage (due to a change in battery) can cause a massive affect on the field. Even if a slight change in batter voltage throws your turning off by a few degrees each time, after several turns you will end up pointing the wrong direction entirely. In the future, try using sensors to help aid your autonomous accuracy. If you are looking for an excellent resource for programming help, take a look at the code for the robot which one programming skills this year (and also robot skills), 1103. Best of luck!
The wait blocks are to slow down the while loops. I had some trouble with variables not being updated in time. I do use sensors. They are just mostly programed in function blocks. I think my problems are in the “Main_drive_straght” and other like functions. This function makes it so that one wheel does not spin faster than the other. After the while loop in “Main_drive_back” the robot checks how far it has coasted. Then in the next step of the program the robot drives back the where it should have stopped. I started to apply this to the other Main_drives but did not test them yet.
After this thread I am going to make my own account.
jjpProgrammer
“Perfect” vs “Didn’t score” is not an actionable description.
The code shows a variety of coding styles, so you developed as you wrote, great! It looks like you learned part way through that you can pass parameters to a subroutine (user routine), so all your drive_slow/fast/stop/backwards could have used a single routine with one parameter for speed.
Another step would be to add parameter for turning.
Another step would be to do some simple PID or at least ramp up, ramp down your motors, rather than just doing a simple limit check, and then re-correct.
And there is still some open-loop “timed driving”, your step 8 for example.
Titan’s 1103 code has many of these next steps, so it would be a good example of what can be done (see that thread)
He has routines with parameters to allow one STEP to be :
"drive straight forward until cross the line, or 1000 ticks max, or 5 seconds max, while setting target arm position to be ‘high’ "
Jordan (LegoMindstormManiac) has similar code for RobotC, but he hasn’t posted it.
Thanks for your help everyone!
Oops, I do need to get to this – doing that right now.
~Jordan