Quote:
Originally Posted by Ether
What would you consider to be the top 3 reasons, and why?
|
Let me first say that I'm sure there's many FRC teams to whom much of this wouldn't apply, and who could create equivalent or superior solutions on their own. For most teams though, it's analogous to using the kitbot on steroids vs a homebrew chassis, and using a standard model with modifications to fit specific needs will ultimately work better than developing a custom solution, while reducing overhead and allowing you to focus on the stuff that matters most.
1. Structure. All the code pertaining to the Operator Interface goes in one file. All the code pertaining to the Drivetrain goes in another. Newer programmers tend to find smaller blocks more easily digestible and less intimidating than monolithic chunks of code, ime.
2. Extensibility. While it takes more time, effort, and complexity to get the basic functions of the robot set up than it does with Iterative, it's generally faster to add new functions to the robot once that's done. Once you have the commands written, it could literally take less than an hour to write a fully functional autonomous program by stringing them together, whilst using parts of those same routines in teleop as well.
3. Because that's the direction FRC programming seems to be heading in, and the documentation is becoming increasingly tailored for it. Not an issue for some teams with lots of older code to look back at, or teams with great programming mentors, or students with lots of programming experience. Many newer teams don't have any of those, and and for them the best-documented solution is probably the best one.