Inconsistent autonomous

Programming Support
1

An open letter to REC

Dear REC foundation,

I am a student who has been doing VEX IQ for 3 years, and EDR for one. I have always enjoyed participating in VEX and I really like the way it is set up to encourage students to improve problem-solving skills, teamwork, and STEM knowledge. I have qualified for the worlds competition twice, once in 2018 and once in 2020, the latter being canceled due to COVID, so unfortunately I was not able to attend. I also attended the 2019 worlds competition as a volunteer, as well as to cheer on my sister who qualified that year.

However, there is one major flaw that has bugged me for all three years of my VEX involvement, and all my teammates and coaches share this frustration. It has discouraged me and many of my peers from indulging in STEM, especially on the programming side. The programs are extremely inconsistent, random motor errors occur that get fixed by something completely unrelated, like changing the battery, and the user interface, in general, is extremely buggy. I understand that it is difficult to create a perfect system, and I am not asking for one, just that you at least attempt to create a more consistent, less buggy program. Other teams and coaches that I have discussed this with have also expressed their struggles with the inconsistencies of the program, especially autonomous.

I understand that there are many teams who are able to achieve high autonomous scores, however I do believe that they are frustrated with it as well, and It takes them a lot longer than it should with their level of coding expertise. This is a request from not just me, but my entire team and many others as well. Please fix the format or the platform. If you want to test our programming skills then have us write virtual world programs where a result can be repeatable - like how real-world regular software works. I understand that there are outside interfering factors that would occur in the real world, such as inertia, but it is clear that these aren’t the only things causing these inconsistencies. In the current program, the autonomous is purely luck-based. Obviously, students still need to be able to code and have a basic foundation of programming, however, with the exception of a few teams who spend almost all of their time and efforts in autonomous, all teams rely on luck in competitions hoping that their autonomous will work. There have been multiple instances where the autonomous code worked consistently at least 10 times in a row, and then we move the robot to the other field, and it doesn’t work a single time. All the coaches joke about the students constantly saying “but this just worked yesterday!”, but it is a real issue that discourages students from pursuing coding.

As a student with personal experiences in the struggles of VEX autonomous, I am requesting that the REC Foundation please try to make their system more reliable and similar to the real world because the way it is now, it is doing the biggest disservice to eager students looking to go into STEM, as they are discouraged from pursuing coding because of their bad experiences with it, and given that all of the participants in VEX are students, some as young as 6 years old, this can really impact their views on coding, and discourage STEM. In short, VEX autonomous and overall software is unreliable and inconsistent, and should be fixed.

3 Likes
2

I do agree that inconsistent autonomouses across different fields is frustrating, but quite frankly, I view it as another challenge to overcome.

And to be honest, in engineering, you will not always have what you want. Limitations will force you to work on a tight schedule, or with suboptimal parts, and I feel like getting things to work under imperfect conditions is part of the experience.

14 Likes
3

You haven’t mentioned a single specific issue with “the system” that you would like resolved, only implied that you feel inconsistent programs are someone’s fault other than your own. Are you talking about the field controller, the motors, the sensors, the programming environment?

This is 100% untrue. Autonomous programming is all about using sensors to make sure that your program doesn’t rely on luck, which is entirely possible to do.

That’s not how real-world software works at at all. Real world software runs on real-world hardware, with real-world outside factors and inconsistencies to be accounted for

tldr:
At the risk of sounding a bit rude, get good. Chances are you’re not doing everything you can to ensure a consistent program.

26 Likes
4

Engineering is all about practicality. Don’t make autos that have a small margin for error and then complain about the imperfect system given to you. I had to back down on so many auto routes because I acknowledged they were too ambitious. I got 3rd in MD prog skills (130ish in world) for TT by only stacking 5 and realigning with the wall at least 6 times.

Maybe the autonomous system in this practical competition rewards consistent builds and smart routing more than complex programming, but that’s just how it is. Like Joey said, get good I guess.

16 Likes
5

bro what

the real world is rife with inconsistencies. you’re never going to have a perfect system

12 Likes
6

My troll detector is going off hard here - brand new account, pretty nonsensical post, team number that doesn’t exist…

16 Likes
7

image
image
sus

4 Likes
8

Looked it up, says their a registered IQ team.
https://www.robotevents.com/teams/VIQC/1696Z

3 Likes
9

if you’re experiencing inconsistencies in your robot’s autonomous behavior, that is not the fault of vex’s software, but a fault of your own. There are a plethora of reasons why you might be getting varying and inconsistent results, but vex software is not one of them. If this is in fact a legitimate post and not just a troll, I would suggest a different attitude. Autonomous not consistent? instead of blaming vex software, instead think to yourself, how can I make it more consistent? Better programming, better build, use sensors, reduce friction, there are many ways to improve a robot’s consistency during the autonomous period, and this forum is a great place to learn those techniques. But this isn’t a place to complain to recf (which by the way didn’t write the software used to control motors) about your inconsistent auton.

8 Likes
10

I agree it is suspicious, but the number is an iq team that qualified for worlds last year so he is probably legit. I agree that vex system isn’t the best. I also agree the programming is a challenge. After all, if everyone could just input distances using vex’s drive train then almost everyone could have a home row and there would be no fun.

