|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#1
|
||||
|
||||
|
disabledInit()
After the autonomous period ends does the robot immediately switch over to teleop or does the robot get disabled then goes to teleop?
|
|
#2
|
||||
|
||||
|
Re: disabledInit()
It should go from autonomous to teleoperated without disabling, but you could always check with the practice mode of the driver station.
In other words, have a println in disabledInit() and run practice mode to check if the line is printed. |
|
#3
|
||||
|
||||
|
Re: disabledInit()
The robot will be disabled during the transition from auto to teleop. The sequence will go like this:
Auto Disabled > Auto Enabled > Auto Disabled > Teleop Disabled > Teleop Enabled > Teleop Disabled |
|
#4
|
||||||
|
||||||
|
Re: disabledInit()
It always goes disabled between Autonomous and Teleop. The amount of time that it is in disabled varies year to year.
|
|
#5
|
|||
|
|||
|
Re: disabledInit()
Quote:
There is no difference between AutoDisabled and TeleopDisabled from the programming perspective. There are the same state. While that is the text that is displayed in the driversation, in the codebase they are represented by the same two functions. DisabledInit() and DisabledPeriodic(). The Robot will go into disable mode when going from autonomous to teleop or anytime the robot is disabled. Each time this happens, disabledInit() will run once, and then DisabledPeriodic() will run 50 times a second. For further information. When the robot is first turned on it will first run RobotInit(), then DisabledInit(), then disabledPerioid(). Each time auto or teleop mode is entered, their corresponding init and periodic functions are called in the same manner as the disabled ones. Hope this helps, Kevin Last edited by NotInControl : 14-03-2014 at 16:31. |
|
#6
|
|||
|
|||
|
Re: disabledInit()
Quote:
, from a programming perspective they are two different states. Even though the WPI framework calls the same disabledInit() and disabledPeriodic() functions irrespective of whether you're in Auto/Teleop/Test, in your code you can use the isAutonomous(), isOperatorControl(), and isTest() functions to distinguish what state you're in if you really need to. |
|
#7
|
|||
|
|||
|
Re: disabledInit()
Quote:
This is incorrect. There is only one disabled state for the robot, and there is only one interface to that state from the programming perspective. Quote:
Your original post mentioned Autonomous Disabled, and Teleop Disables which could be interpreted that they are two different functions on the programatic side. However they are not. I will not argue semantics, if you feel to call them two separate states by all means go ahead, but passing that information on to others is completely incorrect. Regards, Kevin |
|
#8
|
|||
|
|||
|
Re: disabledInit()
Kevin -
It's important to be clear and precise so that incorrect information isn't propagated. Maybe I'm misunderstanding, but your posts seem to be teaching others that it is impossible in our robot code to distinguish between AutoDisabled and TeleopDisabled. If that's what you're trying to convey, it is incorrect. The WPI framework (at least in C/C++ and Java) provides the ability to distinguish between those "states". The following Java snippet will display different messages to the console depending on whether you're in AutoDisabled, TeleopDisabled, or TestDisabled. C/C++ is similar, just with slightly different syntax. Code:
public void disabledPeriodic() {
|
|
#9
|
||||
|
||||
|
Re: disabledInit()
Quote:
The first being: Autonomous/OperatorControl/Test and the second being: Disabled/Enabled So if the robot is Disabled it will run disabledInit() and disabledPeriodic() regardless of the state of Autonomous/OperatorControl/Test. TBH, I think you all are arguing semantics. But that is just mu opinion. ![]() |
|
#10
|
|||
|
|||
|
Re: disabledInit()
Quote:
Quote:
Quote:
The crux is, the disabled mode exisits even without a driverstation as it should. If you turn the robot on and have no driverstation connected to it, it will still be in disabled mode, and run disabled periodic (the one and only disabled mode). I challenge you to see what your output is then without a driverstation. It will be nothing. Those functions you use only exist and return true if a driver station is present and reading what state the driverstation wants the robot to be in next, not that the robot changed a state. All your code does is show that you can read from a selector on the driverstation( or FMS if that was connected) which is what all those isAuto/isOperatorControl/isTest() methods return and print out a message which says auto disabled, or teleop disabled. The mere fact that you are doing that from one function (disabledPeriodic) on the robot shows you always remained in one state of the robot state machine (disabled) while you toggle the buttons on the driverstation, not that multiple disabled states exist, or that you magically switched from an Auto Disabled state to a Teleop Disabled State or to a Test Disable state. At the end of the day, as I said before, I will not argue semantics of what a state is or what a programmatic interface is. Please call it what you will, add as many states to the robot as desired, but if you state to others the robot state machine has any other obtainable states then these: disabled, autonomous, teleop, or test (where auto, teleop, and test each enable the robot), you would be incorrect. I believe the original poster received their answer, and see no other reason to continue this thread. I apologize if you felt I hijacked your statement, the information provided was unclear and felt it needed clarification, nothing beyond that. Have a great day, Regards, Kevin Last edited by NotInControl : 15-03-2014 at 23:18. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|