IterativeRobot, CommandRobot, or SampleRobot for brand new programmers?

[PopeRyanI]

Originally Posted by trycatch

Hello all

I'm a programming mentor for a team with a lot of students with very, very little programming experience at all. To me, it looks clear that SampleRobot is by far the most straight forward way to go - honestly, if I'm understanding right, SampleRobot is much more "write out what you want it to do in what order," as opposed to having to keep track of a state machine in Iterative.
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. SampleRobot really seems like the most straightforward and traditional way.

Hello, my team uses SampleRobot and I definitely agree that I think it is a lot more intuitive than Iterative. Being able to control how frequently it looped rather than waiting for a packet was more logical for our programmers. We never really got involved with CommandBased because we did not like all of the boilerplate code and thought that it was rather confusing with so many different classes.

But I do have a couple of quick questions - 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.

We have never had problems with our autonomous ever accidentally being disabled and, as a result, have not had to check during auto if the robot is enabled. This includes running Wait() to pause the robot (for C++, Timer.delay() for Java is comparable). In addition, we found that SampleRobot made more sense in this instance because running autonomous code every 20 ms or so did not seem to make sense.

The WPILIB documentation makes it sound like the SampleRobot class is a lot harder to use, but I don't really understand why. What am I missing?

Honestly, the only part that might be a little confusing for new programmers is handling the looping within SampleRobot, but with some experience, I think it is more straight forward.

In case it helps out, here is my team's code for this past year's robot: https://github.com/CAPS-Robotics/201...ree/master/src

We did use C++ for this and it seems that you use Java, but the same basic idea is present (just ignore all of the pointer fun). We used SampleRobot for this code and you can see that the autonomous does not actually check if it is still enabled. We ran this code in competition and never had any problems with the autonomous disabling during a match.
Disclaimer: I wrote some of this code, so it is not necessarily very good, but I hope it at least helps with the basic ideas.

[virtuald]

Just because you can do something and it doesn't break does not mean one should do so.

A great example of why loops are dangerous are these two bits of code in your autonomous: https://github.com/CAPS-Robotics/201...anOWar.cpp#L89

while (!aligned) {
   ... do things
}

If your gyro breaks (maybe the wire gets messed up on accident), your robot will never enter teleoperated mode and that match is over for you.

Same thing here:

do {
... fire = someSensor > some_value
} while (!fire)

If your encoder breaks/gets disconnected, same business. You're done.

Maybe you have magic hardware that never breaks, but I wouldn't put my trust in that.

[PopeRyanI]

Originally Posted by virtuald

If your gyro breaks (maybe the wire gets messed up on accident), your robot will never enter teleoperated mode and that match is over
Maybe you have magic hardware that never breaks, but I wouldn't put my trust in that.

Wait that is a thing? This is my first year as the head robot programmer for the team and I never realized that it was possible that the robot could get stuck in autonomous and never enter teleop. I thought that the FCS changed modes automatically and that any residual problems from the autonomous would not affect the teleop.

[virtuald]

Originally Posted by PopeRyanI

I thought that the FCS changed modes automatically and that any residual problems from the autonomous would not affect the teleop.

That is incorrect.

Use the source, Luke.

As you can see from the source of SampleRobot, if you never return from the Autonomous function, OperatorControl will never be called. No magic here.

[feverittm]

I have been working with our programmers for a while now and have been working with the WPILIBJ since the beginning in 2010.

Our team uses the command based framework. We like the way we can modularize the code: Break apart functionality into Subsystems, Define commands that operate on those subsystems and then connect the overall system together in the Robot.java code segment while abstracting the harward connections away in the RobotMap layer.

you can get a better look at this methodology by reviewing the Gearsbot code and if you look on Youtube there are videos on this system as well that explain it quite well.

I have looked at he RobotBuilder and in some places it can work reasonably. However, it does make it more difficult to understand your code and our programmers are not a fan of placing all the constructors in the RobotMap file. I use it VERY early in the development to help understand the connections and plan the structure of the code. I can also use it to help with quick testing of systems without having to focus on having everything in place; you can define the subsystems with all their sensors and actuators, then use the 'Testing' mode on the dashboard to verify system functionality.

I know that these capabilities can be developed using the other programming systems, like IterativeRobot, but we find this way easier.

Enjoy!

Floyd Moore

[trycatch]

Originally Posted by virtuald

That is incorrect.

Use the source, Luke.

As you can see from the source of SampleRobot, if you never return from the Autonomous function, OperatorControl will never be called. No magic here.

Yeah, I found that earlier today... if there was a way to break back out of this simply without having to constantly poll, SampleRobot would honestly be perfect. I spent a bit stewing on creating a new extension to RobotBase that would spawn killable threads for autonomous and teleop, but that would require thread.stop(), which has it's own issues. If it got killed in the middle of an i2c command, it could pick up the device it was talking to.