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?
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. :o
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)
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.
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?
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.
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.
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
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.
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.
