Hot Goal Timing Issues
 

This weekend at the Central Valley Regional we noticed an issue with the synchronization of timing between the field management system enabling robots and the triggering of the hot goal lights and targets.

We found that robots were being enabled up to a second before the lights and vision targets indicating the hot goal turned on. This seemed to be a simple time shift as robots would stop moving before the lights turned off and the second hot goal lights would activate exactly 5 seconds after the first hot goal lights turned on. This creates 2 issues:

1) Given humans score the hot goal by way of the field lights and not the field timer, teams had approximately 6 seconds to score in the first hot goal and 4 seconds to score in the second hot goal.
2) Teams had to wait 1 second in auto mode to sense the hot goal. With multiple moving robots and shot being fired, the challenge becomes much different than initially expected.

Over the course of an entire match one second would probably not be a huge deal but given the 5 second scoring window for the hot goal, this bug equates to a 15-20% decrease in available scoring time. Many teams have designed their robot to score balls in the hot goal over a 5 second period. In some matches they are being given less than 4 seconds.

Here are some illustrated examples of this happening. These videos have a timer that starts in the first frame that I can see robot motion, which is the best indicator I have of robots being enabled. There could be more time of "enabled" on top of this as robots may not start moving at exactly t=0.

CVR Qualification Match 2: http://www.youtube.com/watch?v=mgI_PkgsuXA
In this match, the second hot goal is only active for 3.9 seconds. The first hot goal is not indicated until 1.1 seconds after robots are enabled. The second hot goal is activated at 6.1 seconds. Robots are disabled when the overlay timer shows 10.0 (you can see a ball in 254's robot start to move towards the shooter then fall as the single acting solenoid outputs are disabled.)

CVR Qualification Match 83: http://www.youtube.com/watch?v=RXKHpcc6ZOE
In this match, there is a .7 second delay from robots starting to move until the hot goals activate

CVR Qualification Match 11: http://www.youtube.com/watch?v=rycIqPJpbz4
In this match, there is a .6 second delay from robots starting to move until the hot goals activate

CVR Qualification Match 32: http://www.youtube.com/watch?v=9Q3KVlqbwvc
Since the robots are not visible in this video, I have synced the overlay timer to read 1.0 when the match timer on the field changes from 10 to 9. There seems to be about 1.2 seconds of delay from robots on to hot goal on, and a 3.8 second long second hot goal.

As an additional data point, we observed that the scorekeeper seemed to be enabling robots from the PC interface, not the blue hardware control box.

Of the issues listed above, it seems point 2 has a very simple fix. In 2008, drivers were not allowed to touch their controls once the “ball randomizer” had determined ball position and field crews could place them. The first hot goal could work in a similar fashion and be lit before the match starts.

Has anyone else seen issues like this? It would be nice to have these issues fixed for future events!


Thank you,
Team 254 Mentors and Students

Re: Hot Goal Timing Issues
 

This happened at Alamo as well, but sometimes the delay was much worse. In finals match 2, the first hot goal lit up and never switched.

The delay has caused our 2 ball, 2 hot goal auto to be a 2 ball, potentially 2 hot goal auto. Due to our setup, our bot sees the right vision target and decides which goal to shoot at first. The delay makes it always think that the right goal is hot first so it starts moving before a hot goal has actually lit up. So we just have to hope that the right goal is hit first.

I hope this can eventually be fixed

We noticed similar behavior at GTRW.

Re: Hot Goal Timing Issues
 

This is EXACTLY why we asked the following question to the Q/A system. Appearently the answer given is not actually representative of how the system operates.

Here is what the 2014-01-10 Team Updates states:

The blue underlined text is where the update was made.

Notice that no where does it say EXACTLY WHEN the targets flip.

We were right there with you Tom, we saw the same issues in our matches as well.

I hope a post from me following Sac/Davis this weekend will have better news to report!

Re: Hot Goal Timing Issues
 

Our team abandoned HOT goal detection a few matches into our regional and felt it was more efficient to make up the lost 5 points in TeleOp. We have now turned our focus to a two-ball auto.

Re: Hot Goal Timing Issues
 

It's a real killer if the hot goal doesn't light up as soon as the match starts or goes at a variable time and you're detecting the saturation of the goal to determine if it's hot or not.

Thankfully this wasn't an issue at GTRE, but nevertheless I hope it isn't an issue for our team at future events (and others if they use the saturation values of the hot goal--do any of you do this instead of using the retroreflective tape?).

Re: Hot Goal Timing Issues
 

In the 22 matches we played and the 22+ matches I watched while in queue, we saw a hot goal problem twice. The first time, one side of the hot goal remained on the entire auto period. A few seconds after teleop started, the match stopped, and was reset. Our drive team was never told why. The second time the exact same thing happened. I don't know if it's a coincidence or not, but in our three full match replays, the hot goal side changed at least once, but I don't know if a match restart has the ability to switch the hot goal side.

After this match, I watched the timer, and every other time, the hot goal switched within .5 seconds of 5 seconds on the timer.

Another observation I had was that the timer, lights, sound effects, and robot state weren't as lined up as they were last year. In a few matches, our robot was disabled before the buzzer and the lights went off. In one match, I loaded the shooter right as the buzzer stopped.

I don't think it's a problem with the light controller because they were able to put on some pretty fast moving light shows during picking.

Re: Hot Goal Timing Issues
 

To my knowledge, this happened once in eliminations at Mt. Olive. Since only one ball was interfered with, we gave the bonus.

I also recall seeing video of it happening at Centerline.

Re: Hot Goal Timing Issues
 

Here's a video. We shoot the ball in the far goal at 6 seconds into the match.
http://www.youtube.com/watch?v=95lCy...RUwWvGvG8PnQpA

Re: Hot Goal Timing Issues
 

We definitely noticed it being an issue at GTRE, and had to add in one second delay to make sure both our shots were fired on the correct goal.

Re: Hot Goal Timing Issues
 

Well, we had issues with the drive train early on and couldn't actually get going for the auton during that time, so I'm guessing that we just had the good fortune of having the camera delay how it sensed the hot goal once we got going.

I mean, that'd be a problem anywhere else and I definitely will be looking into that, but this time a delay in input seemed to work to our advantage :rolleyes:

Re: Hot Goal Timing Issues
 

Everything in the FMS is connected by ethernet. With all the ref's talking about lag in the tablets, the issues with the hot goals, and the timing of the sounds, all of which I've noticed, I think they are all related to lag somewhere. The FMS normally doesn't seem as off as it has this year, but thats where I think the issue is, and I hope they get it fixed soon, because its causing problems.

Re: Hot Goal Timing Issues
 

I noticed the timing of sounds but didn't see a connection. This happened with the end buzzer at MO very often and Groton at least once; a delay between the match ending and the robots stopping(usually stopping first). One match in Elims at Groton even had the "ding ding" not play, but I don't know if that was the FMS though.

I noticed a significant hot goal delay at the start of autonomous at both GTRW and GTRE.

I also felt that matches were ending about 1 second before the match timer expired and the buzzer sounded.

Re: Hot Goal Timing Issues
 

We also noticed robots being disabled 1-2 seconds before the lights going out.

Re: Hot Goal Timing Issues
 

I'm glad you guys noticed this as well. I thought I was going crazy. It definitely seemed like robots were being disabled before the buzzer. I just assumed it was something to do with they way the audio was being fed to the A/V system. But now that you mention the match timer and lights, it appears to be a larger issue.

Re: Hot Goal Timing Issues
 

I linked this in another thread, but I will put it here
This was a Semi-Final match at GSD a week ago.

If you look at the goals, the second "hot" goal turns on with a fraction of a second left. This happened on both sides of the field (look to the far left of the video and watch it a few times). Whatever is wrong with the hot goal timing this year, it does not seem to be an isolated incident. Also, I think Dean Kamen points it out to one of the field personnel, so it did not go unnoticed.

I noticed something with the timing this year as well, usually when the timer hits zero on the field (before the buzzer sounds) you can step forward and the control the robot almost immediately. But this year there is a noticeable 1-2 second delay between the end of auto (timer hits 0) and the start of teleop. It was bothering me a lot at GSD, because in 2012 and 2013 you could immediately take control after auto, this year seems different.

Re: Hot Goal Timing Issues
 

Look at your Driver Station logs. You'll see a consistent one-second pause between the end of autonomous and the enabling of teleoperated mode. It's always been possible, and this year it's definitely being controlled that way.

Re: Hot Goal Timing Issues
 

We experienced both the hot goal delay and the early match endings at San Diego.

We had to implement the same solution. Losing an entire second in autonomous is pretty detrimental.

Re: Hot Goal Timing Issues
 

Good News! The people in charge of the FMS are aware of this issue and are trying to fix it in time for week 3 events.

Re: Hot Goal Timing Issues
 

source?

Re: Hot Goal Timing Issues
 

I volunteer as a scorekeeper and I get weekly updates, so my source is literally the guys who are in charge of updating the FMS.

Re: Hot Goal Timing Issues
 

Can confirm, this week's Scorekeeper update mentioned they're aware of the issue and working on a fix to be pushed out before week 3 events

Re: Hot Goal Timing Issues
 

We too have noticed hot goal timing issues at the Groton District event this passed weekend. It was such a problem that towards eliminations we dedicated our media student to filming the actuation of the hot targets so we could study them later.

There was a noticable 1 second delay between match start and goal actuation that was noticable with the naked eye. It was also appearant that one side was more affected then the other when looking at blue vs red.

Thank you for posting your videos they are very helpful. We too can post the videos we took at Groton if that will help the community.

What system are you using to detect hot targets? It also appeared that the last link "Qual Match 32" your alliance started with 4 balls in auto. How did the refs let you pull that off?

Regards,
Kevin

Re: Hot Goal Timing Issues
 

That was a practice match that I incorrectly labelled. Nice catch.

Re: Hot Goal Timing Issues
 

Can anyone at an event this week verify that this has been fixed?

From the one brief look I took at the Sacramento Regional webcast, there doesn't appear to be any difference from last week.

Re: Hot Goal Timing Issues
 

I have not noticed any hot goal discrepancies at Escanaba today. If someone has seen one, please correct me as we want it to be done right.

I did confirm that the robots shut off as the timer hits 0, but the buzzer sounds a second or so later.

Re: Hot Goal Timing Issues
 

It's not as big of an issue in the matches I've seen, but fast robots will always fully cross the line before the goal lights up. I guess we'll just have to rewrite our auto code. I have yet to see the lights come on before a robot moves.

Re: Hot Goal Timing Issues
 

I'll preface this post with the fact that I was the scorekeeper at the Week-1 Alamo Regional. This problem (sounds out of sync with game timer) is separate from the other (field action out of sync with game timer), but possibly could be related. The monolithic FMS application controls the robots, but the Audience Display app controls the game sounds and what gets seen on the "big screen" when the A/V crew allows it to be seen. At Alamo I noticed almost two seconds between when the game timer hit zero and the sounds played; I messaged FIRST and asked what was up with that, and they told me to restart the Audience Display since the game sounds are triggered by the audience display (I assume the audience display is polling the FMS timer to determine what to do - that's just my assumption though, from years of experience writing these kinds of apps, it's in no way confirmed by FIRST). On restart, the game sounds and timer sync'd up just fine. I did notice, however, that over the course of 40 or so matches the game sounds and field timer drifted once again. During a break in the elims, I restarted the display app to re-sync the game sounds, but by the Finals the game sounds were again out of sync. I also noticed this at the Arkansas Regional.

-Danny

Re: Hot Goal Timing Issues
 

It seems to be a lot more consistent that week two, which, at Groton, ranged from really accurate to not changing at all.

I picked four matches from the Howell District competition (Q 35, 42, 36??) to watch, and it still seems to be a little bit unbalanced.

The average time before the goal lights in these four matches was 1.24 seconds, the average time on the first goal was 4.95, and the average time on the second goal was 3.8 seconds. I assumed the end of autonomous was exactly 10 seconds after the first frame where a robot moved.

It may just be coincidence, but it seems that the earlier matches from today were much better.

Re: Hot Goal Timing Issues
 

This suggests that the situation is exactly the same as it was in Weeks 1-2.

Re: Hot Goal Timing Issues
 

At North Carolina both 1) and 2) still seem to be the same. The hot goal is lighting up about 1-1.5 seconds after the start of the match and not switching until the clock is on 4 seconds remaining, or very close to it.

