We’ve set up our robot’s code using java to run Jaguar motor controllers via a DriveTrain subsystem. Thing is, the DriveTrain’s execute() method is only being called once every 10-15 seconds. This means that we push the joystick forward, wait a few seconds, and the wheel starts spinning, then, when we release the joystick, we have to wait another 10-15 seconds for it to update again to stop. If you need code/other information, let me know and I’ll post it. Thanks in advance.
What format of code are you using? The command-based?
Yes, command-based.
Have you checked to see if its a networking issue, are you losing packets?
We put some print statements next to the command statements; they’re running just as slowly on the computer, so I don’t think it’s a network thing. Also, he computer is wired directly to the dlink at the moment (wireless cut out for some reason). If you have other suggestions on how else to test the network, let me know and I’ll try it.
You don’t have two driverstations open do you?
This happens sometimes when there’s one open on the driver account and one open on the developer account.
No, I even restarted the computer just to make sure. Only one driver station running. We’re going to try reimaging the cRIO without the CAN drivers to see if that is having some effect.
We tried running it without the CAN plugin, no luck, we’re reimaging the entire thing.
The commands are run by repeated calls to Scheduler.run(). Make sure that it’s being called in the teleopPeriodic() or autonomousPeriodic() methods in the main robot project like this:
public void teleopInit() {
// This makes sure that the autonomous stops running when
// teleop starts running. If you want the autonomous to
// continue until interrupted by another command, remove
// this line or comment it out.
if (autonomousCommand != null) autonomousCommand.cancel();
}
/**
* This function is called periodically during operator control
*/
public void teleopPeriodic() {
Scheduler.getInstance().run();
}
Also you can verify that the commands are running by writing the Scheduler instance to the SmartDashboard as shown in this web page:
http://wpilib.screenstepslive.com/s/3120/m/7932/l/97019-displaying-the-status-of-commands-and-subsystems
Brad
We have the Scheduler.getInstance().run() in the code already. I tried the SmartDashboard thing, its says it’s running. I have print statements in the execute() method, they running, but only once every 10-15 seconds.
Try deploying a blank SimpleRobot project with a print statement in the operator control method
Can you put a print statement in the teleopPeriodic() method to see how often it (and Scheduler.run()) is getting called. It should be about every 20ms (50 times per second).
Brad
We tried running a simple robot; the problem does not occur. We tried putting the print in the teleopPeriodic; it was being called about once every 10 seconds.
I think the issue is you are using loops in your code.
Iterative and Command based robots should NOT be using “while” or “for” loops (generally) in their code. The methods are already looped for you, and long loops will mean that any “simultaneous” commands will be put on hold until the loop is complete.
The Simple template handles looping code by interrupting it periodically, and so you won’t see any issues there.
We double checked, there are absolutely no for or while loops anywhere in the program…
Are there any delays in your code which are implemented as busy-waiting?
It might be helpful if you posted your project.
I have absolutely not idea what’s slowing it down. The good news is that the delay is now only about 2 seconds (no idea why) but that’s still too long. The entire project is attached.
4024-2013.zip (1.35 MB)
4024-2013.zip (1.35 MB)
The starting of a command in teleopInit is not conventional. I would suggest removing that as well as making another subsystem that implements all your drive motors. This command would be the one that has the default command of normDrive as well as being the subsystem normDrive requires. Also, after doing the above, make sure to remove all the require commands from your motor subsystems.
What I believe is happening is your starting 5 normDrive commands in your code, which are all trying to control the same thing at the same time, which could possibly be your delay issue.