You bring up a good point, that some issues are more important than others. If you need to get a camera stream running, it might not be prudent to keep a person on the field, since it’s just not worth incurring the anger of an FTA. However, if your robot doesn’t connect, it definitely makes sense, since the FTA can’t reasonably get angry at you for that.
In those cases, the person on the field isn’t really changing much.
In order for the field to go green, every robot must be connected. Looking at the FMS, you can see 4 statuses immediately that influence this connection:
- Is there something plugged into the station?
- Is the thing plugged in the same team number as the station expects?
- Can we talk to the team’s radio?
- Can we talk to the team’s roboRIO?
If any of those 4 are a “no,” the flashing lights above your station are on, the color matching your alliance is lit up on the score table, and the game cannot be started.
There are only two ways to get around this. Fix the problem or bypass the robot. The robot won’t be bypassed without the FTA or FTAA coming over to check on the robot and then making a decision. While I won’t say it can’t happen, I’ve never seen a decision to bypass not be explained to a team.
The ready button wouldn’t be meant to fix these sorts of problems. Instead, it’s meant to resolve issues you’d see if something didn’t load correctly or you were still making changes to your dashboard when the match countdown starts.
Add
- The roboRIO user code must be running and communicating with the DS.
I’d have a serious problem with any volunteer who decided to disable a team because they wanted the match to not start without their robot connected or autonomous mode selected or whatever (provided selecting auto takes a trivial amount of time), just because they chose to stand on the field during this time where the match already shouldn’t be started. It would seem pointlessly targeted and antagonistic for no real benefit.
That’s incorporated into 4. If it’s not, we show up red there for the FMS display and the field isn’t green.
4 is a roboRIO green status on the FMS field monitor.
5 is a yellow background before the user code communicates, while the roboRIO shows as green on the FMS monitor.
The field still won’t start a match in that condition.
Touche.
It always goes white so quickly I never bother to think about it.
Since you used the word, define “trivial”.
How much time are you asking me to wait, after the field has gone green, before I have to look over at the head ref (who makes the actual decision in the case of G02)? What about the 5th match of the competition for that team of the same delay? How about when that team doesn’t turn their robot on when the wheels hit the field but until after all 5 other robots are already connected when they know full well that their match setup procedure takes a long time (yes, every event I have at least one team, purposeful or not, although it tends to be teams that really should know better)? At what point does it become an issue of a bad design implementation that is affecting the competition for other teams involved and I am now being asked why they are special and being given extra time when the rookie team on the other alliance with the multi-autonomous routines seemed to figure it out? Them standing on the field until whatever time they deem their over-complicated startup procedure is complete then also means them having to leave the field to make their way back to the player station and someone now closing the gate that had to be left open, further delaying. Remember that the field is already green through all of this, so G02-Blue Box F, is what would be in play here for the head ref to be looking at.
Things like these are entries I put in the FTA Notepad app (THANKS KERRY AND JON!) that I use to track what I call Chronics (from my prior telecom NOC life), and allows me to see if it was a one-off situation or procedural. If there is a trend of a robot being a slow-starter, they will have more of my attention when they hit the field, or sometimes even before. This same app is where I’m noting why robots stopped moving, particularly if a cause was found (6ga wires in breaker being loose being the most noted item this year for me, NOT the barrel connector in the radio). It allows for some pre-match checking to see if the problem was corrected.
Not trying to be argumentative, but I need a guideline to work with if you are going to say “trivial amount of time” as that seems to mean something different to any member of a group you ask. I’m only giving the hypothetical of one team being a perpetual delay here, what if it is 5 of them?
I am a major FAN of FRC (one major reason that I so badly pursued being an FTA even though I do not have any kids of my own yet in the program…hopefully my 13 year old will), and I REALLY want to see 6 robots moving on the field. I hope that any attendees of my events can back me up that I have and will do just about anything to get a robot connected (Hi AZ and CO event teams!), but sometimes it just isn’t going to happen (last minute code push forgetting to set it to start on power-on is an often cause for Mark’s #5 staying yellow on the FMS monitor).
I really enjoy watching the highs of a competition (I have a great video of 5499 on the practice field in Houston where the drive team mixed it up with the pilot driving and one of the drivers as pilot…the sheer joy on their faces was amazing…I’ll post it if 5499 PMs me permission). It also kicks me in the gut for the lows (queue video of a robot that was velcro’d to the floor…2662, let me know if you want that one posted). And don’t get me started when I have teams on opposite alliances in playoffs that I work with…that must be absolutely entertaining for everyone else around the scoring table, particularly when it was a great match that ended up tied in the semifinals.
I know that we are done for this year, but anyone at one of my events that wants to see what it is like “on my side of the glass”, I welcome to shadow me for a bit (please PM beforehand so that we can chat first and not have a rush). Practice day is generally when we see the most interesting stuff and is much more time available to showing things. It may be enlightening for those that have only been on the player station side or in the stands.
You’re describing a wide variety of scenarios there, none of which were what I or anyone else in the thread was talking about. Teams deliberately not turning their robots on, for some reason, are not what the topic of discussion was. Certainly not teams causing any substantial delay. That’s a whole separate thing than teams waiting for comms to establish.
What I was trying to refer to is teams that need to use SmartDashboard or a similar interface to select autonomous modes, a procedure that at most takes several seconds, yet needs to be started only after comms are established. Occasionally you’ll find some well meaning but rushed field staff really excited about getting comms ready who gives the go-ahead as soon as the light turns green.
Every team I know of who does this has a drive team member just stand on the field until comms are established and they get a thumbs up from the operator. Never much longer than 5-10 seconds after comms are established.
The extra ten seconds it takes for a single person to walk through the gate back to their station, after comms are established, is about the same amount of time it takes a driver to select an autonomous mode on their SmartDashboard and to click “stop calibrating the gyro”. But if this person isn’t on the field waiting for comms, people who mean very well but are in a hurry may go “WE HAVE A GREEN LIGHT DRIVERS BEHIND THE LINE 3 2 1” before the team even realizes their dashboard is now active.
The biggest problem I see with holding off the Robot Code until a start button is pressed is what to tell the FTA that comes over to help you. In most situations (where you’re just waiting for cameras/vision to come online and you press it after a few seconds of being connected) it would work, but if you’re trying to troubleshoot your vision system and the FTA’s think your robot has no code that could be a problem.
I’m always cognisant of the amount of time it takes us to set up on the field. I think it’s an important balance between getting what you need done before match start and GP in getting the match started in a timely manner.
We have two things that that take a significant amount of time (relative to our other tasks) during setup. It’s been this way for this year and last (our rookie year). First, we do not bring our DS laptop to the field with the DS software running. Windows is booted, but sleeping. Usually as the robot is being placed and powered the driver is starting up the software.
We do this because it forces NetworkTables (and SmartDashboard) to reset, avoiding an inconsistent state between DS and RoboRIO (which was a problem we had last year). Luckily in nearly every case this was done and ready well before the Robot booted.
The second item is that we run our gyro calibration as soon as robot code starts. We’ve timed it and it takes about 30s from power on until it’s finished calibrating. We’ve trained our drive team to not move the robot for any reason during this time. (It avoids unnecessary recalibration later, often because “we weren’t sure, so we recalibrated”. Our DS-calibration command is hidden for a reason. 
)
The only times we have a delay is if the robot is in the wrong position when powered up (faster to wait the 30s then move than to power cycle), or if we have a field fault. We did have one a few seconds into one of our matches this year, and we were one of the last to be ready – mostly because I forced the drive team to go through all the startup steps, restarting the DS software, power down, move, and then power up robot, etc.
I figure we make these procedures for a reason, and skipping steps to shave a few seconds can cost a match. (Even though everyone, including the head bumblebee, was saying to take our time, I was still wishing we were a bit faster.)
Now I know we’re not the slowest to setup (FMS/networking and stuff happens aside), but I know we’re not the fastest. Maybe these things will help others with longer setup times.
Outside of one-off issues (that one time the robot wouldn’t connect, or the DS ethernet plug was glitchy, or Windows needed to be rebooted), what do you all think is too slow setup-wise?
A 7 minute cycle is 420 seconds. Take away 150 seconds for a match, 45 seconds for radio bootup, 60 seconds for team intros, and 30 seconds for the field to go green and you’re left with 135 seconds for setup. Which means about 2 minutes for setup is what it takes to keep the field on time.
If you’re using the kit gyro, calibration should take about 5 seconds.
What I had our code do was repeatedly tell the gyro to calibrate until a checkbox on SmartDashboard is unchecked. This checkbox should be unchecked after the emcee walks past your robot, eliminating any chance of the robot being bumped while calibrating. By calibrating as close to the beginning of the match as possible, drift is kept to an absolute minimum.
Doing something like this in your code (or even a push-button-to-calibrate procedure, if you remember to do it every time) should speed up your cycle times as it allows your robot to be powered on and set without any delay, taking this time during the otherwise “dead” time of standing behind the glass waiting for the match to start.
The worst case if you forget to uncheck the box is that your auton doesn’t start for 2-5 seconds while it waits for the gyro to finish a calibration.
Is there a reason why you can’t record the current angle at match start and use that as a baseline? All of the gyros I’ve dealt with in FRC have nearly constant drift over a match.
Aren’t these two statements together a tad unfair? The teams you’re mentioning aren’t what the thread is talking about either. They’d see no benefit from the ready button. And really, we can’t say those teams AREN’T what he was describing. The only way you’d gain ANY value from having a member on the field until comms are established is if you’re the last team to establish comms. If this is the case, you can fit into pretty much every scenario listed. If not, the drive team member isn’t serving any actual function.
Yes, it is the kit gyro. The 30s we’re talking about is from the time the main breaker is closed, through RoboRIO boot, code start, and finally calibration. (It might be a hair faster this year, but it’s negligible.) Yes, the Gyro does take about 4s on average to calibrate, we find it to be a bit slower just after boot.
We also reset the gyro (not recalibrate) at the beginning of our auton – if an Emcee moved our robot accidentally I’m sure none of the field staff would mind a student running out for a second to put it back. (As that delay certainly wouldn’t be our fault.)
With auto so short, and trying to do so much, burning the time it takes to calibrate could easily be 30% or so of your total time, something we just can’t let happen.
I’m still not understanding why you need to recalibrate at the start of auto. Other teams record the gyro angle at the start of auto and use that as the starting angle.
I assume resetting the gyro as auton starts is a given.
I couldn’t think of a better way to make sure the gyro calibration was as close to the start of the match as possible. Burning the calibration time in auton is really bad, yes, but it’s generally much better than a gyro rapidly drifting, and your auton will only be delayed if you forget to tell the gyro to stop calibrating. We just insert this step into our normal pre-match checkup - making sure the controllers are configured, auton is set up, and the calibrate button is unchecked.
Make it a very large button on your SmartDashboard, perhaps one labelled “Ready” that turns from red to green once clicked, and you won’t miss it
Resetting the gyro zeroes it without any noticeable delay. He was discussing why it’s bad to have a disabledPeriodic calibration routine that could result in the match starting while the gyro is calibrating.
What my team did is while we are disabled, we periodically re-calibrate the gyro. That way when we enable, we are good to go.
How does that work if you’re calibrating when the match starts?