Still appears that robots are about a second ahead of match clocks (e.g. Robots are dead with about 1 second remaining in teleop).

All of this is from a naked eye test; no analysis or frame by frame study.

Re: Hot Goal Timing Issues
 

To me, it seems better than Groton was. Sometimes, robots would shoot the ball before the hot goals lit up, and other times, one side would remain lit for all of autonomous. I have only watched about 15 week three matches, so I'm not sure.

Re: Hot Goal Timing Issues
 

Here's a few videos of the problem.

http://www.youtube.com/watch?v=NJ8NMU4aVDs (ball through the goal before it lights up)

http://www.youtube.com/watch?v=IGRYbF7Qll8

http://www.youtube.com/watch?v=cth8G3p6zGk

Re: Hot Goal Timing Issues
 

Still an issue, here is a match from Orlando where you can see the lights don't come on for about 7 seconds.

http://youtu.be/3HqtHBYJLfg

Re: Hot Goal Timing Issues
 

I noticed in this video that the vision targets appear to be switching at the correct times, but the LEDs are clearly way off.

Re: Hot Goal Timing Issues
 

Why is this not considered a field fault, and why isn't the match stopped?

If, in the judgment of the Head Referee, an “ARENA fault” occurs that affects the outcome of the MATCH, the MATCH will be replayed.

