Poll: Command or not Command, That is the Question

As I navigate my way through this crazy world of social distancing and make my way through the list of all the off-season projects our team and I have never had time for, I realized I have not seen a poll that asks, which framework people use.

Here is the question,

Which Framework do you prefer and why?

  • Timed Robot
  • Old Command Framework
  • New Command Framework

0 voters

If I forgot any, let me know and I will add it.

1 Like

Given that you are using python, you should include magicbot

1 Like

Oh my, how did I forget that? Thank you. Edit, apparently I cannot add it. I would appreciate it as a write in. I love how it bridges the gap between timed and Command. In addition, I love how Pythonic it truly is.

This feels like an appropriate time to remind everyone of the Chief Delphi Selection Bias, present in most polls on this site. Take the numbers above as a representation of a subset of FRC, not a representation of most teams.

5 Likes

That is a good point. However, I asked it because we use timed robot for ease of understanding. As I delve into investigatimg other people’s examples to learn new things, I realized that much of the code shared on CD (especially demonstrating complex operations) use either the Command or Magicbot frameworks. As a mentor, I am wondering at what point do I begin teaching frameworks instead of some operations. In this too, I am aware of selection bias. The first thing I accomplished during this extended offseason was truly understanding how Command Based and Magicbot frameworks work (I have @auscompgeek and the wonderful trajectory example he sharwd as well as 4627’s incredible tutorial thank for that). So, now taht I feel I understand it, though teaching the other frameworks was not on my radar, I wonder if it should be.

1 Like

New command based. Initially I wasn’t a big fan of it last year but I was forced to use it by my team. This year with the new framework felt a lot more intuitive and took full advantage of the command scheduler

1 Like

Our team has used TimedRobot for 4+ years. I know the basics of command based programming, but I prefer TimedRobot because it’s definitely a lot more simple (at least from my perspective). Part of it is I know how to train younger students to use an established framework and build off of past years’ examples. If we suddenly switched to CommandBased, I’d have to do some learning. Now, I’m always open to adventures, but I see no reason to switch. Sure, I guess concurrent commands are easier, but we’ve managed in TimedRobot before.

@Mr.R_2 - If you want our example of TimedRobot from 2020, you can see our code here: https://github.com/amhsrobotics4681/2020-First-Rise/tree/master/workspace/2020%20FIRST%20Rise
Past years can be found at https://github.com/garykac/amhs-robotics-4681, but it’s a horrible mess in there.

2 Likes

Thank you for sharing. @Derek_Geng I know what you mean. To me, the new Command feels a lot like magicbot. It separates everything out, but flows a lot better.
@cmarley thanks for sharing. Though I am still leaning toward sticking with timed robot, there are some functions (like trajectory) that seem to fit cleaner in command or margicbot. Hence the origin of the poll. Your code will be helpful. Thank you.

TImed robot. Historically, it was because people didn’t want to teach brand new students a language and a framework. It’s not the best argument, but it’s one of them.

More realistically, we’ve historically had multiple mentors (both on and off the software team) who have background in embedded, real-time controls software development. Generally, they (and the students they teach) respond better to an industry standard init/update structure, than something (relatively) bespoke to FRC. Add in that we re-invented the wheel with a timeline-based “Auto-Sequencer” to self solve some of the more frustrating portions of concisely defining auto sequences… the push just isn’t there to move to anything else.

We’ve had a summer action item to “go investigate switching to command based”, but never gotten it high enough priority to have a legit opinion one way or the other.

1 Like

…we re-invented the wheel with a timeline-based “Auto-Sequencer

This is an interesting point. We accomplished something like that this year and this is one of the pieces that led me to ask the question. One of our programmers investigated how to use the robotPy
Stateful Auto. He did a good job with it, but it really is not that far from implementing the MagicBot framework.

It is also validating that you have mentors in the industry who look at things more procedurally. I was thinking one upside is that it is a good way to teach the principles of OOP (not that we do not do this with Iterative).

