Next season will be my third year competing in vex. I am a one-man team and I’ve always struggled with auton. For my two previous season, my auton code was very simple and it was just based on time without any sensors. This season I’m trying to up my game in auton and create a more effective and consistent auton code. I’ve hear about PID a lot but I don’t seem to understand how it works and I’m also trying to sensors this year.
4 Likes
I would strongly recommend getting away from time-based autons. They are much less reliable than other control methods. If you’re looking for a simple way to do auton (a level below PID), use rotations of the motors instead of time. You could even make functions to tell the robot to drive certain distances with minimal math involved.
If you want to get more advanced, PID control is a great way to improve consistiency (it is a lot more effort because you have to tune it). A very common link here on the forums is to George Gillard’s document on PID control: http://georgegillard.com/documents/2-introduction-to-pid-controllers
Don’t be scared by the terms “integral” and “derivative”. There’s not any actual calculus involved.
And if you want to go even more advanced than that, you could implement tracking wheels and odometry so that your robot can self-correct. Team 5225A made a great document detailing their process: http://thepilons.ca/wp-content/uploads/2018/10/Tracking.pdf
Additionally, I recommend getting a V5 interial sensor if you can. It helped my robot make very accurate turns this year.
9 Likes
The QUEEN VEXU team has a youtube channel with a bunch of videos that cover different programming topics. Here is a link to one of their videos about PID.
11 Likes
I remember my programming mentor had me progress kind of like this:
- time based auton
- rotation based
- distance based (and degree based turns)
- distance based w/ P control
- distance based w/ PID
It was a nice progression for me and it helped me kind of ease into it, especially because it was completely foreign. We never had odometry or the intertial sensor, but I’m sure that would that would have been next.
My main point is to take it step by step, adding one layer of complexity at a time as you go and you’ll get there eventually.
10 Likes
I use rotations. Time based auton is much more inconsistent than the others. Also to make sure your auton is consistent you need a well built robot. If your robot is square and consistent then your autonomous should be consistent.
This is always over looked by so many people. It doesn’t mean you’re auton will be consistent by default, but it will give you a much easier time tuning constants and other functions because other unwanted variables (such as excessive friction within the rotational joints of the robot) are virtually eliminated
6 Likes
What does this mean? Does it mean that the wheels are in a square formation instead of rectangle?
1 Like
No it means everything is straight not twisted
1 Like
I’ve actually had issues with the past 2 seasons where my robot would not drive straight and slightly turn one direction. So i had to position my robot at a small angle to make sure that auton would work properly.
There is a software solution to this issue if you’re interested in that, but yeah it is an imbalance in the friction on the axles on each side of the chassis. Build quality mitigates it, but I think it’s impossible to completely void a robot of mechanical defects (mainly because of manufacturing error, but also because of the unpredictability of physics).
@Noah10851B I think @64811AOverHeat meant that every component on the robot should be parallel and symmetrical relative to each other.
9 Likes
Ok. That makes more sense. Thanks!
1 Like
It may be that some of the axles are bent because they have been in use for about 9 seasons. I will try to use brand new axles for my next robot.
I just remembered that my first robot had that issue because i had 6-wheel drive where the middle wheels are not position exactly the same holes on each side. I thought it would be fine because i didn’t have enough time to fix it, now thinking back that may have been the problem.
That could be a factor of many, but I can guarantee this “veering” is an issue for all robots which is only slightly mitigated by better build quality. The software for it requires real time feedback on the desired state of the robot (both in terms of orientation and linear displacement). This is true for any system with multiple degrees of freedom. (take it with a grain of salt though)
3 Likes
This touches a lot of areas in computer science and robotics. The real world is difficult, not only are you working with a lot of factors that add noise to the system, but it’s a sensitive problem. Technically this is between a soft and hard realtime problem, depending on the definition (I have seen hard realtime described as a situation where failure of the system will cause harm or death). In general however, once the buzzer rings, you don’t get do-overs, it’s a life or death situation in terms of match outcome.
So, welcome to the real world! It’s a scary place. You are beginning to embark into the frontier of - things that are not deterministic but we are going to attempt to apply conventionally deterministic computer science concepts to in order to solve interesting problems.
A place where A + B = A+B+Noise.
Go look into fuzzy logic, machine learning, signal processing, kalman filters, control theory, SLAM, sensor fusion and two PhD’s later your robot will still occasionally fail to do basic things, even if it gets it right 99.5% of the time.
Now to be clear, a lot of good work can be done with autonomous routines in VEX without having to go down the rabbit hole completely. You can do a lot with PID (which isn’t that hard to learn, I did it in HS), and a few solid sensors. Use the lines on the field, use the bump sensors, use any orientation sensors you have available, etc. A lot can be done by averaging values, counting encoder ticks, making some simple assumptions, etc. You have to be clever to avoid the PhD level maths…
6 Likes
High build quality leads to consistency. You need to have a solid foundation. Does your robot drive straight when programmed? E.g. can it drive 6 feet with only x inches variance between runs?
Start simple. Remember Gall’s Law:
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
Remember that change itself introduces new forms of failure. TEST!
5 Likes
This is one of my favorite videos to show budding robo-teers:
The DARPA challenge from a number of years ago. These were built by a number of large and well-funded teams.
Failure is always an option, and, in fact, may be the most likely outcome. Learn from failures, don’t be afraid of them. What a sad life to lead to have never failed.
6 Likes
My robot last season could not drive straight and i ran out of time so i ended up programming a one cube auton.
Also at my school we only meet for 35 minutes during lunch and I am also a one man team because people at my school don’t seem interested in robotics.
As I have friends who worked on the 2 teams I feel obligated to point out.
The joint WPI/CMU team was the only team to attempt every task and never fall over.
And the CMU (offsite research group attached to CMU, its complicated) team was the only robot to fall over and get back up itself.
10 Likes