ARENA faults include broken FIELD elements, power failure to a portion of the FIELD (tripping the circuit breaker in the PLAYER STATION is not considered a power failure), improper activation of the FMS, errors by FIELD personnel, etc.

Re: Hot Goal Timing Issues
 

Also, correct me if I am wrong but I think the blue alliance was scored wrong for Auto, the announcer says they got 40 points but I can't figure how you can get that with 15 in mobility points and either 1 or 2 balls scored (hot or not)

It leaves 25 points scored by balls in high goals, which is impossible.

Edit: I think I figured out what was wrong, the vision targets indicate that both blue balls were scored in hot goals, but the LEDs indicate they were scored in not hot goals. If both blue balls were counted as not hot that would be 30 points. I also think the refs did not notice that 223 moved all the way into their zone before moving back. If only 1065 and 4064 got mobility points for blue that is 15+15+5+5 = 40 points that was announced when it should have been 20+20+5+5+5=55

So 3 problems in the first 10 seconds of the match (if it was even 10 seconds)...

Also, the game announcer audio is also about 2 ahead of the match, as he is correctly predicting everything :P

Re: Hot Goal Timing Issues
 

After just coming from the VA regionals day one, I was surprised to discover this issue... my bad.

What I don't understand is why the startup logic for the lighted indicator and the dynamic indicator are opposite...

