Quick question re: CommandBased programming and sharing a joystick

[Charlie Peppler]

This is probably pretty basic, but I've been following through the wpilib docs learning about Command based programming,
and I came to a question about sharing the joystick.

When you are doing classic drive (say Mecanum drive as with a Studica robot), you typically see something like

this in a drive subsystem:

[...]

 private final Joystick m_joystick = new Joystick(0);

[...]

and then later...

[...]

    m_robotDrive.driveCartesian(m_joystick.getX(), m_joystick.getY(),  m_joystick.getZ(), m_gyro.getYaw());

[...]

All this code is down inside the Drive subsystem.

The problem is, I want to also use the buttons on the Joystick.

Following these instructions, there is a different instantiation of new Joystick() when accessing the
Joystick buttons.

Is it kosher to have two different instantiations of the Joystick class that point at the same physical
Joystick?  Instinct tells me to share a single instance, but what a mess when you try and separate the 

subsystems.

Trying to understand best practice. 

Thx!

[Scott Libert]

> Is it kosher to have two different instantiations of the Joystick class that point at the same physical
Joystick?  

Having worked w/the WPI Library, Joysticks and JoystickButtons, we've only ever used on instance of the Joystick class.  We've definitely driven the robot and used joystick buttons on the same physical joystick, and that was accessed using a single Joystick class instance.

When you create the JoystickButtons, provide the constructor the reference to the same Joystick instance used for driving, and you should be good to go.

[jrothr...@hdsd.org]

This is an excellent question.  Thank you for bringing it up.  I too was confused by this, but I am guessing the confusion lies in the way the new Command framework works.  

I think you are actually both saying the same thing.  If you look at the examples (specifically the RobotContainer class, formerly OI) from WPI, it seems that NewJoystic() is not a new instance of the joystick, but a new interface to trigger the command. I am not certain about this, but it seems in the example, that the NewJoystick() class declares a new link to the existing joystick and button.  

Java and CPP deal with this well, but when we used Labview, it was easy to create multiple instances of hardware, and frequently created race conditions.

~Jacob

P.S. One of our team members found an incredible way to map a mecanum drive.  We realized that most of the people who complain about mecanum, drive it like a normal drive most of the time (unless they want to strafe) missing out on much of its power.  A way to quickly change that paradigm is to map an Xbox controller like an arcade drive using the left stick Y-axis to do forward and back motion, the left stick X-axis to do the strafing, and the right stick X-axis to do the turning.  This forces our drivers to actually drive using the strafe as part of the normal drive rather than as an afterthought. It makes for some powerful maneuvering.

[Charlie Peppler]

Scott,

I understand.  This means you need to instantiate the Joystick object at a higher
point in the architecture instead of instantiated at a lower level as presented

in the individual code snippet examples (which I understand now).

I"m assuming Joystick object instantiation should be done in the constructor 

of the RobotContainer class, and then the Joystick object reference is passed 

down through the constructor of any subsystem that needs access to it (typically 

the drive Subsystem, that keeps a reference to it, and typically uses the axes), 

and then pass the same reference to the constructor for the JoystickButton(s) 

(that, obviously, access the buttons).

Just wanted to understand best practice for organization of the entire robot code 

base within the new architecture (which I like btw) before building out other

subsystems and commands.

Charlie

[jrothr...@hdsd.org]

As I understand it, this is mostly correct.  However, the drive subsystem does not access the joystick, the joystick accesses the RobotContainer (It used to be OI) accesses both the Joystick and the drive subsystem.  One of the design tenants of the command base architecture is that in general, the joystick does not directly control systems.  It just triggers events. This is difficult to understand conceptually and one reason why we have not yet adopted the Command Base format.  Interestingly enough, there is a wonderful hybrid system for Robotpy called MagicBot.  It seems to use the best of both worlds.  However, I may focus our energy toward making the switch to Java first. I could not find any tutorials for the new command base as it is too new, but these videos helped me understand how to set use the old command setup.  It is not completely different, but there are changes.

I only partially understand the Command Framework, so apologies if my 2 cents are distracting.

https://youtu.be/64hPDvphcfA