Really underhanded

[cstelter]

Hello-- I'm the programming mentor for 3018 Nordic Storm, and our programming team this year is new to java. But here is how we approached it.

What you are asking should be doable in 7 lines of Java written and about 10 labels provided to Robot builder and about 7 items added to robot builder, 2 chekbuttons pressed and 6 dropdown selections made in Robot builder.

*Very Briefly*

In Robot builder:

• Start RobotBuilder
• Specify project name and team number (e.g. MyRobot and 1234)
• Add Subsystem named DriveTrain
• Add 'Robot Drive 4' controller to DriveTrain
• Add 4 Speed Controllers to RobotDrive41, label them lf,lr, rf, rr
• If known, set port numbers for speed controllers, otherwise wire up according to how they were added in RobotBuilder
• Map lf to Left Front Motor, lr to Left Rear motor, etc in RobotDrive41
• Invert motor direction for Right Motors
• Add Command named DriveWithJoystick
• Set DriveWithJoystick to require DriveTrain
• Set DriveTrain Default Command to be DriveWithJoystic
• Add Joystick to Operator Interface
• Press Java --> Code will appear in c:/users/<username>/workspace/MyRobot

In Eclipse:

• File > Import...
  Open General folder
  Choose Existing Projects Into Workspace
  Choose path specified in last step
• In MyRobot > src > org.usfirst.frc1234.MyRobot.commands > DriveWithJoystick.java file, change existing execute() to this:
  

  protected void execute() {
      double mag=Robot.oi.getJoystick1().getMagnitude();
      double dir=Robot.oi.getJoystick1().getDirectionDegrees();
      double rot=Robot.oi.getJoystick1().getTwist();
      Robot.driveTrain.mecanumDrive(mag,dir,rot);
  }

• hover over word 'mecanumDrive' in last line in previous step and select option to 'Create method 'mechanumDrive(double,double,double) in type 'Drive Train'.
• In MyRobot > src > org.usfirst.frc1234.MyRobot.subsystems > DriveTrain.java file, change newly added mecanumDrive() Method to:
  

  	public void mecanumDrive(double mag, double dir, double rot) {
  		robotDrive41.mecanumDrive_Polar(mag, dir, rot);
  	}

• Deploy!

Above is essentially how I led our programmers through the task of programming our mecanum chassis. There may be some typos, but it is relatively complete

Here is the above sequence with a lot more details

1. after eclipse is up and installed and configured for wpilib, Select the menu WPILib > Run Robotbuilder
2. provide your team number and a name for the project when robot builder opens
3. if you use the default workspace no mods should be required-- otherwise click on the root of the robot tree and specify the path to your eclipse workspace
4. Right click on Subsystems and add a subsystem. Name the subsystem DriveTrain
5. Right click on DriveTrain in the tree and Add a controller-- add the Robot Drive 4 controller. Robot Drive is a java class with lots of very useful code for driving robots with a variety of drive trains.
6. Right click on the new Robot Drive controller (default name will be Robot Drive 4 1) and either Add SPeed Controller or Add CAN Jaguar, whichever is your case. We used Talon SR's in our first attempt so we added Speed Controller
7. Repeat last step 3 more times and rename the 4 speed controllers to lf, rf,rr,lr
8. Set the PWM port (Or can port if you are using Talon SRX or CAN Jag) for your controllers per your wiring, or choose the defaults and tell electrical what how to wire it.
9. click on Robot Drive 4 1 and set the value for 'Left Front Motor' to lf, repeat for 'Right Front Motor=rf' and 'Right RearMotor=rr' and 'left Rear Motor=lr'.
10. Because your motors on the right have the shafts facing right a clockwise spin will run the wheels to drive the robot backwards while the shafts facing left have clockwise turn roll the robot forward, you must invert the motors on the rigght, so check the 'Right Rear Motor Inverted' and the 'Right Front Motor Inverted' boxes
11. You need a command to drive a subsystem, so add a command (right click on Commands in tree and Add Command) and name it DriveWithJoystick
12. This command needs to use your DriveTrain subsystem, so set the value of 'Requires' on your command to require DriveTrain. You don't need a button on smart Dashboard, but it matters not if it is checked or not at this point.
13. You will need a joystick, so right-click on Operator Interface and Add Joystick. Accept the rest of the defaults
14. With the CommandBase robot pattern that RobotBuilder uses, you must schedule a command to run, and the easiest way to schedule our DriveWithJoystick command to run is to make it the default command for the DriveTrain. This means that it will be scheduled by default. Visit DriveTrain and set the 'Default Command' to 'Drive With Joystick'
    
    At this point we've fully described our robot to Robot Builder.
    
