Simple Autonomous Programs

[Kevin Phan]

Having an autonomous program is something that every team should strive to complete. Many teams still do not have the necessary support they need to actually create an autonomous that benefits their strategy. I worked with teams who don't have any programmers. It's up to the drive of the team and the people in charge of programming the robot. If there is not a programmer on the team, someone on the team has to take a charge on making it a priority. They could ask for assistance from other teams and take some notes on how to go about programming their robot the next year. Every programmer has their flavor of programming language and different logic. Number 1 thing I see in new programmers or other programmers trying to adapt to a different logic is anger. I get that you are having a hard time understanding or that it should work because you went through every combination. It's reasonable to be frustrated, but in a competition, you have to keep your head straight and stay calm. An entire 5 minutes of this "should have worked" is not the answer.
I understand that making a robot is a team's first priority, but a robot without good code is just as good as a paperweight. You can make the argument to make your drivers practice more and more, but in the end if your drivers have to control every single piece of your robot, there will be a slip of a finger and everything falls apart. It's a collaborative effort between the mechanical, electrical and programming teams to understand exactly how the robot should operate and what does its peak performance look like.
Programmers are the ones who are suppose to take the logic behind the robot and come up with its behaviors. Finding patterns in the strategies and taking those patterns and automate them so that it can efficiently complete its task. You can continue to make beautiful mechanical designs, but your robot will not be better than a team that can develop a robust program that compliments their alliance's strategy. The controls aspect is also important, your drivers must be able to fine tune themselves to the controls implemented to the robot. Sometimes the program might not be intuitive and must be rethought from the ground up.
I'm currently in my freshman in college and I only have time to volunteer at one event as a CSA. CSAs are your best friend at a competition for when you want to implement a simple auto or a second opinion in your program or new controls. Pay attention to the advice they give you, it might help you implement something for the next competition. Ask them if you can contact them after the competition to ask several follow up questions. I was the head programmer for my team last year and I really never had to change a major component in code. The most I did was increase distance or time. I usually ran off to aid some team who's having a real hard time with programming. Number 1 thing to do when making an autonomous, make a plan. Psudocode really helps you get your logic out there. Show it to your team and ask them for their opinions. It's better to develop logic as a group rather than going by yourself. A team that has a sub team of programmers is a privileged team, there might be programming classes in one school, but there is no real standard to the quality of the class. Many talented programmers are off in the industry and only some of them mentor a frc team.
Handing an autonomous to a team will only benefit them in the short term, they need something that will last for the existence for the team. At some point this idea of handing autonomous will then morph into the entire controls of a robot and the rookie teams that takes that are at risk of becoming dependent on it. When the code stops being circulated this short term plan will collapse and bring the level of the competition down. Every team operates differently and you can't change that, they might not have the resources to develop their robot as well as another team. That is just the hard truth and it's something that needs to be addressed. No matter how many seminars, workshops, tutorials there are, teams are still going to slip through the cracks with no autonomous and that's just the sad fact. Teams are not aware of these resources, and when they do, they have to sink time into it. Many teams only operate the six weeks of build season and after that, they don't make much of an effort to do more or learn more.
In the end the only answer to this is the team itself. They are responsible with how they conduct their own program. All you can do is hand them the resources and hope that they take it to heart and keep on trying to improve.