Command Based V iterative V Custom?

[E, Palmer]

So as this year begins to end I'm looking to next year. I am Programming lead for my team. This year we used the WPI Command Based Form given by FIRST. My question is, for next year, is this form the best option? I was not particularly pleased with the constant overhead that it forces. I do however realize the merit in the system, it allows for beginners to learn structure and the basics of programming in java. Next year however we wont have as many beginners and i was wondering what other teams are doing? is there an established, better way? or is command based the best?

[mikets]

It's not necessarily better but our team has developed a library for the past eight years. It was in C++ first but we converted it to Java last year when we switched to Java. This year, we even merged with our FTC library so the library is compatible with both FTC and FRC. If you want to take a look, you can access it at GitHub (https://github.com/trc492/Frc2016Fir...Stronghold/src)
The main file is in frc492/Robot.java
Our framework was based on the same concept as Iterative Robot but it supports Cooperative Multi-tasking (multi-task with one thread) so it is easier to learn. You started with putting code in a method called initRobot where it creates the entire robot configuration (drive base and subsystems). Then at the end of initRobot, you create the RobotModes: Autonomous, TeleOp and Test. Each of them implements the RobotMode interface which includes the methods: startMode, stopMode, runPeriodic and runContinuous. startMode and stopMode are methods that will be called one time before the competition mode starts or stops. For example, before autonomous starts, teleop starts, autonomous stops or teleop stops. Then the methods runPeriodic and runContinuous will be called periodically. The difference between runPeriodic and runContinuous is the frequency it is called. runPeriodic is called when there is new driver station data and runContinuous is called in a loop as fast as it can. So typically, TeleOp code goes into runPeriodic and autonomous goes into runContinuous for better resolution.
Not only does this framework makes it a lot easier to write multi-tasking code without the gotcha's of multitasking (i.e. resource contention and tasks synchronization), it also cumulates all the knowledge we learned about different mechanisms. For example, how to use PID control to drive a robot base accurately in all different drive modes: arcade drive, tank drive and mecanum drive. Our PID control for the drive base is overall PID control, not individual motor PID control. It means it will combine encoders, gyro, ultrasonic or any sensors to determine what power should be distributed to each of the motors of the drive base so it will drive straight if you wish so. Also, it supports using PID control to control an elevator/arm so it will hold its position fighting gravity? It also provides supports for event driven actions such as calling you back if a joystick button is pressed or if a limit switch is activated and much more.

[Ozuru]

Originally Posted by mikets

It's not necessarily better but our team has developed a library for the past eight years. It was in C++ first but we converted it to Java last year when we switched to Java. This year, we even merged with our FTC library so the library is compatible with both FTC and FRC. If you want to take a look, you can access it at GitHub (https://github.com/trc492/Frc2016Fir...Stronghold/src)
The main file is in frc492/Robot.java
Our framework was based on the same concept as Iterative Robot but it supports Cooperative Multi-tasking (multi-task with one thread) so it is easier to learn. You started with putting code in a method called initRobot where it creates the entire robot configuration (drive base and subsystems). Then at the end of initRobot, you create the RobotModes: Autonomous, TeleOp and Test. Each of them implements the RobotMode interface which includes the methods: startMode, stopMode, runPeriodic and runContinuous. startMode and stopMode are methods that will be called one time before the competition mode starts or stops. For example, before autonomous starts, teleop starts, autonomous stops or teleop stops. Then the methods runPeriodic and runContinuous will be called periodically. The difference between runPeriodic and runContinuous is the frequency it is called. runPeriodic is called when there is new driver station data and runContinuous is called in a loop as fast as it can. So typically, TeleOp code goes into runPeriodic and autonomous goes into runContinuous for better resolution.
Not only does this framework makes it a lot easier to write multi-tasking code without the gotcha's of multitasking (i.e. resource contention and tasks synchronization), it also cumulates all the knowledge we learned about different mechanisms. For example, how to use PID control to drive a robot base accurately in all different drive modes: arcade drive, tank drive and mecanum drive. Our PID control for the drive base is overall PID control, not individual motor PID control. It means it will combine encoders, gyro, ultrasonic or any sensors to determine what power should be distributed to each of the motors of the drive base so it will drive straight if you wish so. Also, it supports using PID control to control an elevator/arm so it will hold its position fighting gravity? It also provides supports for event driven actions such as calling you back if a joystick button is pressed or if a limit switch is activated and much more.