15. Now press the 'Java' button in the toolbar at the top. This will create an entire eclipse project for you under the name you named the project inside your eclipse workspace.
16. in Eclipse do File > Import..., open General branch for types of imports, select 'Existing Projects into Workspace,
17. on import projects dialog, click browse for 'Select root Diretory' and go to your new project-- (most likely going to be c:/users/<username>/workspace/<projectname> )
18. when it opens you have a few hundred lines of java already created for you by Robot builder. We now have to write about 10-15 lines of code to finish it off.
19. so we set up a command named DriveWithJoystick. That command was set up to require DriveTrain Navigating in Project Explorer to <projName> > src > org.usfirst.frcNNNN.<projName>.commands we can find our DriveWithJoysticks java code. A command has standard entry points
    
    A constructor-- called any time you make a new DriveWithJoystick()
    initialize()-- called once when scheduled
    isFinished()-- called once every time through teleopPeriodic() to see if it is done
    execute()-- called once every time through teleopPeriodic() after command only if command as returned false to isFinished()
    end()-- called once before the command is removed from schedule after reporting true to isFinished()
    interrupted()-- called once when another command requiring the same subsystem is scheduled.
    
    So for a default command that will never end of its own accord (as long as telop is running, we want to be able to control the robot with the joystick), we simply return false from isFinished() and this is the default, so no code required.
    
    No initialization for this command is required.
    
    for execute() we would like to read some values from our joystick and tell our drivetrain to drive using those values. So we add 4 lines to execute so it ends up looking like:
    

    protected void execute() {
        double mag=Robot.oi.getJoystick1().getMagnitude();
        double dir=Robot.oi.getJoystick1().getDirectionDegrees();
        double rot=Robot.oi.getJoystick1().getTwist();
        Robot.driveTrain.mecanumDrive(mag,dir,rot);
    }

    If you begin typing 'double mag=Robot.' as soon as you press the period, you will get a popup of all functions and fields on the Robot object and you will see oi as an option. When you press the period after typing or selectin oi, you will see a list of all the functions and fields available on oi-- including a function getJoystick1() and after choosing that and pressing period again you can find the getXXXX() functions.
    
    TIP: Any time you need something, you can start by typing 'Robot.' and seeing what is available or sometimes you may need 'RobotMap.' and sometimes it helps to start with 'this.' to see what you might have inherited from your base class.
20. so in the previous step, you will see red undermarks under the function name mecanumDrive on the last line we wrote for execute(). This is because we've said to call a function that has not yet been written. But thinking top down, we know we need to call some mecanumDrive function and pass it the joystick direction, how far it is going and how much we are twisting it (assuming an Extreme 3d joystick). So we wrote it even though it does not yet exist. Eclipse has a nice 'quick fix' feature when you hover over a word with red undermarks. So if we do this on 'mecanumDrive' we are given the option to 'Create method 'mechanumDrive(double,double,double) in type 'Drive Train'. Select this and it will write an empty method for you over in your DriveTrain.java file
    
