Quote:
Originally Posted by trycatch
if I'm understanding right, SampleRobot is much more "write out what you want it to do in what order,"
|
This is precisely the problem with SampleRobot.

SampleRobot tends to encourage creation of loops and other constructs that don't allow the robot to do more than one thing at a time, or can potentially loop infinitely.
Constructs such as this: Imagine a naive implementation of making an arm move:
Code:
while arm.isNotInPosition():
arm.moveToPosition()
As I'm sure you're aware, there are several obvious problems with this:
- The arm may never be in position (the sensor broke), so your robot keeps moving the arm and does nothing else
- The robot can't drive while this loop is executing
By using state-based techniques that IterativeRobot encourages, you can avoid these problems.
Quote:
|
I have mixed feelings about CommandBased - as a programmer (who's made a few robots), it seems VERY overly complex, especially for brand new programmers, to require entirely separate classes for every single thing you want the robot to do, especially when every command class is a single function.
|
I dislike Command-based for the same reason, but I've heard RobotBuilder can take the edge off this.
Quote:
|
if using SampleRobot, do I have to check periodically if the robot has been disabled (IsAutonomous() && IsEnabled()), or will this be caught in Timer.Delay() pauses? I've mentored for FTC previously, and the autonomous thread would be killed if you disabled it when the main thread got control for a bit, i.e., when you delayed the Autonomous thread for a few milliseconds at least.
|
In FRC there is no thread killing. If you never return from autonomous, you will never return from autonomous. Timer.delay only sleeps, it does no extra checking.
I tend to encourage an IterativeRobot/asynchronous "style" of programming, though I personally don't like IterativeRobot itself because I would rather have a stable loop period instead of looping when the DS packet arrives.