TeleOp Init/Stop vs. Auton-Iterative Init/Stop

[Ziaholic]

I've been going through the subVI's for the Robot Mode and Derived States and I'm having a hard time determining the exact flow that the competition's game-control/management system will push us through ... and do the driver-station buttons emulate what we'll see on the field ...

The Robot Mode has 6 states ... and I'm guessing that they'll flow in this order when we're on the playing field:

Autonomous Disabled
Autonomous Enabled
Teleop Disabled
Teleop Enabled
Finish (?? Maybe a Teleop Disable before the Finish ?? I dunno.)

(the 6th state is Timeout and it's the exception when we don't get a DS packet)

I'm hoping that when we emulate that on the DS, it's the same as what we'll see on the field.

Now, inside both the Auton and Teleop structures, we have the Derived Robot State of

Init
Execute
Stop

... and this is where my analysis of their subVI's breaks down. I'm not sure if we sit, looping, in the INIT state while we're "disabled" the entire time ... or do we only get one time thru the INIT state.

... and will my Auton get a chance to run it's STOP case as we transition between Auton-Enabled and Teleop-Disabled?

... similarly, will my Teleop get a chance to run it's STOP case as we transition to FINISH?

Sorry if this has been asked to death, but the keywords that I searched for brought up quite a mix-mash of posts, and nothing really covering my questions.

[Joe Ross]

You can use the driver station to simulate a match and get the transitions. I believe your flow is correct, except that finish is never called unless the finish button is clicked in Robot Main. Since you can't do that on the field, finish is never called when you are on the field. If you are just using closing device references, that shouldn't matter since a power cycle clears everything. If you're doing things like closing files, you should either figure out other places to close them (such as right after you write to them), or modify the framework to add another way to get to finish (maybe a switch on the robot). You end the match in Telop Disabled.

As far as the int, execute, stop. Init is called the first time the Robot Mode changes. It's called just once, then Execute happens. When Robot Mode changes again, stop of the old mode is called once, and then the init case of the new mode is called once.

[Greg McKaskle]

Good questions.

The framework for LV will guarantee that the first time through a mode like auto, that you'll run the init once, and when the mode switches to something else, it guarantees that you run Stop once. These are not officially part of the protocol, and if you use Begin, you really don't have to do anything there. The framework was written to support a number of programming styles.

The match states you list skip one transition I think you'll see. Specifically, at the end of auto, I believe the transition is auto-enabled to auto-disabled to tele-disabled, then to tele-enabled. This has only one bit changing at a time.

I believe this is the same transitions you'll see if you use the practice match feature of the DS. On the other hand, it would be best if your resource usage would be robust in case the field starts in tele disabled, say, then goes to auto-disabled before the match. Little glitches like this are not that unusual.

Greg McKaskle

[Alan Anderson]

Originally Posted by Greg McKaskle

On the other hand, it would be best if your resource usage would be robust in case the field starts in tele disabled, say, then goes to auto-disabled before the match. Little glitches like this are not that unusual.

I'm counting on the field starting in Teleoperated disabled. That's how it has always been in the past, and that's the only way information from the Driver Station can get to the robot before Autonomous begins.

(In the pre-cRIO days, it was not possible for the state to be both Autonomous and Disabled simultaneously.)

[Ziaholic]

OK ... really good stuff here. Thanks. I'll update my flows here instead of editing my OP.

When I referred to the "FINISH" state originally, I was referring to every option of the ENUM that defines the Robot Mode, not necessarily the Finish.VI that gets called when you press the button on the RobotMain.vi's front panel.

I took a second look at the default robot project. I had assumed that that ENUM/CaseStructure's possible entries were 1-to-1 with what the FieldManagementSystem (FMS) can send us. But apparently the FINISH state of that ENUM/CaseStructure is only written as the RobotMode when you press that front-panel button. And I agree. It doesn't matter, since the first step of leaving the field is to power down anyway.

... so here are my new assumptions ...


The Robot Mode has 6 states. 4 are controlled by the FMS. They'll normally flow in this order when we're on the playing field:

