Code for Can jaguars.

[wolfspell12]

We were asking some questions about CAN jaguars in this topic, and some questions came up that we figured were more closely related to programming. I quote the statement that brought up my question:

Regarding the Jaguars -
Assuming that you intend to do PID wheel speed control inside the Jaguar (which is a fine distributed processing architecture), the Jaguar must be connected to the cRIO via CAN (not PWM) and the encoder is connected directly to the Jaguar.

I strongly recommend doing a CD search for old threads on PID and Jaguar for more info. Velocity loops are tuned differently than position loops in that the loop must integrate the encoder error to get the control velocity. The recommend method of tuning is to start with P=0, I=small, D=0 and increase I until just before speed is unstable. Then increase P to further improve stability.

As mentioned in post 2, the gyro outputs angular velocity and I don't believe it will interface directly with the Jaguar. The standard WPI mecanum code I believe does handle the gyro for you on the cRIO, but I have never used that code. The WPI code may also assume that the encoders are hooked to the cRIO and not the Jaguars - you will need to verify that first.

So I am wondering if the API assumes that encoders are plugged into the cRIO , or the Jaguar. The object constructors for the encoders calls for a DigitialSource object, and the javadoc for that only says that it can be analog or digital. If someone could help explain, that would be very helpful. Some help learning how to code CAN jags in general would be helpful-The screensteps from FIRST are a little lacking from what I could find from a search on CAN jaguar a minute ago. (If you can skype then that might be good.)I hate to create a second topic for this but it seems to be a little beyond the knowledge of the people in the sensors section.

[otherguy]

I haven't implemented code for any of this myself, but from what I can tell from the wpilib source and javadocs:

The mechanumDrive_Cartesian (which you talk about using in the other thread) expects the x and y values you are passing in to be scaled from 1.0 to -1.0 implying that this method is driving the motor controllers open loop. So no encoders are being used by this method.
Furthermore the source calls the .set() method for the SpeedController. I'm not sure this will work if you're using the CANJaguar class. .set() is deprecated. You're supposed to use .setX()

IF you are dead set on using a CANJaguar, with encoders wired to them, and use the mechanum cartesian method... you could always write your own implementation of the mecanumDrive_Cartesian method. The source is here, it shouldn't be that hard to modify for your own uses.

The gyro should be wired in to the crio.

Also, using the Encoder class, for encoders, implies that the encoder is wired to the DSC. There are many constructors for the Encoder class. Fore example you could just pass in the pin numbers that the encoder is plugged into.
The constructors taking in DigitalSource objects would be used if you had already created a DigitalInput object for the specific pin your encoder is wired to.

[Joe Ross]

Almost everything in WPILib and the documentation assumes that the sensor is plugged into the cRIO. This includes the PIDController class and PIDSubsystem, etc.

The CANJaguar class is what is used to do PID on the Jaguar. You set the appropriate mode (vbus, position, speed, or voltage) and configure all of the appropriate options. I recommend getting your desired mode working with BDC-COMM first and then copy those options to your robot code.

Other people have posted code using the CANJaguar class, I'd suggest doing some searching.

[wolfspell12]

Perhaps I should have clarified a little about our current control setup. We plan to plug our encoders into the jaguars-if I'm understanding what you're saying correctly, the CAN Jaguar class is what you use for an encoder if it's plugged into a jaguar, and the Encoder class is used for connection to the cRIO?

The encoders are only receiving real use in autonomous, which will drive forward and deposits a ball in the one point goal if one was pre-loaded, once we've actually written that command. During teleop, the plan would be open loop control as implied by a Cartesian method. Is something like that feasible, and does something like that require a separate subsystem for the drive? Will switching to an open loop system mid-game still work when the Jaguars are only connected via the CAN bus? I do see a .disableControl() method that sounds like it disables closed loop control-but I don't know if that would enable open loop control.

Alternatively, if we need to rewrite the source, would that be productive, how hard is it, and are there any questions on legality? Could we get some guidance on doing so?

There is the final option of using encoders during teleop, without the gyro, which is something I'm just as unfamiliar with as the CAN Jaguar system itself. It doesn't look like anything in the RobotDrive class is compatible with CANJaguar objects, and I don't know how to write a drive code with simply the CAN Jaguar class, though I think the percent vbus thing is the most simaler to RobotDrive.

While I know which is which in the code (CAN Jag is closed; RobotDrive is open), an explanation of how open and closed loop are different would also help me make more sense of this.

[gpetilli]

Wolfspell
If you are connecting the encoders to the jaguars, then you do not use the encoder class on the cRIO.

You should start by hooking the jaguar to a laptop using a serial cable and BDC-Comm software to debug the parameters that you want to send to the jaguar. When you configure your drive software, you can assume the the command to the jaguar is "ideal" and not use close loop control on the cRIO for wheel speed. Be sure to set the right side motors to inverted on the cRIO; the feedback to the jaguar will be inverted if you try to reverse the motor leads to invert the direction.

If you are using a gyro, that still gets connect to the cRIO for rotational control, which will modify the commands sent the the "ideal" jaguars.

[wolfspell12]

Thank you for the help so far. I left the topic open but unattended for a while because I anticipated more potential problems. We have a problem right now.

While we were successful with firmware updates, (Hardware Version 2, Firmware Version 107) the Jags refuse to set to anything other than 1 for CAN ID. If you try and assign something else, then it just defaults or reverts back to 1.

