THE HORROR! THE HORROR!

[JohnSchneider]

16 and ourselves had a buggy match at Lubbock.....where we both sort of spun after losing connection. A few times titanium was spinning in auto in Elims as well...

From what I've seen this is sort of a popular failure...why I wonder do all the robots react like that?

[Kusha]

Originally Posted by animenerdjohn

16 and ourselves had a buggy match at Lubbock.....where we both sort of spun after losing connection. A few times titanium was spinning in auto in Elims as well...

From what I've seen this is sort of a popular failure...why I wonder do all the robots react like that?

What language did you guys program in? (Curious)

[itsjustmrb]

We had very few problems at Hub City until the championship finals. In the first match our CRio decided to reboot in the middle of the match and in the last match it rebooted as soon as autonomous started. Please don't start flaming me, I am not making excuses or blaming anyone or anything. I am just stating the facts. I know there was at least 2 others that had the same problems and the suggested fixes were cleaning the CRio and changing the black connector to the green one.

We use labview and did not make any code changes before the hiccups started.

Mr. B

[DominickC]

Being the programmer last year, and the one on disaster control at the time of the incident at the WPI Regional last year, I can speak in greater detail to the issues we experienced.

It was round 3 of the quarterfinals. Only mild issues with initial FMS connection were experienced at any point prior to the issue. Auton executed as expected. When transitioning from Auton Disabled to Teleop Enabled, the robot began spinning in a tight circle, and was not responding to any driver commands.

Later inspection from the FTA, CSA, as well as a National Instruments rep yielded no result. The code was ruled out as a non-issue.

EDIT - We later attempted to replicate the failure using FMS simulation software provided to us by the CSA. All attempts at replication failed.

[Kevin Sevcik]

I'm told many problems at Lone Star were caused by multiple teams trying to run cameras at 640x480 at 30fps. Or in one case, TWO cameras at that rate. Teams have been instructed to throttle down to 320x240 @ 15fps and things have calmed down a good bit.

[thinker&planner]

May I say that we were one of those teams in Florida who was "spinning out", and that was not due to FMS. It was our vision code that kept spinning because it couldn't find a target (we are still having problems, but whatever). Unfortunately, this happened during autonomous and we had discs in the bot. The judges weren't very happy about our spinning, disc-shooting robot (but they were understanding later). We call this the "Death Spin".

On the other hand, we HAVE had some problems with communications. In our last two matches, we suddenly lost comm right after auto ended. we grabbed the controls, drove to the feeder,loaded discs, turned around, and died. The driver station said that we had comm and code, and yes, we do have the most recent version. In case you want more details; we program in Java and use the Smart Dashboard. Our robot worked for the whole day until our last two matches, and we can't remember changing our code majorly. Our robot works great while tethered with the ethernet cord. We had to reduce the resolution of our camera because the control system was delaying so much that we accidentally fell over.

Other teams seem to be having this problem and we have consulted with the control system experts who have told us this: Java has a 5-sec delay when it resets the gyro (andymark) which our whole drive system is based off of (orientation to the field). We moved the gyro zero function into the disabled code but haven's been able to test it yet. Our code might be crashing. We need to get to the arena early to test tomorrow.

If you have suggestions, that would be great, and I hope that we can resolve this issue soon (1st match tomorrow!).

[cmrnpizzo14]

I understand your point, but I believe that you are overreacting just a little bit. In particular, "THE HORROR! THE HORROR!" might not be the most appropriate title on this thread.

As far as I know, there were no significant field issues at FLR this year. That is the only regional I know about for sure right now. I think that things will get fixed by FIRST as soon as they can, but for now there should probably be more work devoted to fixing the automatic scoring system. I think more teams are getting burned by not knowing what the score is at the end of the match as opposed to FMS issues.

We will see more as time continues but for now I think that FMS is doing a pretty good job overall.

[pfreivald]

The only robot at FLR that randomly spun in circles was 1551 in our first match, and that stopped when we disabled our gyro...

[Gregor]

Originally Posted by thinker&planner

We had to reduce the resolution of our camera because the control system was delaying so much that we accidentally fell over.

What?!?!

[Jared Russell]

Originally Posted by Kevin Sevcik

I'm told many problems at Lone Star were caused by multiple teams trying to run cameras at 640x480 at 30fps. Or in one case, TWO cameras at that rate. Teams have been instructed to throttle down to 320x240 @ 15fps and things have calmed down a good bit.

I thought bandwidth caps were in place...?

[Kevin Sevcik]

Originally Posted by Jared341

I thought bandwidth caps were in place...?

I can only tell you what the FTA mentioned to me in passing. I'll note that he didn't say and I didn't say that the cameras were causing issues for teams other than the ones running the cameras.

[Nuttyman54]

Originally Posted by Jared341

I thought bandwidth caps were in place...?

Based on reports from this thread and others, it seems that the bandwidth limits are either not in place or not working, at least not at all events. It also seems that the Quality of Service packet prioritization is not working properly either. Several people have reported needing to turn off or turn down camera resolutions to resolve lag and loss of comms issues not only for their robot but for others in the same match.

I was not at any of these events nor do I know anyone personally who has reported these symptoms, so it's second hand information at best. The fact remains that turning camera feedback to the driverstation down or off seems to have resolved many of the issues at events. Hopefully FIRST will address this in some regard in an update or blog post soon.

[mtaman02]

Originally Posted by Kevin Sevcik

I'm told many problems at Lone Star were caused by multiple teams trying to run cameras at 640x480 at 30fps. Or in one case, TWO cameras at that rate. Teams have been instructed to throttle down to 320x240 @ 15fps and things have calmed down a good bit.

^^^
Had the same issues with the NYC Regional with the cameras. Once we tamed the settings the field ran the way it did the previous 2.5 days before. Also had to look for a couple of other things that tied up the comm bands.


I don't believe there will EVER be a comm problem free season. Thats the nature of technology. The field and FMS always gets heavily looked at both locally and through a remote connection whenever a field allegedly has issues. Nothing is fool proof - all that can happen is that it improves a little with each passing day.

[Jefferson]

Originally Posted by Kusha

What language did you guys program in? (Curious)

We use c++.

[Alpha Beta]

Originally Posted by animenerdjohn

A few times titanium was spinning in auto in Elims as well...

From what I've seen this is sort of a popular failure...why I wonder do all the robots react like that?

Our spinning was due to a failed battery. We had 2 separate instances in elims where batteries showed 13 volts on the charger and dropped to 6 volts within seconds during autonomous.

To the best of my knowledge we had no problems with the FMS in Hub City.