So I’ve noticed that there are lots of robots that don’t move at all during autonomous and its more important this year than others that all robots have an autonomous, due to points coming in sets. So, is it against the rules to distribute simple autonomous programs? Any team that doesn’t have an autonomous can just load this onto their robot, that way no one lets the alliance down.
Because the only thing every robot has in common is wheels, the autonomous would only be driving forward, but position the robot behind a yellow tote and you can get the robot set and tote set.
Our team’s Rookie year, our cRIO got fried. We were lucky enough to have a borrowed one; but our Electrical/Programming mentor that year wasn’t available at the regional event. We barely had any students that could program… So, even with a borrowed cRIO, we were still pretty much dead in the water… Then another team came over and spend almost the entire Thursday rewriting our program for us. We were soooo extremely grateful.
I really think a lot of teams would be grateful to have something extra for their robot.
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.
With no sprawl limits, I expect a few exceptions to this, at least if you only mean drive wheels.
Also, in order for this to work, you would need to meet all of the languages and models (sample, iterative, command-based) and convince the other teams that your code is not going to interfere with theirs. I’m not sure it’s possible to find something that will work in every case where it’s physically possible and never break the original code; some teams do ***weird ***things with their code.
I think this is a great idea…Sometimes if a new programmer sees a working program before they begin to write their own, they may understand programming as a whole, better. Its like showing someone how to do something and them doing it on their own. Programming is daunting. If someone doesn’t understand the basics going into day 1, it will be a tough, tough season. I know it was tough for me when I was first learning. But thankfully I saw examples and learned that way. Without those examples, it would’ve been tougher I’m sure.
I greatly agree with the sharing of code with teams that need it. We have a “Programming Trauma Kit” that comes with sample code for a basic robot using things from the kit of parts. It has code for a drive train, an Xbox controller class (for them to more easily read axises, bumpers, and the D-Pad), two Talons set up to use for the drive train and two to use for manipulators/other things, two joysticks (standard and Xbox), and a “drive forward” autonomous.
I’ve actually said this before at competition, but, people prefer not to have a stranger touch their programming. I saw quite a few teams this year that were amazing last year not even have an autonomous that worked at Hatboro-Horsham and I was pretty confused considering simply programming a robot set is trivially simple. I think the hardest part of this would be having to overcome their pride, not their robot.
As a side note: the world of tele-operated robotics is shrinking and the world of autonomous robotics is increasing.
Something I have thoroughly enjoyed beyond first is the purely autonomous robot challenges that I am able to compete in now. It seems more fitting for the type of world we are headed to.
Still waiting for first to make autonomous mode game deciders that isn’t necessarily what it can do in the first second (RC bin grabbers). One can only dream I suppose.
This year would be an ideal year to implement a minute long autonomous mode too but if no teams have an active autonomous for that duration then everyone would just sit there.
Anyways, I think it comes down to more pride than ability, as others have mentioned.
We tried, and the other team did not accept our offer. We even grabbed one of our mentors who knew some Java, but had never programmed a robot in it, but was willing to try. The other team on our alliance was the only one that didn’t move, they were a rookie team, and it would have boosted their average by a decent amount. Some teams may just not accept it out of pride or something.
In theory, easy. In practice, a little more difficult.
First, there are 3 programming platforms in use: Labview, C++, and Java. So, you have to know how to program in the platform being used by that team.
Second is how the team has implemented drive motor control. If the routine can be easily called, then it is not that difficult to drive forward for x milliseconds.
I have thought about having an example on a flash drive of auto code in LabView, C++ and Java to go off and writing it for alliance members that don’t have it.
A simple drive code for (X) seconds at 0.5 speed would be easy enough to do in pre-match strategy. However I don’t know if I’d give all the robots at the regional auto code, but I love the GP there
but if no teams have an active autonomous for that duration then everyone would just sit there.