ie: Before auto starts, the LIGHTED indicators both indicate NO hot goal. whereas the dynamic indicators both indicate a HOT goal.

So if you are waiting for a LIGHTED indicator and they come on late, at least you don't take off and score prematurely.

But with the *mechanical* dynamic indicator, any delay in the flip to NOT HOT will cause the robot to take off and score. Adding a "guesstimate" of how long this will take in the code is a realllly bad habit to get into.

It seems to me that both indicators should start in the NOT HOT position, and then transition into HOT mode as required. This would eliminate any false starts.

Re: Hot Goal Timing Issues
 

Orlando's head ref generally refused to accept field faults;
"I don't have time to investigate scoring errors" was what she told us when we confronted her about scoring glitches.

I found 5 hot goal errors in the first 20 matches played:
1. http://www.youtube.com/watch?v=wNWBS...7MSz&index=123
2. http://www.youtube.com/watch?v=ItRyC...9Hg DQxrs7MSz
3. http://www.youtube.com/watch?v=R-hDB...rf9HgDQxrs7MSz
4. http://www.youtube.com/watch?v=shWpl...9Hg DQxrs7MSz
5. http://www.youtube.com/watch?v=DuCft...9Hg DQxrs7MSz


Also why are the hit goal lights coming on during the first few seconds of teleop?

Re: Hot Goal Timing Issues
 

We noticed this bug in the Virginia Regionals this weekend during the eliminations, and not anticipating the delay cost us a hot goal or two.

Re: Hot Goal Timing Issues
 

We also noticed the issues with Orlando, but I was hoping from Frank's blog this week where he addressed the issue, this problem would be in the past. I know they will get this working better, everything seems to have improved week to week.

