Continuing Autonomous into Teleop

Is there a rule against continuing your autonomous program into teleop? Autonomous ends and there is a considerable delay between teleop and auton. So could we continue with our autonomous routine into teleop?

For example, in 2017 if our robot still had balls in the hopper, could we just continue to shoot balls until we physically handle the controller? Or if we wanted the robot to move back to a certain position after it’s autonomous routine, can we just tell it to move to a place and if it doesn’t get there, during autonomous, keep going until we input different controls?

Is there anyone that implements this? I feel like the 1-3s of deceleration and re-acceleration for the robot is time well wasted


Some people do it accidentally…

Set your talons to coast mode and pray

To be clear, there is no rule about running a pre-programmed routine in the teleop time period. That said, during the second between when auton ends and teleop begins the robot is disabled, so you cannot give power to any of the motors or change states on any pneumatics. If inertia should keep your robot moving through that second of disable into the first few seconds of teleop, when you continue where you left off in your pre-programmed routing until your drivers pick up the controllers, that is perfectly fine.

Correct me if I’m wrong: I think some form of command-based programming would be necessary here. Achieving continuity while using IterativeRobot (or TimedRobot) would be much harder, as autonomous code is called in the AutonomousPeriodic function and Teleop from TeleopPeriodic.

We write a lot of command groups to use in Teleop.

Last year with a single button push the robot
1 tilted the gear onto the peg
2 drove away from the peg
3 raised the gear manipulator.

That sequence we did a lot so we automated it.

This year a single button press prepared our climb by;
1 drop cube (If had one)
2 raise intake wrist
3 lower scissors
4 engage winch
5 raise hooks to bar
all while the driver positioned the robot for facing the boss.

A command group is an autonomous routine.

One thing to remember is the field does explicitly disable your robot for about a second between auto and teleop, so any motors will definitely lose power during that time period.

Alright fellas. Lets get to work on the new meta of robots that use inertia to continue playing the game during the 1 second disable period. Should be some interesting clockwork mechanisms.

Heck, lets build robots that start playing the game before autonomous starts using entirely non electrical stored potential energy and controls. We could start them with a timed fuse, or an arrow shot at a tensioned rope. Are there any rules against this?

Use half the robot’s allowed weight for flywheels and use that energy to continue to drive! It’s the future!

To everyone else: I forgot the robot disable period. That throws a wrench in things. It might be advantageous to write some code to continue the autonomous routine in teleop until we cancel it manually. Who knows, it all depends on what the autonomous system can do

I have never used the command based robot program, however, from what I understand of it 1817 uses a method similar to command based while extending TimedRobot. We never thought about letting the auto program continue outside of the autonomous period (and put measures into the program to prevent this), but components of our robot retained their autonomous functions that got set in auto.

Necessary - probably not. A quick proof by counter-example:

void teleopPeriodic(){
    if(DriverStation.getMatchTime() > 120.0){
        //do autonomous stuff
    } else {
        //do full driver control stuff

Helpful? For sure. Any architecture that helps you separate the source of the commands for the robot from the execution of the action commanded will probably be very useful for keeping something like this clean and robust.

I actually think this topic deserves much more credit than most people in this thread are giving it. This has been a topic I have wanted to dive into for 2 years now. It hasn’t been realized due to my switch from 1747 as a student to 1646 as a mentor, but it definitely is interesting.

Let’s take a look at this year to start. For a team that can get 3 cubes to the scale in auto, It’s safe to assume that it takes at most 6 seconds to go from scoring a cube on the scale to scoring another. Even with a disable period, scoring another cube on the scale within the first 6 seconds of the match would have been very big. Even if your team averages only 2 cubes from auto, that takes about 8 seconds, which still beats the speed of many strong robots. This game was completely about being fast and first, and this would definitively aid in that.

Some might be hesitant of letting a robot score on its own again, but there is still a huge gain if the robot has grabbed another game piece, ready for the human player to take control, as long as the controller disables the auto when any input is given.

This all may seem quite complicated, so the question remains…

Can only top-tier teams do it?
No! Let’s take steamworks for example. Some first may think that continuing auto would require advanced motion profiling, top-notch speed and precision, some killer hardware, and not to mention balls. However, there is a very simple auto for teams looking to be picked for their defensive abilities. As soon as auto starts, run the robot at full speed onto your opponent’s side of the field, with the intent of hitting one of their robots and starting a pushing match. This sudden burst will be a large problem to deal with, since most teams wouldn’t be able to react with enough time to evade, allowing you to immediately start your defensive countermeasures.

There is a host of options available, and I really do hope to see some of them implemented in the near future. It may seem like only a minor advantage, but it’s a combination of many minor advantages that will take a team from good to great.

In most cases, accomplishing this is advantageous. The question is how to accomplish it best.

For our team, the answer has been (and will likely continue to be) human driver is faster and more consistant than auto. So, for us, the best way to accomplish the strategy is to use the human as soon as possible.

We do usually look to see where we should be “ending” auto to be well positioned going into teleop. We missed the boat on this in 2016, where there was high value in crossing back over a defense (better prep for the first cross in teleop).

We used to do this exact thing for many years. That way if autonomous mode ended before you scored that last object, it would finish scoring it while the drivers were stepping up to the controls.

You do have to be careful because the code is still running while you’re disabled (if you put your control code in the timer loop area rather than in the autonomous area), which means you could be getting a lot of integral windup in your PIDs (as well as other issues). As long as you take care of those things, it can work pretty well.