Really underhanded

[Kyorox]

I'm a junior at Whittier Tech, and lead programmer for theFRC robotics team, The Maroom Monsoon. We really need help from a little bit of everyone. Due to weather we have been set back 8 days.
It is my main priority to ask you guys for help in Java programming using mecanum wheels and the eclipse software.
Our head programmer last year was very anti-sociable and programmed the entire robot then graduated without keeping note of what he did or how.

I have a place to start,
I have been studying and reading plenty of other fourms and have been practicing myself, along with my team, but our efforts prove somewhat meaningless when our robot is so behind. We have little to no way of knowing what we are doing without having something to physically test on, and the limited amount of time remaining worries me. We had preiviously asked Reddit for advice and got some wonderful responses however, we are too inexperianced to understand exactly what has been coming through.
What I'm trying to ask is if it is possible that there is a way to test what we have without having a robot to physically do this with? We also have very to no experiance with what we have. I have been practicing with eclipse along woth some fellow classmates, but they have mainly been on code academy practicing, and writing sample programs in netbeans and now in eclipse.

Please respond as though we are a rookie team although this is our second year.
I am an Admin for this team and widely looked up too, I still need advice on many other topics of interest as well.

[Ben Wolsieffer]

The screensteps have lots of useful information if you haven't seen them yet, especially regarding the setup of the programming environment and the electrical system.

If you can, I would recommend creating a benchtop electronics board with the just the basic components and maybe a couple of motors and motor controllers for testing. This would help you test parts of your code and also get the software setup without an actual robot.

Feel free to ask for help with problems you encounter along the way, and people here will be more than willing to help you.

[virtuald]

Originally Posted by Kyorox

What I'm trying to ask is if it is possible that there is a way to test what we have without having a robot to physically do this with? We also have very to no experiance with what we have. I have been practicing with eclipse along woth some fellow classmates, but they have mainly been on code academy practicing, and writing sample programs in netbeans and now in eclipse.

Well, this sort of thing is why I created pyfrc -- it contains a very simplistic robot simulator so you can see immediately what your robot motors/sensors are doing. Since it's written in python, it's only available to teams using RobotPy to program their robot. Of course, without mentor support, I wouldn't recommend switching programming languages this late in the season...

Search the forums for CCRE -- I believe it has a similar capability for Java.

Other than that, I'd definitely create a benchtop electronics setup so you can try simple things as lopsided recommended.

[Kyorox]

We have two programming mentors who visit us on saturdays, but thats the only time we have them. We have seen them about 4 times, 2 times since we learned the game. They are trying to help, but without much information and lack of communication we dont get to far.
We have a benchtest board with motors and such on it, but the motor controllers are not the same as the ones in the robot, will that effect the program?

[Ben Wolsieffer]

You will have to change the type of motor controller in the code when you switch from the test board to the real robot, but other than that your code should be the same. If you forget to change the type, you may end up with some unusual and hard to diagnose behaviors, due to slight differences in the way the controllers communicate.

[Kyorox]

Unfortunately, I would love to be able to update this more often, but students are not allowed to bring the clasemate home under previously developed rules.

But I appreicate the feedback, we very unexpericanced and I know I am going to need more help, but without the classmate I can't post sample code, nor can I even veiw the code *sigh*

[Ben Wolsieffer]

Would it be possible for you to set up Eclipse and the FRC plugins on another computer? I know for me, it would be very difficult to get all our code written just during build meetings. For a simple code sharing system, I would recommend using Dropbox, which simply synchronizes files over the internet. We used this for a couple of years, and it works well enough as long as two people do not edit the same file at the same time.

While I wouldn't recommend trying to set this up this far into the build season, it would be a good idea to look into using a real version control system, such as Git. This allows for easier code sharing and the ability to keep track of changes over time.

[Kyorox]

The only real form of communication we have at the moment is a teacher run twitter page, so I will look into something like this sooner than later.
We thought about using a google Doc but decided against it.

[Kyorox]

After eight days of snow and a 2 hour meeting after school we have a wheel spinning. Only one, and it is thanks to a sample program and a few screen steps.

[emusteve]

If you'd like to PM me to exchange email addresses, I'd be happy to send you some basic drive code, with examples for setting up a Digital Imput, Relay, and a mechanism motor.

Also, it is possible to get to the source file and view it with WordPad. To find the source file for your project, open the Workspace folder, and the folder within that has your project name. Within that, open "src", then "org", "usfirst", "frc", "team####", "robot", and at the bottom of the tree, you'll find a file named "Robot.java. That is your source file for the project. You can copy it, view it, and even edit and replace it. (But keep a copy of the original, if you decide to make any changes!). If you just want to take it home to study, or for documentation, you can always print it from within eclipse, using a utility like Cute pdf.

Hope this helps.

[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

[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.