@OP - my personal advice is not to bother with this for two reasons:

1) You're new and aren't an expert with FRC's ins and outs. Debugging will be very hard and CD won't be able to help you. The only person that will understand why something is breaking is the maintainer of that software.
2) The project could be discontinued at any time and next year you'll be forced back to the position you are in now.

As someone who has used iterative and command based for multiple (independent) seasons, I feel that command based is more intuitive and powerful than iterative. I view iterative as one giant while(true) loop, while command based has the #basedscheduler and allows subsystems to run in parallel (and be delayed without locking other robot functionality). Also, command based builds off of object-oriented concepts, something new programmers should be very familiar with if they've taken AP Computer Science.

That being said, command based has some flaws, but I personally believe that it has less flaws than iterative. I can go more in-depth into command based's weaknesses if you'd like.

[Cr1spyBacon8r]

I'm taking a page out of #254's book to reprogram our robot in the offseason. They use a mix between iterative and command based, which looks really organized (at least compared to ours).

[notmattlythgoe]

We have used the Command Based structure since it's inception and have always been very happy with it.

[Pratik Kunapuli]

I've always used iterative, and have no issues with it. Some people say command based is more intuitive, but I've always thought the opposite. I think command based lends itself to automation very well, so I'll definitely be taking a look into it during the summer/offseason. Ultimately, it's easy to try both and figure out what works best for you, just pick the one that you like the best and run with it.

[notmattlythgoe]

Originally Posted by Pratik Kunapuli

I've always used iterative, and have no issues with it. Some people say command based is more intuitive, but I've always thought the opposite. I think command based lends itself to automation very well, so I'll definitely be taking a look into it during the summer/offseason. Ultimately, it's easy to try both and figure out what works best for you, just pick the one that you like the best and run with it.

I wouldn't say intuitive. I've always told people it makes it harder to do very simple things but easier to do more complex things.

[mikets]

The design of our library is supposed to be as easy to use as Iterative robot but also supports complex scenarios you can find in command-based code but simpler to understand.

[Bell-Inequaliy]

Sorry to hop on a bit late, it took me a little while to prepare what I was going to show you. If you want to look at an example of a custom coded but non-library structure, take a look here:

https://github.com/ToasterTechFRC/Toaster-Base-Bot

It is built off of the iterative model but it has a structure similar to command-based. It does require a bit more knowledge of Java than entry-level but it does show how a custom structure can be created manually to fit your needs. I've also documented it as best I can. Our 2016 code (we haven't pushed our CMP code) is also on GitHub, but it is much messier and has significantly less comments although it does show how our structure can function with autonomous modes.

[mikets]

Originally Posted by Bell-Inequaliy

Sorry to hop on a bit late, it took me a little while to prepare what I was going to show you. If you want to look at an example of a custom coded but non-library structure, take a look here:

https://github.com/ToasterTechFRC/Toaster-Base-Bot

It is built off of the iterative model but it has a structure similar to command-based. It does require a bit more knowledge of Java than entry-level but it does show how a custom structure can be created manually to fit your needs. I've also documented it as best I can. Our 2016 code (we haven't pushed our CMP code) is also on GitHub, but it is much messier and has significantly less comments although it does show how our structure can function with autonomous modes.

Your code implemented a framework. It is a light weight framework but it is still essentially a library although it is structured not very library friendly (i.e. all reusable code scattered in various folders instead of concentrating in one library folder).