21. Now visit DriveTrain class definition under the subsystems (open src branch, then open org.usfirst.frcNNNN.<robotname>.subsytems branch in the project explorer to find DriveTrain java). In this class you can see you have local fields for your robotDrive41 as well as your motor controllers lf, rf,rr,lr.
    
    At the bottom of this, you should find
    

    	public void mecanumDrive(double mag, double dir, double rot) {
    		// TODO Auto-generated method stub
    		
    	}

    because of the quick fix we applied in the last step.
    
    Now we need to write code for this method. As mentioned in the TIP last step, we can always type a name followed by a period to find out what we can do with it. In this class we have a RobotDrive object named robotDrive41 so if we start by typing robotDrive41. we will see two very useful functions for a robot with mecanum drive-- mecanumDrive_Polar and mecanumDrive_Cartesian. Since we got Magnitude and Direction from the joystick, the Polar form is appropriate so all we have to do in our method is this:
    
    

    	public void mecanumDrive(double mag, double dir, double rot) {
    		robotDrive41.mecanumDrive_Polar(mag, dir, rot);
    	}

22. right click on the project root node in the Project Explorer (e.g. right click on the word MyRobot if that is what you named your project), select Run As > WPILib Java Deploy

Hopefully this will prove helpful. There are also some great YouTube videos about RobotBuilder published 2 years ago here: https://www.youtube.com/watch?v=k7Pa...lgn vhGObeKzp that I recommend to understand the wonderful CommandBase architecture provided by WPILib.

It takes a bit of skill to properly use CommandBase-- choosing your subsystem functionally that you expose is key. Only using commands to access that functionality of your subsystems is key.

For example, say you have a switch in a toteCollector subsystem that lets you know when one tote is loaded.

You *could* write a method called bool getToteCollectorSwitchState(), or worse DigitalInput getToteCollectorSwitch() but you will find it it quickly tedious to use. The whole point of a subsystem is to *hide* details and expose only those things that you deem commandable or askable. Instead consider the approach

bool isTote1Loaded() {
}

Now the switch is hidden from the subsystem's external callers-- they don't need to know how the switch works in the subsystem, nor should they care. What they need to know is if the tote is loaded. This gives your subsystem flexibility to change to a light sensor or a pressure sensor instead of a digital switch, but any commands that need to know when tote #1 is loaded won't need to be changed.

[Kyorox]

I will look into this though out the day, we havent dabbled much with Robot builder, as we have been waiting for our programming mentor (who we only see on saturdays) to assist us with this matter. With these instructions and what i have found elsewhere its worth the shot.
Please ignore my ignorence, on our team we really stress the "The Kids Run The Team" Motto, so I have had a lot on my plate and offered not to be the head programmer for this exact reason.

[Kyorox]

Originally Posted by Kyorox

I will look into this though out the day, we havent dabbled much with Robot builder, as we have been waiting for our programming mentor (who we only see on saturdays) to assist us with this matter. With these instructions and what i have found elsewhere its worth the shot.
Please ignore my ignorence, on our team we really stress the "The Kids Run The Team" Motto, so I have had a lot on my plate and offered not to be the head programmer for this exact reason.

I emailed my mentor with this link and I got the ok. As of 9:20 Am I have a partially working Mecanum drive train. A little trouble shooting here and there and a few adjustments and I should be able to work this out.

