Take an exit with dignity

[synth3tk]

Originally Posted by ideasrule

What's wrong with valuing competition? It's the most powerful driver of progress in existence. Let's face it: it wasn't community service or gracious professionalism that made the light bulb, the telephone, the computer, radar, or any other technology possible. It was intense competition, often with war in progress or looming on the horizon.

As for communication problems, 610 didn't have any problems except during one match when the bridge power cord came loose, but I'm still very anxious about our next regional.

I'm not saying to get rid of it completely, which you seem to assume. I just think that in a program like FIRST, I feel (my opinion, not fact) that all I see is regarding the competition itself.

But whatever. Maybe I'm just crabby.

[ideasrule]

Originally Posted by synth3tk

I just think that in a program like FIRST, I feel (my opinion, not fact) that all I see is regarding the competition itself.

I agree, but don't see it as a problem. After all, it is the FIRST Robotics Competition.

[Pat Roche]

Originally Posted by FRC4ME

Are you using SimpleRobot or IterativeRobot?

Also, how are you implementing the "do nothing for 19 seconds" part? Timer.delay()? Thread.sleep()? wait()?

Sorry I can't speak to that with much knowledge. I only know the 10000 ft. logic of the program. I can ask around and see what I get for an answer.

[Racer26]

Originally Posted by Radical Pi

It's a known issue and 100% error of the team's programmer. Java and C++ code waits for the autonomous code to finish execution even when the FMS switches to teleop. The LabVIEW error is a little tougher to explain but it is user error.



coincidence

Not entirely sure I agree here.

Yes, C++ (what 1075 uses) DOES wait to start Teleop() until after Autonomous() is completed.

However, Autonomous() at least, as defined in the SimpleRobot template, has a While(IsAutonomous()){} loop in it. If your code is designed to pay attention to this fact, you should have no problems forcing your Autonomous code to stop operation the instant FMS changes your robots status from Autonomous to Teleop.

[The Lucas]

Originally Posted by FRC4ME

This right here is an indication that FIRST does not fully understand the FMS they are dealing with. Correct me if I'm wrong, but the order in which you connect devices to a WiFi network should have no affect on how the system works. We have found a solution that seems to make things work, but I doubt anyone understands why it "works," and whether it leaves behind any residual problems. One of the first steps toward solving the FMS bugs, IMO, would be to determine why the boot order matters. This could possibly shed light into the root cause of other problems.

The gaming adaptor problem is a tough one and not entirely FMS's fault. I thought the WGA600N worked well last year. Unfortunately, it was discontinued for the WET610N. Now you have lots of teams with the old adaptors, and many teams with the new ones since they cant get the old ones (and we have an unavoidable mix).

Before I say this next part, let me preface it by saying that Cisco/Linksys makes great products and I thank them for their sponsorship of FIRST. Linksys products are my preferred brand and what I usually tell family and friends to buy when they ask for advise. I use the old adaptor on the comp bot and the new one on the practice bot. The 2 adaptors are noticeably different. WET610N takes much longer to even connect to the Linksys router, independent of any other FIRST equipment. What is it doing during this time? Looking at the Cisco site it seems to be focused on Streaming video to HDTV and has 3 antennas as opposed to 2 . Of course more features for increased boot time is a great trade-off to make in a product that doesn't need to boot often in its intended use (once a month maybe?) Keep in mind we are not using these products for their intended use (see the power adaptor which is even harder to keep in on the new one). For our use, boot time is critical.

