Is anyone planning to use sensors on their robot, or just hard-coding it to intake the triballs (acorns…?) at the predetermined locations? What are the benefits and drawbacks for each?
I was thinking of using sensors, but they seem unnecessary.
Is anyone planning to use sensors on their robot, or just hard-coding it to intake the triballs (acorns…?) at the predetermined locations? What are the benefits and drawbacks for each?
I was thinking of using sensors, but they seem unnecessary.
Spend a day blindfolded and then come back and tell me how sensors are unnecessary…
Seriously?
If you hard-code values then you can get an autonomous done really quickly and without many problems coming up in the code. Hard-coding values can also be relatively accurate if your build is really good (eg. both sides of the chassis have an equal amount of friction).
The problem with hard-coding values though is that the robot can’t autocorrect it’s heading and position like it can with a PID and odometry. Plus, if your robot build isn’t the best then the robot may start to drift off to one side and won’t have the ability to fix itself.
Personally, I’m going to use odometry and PID (with optical shaft encoders and an inertial sensor)) because they are really great programming techniques that can make my autonomous more versatile and less finicky. In some cases if you add in things like pure pursuit then your autonomous can be really efficient because then the robot can follow curves and not have to go in straight lines making your autonomous much faster.
The only problem that I’ve faced with odometry and PID is tuning. In odometry you have to tune things like the distance of the wheels from the center of the robot, and in PID you have to tune certain variables to make sure your robot doesn’t overshoot or undershoot the target, and this type of stuff takes a lot of time.
Overall, the type of programming technique you use will depend on your experience and the amount of time you have. If you have about a month or two and know how to code more advanced algorithms, then by all means go ahead and use sensors, because if they are used right, then they can prove to be a very important tool to your autonomous. On the other hand, if you had only lets say 2 weeks, then you should definitely just use hard-coded values.
Pascal is right; you need sensors on your robot, but I think the question is meant to be more nuanced than a yes or no. Of course you need sensors on your drive (and an imu for heading). These let you make accurate driving movements and turns in order to “hard-code it” to intake the triballs at predetermined locations. You can use EZ Template for PROS or JAR Template for VexCode to do just that in a few hours.
But I think this question is about the vision sensor. In match auto, it’s useless, but in programming skills, most robots will end up with a multitude of (about 44) triballs in arbitrary positions on the opposite side of the field. And when this happens, I think the teams with vision sensors will “see” the most success. Making the algorithm that connects the vision sensor to the drive is up to you.
I apologize for not being nuanced - human senses allow one to adapt to our surrounding, same for robots. If applied correctly, sensors will allow the robot to adapt in autonomous portion of competition and ultimately simplify a driver’s task during a competition.
I advise all teams to understand opportunities afforded by the myriad of sensors in the V5 ecosystem.
The benefits of sensors is that it’s easier to code because the sensors pick up where everything is(vision)
gives more accurate values for turns (gyro)
Their are no down sides to sensors it’s easier to code because you don’t have to guess and check every singe time. Also every field is different so turning is different on every field so sensors allow you to be sure that you code is going to work 90% of the time.
For every robot I would recommend a vision sensor and gyro sensor.