PID onTarget() Updated

Technical Java
1

We been working with PIDcommands and through some searches came to the understanding that the onTarget() method had bugs and was unuseable this year. We came across a thread that mentioned it was repaired in an update to the wpilib so we ran the install new software in Eclips “FRC Plugins - http://first.wpi.edu/FRC/roborio/release/eclipse/”
Two things happened on didn’t
First one of our subsystems that

extends PIDSubsystem implements SpeedController

found errors and needed to add unimplemented methods. It was:

@Override
	public void stopMotor() {
		// TODO Auto-generated method stub
		
	}

The second was we are getting an error on the console

ERROR 1 Robot Drive... Output Not updated often enough. java.lag.Thread.run(Thread.hava:745)
Error at java.lang.Thread.run(Thread.java:745): Robot Drive... Output Not updated often enough.

Finnaly onTarget() still not worky

Any direction you can point us?

2

Could we get your full robot code please?

3

Here is a link to our Github. Enjoy the read :eek:

The working file is named SirAntsABot_Summer. If you brows up the tree there are progressive copies of the program of the summer “Copy SirAntsABot_Summer_YYYY_MM_DD_HHMM”
https://github.com/GraniteCiyGearheads3244/FIRSTStronghold2016/tree/master/SirAntsABot_Summer

4

Just a few notes with git:

  • don’t put binary files on git. That means you should add bin, build, and dist to your .gitignore
  • don’t manually version files. That’s what git is for. Instead of “SirAntsABot_Summer_YYYY_MM_DD_HHMM”, you can use branches or tags to keep track of the versions.
    ​ ​ ​ ​- use branches if you have several different versions of the code that you’d like to develop independently of each other
    ​ ​ ​ ​- use tags if there are previous versions of the code that you’d like to name for easy reference

Now looking at NordicSpeedController, I’m confused as to why you are extending SpeedController yourself. You shouldn’t be doing that when you’re just wrapping a CANTalon. Second, the Talons have built-in PID control which has a much faster update loop since it’s internal to the Talon itself. Just connect the encoder directly to the Talon and call PID methods on the CANTalon object - see section 10 of the software manual and section 1.4 of the user’s guide. The Talon’s own PID also isn’t subject to WPILib bugs (such as the one with onTarget()) so it’s more reliable to use.

5

Thanks for the feed back and all really great points. This was my first year with competition robotics and the first year for the team with a full time technical mentor (Me). I personally never used a repository and the team specially. I understood the idea as you pointed out and likely should start now vs. latter using it properly.
Your right on the CANTalons but again as a new member my voice didn’t have a vote in the correct way to use the controls properly. Just a matter of the dynamics of our team. (Lots of not enough time to do it right the first time so lets try a second) Anyhow I’ve been given the position of lead mentor so now we/I can try to figure out and demonstrate how to use the controls to their fullest ability and hopefully get some breakout boards to the team to test with.

Are you thinking its the “SeaLegs” drivetrain that is causing the error? Or is it the fact that we have two RobotDrive type objects.

RobotDrive robotDrive41 = RobotMap.driveTrainRobotDrive41

and

RobotDrive seaLegeDrive21 = RobotMap.seaLegsSeaLeg_Drive;

The robotDrive41 is our primary drive train (Wheels) the SeaLegs are a set of CAM’ed legs that walk the bot over obstacles.

The NorticSpeedControler was a bit of code team NorticStorm shared with us just after RecylingRush. It help a lot with that years drive train with driving low speed control of the robot. With this years WPILIB something broke even they said it reacted differently so the main drive went back to a more traditional configuration but with our “SeaLegs” it still seem to help with the control of the subsystem.

6

I see.

The second error you’re getting kind of tells you what it is. You need to update the output of a RobotDrive on every iteration, unless you set it to 0. Your codebase is quite large so I can’t find why updates aren’t happening at the moment, but check to make sure your joystick commands are running at all times during teleop, etc.

7

Yep Lots to mill through. It could likely use some clean up clearing out old commented out lines and commands that are not used. Anyhow through this conversation I been Looking deeper into what maybe happening. I see the “Sealegs” subsystem has

 setDefaultCommand(new SeaLegs_Jog_FWD());

That Command never finishes and is constantly getting the joystick values and updating the SeaLegs motors. We do have other commands that requires the SeaLegs subsystem but they finnish and the default regains control.

Plus in the RobotMap when the RobotDrive object is created we set the Safety false

 seaLegsSeaLegDrive.setSafetyEnabled(false);

So I’m looking at the driveTrainRobotDrive41 created in the RobotMap. Robotbuilder generated this code.

driveTrainRobotDrive41.setSafetyEnabled(true);
        driveTrainRobotDrive41.setExpiration(0.1);
        driveTrainRobotDrive41.setSensitivity(0.5);
        driveTrainRobotDrive41.setMaxOutput(1.0);

Should we look at the .setExpiration(0.1) value? Specially if we are controlling the Subsystem in the temporary PID command " Drive_Spin_In_Place_PID_TrackTarget"?

Thanks for listening and being a sounding board.

8

Wait .1 or 100ms should have 5 code scans.

9

I think I’m going to run these parts in the execute method to see if there is a part that is taking too long

private double t_loopstart, t_loopend, t_getCX, t_getSpin, t_setSetpoint;

// Called repeatedly when this Command is scheduled to run
    protected void execute() {
    	t_loopstart = timeSinceInitialized(); // seconds since startup
    	double cX = Robot.vision.my_Get_Xcenter();
    	t_getCX = timeSinceInitialized(); // seconds since startup
    	double spin = Robot.vision.my_SpinToTarget_Lookup(cX);
    	t_getSpin = timeSinceInitialized(); // seconds since startup
    	m_setpoint = Robot.driveTrain.my_Get_Gyro() + (spin*-1);
    	t_setSetpoint = timeSinceInitialized(); // seconds since startup
    	//getPIDController().setSetpointRelative(spin*-1);
    	getPIDController().setSetpoint(m_setpoint);
    	t_loopend = timeSinceInitialized(); // seconds since startup

        SmartDashboard.putNumber("t_loopstart", t_loopstart);
    	SmartDashboard.putNumber("t_getCX", t_getCX);
    	SmartDashboard.putNumber("t_getSpin", t_getSpin);
    	SmartDashboard.putNumber("t_setSetpoint", t_setSetpoint);
    	SmartDashboard.putNumber("t_loopend", t_loopend);
    	

}

Then plot on line graphs

10