Quote:
Originally Posted by Bryscus
It turns out that our code had thrown an exception at one point and VXWorks had killed our main robot task. There is a network communications task however, that remained operational - thus, we never lost comms, but the robot was dead.
|
The (work of) the network stack in VxWorks is accomplished in the "netTask". One can alter the relative priority of this task to application tasks to achieve desired behaviors. The netTask was probably alive as well as the FRMComm task.
The standard behavior of VxWorks to an exception is to suspend the offending task (not the entire system) and print out a message to the console. So what you are saying makes perfect sense!
Our students had many such problems (during development) where the robot seemed to still be connected but some portion of it stopped operating. We separate the control of every major component into a separate task (drive, gather, shoot, autonomous, etc) so any one of the subsystems might fail. It was ALWAYS because of a human programming error. Luckily I teach Wind River courses and knew exactly what to look for.
Many of our problems came from the C/C++ code for capturing and analyzing images. One really had to know what was going on to migrate the NI Vision stuff to C++ (while removing some of the memory allocations that slowed it down) and get it just right. I BELIEVE there are comm problems with the FMS this year but I'll bet a lot of teams issues relate to the camera/analysis code and memory allocation/manipulation errors.
Quote:
Originally Posted by Bryscus
Now, fast forward to the Championship. After seeing 118 stationary in the first match I went over to share my sentiments about the situation and impart the valuable knowledge that I had gained over the season with them. I have no desire to win anything knowing my competitor was maimed because of something out of their control. They are a great team and don't deserve to not compete.
|
An exemplary example of GP - your alliance was talented, gracious and professional!
Quote:
Originally Posted by Bryscus
It seems to me that there is either a bug in the networking stack on the cRIO or in the field communications computer. Even until the last match, I would occasionally see networking errors on the diagnostics tab. I hope this can be rectified in the future and I'm sure FIRST is putting every effort forward to resolve this debacle.
|
The network applications could be buggy but the network stack is pretty bullet-proof. It is derived from the BSD 4.4 stack and pretty well exercised in the real world.
Quote:
Originally Posted by Bryscus
As for the 180, 25, and 16 alliance I feel that we really were one of the best alliances out there. I feel that 16 was by far the best defensive robot at the competition. No matter who we went up against, 25 and 180 always had balls to shoot. It's a testament to 16's rugged design that they could even stay together with the incredible pounding they took every match. We never ran dry, while the other alliances were scrounging for ammo. 25 played brilliantly - both accurate and efficient. We were an alliance that worked well together and the cunning and experience of 25 and 16's coaches was invaluable in maintaining our advantage. I still can't believe the stars aligned to allow such an alliance to happen. It was an absolute pleasure to compete with both teams and I'm proud that we can now call them friends.
|
I enjoyed the matches and have no problems lauding 180/16/25 as our 2012 FIRST champions! But to FIRST - please fix the FMS! And please start by rotating out the D-Link router/bridges/radios.