Emergency Autopick?

So real quick, does anyone know a way to basically autopick selections on an LCD just incase something happens during a match.

Do you mean like a way to switch between autonomous programs at the beginning of a match? If so, refer to this post.

@Joshua_84927A Thanks for the link, but I was specifically referring to a common situation that teams have. So let’s say that in past matches your auton has already started running but for some reason, whatever it may be respectively, your robot has power cycled itself and is currently waiting for a selection to be made. Although, you can’t make a selection since your bot has already moved and so you become the dreaded stalemate. Once again, for clarity, I was wondering if anyone knew of ANY way to code or set an autopick for your LCD in case of an desperate emergency like the one above.

I have the LCD automatically select the first auton if no buttons are pressed within 5 seconds. If a button is pressed, the 5 second count begins again.

Use a potentiometer for auton selection and just let the LCD handle showing the autons picked.

What we did was at the start of the LCD section in pre-autonomous (RobotC) or initialize (easyC), set “autonChoice = 0;” Each auton routine has its own number, which overwrites this “0” if someone presses a button. Then let’s say, that if no one presses a any button, and you want it to fall back to pattern #2, you’d have:

if (autonChoice == 0 || autonChoice == 2) {
   regular code for pattern #2
}

Is this what you’re asking?


If you’re saying that your LCD has a primary option without being chosen and only runs different tasks when a certain button is pressed, then yes.

The way I do it is actually pretty simple. Since RobotC initializes int’s as 0, if no autonomous is picked, then it’ll default to the 0th autonomous routine

I think the issue in question isn’t which selection by default, but rather how to not sit there waiting for a selection to be made. The problem is that, if no autonomous is picked, you could get stuck waiting for a pick.

@Mystellianne and @OscarMNOVA12 gave two different solutions that both work.

Personally, I would rather check the field control. If you’re already in autonomous or operator control, then you’ve clearly reset and you don’t want to wait for a selection. I’m not sure on the RobotC commands to check the field control. In PROS there are isAutonomous(), isEnabled(), isOnline().

So, personally, I have a “do nothing” program as selection 0. The selection variable, in my case routineNum, is initialized and defined to be 0, just as @brendanmcguire said. So, by default, if nothing is selected, that runs during autonomous.

As for what @callen was saying, I believe those PROS booleans are the following in RobotC:


 while(!bIfiAutonomousMode || bIfiRobotDisabled)
{
    //Selector code
}

Also, I had a second thought. I’m not sure how this would work cause I’m not really sure how the cortex handles the fundamental (autonomous & usercontrol) tasks. But what if you had a task that you start in pre_auton() that handled emergency switching?


task emergencySwitcher()
{
    while(true)
    {
        //If not in autonomous and not disabled - so in driver mode (at least if plugged into field control)...
        if(!bIfiAutonomousMode && !bIfiRobotDisabled)
        {
            //Stop autonomous selector
            stopTask(autonomousSelector);
            //Stop autonomous task
            stopTask(autonomous);
            
            //Start driver control mode
            startTask(usercontrol);
            break;
        }
        else
        {
            //Do nothing
            wait1Msec(500);
        }
    }
}

void pre_auton()
{
    startTask(emergencySwitcher);
    
    //Sensor initialization
    SensorValue[myGyro] = 0;

    //Start autonomous selector
    startTask(autonomousSelector);
}

This is always safest.

But Tasmanian Devil Middle Side Mode is much more productive

I do the same thing. At first, we have a selection screen where we choose our autons. If a button is pressed, it resets the timer, and if the timer reaches 5 seconds, it selects whatever auton is currently on screen and continues to go to driver control.

I know this is a slightly old thread, but this happened to us twice at FL states. The first time we were dead on the field after the reset as the robot was waiting for a selection. We were only running one auto in every match anyway, so we commented out all the LCD auto selection code to prevent this. The second time it reset we were able to play after the reset.

We thought about how to fix this in the future, but haven’t coded the new robot for world’s yet. The idea is going to be using a jumper in a digital port. After selecting auto, the drivers are going to pull out the jumper. The auto selection routine is going to first look for that jumper. If jumper is in, wait for a selection. If jumper is out, do nothing. This will avoid the extra 5 second delay other teams are talking about before falling out of the auto selection.

@rsoviero Hm… That works, but in my opinion, that somewhat contradicts the convenience of the LCD display. I may be stubborn, but I personally still think that using the booleans


bIfiAutonomousMode

and


bIfiRobotDisabled

is best. That way, when the robot starts, it will immediately exit the selection loop and run the default autonomous.