Bill's latest blog

[johnr]

Bill's latest blog mentions a problem at the start of matches. How wide spread was this problem and how much could it effect code. I am not a programmer but our bot did act up once or twice late in the season. Thanks for any further explanation you can give.

[bobwrit]

I didn't notice it often, but I noteced teams getting dropped from the FMS more often. It *may* affect a teams code slightly by forcing them to think of teleop and auton as two seperate programs instead of having one, then the other.

[Ice Berg]

This problem plagued us throughout the season, and caused us to sit still during autonomous during eliminations at Hartford. Our autonomous routine implemented a timer in order to break out of a PID loop. We had intermittent problems throughout NY and CT, but the FTA people couldn't figure it out. We suggested that the field may have been sending auton enabled signals before auton actually began causing the timer to start and count down, then when auton actually started the timer had already run out, but the field people said that this was impossible (disclaimer: not being a programmer I only have a general sense of how the program worked, so I'm sorry for not being more specific). We actually spent the last few weeks going through our code trying to fix the "problem" but could not find anything. This explains a lot.

[jtdowney]

This is an issue that I noticed quite a bit on Galileo. Speaking as a professional software developer I can say that independent programs to talk to each other in a disconnected manor is a difficult problem to solve. There is a lot to be said for the positives of FMS but every piece of software has its defects. At least no one got hurt because of this bug.

[Mark McLeod]

Essentially, if the DS and robot began communicating with each other before the FMS exerted control (takes a second or two), then it would start operating enabled just like at home. Either auto/enabled or teleop/enabled depending on how your DS switch was set.

This bug was discovered during the early events and was the reason for the team startup procedure of:
1) making sure your DS switch was set to Teleop,
2) waiting for the Field Preset,
3) connecting the Driver Station and waiting for FMS to recognize the DS,
4) powering up the robot.

For next year, to solve this, FIRST is looking at a firmware change that forces both the DS and cRIO to connect to FMS before being allowed to connect to each other.

The window was small, but the robots could twitch dangerously (threatening the team & field crew), and of course if you used an auto state machine or a timer then your auto would likely be messed up.
For programmers this means always resetting any required startup states during auto/disable or teleop/disable. In the early days of autonomous in 2003/2004 we had similar learning experiences where the modes could be mixed and not the progression you'd expect: 1)auto/disabled, 2)auto/enabled, 3)teleop/disabled. 4)teleop/enabled, 5)teleop/disabled.
You might see a similar issue during the usual back-to-back practice matches run on Thursday.
Don't design your code to depend on these exact steps. Design it to work at home if the Teleop/Auto switch is toggled randomly.

We found at SBPLI we could safely stagger the startup procedure, but we made sure the FMS was in control of the DS before the robot cRIO's finished booting.

[Jared Russell]

I have a scar on my left hand from when our "disabled" robot suddenly enabled itself in San Diego. I am glad to see that we are at least cognizant of the issue.

[Kingofl337]

We had trouble with out robot (rolling PID loop(s)) on Galileo during the semi finals when they started rushing people to turn on the robot "right away". It caused our auto malfunction and we were not allowed to reboot the robot from the DS.

[RoboMaster]

I don't think that this was the cause to our problem, but one time our robot was unable to drive around during the whole match. The wheels would move and other motors on our robot would move just fine and such, but apparently our back two wheels (we had 4WD for our traction control) were not moving. Our front wheels were not able to provide enough pulling force to move our robot and we could only inch forward.
This doesn't sound like a symptom of this problem, but just wanted to throw that out there. Our robot is mysteriously fine now and we have theorized till our brains cramped.

[AlexD744]

Originally Posted by Kingofl337

We had trouble with out robot (rolling PID loop(s)) on Galileo during the semi finals when they started rushing people to turn on the robot "right away". It caused our auto malfunction and we were not allowed to reboot the robot from the DS.

Yeah something like that happened to us our very first match on Galileo. Thanks again for making sue we were okay. After that we conspired to get the control board on in like 2 secs and our driver and coach slowed down a little while placing the robot.

[Joe Ross]

Originally Posted by RoboMaster

I don't think that this was the cause to our problem, but one time our robot was unable to drive around during the whole match. The wheels would move and other motors on our robot would move just fine and such, but apparently our back two wheels (we had 4WD for our traction control) were not moving. Our front wheels were not able to provide enough pulling force to move our robot and we could only inch forward.
This doesn't sound like a symptom of this problem, but just wanted to throw that out there. Our robot is mysteriously fine now and we have theorized till our brains cramped.

That sounds like it could be the problem I reported on the FIRST Forums.