http://www.usfirst.org/roboticsprogr...C-FIRST-Values

Re: Hot Goal Timing Issues
 

At Wisconsin we were missing the hot goal when it would light on the side we were on first. The first couple of matches on Friday it was not a problem. Half way through elims we noticed what was actually happening so we added a .5 second delay at the beginning of auto. From then on we never had any problems with it.

Re: Hot Goal Timing Issues
 

The reason it appears that the hot goals are still lit in teleop is because the audio/video aren't synced. The audio is slightly ahead of the video.

Re: Hot Goal Timing Issues
 

At the Orlando Regional, our team's auton. would check the Hot Goal about a quarter second after the robot was enabled for auton. During the matches, it would always think there was a hot goal because the vision target hadn't changed yet to indicate that the goal in front of us wasn't hot.

While changes could/will be implemented to compensate for the lag, it'd be nice to have the lag fixed entirely.

Re: Hot Goal Timing Issues
 

We ran into the same issues as our autonomous does roughly the same thing.

It was also hard to fix the problem because there was so much inconsistency in the lag/delay of the hot display.

Re: Hot Goal Timing Issues
 

In LA it was really inconsistent, sometimes it would switch right away, sometimes it took a second and a half, leading us to miss our hot goal shot if the goal we were aiming for was hot second.

As someone mentioned above, this could easily be solved if the indicators started the match in the "not hot" position and flipped down to indicate hot rather than the other way around.

Re: Hot Goal Timing Issues
 

Video : http://youtu.be/rMa97wE1XIc

Week 4 was our fist event, and having read about the issues and seeing it on the videos we worked hard to get this worked out on Thursday practice matches.

We are using a sensor to detect the dynamic reflector, we line up at the start of the match, and we have to make our hot detection prior to moving the bot, once we move the photoeye is no longer aligned.

We chose this as we have never done vision processing on a comp bot yet, and this seemed so simple that it was not worth the effort, for the point bonus.

This was taken at Week 4 Midland Mid Michigan event, and the timings below were calculated with raw video from my Nikon D5100. I am not sure about the frame rates after processed by YouTube so posting data here.

Summary, we have to wait a full second to detect, it was 750 mils to see the dynamic sensor move in frame. Also the second between 6 and 5 on the clock is significantly longer than a second. I suspect as the field electronics are running the code to change the states of the dynamic sensors and lights, there is extra processing happening. It appears that the added length from 6 to 5 is the taken off from 5 to 4 as 6 to 4 timing is 2 seconds.

For our bot, 1 second after autonomous starts, we check the sensor, and then turn on the underglow to match the goal we are shooting at.

Re: Hot Goal Timing Issues
 

When did the 2nd hot goal light? Hard to tell from Youtube.

Thanks for taking these measurements.

Re: Hot Goal Timing Issues
 

The field update for week 4 seems to have made all the hot goal delays less than one second. They've also changed the timer on the video display so that it turns yellow at 30 seconds.

Re: Hot Goal Timing Issues
 

Thanks for collecting this data.

I don't know whether I should laugh, or slam my head into my laptop.

Re: Hot Goal Timing Issues
 

Laugh first, head slam second and hope it knocks you unconscious so you don't have to worry about it anymore.

Re: Hot Goal Timing Issues
 

Frame 222 - Right Goal Only lit
Frame 223 - Both Goals lit
Frame 224 - Left Goal Only lit

I shared the raw video file on my goggle drive, you should be able to click the link to download. Not sure if google will try to play or not, hopefully you can download.


https://drive.google.com/file/d/0B9P...it?usp=sharing

*when you click the link, you can use the "File" menu to download.

Re: Hot Goal Timing Issues
 

Also, picture of the actuator for the dynamic reflector.
I would guess this reacts much quicker than the 750 mils. :)
Pretty sure it isn't hardware.

https://www.facebook.com/photo.php?f...type=3&theater

Re: Hot Goal Timing Issues
 

Team 3018 was in 18 matches week 4 at Wisconsin (19 autonomous periods since one match had a replay declared partway through telop).

We hit the hot zone in 18 out of 19 attempts. The reason for the one failure was that the hot zone flapper stayed hot on the non-hot goal for the first 5 seconds. We hit the shot in the first 5s because that is what the flapper told us to do.

