|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
|||||
|
|||||
|
Re: TeleOp Init/Stop vs. Auton-Iterative Init/Stop
Quote:
(In the pre-cRIO days, it was not possible for the state to be both Autonomous and Disabled simultaneously.) |
|
#2
|
||||
|
||||
|
Re: TeleOp Init/Stop vs. Auton-Iterative Init/Stop
Quote:
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. |
|
#3
|
|||
|
|||
|
Re: TeleOp Init/Stop vs. Auton-Iterative Init/Stop
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 Last edited by Greg McKaskle : 06-02-2010 at 21:28. |
|
#4
|
|||||
|
|||||
|
Re: TeleOp Init/Stop vs. Auton-Iterative Init/Stop
Quote:
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. |
|
#5
|
|||
|
|||
|
Re: TeleOp Init/Stop vs. Auton-Iterative Init/Stop
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 |
|
#6
|
|||
|
|||
|
Re: TeleOp Init/Stop vs. Auton-Iterative Init/Stop
Quote:
Exactly... which is why the FMS starts in Auto Disabled. |
|
#7
|
||||||
|
||||||
|
Re: TeleOp Init/Stop vs. Auton-Iterative Init/Stop
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.
|
|
#8
|
||||
|
||||
|
Re: TeleOp Init/Stop vs. Auton-Iterative Init/Stop
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.
|
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| adding a second joystick to TeleOp Init | smcmahon | NI LabVIEW | 14 | 17-02-2009 20:43 |
| the E-Stop | Greg Needel | Rules/Strategy | 10 | 13-04-2003 22:13 |
| Wierd basic init | Jeremy J | Programming | 5 | 06-02-2003 11:42 |
| Basic Init Error | yan184 | Programming | 5 | 14-12-2002 13:10 |