Disableinit() did not execute when robot is disabled

Technical Java
1

Our code:

boolean second_loop = false;

public void IntakePeriodic() {
if (run_intake) {
Intake.Run_Intake(SmartDashboard.getNumber(“Intake Speed”,
Constants.Intake.INTAKE_SPEED));}
else {
Intake.Run_Intake(0);
} }

public void Init() {
Intake.Disable_Compress();
run_intake = false;
Shooter.Shoot(0);
Shooter.Run(0);
}

public void Enable_Intake() {
    Intake.Enable_Compress();
    run_intake = true;
}

robot.java:

@Override
public void disabledInit() {
Robot_Pause();
ShootSub.Init();
}
@Override
public void robotPeriodic() {
ShootSub.IntakePeriodic();
ShootSub.ShooterPeriodic();
}

Why shooter didn’t reset?

2

It would really help to have access to the full code. As a minimum in that case the shooter is quite essential to debug the shooter.

1 Like
3

It really depends on what is in ShooterSub.Init()

You can tell if the code is executing by putting a flag out wth SmartDashboard. IF you are expecting any movement in the ShooterSub.Init() it won’t happen. The motor safety protocol will prevent any motor controllers from running motors while disabled.

4

Alao, if any of those custom classes are loops, the robot may not actually ever get into DisabledInit() or periodic when it is disabled. That could be dangerous.

5

So you mean if there are some code executing periodically, the robot will not get into DisabledInit()?

6

Yes, any blocking loops in methods called by periodic or init methods will block the main thread until the loop ends

7

Not exactly. When we programmed in labview it was easy to create a situation that could cause the code to get “stuck”
Any loop that is waiting for a condition to exit has the potential to be a loop that holds up the main thread until that condition is reached.

It is difficult to create one that also feeds the watchdog (so the typical behavior when this happens is that the motors do not run), but not impossible.

Init is just a command. So if the robot is eaiting for another command to finish, it will not get called until that other command is called.

For this reason, we use the built in main loop for all of our (looping) functions (save for filling an LEDBuffer) and just run conditional checks on that thread. There are other ways to handle this, but this is the simplest for us that also avoids race conditions.

1 Like
8

In this case they are using Java which by default is single threaded. I wouldn’t recommend using a separate thread in a Java project unless you know exactly what you’re doing and how to avoid concurrency issues.

1 Like
9

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.