If anyone has any clue, that would be helpful.

EDIT: While unrelated to Jaguar problems, an additional problem has popped up in our Command-Based robot. Robot Builder's autogenerated code:

 
// RobotBuilder Version: 1.0
//
// This file was generated by RobotBuilder. It contains sections of
// code that are automatically generated and assigned by robotbuilder.
// These sections will be updated in the future when you export to
// Java from RobotBuilder. Do not put any code or make any change in
// the blocks indicating autogenerated code or it will be lost on an
// update. Deleting the comments indicating the section will prevent
// it from being updated in the future.
package org.usfirst.frc3244.RobotTest.subsystems;
import org.usfirst.frc3244.RobotTest.RobotMap;
import org.usfirst.frc3244.RobotTest.commands.*;
import edu.wpi.first.wpilibj.*;
import edu.wpi.first.wpilibj.command.Subsystem;
/**
 *
 */
public class Compressor extends Subsystem {
    // BEGIN AUTOGENERATED CODE, SOURCE=ROBOTBUILDER ID=DECLARATIONS
    Compressor compressor1 = RobotMap.compressorCompressor1;
    // END AUTOGENERATED CODE, SOURCE=ROBOTBUILDER ID=DECLARATIONS
    
    // Put methods for controlling this subsystem
    // here. Call these from Commands.
    public void initDefaultCommand() {
        // BEGIN AUTOGENERATED CODE, SOURCE=ROBOTBUILDER ID=DEFAULT_COMMAND
        setDefaultCommand(new compressorStart());
    // END AUTOGENERATED CODE, SOURCE=ROBOTBUILDER ID=DEFAULT_COMMAND
	
        // Set the default command for a subsystem here.
        //setDefaultCommand(new MySpecialCommand());
    }
}

causes netbeans to display an error message at line 20: "incompatible types: edu.wpi.first.wpilibj.Compressor cannot be converted to: org.usfirst.frc3244.RobotTest.subsystems.Compresso r". The RobotDrive has the same problem.

[gpetilli]

Originally Posted by wolfspell12

While we were successful with firmware updates, (Hardware Version 2, Firmware Version 107) the Jags refuse to set to anything other than 1 for CAN ID. If you try and assign something else, then it just defaults or reverts back to 1.

This may be a stupid question, but did you press the reset button with a paper clip and send the CAN ID change while the light was blinking? Sometimes they get finicky about the timing of pressing the button.

[wolfspell12]

We didn't even know there was a reset button.

While that worked, we're leaving CAN and command-based robots behind until next season or next summer when we've got time to play around and get them to work. Thank you for helping us learn what we have about CAN, and we hopefully won't have any more troubles till we try and learn PID tuning.

[L_bot]

EDIT: While unrelated to Jaguar problems, an additional problem has popped up in our Command-Based robot. Robot Builder's autogenerated code:

 
// RobotBuilder Version: 1.0
//
// This file was generated by RobotBuilder. It contains sections of
// code that are automatically generated and assigned by robotbuilder.
// These sections will be updated in the future when you export to
// Java from RobotBuilder. Do not put any code or make any change in
// the blocks indicating autogenerated code or it will be lost on an
// update. Deleting the comments indicating the section will prevent
// it from being updated in the future.
package org.usfirst.frc3244.RobotTest.subsystems;
import org.usfirst.frc3244.RobotTest.RobotMap;
import org.usfirst.frc3244.RobotTest.commands.*;
import edu.wpi.first.wpilibj.*;
import edu.wpi.first.wpilibj.command.Subsystem;
/**
 *
 */
public class Compressor extends Subsystem {
    // BEGIN AUTOGENERATED CODE, SOURCE=ROBOTBUILDER ID=DECLARATIONS
    Compressor compressor1 = RobotMap.compressorCompressor1;
    // END AUTOGENERATED CODE, SOURCE=ROBOTBUILDER ID=DECLARATIONS
    
    // Put methods for controlling this subsystem
    // here. Call these from Commands.
    public void initDefaultCommand() {
        // BEGIN AUTOGENERATED CODE, SOURCE=ROBOTBUILDER ID=DEFAULT_COMMAND
        setDefaultCommand(new compressorStart());
    // END AUTOGENERATED CODE, SOURCE=ROBOTBUILDER ID=DEFAULT_COMMAND
	
        // Set the default command for a subsystem here.
        //setDefaultCommand(new MySpecialCommand());
    }
}

causes netbeans to display an error message at line 20: "incompatible types: edu.wpi.first.wpilibj.Compressor cannot be converted to: org.usfirst.frc3244.RobotTest.subsystems.Compresso r". The RobotDrive has the same problem.

In response to your compressor problem if you change the subsystem name of the compressor to something like Airmaker or Airgetter it will fix the problem. The reason for this is because Robot builder does some auto naming and will try to call your compressor from another location.

[gpetilli]

Originally Posted by wolfspell12

We didn't even know there was a reset button.

While that worked, we're leaving CAN and command-based robots behind until next season or next summer when we've got time to play around and get them to work. Thank you for helping us learn what we have about CAN, and we hopefully won't have any more troubles till we try and learn PID tuning.

If you were not pressing the reset, then you never changed the ID and the rest of your CAN chain problems make sense.
I do recommend that you try this over the summer. CAN can be very powerful once you get used to it. Next season we switch to the new controller, which is more heavily CAN based (PDB and solenoids are CAN based) so some off-season experience should payoff.