We too have had it on the back of our minds for a while.

1 Like

FWIW I feel like this poll is missing an important distinction. It’s a bit pedantic, but I have seen it a lot on CD. TimedRobot isn’t really a framework - it doesn’t inherently dictate how you write robot code. In fact, command based projects are running on top of TimedRobot. There’s a lot of different ways to use the TimedRobot class, and there’s quite a few teams who have built a framework of their own on top of that, us included. On the other hand, it’s possible to write the entire robot code in the Robot class with TimedRobot, which is generally a bad idea in terms of readability and usability, but can be perfectly fine if the robot is simple and there’s a desire to avoid abstraction. The point is, both 254’s code and very simple code would be counted the same in this poll, which isn’t capturing the actual nature of the codebase.

3 Likes

I think that teleop code can be written in command based or an iterative style well.

However for autonomous, I’ve never seen a reason to not go with a command based approach. Using commands makes editing your routine so much easier. It just makes so much more sense to be able to say something like: go left, go straight, turn at a high level.

For teleop, using commands doesn’t make as much sense because most of the time, you’re just telling the motors to go to a certain speed. Yes, there are times when you might want the robot to do something automatically in teleop, but usually when that’s the case, a state machine works just as good if not better than trying to use commands.

Also, we’ve never used the WPI command frameworks, but I still consider most of our code to be command based.

TDLR; Iterative approach for teleop, command based for autonomous.

1 Like

I’ll go as strongly disagreeing with this. Command-based (or similar) programming makes it very easy to keep the user interface separate from the functionality - in the sense of being able to connect things differently. It also makes it all-but-trivial to ensure that you aren’t giving the same motor two different speeds at the same time.

At the next level, It makes semi-auto functions much easier, like having the robot automatically target and score at the push of a button. You need 0.3 seconds for your wheel to spin back up? Let the computer count those down for you, and empty your magazine in minimal time.

4 Likes

I can agree that command based definitely makes it easy. However I don’t think it’s significantly easier than using an iterative approach for this.

I agree that a complex autonomous movement during teleop such as lining up and scoring should use commands. But for something as simple as making your wheel spin back up in 0.3 seconds? That’s just easier to do putting some of that logic into the subsystem itself and using a more iterative approach with simple state machines.

I was arguing that you shouldn’t force everything into a command, not that you should avoid commands in teleop altogether.

Some things in teleop that we didn’t use commands for:

  • Automatic movement of power cells in indexer (used 3 sensors)
    • We had the option to use commands here because of how complicated the state machine got, but we chose not to
  • Waiting for shooter to get up to speed (we had a method that returned true in our shooter subsystem if it was up to speed and we used a state machine in our shooter subsystem to determine if it was up to speed)

If we had a wheel spinner, we would have used a command for spinning the wheel, so it’s not like we’re avoiding them altogether, I just think that there are a few places where state machines are easier.

Thank you all for your reaponses. Sorry I did not reply for a bit. I have been busy (aapparently that happens even in quarantine).

emphasized text[quote=“GeeTwo, post:13, topic:384012”]
Command-based (or similar) programming makes it very easy to keep the user interface separate from the functionality - in the sense of being able to connect things differently. It also makes it all-but-trivial to ensure that you aren’t giving the same motor two different speeds at the same time
[/quote]

This is an impotant point, and perhaps the best reason for using a framework. We struggled with race conditions at times when using Labview, but that was more us than the logic flow.

Semi-Autonomous is also another powerful reason to use a framework.

Thank you all for your votes and answers. This does help us as we go forward.

I can see now some of the merits of using more encapsulation, and how Command and Magic bot frameworks are a helpful way to incorporrate that. I also love the way other teams (like 254) do it successfully without using the command framework. It is interesting because some of my hesitation for jumping into command came up and have been dealt with in intereating ways.

I feel like our team is getting a lot out of this extended off-season already. We have CD to thank for a lot of it.