And how do you propose doing this? PROS just uses the standard arm-none-eabi toolchain.
My teams do. The one time they didn’t was at a tournament where, go figure, they were still building the robot the morning of and wanted to get some kind of auton fast. And, as I said, they were able to understand it with a brief discussion, and edited it manually.
When my teams ask how to make an autonomous, I walk them through time-based auton. When they discover how inconsistent that is, I help them find ways to add sensors. When they find out that sensors don’t alter momentum, we move on to more advanced motor control. Thing is, I have taken the time to learn enough programming to do this for my team. Not all teams have access to a mentor that can program.
Rerun programs can give developing teams a starting point. The programs that come out of them are weak, and offer no advantage over teams that learn more advanced techniques. You wrote above that it would be easy to rerun program a cone and 20 point mogo score. That is just not true. I would be shocked if it worked more than 25% of the time. If students (and their mentors) see that kind of failure rate, how can they not want to figure out how to solve that problem?
I understand what you’re saying, and I entirely agree that a team not knowing how to program is bad, but you cannot just ban an algorithm. As much as I may disagree with it, the choice to disregard programming a full autonomous is just that- a choice. Many members in my organization have no idea how to program (which gets a bit annoying when they tell me to “turn off your PIDs” when the Cortex is off, but that’s besides the point), but are exceptional builders. What if I wasn’t there? Our team would have a well-built robot that can barely move. Sure they could grab a rerun autonomous from the internet and implement it, but at the end of the day it will still be inferior to most other autons (I doubt that it could beat 35 other teams in one tournament, but I’ll give you the benefit of the doubt).
If a team has a clawbot, they aren’t going to a competition to win, they are going to learn so they can win next time. This means they are open to learning. If a team goes to a tournament with 202Z’s ITZ bot, they are competing to win, and if a rerun auton causes them to lose, they will improve their program for next time, either by improving the rerun library, or by coding an auton manually.
Sure, a rerun auton can do okay in a competition, but it will not win. If a team wants to win, they will have to learn to program. If a team does not want to win, they are at the tournament to learn, in which case they will either eventually reach the point where rerun becomes a bottleneck, or they will learn to code on their own volition.
You can’t force people to learn if they don’t want to. If you ban rerun, they’ll just ask someone else to code their autonomous, or (as @Ashwin Gupta noted), they can use other people’s function like “move x inches” or “turn x degrees”. Actually, Aswin’s whole post was really good and basically says exactly what I’m trying to say, but in better words.
We should be encouraging teams to learn to program rather than imposing limitations on what you can or can’t use. What about the team that eventually makes a rerun autonomous that is just as accurate as a hand-coded one? Should they be forced to discard their hard work to punish someone else? Should we ban clawbots because they followed instructions to build it?
So, what you are saying is that your team chose to do extra building and used replay to quickly get an auton without having to actually write code … then competed against teams that had to build AND write code?
Again, it shouldn’t be all about winning.
So, you are now comparing using replay to asking someone else to code their autonomous for them. I agree with your comparison and don’t agree with either.
Again, you and I agree. From what I have seen, however, most (not all, but most) teams using replay use it to avoid programming - which is exactly why I have a problem with it.
First of all, if rerun was as easy to implement and as successful as you say, literally every team would have it. Rerun is HARD to get working consistently, that’s why the overwhelming majority hardcodes autonomous. As a programmer, and knowing many other programmers in my program, I really doubt anyone would implement programs that they didn’t understand. By allowing rerun, and even sharing code, you open up a whole other concept to people’s consideration. By banning rerun, you are limiting teams to only learn and care about standard function based programs.
Also, as others have mentioned, whats the difference between rerun and PID libraries, autonomous function libraries, gyro integration programs, etc. You don’t strictly need to understand how PID works to implement someone else’s code, but I’m sure every programmer that uses a PID library knows how PID works.
Lastly, what if someone spends all season programming their own rerun code, taking the time to carefully code and tune everything, and they learn at worlds that they can’t use that code… because why exactly? In what way is that fair?
The first team of mine to get it running did spend some time with it. The 2nd through 20th team spent VERY little time getting it running. As it is handed down year-to-year, there would also be very little time spent on it.
Answer a question of mine - what is wrong with encouraging all kids to manually program?
Let’s look at it a different way … because replay is available, there are many teams that are using it to avoid programming. I didn’t say all teams, but many. As it becomes more widely known, many more will as well.
Is it a good thing that teams are avoiding programming or not?
imo teams can do whatever they want. the point of vex is to do your own thing within the constraints of the rules.
I’m not sure that is “the point of vex”.
I just don’t see that here: https://www.vexrobotics.com/about-us/
I am not trying to make that point.
Getting frustrated about the rerun code creating a missed opportunity for students to learn more about programming is fair, but that is an issue for those students and their mentors to police. A new team is going to make the incorrect assessment that X points of auton bonus is not worth the steep learning curve of mastering PID motor control. They need to be instructed out of that incorrect assessment.
Getting frustrated about the fairness of team A manually coding and team B resorting to rerun is disconnected from the fact that basic, time-based rerun auton code is worse than anything manually coded. It records all the driving errors at one voltage and repeats them at another… its awful.
I feel like this thread has gotten unnecessarily heated. I very much respect your point of view. I am glad you are a strong advocate for the students you instruct in STEM through vex.
Whether it is awful or not, the fact is that it is done and done by a much larger segment than it should be done by. Putting this on mentors is very unrealistic.
I ask again - what is wrong encouraging teams to manually program?
Nothing wrong with encouraging manual programming; very unreasonable to say that rerun should not be allowed. The point of the game is to develop the best possible way to score the most points- not learn the most life lessons. Using your logic, it could be argued that teams shouldn’t be allowed to run ram autos in ITZ to block their opponents. It requires very little effort to do but can be extremely strategically advantageous. They’re not learning much by making ram autos, but that’s not the point. They’re accomplishing a task in the most efficient way possible and that’s what matters. If a team feels that rerun allows them to make their autonomous more efficiently, they have every reason to do so.
Actually, it kind of is …
Having re-read all this to make sure I did not miss some point I will risk summarizing your position as:
“Rerun code is so easy and effective that teams will never see the need to learn to manually code. This is terrible, as programming is a significant component of what Vex is aiming to teach.”
In terms of learning to program, it would be reasonable to see a normal progression of programming skill in vex to be:
- time-based auton (motor and wait statements)
- simple sensor auton (while sensor < value)
- advanced motor control (PID)
- functions, tasks, arrays, structs and all that fancy stuff
The reason a team would desire to move up that list is that the level they are currently on is not giving the results that they desire… that their autonomous is not effective. I and others have pointed out that rerun code is not effective, and is in fact less effective than level 1 above. One might say its level 0 on that scale. What is the value in rerun programming? Students get to see their robot move to code, discover that rerun code is awful, and move on.
You say you have seen highly effective rerun code. If that were the case, your position is quite compelling. I just do not believe it to be the case that rerun code is effective. Others in this thread have stated a similar opinion.
TP has a simple way to score in autonomous, which you and I agree was missing in ITZ. I would hope that new teams just start with manual code since it will be something like 3 actions with no turns. ITZ was at least 12 actions with 2 turns and a fairly long travel distance that included at least one obstacle – rather intimidating to a new team.
Edit: removed a confusing double negative
Regardless of how anyone feels about re-run code there is absolutely no reason to ban it because a) such a ban is completely unenforceable and b) it punishes teams who want to take the time to try to create such a program on their own. While I disagree with downloading and using re-run code written by someone else instead of writing your own autonomous, I’m completely against unenforceable rules and that’s all that a ban on this style of code would be.
You got it.
I never said it was highly effective. I have only said that I have seen MANY teams use it.
crooked dog look If that were the case, why in the world are we even having this conversation? If there was no value to anyone, no one would want to use it. Obviously, there is value to many - and many in this thread - as they do not share my opinion. The value, however, is that they get to shortcut manually programming their robot.
I would agree with that … to an extent. But I contend that there would be ways that VCS, RobotMesh Studio, PROS, etc. could prohibit this - or make it so cumbersome that no one would use it.
Instead of trying to prohibit rerun, what do you think about working on better tools so teams can make more complex (non-rerun) autonomous programs easier?