What I do really dislike is things like white screens, blown ports, and field tolerances. I feel like vex should look into making v6 sturdier. I especially dislike the fact that the tolerances in a change up goal can make or break you. On the lowest end it can take a second to pull a ball out, and on the highest end scored balls can fall out the bottom.

Tl;dr: Yes the system has its flaws, but everyone is at the same disadvantage.

5 Likes
11

Um…

That’s not how real world software works. Sure it might be close to perfect when things are released to the public, but any robotics/programming project requires long long hours of troubleshooting/debugging. TBH vex is more “real-world” than

I would also have to disagree here. While there is a certain degree of luck involved, teams with odomedry/PID programs can to much to mitigate that.

TL;DR I respectfully disagree

4 Likes
12

i have. ive been trying for three years to no avail. we’ve tried different progams, different designs, different brains, batteries, and motor. nothing worked. the point of this isn’t to complain that it’s too hard, but to bring to attention that the way it’s set up is actually discouraging students from pursuing coding as a career, especially in iq because a majority of the students who participate are young and impressionable.

13

I would argue the opposite. It encourages students to strive for a consistent auton, rather than being able to just slap on some simple motor commands and get a 100% consistent auton (which is impossible by the way).

well the reason why none of this worked is because it isn’t the fault of the brains, the batteries, and the motors. auton inconsistencies are usually due to the build of the robot, as well as the lack of sensors and smart coding to mitigate variances in robot behavior.

For example, using time based motor commands will not give you reliable results because varying levels of friction, traction, load, and other factors will cause your robot to travel different distances every time. Using spinFor commands with vex’s built in motor PID is a definite step up, which will give much more accurate results. however, factors such as friction, wheel slipping, and varying load on the robot will still cause inconsistencies. Using a custom control function, alongside reliable tracking wheels to get nearly perfectly reliable sensor values, you can achieve movements that will happen nearly exactly the same way every time you run them.

the build of your robot is also an incredibly important factor. if your robot is sloppy and janky, it will behave with inconsistency regardless of how good your code is. The code can only be as consistent as the robot.

It’s got nothing to do with vex’s software, and everything to do with your ability as a roboteer.

and it’s not like it takes a ton of programming skill to have a consistent autonomous, it really doesn’t. You can get a decently consistent simple route using the built-in motor PID and decent robot build. But it takes advanced skill to constantly perform advanced auton tasks, and that is how it should, and will always be.

8 Likes
14

can you… expand on this?

4 Likes
15

I feel like that inconsistency is good for the game for the most part. Different fields with different amounts of friction, robots having the center of gravity off, etc, makes it so teams that use no sensors or only the motor encoders are encouraged to try different methods, research different algorithms and learn about different sensors.

It is very frustrating having your auto work one day and not work at all another, and that is a problem I had for most of my time in vex. But with every new sensor, I added the autos worked more and more consistently.

Anyway, if I have one piece of advice for any of you auto makers,
S tier: sonar, button, limit, encoder (accurate, reliable)
A tier: vision,optical, inertial(sometimes bugs out,vision/optical also have a notable delay)
F tier: old gyro, any accelerometer,
idk about the new rotation/distance sensor.

5 Likes
16

It does exactly what you tell it to. If you tell the motor to spin at 100% speed and then stop on a dime once the target is reached, then of course it’s going to be inconsistent. The odds of all those different hardware components failing simultaneously is beyond unlikely.

TL;DR: The engineers that designed the v5 system have teamed up with our nemesis Murphy to ensure the hardware isn’t the root of the vast majority of issues.

14 Likes
17

It seems like a lot of the problems brought up in this thread are mostly due to problems like wheel slippage, and just the absence of sensors. But there are some problems that I’ve noticed that can be annoying.

For example, sometimes at tournaments during autonomous, the robot will start the first 1 or 2 seconds of autonomous doing something it’s not programmed to do, such as turning when it’s programmed to drive forward. This happened during Tower Takeover and during Change Up, despite the fact that I’ve switched to PROS and use completely different motion algorithms since last season. It only happens on competition fields and never during practice, and it’s somewhat annoying.

This is an example of the kind of issue that should probably be addressed, but something like having tiles with different friction, or goals of different tightness should already be accounted for in the process of building, designing, and programming robots.

1 Like
18

yeah, i’m begining to think his problem is with his designs’ coherence with physics, and not with vex’s software

2 Likes
19

To be frank:

If your code doesn’t work, your first question should be “How can I make my program more consistent?” and not “How can vex make their software easier for me?”

9 Likes
20

If you want a better and more consistent autonomous, then you’ll have to put effort into making it better. The whole goal of programming in vrc is to let you learn programming concepts at your own pace. The more you learn, the better the autonomous. There’s nothing inherently flawed about the v5 system, you just have to make a better autonomous. If you didn’t need to improve to compete with the best teams, then there’s no reason to bother with programming concepts like pid or position tracking. I know that if anyone puts time into their code, then it will show just as well as if they spent that time working on the notebook or upgrading the robot. Tl;dr: Over time your autonomous get better and better, but only if you put in the work. It’s what distinguishes teams that do amazing from the clawbots. Always remember that the clawbots of one year are defining the meta a few years down the line

1 Like