RobotBuilder and new Command structure in wpilib 2020

[Charlie Peppler]

This is not specifically related to Studica or vmx-pi, but it's an observation about how to work on 
setting up for training software for next season.

Frankly, I had never heard about the OI class until Jacob mentioned it during my question

about instantiation of the Joystick class.

I went back through docs.wpilib.org, to try and find what he was referring to
and examining how best to structure the overall robot code.  I then discovered
RobotBuilder.

I tried RobotBuilder for the first time, and saw that that it automatically generated
the overall structure of the robot code project (which is really cool), including
the OI class, and the structure for the Joystick and buttons, and then saw
what Jacob meant by the drivetrain subsystem going to fetch the Joystick object
from the OI class.

I went to go try and build the frame of a robot code project using the robotbuilder 

from scratch, to see if that would be a good path to lead new students down.  

It's great in concept, however, it has not been updated to create wpilib 2020 projects,
and still generateds 2019 version project structure, including the old command structure.

So, I'm taking a step back, and trying to figure out how to resolve which way to go:

1. Building a new set of robot code from scratch using the new Command structure, and try and
   stick with the OI class
2. Starting with a structure built with RobotBuilder, adapting it to use the new command structure,
   and then leaving RobotBulder behind (or waiting for it to get updated), and just work/train
   from a new code base.
3. Waiting for RobotBuilder to get updated so it will generate a wpilib 2020 command structure
   project, and then try and organize around that.
   

I'm tending toward #2, but curious if others have run into the same thought process about

becoming an effective trainer in this stuff.

Charlie

PS.  Having used code generators in other contexts in the past, I realize they run out of gas

after providing the original structure.  

If you modify or add to the code generated, the code generator can not 

reintegrate those changes, so you have to choose which you use, which ultimate

is the code itself.

[Kaden Keep]

Hey Charlie,

My personal preferred method of creating 2020 new command structure projects is by using provided examples/templates provided with the WPILib VSCode extension. Some of these examples/templates are the new command structure, and some are the old, most will specify. I typically find the closest match to my needs, then just add on what is missing. There are a very limited few that feature the multiple files, such as OI and RobotContainer.

The simplest template with the whole structure can be found on the allwpilib git: https://github.com/wpilibsuite/allwpilib/tree/master/wpilibjExamples/src/main/java/edu/wpi/first/wpilibj/templates

Additionally, the OI/RobotMap file is actually the older command structure. They have been replaced in the new command structure with RobotContainer/Constants, respectively. The two new files also somewhat contain parts of command scheduling and the Robot file, best described by the docs.

A second option more related to your listed options would be to use RobotBuilder to create a 2019 project then to use the WPILib VSCode plugin to import the project to the 2020 libraries. The main issue here is that you would be using the old command structure, but could be manually adapted to the new structure.

[Charlie Peppler]

Kaden

Thank you for your note and guidance.

I tried using the RobotBuilder to structure the overall code for a new set of robot code
and then converting it.  Because of all the differences, comparing back and forth between
old and new, I realized the OI class had been pretty obviously deprecated, and trying to follow

that structure, it became a mess, and obviously not something teachable.

I will be starting over again using the templating structure for the new command structure,

however, I'm still finding inconsistencies btw the documentation (not a complaint, I understand

why) and the templates.

One example I've run into is the declaration of (new) commands.  In the documentation, 

the constructor passes in the subsystem to the command, and the command 

constructor adds it to it's requirements.

Also in the docs, when you bind the commands to a trigger/button, it declares it as a new instantiation,

but does _not_ pass the subsystem to the constructor, so I'm confused about which is the
best practice, to pass subsystem or not on the command constructor.

Thanks for the post.  None of this is specific to you guys, I'm just trying to figure out
best practices to build a full working demo with the Studica robot, VMX-pi, and the latest
from WPIlib.  I'll keep working my way through.

[jrothr...@hdsd.org]

Charlie,

As with you, I am figuring all this out as I go along.  One thing I keep reading about with the command structure is that oi never interacts directly with subsystems.  While this makes sense in terms of auto routines, it is a significant paradigm shift for our team when it comes to teleop.

This is the reason we have not jumped into the command structure as of yet (though I am learning it this summer with all of my other projects:).

I think the answer you are looking for is that the command passes the subsystem and the trigger/ button runs the command.  

However, your question brings up one of my own.  If this is the way:

Each command passes the subsystem, and 

each action (trigger or button) creates a new instance of the command: 

What happens when two instances run at the same time?

Let's say we have a drivetrain subsystem and have a command to turn to 90 degrees and a command to turn to negative 90 degrees.  if they are each triggered by a different button (or a tired programmer binds them both to the same one), what happens when both are triggered att he same time?

To make matters more complicated, what happens if a continuous command (like drive with the stick) happens at the same time as pushing one (or both) of those buttons?

I know the scheduler makes sure things do not get too confusing and should dictate which happens, but it is a curiosity for sure,

~Jacob

[Charlie Peppler]

Jacob,

I think I'm discovering that the new 2020 command structure has pretty effectively deprecated the OI class of the
previous generation of the command structure.  The functionality of the OI class seems to have been replaced 

by the RobotContainer class, in which configureButtonBindings will contain new button bindings 

(which look to be significantly more flexible/capable).

As far as the command/subsystem relationship, from what I've read, the best practice is to "inject" the reference of the subsystem
into the command, and then the command "requires" the subsystem.  I think that this informs the scheduler of that commands requirement for 

the subsystem, and the scheduler either queues the command or interrupts the existing running command that is using that subsystem.

The "DefaultCommand" for a subsystem runs when no other command is using it.  What this does, is lets you set, for example,
the default drive command for the drive subsystem during teleop, that runs when no other command is running.  Then if you put 

in a higher priority command it subsumes control of the subsystem, and then lets it go when it's finished.

Still working out the details, but I think it's something like that.

The new command structure allows you to link together multiple commands, either in sequence or in parallel, which is pretty cool.
I haven't tried that yet, but it sounds interesting.

[jrothr...@hdsd.org]

Thank you.  This explanation helps a bit.  I also think that this is key.

"The new command structure allows you to link together multiple commands, either in sequence or in parallel, which is pretty cool.

I haven't tried that yet, but it sounds interesting."

This was another stumbling block for us.  Frequently we drive and pick up or place a game item.  This is an incredible development (of course, too many parallel activities could still lead to power issues, but that is an issue with not using a framework as well.

~Jacob