The robot can score in about 1.8s from the white zone so the auton algorithm is to wait for 2 full seconds before checking for the hotzone (we use vision tracking of 4 pics per second). It begins moving as soon as it sees a hot marker or until a timer set at autonomous_init() hits 5s.

I've seen us start moving *before* the hot goal has moved to our side but it is always hot by the time we hit it. I think this must be due to the long 5-6s interval.

At our first event (Lake Superior week 2) we had unbelievable issues with the hot zone. Originally we waited only 1s and we were using the drive station object (java) to check match time to decide when to go. We were always going early so we first had it start waiting 2s instead of 1s. But we would still always go early. We set our own timer in autonomous_init and things started working like at home, but we kept the 2s wait 'just to be safe'.

Then we discovered the flappers at one end of the field were reversed, and later we had another stuck (both stay hot) scenario. We lost a match by 3 points in one match where the field lied to us about which was hot (we'd have been the first seed instead of second had that worked properly). Finally, (completely unrelated to to hot zone targeting) we had a physical catch to keep our robot in frame that a motor had to break away from. By elims we were bent and battered so even though the robot was moving for the hot zone, the breakaway failed for mechanical reasons (catch too firm all of a sudden) and the shot never happened. We only scored 5pts for about 6 matches in a row. A piece of scored electrical tape allowed us to function properly in the very final match.

Things were certainly better week 4 at Wisconsin (we used a magnet base breakaway which completely solved the one problem), but not quite perfect due to the one bad flapper event.

It's only 5 points, but it can be the difference in some matches, so it is nice when it works properly.

Re: Hot Goal Timing Issues
 

Those situations, if they occur again, should be brought up to your FTA - those sound like prime candidates for field faults.

Every morning the field staff should run a full test where they check for this sort of thing, so they should be pretty rare.

Re: Hot Goal Timing Issues
 

Seriously?

Coding timers that remain true to real-time while other stuff is going on is not difficult. Seems to me that the field timing should probably have 'remains true to within 100 ms throughout the match' as one of its mission critical requirements.

Its stuff like this that makes me seriously question both the people *doing* the work, and the people *checking* the work in Manchester.

Re: Hot Goal Timing Issues
 

We brought the issues up to the FTA at Lake Superior. The one failure at WI occurred in our 2nd quarter final match and it did not affect the outcome. My son is the lead programmer and was driver and he saw the problem. I'm not sure if he mentioned to the FTA or not, but we started in the same place for finals and it was fine.

At Lake Superior, we had to review video, check code, etc. before we found the root cause of the problems. The reversed flappers I think were only problematic on practice day. The stuck flapper required us to review the video before we found the problem and by then it was too late to ask for a fault. (I think we did ask and were told it was too late-- it was a couple matches later).

None of the problems hurt us from winning Lake Superior, nor reaching finals at Wisconsin so we're not grousing about it-- just sharing our own observations.

We now *always* watch the flappers (both left/right) every match as you never know when those 5 points will become critical and unless we notice it live it will be too late to go to the question box. Even then, I'm not sure it will result in a replay as it is unlikely the refs are watching for it and they won't accept video evidence.

Re: Hot Goal Timing Issues
 

Any news on if the initial hot goal delays have persisted through week 5? If so, is the delay now consistently <1sec? Just wondering for autonomous implementation. Thanks!

-Mike

Re: Hot Goal Timing Issues
 

Looking at the images we recorded from DC indicates that there was still a delay.

Re: Hot Goal Timing Issues
 

At Dallas I never noticed a problem

At Oklahoma there was no problem with the hot goals, however apparently the FMS was failing to send timing packets and would randomly ruin a robot's awesome autonomous for no problem of their own.

Re: Hot Goal Timing Issues
 

Can you/someone elaborate on this? (Preferably in lay-speak/non-programmer speak)

Re: Hot Goal Timing Issues
 

This means the FMS forgot to follow the game rule (5 seconds per goal, "randomly" light up one goal for first 5 seconds and the other goal after the first 5 seconds) and turned on the hot goal lights and the reflecting tape little too late or little too early. Off recent I am not following the auto-on period, Week 1 Michigan had seen, not 5 bonus points are trivial compared to 50 fould points to worry about.

Re: Hot Goal Timing Issues
 

At Waterford there still appeared to be some delays, but I would have to go back and look at match video to be 100% sure.

We had to continue to increase our hot goal detection delay in our software before we started consistently detecting the hot goal. We were 100% accurate in detecting the hot goal after we bumped up our delay to 1.2 seconds. (The delay you need may be different due to latency within your software due to image processing and communication. We use the lowest camera resolution at 20 FPS. Our image processing is done at the driver station and the hot goal status is then transmitted to the robot over UDP.)

Re: Hot Goal Timing Issues
 

I am by no means a programmer and don't know exactly how it works. This is the way I understand it

You can choose to program your robot to operate its autonomous based on the FMS clock. (Ie: wait for hot goal detector to indicate hot or if it fails just simply shoot at second 9). Instead of relying on your CRIO to keep an active clock it bases its time delays on official markers (timing packets) sent by the FMS.
Apparently it was messing up, in the sense that it is supposed to send (in laymans terms)

Real clock | Packets sent
Second 0 | 10 seconds left
Second 1 | 9 seconds left
Second 2 | 8 seconds left
etc

But was sending instead (in an exaggerated case)
Real clock | Packets sent
Second 0 | 10 seconds left
Second 1 |
Second 2 | 9 seconds left
Second 3 | 8 seconds left
Second 4 |
Second 5 | 7 seconds left
Second 6 | 6 seconds left
Second 7 |
Second 8 | 5 seconds left
Second 9 | 4 seconds left

In this case, it never told the robot there was less than 4 seconds left (autonomous is killed at real time Second 10)

This problem may actually be the exact issue with the hot goals. I never noticed a problem with the hot goals, but I was never specifically watching.

If the hot goal lights are also relying on these packets to work (I cant imagine why they wouldn't be), it would not switch in the above case until second 7 had passed.

Our robot was initially programmed to rely on this system, but all day friday it would never ever shoot the auto ball. We thought it was mechanical problems etc but once we got whiff of this potential problem we (by we I mean the coders :P) changed the code to only operate on an on-board clock, and never had a problem again.

If it works differently than I think it does, please correct me, but this is how I have come to understand it.

Re: Hot Goal Timing Issues
 

If the FMS sends a time stamp, I am unaware of this. So Brian I do not know if your analysis is correct. But in OK City during autonomous the FMS was not sending messages at the normal rate. Practice mode on the DS worked properly. The FMS at Dallas worked properly. But the FMS in OK City would go silent for random amounts of time, often seemed like multiple seconds. The problem seemed to be only during autonomous.

We had to remove any dependencies on the FMS message rate and/or time of arrival to get our autonomous to work correctly. Whether or not any team would experience this depends much on how their autonomous code is structured. Ours is all custom-code and the effect was crippling. We went from hitting 90+% on Saturday in Dallas to not shooting in auto all weekend in OK City. We would run 10 perfect auto sequences on the practice field then go out for a game and some portion of the sequence would run but never all of it. 1296 did not discover this. If other teams at OK City had not figured it out, we still would not know what went wrong.

Re: Hot Goal Timing Issues
 

FMS does not send a time stamp.

Can you post a driver station log from a match where this occurred, as well as from practice mode?

I'm not sure what you mean by GMS, but the FMS talks only to the driver station, and the driver station speaks exclusively to the robot. This is described in the FMS white paper.

If the FMS is telling the DS to go to disabled, this would cause the DriverStation::GetMatchTime() method to reset each time. However, this would also be logged in the driver station log.

Re: Hot Goal Timing Issues
 

The light delay seems better, but not fixed: http://youtu.be/NYgLapDfBkQ?t=1m16s

It has been 5 weeks and this still isn't working correctly so I guess this is the final product we are buying. :(

Re: Hot Goal Timing Issues
 

Bummer. This is a pretty big issue for our 3 ball hot goal routine, since we need to see the vision target within the first .5 seconds to make a decision and have enough time to shoot all three balls. We're not cool enough to shoot all three in <5 seconds... ;)

FIRST is penalizing teams that push the envelope of excellence in auto this year. It's pretty disheartening to tell my kids that their auto modes won't work because FIRST couldn't follow their own game rules. Maybe week 6 will be the golden week, who knows!

Holding out hope.

-Mike

Re: Hot Goal Timing Issues
 

The DS computers are at the school and frankly I'm exhausted, no robot stuff for a few weeks.

I'm pretty sure you know that I used GMS instead of FMS. Perhaps there was something about our DS computer that was not relaying the messages in a timely manner. But it is the same computer we used in Dallas. And like I said, it was others teams that pointed this out. So we were not the only team experiencing the delays.

I didn't say anything about state changes. They seem to work properly and happen at the correct temporal offsets from the start of the match.

We have never used this method. It is the relative time of arrival of the periodic messages from the FMS that hurt our auto code.

Re: Hot Goal Timing Issues
 

At this point, this is the first I've heard of anyone at Oklahoma, or any other event with this type of problem, so I'm poking at the only lead I have. Which of the event volunteers were aware of the problem?
Can you explain exactly what you were measuring, and how you were using it?

Re: Hot Goal Timing Issues
 

I saw a few like this at Hartford. Even on the ones that appear consistent, there's still variation. Our robot activates the solenoid to fire our shooter (which takes a second to fire) at exactly four seconds after autonomous starts. Timing this at home, the ball always entered the goal in the last half of autonomous mode. At competition, the ball sometimes make it in before the goals changed, and sometimes make it in after the goals changed.

I'm not sure why this seems to be such a difficult problem for FIRST. I was told at Hartford that the issue is because the lights aren't responsive enough and can only update once a second, and that the timing variation isn't the field's fault, but the crazy light show they put on during alliance selections seems to prove otherwise. I think the problem is with the FMS sending the data at the right time. There was also a five second delay between assists being counted on the video display with the green dots and the field LEDS being updated, and several times, the match timer stopped working. There were also issues of the pedestal light not lighting the entire match, even though the referees had ended the cycle.

Re: Hot Goal Timing Issues
 

Shooting 3 in 5 seconds doesn't help when the second goal is only hot for 4 seconds.

Re: Hot Goal Timing Issues
 

Truth. Ouch. You guys got hit the hardest by this. Saw you running two hot at Waterloo Elims. We may have to do the same.

Re: Hot Goal Timing Issues
 

I also saw the delay at Waterford, but like at Midland last week, our one ball hot detect worked with a 1 second delay from the start of auto. We only used the 1 ball hot detect twice at Waterford, so there is not many samples. The 2 ball auto does not use hot detect, as we can't load and shoot in under 2.5 seconds.

Re: Hot Goal Timing Issues
 

Do you play some sort of technical role for FIRST?

I don't know which event volunteers were informed about the problem. Several teams in the practice area were complaining about the delays and it sounded like they were talking to the field techs but we did not.

Our auto code executes a script file. Some of the commands are timed internally, for example "MMOVE 14.0 1.0" (move forward 14 feet at full speed). But there are many other commands in the script. To transition from one command (or line) to the next we send a message from the task that receives the DS messages (which only runs when a message from the DS arrives). On the practice fields and the Dallas field this worked as expected. On the field in OKC there were long hesitations from one command to the next. We display the commands as they are executed on the dashboard. I added timestamps and the responses were delayed by pseudo-random amounts of time on the field. It was very late in the event that we diagnosed this. Our priority was to remove the dependency which we did by isolating the script engine in a task that required no input from the DS other than the state changes. Then we changed our auto on Saturday afternoon to simply pull forward a few feet (had alliance partners with reliable 2-ball autos) thus we recorded no valuable data.

Re: Hot Goal Timing Issues
 

Yep. The sounds are way out of sync as well. We're actually on the other half of the field from that video, and we shoot our last ball at 9 seconds. The 'auton over' sound routinely goes off before we've fired the ball, but the lights stay on and we score every time.

We've turned off vision entirely. It's not worth the guessing for 5 points.

In addition, there was usually 1-2 seconds remaining on the game clock at the end of teleop when the robots were disabled.

Re: Hot Goal Timing Issues
 

We also ran into his problem at the Granite State and Northeastern districts. Our autonomous detects which goal is hot at the beginning of autonomous and uses that to decides whether or not to wait to score.

This field bug meant that we couldn't tell teams that we could consistently score in the hot goal. Our robot only goes fast enough to reach the goal and score in just under five seconds, so it is not possible for us to wait a second before detecting the goal.