Autonomous Didn't Start Every Time


At our first event, Georgian College, Barrie, Ontario our Auto didn’t work every time. It worked when we tried it in the pit, then would just sit there during the match. Tele worked fine.

Any thoughts?

YES we had the same issue! From the debugging we did, it seemed like autonomous wasn’t even being entered, because gyro zeroing code that should’ve been called when it initialized wasn’t even called. However, when we removed our custom chooser system and hardcoded in which auto mode we wanted to run, it worked fine. It’s quite a weird predicament.

We have had issues with Smart Dashboard input during disabled in the past. We now use input from the joysticks to cycle through auto modes to verify that the mode is set properly on the rio.

Ours was just a very basic Auto, “drive forward”.

No need to select anything from anywhere.

My team has used switch cases with dashboard sliders being the switch, and it works every time. It looks like this:

try {
int slider1 = (int)Robot.oi.getDashboardSlider0();

		switch (slider1) {
		case 0:
			autonomousCommand = new AutoDoNothing();


//Also a catch statement would go here

Post your code.

It could be as simple as you not energizing your driver motors enough. 0.15 is enough to get the motors spinning in the pit, but you need at least 0.25 to get the robot moving on the field.

You can look at the driver station log for the match. It has some ‘dots’ across the top of the log which indicate when your robot thought it was in autonomous and operator control modes. If you post your code we can probably figure out what happened too.

I’m not OP but when we had this issue, and FTA came and looked at our logs and said that we were entering autonomous. It seemed pretty clear that we weren’t entering the selected mode correctly though. I think I would probably chalk it up to a SmartDashboard communication issue just before the match starts.

Yes, please show us your code. I didn’t realize you were having code troubles, maybe we could have helped you out. Oh well.

After hearing so many horror stories about Chooser modes and software issues, we have gone with a hardware solution to choose our autonomous modes. We use a 12-position rotary switch that can be read by the RoboRio. It’s not perfect, but it has never failed us.

(That said, you might have noticed that we were having our own autonomous troubles at the Barrie event. The robot seemed to wander unpredictably. Chalk that up to a faulty encoder that we discovered at the end of quals. Oops. :eek: )

Do you mean cement vs carpet?

This will depend on the event as well. Pit floors could be cement, or some kind of covering over a hardwood gym floor. Our Ryerson district event was held on the surface of an ice rink with plastic floors on top.

Some teams bring a patch of carpet to serve as their floor surface. We like to bring interlocking foam “puzzle piece” floors.

In any case, the point applies that the driving characteristics could be different. The practice field, assuming it is carpeted, is probably a better place to test.

Nope. In the Pits, you can’t have your robot moving, so the robot wheels are not in contact with anything. At 0.15, you can get a motor to move that has little resistance. If you are trying to get the motors to move the robot, that is a lot of resistance, and you need more power, around 0.25 at a minimum.

So, by saying that “it worked in the pits”, it begs the question: What “worked”?

If they said it worked on the Practice Field, then it narrows down the possibilities.

We’re starting @ 0.85

Here’s our Auto code. Please let me know if you need more.

* This function is run once each time the robot enters autonomous mode
public void autonomousInit() {

	speeddrive.arcadeDrive(0.85, 0);
	 * speeddrive.arcadeDrive(0, 0); frontleft.setSpeed(-0.5);
	 * Timer.delay(1); backleft.setSpeed(-0.5); Timer.delay(1);
	 * frontright.setSpeed(-0.5); Timer.delay(1); backright.setSpeed(-0.5);
	 * Timer.delay(1);
	speeddrive.arcadeDrive(0, 0);

This might be more style than substance:

autonomusInit should be used for initialization.

AutonomusPeriodic (or AutonomusContinuous) is where you want your real code.

Maybe FMS doesn’t see you exit autonomusinit (in a reasonable amount of time), and does something strange.

> speeddrive.arcadeDrive(0.85, 0);

Only energizing one set of wheels? Are the others in coast or brake mode? If brake mode, then your one set of energized motors has to be able to overcome brake mode of the other.

Here is the structure we would use:

Set a timer to 0, and start counting (or get system time)

If (timer<1.3 seconds) then
speeddrive.arcadeDrive(0.85, 0);
speeddrive.arcadeDrive(0, 0);

Actually, our structure is more complicated than that. In AutonomusPeriodic, we have a command que, and execute each command in sequence. We would use AutonomusInit to build the command que depending upon switches (where is the robot starting, and what do we want it to do).

FYI: In a prior year, there was an FMS glitch that caused AutonomusInit to be called more than once. Write your code to look for that, and ignore subsequent calls to AutonomusInit.

Hey rich,

I was wondering about that. A number of people saw our code but nobody mentioned it.

In robotInit we have:
“speeddrive = new RobotDrive(frontleft, backleft, frontright, backright);”

Thanks for all the help. Will make changes and try it out.


> speeddrive.arcadeDrive(0.85, 0);

I just realized you are using arcadedrive, rather than directly controlling motor values.

FYI: by calling “speeddrive.arcadeDrive(0.85, 0);” every iteration (autonomusPeriodic), that keeps the watchdog happy, and you don’t have to worry about “speeddrive.setSafetyEnabled(false);” unless you code hangs, in which case you want the watchdog to turn off your motors. We have variables for each motor that is set during autonomusPeriodic/teleopPeriodic, and at the end of each iteration, the values are sent to the motors. That minimizes the risk of one routing wanting one value, and another routine wanting another.

This is definitely not a difference in style. This is it right here. What the OP’s code is telling the robot to do in autonomousInit is:

  1. Drive forward with 0.85 power.
  2. Suspend processing for 1.3 seconds. This means signal will not be sent to the motor.
  3. Stop moving.

It’s likely that motor is getting a very brief signal but perhaps it’s too small/quick to see.

This works because the robot’s processing is not paused. autonomousPeriodic is called back approximately every 20ms.

Then why would it work in the Pits, but not on the Field? The only difference being the FMS system.

Last season we also had our share of sendablechooser hang ups. We found in the off season after adding a Kangaroo running GRIP we had to restart the smartdashboard to get the grip mjpg steam. This also seemed to help the autochooser work every time too.
I like the case statment and slider option mentioned at the start of this thread. I’m going to have the team look at this before next week. We have been having some trouble with the sendablechooser not even displaying on the smartdashboard. We have to select file>new and reset everything forcing us to add our camera feeds back in and organizing everything.