Now the big problem (as I have heard from web casts I'm not an FTA) is that the new ones tend to interfere with established connections of the old ones. This would seem to point to an FMS bug but it could be a problem with the 2 adaptors. Has anyone tried to use both at once in their lab? If I was using both adaptors at home and setting up the new one temporarily knocked the old one off the network, I probably wouldn't even notice because it would reconnect in a few secs. Unfortunately in our use this is a big deal. It would be nice if Cicso could provide some sort of WGA600N compatibility firmware for WET610N. Maybe there is a set of settings that can achieve this? (I dont know)

Originally Posted by Tom Ore

Our programming mentor thinks he may have found the issue. Sorry I can't be too specific, but he changed the location in code when the camera is launched. We'll find out in Minneapolis.

We get the first instance of the camera in the constructor (for the robot class in C++) after a 10 sec wait. I have tried other places that have not work (however updates may have fixed this). Keep in mind that you are not just connecting to the camera, you are connecting the PCVideoServer to the Classmate. I wish that they would decouple the Camera and the PCVideoServer feed like last year. Yes I know it is easier to use, but you don't have the ability to control the feed anymore and start it at a different time.

Originally Posted by Pat Roche

The code was a simple drive forward for x seconds then do nothing for x number seconds (sorry I cannot recall the exact number of seconds but it was approximately 19). There was nothing executing beyond that. We tested this during our system check field side. It worked 50 matches in a row successfully. It was the only autonomous code we had in our robot. It makes no sense that after match 50+X all of a sudden a timing issue like that would begin occurring without changing something in the software.

In Baltimore, one team was having issues transitioning in teleop from auto using LV. they had timer waits at the end of auto. I advised them to get rid of the end of auto timer and disable the user watchdog. They seemed to run fine after that when I saw them and they didn't ask for any more help.

Any waiting (over a tenth of a sec) in auto is just a bad idea to me. I know it is easier to program but it is important that you get out of autonomous and into teleop ASAP after the teleop bit is set no matter when that happens or what your robot was doing. Instead of waiting on timers, check them periodically and if auto period ends before your timer reaches its value, go to teleop.

[Racer26]

Perhaps Cisco/Linksys could develop custom firmware for their WGA600N or WET610N for FRC, so that all the fancy features we don't need are turned off, and the system is optimized for lightning fast boot and connection.

Seems plausible to me...

[Isaac501]

When we use our WGA600N, we are communicating in about 7-10 seconds. The WET610N takes 30-45 seconds. Bootup time aside, we haven't had any problems with the WET610N. Though waiting is *very* annoying when you're in a hurry. We'll be replacing the "new" bridge with an "old" bridge next season, assuming the WGA600Ns are still legal.

[Racer26]

...I wouldn't bank on anything for next season, given all the trouble this season. FIRST may well come up with an entirely new solution to the Wifi->Robot link.

[Mathguy77]

The Toltechs had serious communication issues at the Arizona Regional this year, and we were by no means the only ones. Like most of the anecdotes here, we worked fine tethered and in practice. But, on the game field, we had slow and/or dropped connections.

At the FTA's suggestion, I even went out on Friday to a local BestBuy to purchase a new gaming adapter. Apparently the one we had was "twitchy." (His words) Even then, we would either not connect or lose control after a few seconds of Tele-op.

One thing we felt (my fellow mentors on 499) was that the gaming adapter was designed to remain stationary on a desk or shelf, always powered on. Perhaps the bumps and shocks of competition, along with numerous powerups/powerdowns, are simply more than it was designed to handle.

The worst part for me was to see the disappointment on my students faces. They spent (like everyone) many hours working on the bot, and many hours traveling, just to see the result of their work sit on the field. Very Frustrating!

Pete

[Pat Roche]

Originally Posted by The Lucas

In Baltimore, one team was having issues transitioning in teleop from auto using LV. they had timer waits at the end of auto. I advised them to get rid of the end of auto timer and disable the user watchdog. They seemed to run fine after that when I saw them and they didn't ask for any more help.

Any waiting (over a tenth of a sec) in auto is just a bad idea to me. I know it is easier to program but it is important that you get out of autonomous and into teleop ASAP after the teleop bit is set no matter when that happens or what your robot was doing. Instead of waiting on timers, check them periodically and if auto period ends before your timer reaches its value, go to teleop.

I can see where you might be coming from but what doesn't make the slightest bit of sense to me is that it started occurring after 50+ matches. It seems to me something like this should have surfaced much earlier and doesn't explain why during the system check auto worked fine and didn't get hung up. Sorry I'm not trying to be argumentative but nothing seems to fit all the symptoms that were displayed by what was a previously flawless working robot.

[Radical Pi]

Originally Posted by 1075guy

Not entirely sure I agree here.

Yes, C++ (what 1075 uses) DOES wait to start Teleop() until after Autonomous() is completed.

However, Autonomous() at least, as defined in the SimpleRobot template, has a While(IsAutonomous()){} loop in it. If your code is designed to pay attention to this fact, you should have no problems forcing your Autonomous code to stop operation the instant FMS changes your robots status from Autonomous to Teleop.

The thing is Autonomous coding is MUCH different from teleop coding. In teleop, the entire code is usually a loop that reads in data at the beginning and writes at the end. IsTeleop() is a fine solution to ending the teleop properly.

Autonomous on the other hand, it usually seen more as a pre-programmed set of instructions, executed sequentially. Very few teams do something as complex as a state machine that uses the IsAutonomous check in a continuous loop. The average C++/Java team will probably do waits between pre-defined commands, which does fail the termination part. The most common problems are when teams don't enforce the end of autonomous period in their code and just let it sit, waiting for an input (such as a ball hitting a sensor). Even in your IsAutonomous loop, if the code doesn't make it through the loop then end of autonomous is never checked, and the loop cannot end.

[Zach Purser]

Let me go ahead and show my ignorance here. I haven't been part of programming the robot since FIRST switched to the current controller, but aren't there any watchdog timers to prevent you from getting stuck in automode?

[Radical Pi]

Originally Posted by Zach Purser

Let me go ahead and show my ignorance here. I haven't been part of programming the robot since FIRST switched to the current controller, but aren't there any watchdog timers to prevent you from getting stuck in automode?

Nope, none at all. The SimpleRobot template for code simply is call Autonomous(), wait for field to signal end of autonomous, run Teleop(), wait for field to signal end of teleop.

[Greg McKaskle]

I was assisting at the Dallas regional, and would follow nonmoving robots back to the pits to help resolve the problem. We saw a small number of issues that explained the failures.

The most common issue was loose power connectors. Robots that disable for ~15 secs, then continue had the cRIO reboot -- wiggle the connectors at cRIO and at PD to find which is loose. If the robot is disabled for 30 to 40 secs, check power to the bridge. Also, bridge only power issues don't affect RSL. If it was 40 secs and RSL goes out, check battery connectors.

Clearly, a cRIO reboot that isn't explained by a loose connector can also be a code issue especially if running C/C++.

If the reboots are due to a weak battery, the RSL tends to be dim. Clearly the DS should help identify this as well.

Another issue, harder to diagnose from the stands is the Security button on the bridge. If the bridge can move and an impact can cause the lock button on the front to be pushed, the robot will not move for the remainder of the match, and the Security LED will be blinking green or amber at about 3Hz on the bridge after the match. It blinks green for about two min, then amber for several more minutes.

One well built robot had the bridge security button pushed several times. Testing the bridge outside of the robot, it seemed that the board moved within the case, possibly due to their good job of hard hit testing before ship. Replacing the bridge resolved their issue.

-------

DS setup:
Do not plug Cypress board into an external hub, plug it directly into the laptop port. This may cause the Cypress to stop working, but it may cause the entire hub to drop out. This is often corrected, for awhile, by unplugging and replugging. Hit F1 if the match has already begun.

To test the Cypress board, press the button. If one red LED lights up in response, the board has not been recognized. If zero LEDs light up, everything is fine. This should match the state of the LED on the DS I/O tab.

To test joysticks, click a button and see if the LED on the Diagnostics tab turns blue, or if the listbox line turns blue on the setup page. When disabled, the DS scans for joysticks once per second. This is too expensive during a match, but F1 will force a rescan if connections are changed during a match.

-------

I'm not posting this here to declare that the field or FMS never has issues, but in my investigations, the issue was explained by one of the above. Hopefully this will help with troubleshooting.

Greg McKaskle