Autonomous Disabled
Autonomous Enabled - (VisitedAutonomous goes TRUE)
Autonomous Disabled
Teleop Disabled
Teleop Enabled - (VisitedTeleOp goes TRUE)
Teleop Disabled

The 5th state is FINISH and only happens when you have the front-panel's open and can press the FINISH button.

The 6th state is Timeout and it's the exception when we don't get a DS packet.

Now, inside both the Auton and Teleop structures, we have the Derived Robot State of

Init Called when transitioning from Disabled to Enabled.
Execute We spend most of our time in here
Stop Called when leaving Enabled

I learned a few things today. Thanks guys.

[Ziaholic]

Originally Posted by Alan Anderson

I'm counting on the field starting in Teleoperated disabled. That's how it has always been in the past, and that's the only way information from the Driver Station can get to the robot before Autonomous begins.

We'll have to get to the bottom of this one ... I don't know why they'd start us up in TeleOp Disabled if Auton is the mode that we switch to when the gun goes off.

[Greg McKaskle]

Hmm. I didn't know about the field before 09. And since I cannot be sure about the field code, I'd say your better odds are on what Alan is saying. On the other hand, I'm certain that the practice match behaves as I described. Of course you can easily flip there from Tele.

Also, you should verify independently, but this year, the robot communications code automatically latches the joystick state and the I/O state before transitioning to Auto Enabled. This acts as both a filter to ensure no joystick inputs drive the robot, and to make it simpler for teams to access their switches and joystick throttles, etc.

Greg McKaskle

[jhersh]

Originally Posted by Alan Anderson

I'm counting on the field starting in Teleoperated disabled. That's how it has always been in the past, and that's the only way information from the Driver Station can get to the robot before Autonomous begins.

(In the pre-cRIO days, it was not possible for the state to be both Autonomous and Disabled simultaneously.)

I'm pretty certain that the FMS will start the round in Auto Disabled. control inputs are sent to the robot during Auto Disabled. Only during Auto Enabled are the control inputs filtered.

Originally Posted by Ziaholic

We'll have to get to the bottom of this one ... I don't know why they'd start us up in TeleOp Disabled if Auton is the mode that we switch to when the gun goes off.

Exactly... which is why the FMS starts in Auto Disabled.

[Joe Ross]

As a side note, unless you modify Robot Main.vi, it doesn't matter if it starts in Auto Disabled or Telop Disabled, as they both call Disabled.vi.

[Ziaholic]

Originally Posted by Joe Ross

As a side note, unless you modify Robot Main.vi, it doesn't matter if it starts in Auto Disabled or Telop Disabled, as they both call Disabled.vi.

Exactly. ... I assumed that Alan's concerns were because his team may not be using Labview, and then that double-state (either/or) case structure wouldn't apply to him. I have zero insight into the C++ or Java frameworks, so I don't know if they provide that "either-or" case like we have in LV.

[Alan Anderson]

Originally Posted by Greg McKaskle

Also, you should verify independently, but this year, the robot communications code automatically latches the joystick state and the I/O state before transitioning to Auto Enabled. This acts as both a filter to ensure no joystick inputs drive the robot, and to make it simpler for teams to access their switches and joystick throttles, etc.

That's a fundamental change to the way Autonomous mode has handled operator input since it was introduced. Is there some official documentation for that behavior, or should it be considered oral tradition?

If the automatically latched values are indeed something we can count on, implementing code to select autonomous options is now much simpler.

As for joystick values etc. being passed to the robot in Autonomous Disabled, that too contradicts the long-understood condition that Driver Station inputs are not available during Autonomous. Again, is there an official description that tells us how it really works now?

Lest it seem otherwise, I'd like to point out that I'm very happy to know this. I'm only concerned because I don't know how I would have found it out if I hadn't been making reading the Chief Delphi forums a priority.

[Greg McKaskle]

Very good questions. I'm not sure how the old system was documented, and I'm not sure who's documentation should call this out. But since this change is backwards compatible, it seemed like a simplifying change that still avoids any joystick direction during auto, but instead of zeroing fields, it latches.

If you have an idea of where to add the documentation so that teams will find it, we can provide the technical details.

Greg McKaskle