The major issue at hand is that the wheels are all spinning at different paces although they are all the same ( and by that I mean is that they are all controlled by talons

[notmattlythgoe]

Originally Posted by Kyorox

I emailed my mentor with this link and I got the ok. As of 9:20 Am I have a partially working Mecanum drive train. A little trouble shooting here and there and a few adjustments and I should be able to work this out.

The major issue at hand is that the wheels are all spinning at different paces although they are all the same ( and by that I mean is that they are all controlled by talons

Make sure to calibrate the talons. To do this you press and hold the calibrate button on the talon until it starts to flash multiple colors. Then drive the motor full forward and full reverse a couple of times. Then let the button go. Do this for each Talon and this should even them out a bit for you.

[Kyorox]

Originally Posted by notmattlythgoe

Make sure to calibrate the talons. To do this you press and hold the calibrate button on the talon until it starts to flash multiple colors. Then drive the motor full forward and full reverse a couple of times. Then let the button go. Do this for each Talon and this should even them out a bit for you.

This wont be exact thought correct? It will get them a lot closer though?

[notmattlythgoe]

Originally Posted by Kyorox

This wont be exact thought correct? It will get them a lot closer though?

Correct, there could be other issues causing them to be off in speed, but this should get them close enough to be decently driveable.

[Ether]

Originally Posted by notmattlythgoe

Make sure to calibrate the talons. To do this you press and hold the calibrate button on the talon until it starts to flash multiple colors. Then drive the motor full forward and full reverse a couple of times. Then let the button go.

Center the joystick before letting the button go ?

[notmattlythgoe]

Originally Posted by Ether

Center the joystick before letting the button go ?

Oops, missed that step. Correct.

[Kyorox]

I have the wheels on center now and with a robot builder built code have the drive train working. Although that is wonderful, I am interested in using the generators within eclipse itself.

Would that change the robot's form? And by that I mean from command to simple or ect?

[notmattlythgoe]

Originally Posted by Kyorox

I have the wheels on center now and with a robot builder built code have the drive train working. Although that is wonderful, I am interested in using the generators within eclipse itself.

Would that change the robot's form? And by that I mean from command to simple or ect?

RobotBuilder creates your robot in the Command Based structure. Are you wanting to switch it to something else?

[Kyorox]

Originally Posted by notmattlythgoe

RobotBuilder creates your robot in the Command Based structure. Are you wanting to switch it to something else?

No, I am just curious on which is better to use for the team in the long run. As programming lead it is my best interest to teach the underclassmen for the future. I will take the time during the season and in the off season to teach and share my learning with the other programmers. Fortunately I am a junior so I will be here for at least another year.

[notmattlythgoe]

Originally Posted by Kyorox

No, I am just curious on which is better to use for the team in the long run. As programming lead it is my best interest to teach the underclassmen for the future. I will take the time during the season and in the off season to teach and share my learning with the other programmers. Fortunately I am a junior so I will be here for at least another year.

For the long run, I would personally suggest using the Command Based structure. It is what my team has used since it came out and we couldn't be happier. If you need information about it I can help.

[Kyorox]

Originally Posted by notmattlythgoe

For the long run, I would personally suggest using the Command Based structure. It is what my team has used since it came out and we couldn't be happier. If you need information about it I can help.

I may need help with getting started, or explaining for that matter. Do you usually use robot builder?

[notmattlythgoe]

Originally Posted by Kyorox

I may need help with getting started, or explaining for that matter. Do you usually use robot builder?

We do not usually use robot builder. But it is usually a good place to start. Here are 2 presentations that our team gave on writing everything from scratch.

[cstelter]

Originally Posted by Kyorox

I will look into this though out the day, we havent dabbled much with Robot builder, as we have been waiting for our programming mentor (who we only see on saturdays) to assist us with this matter. With these instructions and what i have found elsewhere its worth the shot.
Please ignore my ignorence, on our team we really stress the "The Kids Run The Team" Motto, so I have had a lot on my plate and offered not to be the head programmer for this exact reason.

There are advantages and disadvantages to the RobotBuilder /CommandBase approach. I only outlined the above because it is possible to use the framework to get a mecanum drive up and running in 10-15 minutes. Also, I'd like to see as many teams as possible adopt this approach as I believe it is the best long-term approach for any team.

Disadvantages

• Takes more time to wrap your head around. You have to start thinking 'object oriented'
• To truly master CommandBase paradigm, you must learn computer science concepts such as polymorphism, inheritance, data abstraction and encapsulation, but you can be successful with only a rudimentary understanding
• It is possible to try to use the CommandBase framework and do it so badly that you get almost no benefit from it. Misusing commands or not properly abstracting what your subsystem can do or hiding the subsystem's internals can lead you into the weeds
• The robot code generated by RobotBuilder with no functionality is more code than many teams code for a fully functioning robot. You don't *need* to know exactly how all that code works, although the more you understand, the more successful you can be. If you don't have a clue what the scheduler is and how it work, it hampers your ability. If you don't understand what is happening in TeleopPeriodic() and how that gets you to your command's execute() method, it will hamper your ability. In other words-- using RobotBuilder starts you with a lot of code that you probably want to read about.
• learning RobotBuilder is an investment in time early on that is not always conducive to the FRC hectic pace.

Advantages:

• Once you have gotten over the learning curve, or if you have a mentor who fully understands the framework-- it is the most powerful way to get to sophisticated control.
• For large teams, the framework allows for groups to break up and take responsibility for separate subsystems in your robot-- each team responsible for coding the functionality of one part and the commands to control them.
• Learning this will give you a head start on college and toward a career in computer science. My son was lead programmer for our team the past 3 years and is now a freshman in college studying computer science. His first semester he was required to take an intro to C++ class (which was fine as he'd not learned C++ yet), but because he had been working with objects and object oriented concepts that CommandBase promotes, he quickly found himself helping other students after class. He was also asking his teacher far more advanced questions than a typical freshman and the teacher noticed all this and hired him as TA for one of her classes his second semester.
• Proper application of the CommandBase framework will make your code far easier to understand and write. You will avoid common issues that arise when one does *not* use CommandBase. You will never find yourself writing code to loop until something happens, or trying to maintain a mess of global variables. Instead of one big nasty function to handle everything, you find yourself writing many very short functions and it is always easy to read 6 lines of code and be sure it will do what you intend it to do rather than reading 150 lines of code an be sure it will do what it is supposed to do.

Truth in advertising disclosure: The electrical team delivered our practice chassis with the shiny new roboRIO to the programmers at 6pm a couple weeks ago. The previous session we had done the first RobotBuilder portion of the sequence but hit a wall because wpilib was not being introduced into the project and none of the functions from wpilib were resolving. We spent 1hr realizing that we had installed Eclipse/Java instead of Eclipse/C++ (didn't read the install directions carefully enough). It took us a full hour to write the 7 lines of code noted above and we kept having to revisit RobotBuilder because my style of teaching is 'OK-- what do we do next? What do we need now that we have this DriveTrain???' What can we currently do with it?? What methods are avaliable to us? They look and realize the class as written from RobotBuilder does nothing but set the default command and that is nothing but comments. So I taught them the concept of adding functionality to a class by providing useful methods and we wrote mecanumDrive and taught them the whole 'just type robotDrive41 and press period' to see what functionality exists on a RobotDrive object, etc. etc.

Finally after 30-40 minutes and teaching what a double is and what parameters are, etc... we wound up with the mecanumDrive() function. Then I ask 'OK-- so now we have a subsystem called DriveTrain that has the functionality of something called mecanumDrive on it. How can we make use of this? How can we command it to do something??

Eventually we arrive at the discussion that we need commands to control subsystems, go back to robot builder and add in DriveWithJoystick, we talk about Scheduler and the role it plays and why we need requires'. Then we get to the question 'OK-- so what else do we need now that we have a command that can control our DriveTrain???' Eventually after much prodding I get them to realize that we need Joystick input and we add the Joytick. By the time we review how a command works and fill out the execute() function there is only one hour left and we spent that flashing the roboRio, etc.

We spent the first hour of the next session setting up routers figuring out how to deploy the code. It took us a full 4 hours of FRC practice following the general cookbook I outlined in my previous post until we even downloaded our first set of code. Thankfully things were working pretty good out of the gate-- one wheel was not spinning at all-- we replaced PWM and it started working. We realized that when we tried to drive forward the right wheels went backwards and I had them invert the right side. So even though you *can* get up and running in 10-15 minutes with the above cookbook-- to properly learn what is going on along the way and be successful when you don't know all the answers going in, you may find yourself needing 3-4 hours.