Weird hybrid mode in competition

[Doug Leppard]

We have a data logger on our robot that has confirmed that after robot goes through initialization and as it released to hybrid mode it goes through operator mode.

It causes our robot from a 0-5 second delay and relays fire mysteriously. Doesn't happen everytime but often.

Talked with IFI and field reps and they had no idea and could give no help.

We know it goes through operator mode before hybrid mode because we get a print statement that is only in the operator mode.

We don’t think it happens in the pit tethered.

Any ideas on this and how we could program around it?

[Eldarion]

The IFI control system can enable the robot before the autonomous flag has been set--this was documented elsewhere, although I cannot remember exactly where.

What I would do is poll the disable and autonomous flags. On the first start of the robot controller, monitor the disable flag--the first time it goes low, even if the auto mode flag is also low, prevent the operator code from executing. Only allow the operator code to execute on the second disable high-to-low transition. (It is guaranteed that the disable flag will go high in-between autonomous and manual control modes)

Hope this helps!

Eldarion

[Alan Anderson]

What software framework are you using? There was an acknowledged glitch in Kevin Watson's "v3" code involving transitioning into hybrid, and I think a fix was posted.

[Doug Leppard]

Originally Posted by Alan Anderson

What software framework are you using? There was an acknowledged glitch in Kevin Watson's "v3" code involving transitioning into hybrid, and I think a fix was posted.

It is easyc pro. reading through the easyc pro documentation again I saw this statement:

Note:
Depending on the specific field control at a competition, the Field may be Enabled while remaining Operator for approximately one second before the Autonomous flag registers. This means a small portion of your Operator Control function may run before your autonomous code begins. You should take this phenomenon into account when constructing your program

Still doesn't explain where the dealy comes from. But on the last run there was a 4-5 delay, we still knocked down a ball and crossed 4 lines, so we felt good, but this weird delay thing is killing us otherwise.

[Doug Leppard]

Originally Posted by Eldarion

The IFI control system can enable the robot before the autonomous flag has been set--this was documented elsewhere, although I cannot remember exactly where.

What I would do is poll the disable and autonomous flags. On the first start of the robot controller, monitor the disable flag--the first time it goes low, even if the auto mode flag is also low, prevent the operator code from executing. Only allow the operator code to execute on the second disable high-to-low transition. (It is guaranteed that the disable flag will go high in-between autonomous and manual control modes)

Hope this helps!

Eldarion

Thanks, we added this to our notes and confirmed what we were seeing and direction we might be going.

[Jetweb]

what are you using for heading?

You may be waiting for the gyro to initialize? It usually take about 3-5 sec.
possibly teleop resets it?

[Doug Leppard]

Originally Posted by Jetweb

what are you using for heading?

You may be waiting for the gyro to initialize? It usually take about 3-5 sec.
possibly teleop resets it?

It is not waiting on gyro, we confirmed that.

We will make sure it does not go into drive mode before auto mode, hope that settles it.

[Kingofl337]

Doug

Try putting a 500ms wait at the start of Operator Comtrol.
Let me know if that fixes the issue.

Adam

[Doug Leppard]

Originally Posted by Kingofl337

Doug

Try putting a 500ms wait at the start of Operator Comtrol.
Let me know if that fixes the issue.

Adam

Thanks Adam,

We don't have a continuos loop in operators mode but it goes to the end and runs again, thus with a 500ms wait then there would be a wait as it runs each time.

So should we be running a while loop or something so it never finishes the operator mode and thus it would be ok to have the 500ms wait at start?

Thus operator code would be:

delay 500ms

while 1==1

code we want run in operator mode

end while


Does this makes sense?

[Alan Anderson]

Originally Posted by Doug Leppard

It is easyc pro. reading through the easyc pro documentation again I saw this statement:

Note:
Depending on the specific field control at a competition, the Field may be Enabled while remaining Operator for approximately one second before the Autonomous flag registers. This means a small portion of your Operator Control function may run before your autonomous code begins. You should take this phenomenon into account when constructing your program

Ugh, that sounds like a pain. I'm continually getting reinforcement of my decision not to use EasyC. Using the MPLab default code, the disabled_mode flag going away and the autonomous_mode flag appearing are simultaneous.

Originally Posted by Eldarion

(It is guaranteed that the disable flag will go high in-between autonomous and manual control modes)

Where do you find this "guarantee"? I can easily demonstrate the opposite.

[Eldarion]

Originally Posted by Alan Anderson

Where do you find this "guarantee"? I can easily demonstrate the opposite.

In the current field control system only. During manual toggling of the autonomous/disable signals, this will not hold true.

If you like, you can observe this behavior for yourself on the field--the robots will be disabled for a variable period of time directly after autonomous, regardless of the referee's current state. The way the system is designed, even if they signal a go-ahead for operator control immediately, that enable signal still has to propogate to the actual arena controllers and there will be a short disable pulse.

Eldarion

[Doug Leppard]

Originally Posted by Kingofl337

Doug

Try putting a 500ms wait at the start of Operator Control.
Let me know if that fixes the issue.

Adam

Fixed it. We did not have a while loop in operator put that in. Then put in the 500ms wait state.

Thanks for helping.

[Tim Arnold]

Thanks for finding the cause of this problem... our extremely basic auton (drive forward) was experiencing this same 4-5 second mysterious delay, also using EasyC Pro. This is good to know for when/if we get our hybrid working

[adamdb]

I am glad you posted this as we also had a strange occurrence. We were also using EasyC Pro. After experiencing several wierd issues, we removed ALL of our autonomous code including all code in the Autonomous() function. 5 or 6 seconds into the autonomous period we were also experiencing relays energizing on their own. Further debugging showed that it was calling an init routine we had in our Operator Control code that was causing the relays to power up. I would have expected that with the Autonomous() function being empty that nothing at all would happen during the autonomous period. The addition of an endless loop in the Autonomous() function:

while(1);

resolved the issue, but certainly doesn't explain why EasyC was calling a random function when nothing should have been happening.

[Kingofl337]

In 2006 when Brad wrote WPILIB and we wrote easyC for FRC we observed this issue and documented it in the help file. The problem is how the field switches to autonomous mode from disabled. The field starts out Disabled in Operator Control then is enabled and switched to Autonomous. So, for a brief amount of time the robot is enabled in operator control and may executes a couple lines of your operator control. I have not tested this on the 2008 field but I would assume it is the same based on the issues you are having.

We also don't recommend running operator control without a while(1) loop. If you check all of our examples for both Vex and FRC operator control is always in a while(1) loop.